Middleware Matters

Grady Booch talks about SOA: "Snake Oil-oriented Architecture." :-) Well worth the read. Here's my favorite paragraph:

"Having said that, there follow a multitude of hard technical and process decisions that must be made, which the Snake Oil-oriented Architecture showmen often neglect to tell you about: what distinguishes a good service from a bad one? what should the granularity of a service be? when should I offer up a stateless service versus a stateful one? as for the stateful ones, how to [sic] I express their semantics, and how do I ensure their their [sic] misuse doesn't corrupt my system? how do I express the semantics of a society of services (only the most trivial services work in isolation)? how do I decide upon the semantics of the information transmitted by these services so that locally they are efficient and useful but that also globally they are consistent? how do I expose some services to some clients and hide them from others? how do I offer up variants on a service, so that different clients see a different face to that service? how do I ensure the security of critical services, such that I am confident I'm not opening up holes in my enterprise that will let the bad guys in? what services should I expose to the world, and what services should I keep hidden? where are services appropriate, and where are they not? how do I best expose services in a legacy system? who should own/maintain these services? are there alternative architectural patterns I should employ instead of services, and where, and why?"

These are indeed the right questions, and they are hard questions. At the recent JAOO SOA panel, some attendees expressed disappointment afterward essentially because we didn't give them cookbook answers to these questions. Unfortunately, someone speaking to an audience about SOA can give general high-level advice about such things, and that's about it. People seem to want SOA to be a silver bullet design blueprint for solving all these issues, such that they don't even have to think about these questions, but that just ain't gonna happen. I guess that's why I prefer "SOA" to mean "service-oriented approach," as it doesn't directly provide you with an architecture, but instead steers you toward a desirable architecture. But if you want to succeed with a service-oriented system, you eventually have to answer the hard questions that Grady brings up. Like he says, don't let the snake-oil salesmen fool you: there's no easy way around it.