OASIS SOA Reference Model

Last updated April 10, 2021

The OASIS Reference Model for Service Oriented Architecture^[1] (SOA-RM) 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.

In this context, a reference model is seen as a venue to provide a common semantics that can be used unambiguously across and between different SOA implementations. The relationship between the Reference Model and particular architectures, technologies and other aspects of SOA is illustrated below from the specification.

Description

History

The OASIS SOA Reference Model, is a product of the OASIS SOA Reference Model (SOA-RM) Technical Committee (TC).^[2] Prior to this initiative, no standard definition of SOA had existed. The SOA-RM TC was chartered in February 2005 to develop a core Reference Model to guide and foster the creation of specific service-oriented architectures, and to publish a reference model for SOA, as well as one or more reference architectures based on the Reference Model.^[3] The reference model was approved as an OASIS Standard by OASIS members in October 2006.^[4]

The OASIS SOA-RM TC began work on a companion Reference Architecture during the final approval period for the Reference Model, and the OASIS Reference Architecture Foundation for Service Oriented Architecture (SOA-RAF)^[5] was approved as an OASIS Committee Specification in December 2012.

While the OASIS SOA Reference model has been welcomed in some quarters,^[6] numerous other SOA specification efforts^[7]^[8] were also being discussed during the time period when the SOA-RAF was being developed . A collaborative effort to “harmonize” the individual efforts was begun with OASIS, The Open Group, and the Object Management Group (OMG) during the 2008-2009 period. While discussions found obvious commonality, harmonization was beyond reach at that time, and the final product was a joint paper Navigating the SOA Open Standards Landscape Around Architecture^[9] published in July 2009. In addition, Appendix C of the SOA-RAF contains a summary of other SOA standardization efforts. Discussions have continued to the present. Below (and in the SOA-RM itself), there is discussion of how multiple reference architectures can be derived from a single reference model.

Current status

The SOA-RM TC remains active and continues discussions on topics such as service and interface granularity. Additional Committee Notes may result from those discussions.

Principal Concepts

OASIS definition of SOA

According to the SOA-RM specification, SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. The SOA-RM specification bases its definition of SOA around the concept of “needs and capabilities”, where SOA provides a mechanism for matching needs of service consumers with capabilities provided by service providers.

Service

The central concept of the Reference Model is that of service, which the Reference Model defines as follows: A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.

The following are the principal concepts that the Reference Model defines around services. Visibility, Interaction, and Real World Effect address the dynamic aspects of services (interactions with services), while the remaining concepts address static aspects:

Service Description: The information needed in order to use, or consider using, a service. The purpose of description is to facilitate interaction and visibility between participants in service interactions, particularly when the participants are in different ownership domains.
Visibility: The capacity for those with needs and those with capabilities to be able to interact with each other. Visibility includes not only that a service exists but also that there is sufficient consumer knowledge of the provider and provider knowledge of the consumer that willingness has been established between the parties to initiate or continue the interaction. 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.
Interaction: Refers to the interaction between service providers and consumers. Typically mediated by the exchange of messages, an interaction proceeds through a series of information exchanges and invoked actions. The result of an interaction is a real world effect.
Real World Effect: The actual result of using a service. This may be the return of information or the change in the state of entities (known or unknown) that are involved in the interaction.
Execution Context: The set of technical and business elements that form a path between those with needs and those with capabilities and that establish the conditions under which service providers and consumers will interact. All interactions are grounded in a particular execution context, which permits service providers and consumers to interact and provides a decision point for any policies and contracts that may be in force.
Contract & Policy: A policy represents some constraint or condition on the use, deployment or description of an owned entity as defined by any participant, while a contract represents an agreement by two or more parties. The Reference Model is focused primarily on the concept of policies and contracts as they apply to services.

SOA Example

The following example is taken from the SOA-RM specification and includes the principal concepts described above as well as other concepts that the Reference Model defines, in parentheses and italics:

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 and load supported; and the consumer in turn assumes that compatible consumer devices can be connected without damage or harm (service technical assumptions).
A residential or business user will need to open an account with the utility in order to use the supply (service constraint) and the utility will meter usage and expects the consumer to pay for use at the rate prescribed (service policy). When the consumer and utility agree on constraints and policies (service contract), the consumer can receive electricity using the service as long as the electricity distribution grid and house connection remain intact (e.g., a storm knocking down power lines would disrupt distribution) and the consumer can have payment sent (e.g., a check by mail or electronic funds transfer) to the utility (reachability).
Another person (for example, a visitor to someone else's house) may use a contracted supply without any relationship with the utility or any requirement to also satisfy the initial service constraint (e.g., reachability only requires intact electricity distribution) but would nonetheless be expected to be compatible with the service interface.
In certain situations (for example, excessive demand), a utility may limit supply or institute rolling blackouts (service policy). A consumer might lodge a formal complaint if this occurred frequently (consumer's implied policy).
If the utility required every device to be hardwired to its equipment, the underlying capability would still be there but this would be a very different service and have a very different service interface.

SOA and Processes

While the Reference Model incorporates the notion of processes through its Process Model concept, the extent of this aspect of the Reference Model is intentionally not completely defined. For example, the Reference Model does not address the orchestration of multiple services, although orchestration and choreography may be part of the process model. This is because the focus of the Reference Model is on modeling what services are and what key relationships are involved in modeling services. It is envisioned that there may be future work in this area, though the source of that work has yet to be defined.

Secondary Concepts

OASIS definition of Reference Model

According to the SOA-RM specification, 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. A reference model for SOA, therefore, is an abstract framework for understanding significant relationships among the entities of SOA.

Reference Model vs. Reference Architecture

The SOA-RM specification provides a clear distinction between a reference model and a reference architecture, and describes the relationship between them. A reference architecture is an architectural design pattern that indicates how an abstract set of mechanisms and relationships realizes a predetermined set of requirements. One or more reference architectures may be derived from a common reference model, to address different purposes/usages to which the Reference Model may be targeted. The SOA-RM specification provides an analogy involving the design of housing to illustrate the relationship between a reference model and a reference architecture, as well as how reference architectures may be used to derive concrete architectures.

Related Research Articles

Service-oriented architecture (SOA) is an architectural style that supports service orientation. By consequence, it is as well applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.

Representational state transfer (REST) is a software architectural style which uses a subset of HTTP. It is commonly used to create interactive applications that use Web services. A Web service that follows these guidelines is called RESTful. Such a Web service must provide its Web resources in a textual representation and allow them to be read and modified with a stateless protocol and a predefined set of operations. This approach allows interoperability between the computer systems on the Internet that provide these services. REST is an alternative to, for example, SOAP as way to access a Web service.

Web Services Discovery provides access to software systems over the Internet using standard protocols. In the most basic scenario there is a Web Service Provider that publishes a service and a Web Service Consumer that uses this service. Web Service Discovery is the process of finding suitable web services for a given task.

In computing and systems design a loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.

Java Business Integration (JBI) is a specification developed under the Java Community Process (JCP) for an approach to implementing a service-oriented architecture (SOA). The JCP reference is JSR 208 for JBI 1.0 and JSR 312 for JBI 2.0. JSR 312 was removed from the JCP balloting process on 17 Dec, 2010 by the submitters without being accepted.

A reference model—in systems, enterprise, and software engineering—is an abstract framework or domain-specific ontology consisting of an interlinked set of clearly defined concepts produced by an expert or body of experts to encourage clear communication. A reference model can represent the component parts of any consistent idea, from business functions to system components, as long as it represents a complete set. This frame of reference can then be used to communicate ideas clearly among members of the same community.

In the contexts of software architecture, service-orientation and service-oriented architecture, the term service refers to a software functionality or a set of software functionalities with a purpose that different clients can reuse for different purposes, together with the policies that should control its usage.

Reference Model of Open Distributed Processing (RM-ODP) is a reference model in computer science, which provides a co-ordinating framework for the standardization of open distributed processing (ODP). It supports distribution, interworking, platform and technology independence, and portability, together with an enterprise architecture framework for the specification of ODP systems.

The Governance Interoperability Framework (GIF) is an open, standards-based specification and set of technologies that describes and promotes interoperability among components of a service-oriented architecture (SOA). GIF integrates SOA ecosystem technologies to achieve heterogeneous service lifecycle governance and is supported by Hewlett-Packard Company and by GIF partners.

Service Component Architecture (SCA) is a software technology designed to provide a model for applications that follow service-oriented architecture principles. The technology, created by major software vendors, including IBM, Oracle Corporation and TIBCO Software, encompasses a wide range of technologies and as such is specified in independent specifications to maintain programming language and application environment neutrality. Many times it uses an enterprise service bus (ESB).

The first version of the Enterprise Collaboration Architecture (ECA) has been published by the Object Management Group (OMG) in 2001. The vision of the (ECA) is to simplify the development of component based and services oriented systems by providing a modeling framework aligned with the model-driven architecture (MDA) of the Object Management Group (OMG).

Content Assembly Mechanism (CAM) is an XML-based standard for creating and managing information exchanges that are interoperable and deterministic descriptions of machine-processable information content flows into and out of XML structures. CAM is a product of the OASIS Content Assembly Technical Committee.

In intelligent networks (IN) and cellular networks, service layer is a conceptual layer within a network service provider architecture. It aims at providing middleware that serves third-party value-added services and applications at a higher application layer. The service layer provides capability servers owned by a telecommunication network service provider, accessed through open and secure Application Programming Interfaces (APIs) by application layer servers owned by third-party content providers. The service layer also provides an interface to core networks at a lower resource layer. The lower layers may also be named control layer and transport layer.

Event-driven SOA is a form of service-oriented architecture (SOA), combining the intelligence and proactiveness of event-driven architecture with the organizational capabilities found in service offerings. Before event-driven SOA, the typical SOA platform orchestrated services centrally, through pre-defined business processes, assuming that what should have already been triggered is defined in a business process. This older approach does not account for events that occur across, or outside of, specific business processes. Thus complex events, in which a pattern of activities—both non-scheduled and scheduled—should trigger a set of services is not accounted for in traditional SOA 1.0 architecture.

Marlin is a DRM platform, created by an open-standards community initiative called the Marlin Developer Community (MDC). The MDC develops the necessary technology, partners, and services for enabling the creation of interoperable digital content distribution services.

SoaML is an open source specification project from the Object Management Group (OMG), describing a UML profile and metamodel for the modeling and design of services within a service-oriented architecture.

Open Automated Demand Response (OpenADR) is a research and standards development effort for energy management led by North American research labs and companies. The typical use is to send information and signals to cause electrical power-using devices to be turned off during periods of high demand.

Cloud Infrastructure Management Interface (CIMI) is an open standard API specification for managing cloud infrastructure.

The SAML metadata standard belongs to the family of XML-based standards known as the Security Assertion Markup Language (SAML) published by OASIS in 2005. A SAML metadata document describes a SAML deployment such as a SAML identity provider or a SAML service provider. Deployments share metadata to establish a baseline of trust and interoperability.

NGSI-LD is an information model and API for publishing, querying and subscribing to context information. It is meant to facilitate the open exchange and sharing of structured information between different stakeholders. It is used across application domains such as Smart Cities, Smart Industry, Smart Agriculture, and more generally for the Internet of Things, Cyber-Physical Systems, Systems of systems and Digital Twins.

References

↑ "OASIS Reference Model for Service Oriented Architecture 1.0, Official OASIS Standard (Normative PDF), Oct. 12, 2006" (PDF).
↑ "OASIS SOA Reference Model TC". OASIS. Retrieved February 5, 2015.
↑ Nickull, Duane (January 4, 2006). "Why we need the OASIS SOA Reference Model". Loosely Coupled. Retrieved February 5, 2015.
↑ "OASIS Members Approve SOA Reference Model". Grid Today. October 30, 2006. Archived from the original on 27 September 2007.
↑ "OASIS Reference Architecture Foundation for Service Oriented Architecture Version 1.0, Committee Specification 01 (Authoritative PDF), 04 December 2012" (PDF).
↑ Considering the SOA Reference Model Part 1, Considering the SOA Reference Model Part 2
↑ Linthicum, Dave (February 4, 2007). "Open Group debates SOA Reference Architecture..." Infoworld. Archived from the original on June 7, 2007.
↑ Little, Mark (February 21, 2007). "Psst ... got a SOA Reference Model? Want another one?". InfoQ. Retrieved February 5, 2015.
↑ "Navigating the SOA Open Standards Landscape Around Architecture, Joint Paper by The Open Group, OASIS, and OMG, July 2009" (PDF).

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[1] "OASIS Reference Model for Service Oriented Architecture 1.0, Official OASIS Standard (Normative PDF), Oct. 12, 2006" (PDF).

[2] "OASIS SOA Reference Model TC". OASIS. Retrieved February 5, 2015.

[3] Nickull, Duane (January 4, 2006). "Why we need the OASIS SOA Reference Model". Loosely Coupled. Retrieved February 5, 2015.

[4] "OASIS Members Approve SOA Reference Model". Grid Today. October 30, 2006. Archived from the original on 27 September 2007.

[5] "OASIS Reference Architecture Foundation for Service Oriented Architecture Version 1.0, Committee Specification 01 (Authoritative PDF), 04 December 2012" (PDF).

[6] Considering the SOA Reference Model Part 1, Considering the SOA Reference Model Part 2

[7] Linthicum, Dave (February 4, 2007). "Open Group debates SOA Reference Architecture..." Infoworld. Archived from the original on June 7, 2007.

[8] Little, Mark (February 21, 2007). "Psst ... got a SOA Reference Model? Want another one?". InfoQ. Retrieved February 5, 2015.

[9] "Navigating the SOA Open Standards Landscape Around Architecture, Joint Paper by The Open Group, OASIS, and OMG, July 2009" (PDF).

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]