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 of the following:
-
A simple UML interface that was discovered during the creation of new service interfaces.
-
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:
|
Create service participants
Model data control points
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 Example: 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.
|
|