Using models to design business processes and services

Assembling components with modeling tools

Get an overview of designing business processes and services, the roles and tools involved, and workflows that software architects can use. The author highlights advantages of assembling the participants and services in a business process or service and provides examples to demonstrate the effects that different models have on the tools used to generate deployable artifacts. She also explains techniques to use to achieve good results, even from incomplete models, and summarizes the SoaML modeling practices to use when assembling processes and services.


Tanya Wolff (, Software Quality Developer, IBM

Author1 photoTanya is a developer on the Rational Software Architect and Green Threads System Verification Test teams. She has been testing the Business-Driven Development green thread and product integrations by developing end-to-end scenarios from requirements to deployment in a collaborative environment, using IBM Rational and WebSphere tools.

13 December 2011

Also available in Chinese Russian Vietnamese

Choose your hats and shoes

As businesses grow and adapt to change from industry direction and technology advancement, business process architects must continually analyze and optimize current solutions. By devising new strategies to automate services or improve processes, while keeping track of the business vision and maximizing reuse, architects and developers reduce the distance from requirements to implementation, iteratively providing more efficient, traceable, flexible, and usable solutions that support business integration and agility. With the introduction of IBM® Business Process Manager Version 7.5 and new business-centric capabilities in IBM® Rational® Software Architect Version 8.0.4, software designers can adopt and integrate new hats and shoes into their tool kits.

Building a business solution begins by analyzing the current business processes and the IT services that support them. Then you determine which approach is best suited to embark on the path to achieving the business goals by choosing the service-oriented architecture or business process management approach -- or whether to reach for the SOA or BPM hat, to continue the metaphor, keeping in mind that both will be required during the architecture and development lifecycle. The person who wears the architect's hat has the knowledge of tool capabilities, best practices, and infrastructure in a business concern and can analyze the shortcomings and provide strategies to designing a solution. The developer has a choice of shoes -- technologies or tools -- to adhere to requirements, to bring the solution to deployment, and to maintain governance for the solution. Developers might need a good pair of hiking boots if they're in for a steep climb, their best dress shoes when they're ready to focus on the user interface, or their fastest running shoes if time to market is critical.

The overview diagram in Figure 1 shows the tools involved in both approaches, including modeling, implementation, simulation, deployment, and governance. You begin modeling the business process or service by using Rational Software Architect, analyzing and optimizing as required by using the Business Process Manager Process Designer, generating code stubs using Rational Software Architect transformation tools, and then continue implementation with the Business Process Manager Integration Designer. The deployment target of the completed process application or service is the Business Process Manager Process Server. Servers and applications can be stored in the Business Process Manager Process Center. Figure 1 illustrates this process.

Figure 1. Topology of business process design
Flow diagram

In the SOA approach, business motivation and goals drive solution design by defining needs and capabilities, which are candidates for services. Rational Software Architect is used to identify business goals as use cases, and to define strategies to achieve them in a services architecture, composed of participants that use and provide services. SOA enables the business to be more interoperable and distributive, yet with reusable parts, by separating interface from implementation, thereby improving adaptability.

To get started building an SOA solution using Rational Software Architect, create a UML model with a services design template, which comes with instructions for each step of the process.

BPM architects will first model the business process, identifying the resources and orchestration involved, to see where the process can be improved. The solution is refined by extracting the provided and required interfaces from these collaborations through transformation to a service model. From there, the structure of the solution is detailed in a package hierarchy of participants and services. BPM brings process model and execution closer together, driving more agile solutions and traceability from requirements to quality assurance.

To get started building a business process management (BPM) solution using Rational Software Architect, create a BPMN project with a process template, or if you prefer to design multiple collaborating processes, use a collaboration template. To start building your solution with IBM Business Process Manager Process Designer, create a new process application in the Process Center, and open it in Process Designer. You will need Business Process Manager Version 7.5.1 to export the Business Process Modeling Notation 2.0 (BPMN 2.0) model that will be imported into Rational Software Architect. (With Process Designer Version 7.5, you can import only a BPMN 2.0 model.)

When modeling, the two approaches are often intertwined. As such, a process can be viewed as a service, and vice versa. A process is composed of activities that reference services; each service can be detailed by an activity diagram or a process. Using the SOA approach, the architect might choose to use BPMN processes to describe the service contracts in the services architecture and to show how the participants use and provide the services specified in those contracts. The BPMN model that invokes the BPM approach might contain IT services. If so, the architect uses an SoaML model to elaborate the process' activities and service interfaces. Such an IT service might still require full or partial human participation.

Regardless of approach, where collaboration of participants is involved in the solution, both SOA and BPM approaches complete a design and begin assembling the process or service in the SOA Modeling Language (SoaML), as represented in the Rational Software Architect product depiction. The examples in this article refer to the Assemble participants task in the SoaML artifact.

Assembling a process or services solution

Being able to assemble participants in the modeling stage of business-driven development gives the designer more control over directing which of the various players can fill a role will be chosen for a particular implementation. Participants expose their offered services and express required service through ports. The ports are typed by service interfaces, which describe the available operations and their input and output parameters. Participants are assembled in a composite structure diagram of a separate participant, the composite or assembling participant. The internal structure of this participant collects instances of the collaborating participants as properties of the assembling participant.

In the composite structure, the ports on the participant instances are connected by service channels, which encapsulate the interactions between the participants. These instances and service channels direct the UML-to-SOA transformation tools in Rational Software Architect to create the implementation artifacts and set the binding information in the implementation of the assembled solution.

A different solution for another process or service under development might use either some or all of the same participants or new participants with different implementations that expose the same interfaces to accommodate different business needs.

Benefits of assembling with modeling tools

Assembling the participants using the modeling tools offered in Rational Software Architect 8.0.4 establishes the task as an essential step in the development of the process or service and is beneficial in several ways, as described in the following subtopics.


SOA and BPM architects can transform a complete services model to implementation artifacts and transfer them to the integration developers to continue the flow of the SOA development lifecycle. Prior to Rational Software Architect 8.0.4, the assembling participants task was performed by both roles; the architect could model the connections between the assembled participants, while the integration developer, after importing in Integration Designer, again connected the parts by specifying binding information on each import. This duplication of effort is erased with the transformation enhancements in Version 8.0.4.

Rational Software Architect now transforms assembled participants in a process or SOA to a set of Service Component Definition Language (SCDL) modules, which are wired together through Service Component Architecture (SCA) service and reference imports and exports, correctly setting the SCA wire targets and import bindings.


The assembled participant instances represent the roles in the collaboration or solution. Each component instance in the solution is accessed though ports, and their implementations are represented by behaviors in the component definition, thus fulfilling the specification of the business goals.

Use of the Rational Service-Oriented Modeling and Architecture (SOMA) process in modeling the solution refines the business goals toward implementation.

  • First, the services required to achieve the business goals are identified by using roles and collaborations.
  • Second, the services are specified by service interfaces and protocols.
  • Finally, they are realized into components, ports and service channels.

Each stage constitutes a further refinement from specification.

Where the business processes or requirements are specified by use cases and business models, the service identification is a refinement into roles and collaborations. These, in turn, are refined into service contracts and interfaces and roles, and then further into services and behaviors.

After all stages of refinement to complete the abstract definition of the services or behavior, the implementation stage begins with assemblingparticipants. This assembling task is what allows the architect to specify the communication channels between the participants and fulfill the roles in the collaboration. The exposed service on the assembling participant is easily traced back to the business requirement or system use case.


The ability to design the services model from service identification to assembling of participants addresses the designer's preferences in driving the solution from either an SOA or BPM perspective, or both. We can design a services architecture in UML to identify services or design a process in a BPMN model to illustrate the activities involved and identify candidate services. The assembling participant can be viewed as providing a service or process, according to the approach.

From an SOA perspective, use cases are realized by a participant providing a simple service interface or by an assembling participant containing instances of two or more collaborating participants.

From a BPM perspective, business processes can also be simple or collaborative. Simple ones are realized by a single participant representing a business or a department within a business, while the collaborating process involves multiple departments or business partners.


The deployment designer uses the advantages of both BPM and SOA when considering the components' target system. Although the simple service or process can be implemented by a Java Enterprise Edition (JEE) module or Business Process Execution Language (BPEL) process, the collaborative solutions or processes can integrate a mixture of implementations. Not only are these implementations interchangeable according to the developers' preferences, they are often imposed in the tools. A UML-to-SOA transformation will generate a BPEL implementation for a participant exposing multiple services to route the service call to the appropriate service. The importance of the UML assembly is seen in how it integrates, distributes, and accommodates multiple players, services, and technologies in building cohesive solutions for the business.

How the transformation to SOA works

With Rational Software Architect 8.0.4, the ability to generate SCDL with correctly bound imports from an assembling participant in a SoaML model can be demonstrated with a few examples to show how the transformation algorithm works. Correct transformations result from inspecting service channels on the part of the assembling component that has been delegated the implementation of the provided service. An explanation of the algorithm at work is helpful in understanding some of the results.

When transforming the assembling participant, Rational Software Architect performs the transformation assembly algorithm shown in Listing 1.

Listing 1. Transformation assembly algorithm
1.  Given a composite participant, find the participant instances in the internal structure of 
    the composite that are delegated from its ports.
2.  For each instance delegate:
       a.  Create an SCA module with a SCDL component and an export
       b.  Find all of the participant instances connected by service channels to the instance.
       c.  For each instance,
             i.  Create an SCDL import in the current module and set the binding properties.
            ii.  Inspect the instance's type.
           iii.  If it has a composite structure, call the transform assembly  (recurse).
            iv.  Otherwise, create an SCA module with a component and an export.
Figure 2. Flowchart for transforming the assembling participant
Diagram of workflow

The algorithm recurses into each participant along the delegation tree, traversing connections, creating SCA modules. The recursion reaches its end when it encounters a simple participant without an internal structure; that is, it requires no more interfaces.


To illustrate the inner workings of the transformation and its limitations, examples with assemblies involving more than one participant, for a minimum of three participants, are required. This requires the assembling participant and at least two participants involved in a collaboration where the conversation occurs in a single service channel between them.

Screen captures show the model in Rational Software Architect before the transformation tools are applied and the generated SCA structure in Integration Designer after the transformation. In the case where the transformation produces strange results due to an incorrect assembly model, a choice of recovery techniques is presented to the Integration Designer user to be able to work with the given artifacts.

Three SoaML designs illustrate the successful outcomes of transforming assembled participants in IBM Integration Designer:

  • Simple demonstrates the simplest collaboration: two assembled participants, one delegated provided interface.
  • Nested demonstrates nested assembling participants. Each assembling participant has a delegated provided interface and two assembled participants.
  • Double demonstrates a solution with two provided interfaces. It could represent a business process with two entry points or, more likely, an SOA solution providing more than one service interface.

A fourth design shows the current limitation of the transformation to accommodate incomplete assemblies.

  • NoDelegate demonstrates the effect of assembling participants, but the assembling participant either does not provide a service or does not delegate to one of its parts. This design is incomplete and no warning from Rational Software Architect is forthcoming, so the architect gives the result to the developer. This example provides techniques for the developer to use in completing the model in the Integration Designer.

Other designs are certainly possible. For example, more complex conversations can contribute to more ports and service channels between participants in the same process, more abstraction and realization can be imagined to contribute to deeper levels of nesting, and, of course, more participants can exist, thus contributing more services or processes that the use case or business process design requires.

Simple collaboration of two participants

This model shows two participants; the first has a UML activity as its behavior that calls an operation in the second participant. SoaML guidelines emphasize minimizing coupling, so all connections are between ports. A delegate connection connects internal ports to a port of the same type on the assembling participant, whereas service channels connect request ports to service ports inside of the assembling participant's structure.

Figure 3. Assembling a simple collaboration
Diagram of the model

The UML-to-SOA transformation on this model produces SCA modules and a library. The com.simple.Part1.Participant and com.simple.Part2.Participant modules each have a component and export. The first module also contains a BPEL implementation of the behavior of the component and an import to reference the required services on the second module. The import has binding properties with module and export names pointing to the export on the second module (the import in com.simple.part1.Participant is bound to com.simple.part2.Participant's export).

Figure 4. SCA components of a simple collaboration
SCA module diagram with import properties

Nested participants

This UML model shows three participants: the first requests the second which requests the third. There are two assemblies in the UML model, A1 and A2. A2 is the nested assembly that contains the second and third participants.

Figure 5. Assembling nested participants
A1 composition model with nested A2

The output generated from the transformation demonstrates the recursion process in the algorithm. The modules correspond to Participant, Participant2, and Participant3. Although there are five participants in the UML model, only three SCA modules are generated by the transformation. The purpose of assembling participants is to specify the binding properties for the imports of the delegated modules as in the Integration Designer in Figure 6.

Figure 6. SCA components of nested assemblies
3 SCA modules and binding properties

Double delegation

This UML model shows two participants. Each provides an interface, and each requests the other. Here is where the architect sees the benefits of recognizing the synergy between BPM and SOA approaches. A BPM architect would design a process where the assembling participant's name reflects the process that the collaborating participants converse about. But in this example, the design follows the guidelines of good assembling practice in which a delegate connector is added to all provided interfaces within the assembly that are not otherwise connected. This resembles an SOA solution: providing a set of interfaces, rather than a single process. The designer wearing the SOA hat is smug, but the one in the BPM hat is getting nervous. Keep the BPM hat though, because it will make understanding the transformation easier.

Figure 7. Assembling multiple services
UML model composition with 2 delegations

Click to see larger image

Figure 7. Assembling multiple services

UML model composition with 2 delegations

After transforming the UML assembling participant, the resulting SCA contains an SCDL module for each participant in the composition. Each module contains an import bound to the other's export. This outcome might bewilder the SOA architect, because it still produces two modules, one for each process, which satisfies the BPM style.

Figure 8. SCA components of multiple services
2 SCA modules with SCA import bindings

These examples show processes and provided services at the interface level only. In theory, there could be several operations provided in each interface. However, a BPM -style solution should have only a single method in its interface representing the process, while in SOA, a participant can implement multiple methods, exposing them all in a single interface or in separate interfaces. If the SOA architect would rather see a single module in the generated SCA, then they would design a new participant that uses both of the participants, providing any number of services, and wrap all three in a fourth assembling participant. The two originally exposed interfaces would then be connected through service channels to the third participant.

Figure 9. Assembling components using multiple services
composition with 3 participant instances

The resulting SCA will have the original building blocks as in the initial Double Delegation example, plus the new module that imports both.

Figure 10. SCA components using multiple services
3 SCA modules and import binding properties

Click to see larger image

Figure 10. SCA components using multiple services

3 SCA modules and import binding properties

Assembly with no delegate

The UML model assembles the participants in the simple scenario, but it does not delegate.

According to the guidelines in the service modeling template instructions, the assembling participant should create a delegate connector to all provided interfaces that are not otherwise connected to a request port. This example shows what happens if we do not complete the model.

Figure 11. Assembling without delegating
UML composition with no delegate connector

The transformation generates the building block modules for each participant in the assembly, as well as a separate assembling module, but does not generate correct imports in the assembling module. The resulting component implementations are in the assembly rather than in their own modules, so this workflow should be avoided. It is best to leave the components disconnected. Do not wrap them in an assembly until you are ready to delegate the service to a particular implementation.

Figure 12. SCA components not exported
SCA modules for all UML participants


If you do not have access to the original model to add the delegation or remove the assembling participant, there are different approaches you can take to correct the module in Integration Designer.

Currently, in Rational Software Architect 8.0.4, you will see three modules generated:

  • com.noDelegate.Part1.Assembly
    Contains two components and one export. There is no wire to the export because there was no delegation in the UML model. One of the components has a BPEL implementation in its SCDL representation, pointing to the com/noDelegate/Part1/Participant.bpelfile,which doesn't exist in this module. The SCDL for the component contains this code:
<implementation xsi:type="process:ProcessImplementation">
 <scdl:implementationQualifier xsi:type="scdl:Transaction" value="global"/>
 <process bpel="com/noDelegate/Part1/Participant.bpel"/>
  • com.noDelegate.Part1.Participant

Contains a component with no implementation in its SCDL, an export with interface type com.noDelegate.Part1.ServiceInterface, and an import with interface type com.noDelegate.Part2.ServiceInterface2. But the binding doesn't specify a target module/export. There is a BPEL file in the com/noDelegate/Part1 directory.

  • com.noDelegate.Part2.Participant
    Contains a component and an export.

The transformation creates the set of building block modules as expected, but it also generates a module for the assembling participant. This module attempts to assemble the actual building blocks, rather than importing references to them. This causes the implementations for the components to end up in the wrong place.

You must decide whether you want to hide the building blocks in the assembling module, by choosing the com.noDelegate.Part1.Assemblymodule to work on, or to preserve the building blocks by working on the com.noDelegate.Part1.Participant and com.noDelegate.Part2.Participantmodules.

The method to assemble the components inside the module is the top-down method, similar to composing a substructure component in UML. Substructure composition contradicts module reuse guidelines, and it should be done only if the parts are never needed outside the composite, thus removing the need to create separately deployable components. To build the collaboration using a bottom-up method is to perform the steps that the transformation would have done if the model were properly created in UML. The building blocks remain intact and outside of the assembling module being built.

Perform the steps according to your chosen method to complete the collaboration in ID.

Top-down workaround

An assembly module composed of internal connected components.

  1. Move the BPEL from the com.noDelegate.Part1.Participant module into the com.noDelegate.Part1.Assembly. You can copy the complete folder hierarchy from the Navigator view. Ensure that the ParticipantArtifacts.wsdl file gets copied as well and into the same folder as the BPEL.
  2. Clean and rebuild the com.noDelegate.Part1.Assembly module. Ensure that the BPEL is correctly located by double-clicking on the component in the assembly diagram. This action should open the BPEL diagram.
  3. Fix the new errors in the component properties as the error markers suggest. The screen capture in Figure 13 shows the correct properties for the interface and reference.
Figure 13. Interface properties in corrected component
Assembly diagram with interface properties
Figure 14. Reference properties in corrected component
Diagram with reference properties, corrected
  1. Wire the export to the interface being provided.
  2. Delete these modules:
    • com.noDelegate.Part1.Participant
    • com.noDelegate.Part2.Participant

Bottom-up workaround

Keep the building blocks – the collaborating participants -- outside of the assembly, and reference them using imports in the assembling module. In this example, the only building block is the required service implemented in com.noDelegate.Part2.Participant. The com.noDelegate.Part1.Participant is the module that imports the building block. The com.noDelegate.Part1.Assembly module is unnecessary.

  1. Copy the implementation tag from the first module's component to the second module's component.
  2. Delete the first module, com.noDelegate.Part1.Assembly.
  3. Create a new module called com.noDelegate.Assembly with an SCA component and an SCA export wired to it.
  4. Add the binding information to the import in the second module, com.noDelegate.Part1.Participant. The result will look like Figure 4, SCA components of a simple collaboration, in the first example.

The composite module SCDL is now complete. You can continue implementing the building blocks or contained components that compose the assembly. When the implementation is complete, you can make it deployable as a web service by generating a web service binding on the export and deploying the module to a process server.

SoaML modeling guidelines

Maximize reuse and minimize coupling when assembling participants by following the best practices guided by Jim Amsden's "Modeling with SoaML, Part 4. Service Composition" (see Resources for a link to this five-part series):

  • Assemble participants using references to the assembled participants by dragging the participants onto the composite structure diagram to create participant instances.
  • Model participants' capabilities and needs through service and request ports instead of direct relationships from participant to service interfaces
  • In the assembling participant's internal structure, use service channels between service and request ports of participant instances to finalize the realization of the service or process that the assembling participant represents.
  • Keep participant definition and assembly modeling as separate concerns. Component definitions are at the class level, while assembling is at the instance level.
  • Use a participant for the assembling participant, instead of a subsystem which restricts reuse of the contained participants
  • The assembling participant must have at least one delegation connector from an exposed service to an internal participant instance's port. All ports in the composite structure diagram not otherwise connected should be delegated to ports on the assembling participant.


Modeling a service-oriented architecture simplifies development of a process or service solution where a business process can be improved or implemented. Assembling the processes and services involved in the business solution is an architect's task, to be performed in Rational Software Architect. Prior to Rational Software Architect 8.0.4, the architect was advised to skip this assembling step when modeling in SoaML (see IBM BPM integration issues in modeling and transformations of business processes and services architecture) and give the task to the developer to complete the connections between the participants after the generated artifacts were imported into ID.

Starting with Rational Software Architect 8.0.4, it is more efficient to connect the components in the modeling stage of process development. It provides more flexibility of design by providing tools for both the BPM and SOA architects to use. The products are more usable by offering smoother integrations to architects and developers, maintaining traceability for design decisions throughout the service modeling evolution and implementation.

This article used simple models to demonstrate how the UML-to-SOA transformation generates SCA modules, components, imports and exports, and sets the import binding properties on the imports generated from required interfaces. Techniques were given to complete the assembly of the SCA in Integration Designer where the SCDL implementations and import properties could not be found. A set of best practices for assembling participants using SoaML was collected from developerWorks articles.



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. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. 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, DevOps
ArticleTitle=Using models to design business processes and services