The theory of SOA - Part 1 - Intro

May 8th, 2006, 17:40.

I’ve read a lot about Service Oriented Architecture (SOA). I’m still not clear on some of the concepts that should be followed if one wishes to say that they are doing SOA. In this series of articles I aim to explain what SOA is all about and then moving on to some concrete examples of how working with SOA baffles me.

To put it short, SOA is a design approach which is aimed at achieving loose coupling between interacting software components. There are two important design limitations which are imposed:

• employing a set of transparent interfaces acceptable for all of the components
• using these interfaces to transport minimal and descriptive messages described by an extensable schema

But what exactly does this mean and how does it work in real life?

Technorati Tags: soa, service oriented architecture, design, programming, technology, theory

Transparent interfaces

The requirements for the interfaces, as imposed by SOA are that an interface must be acceptable for all components, and ideally it should also be transparent.

The acceptability means that all given components are able to communicate using this interface. In most applications it is either HTTP, an implementation of the Java Message Service, or some other messaging system with a large number of implementations available for various platforms.

Transparency is the property of an interface which is easily examinable. In the case of HTTP, this becomes trivial: any proxy based listening solution, or even a general purpose network traffic analyzer will do the job. With complicated interfaces the tools themselves become more complicated such as in the case of JMS. JMS protocol analyzers can be complex beasts whith debugging features, message editing and resending support, recording and playback and various other features.

Messages

The minimalistic, descriptive messages are one of the keyes of SOA. What does this mean? Minimalistic means that the messages should contain as much information to be useful for end-systems, but should not contain more than that ammount of information. Descriptive, opposed to instructive messages are those which publish a certain event, rather than a precise instruction. For instance, a message publishing an event such as “new user has been created” is considered descriptive, while a message publishing a command such as “create a new user” is considered instructive.
For a message to be really useful, it needs to be understandable by all end-systems. This means that a common language needs to be established. XML lends itself naturally to this task, along with the document grammar described by one of the utility languages: DTD, XML Schema or Relax NG. It helps to study those technologies, particularly if you are planning to do much work with SOA. Take care, though: DTD is in the process of being phazed out. XML Schema is the current stuff, and Relax NG represents a future technology with space for potential growth.
With this, I’d like to conclude the first part of the theory of SOA article. I hope I’ve shed some light on the issue, as well as interested you in reading the following articles where I hope to describe some situations which confused me!

Permalink.

Leave a Reply