Transformation to SOA
Part 1. From business process to service model architecture using IBM WebSphere Business Modeler and IBM Rational Software Architect
This content is part # of # in the series: Transformation to SOA
This content is part of the series:Transformation to SOA
Stay tuned for additional content in this series.
Overview of the Business Process Analysis model
A typical development cycle starts by capturing and analyzing business requirements and goals. Part of the analysis consists of identifying core services that are necessary to create service-oriented architecture (SOA) solutions to meet business requirements.
The task of analyzing business requirements typically falls to a business analyst, who usually uses IBM® WebSphere® Business Modeler to create a Business Analysis model (also called a Service Specification model), as well as to refine, extend, or optimize this model by using the built-in analysis and simulation functions of the WebSphere software. The end product of this analysis stage is a model that defines core services (business processes), how they interact, and how they are invoked by actors or other services.
You can find a detailed outline of service specification modeling in the "Modeling SOA: Service Specification" article from the "Modeling SOA" series by Jim Amsden (see Related topics).
Transforming a business process to high-level architecture
The next step in the cycle is to transition the Business Analysis model into a Design Solution Architecture model. This is a task typically performed by a software architect. The Business Process-to-Service Model transformation feature of IBM® Rational® Software Architect aids this transition.
You can use a WebSphere Business Analysis model project within the Rational Software Architect workbench that is configured with the WebSphere Business Modeler Integration feature. When you open it, the software creates an in-memory UML representation of the business model that you can use as the basis for modeling business operational requirements.
The Business Analysis model from WebSphere Business Modeler is converted into a UML representation by reflecting a role-based view of the business process. That is, you can look at a business process as a collaboration between the required roles for the tasks and the services involved in the process. You can view each required role as a UML interface that defines operations for each task and WebSphere Business Modeler service, for which it is responsible. Figure 1 shows a portion of a business process in WebSphere Business Modeler that describes how to handle customer orders in a business. In this view, the process shows swim lanes, with each representing a particular role that participates in the process.
A portion of a WebSphere Business Modeler process for Customer Order Handling
The UML representation of the business process includes a UML use case that represents each process, as well as Actors for each of the roles that participate in the use case. This representation shows the relationship between roles and processes at a high level of abstraction, which is suitable for getting an overview of a business process. Figure 2 shows the use case and Actors for the Customer Order Handling business process.
Figure 2. UML use case representation of the Customer Order Handling business process
Figure 3, which follows, shows the UML collaboration that represent the same process, along with its relationship to the UML interfaces that represents the required roles and the UML use case for the process. In the figures that follow, notice that the tasks that Figure 1 shows as requiring the CRMApplication role (Determine Requester Status, for example) have been translated into operations in the CRMApplication UML Interface (see Figure 3).
In addition to the use case and collaboration, the behavioral aspect of the business process (that is, how the roles interact with each other in performing their tasks) is represented as a UML Activity owned by the collaboration. Each task from the original business process is represented by a UML Call Operation action that invokes the appropriate operation, as defined in the role interfaces described previously. Flows between tasks, as well as the control nodes (decisions, forks, merges, and so forth) are also represented in the UML Activity. The collaboration shows which roles work together to define a process, and the Activity specifies how these roles interact with each other. The partitions within the activity represent the roles within the collaboration. This UML model provides what is, in essence, a specification that defines both structural and behavioral requirements that must be satisfied by any solution model that implements the business process.
Figure 3. UML collaboration for the Customer Order Handling business process showing relations to use case, interface, and Activity
See the business services modeling article in the Modeling SOA series by Jim Amsden, cited in Related topics, for a more thorough discussion of the relationship between elements of the WebSphere Business Modeler Business Analysis model and the UML counterpart.
Figure 4. UML representation of the WebSphere Business Modeler model in Rational Software Architect
The UML representation of the model in WebSphere Business Modeler is intended to be viewed as a requirements contract to be fulfilled by an architected solution model. The purpose of Business Process-to-Service Model SOA transformation feature in Rational Software Architect is to create an initial, or default, SOA solution model.
To create and configure this transformation, select Modeling > Transform > Create new configuration menu in the Modeling perspective (see Figure. 5). The transformation will accept a model open in WebSphere Business Modeler as a valid source and any Eclipse project as a valid target.
Figure 5. Creating a transformation from a business process to a service model
Figure 6 shows a single WebSphere Business Modeler model and a target, which can be any Eclipse project or folder where you want to put the output generated by the transformation.
Figure 6. Specifying the transformation source
The UML services model created by the transformation represents a service decomposition from the analysis model for each business process. You can configure the type of the decomposition from the transformation UI and apply it to an individual business process. The structure of decomposition depends on the target domain (implementation language, deployment environment, and so forth).
The decomposition for each service will be produced by an extension. Although the transformation comes with three extensions, it is not limited to these three (a high-level UML, a generic SCDL decomposition, and an empty implementation for Do Not Transform). The transformation is extendable and allows clients to create and add custom extensions. We will take a closer look at each default extension in detail later in this article.
After the model is generated by the transformation, system or software architects can further refine the service model by specifying more implementation details or creating references to other services or legacy libraries for reuse.
Contract verification in requirements traceback
Regardless of any specific decomposition, the architected solution model created by the transformation (also called a service model, or contract fulfillment model) preserves the contract information defined in the specification model. It also provides the implementation details required to fulfill the contract.
A business process in the specification model is represented by a UML Collaboration element. UML Collaboration elements from the specification model are transformed into UML Component elements in the architected solution model. The transformation populates the generated components with ports that specify interfaces for services required or provided by the business process.
In addition, the transformation generates a
element inside of each component. The CollaborationUse element maintains a
link between the original Collaboration element in the specification model
and the Component element in the service model. The transformation creates
UML bindings between component ports and collaboration roles. The port and
role bindings established through the CollaborationUse element define the
roles in the contract requirements that are played by parts in the
services software. This enables traceability between the solution and the
business requirements that it fulfills, as well as a means of verifying
that the solution actually meets the business requirements represented by
the WebSphere Business Modeler business model.
Consider the example in Figure 7, which depicts a contract verification for the Customer Order Handling business process and the associated service model.
Figure 7. Example of a composite structure diagram
The Customer Order Handling component that represents the service contains a CollaborationUse element with a Collaboration type that points back to the Customer Order Handling Collaboration element defined in the Business Analysis model created in WebSphere Business Modeler. The Customer Order Handling Collaboration roles are played by (or bound to) the component ports. Each port specifies interfaces provided or required by this business process, as outlined by the Business Analysis model. For example: The port that provides an interface to the service (myRole) is bound to the Collaboration role, which represents the business process itself. The other ports, which represent various actors (potentially, other services), are bound to their respective roles in the Collaboration element. These ports (for example, PaymentHandling, OrderVerification, CRMApplication, and so on) require interfaces to communicate with the pertinent Actors. Both required and provided interfaces are defined in the WebSphere Business Analysis model, and the services model in Rational Software Architect points back to those interfaces, as Table 1 shows.
Table 1. Transformation mapping
|Specification model element||Transformation output (UML high-level architectural model)|
|Model or package||The
transformation creates a UML model or package with the same
name, a containment structure for nested packages, and
collaborations. Nested packages or collaborations might also
contain UML activities. |
Interfaces, classes and data types, and activity elements are not transformed. When necessary, the generated model creates use relationships that correspond to these elements in the source model.
The generated model has the
transformation creates a UML component with the
The transformation creates a CollaborationUse element for each component.
The type of the CollaborationUse element is set to the collaboration element in the source model.
Each port in the generated component binds to a respective role in the collaboration through the CollaborationUse element. For details about the ports that the transformation creates, see the Collaboration role::type row that follows in this table.
|Collaboration role|| The
transformation creates a UML port on the component. The
generated port has the same name as the role in the source
Each port binds to a role by using a collaboration use relationship.
The type of the port is also set to that interface.
Electing process decomposition
The Business Process to Service Model transformation provides extensions for transforming business processes in a specification model.
The Default Implementation decomposition describes the behavior of the process by assigning a UML Activity as an owned behavior of the business process, as represented by UML Component (see Figure 8). This decomposition can later be used by the UML-to-SOA transformation to generate Services Component Definition Language (SCDL) modules with Business Process Execution Language (BPEL) artifacts.
Figure 8. Using the transformation configuration to specify the decomposition type for each business process
As Figure 9 shows, the default Implementation extension produces decomposition where behavior is described by an Activity element that is cloned from the business analysis model.
Figure 9. Default Implementation extension
The Do Not Transform option is offered in case you do not want to consider certain processes for transformation. This extension simply means "Ignore this process."
The Skeleton Only implementation transforms behavior into structure, creating a generic decomposition for Services Component Definition Language (see Figure 9). It produces an inner component for each Collaboration role in order to perform any preprocessing (such as obtaining proxies, for example) before making a call to the role's respective Actor (possibly another service). A model such as this can be used by the UML-to-SOA transformation to generate output, which can be deployed by the IBM® WebSphere® Integration Developer.
Figure 10. SCDL decomposition created by the Skeleton Only extension
To create UML service models that contain implementation details for other domains, clients can create and register custom extensions for the Business Process-to-Service Model transformation.
An example of creating customized decomposition will be presented in the next article in this series, "Transformation to SOA: Part 2. Creating a custom extension for the Business Process-to-Service Model transformation feature in IBM Rational Software Architect" (see More in this series above the table of contents here).
What Part 2 covers
This article focused on integrating WebSphere Business Modeler artifacts into the Rational Software Architect environment and the tooling provided to create a bridge between business models and software analysis and design models. Part 2 gives you a step-by-step example of how to create a custom process decomposition for transforming a business process to a service model. It is intended for readers who are familiar with authoring transformation extensions.
For additional useful information, read this series of five articles by Jim Amsden about developing software based on service-oriented architecture (SOA):
- Modeling SOA: Part 1. Service identification shows how to use UML models extended with the IBM Software Service Profile to design an SOA solution that is connected to business requirements, yet independent of the solution implementation. The author describes the business goals and objectives and the business processes implemented to meet those objectives, and then explains how to use the processes to identify business-relevant services necessary to fulfill the requirements that they represent.
- Modeling SOA: Part 2. Service specification. The author continues defining the SOA solution by modeling the specification of each service in detail. These specifications will define contracts between consumers and producers of the service. These contracts include the provided and required interfaces, the roles those interfaces play in the service specification, and the rules or protocol for how those roles interact.
- Modeling SOA: Part 3. Service realization. This third article explains how SOA-based Web services are actually implemented. The service realization starts with deciding what component will provide what services. That decision has important implications in service availability, distribution, security, transaction scopes, and coupling. After these decisions have been made, you can model how each service functional capability is implemented and how the required services are actually used. Then you can use the UML to SOA transformation feature included in IBM Rational Software Architect to create a Web services implementation that can be used in IBM WebSphere Integration Developer to implement, test, and deploy the completed solution.
- Modeling SOA: Part 4. Service composition. This fourth article covers how to assemble and connect the service providers modeled in "Part 3. Service realization" and choreograph their interactions to provide a complete solution to the business requirements. The resulting component will be a service participant that composes the services provided by the Invoicer, Productions, and Shipper components to provide a service capable of processing a purchase order. It also shows how this service participant fulfills the original business requirements.
- Modeling SOA: Part 5. Service implementation. In this final article in the series, the author describes 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.
- Visit the IBM Service- Oriented Architecture (SOA) Solutions area on IBM.com.
- Subscribe to a developerWorks newsletter.
- Download a trial version of IBM Rational Software Architect, Version 7.
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.