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.
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.
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.
- For each ServiceArchitecture, identify its owning Service-Oriented Solution
(SO Solution) package. These packages were created by using Tool Mentor: Identify Service-Oriented Solutions.
- Copy an instance of the ServicesArchitecture building block and paste
it under the SO Solution package.
- 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.
- Open the Composition (structure) diagram for the ServicesArchitecture.
- 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.
- 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:
- Select the 3 - Service Contracts package, right-click,
and select Add Services Modeling > Service Contract.
- 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
- 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.
- 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.
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.
- From the Composite Structure drawing tool palette, select the Role
Binding tool.
- Draw a binding from a CollaborationUse to the port (ServicePoint
or RequestPoint) on the part that you are binding.
- 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.
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.
- Use one of the ownedBehaviors -- either the Activity or the Interaction
-- that is created when the building block is instantiated.
- 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.
- For Sequence diagram modeling, drag the properties onto the diagram
to create the Lifelines.
- 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.
- Drag the ServicesArchitecture, itself, onto its Overview diagram.
- Select the ServicesArchitecture, right-click, and select Filters
> Show/Hide Compartment > Structure Compartment.
- Drag the ServicesArchitecture ownedBehavior onto the diagram. Use Filters
to show only the Name compartment.
- Drag the ownedBehavior's Activity or Sequence diagram onto the Overview
diagram.
|