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.
SerialSeb