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