What is the OASIS Service Oriented Architecture Reference Model?
Under the auspices of the OASIS standards consortium, a group of end users, software vendors, and other interested parties came together to help define a reference model for Service Oriented Architecture (SOA). SOA itself is used in multiple contexts within the software industry with confusing, differing and even conflicting definitions. The OASIS Technical Committee (TC) decided to start the work to answer two fundamental questions about SOA:
- If SOA is architecture, as the name implies, how can it be defined and what makes it different from other architectures?; and
- How can SOA be described in an architectural manner that is abstract of all implementations?
The TC seeks to answer these two questions. In doing so, it may define SOA in terms of its components (abstract) and the nature of the relationships between them. (See also "What is software architecture?" below.)
Is a Reference Model part of a larger framework?
It could be, whether explicitly or implicitly. The figure below shows how the SOA RM might fit into an SOA Framework and aid those in the industry, their customers and their sales processes by also helping explain a concept (SOA) and its inner workings to different audiences.
In this figure, the reference model "guides" those who do architecture work, but not in a constrictive manner. Architects are free to use the base model alone or combine it with other models and even add other components to it.
The requirements and goals of the stakeholders of the specific SOA implementation is critical input during the architectural cycle. There are several well defined processes within the software industry to control software architecture development. Some of the most common are IBM's Rose Unified Process (RUP), OMG's Model Driven Architecture (MDA), and the Zachman Framework. Many others exist.
The architects use artifacts similar to a reference model in each of these processes, whether explicit or implicit to determine the components that will be part of the solution. At the right hand side of the figure above, there are some referenced protocols, specifications, and other standards. These are used to help compose the implementation and often vary depending on the requirements of the stakeholders. Some examples specific to an SOA implementation might be XML, SOAP, WS-Security, XML Schema, or WS-Reliable Messaging.
The implementation itself is constrained directly by the architecture work.
It is important to note that architects need not follow the reference model precisely. It is merely a template to start the process. If an industry is well aligned around a common reference model, it benefits all within the industry. Suppliers of specific components can easily describe what their companies deliver in terms of the reference model (much the same way that the OSI Seven Layer reference model helped align the network industry. Vendors were able to clearly explain what layer they offered product in, network engineers were able to determine the responsibilities of each layer and avoid architecting networks with functionality duplicated amongst multiple components.)
Architects may work with the reference model and other models during the architecture development process. Other models for items like managing multiple service calls in terms of a Process Oriented Architecture model might be used, as well as network models like the OSI seven layer reference model (as examples).
Architects may develop several reference models specific to the SOA-RM, then specialize each of them for more tightly defined purposes. An example of this may be to develop a generalized Reference Architecture (RA) for the purposes of managing, gathering and aggregating data over a wide area network, employing security to prevent unauthorized usage, then develop several specific architectures for multiple clients who want that Reference Architecture further specialized to their requirements.
How does the SOA-RM relate to Web services and other SOAs?
The Reference Model is abstracted from specific SOAs. For example, one could state "Web services can be used to implement SOA, but service orientation does not necessitate the use of Web services protocols, nor does the use of Web services protocols ensure that the overall system is SOA."
The graphic above depicts a section on the right hand side with the labels "Related work" including protocols, specifications and standards. This is where many Web services standards would be in relationship to the architecture process. Architects might use these standards, protocols and specifications to build a concrete implementation, guided by OASIS SOA-RM.