Modeling SOA: Part 5. Service implementation

In previous four articles of this series (see "More in this series," upper-left), we used business analysis to identify business-relevant services ("Modeling SOA: Part 1. Service identification") that meet business goals and objectives. Then we specified services and use protocols ("Modeling SOA: Part 2. Service specification") necessary to meet IT objectives. Next, we provided design models for how the services are provided and used ("Modeling SOA: Part 3. Service realization," "Modeling SOA: Part 4. Service composition"). The result is a technology-neutral but complete design model of an architected services solution. In this final article in the series, we look at how to create an actual implementation that is consistent with the architectural and design decisions captured in the services model. We'll generate the platform-specific implementation by exploiting both model-driven development and the IBM® Rational® Software Architect UML-to-SOA transformation feature to create a Web service from the SOA model.

Jim Amsden (, Senior Technical Staff Member, IBM

Jim AmsdenJim 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.

30 October 2007

Also available in Chinese Russian Vietnamese

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.

Table 1. Development process roles, tasks, and tools
Business ExecutiveConvey business goals and objectivesIBM® Rational® RequisitePro®
Business AnalystAnalyze business requirementsIBM® WebSphere® Business Modeler
Software ArchitectDesign the architecture of the solutionIBM Rational Software Architect
Web Services DeveloperImplement the solutionIBM® Rational® Application Developer and IBM WebSphere Integration Developer

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 1. Service topology
Service topology

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.

Figure 2. Service data model
Service data model


Figure 3 shows the complete Scheduling service specification.

Figure 3. The Scheduling service specification
The 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.

Figure 4. The Productions service provider
The Productions service provider

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.


Figure 5 shows the ShippingService service specification.

Figure 5. ShippingService service specification
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.

Figure 6. The Shipper service provider
The Shipper service provider

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.


Figure 7 shows the InvoicingService service specification.

Figure 7. The InvoicingService service specification
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.

Figure 8. Invoicer service implementations
Invoicer service implementations


Finally, Figure 9 shows the Purchasing service specification.

Figure 9. The Purchasing service specification
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 10. The OrderProcessor service provider
The OrderProcessor service provider

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

Figure 11. The processPurchaseOrder service operation implementation
The processPurchaseOrder service operation implementation

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.

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).

Figure 12. Creating a new transformation configuration
Creating a new transformation configuration

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

Figure 13. Selecting the UML-to-SOA transformation
Selecting the UML-to-SOA transformation

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).

Figure 14. Configuring the transformation sources and targets
Configuring the transformation sources and targets

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.

Figure 15. Configuring the transformation properties
Configuring the transformation properties

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 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.

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.

Figure 16. Transformation results
Transformation results

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.

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.

Figure 17. The ProcessPurchaseOrder library and its business objects and interfaces
The ProcessPurchaseOrder library and its business objects and interfaces

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.

Figure 18. The XSDs generated from the service data model
The XSDs generated from the service data model

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.

Figure 19. WSDL generated for the Invoicing interface
WSDL generated for the Invoicing 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.

Figure 20. Invoicer module assembly
Invoicer module assembly

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.

Figure 21. Productions module assembly
Productions module assembly

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.

Figure 22. OrderProcessor module assembly
OrderProcessor module assembly

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.

Figure 23. OrderProcessor process component implementation
OrderProcessor process component implementation

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.

Figure 24. The Productions service provider implementation
The Productions service provider implementation

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.


RSM sample modelRSM_sample_model.zip60KB



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

Zone=Rational, SOA and web services
ArticleTitle=Modeling SOA: Part 5. Service implementation