Artifact: Service Model

Main Description

The Service Model captures the details of a set of services over multiple iterations, progressively elaborating on the detail. The service model may be used for different levels of scope:

Service-scoped development where the scope of the project is to develop the service independently (as much as possible) from other services. The modeling would therefore encompass the use cases, architecture, design and implementation models as a vertical slice for the one service.
Project-scoped development where a project involves the specification of a number of services in support of a set of application requirements, in this case the scope is broadened to the application level and may involve a number of services. In effect there is a set of application level models for use cases and architecture and then a set of service specific design and implementation models.
Enterprise-scoped development, or service portfolio management, where the scope is only to capture the service specifications and logical partitioning but at an enterprise-wide scope. This allows designers and architects to make wide ranging decisions about the entire portfolio, yet separate projects are required to develop the design and implementation models for the identified services (and client applications).

The following diagram demonstrates the key aspects of the Service Model, abstractly, and the relationship between them and the Identification, Specification and Realization activities.

Identification Elements

The first elaboration begins with a list of candidate services in the Service Portfolio created during the Activity: Existing Asset Analysis, using techniques such as process decomposition (see Concept: Business Process Decomposition). These services are categorized according to their functional area and the technique used to identify them. It is key to note that the Service Portfolio we describe here is a project-specific portfolio and contains the candidate services identified using the different analysis techniques described in the Activity: Existing Asset Analysis. Services identified at this stage are often only provided as a name and possible functional description, A simple document containing this list of services may often suffice, however if the UML approach is used then the portfolio is maintained as a collection of Artifact: Service Specification and may be produced using Report: Service Portfolio.

As soon as possible services in the list are organized into a Hierarchy using a functional classification scheme (typically based on functional areas identified during domain decomposition). 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 (in which cases we would tend to use the Artifact: Service Partition to model functional areas).

Note that it is also possible that the term Service Portfolio represents the enterprise-wide service portoflio (as expressed in Concept: Service Portfolio) which has a lifecycle beyond that of the project-specific portfolio. Indeed there is a relationship between the enterprise and project portfolio as show in the figure below.

Specification Elements

One of the first steps within Activity: Perform Service Specification is to decide up on, and document, the Exposure of services - that is to document those candidate services that are to be developed and exposed as true services. One key technique is the Task: Apply Services Litmus Tests which provides specific guidance on how to evaluate services for exposure. In terms of the UML representation of the service model the Service Specifications that were developed during Identification are marked, using the status property, to exposed and then detailed further within the model. During analysis of services for exposure it is possible to start grouping services into logical offerings and this may be modeled in UML using the Artifact: Service Provider.

In documenting service specifications it is key to capture all Service Dependencies for various purposes - for example services with a high number of dependencies are harder to reuse in different environments, whereas services with many dependents indicate core capabilities. Service dependencies may be captured textually, often in a tabular form (see Report: Service Dependencies) or they may be modeled using the UML representation of the service model. It is also important to realize that some dependencies are due to inter-service communication and there are then specific details associated with this dependency (required communication protocols, security, etc) which can be documented using the UML model and specifically the Artifact: Service Channel in collaboration models.

In defining services it is common to recognize composite services that exist only to choreograph a set of more fine-grained services, this Composition and Flow should describe the relationship between the composite and composed services as well as the dependencies between services expressed by the flow across them. In the UML representation this composition can be well described (Composite Classes) as well as the flow (Activities, Interactions) and the techniques are described in Concept: Service Composition and Choreography.

It is key to also capture the Non-Functional Requirements for services (where many of the topics above focus more on the functional requirements) 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 may be more easily expressed using a requirements management product. When using the UML representation of the service model we recommend the use of both the existing RUP Artifact: Software Architecture Document and Artifact: Supplementary Specifications to capture non-functional requirements. One aspect of the non-functional solution architecture concerns the Distribution and Availablity of services which can be documented using the UML model and in particular the Artifact: Service Partition and Artifact: Service Gateway.

Obviously the detailing of Service Messages is key to the development of usable service specifications. These messages may be derived from high-level models or may be directly expressed in some technology-specific form (such as XML Schema). Whether the messages are described textually, in a schema language, or in the UML model these message definitions should be aware of key considerations that are documented in Task: Message Design and the corresponding Guideline: Message Attachments.

While it is true that in an SOA we strive to make services stateless it is not always possible or even preferrable to make this a fixed goal; the topic of State Management Decisions is provided to allow the designer time to reflect on the trade-offs, the cost and benefit 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 does have to be maintained by a service.

Realization Elements

The realization of services concerns itself primarily with three areas, 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 as described in Task: Document Service Realization Decisions. 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 to be documented separately.

Brief Outline

The service model is often a heterogenous 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 (see main description).

Service Portfolio
Service Hierarchy
Service Exposure
Service Dependencies
Service Composition & Flow
Service Non-Functional Requirements
Service Messages
State Management Decisions
Realization Decisions