Tool Mentor: Build a SoaML Service Model Using the SoaML Template
This introduces our family of tool mentors that collectively describe how to build a SoaML-based services model using Rational Software Architect for WebSphere Software, Version 7.5.4 or greater. For the most part, the following text provides a high-level narrative of the Rational SOMA 2.9 service design process. Each tool mentor is introduced in the flow of the narrative, at the point in the process which it supports.

Tool: Rational Software Architect
Relationships
Main Description

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.

Create SoaML Model Elements

SoaML model elements can be created in several ways.  Five different approaches for creating such elements are described in:

Describe a Business Process

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.

Identify Candidate Services

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.
 

Create Service Interfaces

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:

Identify Service-Oriented Solutions

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:

Specify Service-Oriented Solutions

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:

  1. Specify protocols that service consumers and providers must adhere to as they interact during service delivery;
  2. Define the service data model; and
  3. 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:

  1. Create individual Participants;;
  2. Configure them with ServicePoints and provided services; 
  3. Identify and describe composite services
  4. Configure a composite service's Participant with the referenced services that are used to realize the composite's behavior; and
  5. 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.

Generate SOA Artifacts from Service Models

RSA can leverage a services model to generate a robust set of SOA-related artifacts, including XSDs, WSDLs, BPELSCA 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.

More Information