Context of this article

The steps in the previous articles created a complete SOA solution model that meets the business requirements. Therefore, we know what requirements that this solution architecture fulfills and what might need to change when the requirements change.

To deploy and run a Web service, we need to create an actual implementation that is consistent with the architectural and design decisions captured in the model. We could create that solution by hand, using the model as a guide. But this would be tedious, error-prone, and time-consuming, and it would require a highly skilled developer to ensure that the architectural decisions were implemented correctly. It is certainly possible to create the solution by hand, and having the model as a guide would be very helpful. But having a complete, formal, verified model gives us an opportunity to exploit model-driven development (MDD) to create one or more solution skeletons from the model and then complete the detailed coding in a platform-specific programming environment. That is the subject of this article. We'll use the IBM® Rational® Software Architect UML-to-SOA transformation feature to create a Web services solution that can be used directly in IBM® WebSphere® Integration Developer to implement, test, and deploy the completed solution.

As with all of the articles in this series, we'll use existing Rational and WebSphere tools to build the solution artifacts and link them together, so that we can verify the solution against the requirements and more effectively manage change. Table 1 provides a summary of the overall process that we'll use to develop the example and the tools used to build the artifacts.

But let's start by reviewing the services and service participants that were created in the previous articles.

Service specification, provision, and use review

Figure 1 shows the service specifications that were identified as needed to fulfill the business requirements. These are the services that are capable of playing the roles in this Business Services Requirements contract.

Figure 2 shows the data model for the service data. This is the model of the information exchanged between service consumers and providers, and it is used to define the parameters of the service operations.

Scheduling

Figure 3 shows the complete Scheduling service specification.

This service specification is a simple interface, because there is no interesting protocol for using scheduling services. Figure 4 shows a service provider that provides the Scheduling service.

The actual implementations of the requestProductionScheduling and sendShippingSchedule behaviors (an activity and an opaque behavior. respectively) are not shown in detail in this diagram, but are defined in the model.

Shipping

Figure 5 shows the ShippingService service specification.

This service specification is a little more complicated, because it models the interaction between a shipper and an orderer by using a simple callback style interaction. Figure 6 shows a service provider that provides the ShippingService service.

The requestShipping opaque behavior that is the method for the provided requestShipping operation invokes processSchedule on the shipping port at some point in its implementation. The consumer who is connected to this port will be expected to provide an implementation of this operation to respond to the request.

Invoicing

Figure 7 shows the InvoicingService service specification.

This protocol is also a bit more complicated. It indicates there is a specific order in which the service capabilities must be used. Both the consumer and provider are expected to follow this protocol. In this case an activity is used to define the service protocol.

Figure 8 shows a service provider that provides the InvoicingService service and the methods providing the service capabilities.

Purchasing

Finally, Figure 9 shows the Purchasing service specification.

This service specification represents the functional capability specified in the original Process Purchase Order business process. It represents a service identified and designed from that business process.

Figure 10 shows a service provider that provides the Purchasing service, and the services it requires in order to do so.

Figure 11 shows the complete method for the processPurchaseOrder service operation using a UML activity.

This diagram corresponds very closely to the IBM WebSphere Business Modeler diagram for the same behavior. The InvoiceProcessing and ScheduleProcessing service operations are realized through the processInvoice and processSchedule Accept Event actions in the process. Notice that the corresponding operations in the interfaces are denoted as <<trigger>> operations to indicate the ability to respond to AcceptCallActions (similar to receptions and AcceptEventActions where the trigger is a SignalEvent). The <<trigger>> keyword is not part of Unified Modeling Language 2 (UML 2); it is included only to highlight how these operations are realized. Note that these operations will not be accepted unless the processPurchaseOrder activity is running and the flow of control has reached the two Accept Call actions. This indicates that the implementation of an operation can determine when there will be responses to other operations.

Services modeling best practices

UML 2 modeling helps improve our understanding of underlying systems by enabling us to abstract away extraneous details. Nonetheless, modeling isn't a panacea, and meaningful model diagrams still can require expertise to create and understand. This is a natural consequence of the need to support a very general model of computing that can be used for a wide range of application domains and levels of abstraction, and it also represents the semantics of several platform-specific execution models. In addition, the types of actions or styles of activity models might need to be constrained to allow efficient transformation of those models to the target execution platform.

In this case, the target platform is Web services and the IBM SOA programming model supported by WebSphere Integration Developer. This includes business objects (XSD), interfaces (WSDL), module assemblies (SCDL, an IBM predecessor of SCA), processes (BPEL), SCDL (business state machines), and Java™ components. To support transformations of UML models to this particular Web services platform, we need to follow some services modeling best practices. That is, we need to first customize UML to model an SOA solution architecture, and then we need to use a particular modeling style to produce models that can be translated to Web services.

UML is typically customized by using profiles. A profile defines a number of stereotype classes that can extend one or more UML metaclasses with additional properties and relationships. Profiles are applied to UML models to make these extensions available. These applied profiles generally support two purposes in model-driven architectures:

• The first, and most general, use of profiles is to customize the abstractions that are intended to be supported. In this case, we have applied the IBM Software Services profile to our Purchase Order Process model to extend UML to support services modeling. Many of the stereotypes in that profile simply clarify how the UML metaclasses are used to model an SOA solution and to restrict the kinds of things that can be done in UML in order to ensure that the SOA models reflect SOA principles. For example, the <<serviceConsumer>> stereotype is used to indicate a UML component that is modeling a user of services that doesn't actually provide any reusable services of its own. Such a component might represent a business process that is not intended to be reused. For an example of a restriction, the Software Services profile requires all interfaces realized or used by a <<serviceProvider>> component to be handled through service ports, not directly. This is to reduce the coupling between the connected users and providers by having dependencies on the service port, not the component as a whole. Then, when some interface changes, only that port has to be examined to respond to the change, not everything connected to the component.

• The second purpose of profiles in model-driven architecture (MDA) is to support platform-specific markings. These markings consist of additional stereotypes and properties that "mark up" a model with information necessary to translate the model to a particular platform. For example, a UML package may need to have a specific Uniform Resource Identifier (URI) when translated to a Web services container.

Sometimes, these two purposes of profiles are combined. For example, the extensions to UML to support relational data modeling consist of a single profile that both extends UML for entity-relational-attribute (ERA) data modeling and provides the markings necessary to translate the UML domain models into IBM® Rational® Data Architect logical data models (LDMs). The IBM Software Services profile provides this dual role for models that are translated to Web services.

In other cases, one profile can be used for modeling support, while another is used to drive translation. For example, consider the case of modeling SOA designs that are to be implemented in Java™ 2 Platform, Enterprise Edition (J2EE). The latter application can be assisted by applying both the Software Services profile and the Enterprise Java™Beans (EJB) transformation profile to the same model. The Software Services profile stereotypes would be applied to model elements to support services modeling, while the EJB transformation profile stereotypes would be applied to model elements to guide the execution of the Rational Software Architect UML-to-EJB transformation as it generates implementation code. Of course, the same SOA model could also be translated to Web services by using the Rational Software Architect UML-to-SOA transformation tool. The UML-to-SOA transformation would generate Web services by keying off of the Software Service profile markup. It would ignore the markings for the EJB transformation.

The next sections describe some modeling best practices for SOA models that are intended to be translated to Web services, in particular Web services as implemented in the IBM® SOA Programming Model and as supported by WebSphere Integration Developer.

Data modeling

The type of a service operation parameter should be either a primitive type or a <<message>> DataType. Modelers should make no assumptions about the location of the data, call-by-value or call-by-reference semantics, nor any implicit concurrency management facilities. Assume that service implementations are working on a transient copy of the data that may have been transferred, transformed, or both from its original source. This ensures minimal data coupling between service users and service providers.

Services modeling

As specified in the IBM Software Services profile, a service provider component must realize or use all interfaces through service ports, never directly. This ensures proper decoupling between service consumers and providers connected to the component.

Activity modeling

A concrete service provider models the methods for its service operations by providing a behavior for each operation.

Note:
A concrete service provider is a component that is not abstract nor a <<specification>> component.

Any behavior may be used, but if the model target platform is Web services, it is convenient to use an activity that can easily be translated to WebSphere-BPEL. The activity model shown in Figure 11 is an owned behavior of the Order Processor service provider component that is the method for the processPurchaseOrder operation. There are several things about this activity that require further explanation:

• The signature for a method behavior must match its specification operation.

• Input and output pins on the actions are ordered starting at the lower-right corner of the containing action, and they proceed clockwise around the action to the lower right side. This pin ordering corresponds to the order of the parameters of the called operation, with the target input pin being the first pin and the type of the operation (if any) being the last output pin corresponding to the return result. The target input pin represents the target object to which the action request is sent (for example, the classifier that owns the operation).

• The input and output pin types are not generally set, because these can be derived from the corresponding parameter.

• This activity does not use object flows to simplify the creation of the diagram. Instead, the names of the input and output pins on the actions are labeled by a parameter, variable, or structural feature in the context classifier (the class owning the activity) that is in scope. UML 2 supports either, and which one to use is a matter of preference.

• The activity parameter nodes (on the left and right edges of the activity) are not used. Instead, the parameters of the activity (which must correspond to the parameters of its specification operation) are referenced directly on input and output pins where needed. These activity parameter nodes would be used if object flows were used.

• The activity partitions are set to represent the service ports or parts of the component containing the activity. All invocations are made and all events are accepted through these parts. The partitions are not named in this case, because the represented property provides sufficient information to identify the partition.

• The target input pins of the call operation actions need not be set. As an alternative, the activity partition represents the service port where the calls in that partition are invoked. These are called <<instance>> partitions in UML 2 and have well-defined semantics. The target input pins could have been set too, but this would be redundant.

• The returnInformation pin of the Accept Call actions is handled the same as the target input pin of a call operation action. It is also the port represented by the activity partition, and it represents the interaction point through which the call will be accepted.

• Assignment expressions are shown with opaque actions, where the name of the action contains an assignment expression that references variables, parameters, and structural features in scope. The lvalue and rvalue in the assignment statement is separated by a := (colon plus equal sign).

• Guard expressions on object and control flows are Java or XPath Boolean expressions that reference variables, parameters, and structural features in the activity scope.
• The data on an object flow is referenced by the name of the flow.
• The type of the data on an object flow is determined by its source.

These conventions are used to simplify activity modeling, to simplify the activity diagrams, and to correspond better with the BPEL that will be generated from them.

Translating to Web services

Transformations require using a transformation configuration.

Configuring the transformation

You can create a transformation by selecting File > New > Other > Transform Configuration (Figure 12).

We'll be using a UML-to-SOA transformation for this example, as Figure 13 shows.

The configuration of most transformations consists of three basic parts:

1. Selecting the transformation source elements
2. Selecting (or creating and then selecting) the target elements
3. Configuring the transformation properties

The permissible source elements are defined by the particular transformation selected. Generally, it is best practice to transform only whole models, not individual parts of models. This ensures that the models, which represent individual versioned resources, are treated as compilation units with respect to model transformation. This simplifies model management and transformation dependency handling by ensuring that changes in resources in the workspace correspond to builder and transformation deltas that should be processed to ensure that derived artifacts are synchronized with their source elements. For example, you wouldn't think of selecting an individual method in a Java class and compiling just that method, and then inserting it into the byte codes for the rest of the class. This would be impossible to manage in a rapidly changing environment, and it would require you, rather than the builders and compilers, to know all of the dependencies that might need to be compiled as a result of the change.

In this example, the PurchaseOrderProcess model is the source, and we created a new, simple Eclipse project for the target. All of the translated model elements are placed in this project (Figure 14).

The transformation configuration parameters represent transformation options that are not generally appropriate for markings in the model. Typically, these control overall options rather than options that apply to a particular model element. The UML-to-SOA transformation has only a few transformation options, as Figure 15 shows.

Process UML elements without stereotypes set to True means that the IBM Software Services profile is actually optional. Data types, components, and activities are translated to the Web services solution without requiring the <<message>>, <<service>>, or <<serviceProvider>> stereotypes, or the stereotypes may be left off particular model elements that don't need their additional properties.

This completes the configuration of the transformation of the PurchaseOrderProcess model to a Web services solution that will be placed in the PurchaseOrderProcessWorkspace project.

Running the transformation

Executing the PurchaseOrderProcess2WebServices transformation is quite simple:

1. Select the PurchaseOrderProcess2WebServices.tc transformation configuration file that was created in the previous section.
2. From the pop-up menu, select Transform > UML-to-SOA.

The selected transformation in the transformation configuration is executed, thereby transforming the source model into the Web services artifacts and placing the results in the PurchaseOrderProcessWorkspace project.

Tip:
If the model changes, you will need to re-run this transformation.

The results of the transformation are shown in Figure 16 using the Modeling perspective in Project Explorer.

Examining the result

The UML-to-SOA transformation configuration requires a target project in which it places all of the derived artifacts. This project is a simple Eclipse project that contains either a WebSphere Integration Developer library or module projects, as described in the following subsections.

• The library projects contain the business objects, interfaces, and module exports that are shared by other projects.
• The module projects contain a module implementation for each service provider component in the UML services model.

You can import these projects into your WebSphere Integration Developer workspace. Alternatively, you can use the target project as a workspace that contains all of the projects generated for a set of UML-to-SOA transformations of related SOA models.

1. Simply start WebSphere Integration Developer and select the target folder as your workspace.
2. Then import all the projects in that folder into that workspace.

Tip:
You may find it helpful to turn off Automatic Build until after all of the projects have been imported, just to speed up the imports.

Model and libraries

Each model in the transformation configuration's selected source is translated to a WebSphere Integration Developer library with the same name as the model. This library contains an XSD element for each class and data type in the source models, and a WSDL definition for each UML interface. These libraries define the business objects and interfaces used by all the WebSphere modules generated from the components in the transformation configuration's selected source.

Figure 17 shows the imported generated library and module projects in WebSphere Integration Developer with the PurchaseOrderProcess expanded to show the generated business objects and interfaces. Notice that the folders and name space in WebSphere correspond directly to the package structure in the UML services model. This ensures consistent name space management and reuse support across the resources and tools.

Let's take a closer look at the business objects and interfaces and compare them with their UML source elements. Figure 18 uses the WebSphere Integration Developer Business Object editor opened on the PurchaseOrder business object to show the XSDs generated from the service data model shown in Figure 2. As you can see, the XSDs correspond very closely to their source <<message>> data types. Click the figure to see the generated source.

Each UML interface is transformed into a WSDL portType. The WSDL generated for the Invoicing interface in Figure 7 is shown in Figure 19. Click the figure to see the generated WSDL source. Again, the WSDL looks very similar to the UML interface.

Components and module assemblies

Each service provider component in the UML services model is transformed into a WebSphere Integration Developer module. There is no Web services standard yet for assembling service users (consumers) and providers. Therefore, WebSphere Integration Developer Version 6.0.2 uses a proprietary, early version of Service Component Architecture (SCA). Module assemblies are captured .component files that use Service Component Description Language (SCDL), an XML document language for SCA. Several companies are collaborating to develop a standard for SCA by a collaboration of companies. See the Open SOA Web site for further information.

The UML-to-SOA transformation creates WebSphere Integration Developer modules for each service provider component to maximize reuse. SCA modules cannot be assembled from other modules. However, they can import services from other modules and use them indirectly. Therefore, connections between service consumers and providers in UML are implemented as bindings between module imports and exports in WebSphere Integration Developer. For example, consider the Invoicer service provider shown in Figure 8.

Figure 20 shows the corresponding WebSphere Integration Developer module assembly. Module imports and exports are created for each service port. SCA cannot support both provided and required interfaces for the same interaction point, thus separate import and export elements are created for service ports that provide and require interfaces. The invoicingExport service exports the provided Invoicing interface; whereas, invoicingImport imports the required InvoiceProcessing interface of the invoicing service port of the Invoicer service provider.

Notice the module name. A module is an Eclipse project, but because a module is a reusable element, it must manage name collisions just like any other reusable element. The convention used by the UML-to-SOA transformation is to create module project names based on the fully qualified name of the service provider component, as determined by its containing package. This results in long module names that may cause some runtime problems on Windows platforms due to restrictions in the length of URLs. These module names can be easily refactored into shorter names as long as name conflicts are managed properly in the context in which they are reused.

The Productions component results in another module assembly, which is shown in Figure 21. This module has no import, because the service port doesn't require any interfaces.

Both of these modules use a BPEL process to actually implement the services provided by their corresponding service provider components. The details for how this is done are shown in the next section.

Take a look at Figure 22 to see the module assembly created for the OrderProcessor component previously, in Figure 10.

The OrderProcessor service provider provides the purchasing service, and has requisitions for invoicing, scheduling, and shipping services. The service channels that connect the consumer and provider components in Figure 10 are implemented as imports in the OrderProcessor module bound to the exports of the corresponding service providers. This allows effective module reuse in WebSphere Integration Developer and keeps the UML services models independent of the evolution of SCA. When SCA is standardized, the UML services models won't have to change; only the transformation will need to be updated.

Activities and BPEL processes

Each functional capability (operation) provided by a service provider must be implemented somehow. The implementations are either designed in UML by using method behavior for each operation or Accept Call actions in some other behavior. The latter method provides additional decoupling between users and providers by allowing the provider to determine when it is willing and able to respond to a request, rather than having to respond immediately when the operation is invoked by the service user.

WebSphere Integration Developer SCA takes a different approach. Each export must be wired to a component in the assembly that provides an implementation for the operations in that interface. Components in SCA each have implementation types:

• Human Task
• Java
• Process
• Rules Group
• State Machine.

The OrderProcessor service provider in Figure 10 and Figure 22 provides a single functional capability through its purchasing service to process a purchase order. The implementation of this operation was an activity in the UML service model. The UML-to-SOA transformation creates a BPEL process from that activity and uses it as the implementation of the exported operation.

Notice that the BPEL process in Figure 23 is very similar to the activity shown in Figure 11. The details for how the UML activity is transformed into a BPEL process can be found in the Help section of Rational Software Architect.

Decoupling interface and implementation

As described above, WebSphere Integration Developer SCA implements provided capabilities by wiring an export, which provides the interfaces to a component that implements the provided operations. Because a component has an implementation type, all of the operations provided by all interfaces of that export have to be implemented the same way. This couples the implementation type to all of the interfaces of an export. (An export can be wired to and implemented by only one component.) If the developer wants to change the implementation type of a particular operation (for instance, from a human task to an automated service implemented in Java), the interfaces must be refactored to allow different exports to be wired to different component implementation types. This, in turn, would require changes to all users of those interfaces. This coupling of interface design to implementation type could inhibit the very business agility that SOA solutions are intended to support.

UML does not have this specification and implementation coupling. Each provided operation can have a method behavior that is an activity, interaction, state machine, or opaque behavior (code). The modeler designs the implementation of each operation independently. This can result in situations (shown in Figure 4) where the same service provider component uses different behavior types for different operations provided through the same interface. We need some way to translate these service providers to Web services.

There is another factor to consider. In UML, components are instantiated, rather than the behaviors that they own. Therefore, instance identification and lifetime are the same for all behaviors in the same component. In addition, the component establishes a context or scope for all of its owned behaviors, thereby allowing those behaviors to share access to the components state (properties and ports). Thus, when translating to Web services, we must have something that manages this identity, lifetime, and shared state to be able to implement UML semantics. This is where Business Process Execution Language (BPEL) processes come in (see Resources for more about BPEL).

Rather than creating a separate SCA component that implements each behavior of the service provider in the module assembly, we create a single BPEL process that corresponds to the component itself. You'll notice that the name of the BPEL process in Figure 23 is OrderProcessor, the same as the OrderProcessor service provider, not processPurchaseOrder, the name of the provided operation.

Let's take a closer look at Figure 4 to see how the Productions component is translated to WebSphere Integration Developer Web services. Notice that the implementation design for requestProductionScheduling uses an Activity (with the details not shown), but sendShippingSchedule uses an OpaqueBehavior with the implementation provided in Java code. The module assembly for this service provider is shown in Figure 21, and the Productions Process component is shown in Figure 24.

A BPEL process is created for the Productions service provider component. The identity properties of the service provider are used to define the correlation for all Invoke, Receive, and Reply activities in this process. Each operation provided by the component is implemented by a fragment of this process. The process starts with a pick element that is used to dispatch each operation request. Then a scope is created for each operation to provide a place for variables defined in the UML behavior. The scope then contains the result of the translated behavior. If the behavior was a UML Activity, then the scope will contain the BPEL generated from that activity. If the behavior was an OpaqueBehavior with Java language, then the body of the behavior is copied into a Java snipped activity in the scope. If the behavior was an OpaqueBehavior with HTML or Java™Server Pages (JSP) language, then a Human Task activity is added to the scope.

This provides complete decoupling of the interfaces and their implementations. For example, if the modeler or developer decided to change a service operation implementation from a human task to an automated Java service, only the human task element in the scope for that operation would need to change. Clients would be unaware that the implementation had changed until they noticed that the service ran faster and they didn't have to do as much work.

It is commonly understood that this is somewhat complex and confusing, and is likely to change when SCA is standardized. But decoupling, separation of concerns, reuse, and agile solutions are fundamental to SOA, and getting them isn't always easy.

Completing the solution

The UML-to-SOA transformation does not generate complete solutions (yet). That's because the effort to put implementation detail in the models would be harder than putting it into the platform-specific artifacts by using editors created for that purpose. There are also some features of UML 2 Activities that are not yet translated to BPEL. These will be added in future releases. Details for what is supported in a particular release are available in Help in Rational Software Architect.

Typically, WebSphere Integration Developer will have to do some or all of the following development activities.

1. Add the Java code for opaque behaviors if it was not provided in the model. Even if Java code is provided in the body of the opaque behavior, it is prone to having errors, because Content Assist and Java compilation are not (yet) integrated with the modeling capabilities of Rational Software Architect.
   
2. Add correlation for business processes. Correlation specifies information needed to identify instances of a component, and it is not yet supported in the UML-to-SOA transformation. This will be supported in a future release.
   
3. Create a user interface (UI) for human tasks. The UML modeler may have included JSP or HTML in the body of an opaque behavior. But, like Java source code, this may be incomplete or incorrect. The integration developer will want to use the Human Task editor, Page Designer, portal, or other tools to create complete human tasks with the proper look and feel to complete the application UI.
   
4. Configure the monitor model. Currently, the UML-to-SOA transformation does not create any monitor information to evaluate business Key Performance Indicators (KPIs) that may have been modeled as constraints on services and service providers. The integration developer can use the Monitor Model Editor tool in WebSphere Integration Developer to configure what data should be collected for simulation updates and for business measures and metrics.

Series summary

This concludes the series on services modeling in Rational Software Architect using the IBM Software Services profile (see More in this series, upper-left). The first article, Modeling SOA: Part 1. Service identification, covered how to use business process models and services collaborations to specify the requirements contracts for how a set of services should be connected and choreographed to accomplish some objective. These service contracts are often used to specify what has to be accomplished to achieve business objectives. Then the service collaborations can be useful in identifying services that provide real business value.

Modeling SOA: Part 2. Service specification showed how to model the details of a service specification from the provider's perspective. A service specification defines information necessary for potential consumers to determine if a service is applicable for their problems, and if so, how to actually use it. A service specification also defines what providers of a service need to do to implement the service.

The next articles, Modeling SOA: Part 3. Service realization and Modeling SOA: Part 4. Service composition showed how to design and model components that provide or require services and how the service operations are implemented. They also described how service providers indicate the contracts that they fulfill to link the service providers back to the business goals, objectives, processes, and requirements.

This last article described how to implement the services on a Web services platform supported by IBM WebSphere Integration Developer by using the IBM UML-to-SOA transformation. WebSphere Integration Developer supports an SOA programming model that is consistent with the service identification, specification, and realization designs captured in Rational Software Architect. By using WebSphere Integration Developer, you can complete the services programming, and then generate a UI for the human tasks, run tests, and deploy your SOA solution.

Back to top

Download

Information about download methods

Resources

Learn

• Modeling SOA: Part 1. Service identification by Jim Amsden is the first in a series of five articles about developing software based on service-oriented architecture (SOA). (IBM® developerWorks®, October 2007).
  
  
• Modeling SOA: Part 2. Service specification by Jim Amsden is the second in the series. (IBM® developerWorks®, October 2007).
  
  
• Modeling SOA: Part 3. Service realization by Jim Amsden is the third in the series. (IBM® developerWorks®, October 2007).
  
  
• Modeling SOA: Part 4. Service composition by Jim Amsden is the fourth in the series. (IBM® developerWorks®, October 2007).
  
  
• Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA by Ali Arsanjani is about the IBM Global Business Services' Service Oriented Modeling and Architecture (SOMA) method (IBM® developerWorks®, November 2004).
  
  
• IBM Business service modeling, a developerWorks article by Jim Amsden (December 2005), describes the relationship between business process modeling and service modeling to achieve the benefits of both.
  
  
• "Using model-driven development and pattern-based engineering to design SOA: Part 2. Patterns-based engineering," Part 2 of a planned 4-part IBM developerWorks tutorial series (2007).
  
  
• "Design SOA services with Rational Software Architect," a 4-part IBM developerWorks tutorial series (2006-2007).
  
  
• "Model service-oriented architecture with Rational Software Architect: Part 3. External system modeling ," Part 3 of a planned 6-part IBM developerWorks tutorial series (2007).
  
  
• Modeling service-oriented solutions is Simon Johnston's great article describing the approach to service modeling that drove the development of the UML Profile for Software Services and the RUP for SOA plug-in (developerWorks, July 2005).
  
  
• UML 2.0 Profile for Software Services, also by Simon Johnston (developerWorks, April 2005), describes the UML profile for software services, a profile for UML 2.0 that allows for the modeling of services, service-oriented architecture (SOA), and service-oriented solutions. The profile has been implemented in IBM Rational Software Architect.
  
  
• SOA programming model for implementing Web services, Part 1: Introduction to the IBM SOA programming model, by Donald Ferguson and Marcia Stockton (developerWorks, June 2005), describes the IBM programming model for Service-Oriented Architecture (SOA), which enables non-programmers to create and reuse IT assets. The model includes component types, wiring, templates, application adapters, uniform data representation, and an Enterprise Service Bus (ESB). This is the first in a series of articles about the IBM SOA programming model and what is required to select, develop, deploy, and recommend programming model elements.
  
  
• Service Data Objects simplify and unify the way applications access and manipulate data from heterogeneous data sources.
  
  
• See Business Process Execution Language for Web Services for more about the BPEL 1.1 specification.
  
  
• Subscribe to the developerWorks Rational zone newsletter. Keep up with developerWorks Rational content. Every other week, you'll receive updates on the latest technical resources and best practices for the Rational Software Delivery Platform.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download the Rational Unified Process plug-in for the SOMA method: IBM RUP for Service-Oriented Modeling and Architecture . You must have IBM Rational Method Composer to install this plug-in.
  
  
• Download RUP plug-in for SOA, Rational Unified Process plug-in for services modeling using the IBM Software Services Profile.
  
  
• IBM SOA Sandbox The IBM SOA Sandbox provides a mix of full-version software trials and "try online" hosted environments where you can explore tutorials and get architectural guidance.
  
  
• Download the trial version of IBM Rational Software Architect V7.
  
  
• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  
• Rational Software Architect, Data Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Software Architect.
  
  

About the author

Jim Amsden is an IBM Senior Technical Staff Member with over 20 years of experience in designing and developing applications and tools for the software development industry. He holds a Masters in Computer Science from Boston University. His interests include contract-based development, agent programming, business-driven development, J2EE UML, and service-oriented architectures. He is co-author of "Enterprise Java Programming with IBM WebSphere". His current focus is on finding ways to integrate tools to better support agile development processes.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Context of this article
• Service specification, provision, and use review
• Services modeling best practices
• Translating to Web services
• Model and libraries
• Components and module assemblies
• Activities and BPEL processes
• Series summary
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Rational Application Developer for WebSphere Software
• Demo: Build, test and deploy JAX-WS Web services
• Webcast: Webcast: Develop innovative applications efficiently using the right application foundation in today's economy
• Briefing: Software development conference
• Buy: Rational Application Developer for WebSphere Software

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers