Work Product (Artifact): Service Model
The service model is a model of the core elements of a Service Oriented Architecture (SOA). The service model is used as an essential input to tasks in implementation and testing.

The service model is an abstraction of the IT services implemented within an enterprise and supporting the development of one or more service-oriented solutions. It is used to conceive and document the design of the software services. It is a comprehensive, composite work product encompassing all services, providers, specifications, partitions, messages, collaborations, and the relationships between them. It is needed to:

  • Identify candidate services and capture decisions about which services will actually be exposed
  • Specify the contract between the service provider and the consumer of the services
  • Associate Services with the components needed to realize these services
RolesResponsible: Modified By:
Input ToMandatory:
  • None
Optional: External:
  • None
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
Impact of not havingWithout this product it would be difficult to properly define services and specify the components needed to realize them.  This could lead to gaps in the service portfolio, proliferation of unnecessary services, inconsistencies in how services were exposed, and inconsistencies in the design of components needed to realize the services.
Reasons for not needingThis product is not needed if we do not need to externalize service descriptions at the edge of a significant organizational boundary (i.e. at the edge of a major line of business within an enterprise, or at the edge of the enterprise).
Representation Options

The Service Model is a large work product and is usually developed using a number of techniques; for example UML models are used to describe service elements, however the presentation of the work product may be a document containing diagrams from the UML model. The level to which any particular project relies on the UML models will depend on the skills and background of the staff involved and also the expectations of the project stakeholders. In general we recommend that as much of the model be developed as possible using the UML representation and be integrated with additional content (especially descriptive text) and presented in its final form as a document.

For the UML Representation see Template: Service Model in UML.

For the Documentation Representation see Template: Service Model in Word.

More Information