OASIS SOA Reference Model

The OASIS SOA Reference Model is a reference model for Service-oriented architecture (SOA) produced by OASIS, an IT industry standards body. SOA is a type of software development where a series of self-contained services combine with other services to create a complete software package. A reference model provides a set of definitions of concepts so that software developers working in different organizations have the same understanding of what terms mean.

The reference model was developed by the industry standards group, OASIS, in 2006. OASIS's model was the first, but the Open Group has developed a rival model.

Description

History

The OASIS SOA Reference Model, is a product of the OASIS SOA Reference Model (SOA-RM) Technical Committee (TC).^[1] 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.^[2] The reference model was approved as an OASIS Standard by OASIS members in October 2006.^[3]

Current status

While the OASIS SOA Reference model has been welcomed in some quarters,^[4] there is some indication of rival initiatives by other standards bodies, including the Open Group.^[5][6]

Future Work

At this time, the future work of the SOA-RM TC beyond the current specification has not yet been defined. The SOA-RA subcommittee is continuing to developing an SOA reference architecture based on the SOA-RM specification.

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, particularly when the participants are in different ownership domains, between participants in service interactions.
• Visibility: The capacity for those with needs and those with capabilities to be able to interact with 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.
• 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 permit service providers and consumers to 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.

Notes

1. ↑ "OASIS SOA Reference Model TC". OASIS. Retrieved February 5, 2015. 
2. ↑ Nickull, Duane (January 4, 2006). "Why we need the OASIS SOA Reference Model". Loosely Coupled. Retrieved February 5, 2015. 
3. ↑ "OASIS Members Approve SOA Reference Model". Grid Today. October 30, 2006. Archived from the original on 27 September 2007. 
4. ↑ Considering the SOA Reference Model Part 1, Considering the SOA Reference Model Part 2
5. ↑ Linthicum, Dave (February 4, 2007). "Open Group debates SOA Reference Architecture...". Infoworld. Archived from the original on June 7, 2007. 
6. ↑ Little, Mark (February 21, 2007). "Psst ... got a SOA Reference Model? Want another one?". InfoQ. Retrieved February 5, 2015.