I forget where I saw someone refer to J2EE servers as "mainframes". The brief mention struck me with some humor and some accuracy. I've not thought about it since, and one could argue I'm not thinking at this moment.
Still needing an update on what these things do, and reading through a few topics in some detail, that analogy came back in a flash. There is a deeper truth, while there has been great progress: they support one or more "modern" languages, they include garbage collection, they run on really inexpensive hardware (often clustered rather than a single ginormous piece of iron on a raise floor -- but the power issue is back with a vengance for some), and take a good bit less configuration.
On the other hand, their configuration (typically in XML) is not unlike JCL, they load a lot of various pieces into conceptually a monolith, include various "isolation" mechanisms alongside various clustering/sharing mechanisms. I don't want to take this analogy too far -- it just struck me recently -- and systems like JBoss have interesting designs with its JMX/MBean microkernel.
Not that all of these are necessarily "bad" things. But I do get the sense of a monolith that doesn't necessarily fit the idea of "small pieces loosely joined" even when the ugliest parts (e.g. EJB) are ignored and the better parts (e.g. JMS) are emphasized. Today I would think an organizations evolutionary intentions should be to move away from mainframes.
Should the same be said for J2EE *today*? If not today, then *eventually*? If so then, toward what? I have a lot of ideas about the "eventually* part, and a few about the "today" part.
No comments:
Post a Comment