OASIS SOA Reference Model
Encyclopedia
The OASIS SOA Reference Model is a reference model
for Service-oriented architecture
(SOA) produced by OASIS
, an IT industry standards body. SOA is an architectural paradigm for matching needs and capabilities that may be under disparate domains of ownership. While the term is often used as a noun, it is a very distinct style of architecture, applicable to domains beyond software systems.
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.
.
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.
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.
• 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.
Reference Model
A reference model in systems, enterprise, and software engineering is a model of something that embodies the basic goal or idea of something and can then be looked at as a reference for various purposes.- Overview :...
for Service-oriented architecture
Service-oriented architecture
In software engineering, a Service-Oriented Architecture is a set of principles and methodologies for designing and developing software in the form of interoperable services. These services are well-defined business functionalities that are built as software components that can be reused for...
(SOA) produced by OASIS
OASIS (organization)
The Organization for the Advancement of Structured Information Standards is a global consortium that drives the development, convergence and adoption of e-business and web service standards...
, an IT industry standards body. SOA is an architectural paradigm for matching needs and capabilities that may be under disparate domains of ownership. While the term is often used as a noun, it is a very distinct style of architecture, applicable to domains beyond software systems.
History
The OASIS SOA Reference Model is a product of the OASIS SOA Reference Model (SOA-RM) Technical Committee (TC). 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 ModelReference Model
A reference model in systems, enterprise, and software engineering is a model of something that embodies the basic goal or idea of something and can then be looked at as a reference for various purposes.- Overview :...
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.
Current status
While the OASIS SOA Reference model has been welcomed in some quarters, there is some indication of rival initiatives by other standards bodies, including the Open GroupThe Open Group
The Open Group is a vendor and technology-neutral industry consortium, currently with over three hundred member organizations. It was formed in 1996 when X/Open merged with the Open Software Foundation...
.
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.OASIS definition of SOA
According to the SOA-RM specification, SOA is a paradigmParadigm
The word paradigm has been used in science to describe distinct concepts. It comes from Greek "παράδειγμα" , "pattern, example, sample" from the verb "παραδείκνυμι" , "exhibit, represent, expose" and that from "παρά" , "beside, beyond" + "δείκνυμι" , "to show, to point out".The original Greek...
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.