Overview
This tool mentor provides the overall context for the Rational Software Architect for WebSphere
Software (henceforth, "RSA") tool mentors that pertain to building service models using RSA's SoaML-based Service Model template. The tool mentors largely are
presented in the order they would be needed to perform the IBM Rational SOMA 2.9 workflow using RSA.
This tool mentor begins by assuming a SoaML service model exists in the workspace. This can be created using the
procedures described in Tutorial:
Introduction to the Modeling perspective in RSA Help. The service model can be created using the Services
Design Model template, in the Services Modeling category in the New Model wizard.
The following steps are performed in this tool mentor:
Be aware that the SoaML Service Model template includes copious internal documentation regarding the structure of the
template and how to build a SoaML-based services model. The content in these tool mentors reinforces and
complements the template's internal documentation.
SoaML model elements can be created in several ways. Five different approaches for creating such elements are
described in:
Business process descriptions are one of the primary inputs to Service Identification. The following tool mentors describe three approaches
for surfacing business process content within RSA.
presents the procedures for describing business processes in RSA using BPMN2 notation.
describe how business process descriptions created using other IBM products can be used within RSA.
Candidate services -- represented using SoaML Capabilities -- are identified during Service Identification using
multiple techniques, which leverage several different input sources. We describe how to create UML
representations of the different types of source elements in:
Then, in
we describe how to create candidate services and trace them back to their source elements.
We transition from Service Identification and into Service Specification by deciding which candidate services will be
exposed and further developed as services. The procedures for creating SoaML ServiceInterfaces and tracing them back to their related candidate
services are described in:
We use the service-oriented solution concept to define larger-scale service model abstractions
that help us (1) strengthen traceability back to the business problems being addressed and (2) maintain conceptual
control of the service model as the volume of content in the model increases. We describe how to identify these
conceptual elements and create them in the service model in:
We lump into "Specify Service-Oriented Solutions" all the effort that takes us from an initial set of
ServiceInterfaces and service-oriented solutions to a completely specified service model. This involves several
modeling activities. These are described in a suite of tool mentors.
We begin by focusing on understanding individual service interfaces. In
we show how to use RSA to support the collaboration modeling that provides us with our initial definitions of
service operations and with insights that are used to support several later tasks. Then, in
we describe how to use RSA to:
-
Specify protocols that service consumers and providers must adhere to as they interact during service delivery;
-
Define the service data model; and
-
Complete service operation signatures by adding parameters and return types to the operations
At this point, we have completely specified the service interfaces. We then move to the realm of service providers, service consumers (collectively, SoaML Participants) and ServicesArchitectures, which are collaborations of Participants that realize the
solutions to the pertinent business problems.
addresses how to use RSA to:
-
Create individual Participants;;
-
Configure them with ServicePoints and provided services;
-
Identify and describe composite services;
-
Configure a composite service's Participant with the referenced services that are used to realize the composite's
behavior; and
-
Describe how the behavior of each provided service operation is realized.
We finish defining the service-oriented solutions using
These two tool mentors collectively describe how to use RSA to define the ServicesArchitecture collaborations that
realize our service-oriented solutions and to model the assembly of instances of specific Participants that will
provide our solutions at run-time.
RSA can leverage a services model to generate a robust set of SOA-related artifacts, including XSDs, WSDLs, BPEL, SCA component definitions, and skeleton Java implementations of SCA interfaces
and SCA components. We present procedures for generating these artifacts in:
Java-based service implementations -- including skeleton implementation of SCA components and interfaces -- can be
performed within RSA using the results of the above transformations. The transform artifacts also can be used to
provide the specifications for services that do not have Java implementations.
The results of the UML-to-SOA transform can be used as input to WebSphere Integration Developer for process
choreography. The integration engineer benefits significantly, because the BPEL generated from RSA already
includes "knowledge" of the specific services and service operations that need to be included in the
choreography. The integration engineer is not forced to design the IT solution himself, which is the case if the
initial BPEL with which he is provided was generated from a business process model that was created by a business
analyst.
|