Slashdot Mirror
Does J2EE Live Up To Its Promise?
Rayooz asks: "With all the hype around the J2EE specification, I'm wondering if it truly lives up to its promise of "server independence" in the real world. Has anyone had experience developing/deploying a J2EE application on one application server and then moving it to another server without any modification?"
When Sun released the J2EE along with all of the various specifications (i.e. the EJB spec), it was largely left up to the vendors as to *how* those specifications were met.
Business code is largely portable across vendor products, as long as you follow the specifications yourself. That is, keep your naming standards consistent with Java RMI, etc. I have seen a lot of cases where a developer tried to be "clever" and screwed themselves in the end. Good design saves the day.
Vendor-specific protocols are typically implemented during deployments, etc. For example, the Inprise Application Server has an Inprise-Specific XML descriptor file that specifies the JNDI names for object naming. Not a big deal, but a slight headache nonetheless.
If you choose the same application server across different platforms (ex. IAS running on NT, Linux, and Solaris), you should have no problems with code portability whatsoever. (Again, as long as you avoid platform-specific bugaboos)
In the end, here's the deal: Do not jump into writing server systems in Java if platform independence is your only goal. Use Java if you are willing to invest the time in designing and developing a clean, object-oriented middle tier that is understandable and flexible. If you can accomplish this, platform independence is a great secondary feature. Java also contains many features that are great for quickly developing complicated systems. (Java Network Programming *rocks*)
If you just want to slap code together and gripe when it doesn't deploy on FooBar app server, just give up and start writing your whole transactional system in Python. Enjoy maintaining *that* system for a few years....
- Entity beans should probably be avoided. Stick with session beans.
- Stateful session beans should probably be avoided. Stick with stateless if possible.
- Given the above, I wouldn't even consider
container-managed persistence.
With these guidelines, it is quite simple to write fast, portable 3-tier applications. The tool situation is also rapidly improving.So, to answer the question, yes, J2EE has lived up to it's promise. I can't imagine doing any serious (maintainable!) middle-tier work in alternatives such as Perl, PHP, etc. It's reached critical mass, having lots of serious, deployed applications, good and improving tool support, and lots of developers who know J2EE and the products supporting it.
I've been doing a lot of research in J2EE adoption at work. My colleagues and I have spoken to dozens of people, and what we've found is this:
Many large companies started getting into server-side Java about a year and half ago, primarily using servlets and helper classes. At the time, the app servers weren't very mature so most companies wrote their own app servers (or hired consultants to do so). Now that app servers have matured, they're currently re-writing the existing systems to work with a commercial app server so that they need only worry about the business logic, and that they can take advantage of the J2EE spec.
Very few companies are using EJBs yet -- the level of J2EE adoption seems to stop at servlets. That's partly because of using homegrown servers, and partly because many companies are waiting for app server EJB-support to fully mature. Most are looking to migrate into EJBs within a year.
Finally, the majority of companies seem to be in the development/test stage for their server-side Java apps. They aren't looking to deploy for another month or two, and they may not be in full scale production for 6 months.
So basically, while many have bought into the J2EE hype already, very few are really using the full spec, although they plan to get into that in about a year. At that point, you'll probably start hearing a lot more about how well (or how poorly) J2EE has lived up to its hype.
I can spell. I just can't type.
(Java Network Programming *rocks*)
Not quite. With things like CORBA and RMI, it's very good. But if you're talking sockets there are some serious problems.
Fundamentally, Java I/O is very limited -- and intentionally so -- by the need for 2 threads to handle bi-directional communication. This is of course because of a lack of asynchronous I/O support. Add the lack of support for multiplexing I/O and you're basically screwed.
Just *try* writing a server in Java that can handle 100,000 simultaneous connections. 200,000 threads is going to break pretty much any server. Yeah, you can resort to clustering and have your servers communicate but that adds a *lot* of complexity in some instances.
A chat server with featues like rooms and private messages and all those goodies that can handle tens of thousands of simultaneous connections on a single machine would be relatively simple to write if one had multiplexing and asynchronous I/O. But without it you have to add your clustering system and implement things like message routing/forwarding and all other sorts of ickiness.
But for simpler stuff, Java makes network programming VERY simple and straight-forward unlike other languages -- and that's a VERY good thing.
-JF
MrJoy.com -- Because coding is FUN!