Middleware Matters

Don's already mentioned it, but my July/August Internet Computing (IC) column is now available, either as PDF or on the Distributed Systems Online site. This column covers Java Business Integration (JBI, aka JSR 208).

In the context of JBI, Don asks about containers. My take is that containers aren't as special as we'd like to think they are. A container really just supports a particular programming model or style. Some do this by forcing certain inheritance structures, others do it by providing particular service APIs, still others state via some sort of contract what they expect of things that they contain. Most use a combination of these approaches. A good container handles the tedious or error-prone details of a particular approach, letting developers focus on their business logic. Containers have been around for decades and won't disappear anytime soon. Writing good containers is pretty hard. Therefore, rather than seeking the "one true container," we should allow for and support container diversity. In fact, isn't that what the web services approach helps with, given that it focuses on the message rather than imposing rules for how applications that handle such messages must be built?

Don takes issue with my opinion on his container question. Ironically, I think Don's objections prove my point, which is that trying to write that one all-singing all-dancing container is futile. You end up with a monolithic beast that tries to be all things to all applications, but instead ends up serving none of them very well.

Much of my middleware work over the past dozen years has revolved around interceptor-based architectures. In this approach, a container is really just another interceptor, or a set of composable interceptors. Breaking container functionality down into orthogonal capabilities that can be composed as needed can address the "management, configuration, deployment, health monitoring, and process model" issues that Don mentions, without requiring yet another monolithic container. This is one reason why, at the end of my most recent column, I slightly dinged the JBI spec for not including an interceptor-based architecture from day one.

My advice is to keep your containers lightweight and composable so that providing different containers for different application styles need not be as cumbersome and costly as Don implies.

A friend of mine works for a large company who has a pretty successful in-house large-scale SOA deployed in production. He emailed me and asked whether I knew of other folks who have deployed large-scale SOAs in production, so he could find others with whom he could compare notes and such, but the only ones I know of are those of our customers, and NDAs prevent me from talking about those without permission.

So, anybody out there who has a large-scale SOA in production want to compare notes with my friend? If so, contact me directly and I'll pass you along to my friend.