Reference Model for Service Oriented Architecture 1.0
OASIS Standard,
12
October 2006
Document identifier:
soa-rm
Location:
http://docs.oasis-open.org/soa-rm/v1.0/
Editors:
C. Matthew MacKenzie, Adobe Systems Incorporated,
mattm@adobe.com
Ken Laskey, MITRE Corporation, klaskey@mitre.org
Francis McCabe, Fujitsu Laboratories of America
Limited, frankmccabe@mac.com
Peter F Brown, peter@justbrown.net
Rebekah Metz, Booz Allen Hamilton, metz_rebekah@bah.com
Abstract:
This Reference Model for Service Oriented Architecture is an
abstract framework for understanding significant entities and relationships between
them within a service-oriented environment, and for the development of consistent
standards or specifications supporting that environment. It is based on
unifying concepts of SOA and may be used by architects developing specific
service oriented architectures or in training and explaining SOA.
A reference model is not directly tied to any standards,
technologies or other concrete implementation details. It does seek to provide
a common semantics that can be used unambiguously across and between different
implementations. The relationship between the Reference Model and particular
architectures, technologies and other aspects of SOA is illustrated in Figure 1.
While service-orientation may be a popular concept found in a
broad variety of applications, this reference model focuses on the field of
software architecture. The concepts and relationships
described may apply to other "service" environments; however, this
specification makes no attempt to completely account for use outside of the
software domain.
Status:
This document is updated
periodically on no particular schedule. Send comments to the editor(s).
Committee members should send
comments on this specification to the soa-rm@lists.oasis-open.org
list. Others should visit the SOA-RM TC home page at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm,
and record comments using the web form available there.
For information on whether any
patents have been disclosed that may be essential to implementing this
specification, and any offers of patent licensing terms, please refer to the
Intellectual Property Rights section of the SOA-RM TC web page at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
The errata page for this
specification is at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.
OASIS takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document or the
extent to which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such
rights. Information on OASIS's procedures with respect to rights in OASIS
specifications can be found at the OASIS website. Copies of claims of rights
made available for publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or users of
this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other proprietary rights,
which may cover technology that may be required to implement this
specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS Open 2005-2006. All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself should not be
modified in any way, such as by removing the copyright notice or references to
OASIS, except as needed for the purpose of developing OASIS specifications, in
which case the procedures for copyrights defined in the OASIS Intellectual
Property Rights document must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is
provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1 Introduction...................................................................................................................... 4
1.1 What is a reference model............................................................................................. 4
1.2 A Reference Model for Service Oriented Architectures.................................................... 4
1.3 Audience...................................................................................................................... 5
1.4 Guide to using the reference model............................................................................... 6
1.5 Notational Conventions................................................................................................. 6
1.5.1 How to interpret concept maps............................................................................... 6
1.6 Relationships to Other Standards.................................................................................. 7
2 Service
Oriented Architecture............................................................................................ 8
2.1 What is Service Oriented Architecture?........................................................................... 8
2.1.1 A worked Service Oriented Architecture example...................................................... 9
2.2 How is Service Oriented Architecture different?............................................................. 10
2.3 The Benefits of Service Oriented Architecture............................................................... 11
3 The
Reference Model...................................................................................................... 12
3.1 Service....................................................................................................................... 12
3.2 Dynamics of Services................................................................................................. 13
3.2.1 Visibility............................................................................................................... 13
3.2.2 Interacting with services........................................................................................ 15
3.2.3 Real World Effect................................................................................................. 18
3.3 About services............................................................................................................ 19
3.3.1 Service description............................................................................................... 20
3.3.2 Policies and Contracts.......................................................................................... 22
3.3.3 Execution context................................................................................................ 24
4 Conformance
Guidelines................................................................................................. 26
5 References..................................................................................................................... 27
5.1 Normative................................................................................................................... 27
5.2 Non-Normative............................................................................................................ 27
A. Glossary....................................................................................................................... 28
B. Acknowledgments......................................................................................................... 31
The notion of Service Oriented Architecture (SOA) has received
significant attention within the software design and development community. The
result of this attention is the proliferation of many conflicting definitions
of SOA. Whereas SOA architectural patterns (or reference architectures) may be developed to explain and underpin a
generic design template supporting a specific SOA, a reference model is intended to provide an even higher level of
commonality, with definitions that should apply to all SOA.
A reference model is
an abstract framework for
understanding significant relationships among the entities of some environment.
It enables the development of specific reference or concrete architectures
using consistent standards or specifications supporting that environment. A
reference model consists of a minimal set of unifying concepts, axioms and
relationships within a particular problem domain, and is independent of
specific standards, technologies, implementations, or other concrete details.
As an illustration of the relationship between a reference
model and the architectures that can derive from such a model, consider what
might be involved in modeling what is important about residential housing. In
the context of a reference model, we know that concepts such as eating areas,
hygiene areas and sleeping areas are all important in understanding what goes
into a house. There are relationships between these concepts, and constraints
on how they are implemented. For example, there may be physical separation
between eating areas and hygiene areas.
The role of a reference
architecture for housing would be to identify abstract solutions to the
problems of providing housing. A general pattern for housing, one that
addresses the needs of its occupants in the sense of, say, noting that there
are bedrooms, kitchens, hallways, and so on is a good basis for an abstract
reference architecture. The concept of eating area is a reference model
concept, a kitchen is a realization of eating area in the context of the reference
architecture.
There may be more than one reference architecture that
addresses how to design housing; for example, there may be a reference
architecture to address the requirements for developing housing solutions in
large apartment complexes, another to address suburban single family houses,
and another for space stations. In the context
of high density housing, there may not be a separate kitchen but rather a
shared cooking space or even a communal kitchen used by many families.
An actual – or concrete – architecture would introduce
additional elements. It would incorporate particular architectural styles,
particular arrangements of windows, construction materials to be used and so
on. A blueprint of a particular house represents a specific architecture as it
applies to a proposed or actually constructed dwelling.
The reference model for housing is, therefore, at least three
levels of abstraction away from a physical entity that can be lived in. The purpose of a reference model is to
provide a common conceptual framework that can be used consistently across and
between different implementations and is of particular use in modeling specific
solutions.
The goal of this reference model is to define the essence of
service oriented architecture, and emerge with a vocabulary and a common
understanding of SOA. It provides a normative reference that remains relevant
for SOA as an abstract and powerful model, irrespective of the various and
inevitable technology evolutions that will influence SOA deployment.
Figure 1 shows how a reference model for SOA relates to other
distributed systems architectural inputs.
The concepts and relationships defined by the reference model are
intended to be the basis for describing references architectures and patterns
that will define more specific categories of SOA designs. Concrete architectures arise from a
combination of reference architectures, architectural patterns and additional
requirements, including those imposed by technology environments.
Architecture must
account for the goals, motivation, and requirements that define the actual
problems being addressed. While
reference architectures can form the basis of classes of solutions, concrete
architectures will define specific solution approaches.
Architecture is
often developed in the context of a pre-defined environment, such as the
protocols, profiles, specifications, and standards that are pertinent.
SOA implementations
combine all of these elements, from the more generic architectural principles
and infrastructure to the specifics that define the current needs, and
represent specific implementations that will be built and used in an
operational environment.
Figure 1 How
the Reference Model relates to other work
The intended audiences of this document include
non-exhaustively:
- Architects and
developers designing, identifying or developing a system based on the
service-oriented paradigm.
- Standards
architects and analysts developing specifications that rely on service
oriented architecture concepts.
- Decision makers
seeking a "consistent and common" understanding of service
oriented architectures.
- Users who need a
better understanding of the concepts and benefits of service oriented
architecture.
1.4 Guide to using the reference model
New readers are encouraged to read this reference model in
its entirety. Concepts are presented in an order that the authors hope promote
rapid understanding.
This section introduces the conventions, defines the
audience and sets the stage for the rest of the document. Non-technical readers
are encouraged to read this information as it provides background material
necessary to understand the nature and usage of reference models.
Section 2 introduces the concept of SOA and identifies some of
the ways that it differs from previous paradigms for distributed systems. Section
2 offers guidance on the basic principles of service
oriented architecture. This can be used by non-technical readers to gain an
explicit understanding of the core principles of SOA and by architects as
guidance for developing specific service oriented architectures.
Section 3 introduces the Reference Model for SOA. In any
framework as rich as SOA, it is difficult to avoid a significant amount of
cross referencing between concepts. This makes presentation of the material
subject to a certain amount of arbitrariness. We resolve this by introducing
the concept of service itself, then we introduce concepts that relate to the
dynamic aspects of service and finally we introduce those concepts that refer
to the meta-level aspects of services such as service description and policies
as they apply to services.
Section 4 addresses compliance with this reference model.
The glossary provides definitions of terms that are relied
upon within the reference model specification but do not necessarily form part
of the specification itself. Terms that are defined in the glossary are marked
in bold at their first occurrence in
the document.
Note that while the concepts and relationships described in
this reference model may apply to other "service" environments, the
definitions and descriptions contained herein focus on the field of software architecture and make no
attempt to completely account for use outside of the software domain. Examples included in this document that are
taken from other domains are used strictly for illustrative purposes.
1.5 Notational Conventions
The key words MUST,
MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED,
MAY, and OPTIONAL in this document are to be
interpreted as described in [RFC2119].
References are surrounded with [square brackets and are in bold text].
Concepts maps are used within this document. There is no
normative convention for interpreting Concept maps and other than described
herein, no detailed information can be derived from the concept maps herein.
Figure 2 A
basic concept map
As used in this document a line between two concepts
represents a relationship, where the relationship is not labeled but rather is
described in the text immediately preceding or following the figure. The
arrow on a line indicates an asymmetrical relationship, where the concept to
which the arrow points (Concept 2 in Figure
2) can be interpreted as depending in some way on the
concept from which the line originates (Concept 1). The text accompanying
each graphic describes the nature of each relationship.
Due to its nature, this reference model may have an implied
relationship with any group that:
- Considers
its work "service oriented";
- Makes
(publicly) an adoption statement to use the Reference Model for SOA as a
base or inspiration for their work; and
- Standards
or technologies that claim to be service oriented.
The reference model does not endorse any particular
service-oriented architecture, or attest to the validity of third party
reference model conformance claims.
Service Oriented
Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the
control of different ownership domains.
In general, entities (people and organizations) create capabilities
to solve or support a solution for the problems they face in the course of
their business. It is natural to think of one person’s needs being met by
capabilities offered by someone else; or, in the world of distributed
computing, one computer agent’s requirements being met by a computer agent
belonging to a different owner.
There is not necessarily a one-to-one correlation between
needs and capabilities; the granularity of needs and capabilities vary from
fundamental to complex, and any given need may require the combining of
numerous capabilities while any single capability may address more than one
need. The perceived value of SOA is that it provides a powerful framework for
matching needs and capabilities and for combining capabilities to address those
needs.
Visibility, interaction, and effect are key concepts for
describing the SOA paradigm. Visibility
refers to the capacity for those with needs and those with capabilities to be
able to see each other. This is
typically done by providing descriptions for such aspects as functions and
technical requirements, related constraints and policies, and mechanisms for
access or response. The descriptions
need to be in a form (or can be transformed to a form) in which their syntax
and semantics are widely accessible
and understandable.
Whereas visibility introduces the possibilities for matching
needs to capabilities (and vice versa), interaction is the activity of
using a capability. Typically mediated
by the exchange of messages, an interaction proceeds through a series of
information exchanges and invoked actions. There are many facets of
interaction; but they are all grounded in a particular execution context – the set of technical and business elements that
form a path between those with needs and those with capabilities. This permits
service providers and consumers to interact and provides a decision point for
any policies and contracts that may be in force.
The purpose of using a capability is to realize one or more real world effects. At its core, an interaction is “an act” as
opposed to “an object” and the result of an interaction is an effect (or a
set/series of effects). This effect may be the return of information or the
change in the state of entities (known or unknown) that are involved in the
interaction.
We are careful to distinguish between public actions and private
actions; private actions are inherently unknowable by other parties. On the
other hand, public actions result in changes to the state that is shared between at least those involved in the current
execution context and possibly shared by others. Real world effects are, then,
couched in terms of changes to this shared
state.
The expected real world effects form an important part of
the decision on whether a particular capability matches similarly described
needs. At the interaction stage, the
description of real world effects establishes the expectations of those using
the capability. Note, it is not possible to describe
every effect from using a capability. A cornerstone of SOA is that capabilities
can be used without needing to know all the details.
This description of SOA has yet to mention what is usually
considered the central concept: the service.
The noun “service” is defined in dictionaries as “The performance of work (a
function) by one for another.” However,
service, as the term is generally understood, also combines the following
related ideas:
- The
capability to perform work for another
- The
specification of the work offered for another
- The
offer to perform work for another
These concepts emphasize a distinction between a capability
and the ability to bring that capability to bear. While both needs and
capabilities exist independently of SOA, in SOA, services are the mechanism
by which needs and capabilities are brought together.
SOA is a means of organizing solutions that promotes reuse,
growth and interoperability. It is not itself a solution to domain problems but
rather an organizing and delivery paradigm that enables one to get more value
from use both of capabilities which are locally “owned” and those under the
control of others. It also enables one to express solutions in a way that
makes it easier to modify or evolve the identified solution or to try alternate
solutions. SOA does not provide any domain elements of a solution that do
not exist without SOA.
Note that while an SOA service brings together needs and
capabilities, the provider of the underlying capability may not be the same
entity that eventually provides the service which accesses that
capability. In reality, the entity with the domain expertise to create,
maintain, and evolve a given capability may not have the expertise or the
desire to create, maintain, and evolve its service access.
The concepts of visibility, interaction, and effect apply
directly to services in the same manner as these were described for the general
SOA paradigm. Visibility is promoted
through the service description which contains the information necessary
to interact with the service and describes this in such terms as the service
inputs, outputs, and associated semantics.
The service description also conveys what is accomplished when the
service is invoked and the conditions for using the service.
In general, entities (people and organizations) offer
capabilities and act as service
providers. Those with needs who make
use of services are referred to as service
consumers. The service description
allows prospective consumers to decide if the service is suitable for their
current needs and establishes whether a consumer satisfies any requirements of
the service provider.
(Note, service providers and service consumers are sometimes
referred to jointly as service participants.)
In
most discussions of SOA, the terms “loose coupling” and “coarse-grained” are
commonly applied as SOA concepts, but these terms have intentionally not been
used in the current discussion because they are subjective trade-offs and
without useful metrics. In terms of needs and capabilities, granularity and
coarseness are usually relative to detail for the level of the problem being
addressed, e.g. one that is more strategic vs. one down to the algorithm level,
and defining the optimum level is not amenable to counting the number of
interfaces or the number or types of information exchanges connected to an
interface.
Note that although SOA is commonly implemented using Web
services, services can be made visible, support interaction, and generate
effects through other implementation strategies. Web service-based architectures
and technologies are specific and concrete. While the concepts in the Reference
Model apply to such systems, Web services are too solution specific to be part
of a general reference model.
An electric utility has
the capacity to generate and distribute electricity (the underlying
capability). The wiring from the electric company’s distribution grid (the
service) provides the means to supply electricity to support typical usage for
a residential consumer’s house (service functionality), and a consumer accesses
electricity generated (the output of invoking the service) via a wall outlet
(service interface). In order to use the electricity, a consumer needs to
understand what type of plug to use, what is the voltage of the supply, and
possible limits to the load; the utility presumes that the customer will only
connect devices that are compatible with the voltage provided an