Understanding SOA Architectures and Models…SOA RA

Continued from my last blog…while there are SOA Reference Architectures all over the place, including mine, the best known SOA Reference Architecture (SOA-RA) is defined by OASIS.

So, what’s a reference architecture and how does it relate to a reference model? In short, a reference architecture is a description of how to build a class of artifacts. An architecture describes how to build a particular artifact. The appropriate way to write the description for a reference architecture depends on the particular artifact.

While the definition is changing according to those writing the standard, the SOA-RA provides a bridge between the concepts and vocabulary defined by the SOA Reference Model (SOA-RM) and the implementation of a SOA. In other words, the SOA reference architecture models the abstract architectural elements for a SOA independent of the technologies, protocols, and products that are used to implement a SOA.

I have to agree with this, albeit it is a bit confusing. They are describing a high level of abstraction to define a SOA, the “reference architecture,” and the “architecture” as an instance of a SOA. I get that. However, the larger issue is the fact that the problem domains I’m seeing are not as similar as you think, thus the questions is: Can you define a single class of artifacts, and thus provide a sound “jumping-off-point” for the instance? I think a few use cases will prove this out. I could not find many, so send them to me if you have them…I’ll post them here. However, to be fair to the creators of the standard, this is still a work in process.

Also confusing is the number of SOA Reference Architectures you see out there, including this one from webMethods.

What’s more, you can find more vendor-created models going by different names, but basically attempting to define the same thing..a reference architecture for SOA. However, most appear to define the same notions as put forth with the SOA Reference Model (discussed next).

Here are some others:

Burton Group SOA RA

IBM SOA RA

BEA (+ some consortia) SOA RA

Some of the key issues, as I see it, are:

There really needs to be some fundamental discussions about the use of the Reference Architecture and the Reference Model in the real world. Based on what I found out, as an outsider, there seems to be an impedance mismatch between the way the architecture and model is defined and what’s currently going on in the world of SOA. I’m assuming that will “self correct” over time.

It’s unclear as to how all of this reaches up into the domain of the Enterprise Architecture…perhaps not as a replacement, but an augmentation. If so, how do we approach that considering the other frameworks employed?

Like many written standards, the approach is somewhat confusing. Not that the standard itself is bad. I don’t think that’s the case; but it’s difficult for those tasked with building a SOA to see how it will mesh with their current architecture and their current thinking. Over the years I’ve found that to be as important as good concepts.

Once again, NASA JPL’s Jeffrey A. Estefan assist with fact checking this post.