Steve just replied to my initial RFC (request for clues) over
on his blog.
I found Steve's opening sentence pretty compelling: My take is that containers aren't as special as we'd like to think they are.
And as for Steve's comments about web services being about supporting diversity in runtimes, amen brother.
Where Steve lost me was when he made the leap from protocol-based integration to the assumption that a given runtime platform (in this case JEE) needs to avoid committing to a single local execution/deployment/management model.
This is counter to my experience over here in Windows-land.
Windows suffered when IIS split from COM in Windows Server 2003 and built a largely duplicative container system.
What we wound up with was two solutions to the "message arrives/context is established/user code gets invoked" problem each with their own approach to management, configuration, deployment, health monitoring, and process models. By the time the product shipped, the differences in functionality between IIS6 and COM+ 1.5 were very minor, even though the details of the implementation were completely different.
We're now spending real $$$ fixing this by investing in a single/unified model called Windows Activation Services or WAS that sits under IIS7, Indigo, and other technologies in need of a container system.
What I don't understand is why the Java community wants to spread its engineering resources across N container models rather than invest in a single general purpose model.
The fact that IBM is sitting this one out means that everyone else in Java-land gets to split their focus across three things, not two (for historical reasons, every JEE vendor already has to support both servlets and ejb).
Yes, the Sonics and Ionas of the world get another chance at becoming the next BEA, but does the Java community at large really benefit all that much from the added surface area?
Posted
Jul 07 2005, 02:19 AM
by
don-box