Middleware Matters

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.