Task: Specify Service-Oriented Solutions
Define and specify the services and structure of one or more service-oriented solutions.
Disciplines: Service
Purpose

To create a fully-specified service model that, when realized, will meet the functional and non-functional needs of the business.

Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory: Optional:
  • None
Outputs
    Process Usage
    Main Description

    This is the core task of service specification. Begin this task with:

    • A defined portfolio of services to be specified
    • Pertinent business processes
    • Descriptions of information models and more concrete data models
    • Representations of the functional requirements that the solution must realize, and the non-functional requirements that constrain it
    • Definitions of the service-oriented solution abstractions that you will use to organize some larger-scale views of your Service Model.

    When you exit the task, you will have accomplished the following:

    • Specified the external view of the services.  Their operations, operation signatures, and interaction protocols (ServiceContracts) have been defined
    • Discovered and described individual participants which provide and consume services
    • Documented the service messages and information objects that compose the service data model
    • Defined service composition and flows
    • Described the dependencies between services

    When you do these things, you have to keep iin mind the need to fulfill the required non-functional requirements, as well as the functional ones.

    The steps of this task are presented as a way to compartmentalize the various activities involved in detailing the service model.  They do not need to be performed sequentially.  Further, each step can be revisited as more information is learned.

    Tool Mentor: Build a SoaML Service Model Using the SoaML Template is an entry point into a family of tool mentors that collectively describe how to build a service model using the SoaML Template and Rational Software Architect for WebSphere Software.

    Steps
    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.

    More Information