Services are the building blocks of SOA, and like building blocks of a house or a building, the quality will define the value of the finished product. In this case, the SOA itself. Thus, spending...

I've seen a lot of activity in the past few months around SOA standards. There’s a joke that goes: "The great thing about standards is that there are so many to choose from". So let's review some of the recent SOA activity.

• August – Open SOA Collaboration group is formed to advance work on SCA and SDO

• October – OASIS Reference Model for SOA approved

• December – OMG begins work on UML Profile and Metamodel for Services

So what's an architect to do? Notice that I am specifically NOT talking about Webs services standards (WS* etc.) which have their own dizzying set of events. I make a distinct difference between SOA and Web services. First, although web services are a useful technology for implementing services, they are not the only technology, and many SOAs have been built without them. Secondly, Web services tell us how to build services (the S of SOA), but SOA is also about the architecture (the A) of building applications and processes across enterprise and organizational units that are composed from multiple types of services. But I digress…

As an architect, we often talk about three types of architecture; Conceptual, Logical and Physical. Sometimes we associate the Conceptual Architecture with the business, Logical Architecture with application design, and Physical Architecture with technology. However, if we do this, we are confusing two very different concepts; viewpoints and abstraction. Enterprise Architecture is divided into several different viewpoints, typically: Business, Information, Application and Technology. These are different perspectives, or views, or ways of organizing architecture around a particular subject area or skill set. Instead, conceptual, logical and physical are different levels of abstraction that describe the amount of detail in a model. We can in fact apply these levels of abstraction to any of the traditional EA perspectives, so for example, we can have a conceptual application architecture, a logical application architecture and a physical application architecture. But I digress again…In any event, it occurs to me that this classification of abstraction is a good way to make sense of the different standards activities.

OASIS Reference Architecture

Let's start with the OASIS Reference Model for Service Oriented Architecture v1.0. The reference model document 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: unifying concepts and concrete details.

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 & Policy. A concept map lists the main concepts and more detailed maps introduce additional sets of concepts for each of the main concepts. The document is right up front 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.

How about the concrete details? There are none. The model is a set of concepts taken to a high level of abstraction. A good set of concepts at that, but I think most people will not know what to do with this reference model. It’s really too bad that the good concepts gets lost in the high level of abstraction because it’s an important problem that OASIS is trying to solve. But you have to start somewhere, so I applaud their initial efforts and look forward to a revised version of the reference model in the not too distant future.

OMG UML Profile and MetaModel for Services

The Object Management Group (OMG) has recently begun work on a Profile and MetaModel for Services. The RFP states: "What is needed is a standard for modeling services that raises the abstraction above the variability in the platforms, enables SOA concepts to be deployed on existing platforms, and provides business integration and interchange to be addressed at the architectural level…The profile will define extensions for modeling and integrating services within and across business enterprises including facilities for formal specification of service contracts…

Service modeling extend component based modeling with additional capabilities to address the effect of integration across ownership boundaries. This introduces the need to explicitly address contracts that formalize the expected interaction between service consumers and providers without coupling them to particular platforms or implementations that would inhibit business agility."

These certainly sound like laudable goals to me as an architect, and ones that fit an enterprise wide, architecturally focused definition of SOA. They also fit within the OMG’s emphasis on formal modeling and integration of IT artifacts through compatible metamodels. As part of this standardization effort, the OMG will define a formal MOF metamodels to describe services, their interface and contracts, their implementation, and their traceability back to business requirements. Then, they will define a UML Profile that allows those concepts to be used within a UML modeling environment. Of course, the OMG process will take a while. Initial submissions are not due until June of 2007, but its good to see someone addressing domain specific modeling for SOA.

In the second half of this series, we’ll look at the OpenSOA Collaboration and show how these different standards activities tie together.

Mike Rosen is Chief Technical Officer at Azora Technologies, which provides products and services for SOA, integration and enterprise architecture. His current emphasis is on the implementation of agile, flexible SOA applications that support EA and BPM. He has years of experience in the architecture and design of applications for global corporations and 20+ years of product development experience for distributed technologies.

About Mike Rosen's Training Course.

Back to Articles, including SOA, BPM & BA