Context
A number of service-oriented architectural elements (services, service consumers and service providers) have to interact and be assembled in order to provide a solution
to a specific problem
Problem
Only having the relatively low-level constructs of ServiceInterface and Participant to represent and understand your solution causes problems when the number of
projects and solutions increases. Some composition mechanism is required.
Forces
-
Describing and understanding reuse can be difficult without a context for using services, service consumers and
service providers. In other words, what is the answer to the question "Where have my service consumers and
providers been used?"
-
Validating specifications of service behavior against a set of requirements without a sensible
grouping for these specifications would be difficult.
-
Understanding (and therefore maintaining) the SOA software built to address a set of requirements without
some higher-level architectural specification artifact than service, service consumer, or service provider would be
difficult.
-
Not having a higher-level solution-size artifact to trace back to the business view means that this traceability is
more difficult to understand.
Solution
Use Service Oriented Solution (SO Solution) as a higher
level description mechanism for your service-oriented software.
Service-oriented solutions can be represented within a Service Model. This is the approach used in Template: Service Solution Design Model, and which is illustrated in Example: Sample SoaML Design Model.
In the template, we divide the information associated with a service-oriented solution into two parts.
-
To assist in more quickly analyzing the service-oriented solution -- to determine what services it might require
and to drive out the services' interaction patterns and operation signatures -- we provide a
<<perspective>> package for collecting analysis-level service collaborations for each service-oriented solution.
-
To more formally document the run-time structure of the service-oriented solution and the contracts by which its
Participant instances interact, we provide a <<perspective>> package for defining one or
more ServicesArchitectures that are associated with the service-oriented
solution. This package also can contain other information to support the ServicesArchitectures, such as
pointers back to structure diagrams for the Participants that are involved in the ServicesArchitectures.
Each ServicesArchitecture describes the run-time structure and collaborations of a community of Participants that
interact to provide some defined business value, such as the automation of a business process. See Example: ServicesArchitecture (SoaML) and Concept: Service Composition and Choreography for sample representations of
ServicesArchitectures. The sample SoaML design model contains a ServicesArchitecture, within the structural
context of a full SoaML design model.
We have now grouped our architectural specifications into:
-
Low-level, detailed descriptions of service providers and consumers (Participants) that are usable
as parts in service-oriented solutions. The definitions of the Participants generally will be distributed
throughout a service design model.
-
Service-oriented solutions that group ServicesArchitectures and supporting information, such as pointers back
to the structure diagrams for the involved Participants and analysis-level descriptions of service
collaborations.
Rationale
Composing service architectures by service-oriented solutions provides a way for creating an
architectural model that addresses a specific problem. We note the following:
-
We now have a manageable context for describing how our services, service consumers, and service providers are
used. This is provided by the ServicesArchitecture.
-
We have a way of grouping the analysis-level collaborations that makes it easier to manage them.
-
Traceability to the business view is simple. There is a service-oriented solution providing software to support the
automation requirements of a specific set of business issues.
|