Tool Mentor: Create and Configure Participants
Create Participants that realize provided services, identify and assign required services, and specify methods for provided operations.
Tool: Rational Software Architect
Relationships
Main Description

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.   

Review the model structure

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.

 

Identify and Create Needed Participants

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.

Create ServicePoints and type with ServiceInterfaces

For each ServiceInterface that a Participant provisions, create a ServicePoint and type it with the ServiceInterface:

  1. Select the Participant, either in Project Explorer or on a Free Form, Class, or Component diagram.
  2. Right-click and select the Add Service Modeling > ServicePoint menu item.
  3. Choose the pop-up option to Select Existing Element.
  4. Use the resulting dialog to select the ServiceInterface with which the ServicePoint is to be typed.

Identify composite services

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:

  1. Select the composite's Role, Property, or Partition under the Service Collaboration.
  2. 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.

Provision participants for composite services

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

  1. From the Rational Software Architect toolbar menu, select Search > Search... Model Search.
  2. Under Scope, de-select All Models and select the model that contains the composite's ServiceInterface.
  3. In the Configure Search Set dialog, provide a name for the Search Set.
  4. Under Search string, provide the name of the composite's ServiceInterface, and then select Search.
  5. 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.
  6. Select the element, right-click, and select Modeling References > Enclosing Model.
  7. 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:

  1. Select the Participant, either in Project Explorer or on a Free Form, Class, or Component diagram.
  2. Right-click and select the Add Service Modeling > RequestPoint menu item.
  3. Choose the pop-up option to Select Existing Element.
  4. Use the resulting dialog to select the ServiceInterface with which the RequestPoint is to be typed.

Model behaviors for provided service operations

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.

Create the Participant Overview diagram

  1. Open the Service Participant Free Form diagram that was precreated as part of the original Participant building block.
  2. Drag the Participant onto the diagram. 
  3. Select the Participant, right-click, and select Filters > Show External View.
  4. Drag the Participant's ownedBehaviors onto the diagram.
  5. 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. 

More Information