OASIS SOA Reference Model
The OASIS 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.
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 Technical Committee. 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. The reference model was approved as an OASIS Standard by OASIS members in October 2006.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 was approved as an OASIS Committee Specification in December 2012.
While the OASIS SOA Reference model has been welcomed in some quarters, numerous other SOA specification efforts 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 , , and the 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 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, 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, 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 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
- An electric utility has the capacity to generate and distribute electricity '. The wiring from the electric company’s distribution grid ' provides the means to supply electricity to support typical usage for a residential consumer’s house ', and a consumer accesses electricity generated ' via a wall outlet '.
- 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 '.
- A residential or business user will need to open an account with the utility in order to use the supply ' and the utility will meter usage and expects the consumer to pay for use at the rate prescribed '. When the consumer and utility agree on constraints and policies ', the consumer can receive electricity using the service as long as the electricity distribution grid and house connection remain intact and the consumer can have payment sent to the utility '.
- Another person may use a contracted supply without any relationship with the utility or any requirement to also satisfy the initial service constraint but would nonetheless be expected to be compatible with the service interface.
- In certain situations, a utility may limit supply or institute rolling blackouts '. A consumer might lodge a formal complaint if this occurred frequently '.
- 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