A Fresh Look at an Old Debate
Once again, discussions about the relative merits of Web Services, SOA, SOAP, REST, and possibly MEST, have come up — and I’ve become so used to it that I’m tempted to feel that everyone must have an opinion on this by now.
This is, of course, totally wrong.
First of all, when a company or organization thinks about adopting SOA — and I’m using this term in the broadest possible way, so broad that it includes all of the approaches mentioned above - the real problems, those that really matter, have got nothing to do with technology. I’ll address this in more detail in another post; suffice it to say, for now, that the willingness to open up closed applications, co-operate with partners in a much more open way, accepting to be measured by the actual business services one provides, and de-coupling monolithic organizational structures poses a multitude of challenges that are much more business-related and social than technical. So for a lot of people it’s much more important to address those issues than care about details, such as the actual software architecture they’ll use in the end.
But even if we talk about technology only, the REST-vs.-SOA debate is not one that everyone is tired of. On the contrary, I’ve talked about SOA to a lot of customers, partners and friends in the last few months, and it’s fact that most of them don’t even know what REST is, let alone are aware that there might be disagreement on a fundamental level in the Web services space. It seems that when you start spending too much time in the blogosphere and 90% of the blogs you read talk about the same thing, citing and reciting and agreeing and disagreeing with each other in much the same way all the time, it’s easy to mistake this group for something representative of the general public.
So I thought it might make sense to address this topic in a way that’s
a little different from what I usually read: Instead of writing for
readers with intimate knowledge of the technologies, I’ll try to
explain my (rather personal) view on the state of the service world in
terms that are understandable for developers, software architects, and
IT managers who are reasonably up-to-date with the way software is
built, but have not yet wasted way too much of their
lives invested the time to study the relevant specs and
standards.
My plan is to roughly stick to the following structure:
- Overview
- RPC-style web services
- Message-oriented web services
- REST
- Contracts and programming models
- The great reunion
In true weblogging style, I post this now without having any idea when I’ll get around to actually doing it — nothing like putting a little pressure on oneself …