Overview
Along with ServiceInterfaces, Participants (the collective term for service providers and service consumers) are one of the central structural elements of a service model. In this tool mentor, you do these tasks:
Model element creation techniques are described in Tool Mentor: Create SoaML Model Elements. Those instructions are not repeated
here.
The provided instructions apply for Rational Software Architect for WebSphere Software, Version 7.5.4 or
later.
The diagram that follows illustrates the portions of the service model structure that are used in this tool
mentor. These are among the notable aspects:
-
Participants and supporting model elements are packaged within the implementation packages portion of the service
model (the portion that commonly is rooted in "com," "org," etc.).
-
A building block is available for quickly creating a Participant, its enclosing package, and its supporting model
elements.
-
The building block comes with a fairly rich set of supporting elements, including provision for defining a
privately-owned ServiceInterface and creating privately-owned service data model definitions.
Begin by creating a Participant to provision each ServiceInterface. If you have decided to represent "simple"
ServiceInterfaces (ones that offer only a single provided interface) as unstereotyped UML Interfaces, create a
Participant to provision each of these UML Interfaces, as well. Henceforth in this tool mentor, we use the term
"ServiceInterface" to refer to both ServiceInterfaces and to UML interfaces which play the ServiceInterface role.
Create the Participant by following these steps:
-
Select the <<serviceParticipantPackage>> building block, copy
it, and paste it into the appropriate location within the implementation package structure.
-
Use standard building block text find-and-replace procedures to name the package and its contents appropriately.
-
If you intend to retain the internal <<serviceSpecPackage>>, perform a second round of
find-and-replace to name that package, its contents, and the ServicePoint which is provided with the building
block.
-
Delete the <<serviceSpecPackage>> and the <<ServicePoint>> ${serviceSpec} elements if you will not be
using them.
-
Delete or retain the packages for the locally defined service data model, based upon whether you will be defining
and using shared data definitions or private definitions. Even if you intend to use shared definitions of
enumerators, messages, and parameter types, it often makes sense to retain the infotypes package to define any private data that is owned by the
Participant. See Pattern 08: Model Data Control Points for a discussion regarding why it
can be useful to define private information types. If you decide to create locally defined data element
definitions, refer to Tool Mentor: Specify Service Interfaces for instructions on data model
creation procedures.
A one-to-one mapping between Participants and ServiceInterfaces is not mandatory. See Concept: Considerations in Service Provider Selection.
For each ServiceInterface that a Participant provisions, create a ServicePoint and type it with the ServiceInterface:
-
Select the Participant, either in Project Explorer or on a Free Form, Class, or Component diagram.
-
Right-click and select the Add Service Modeling > ServicePoint menu item.
-
Choose the pop-up option to Select Existing Element.
-
Use the resulting dialog to select the ServiceInterface with which the ServicePoint is to be typed.
Examine the previous results from service collaboration work (Tool Mentor: Analyze Service Collaborations) to identify the Roles, Properties, or
Partitions that represent composite services. To do this, identify the Lifelines (for Sequence diagrams) and
the Partitions (for Activities), which both provide and consume exposed services. Examples:
-
Role2, in Example: ServiceInterfaces from a Complex Set of Role Interactions. Here, Role1
requests a service from Role2, and Role2 calls on Role3 and Role4 to implement that service. The operations of the
ServiceInterface that is the type for Role2 are realized by using the operations of the ServiceInterfaces that
type Role3 and Role4.
-
orderProcessor, in the Activity diagram in Example: Model Service Collaborations, is asked to provide a Process Purchase
Order service. It uses productions, shipper, and invoicer to realize this service. The operation of the
ServiceInterface that types orderProcessor is realized using the operations of the ServiceInterfaces that type
productions, shipper, and invoicer.
Ensure that at least one of the roles that is being asked to support the realization of the composite actually has been
selected to be an exposed service (by litmus testing). Otherwise, the role that appears to be "composite" is not.
Identify the ServiceInterface that types each Role, Property, or Partition that represents a composite:
-
Select the composite's Role, Property, or Partition under the Service Collaboration.
-
In the Properties View, select the General tab and identify the type to which the element has been
set.
Using similar procedures, identify each ServiceInterface which types each Role, Property, or Partition that helps
realize the composite.
For each ServiceInterface that is to be implemented as a composite, navigate to each Participant
that provides it. For each ServiceInterface that helps realize the composite, add a
RequestPoint to the Participant and type it with the ServiceInterface:
A. Identify Participants that provide the composite
-
From the Rational Software Architect toolbar menu, select Search > Search... Model Search.
-
Under Scope, de-select All Models and select the model that contains the composite's
ServiceInterface.
-
In the Configure Search Set dialog, provide a name for the Search Set.
-
Under Search string, provide the name of the composite's ServiceInterface, and then select Search.
-
From the Search results list, identify the Declaration of
the ServiceInterface. Double-click that list item.
You will be to be taken to the ServiceInterface in Project Explorer.
-
Select the element, right-click, and select Modeling References > Enclosing Model.
-
From the search list, identify the ports that reference the ServiceInterface. Select one of those entries to
be taken to the Participant that provides that composite.
B. Create RequestPoints and type them with ServiceInterfaces
For each ServiceInterface that helps realize the composite, create a RequestPoint on the Participant and type it
with the ServiceInterface:
-
Select the Participant, either in Project Explorer or on a Free Form, Class, or Component diagram.
-
Right-click and select the Add Service Modeling > RequestPoint menu item.
-
Choose the pop-up option to Select Existing Element.
-
Use the resulting dialog to select the ServiceInterface with which the RequestPoint is to be typed.
Model the implementation of each provided service operation using an ownedBehavior (an Activity or an Interaction). If
you want to later use the UML-to-SOA transformation tool in Rational Software Architect to generate BPEL (which reflects the SOA architect's design for the operation), use an Activity.
For each provided operation, follow these steps:
-
Create the ownedBehavior -- either an Activity or an Interaction -- under the Participant, so that it is directly
owned by the Participant. If you are using an Interaction, create a Sequence diagram under that.
-
Name the ownedBehavior the same as the operation.
-
For Activity modeling, create partitions for each of the RequestPoints that is involved in the realization. Use the
General tab of the Partition's Properties view to assign the RequestPoint as the type of the
Partition. Alternatively, drag the RequestPoint from the Project Explorer onto the Partition's name.
-
For Sequence diagram modeling, drag the ServicePoint and the RequestPoints onto the diagram to create the
Lifelines, with the ServicePoint being left-most. Initiate the Sequence diagram by drawing a message from the left
edge of the Sequence diagram's border to the ServicePoint's Lifeline. This creates a Gate at the diagram's edge;
the message extends from the Gate to the Lifeline. Assign the provided operation's name to the message.
-
Model the behavior, using the previous results of service collaboration modeling to guide your understanding of how
the operation needs to be realized. 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.
If you intend to generate BPEL from Activities, you must model with additional precision. See Tool Mentor: Configure and Run the UML-to-SOA Transform for a discussion of the
pertinent considerations.
See [JAM09c] for a detailed discussion of service operation behavior modeling.
-
Open the Service Participant Free Form diagram that was precreated as part of the original Participant building
block.
-
Drag the Participant onto the diagram.
-
Select the Participant, right-click, and select Filters > Show External View.
-
Drag the Participant's ownedBehaviors onto the diagram.
-
Drag onto the diagram each provided interface from a ServicePoint and each required interface from a
RequestPoint.
The result is expected to be similar to the first diagram in Example: Participant (SoaML).
In the last step above, you drag the provided interfaces from the ServicePoints, plus the required interfaces from the
RequestPoints. These collectively define the interfaces the Participant's Service Component will need to realize during component specification and service
realization. We don't show the RequestPoints' provided interfaces here for a reason. RequestPoints represent the use,
not the provision, of the ServiceInterfaces with which they are typed. Those ServiceInterfaces are expressed from the
perspective of the Participant that provides the service, which is the reverse of the perspective of the Participant
that uses the service. So, the underlying Service Component for the requesting Participant actually calls
(requires) the interfaces that are provided by RequestPoint ServiceInterfaces. Similarly, it provides the
interfaces that the RequestPoint ServiceInterface requires.
|