Service Oriented Snake Oil

I don't like this service oriented direction that the world is taking.

I understand how it promotes REAL reuse. I see the benefits that eBay, Yahoo!, Amazon, and Google are gleaning from the technology. I like how it breaks functionality out of application stovepipes. It gives us a chance to write distributed components that can deal with clients written in Java or .NET or any other language that can be a web service client.

But does it have to be so bloody complicated?

I think corporate enterprise application development is markedly different from the demands placed on those Internet leaders I mentioned.

What is this buying us that we can't get with other technology?

Contract first XML helps some with the problems of brittle interfaces and promotes looser coupling, but it's not perfect.

Can you model the operation of a large financial institution using REST?

Transactions and ACID are the biggest problem that I see. I think services have to live between transaction boundaries. It's taken a long time for databases to be able to help us with managing units of work. I'm not aware of anything analogous for services. Compensating transactions break encapsulation, in my opinion. How long should an idempotent service wait to be sure that a PUT or POST will "stick"?

BPM, BPEL, and ESBs are leading us down the wrong path when it comes to maintaining ACID properties. It's a great marketing ploy to tell business people that they can create complex process flows using graphical tools to drag & drop a suite of available services onto a palate, connect them up using "simple" logic elements for branching and joining, and then deploying the whole thing under the watchful eye of The Bus. But the moment there's more than one transactional service in that flow you'll have to worry about ACID properties. If the first one succeeds and the second one fails you'll have a mess to clean up.

It's great for vendors to be able to offer wizards to make it easy to churn out services. It's no different from any other remoting technology in that sense. If I write a sensible interface and a solid implementation for it, it's easy to see how I can expose that using RMI, EJBs, servlets, SOAP, or any other remoting technology that I like. So what's so special about web services again? What's different this time?

And the real difficulty isn't addressed by the wizards. At its bottom, what we really have here is a design problem. I think part of the reason why REST is still not widely used in corporate enterprise solutions is that it's an architectural style, not a standard. There aren't tools and wizards and cookbooks out there to tell you how to run your enterprise on REST. You have to think about it and slog your way through a hard problem. It might have worked for the Internet, but I'm not Roy Fielding.

I'm spent my second career as a software developer using curly brace languages - first C, then C++, now Java. I'm sorry to say that I'm getting the nagging feeling that this has all become too hard. There's got to be a better, easier, faster way to develop n-tier web applications that deal with relational databases. I love Java and Spring, but it's still too damned hard. It might be time for me to try another language.

Maybe this is why Ruby and Python and PHP are gaining traction.