Model service collaborations
Create one or more UML collaborations for each business process and use case that you are addressing. In this
approach (see Example: Sample SoaML Design Model), you keyword these collaborations as Service
Collaboration . Build an activity or interaction model under each collaboration to develop an initial
understanding of how each business process or use case is to be realized. Information gained from this modeling
includes the following items:
-
The roles that are involved in the realization
-
The services (operations) those roles provide or request
-
The connection paths that must exist among the roles to support the behavior
Depending upon the maturity of your understanding of the solution, you can map the roles either to previously-defined
capabilities, to previously-defined ServiceInterfaces, or to a newly-discovered ServiceInterface.
See Example: Model Service Collaborations for further insights regarding this
step.
|
Create new service interfaces
It is likely that the previous service collaboration modeling discovered some collaboration roles that could not be
fulfilled by pre-existing capabilities, ServiceInterfaces, or UML interfaces. Create appropriate model
elements to fill these roles. Use Guideline: Identify Service Interfaces from Collaboration Role Interaction Patterns to guide your discovery efforts.
If you are early in the overall service design process -- perhaps you are still performing some service identification
tasks -- you can create capabilities to fulfill the roles. You also might create capabilities if your SOA
governance process requires that all new services go through service litmus testing before they are approved for exposure and subsequent
development.
If the previous assumptions and considerations are not valid, create either new ServiceInterfaces or UML
interfaces Create an interface only if you are certain that the model element will be involved only in simple
request-response interaction protocols with service consumers. If there is a possibility that a more complex
interaction protocol might be involved, such as that which is illustrated in Example: ServiceInterface (SoaML), then create a ServiceInterface.
If you are organizing your service model in line with the concepts presented in Example: Sample SoaML Design Model, create new interfaces and ServiceInterfaces in
the Implementation packages portion of the model.
|
Identify service operations
Map each message between two roles in a Service Collaborations Interaction diagram to an operation on an
interface. This interface could be either:
-
A simple UML interface that was discovered during the creation of new service interfaces, or
-
A provided or a required interface that is associated with a ServiceInterface.
Create a new operation if necessary.
If you used activities to describe your service collaborations, ensure that each of the activity actions is supported
by an operation.
|
Detail the service interfaces
The full specification of a ServiceInterface can be quite involved -- refer to the table in Concept: ServiceInterface (SoaML) to better understand the types of information
that might be called for. As a minimum, the ServiceInterface specification needs to include the following
information:
-
Fully-defined provided and required interfaces, including full operation signatures
-
Fully defined protocols that govern how service providers and service consumers interact during service delivery.
Do the following to accomplish these things:
-
Build out the service data model to define the information that will be transferred using service calls.
These externally-visible data elements can be messages or parameter types. Derive parameter types from either domain types or information types. Derive messages from either domain types, information
types, parameter types, or other messages. See pages 368 - 375 of Redbook: Building SOA Solutions Using the Rational SDP for an extended
example of doing this. Also see Example: Parameter Types Derived from Domain Types and Example: MessageType (SoaML).
-
Create elements of the service data model either for shared or private use. Consult Pattern 10: Keep Architectural Elements Decoupled and Pattern 11: Use Shared Messages and Parameter Types to help you make this
decision.
-
Complete the signatures of the previously-identified operations by adding appropriate parameters and return values,
typed using elements of the service data model.
-
Leverage the previous service collaborationwork to define the ServiceInterface interaction protocols. These
are expressed as collaborations that show how providers and consumers interact during the performance of a
service. If the interactions involve only a single provider and consumer, it normally is sufficient to create
a simple collaboration that is owned directly by the ServiceInterface, see Example: ServiceInterface (SoaML). If the interaction involves more than
two roles, create a formal ServiceContract.
|
Create service participants
Create the participants that will provide the previously-specified services. Consider
pertinent functional and non-functional requirements when making these decisions. Also keep architectural
constraints in mind. See Concept: Considerations in Service Provider Selection for guidance.
In this step, you are concerned only with services that are being provided. Create a ServicePoint on a participant for each service that it will provide. Type the
ServicePoint with an appropriate ServiceInterface or simple UML interface.
If you are using Template: Service Solution Design Model to build your service model, create the
participants in the implementation packages portion of the model, as is illustrated in Example: Sample SoaML Design Model.
|
Model data control points
For each participant that offers a service that exists to manage access to data, model the information types for which the participant is responsible. Refer to Pattern 08: Model Data Control Points and Example: Pattern 08: Model Data Control Points for guidance. Refer to
pages 381 - 383 of Redbook: Building SOA Solutions Using the Rational SDP for an extended example
of data control point modeling.
|
Identify and describe composite services
Some participants realize composite services. Leverage the earlier service collaboration work to identify these services and to configure the
participants that realize them.
-
For each previously-developed service collaboration, identify the roles that are both providers and
consumers. For purposes of this discussion, we will refer to these as composite roles. In Example: ServiceInterfaces from a Complex Set of Role Interactions,
role2 is
a composite role. It is a provider for role1 , and it is a consumer for role3 and for role4 .
-
Identify each participant that provides the ServiceInterface (or simple UML Interface) that was used previously to
type each composite role.
-
For each such participant, add a RequestPoint for each role that was a provider to the composite role.
These roles are identified from the Service Collaborations.
-
Type each RequestPoint with the ServiceInterface (or simple UML interface) that was used to type each such
provider.
The resulting participants will be configured similarly to the OrderProcessor participant in Concept: Participant (SoaML).
|
Describe run-time services assemblies
Model assemblies of participant instances that can realize the solution at run-time.
-
For each participant that provides a composite service, create a new participant to assemble an instance of the
providing participant and instances of the other participants that it uses.
-
In a structure diagram for the new assembling participant, connect the participant instances using ServiceChannels.
-
Provide the assembling participant with ServicePoints that are typed identically to the ServicePoints on the
composite service provider.
-
Link each pair of identically-typed ServicePoints with a ServiceChannel that delegates implementation from the
assembling participant to its internal composite service provider part
The result will be similar to the Manufacturer participant in Example: Participant (SoaML).
If desired, create a CollaborationUses for the related ServicesArchitecture, add it into the structure diagram for the
assembling participant, and bind the roles of the CollaborationUses to the parts in the structure diagram. This
resulting image concisely shows both the run-time structure of the solution and how the parts of the solution fulfill
the solution's behavioral contract.
Example: Manufacturer Structure Diagram with Services Architecture illustrates this latter rendering of the solution.
|
(Optional) Model service operation behaviors
Each provided service operation of each participant eventually will need to be implemented. It can be useful to
capture in the service model the architect/designer's intention with respect to operation implementation.
For each participant, create an ownedBehavior (such as an activity or interaction) for each provided service
operation. Use the ownedBehavior to document, to an appropriate level of detail, how the operation is to be
implemented.
Example: Participant (SoaML) presents a sample owned behavior for the
OrderProcessor participant. This ownedBehavior illustrates how the processPurchaseOrder provided operation is to
be realized by three interacting services.
|
(Optional) Create SoaML service architectures
For each business process or use case that was used as input to the service modeling effort, create a
ServicesArchitecture. This concisely documents the participants that realize each process or use case,
and the protocols they follow as they do so. See Guideline: Building a ServicesArchitecture for a discussion of the detailed
steps to follow to do this.
As is described in Concept: ServicesArchitecture (SoaML), the internal behavior of the participants
that are involved in a process- or use case level- ServicesArchitecture might themselves be described using
ServicesArchitectures. This is most likely to occur when a participant realizes a composite service. Create and detail additional ServicesArchitectures for such
participants. If you are using the described model structure (see Example: Sample SoaML Design Model), place each such ServicesArchitecture under the
same package as the participant whose internal structure it describes.
|
Document service dependencies
A UML or SoaML service model that is built in accordance with the other steps of this task will have substantial
model-based documentation regarding the dependencies between services. If the service model is being built to a
lesser degree of rigor, or if alternative representations (such as textual documents) are being used for the service
model, some supplementary documentation of service dependencies could be called for. Create that documentation to
capture the concerns discussed in Guideline: Documenting Service Dependencies.
Template: Service Model in Word can be used to capture the required dependency
information.
|
|