Reference Model for Service Oriented Architecture (SOA-RM) Introduction


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.

What is Service Oriented Architecture?

Entities (people and organizations) create capabilities to solve the problems they face in the course of their business; one person’s needs may be met by capabilities offered by someone else. SOA provides a framework for matching needs and capabilities and for combining capabilities to address those needs.

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.


The central concept of SOA is 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. In SOA, services are the mechanism by which needs and capabilities are brought together.

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


Visibility refers to the capacity for those with needs and those with capabilities to be able to see each other.  Visibility is promoted through the service description which describes functions and requirements, related constraints and policies, and mechanisms for access or response.  The descriptions need to be in a form in which their syntax and semantics are 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. The service description provides the information necessary to interact with the service and describes this in such terms as the service inputs, outputs, and associated semantics. 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. The service description conveys what is accomplished when the service is invoked and the conditions for using the service.

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

Service Providers and Service Consumers

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.

Service providers and service consumers are sometimes referred to jointly as service participants.1

Figure 1 illustrates the principal concepts of the Reference Model of SOA:

Principle concepts of the Reference Model of SOA

Figure 1. Principal components in the Reference Model of SOA (SOA-RM).

The relationships between the principal concepts are developed as each concept is defined in turn:

Source: OASIS – Reference Model for Service Oriented Architecture – 2006

Previous: OASIS – Navigating the SOA Landscape Through Architecture
Next: SOA-RM – Service

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