This is the fourth article in a five-part series on how to use Rational's latest best-practices development process guidance and modeling tools to design and construct robust, flexible IT solutions based on service-oriented architectures. Rational SOMA 2.9 provides detailed best practices development process guidance for successful IT service solution design. Rational Software Architect provides industry-leading modeling tools that support the new SoaML services modeling standard from the Object Management Group (OMG).
In the first article we introduced Rational Software Architect and Rational SOMA 2.9 as a unified tool set and process guidance offering for accelerating service solution design and development results. The second article provided an overview of the process guidance content and features of Rational SOMA 2.9. The third article described the Rational Software Architect tools for building business process models using Business Process Modeling Notation (BPMN), and showed how to use them to build a simple example of a business process.
This article describes Rational Software Architect’s support for service solution design and how the capabilities can be used to build robust, enterprise-scale service models. The article also describes how Rational Software Architect enables organizations to deepen the alignment between business and IT. This is done by using business models, built using Rational Software Architect and other IBM tools, to drive service discovery and service solution development.
As has been described in Parts 1 and 2, Rational SOMA 2.9 is IBM's commercially-available method for service solution design. Briefly, the method provides best practices for identifying and specifying services and for making service realization decisions.
Service identification is where we first start to cross from the business domain into the IT domain. Business-oriented inputs can include, for example, business process models, business functional models, business goals, and business domain models. Service identification involves analyzing these and other inputs to discover and describe "candidate services" that represent capabilities that IT could potentially provide to automate the business. In SoaML, we represent a candidate service as a Capability (or, more precisely, a UML class with the SoaML «Capability» stereotype applied to it).
We begin service specification by evaluating the candidate services according to several criteria in order to prioritize them for further design and implementation. The set of prioritized service candidates serves as an input into other service specification activities.
Once the candidates-to-be-specified have been selected, we make architectural and interface design decisions to more formally and completely describe the services that are to be realized and implemented. This includes basic interface definitions in terms of the operations and their parameters and such, but also includes any other constraints or responsibilities that potential providers or consumers of the services must adhere to or fulfill. In SoaML, we represent a service specification primarily in terms of a Service Interface (a UML interface or class with the SoaML «ServiceInterface» stereotype applied to it). More complex service specifications might involve a Service Contract (a UML collaboration stereotyped as a SoaML «ServiceContract») to capture constraints or requirements above and beyond what can be appropriately expressed through interfaces alone.
As part of the service model, we specify conceptual components that provide and/or consume services as Participants (a UML component with the SoaML «Participant» stereotype applied to it). Services and Requests are represented using UML ports applied to Participants and marked with SoaML «Service» and «Request» stereotypes, respectively. Services and Requests are typed using either Service Interfaces or unstereotyped UML interfaces.
Making service realization decisions involves just that – deciding how the specified services will be realized using run-time components. Several modeling techniques, including using some aspects of SoaML, conventional UML-based component modeling, and technology-specific solution modeling, can be used to document these decisions.
Practitioners can substantially automate their SOMA-based SOA design work using the service modeling features in Rational Software Architect, which are based on the SoaML standard from OMG, and other Rational Software Architect capabilities:
- Rational Software Architect's SoaML features, their integration with the tool's BPMN-based business process modeling functionality, plus general-purpose UML modeling capabilities help automate the Rational SOMA service identification and specification activities;
- Rational Software Architect's support for SoaML, general-purpose UML modeling, domain-specific modeling of JEE and .NET solutions, and domain-specific modeling of deployment topologies can be used to help make and document service realization decisions.
Rational Software Architect supports service modeling by providing a SoaML profile (UML extension) and additional SoaML-specific tooling. SoaML support was added in Rational Software Architect 7.5.4 and has been enhanced in subsequent releases. This support is integrated with the BPMN-based business process modeling support that was the focus of Part 3.
In this section we will introduce service modeling and SoaML as we build a service model. We will use the business process model from the previous article as input into service identification. Then we will produce a service specification based on that.
The first step in service modeling in Rational Software Architect is to create a service model in a project. We will use the Model wizard to create a service model in the same project in which we created our business process model in the previous article. If you are not already in the Modeling perspective you should open it at this point by selecting "Open Perspective > Other..." from the "Window" menu. Then you can invoke the Model wizard by selecting "New > Model" (or "New > UML Model") from the "File" menu.
In the Model wizard (see Figure 1), we select the option to create a new model from a standard template, and press "Next".
Figure 1. The first page of the Model wizard
On the next page of the wizard (Figure 2), we select the "Services Modeling" category and then the "Blank Services Model" template. (Note that we do not select the Software Services Profile, which is deprecated.) We accept the default file name, "Services", ensure that the destination folder is set to the root directory of our project, and press "Finish".
For more rigorous service modeling than we are demonstrating in this article, we would have selected the "Service Design Model" template from the wizard. This is a pre-structured template that includes substantial internal advice regarding how to use it, as well as a rich collection of pre-defined model building blocks that can be used to create a consistently-structured service model. Rational SOMA 2.9 includes a comprehensive set of tool mentors that describe how to build a service solution model using this template.
Note: If the "Services Modeling" category is not listed, try selecting the "Show All Templates" checkbox just beneath the "Categories" list. If it is still not listed then you probably do not have the service modeling features of the Extension for SOA and WebSphere feature installed, in which case you will need to install that before proceeding.
Figure 2. The second page of the Model wizard
We end up in the model editor opened on the default diagram, "Main," in our new service model. It is empty to start with. The model itself, "Services.emx," is also opened, but we do not need to edit that so we close it. At this point the workbench looks like Figure 3.
Figure 3. Workbench with new service model
Let's take a quick look at each relevant section of the workbench.
The big empty space in the middle is of course our new (empty) service model opened in the model editor. That is where we will be doing most of our work as we do service modeling. The Properties view, just below (see Figure 4), shows the properties of the diagram itself at this point because nothing is currently selected. As usual, there are more properties than could be shown at once, so there are tabs along the left that let you select whatever category of properties you are interested in.
Figure 4. The Properties view for the new service model diagram
Along the right-hand side of the editor is the Palette. The contents are what we would normally get when editing a UML model, except for the addition of a Service drawer. The Service drawer is available whenever we are editing a service model. It provides most of the types of elements we will need to use while doing service modeling. Figure 5 provides an expanded view of the Service drawer so that you can see the full set of available elements.
Figure 5. The Service drawer of the Palette
We won't be using all of these elements in the service model we will build in this article, so here is a brief description of each. This will also give you a brief overview of the kinds of things you can describe using SoaML. We describe them here in a different order than they appear in the Palette in order to minimize having to mention items that we haven’t already described.
- A Capability is used to represent a candidate service, as we mentioned above. The Palette offers three ways to create one.
- The Capability tool simply creates a Capability that isn't initially related to any other modeling elements.
- If we are identifying services based on a BPMN business process model (as we will be doing here), it is convenient to select Capability from BPMN element. This lets us select a BPMN Process, Lane or Task, from which it will create a new Capability that is named after whatever we selected and already contains operations named after the contained or selected Tasks. It will also automatically create traceability links from the Capability back to the BPMN elements we choose.
- If we've described our business processes using UML Activity diagrams, it is convenient to select Capability from UML Activity. This lets us select a UML Activity, Partition or Action, from which it will create a new Capability that is named after the contained or selected Actions. It will also automatically create derivation links from the Capability back to the Activity elements we chose.
- A Service Interface is used to describe the interface to a
service in terms of the operations it provides and (optionally) operations that
consumers of the service must provide.
- We would use Service Interface (simple) in the case where the service provides operations but does not require its consumers to provide any. A simple Service Interface is based on a UML Interface.
- We would use Service Interface (collaborating) if the service will also require consumers of the service to provide one or more operations, perhaps to support asynchronous communication. A collaborating Service Interface is a UML Class. Like a simple Service Interface, it specifies the operations that the service will provide, but it might also specify that it uses other Interfaces in order to so, thereby specifying operations that consumers of the service will have to provide.
- We would use either Service Interface (simple) from BPMN element or Service Interface (collaborating) from BPMN element if we wanted to create a Service Interface based on a BPMN element, bypassing the creation of Capabilities. We don’t do that in this article.
- We would use Expose to create a SoaML Expose relationship from a Service Interface to the Capability (or Capabilities) that it represents in order to maintain traceability. As we will see later, Rational Software Architect provides tooling that can generate both a Service Interface and an Expose relationship for a selected Capability.
- A Service Contract is used to help specify a service for which Service Interfaces alone cannot capture some kinds of more complex constraints or responsibilities. A Service Contract typically contains parts, typed by Service Interfaces or UML Interfaces, that represent the roles played by potential participants in the service. The Service Contract might also include a UML behavior that describes how the roles interact. For example, a Service Contract could contain a UML Interaction whose Lifelines represent potential participants. Its message sequence could be defined to indicate the required (valid) ordering of operations.
- A SoaML Message Type (based on a UML Data Type, Class or Signal) or UML Data Type is used to specify service messages, which represent the data that are to be passed between service participants.
- A Participant represents a component that will provide or consume services (or both). If we are creating Participants directly from business process elements, it is convenient to use Participant from BPMN element.
- Agent is a generalization of Participant that can define "a classification of autonomous entities that can adapt to and interact with their environment" [SoaML specification, pg. 50]. See §7.1.2 of the SoaML Specification for more details. We do not use Agents in the examples in this article.
- A Participant provides or consumes a service via a Service or Request Port, respectively. A Service or Request Port is typed by a Service Interface or a simple UML Interface to indicate which service it participates in and how. A Participant can have an arbitrary number of Services and Requests.
- We can add a Provided Interface or Required Interface to a Service or Request Port. This adds an Interface to those provided or used by the Port's Service Interface (type).
- A Service Channel represents a connection between a Request and a Service Port over which service operations are to be invoked. Service Channels appear in UML composite structure diagrams, for example to illustrate how the elements of a set of services are connected at runtime.
- A Services Architecture is a stereotyped UML collaboration that describes how a set of Participants work together to collectively realize either a higher-level Participant or a process of some type, commonly a business process.
We are going to start service modeling by identifying some candidate services and representing them as SoaML Capabilities. In order to keep ourselves organized, we will want to create a package for this. We will use the Main diagram in our Services model as an overview of the packages we create, so we edit it and drag a new Package onto it (from the Class drawer of the Palette) and name our new Package "Candidate Services". This also creates a diagram in our new Package, which we rename from "Main" to "Candidate Services" for clarity as shown in Figure 6.
Figure 6. The new Candidate Services Package
To start identifying some candidate services, let's take another look at the business process model that we built in the previous article (Figure 7).
Figure 7. The business process model
Several service candidates are apparent. We first notice that we probably want a service for receiving an order based on the Order Received Start Event in the Order Processing Lane. So, in the Service Candidates diagram, we use the "Capability from BPMN element" tool in the Service drawer of the Palette to create one. In the Select Element dialog, we select the Order Processing Lane and set the traceability link options we want (Figure 8). We click "OK" and accept the default name, "Order Processing."
Figure 8. The Select Element dialog
We can confirm that the traceability link got created for us by selecting the Capability and choosing Navigate / To URL, bringing up the properties of the Order Processing Lane from which we can show it in the Project Explorer (Figure 9).
Figure 9. Following a traceability link
We want an operation to represent handling the event, so we add one to the Capability and name it Receive Order.
We can see that Order Processing will need to be able to invoke a request on each of the other three Lanes, so we'll create candidate services for each of them, each as an operation in its own Capability. Let's start with Production. We use "Create from BPMN element" again, but this time we select the Production Lane. This creates a new Capability for us named "Production" (as well as traceability linkage to the Production Lane), but it also automatically creates a Request Production operation within the Capability because the Production Lane contained a Task with that name. See Figure 10.
Figure 10. The Production Capability
We can go ahead and create Capabilities for the Finance and Shipping Lanes as well, ending up with what is shown in Figure 11.
Figure 11. The initial service candidates
Looking at the business process again, we decide that we want to make some changes to our initial service candidates.
- In Finance we see that Prepare Invoice is something that it will do internally so we don't need an operation for it, so we delete that operation. But we will need an operation for Shipping to invoke in order to provide Finance with the shipping price, so we add an operation, "Receive Shipping Price," to it.
- In Shipping, we delete the Price Shipping operation because it is internal.
- In Order Processing, we see that Finance and Shipping will need a way to provide the invoice and shipping schedule, so we create operations for those.
We then have something like what is shown in Figure 12.
Figure 12. The revised service candidates
We have skipped over an important part of service identification, which is to identify existing services that we might want to leverage. In this small example project we don't have any because we are essentially starting from scratch. In the real world, however, this is seldom the case.
We have now expressed the incoming business requirements (as represented by the business process model) as a set of candidate services. These candidate services represent IT capabilities which, when implemented, will meet the requirements and support the business process. The next step is to more concretely and precisely specify how the services will be exposed and how they can be used.
We are skipping the first step of service specification, in which we evaluate the candidate services according to a well-defined set of criteria which we then use to prioritize them and select those for subsequent specification, design and development. In this small example, we are essentially prioritizing all of them. In the real world, however, priority-based choices will need to be made.
To get started, we create a "Specifications" Package in our Services model (and rename the diagram accordingly). In our Main diagram we create a dependency relationship between the Specifications and Candidate Services Packages as a matter of good organizational form. See Figure 13.
Figure 13. The Specifications Package
Looking first at the Order Processing Capability, we realize that there are really two kinds of things going on here. The Receive Order operation is fundamentally different than the other two because the former is (conceptually, at least) going to be exposed to the outside world while the latter are used only internally by the business. We therefore decide to represent these as two separate interfaces.
First, we will create the externally exposed interface. Because it is useful to have the service candidates visible while creating our service specifications, we drag the Order Processing Capability from the Project Explorer onto our Specifications diagram. Now we can select it and invoke Add Services Modeling > Service Interface (simple) from its context menu. We'll name it External Order Processing. Notice that we also got a SoaML Expose relationship between the Service Interface and the Capability from which it was created. This provides traceability linkage in this phase. We only want the Receive Order operation in this Service Interface, so we delete the other two. We also rename the remaining operation so that it better reflects our IT naming standards. In the same way, we also create a Service Interface named Internal Order Processing that contains just the other two operations. See Figure 14.
Figure 14. Service Interfaces related to order processing
We've made the appearance of the Capability different here in order to make it clear that it's defined in a different package and is included in this diagram just for context.
The other three Capabilities are more straightforward because they are all used only internally. We create a single Service Interface for each, as shown in Figure 15.
Figure 15. All of the Service Interfaces
Note that one could make a case that the operations in, say, the Shipping Service Interface should be in separate interfaces because they will be needed by different participants. Order Processing needs requestShipping() but does not need scheduleShipping(), for example. Having the two operations in the same Service Interface means that we don’t have the flexibility to design separate providers for them. One could make a similar argument about the operations in Finance. In this example, for simplicity, we have chosen not to do this.
We know that our service operations are going to need to pass data around in order to do their jobs. Sometimes a business process model already contains some kind of data definitions, although typically just very high level business terms. In this case it did not, so we'll have to start from scratch.
First, we will define a Data package within the Specifications package in which we’ll create our data definitions (Figure 16).
Figure 16. The Data package
To start off, we can see that receiveOrder() will need something to represent an order that is received. We'll use a SoaML MessageType (Class) for this (from the Message Type stack in the Service drawer of the palette), naming it "Order". We can then add to it the attributes we know it will need (Figure 17).
Figure 17. The Order Message Type
Real, robust data analysis and modeling for services is a critical part of the process but is outside the scope of this article series. For completeness, however, let's say we've specified all of the data types required by these services as shown in Figure 18.
Figure 18. Data specification
Now that we have our data specified, we need to add parameters to the operations in our Service Interfaces that use them. When we're done, we have something like what is shown in Figure 19.
Figure 19. The completed Service Interfaces
Let's say that we want to specify that our service operations must be invoked in a particular order. One way to do this is to create a Service Contract that contains a UML Interaction with a Sequence Diagram that specifies the allowed ordering.
To create a Service Contract, we use the Service Contract item in the Service drawer of the palette. We'll name our new Service Contract "Ordering Contract". Then, we can select it in the Project Explorer, bring up its context menu and select Add Diagram > Sequence Diagram. We'll name the new Interaction and Sequence Diagram "Ordering Interaction" and "Ordering Sequence", respectively (Figure 20).
Figure 20. The Ordering Contract with an Interaction and a Sequence Diagram
We want to create a Lifeline for each Service Interface so that we can use them to show the order in which the operations are to be performed. An easy way to do this is to select the Service Interfaces in the Project Explorer and drag them onto our Sequence Diagram. A nice side-effect of this is that for each Service Interface it creates an attribute in our Ordering Contract that has the Service Interface as its type. Each Lifeline corresponds to (represents) one of the attributes.
With five Lifelines, the Sequence Diagram is pretty wide due to the widths of their headings. We can do a couple of things to bring it down to a more manageable size. First, we select all five Lifelines in the diagram and, in the Appearance tab of the Properties view, we select the "Decoration" radio button in the "Show Stereotype" group. This removes the stereotype name (“«ServiceInterface»”) which saves some width. Note that this merely affects the appearance of the Lifeline; it does not actually remove the applications of the stereotype. Another thing we can do is to delete each Lifeline's name. Since there is only one of each type, we do not need them to have names for us to be able to easily distinguish them from each other. After we delete their names we have something like Figure 21.
Figure 21. Lifelines in the Sequence Diagram
Now we can draw the events in the order we want to specify. To start with, an order is received by the External Order Processing role. To draw this, we place our cursor near the left-hand edge of the diagram, wait for the connector handle to appear, drag a line to the External Order Processing Lifeline, click on Asynchronous Message, then double-click on the receiveOrder() operation. Figure 22 shows the sequence.
Figure 22. Drawing a message event
We then draw the other message events in the desired order, using a Parallel Combined Fragment to show the possible parallelism, after which it should look about like Figure 23.
Figure 23. The completed Sequence Diagram
Putting this Interaction into the Service Contract means that any participant in the service must, in addition to implementing the operations specified by the Service Interface for its role, abide by the ordering specified by this Interaction. For example, a participant playing the Finance role must not invoke the receiveInvoice() operation on the Internal Order Processing participant until it has had its initiatePricing() and receiveShippingPrice() operations invoked.
At this point we have fully specified our service.
Now we are ready to make some decisions about how the services will be realized by deciding what the participants will be and how they will be connected to realize a functioning system. In SoaML, we use a Participant to model a component that will provide and/or consume one or more services. To start with, we'll create a Realization Package with a dependency on the Specification Package (Figure 24).
Figure 24. The Realization Package
First, we decide that we want to realize both the External Order Processing and Internal Order Processing services with the same Participant. In the Realization diagram, we use the Participant entry in the Service drawer of the palette to create a Participant, which we name "Order Processing". We then select it and, from its context menu, select Filters > Show External View. This will let us add and see its ports around on its borders. We then use the Service palette item to add a Service Port to it by dropping it somewhere on its border. You'll know you're in the correct "drop zone" when the Participant's border is highlighted. When we create the Service Port it asks us what we want the Port's type to be. We choose Select Existing Element and then select the External Order Processing Service Interface. Finally, we enter "ordering" to be the Port's name. Figure 25 shows the sequence and results.
Figure 25. Creating a Service Port
We decided that we want this Participant to also provide the Internal Order Processing service, so we add a second Service Port, naming it "internal". It also needs a Request Port for each of the other Service Interfaces is uses: Finance, Shipping and Production.
We'll create three more Participants as follows:
- The Finance Department Participant will have a Service Port whose type is the Finance Service Interface. It will also have Request Port whose type is Internal Order Processing because it needs to invoke one of its operations.
- The Production Department Participant will have a Service Port whose type is Production and a Request Port whose type is Shipping.
- The Shipping Department Participant will have a Shipping Service Port, a Finance Request Port, and an Internal Order Processing Request Port.
After we do this and tidy up a bit, the result will be similar to what is shown in Figure 26.
Figure 26. The Participants
We also want to show how these Participants will be interconnected at runtime in order to actually do their jobs. To do that, we add another Participant to our Realization Package by selecting the Package in the Project Explorer and selecting Add Services Modeling > Participant from its context menu. We'll name it "Ordering". Then we'll add a Composite Structure diagram to the Ordering Participant by selecting it and then selecting Add Diagram > Composite Structure Diagram from its context menu. We'll name the diagram "Ordering" as well.
First, we add a Service Port to it, setting its type to the External Order Processing Service Interface (Figure 27).
Figure 27. The Ordering structure with a Service Port
We can easily add parts to the structure (to represent the Participants) by simply dragging each Participant into the Ordering structure diagram from the Project Explorer. This will add a part for each Participant and set its type accordingly. See Figure 28.
Figure 28. The Ordering structure with its parts
Now we need to create Service Channels to show how the Participants' Ports are to be connected together. First, we'll connect the external ordering Port to the corresponding one on the order Processing part in the structure. To do that, we put our pointer next to the external Port, grab the outgoing connection handle, drop it on the ordering port of the order Processing part, and select Service Channel from the list of possible connections. Figure 29 shows the sequence.
Figure 29. Drawing a Service Channel
Now we'll make the other Service Channel connections that we need, rearranging the layout as we go, after which we'll have something like Figure 30. Note that we’ve hidden the «ServiceChannel» labels on the Service Channels in order to make the diagram a little less cluttered.
Figure 30. The completed Ordering structure
In this article we described the Rational Software Architect tools for building service models using SoaML. First, we briefly explained what service modeling for service identification and service specification is, who typically does it (and why), and how it fits into the overall process. Then we gave a brief overview of the service modeling elements that are supported by Rational Software Architect. Finally, we showed you how to use the service modeling tools to build a small service model that contains some candidate services, some service specifications, and a possible realization.
Part 5, the remaining article in this series, describes how service models built using Rational Software Architect can be used to accelerate the creation of valuable service solution artifacts. Specifically, it focuses on leveraging service models to create SCA-related content.
- BPMN (Business Process Modeling Notation) is a standard from the Object Management Group that specifies a notation for describing business processes.
- SoaML (Service Oriented Architecture Modeling Language) is a specification of the Object Management Group. SoaML defines a notation and a meta-model for describing and specifying service-oriented systems.
- Watch the two-part video series Business Process Modeling and SOA Design with Rational Software Architect 8.0 .
- Learn more about SOA and service
governance in Bobby Woolf's developerWorks article, Introduction to SOA governance.
- To learn more about IBM Global Business
Service's proprietary method for service design and development, read SOMA: A method for developing service-oriented solutions.
- IBM now delivers its commercial best practices content in the form of largely-separable, discretely-adoptable practices. Visit Welcome to IBM practices on
developerWorks to learn more about our Practices.
- One of the major sources of inspiration
for the detailed service design method in Rational SOMA is the IBM Redbook, "Building SOA Solutions Using the
Rational SDP". The latest update to the Redbook occurred in 2008,
thus the tooling it illustrates is dated. Nonetheless, this is a good
service design resource to have on your "book shelf".
- Rational SOMA 2.9 borrows much of its
approach to service modeling using SoaML from Jim Amsden's 5-part IBM
developerWorks series, "Modeling with SoaML, the Service-Oriented Architecture Modeling Language".
- Visit the OASIS Service Component Architecture (SCA) site to learn more about these open-industry specifications for creating service components using a wide range of implementation and run-time technologies.
Get products and technologies
Rational SOMA 2.9. This is
IBM's commercially-available best practices content for service solution design. The URL points to a pre-published evaluation version of Rational SOMA 2.9 and to a full version, which can be published using Rational Method Composer. Rational SOMA also is productized as a Process Advisor configuration that ships with variants of Rational Software Architect, Version 8.0 and higher, that include the service modeling tooling.
- Download a
trial version of Rational Software Architect for WebSphere Software. If you have a choice of versions, we recommend Version 8.0 or higher. To experience the enhanced service solution design capabilities of Rational Software Architect, you will need to use Version 7.5.4 or greater. If you download Version 7.5, then use IBM Installation Manager – which is installed along with Rational Software Architect – to upgrade to the current version of the product that is in the 7.5.x code stream.
Gary Johnston is a Senior Software Engineer and SOA Tools Architect in the Rational Software Architect development organization. For the past couple of years, Gary has been working to deliver and enhance support for SOA design and development in Rational Software Architect itself and to better integrate it with other SOA-related tools (both Rational and non-Rational).
Todd Dunnavant is a Principal Solution Architect in the Solution Delivery Assurance team of IBM’s Rational brand. He also is the primary author of the Rational SOMA best practices for service solution design. For the past 14 years, his professional passion has been enabling Rational and IBM clients to improve their ability to deliver business-relevant software and system solutions. His current focal areas of interest are service-oriented systems and collaborative architecture management.