> opinion > supplier viewpoint

Why we need the OASIS SOA Reference Model

by Duane Nickull
January 4th, 2006

Definitions of service oriented architecture (SOA) vary greatly depending upon whom you ask. In some cases, the definitions are inconsistent. While SOA has dominated recent press and analyst coverage, no formal standard definition exists. In 2004, a group attempting to specialize an SOA architecture realized they had vastly differing opinions regarding the basic concepts and decided any meaningful progress required them to define a normative Reference Model for Service Oriented Architectures.

A good reference model provides common semantics that can be used unambiguously across and between different implementations.

Duane Nickull is Senior Standards Strategist, Adobe Systems, and chair of the OASIS Service Oriented Architecture Reference Model Technical Committee (SOA-RM TC). He is also vice-chair of UN/CEFACT and was a co-editor of ebXML. Edited by Ken Laskey, lead engineer for The MITRE Corporation, this is the first in a series of four articles. Download a PDF version (154k), complete with diagrams.

Within the OASIS SOA-RM Technical Committee, SOA is defined as a "paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains." The TC decided to constrain its work to the scope of software architecture, even though many of the principles of SOA are as valid for completely different domains  for an extreme example, coffee shop architectures.

The work focused on defining an Abstract Model. This can quickly confuse non-architects, who have trouble distinguishing between concrete architecture and abstract models. The Reference Model (RM) of current interest 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 the SOA paradigm. A reference model is not directly tied to any standards, technologies or other concrete implementation details (such as "Web Services"). Hence, a good reference model provides common semantics that can be used unambiguously across and between different implementations.

Common language

Reference models are important for all industries. The housing industry has an implied reference model "Residential Dwelling." It serves a purpose of providing habitable space for human beings. It has clearly defined components such as a door (interface to the community), floors, walls, rooms, a roof, plumbing, heating and electrical systems, windows and more. The main purpose of this implied reference model is to ensure that the entire industry has consensus on the meanings of these terms, which avoids general chaos when architecting and building houses. A house architect knows that when he specified a "front door" for a house, it will be universally understood by the builder and user what the door does and how it may be built and used.

Similarly, in the IT space, architects, CIOs and other IT workers, ISVs and others all need to speak a common language when discussing SOA. The OASIS RM for SOA focuses its views on the abstract service, then progresses to expand on other concepts linked to the service.

In some ways, SOA is really a view of architecture, focusing on the view and things seen by it. A view transforms into how a thing is depicted. A single architecture can have multiple views  mimicking how a person views real world objects. For example, if a person views a book from 90 degrees to the cover, it may appear to be perfectly square and measure about 12 inches by 12 inches. Another view may be of the book at a 45 degree angle with the pages open. While both views are of the same item, they differ in how the 'thing' itself is depicted. Software architecture is no different and elements may be visible or invisible based on the view of the architecture.

Classical architecture views include the class view (a view of the class structure of a system), the data model view, the process model view, and the deployment view. SOA is really a view focusing on the services of a system and the components the services interact with.

Core concepts

The core view of the RM for SOA starts with the concepts of Service, Visibility, Service Description, Execution Context, Real World Effect and Contract & Policy.

A service is a mechanism to enable access to a set of one or more capabilities, where theaccess is provided using a prescribed interface and is exercised consistent with constraints and policies (Contract & Policy) as specified by the service description. The consequence of invoking a service (interaction) is a realization of one or more real world effects, described in detail in the current draft of the RM specification (see 'Background' below for link). The execution context of a service interaction is the set of infrastructure elements, processentities, policy assertions and agreements that are identified as part of an instantiated service interaction.

Services have many other facets and axioms expressed in the current committee draft of the RM for SOA. Services have action models, process models and information models. Information models themselves have aspects such as semantics and structure which need to be universally interpreted and understood by the community of potential consumers.

The work of the OASIS SOA RM TC is not yet complete and the current draft (rev 11) is a candidate for Committee Draft. Once it becomes a Committee Draft, it may progress to become an official OASIS Committee Specification and possibly eventually a full OASIS standard. Architects and other IT workers are welcome to download and view the current draft.