Guideline: Evolving the Service Model
This guideline describes how the Service Model can be evolved across the lifecycle of one or more projects. It provides emphasis as to when certain aspects of the Service Model need focus.
Relationships
Main Description

Concept: Service Model describes the overall purpose of the Service Model and describes, at a high level, its contents.  This Guideline gives advice as to how the Service Model can be evolved over time.

In summary from the Concept, the Service Model is used for the following;

  • Identifying candidate services and capture decisions about which services will actually be exposed
  • Specifying the contract between the service provider and the consumer of the services
  • Associating Services with the components needed to realize these services 

The Service Model often is a heterogeneous collection of physical assets, including UML models, documents and possibly entries in a requirements management tool. However, the service model has to contain the following logical elements:

  • Candidate Service and Service Portfolios
  • Candidate Service Hierarchy
  • Service Exposure
  • Service Dependencies
  • Service Composition & Flow
  • Service Non-Functional Requirements
  • Service Messages
  • State Management Decisions
  • Realization Decisions

Lifecycle of a Service Model

The service model can be evolved in the course of a single project.  More often, some portions -- particularly the Candidate Service and Service Portfolios and Hierarchies -- are evolved and/or maintained at a level above that of a single project.  These portions of the overall Service Model can be used as inputs to individual projects.

For the purposes of this Guideline, we will assume that a given project includes some services discovery activities that result in the definition of additional candidate services.

Identification Elements

A services design project generally begins by analyzing business-oriented inputs or existing assets to identify Capabilities that are useful for realizing a business process or a set of application requirements.  At the time of identification, each Capability becomes a candidate for service-enablement.  Candidate services identified at this stage are often only provided as a name and possible functional description. A simple document containing this list of candidate services often might suffice, however if the UML approach is used, then the portfolio is maintained as a collection of  SoaML Capabilities.

As soon as possible, candidate services in the list are organized into a Hierarchy using a functional classification scheme (typically based on functional areas identified using functional area analysis or a similar technique. Such a hierarchy demonstrates a primary classification scheme for services - that of a process invocation dependency and as such is valuable in understanding the relationships between services identified during decomposition activities. Again, the representation of the hierarchy can be either in a document, spreadsheet or UML model.

As has been mentioned, the Candidate Service Portfolio and the Service Portfolio can be maintained as organization-level assets which have lifespans beyond that of any specific project. Indeed there is a relationship between the enterprise and project portfolios as show in the figure below.

                                        

Specification Elements

Once candidate services are identified, exposure decisions must be made:

  • which services will be implemented and exposed for external discovery and use?
  • which services will be implemented but will not be exposed externally?
  • which services will not be implemented at this time? 

Service litmus testing is one approach for making these decisions.  In terms of the UML representation of the service model, SoaML ServiceInterfaces are created from the Capabilities that are selected for exposure.  The exposure decision can be marked by creating an <<Expose>> dependency from the ServiceInterface to the appropriate Capability. 

Specifying the ServiceInterfaces involves documenting their operations, the operation signatures, and any service contracts that providers and consumers of the service must adhere to.  Each ServiceInterface's provided and required operations can be determined using behavioral modeling techniques, such as sequence diagramming or activity modeling.  Any mandatory sequencing in these operations (the usage contracts) can be documented using either protocols that are directly owned by the ServiceInterface, or by SoaML ServiceContracts. 

Service Messages -- which define the structure of the service operation inputs and outputs -- must be described.  These messages can be derived from high-level models or can be directly expressed in some technology-specific form (such as XML Schema).

The service model includes SoaML Participants, which are the components of the system that offer the services for use.  A Participant provides one or more services via ServicePoints, and it consumes services via RequestPoints.  Each ServicePoint or RequestPoint is typed by an appropriate ServiceInterface.  A complete description of a Participant will include a set of owned behaviors (Interactions, Activities, etc.) that specify the realizations of the Participant's provided operations.  An owned behavior can use the capabilities that are provided by the services which the Participant consumes. 

It is well and good to define ServiceInterfaces and the Participants that provide and consume services, but realizing a business process often requires that instances of specific Participants collaborate with each other.  These Compositions and Flows are defined using:

  • "assembler" SoaML Participants to assemble the interacting instances, and
  • SoaML ServicesArchitectures to document the contract that the interacting instances must adhere to during their interaction. 

See Example: Participant (SoaML) and Example: ServicesArchitecture (SoaML) for more information on these two constructs.

Many of the above aspects of design focus more on satisfying functional requirements.  It is essential to also capture the Non-Functional Requirements for services and capture as much detail as possible on Quality of Service, Policy and so forth. In this area it is possible to express the requirements in a textual document, rather more difficult to express directly in UML, but might be more easily expressed using a requirements management product. One aspect of the non-functional solution architecture concerns the Distribution and Availability of services, which can be documented using the UML model.

While it is true that in an SOA we strive to make services stateless, it is not always possible or even preferable to make this a fixed goal.  The topic of State Management Decisions is provided to enable the designer time to reflect on the trade-offs, costs, and benefits of state management in services. In support of these decisions the topic Guideline: State Management for Services  provides examples of kinds of state that often do have to be maintained by a service.

Realization Elements

The realization of services concerns itself primarily with three areas, those being the decisions concerning the actual realization of services, the identification of subsystems and components to realize the service specifications, and finally the development of these components.

In documenting Realization Decisions it is important to have a reasoned and detailed rationale for the choice of sourcing and development approach.  Again, in a similar way to the Non-Functional Requirements above, it is often hard to express these decisions (certainly in detail) in the UML representation, and so we expect that the choices made for each service might be documented outside of a UML-based model.

More Information