I have been in this field since the early days of Java and I have witness the birth and decline of the J2EE paradigm. The Java mantra's Write Once Run Anywhere has been effectively re-termed in J2EE as Write Once, Modify A Bit, Run Anywhere. What is the cause if this bloody mess? In a consulting company, contrasted to in-house non-consulting development teams, people are forced to tests the compatibility between J2EE containers and their effect to the biz codes. It has been a pain to develop your code in one AppServer only to find out that some things will have to be rewritten, reconfigured or remodelled because the other AppServer behaves differently. Again, back to the question, what is the cause of this bloody mess? The answer: PROPRIETARY code. Every commercial J2EE providers aims to outgun the other. In here, I am talking about the to Web* app servers: BEA's WebLogic and IBM's WebSphere. It is just a bloody mess. Whether you conform to standards, conventions and to the specifications; one way or another, you are going to tweak something. WebLogic and WebSphere contains all sorts of proprietary extensions and "alternatives". Why the heck these guys care to deviate with the specifications? Are they scheming to convert all people to use their proprietary stuff then later on dictate their own specifications, contrary to the noble cause of J2EE. If these commercial butheads wants an extension or deviation to the standard, can't they just release is as a patch? As a plugin? Don't these people know anything about how things should work according to the specifications and how things should deviate. Here's my suggestion, use the decorator and or factory design pattern or use something else. Just don't screw people's time by wantonly allowing these to happen.
BEA and IBM really screwed up J2EE. If you really want to stick to J2EE, use open source. You have GlassFish, you have Geronimo, you have Jonas, you have (arrgghhh!) JBoss. Beware of JBoss, it might treading to the dark side like IBM and BEA did. The moral of the story is PATIENCE. If your organization decided to use either of the proprietary AppServers and decide to move later, be prepared to open multiple can of worms.
Just a viewpoint from Luke.
Subscribe to:
Post Comments (Atom)
4 comments:
Ok - I have to comment here.
Firstly - noone is forcing you to use proprietary extensions. You can choose to use them or choose not.
Secondly - it is Sun's attitude towards J2EE that has led to this. The lack of some APIs in the spec (security / user management comes to mind) means that other vendors have to create extensions to give users functionality.
Thirdly - open source application servers have proprietary extensions also. JBoss is constantly trying to get its users to use non-standard extensions. JBoss wants user lock-in as much as every other application server vendor.
I've written applications (JIRA, Confluence) that run on many application servers (Orion, Resin, Pramati, Tomcat, Jetty, oc4j, Websphere, Weblogic, Sun ONE) without any changes. I've also worked on cross-platform components (Sitemesh, OSUser, Webwork). You do not have to use any extensions to get your application to work.
Perfectly correct.
If I really had the chance and the power to decide what to use and what not to use, I'd prefer to stick the basic and standard elements, moreso, play around with free and open source. The latter is more of a personal preference rather than a possible commercial strategy.
Sun also has something to do with this. Their inaction and adamant stand pushes commercial providers with their own extensions. But even if Sun was a bit more accomodating, vendors (including the heralded JBoss) will still push their own agenda.
er... can you say "spring framework" ?
hehehe. only if I have the deciding power..., I would go light. open source Java EE container plus an IoC container (e.g. Pico, Hivemind or Spring).
Post a Comment