I’ve been to dozens of SOA lectures, presentations and conferences and though I considered some (the first ones) to be very interesting as I approached the subject, it soon started to get a bit boring as I easily could anticipate what the presenters were going to say: why adopt SOA, how will your company benefit from SOA, the possibilities SOA gives you, etc. etc. 
It’s fair to say that there is a lot of confusion and false expertise in this area and often these conferences are more a PR and sales show rather than a valid review of what SOA really is.
But why all this fuzz about SOA?
A SOA expert/sales man once said at a seminar:
‘Don’t ask yourself if you need SOA, you already have it!’.
At first I thought it was funny as it sounded more like some kind of disease... ‘oh crap! when...!? It must have been that Thai stuff...’.
But then he went on saying that SOA is a brand new (fantastic of course) technology... but...wait a moment... how can it be a new technology if I already have it? Am I a pioneer?
What on the spot seemed an exaggerated way to express his excitement about SOA was probably a smart way to sell SOA to the mass of CIOs attending the conference.
Is there a better way to make you buy something than saying you already have it? Don’t ask yourself if you want it, you or someone for you already made that choice, so just keep on following the (right) path...
But he was indeed right to some extent. Some aspects of SOA are commonly accepted and adopted and some parts of SOA are new.
At the same time it’s a bit like saying that just because I name something that had no specific name I created it, it doesn’t really work that way.
Vague, undocumented and double or triple meaning definitions are not uncommon to the IT world but I must say that SOA beats them all. If there is a commonly accepted definition I haven’t found it yet, the ones I have encountered so far not only differ on what SOA is but they do it on so many different levels of abstraction that it is indeed difficult to get a good picture of what SOA stands for.
Some people speak of SOA from a technical point of view, web services, SOAP, REST, etc, others see SOA as a set of techniques that work together in order to create a better alignment between business and technique.
To try to answer what SOA is we should perhaps first answer what SOA is not. Let’s say SOA is services, we all agree on that, by definition. Let’s say then that you have a class with a method for adding 2 numbers, is that a service? Well, yes. Is that SOA? Well, no. It’s a service since it can be used by consumers but the restriction is that these consumers must be something in the same domain, say the programming language the class is written in, or even more specific, the same logical application. This is the traditional way of writing services, nothing revolutionary there, we’ve been doing it for a long time now.
Then maybe that’s why web services are such an integral part of SOA.. If we build a web service exposing that method would we have SOA then. Well, no, or yes according to some. Now I can call my service from any other application outside the original domain, that sounds indeed like some kind of SOA, but is that it?
I could have done that using JMS, RMI or any other communication technology, so do web services automatically give me SOA? No, in fact you can and you often do have SOA without web services.
A key to understanding SOA is probably the distinction between services and Business Services.
A service is, as said before, just something doing something. A Business Service is a service that is relevant to the business we are running and therefore creates some kind of added-value for the organization.
But how do I know if a service is a Business Service? Well, if your development department created it without consulting your business then it’s probably not a Business Service. In order to create a Business Service you need to know what your business requires and this has to be done in cooperation with the business itself. Of course you can try to create what you think is a good Business Service, and you probably will succeed to some extent, but that’s in my eyes not the way to go.
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
