Tool Mentor: Create and Specify ServicesArchitectures
We construct ServicesArchitecture to demonstrate how Participants interact to realize the business processes and use cases that a service-oriented solution addresses.
Tool: Rational Software Architect
Relationships
Main Description

Overview

This tool mentor documents the steps to perform to create and describe a SoaML ServicesArchitecture in Rational Software Architect for WebSphere Software, Version 7.5.4 and later. The following steps are performed:

Model element creation techniques are described in Tool Mentor: Create SoaML Model Elements.  Those instructions are not repeated here. 

Review the model structure

The diagram that follows illustrates the portions of the service model structure that are used in this tool mentor. Notable aspects include these points:

  • ServicesArchitectures, their enclosing packages, and supporting model elements are created under the 5 - Services Architectures package of the service model.  
  • Each ServicesArchitecture includes instances of Participants and instances of ServiceContracts. It also can include an ownedBehavior that explicitly illustrates how the Participants interact to achieve the purpose of the ServicesArchitecture, as well as descriptive diagrams.
  • A ServicesArchitecture building block is provided to accelerate the creation of new ServicesArchitectures. 

 

Identify the necessary ServicesArchitectures

ServiceArchitectures formally document how communities of Participants interact to deliver some defined value, be it the realization of a business process, business sub-process, or use case. They also can be used to document Participant interactions that realize composite service operations.

Identify the following ServicesArchitectures for creation:

  • A ServicesArchitecture needs to be created to parallel each Service Collaboration that was created to help reason about the service interactions needed to realize each business process, business sub-process, or use case.
  • A ServicesArchitecture might be created for each composite service that was created in the service model. The realizations of these composites were documented during the creation and specification of Participants (See Tool Mentor: Create and Configure Participants). Documenting a composite by using a ServicesArchitecture has the advantage of positioning the documentation in a well-known and easy-to-find place within the model -- the "5 - Services Architectures" package structure.

Create a ServicesArchitecture

  1. For each ServiceArchitecture, identify its owning Service-Oriented Solution (SO Solution) package. These packages were created by using Tool Mentor: Identify Service-Oriented Solutions.
  2. Copy an instance of the ServicesArchitecture building block and paste it under the SO Solution package. 
  3. Use standard building block text find-and-replace procedures to rename the ServicesArchitecture. A ServicesArchitecture that documents a business process, subprocess, or use case needs to be named identically to the Service Collaboration that supports the same concept.

Add parts and CollaborationUses to a ServicesArchitecture

  1. Open the Composition (structure) diagram for the ServicesArchitecture. 
  2. From Project Explorer, drag into the diagram each Participant that interacts to deliver the ServicesArchitecture's value.  This will add Properties (parts) to the ServicesArchitecture.  These Properties represent instances of Participants.
  3. From Project Explorer, drag into the diagram each ServiceContract that governs the interaction between each group (generally a pair) of Participant instances that are involved in a service-based transaction.

Those instructions take you in the direction of defining a concrete ServicesArchitecture, in which you illustrate the responsibilities and interactions of instances of specific Participants. If you want to build a more conceptual ServicesArchitecture, manually create parts in the Composition diagram and leave them untyped.  These parts will then represent generic roles that are involved in the ServicesArchitecture. 

If you described your ServiceInterface contracts by using locally owned protocols rather than ServiceContracts (see Tool Mentor: Specify Service Interfaces), you can quickly create an adequate ServiceContract to add to the ServicesArchitecture:

  1. Select the 3 - Service Contracts package, right-click, and select Add Services Modeling > Service Contract.
  2. Give the resulting ServiceContract a name such as <ServiceInterface>Contract, where <ServiceInterface> represents the name of the ServiceInterface for which you are creating the ServiceContract
  3. Select the ServiceContract, right-click, and select Add UML > Role to add a role to the ServiceContract. If the ServiceContract is being created for a multi-interface ServiceInterface, create a role for each interface the ServiceInterface either realizes or uses. If the ServiceContract is being created for either a single-interface ServiceInterface or for a regular UML Interface, create two roles, each with different, meaningful names that are typed by that interface.
  4. If you are creating a ServiceContract for a multi-interface ServiceInterface, add a Free Form diagram to the ServiceInterface. Name the diagram <ServiceInterface>Contract Behavior Overview, where <ServiceInterface> represents the name of the ServiceInterface for which you are creating the ServiceContract.  Into this diagram, drag the Activity diagram or Sequence diagram that was originally created to document the locally-owned protocol. 

Complete the ServicesArchitecture Structure diagram

The Structure diagram currently includes parts and CollaborationUses. Bind the parts to the roles they play in each CollaborationUse. By doing this, you illustrate which roles are committed to interact in conformance to the protocol defined by the ServiceContract each CollaborationUse instantiates.

  1. From the Composite Structure drawing tool palette, select the Role Binding tool. 
  2. Draw a binding from a CollaborationUse to the port (ServicePoint or RequestPoint) on the part that you are binding. 
  3. Use the resulting dialog to select the CollaborationUse role to which you are binding the port. 

Do this until all CollaborationUse roles have been bound.

The final result is expected to appear similar to the second diagram in Concept: Service Composition and Choreography.

Document the ServicesArchitecture's behavior

As an optional check on the correctness of the construction of the ServicesArchitecture, manually construct an ownedBehavior (an Activity or an Interaction) for the ServicesArchitecture. The ServicesArchitecture's properties are the roles in the ownedBehavior. Use the combination of the ServicesArchitecture's ServicesContract behavioral specifications as the basis for constructing a unified behavioral model.

  1. Use one of the ownedBehaviors -- either the Activity or the Interaction -- that is created when the building block is instantiated.
  2. For Activity modeling, create partitions for each of the ServiceArchitecture's properties. Use the General tab of the Partition's Properties view to assign the Property as the type of the partition. Alternatively, drag the property from the Project Explorer and onto the partition's name.
  3. For Sequence diagram modeling, drag the properties onto the diagram to create the Lifelines.
  4. Model the behavior, using the behaviors that previously have been defined for the individual ServiceContracts to guide your understanding of how the roles interact. Follow the guidance in  "Modeling user workflow by using activity diagrams" if you are modeling behavior using Activities. Use  "Modeling the interactions between objects in UML" if you are using interactions.

The ServiceArchitecture's behavior is expected to be a recognizable service-based realization of the business process, sub-process, or use case the ServiceArchitecture was mapped to.  If this ServiceArchitecture was created to document a composite service, the ServiceArchitecture behavior is expected to closely conform to any ownedBehavior that was described for the composite service's Participant.

Construct the ServicesArchitecture's Overview diagram

  1. Drag the ServicesArchitecture, itself, onto its Overview diagram. 
  2. Select the ServicesArchitecture, right-click, and select Filters > Show/Hide Compartment > Structure Compartment.
  3. Drag the ServicesArchitecture ownedBehavior onto the diagram. Use Filters to show only the Name compartment.
  4. Drag the ownedBehavior's Activity or Sequence diagram onto the Overview diagram.  
More Information