A few people who have been reading my blog and this column, and listening to my podcast, as well as reading other SOA blogs and articles, have become a bit confused pertaining to the notions of:

• SOA Reference Model(s)
• SOA Reference Architecture(s)

• Enterprise Architecture

Indeed, there are many definitions for the above concepts (not those terms specifically) that are now being defined by guys like me, standards organizations such as OASIS and the Open Group, and vendors such as IBM, BEA, WebMethods, and TIBCO. Sometimes they align; most of the time they don't.

Who's right? I'm not sure this is a matter of right and wrong, but perhaps it's time we come up with some common definitions and shared vision, as I've been saying. I do think we are moving in that direction, albeit slowly, and I think that just agreeing on semantics will be a huge accomplishment in this emerging space.

I'll tell you what I know; you can make your own choices. Let's begin by exploring the concepts being put forth by the standards organizations. This will be backing up a bit from the recent posts and columns that have basically restated and commented on the news; I'm attempting to provide better context. Also, to avoid the many e-mails and comments I get when writing about this stuff from those who write the standards and define these terms, I'm going to be quoting more than I typically do. Also, I engaged an insider for fact-checking, JPL's Jeffrey A. Estefan, who is authoring the standards. Of course, I have to add my 2 cents. Here goes...

SOA Reference Model
Now let's explore the concept of the SOA Reference Model, also a product of OASIS, and how the SOA Reference Model and SOA Reference Architecture relate to each other. From the OASIS Reference Model for Service-Oriented Architecture.

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.

The role of a reference architecture for housing would be to identify abstract solutions to the problems of providing housing. A general pattern for housing, one that addresses the needs of its occupants in the sense of, say, noting that there are bedrooms, kitchens, hallways, and so on is a good basis for an abstract reference architecture. The concept of eating area is a reference model concept, a kitchen is a realization of eating area in the context of the reference architecture.

The goal of this reference model is to define the essence of service-oriented architecture and emerge with a vocabulary and a common understanding of SOA. It provides a normative reference that remains relevant for SOA, irrespective of the various and inevitable technology evolutions that will influence SOA deployment.

The concepts and relationships defined by the reference model are intended to be the basis for describing reference architectures and patterns that will define more specific categories of SOA designs. Concrete architectures arise from a combination of reference architectures, architectural patterns, and additional requirements, including those imposed by technology environments.

Again, abstraction, one is an instance(s) of the other, if I understand this correctly. I urge you to download and read this 31-page document to get some additional details. Also, get involved, if you like. I always love the comeback from standards bodies that deal with criticism and debate around the concepts they put forward: "If you don't like it, join us and change it." Can't argue with that.

I would, however, recommend that OASIS make this a bit easier to understand for the typical end user, as I stated before. Again, perhaps provide published use cases for the RM and RA, and thus make the notion a bit more consumable. I'll consider this an open-ended definition for now, so please send your use cases and I'll write columns about them here. In essence, how the reference architecture and model will be used in a sentence.

You have to give them an A for effort, but you can see where the debates are going to pop up. It's really a matter of understanding, a marketing issue really. I understand different levels of architectural abstractions, but what is really needed is a reference framework or model, and a set of steps to figure out how to build something that's proper for your problem domain. I've been building that recently, and I'm happy to map them back to this reference model if it makes sense for the project. The use cases out there are like snowflakes, and one size, or one model, does not fit all. You have to account for that within all this formality.

However, to be fair, if you Google "SOA Reference Model" or "SOA Model," or things of that nature, you'll find that most SOA vendors and consulting organizations have their own SOA (reference) models, SOA frameworks, SOA roadmaps, or SOA reference architectures. They are a bit different than what OASIS is proposing, but again, they're looking to solve the same sets of problems.

My best advice is to leverage the architecture, models, roadmaps, or frameworks that will work best for you. At the end of the day, I think clarity of approach will win over complexity, as long as you can do that without diminishing the value.