Bick Group

David Linthicum

Subscribe to David Linthicum: eMailAlertsEmail Alerts
Get David Linthicum: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: SOA Best Practices Digest, SOA & WOA Magazine

Article

Understanding SOA Architectures and Models - Part 1

The SOA reference model PART1

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)
And how all of this works and plays with
  • Enterprise Architecture
I spent a few hours of my weekend attempting to research and define these concepts a bit better, in essence, taking everyone's opinions and normalizing them so they make better sense. What I found were many of the same notions, defined differently, but all attempting to solve the same problems. Seems to be a common theme within the world of SOA, but I digress.

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.

More Stories By David Linthicum

Dave Linthicum is Sr. VP at Cloud Technology Partners, and an internationally known cloud computing and SOA expert. He is a sought-after consultant, speaker, and blogger. In his career, Dave has formed or enhanced many of the ideas behind modern distributed computing including EAI, B2B Application Integration, and SOA, approaches and technologies in wide use today. In addition, he is the Editor-in-Chief of SYS-CON's Virtualization Journal.

For the last 10 years, he has focused on the technology and strategies around cloud computing, including working with several cloud computing startups. His industry experience includes tenure as CTO and CEO of several successful software and cloud computing companies, and upper-level management positions in Fortune 500 companies. In addition, he was an associate professor of computer science for eight years, and continues to lecture at major technical colleges and universities, including University of Virginia and Arizona State University. He keynotes at many leading technology conferences, and has several well-read columns and blogs. Linthicum has authored 10 books, including the ground-breaking "Enterprise Application Integration" and "B2B Application Integration." You can reach him at david@bluemountainlabs.com. Or follow him on Twitter. Or view his profile on LinkedIn.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.