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