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 to be taken in Project Explorer to the ServiceInterface.
- 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. |