For some time now I’ve been writing relatively cautionary entries on service-orientation. Speculating whether it is really anything new, or is just another communication scheme not unlike RPC, DCOM, RMI and others before. It seems that Grady Booch is of a similar mind, suggesting that SOA is not the be-all-and-end-all of architectures, and that it may not be an architecture at all.

In a couple weeks I’m giving the keynote at the Heartland Developer’s Conference in Des Moines. I’ll be talking about service-orientation from a historical perspective. How does it relate and compare to procedural, object-oriented and component-based schemes, as well as client/server and n-tier. In putting together the presentation, I had to formalize a lot of my thoughts on the topic, and the more I’ve considered it, the more skeptical I have become that service-orientation or SOA is a tangibly new thing.

If it is tangibly new, then it is a new way of thinking or conceptualizing the problem space, not a new technology solution. Web services, SOAP, XML and related technologies are merely incrementally new twists on very old ideas. In and of themselves they offer nothing terribly new from an architecture perspective.

But SOA itself isn’t about technology. It is about a new way of modeling reality. It is very data-centric and thus is diametrically opposed to object-orientation. It is much more similar to the older procedural world-view, where data is passive and procedures are the only active entities in a system.

But it isn’t really procedural either, at least not in a traditional sense. This is because procedural design has an underlying assumption that procedure calls are virtually free. In an SO model, service calls have very high overhead – or at least we must assume they do, because that is one possible (and likely) deployment scenario.

Ultimately SO appears to be procedural programming, with the addition of high overhead per call (thus forcing serious granularity changes in design) and dynamic negotiation of the communication semantics (protocol, orthogonal services, etc.) – though there’s no real implementation yet of this dynamic negotiation… And even that isn’t really an architecture thing as much as technological coolness.

So in the end, SO is procedural programming redux, with the caveat that the procedures are very expensive and should be called rarely. Kinda boring in that light…

Or, as I’ll say in my keynote, SO could be emergent (as defined here and here). It could be that the new combination of old concepts and simpler ideas combine to make something new and unexpected. Something that isn’t obvious. Much the same way the simple moves of individual chess pieces combine to create a highly sophisticated whole. The end result is certainly not obvious based on the simplicity of the core rules. And if SO is emergent, then it is far from boring!!

Only time will tell. The next decade will be quite interesting in this regard.