SOA Debate continues

 Benjamin shares with us his views on the great debate about what is a service. So the question is, what can be considered a service and what can’t be? Several proposals for a correct definition are worthwhile commenting:

·         A service is a program that you can communicate with using messages – Don Box
While I highly respect Don for his views, this just doesn’t get anywhere to give a definition. First, a service is not necessarily a program. What is a program? What is considered a program in that definition? Is it any kind of software? Isn’t a webform control a service, in the sense it is using the message pump to do a lot of things?

·         The 'service' is, IMHO, the combination of a definition of the semantics offered by the service, a definition of an end-point at which the service can be found, a definition of the protocol by which the service is invoked, and, somewhere behind all that, something that can implement all those promises. – Matthew Adams
I agree with Benjamin, this definition while absolutely semantically valid, would cover any software written for the last 20 years. We have a definition of the semantics, data structures and APIs, we have a definition of an end-point through the win32 api giving us the memory location of an entry point in a dll, the protocol used can be thought of the calling convention (processor specific). Win32 has been delivering these for a long time, and would the world be highly connected in a highly distributed way, that could be, or could have been, extended to replace all these memory allocations and calling conventions across the network (I’ll blog about the Ring# project that was funded a few years ago on a distributed c# like language for peer 2 peer addressing of “spaces”). This definition is a good way to ask the question, but it doesn’t give any answer.

·         When I visualize SOA, I see a bunch of services which are always listening.  The user can wire up those services at run time and different hostings of that service can have diffent policies.  The services can be called over a queue, tcp, HTTP etc.  Eventually, you can even discover the service using WS-Discovery at runtime using UDDI or some other advanced repository. – Allthings.net
Ok we’re getting closer there, at least closer to my own definition.

What is a service, and in what context we think about a service is the point that must be understood. I do agree that a Message Oriented Architecture and a Service Oriented Architecture are two different beasts altogether. But we must also recognize that the bright minds are absolutely and completely blurring the two with web services, and for one reason: Message Oriented Architecture is one of the best ways to deliver a Service Oriented Architecture. Let’s separate for a second the qualities of each of these architectures.

Message Oriented Architecture

A message-oriented architecture imply that communication can be done asynchronously through a message based communication protocol. Let me put it clearly:

• Asynchronous
• Message based

That’s absolutely as far as it goes. The people still dealing with old technologies knows it. We use a message queue on one side, and get the other side to process the data from the queue. It is asynchronous and is scalable, and we love it. Seeing my queue growing and getting smaller even have some kind of an erotic appeals, late at nights. But now no one said I was normal either.

 

Service Oriented Architecture

A service oriented architecture relies on services. Well sometimes you have to state the obvious. What is a service? By definition, a service is any piece of software that provides a service to you, without you knowing anything about how it provides it. Actually, without you knowing how it does it. If you do you’ll always get a higher salary. Anyway.

The other thing we can say about services is that they are independent bricks that can work on their own. A service is a logical cut of functionality that only relies on itself to ensure proper communication with its users. If not, it definitely is a bug.

The service itself is autonomous, both on the way it works, but also on the way you communicate with him. The definition is that a service needs a contract you have to agree upon to communicate. This contract is the protocol you’re using.

A service can also be called synchronously or asynchronously, and that’s to be agreed upon. It’s a behavior contract you need to have with the service to use it properly.

This definition in itself can cover nearly every single piece of reusable software code. To match the blurry definitions, you have to add a few ingredients:

 

• The protocol contract must not be tied to the service itself and must be a general system, defined outside of the scope of the processing being executed by the service. The rationale being that if your service is to be adopted, you must be able to communicate with it without having to adopt a certain network protocol or a certain encoding scheme which is service specific. That’s a waste of time and kills interoperability.
• The behavior contract must not be tied to a technology, and must not require you to obtain any kind of source code anywhere. It must also not rely on a specific object technology to be able to be reused anywhere without any form of so called distribution of objects. Two reasons, the world is not everywhere about objects, objects sucks outside of your process, and not everybody’s using C# (I know these are very controversial, and some people might unsubscribe, but I had to say it.)
• The independent brick must be accessible through networks, in memory or across process in a transparent way.

 

So how, from this definition, does MOA fits? It answers all three requirements:

• A Message only relies on itself, and is not tied to the protocol doing the transport.
• A Message being used to communicate follows a message exchange pattern that can be defined in an abstract way, without relying on code.
• A Message is a self contained independent entity.

 

The last question, which conveniently is the last piece needed to get to our current definition of SOA, is how in hell do you define all these three components in a standard way…

The XML Infoset – The inside

The XML Infoset is not about how you format your messages, but how do you represent in an abstract way your document. The square brackets are just one of the possible serializations of this Infoset. The Infoset itself can then be transparently converted between all the different serializations by only changing the formatting, and preserving the semantics.

With this data model, that is defined with an XSD document to provide rich semantics to a document (rules about what an Infoset is and what it can contain), you can achieve our first goal, that the message is self contained and independent on the transport or on the format.

SOAP – The Outside

Soap is an encapsulation mechanism for a processing unit. It contains a body with an Infoset, and an extensible way to add contextual information to our infoset, be it in a request / response, push / pull, publish / subscribe system. It ties the Infoset with the next brick, the behavior contract, by providing, again, a protocol and format independent way to add anything behavior related, in a call context. This call context is a sort of sphere that flows through all your services with your message, a bit like dolphins follows boats when they cross different seas.

The call context followers – The dolphins

This is everything related to, and necessary and / or mandatory for the message based communication to happen while responding to our behavior contract. This is where you add the information, the instance data, of everything you defined in your out of band definition files (WSDL, WS-Policy to some extent, UDDI).

 

My definition of SOA

My definition of SOA would be: “Any protocol independent processing unit that can be talked to without relying on knowledge of the specifics of the conditions of execution of the unit, through an agreed behavioral contract, and that can be used without relying on anything outside of that unit, in an asynchronous manner. PS: If it could be messaged based as well that’s always a plus”.

 

An other definition which could also be valid would be the following: “Any processing unit that can be communicated with using abstract representations not tied to any specific technology.” I’m not fond of it, but it makes you look smart with some people. Please don’t try this at home.

 

Now if you followed my position on what SOA is all about, the difference between an RPC style and a Message style SOA (as long as we’re talking about proper xsd use for the RPC mechanism, not outdated on crack formatting of type information at the container level) is how clean the message pattern and behavioral contract is designed.

 

The good thing is that architects still have a few years before being put out of jobs. J

The bad thing is that Whitehorse and Indigo might just kill us again.