OASIS SOA Reference Model
by Mike Rosen, Director, Cutter Consortium Enterprise Architecture Practice
In October, OASIS (Organization for the Advancement of Structured Information Systems) approved the Reference Model for Service Oriented Architecture V1.0. A lot of people have been asking what it is, what to do with it, and how it will impact their SOA initiative.
The reference model document itself states:
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.
That's certainly a mouthful, but let's pick out a few important words: abstract framework, unifying concepts, concrete details.
The abstract framework is a set of concepts, definitions, and relationships. These are expressed as "concept maps," which are informal diagrams showing the concepts as ovals and the relationships as arrows between them. Then, the concepts and relationships are defined in text that follows the diagrams. I think this is my biggest problem with the reference model. Why did a standards organization choose to use a nonstandard way of representing these concepts? There are ISO standards (for example, the General Relationship Model) for addressing exactly this issue in a formal and precise manner. If nothing else, a reference model needs to be precise and I think the OASIS model fails in this aspect.
However, I think the model gets it right in terms of the unifying concepts. At the highest level, the main concepts are: service, visibility, service description, execution context, real world effect, and contract and policy. A concept map lists the main concepts and more detailed maps introduce additional sets of concepts for each of the main concepts.
At the top level, a service is a mechanism to enable access to a set of capabilities. The visibility determines the access, which is provided using a prescribed interface and is exercised consistent with contracts and policies as specified in the service description. A service is invoked within a specific execution context, which causes one or more real world effects to occur.
The document is right upfront about its purpose. It is not an architecture, a set of patterns, or any kind of technology. It is a set of concepts that occur in most SOA architectures. So, if you are going to be creating an SOA, you should consider these concepts during that process and integrate the appropriate ones into your architecture. Or if you want to compare different architectures, the reference model provides a set of concepts, or a "common language" that allows them to be objectively compared. So here's another beef I have with the document. I know that the choice of terms is difficult, but it's important in a "common language." I just can't see "real world effect" as standing the test of time. But that is a minor complaint.
Finally, on to concrete details. There are none. This is just a set of concepts taken to a high level of abstraction. A good set of concepts, but I think most people will not know what to do with this reference model, which will undoubtedly limit its usefulness. Additionally, I think the common language aspect of the reference model will start to fall apart as people go in different directions to get to the next level of detail.
So I've answered the first two questions. What is it? It's a set of fundamental concepts that occur in SOA. What to do with it? Use the concepts to develop or refine your SOA architecture, to compare architectures, or as a basis for a common language to discuss SOA. And for the third question, how will it impact your SOA initiative? I'd say probably not very much. Unfortunately, I think that a very good set of concepts gets lost in the high level of abstraction and the informal, imprecise, and nonstandard presentation. It's really too bad, because it's an important problem that OASIS is trying to solve. You have to start somewhere, so I applaud OASIS for its initial efforts and look forward to a revised version of the reference model in the not-too-distant future.
-- Mike Rosen, Director, Cutter Consortium Enterprise Architecture Practice