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.)
What is a Reference Model?
A reference model is an abstract framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment. A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist.  A reference model is not directly tied to any standards, technologies or other concrete implementation details, but it does seek to provide a common semantics that can be used unambiguously across and between different implementations. (See "Purpose of Reference Model" below.)
What is software architecture?
Software architecture for a system is the structure or structures of the system, which consist of elements and their externally visible properties and the relationships among them.
Is a reference model implementable or does it reference existing standards like Web services?
No. It is abstract in nature.
What is the purpose of a reference model?
A Reference Model is used by architects as a template for composing architectures. Much the same way as the auto industry agrees on the logical divisions in components of a car, the software industry uses reference models to make logical divisions and groupings within architectures. Doing so makes it easier for vendor products to be aligned to meet the requirements of the architecture and allows users to understand where their products fit into their corporate architecture. It works much the same way as when a tire manufacturer knows that an auto manufacturer understands implicitly that a "wheel" is a round component that bolts to a " hub" and accepts a " tire" into its rim. Unlike specific architectures, however, the reference model does not specify what size the wheel is or what bolt pattern it must use, only that it has those attributes. Individual instance of wheel and rim may vary in size, shape, and composition.
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.