Does J2EE Live Up To Its Promise? 18
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?"
In some ways... (Score:3)
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....
Re:Pick and choose (Score:1)
The only thing I do tend to stay away from is container-managed persistance. In dealing with relational databases, sometimes the table structure is a little more complicated than a simple table-to-bean like a lot of the current AppServers are set up to handle. (Even the Raefel-Monson book has pretty simplified business scenarios)
Some of the newer app servers seem to be incorporating more complicated container managed queries, etc.
Portability, Logical Design & Portability (Score:1)
At the end of the day your only going to use the 'Enterprise' stuff if your running multiple application servers, which some people do and the choice of application server is important there. ASP is still the easiest way to write a dynamic solution (java is a little wordy..) but then basic is the easiest way to write a program etc..
Re:Ask again in a year (Score:1)
The only really bad thing about EJBs is that you lose a lot of object-oriented features by using them. (Like polymorphism, inheritance, etc.) You can get around this with some design tricks (using Entities as 'wrappers', etc.) but it would be nice if I could represent a heirarchy of related EJB "objects". (Usually, I've used EJBs as very course-grained objects..)
CLASSPATH nightmares! (Score:1)
I have also got java to run quite nively on my Palm with WABA, even though the code is not portable.
The biggest pain I have found with java is classpath files. Vendors just will not aggree on a common directory for Java classes. On my NT box I have nearly 20 directories and Jar files in my CLASSPATH.
JAR files are particulary annoying as most JVMs will only recognise a JAR file if it specifically included in the CLASSPATH, so what should have been a neat idea for packaging sets of classes, becomes a configuration nightmare.
Why can't we just have one root directory and have the JVM search everything (including jar files).
Portability. (Score:1)
J2EE is nice - certainly an improvement over traditional languages. I'm still nervous about the overhead of the jvm, but I haven't found anywhere where it's been a real problem.
Regarding portability, we once had a piece of middleware that was a bit of a resource hog and it needed to be moved around a lot. We moved it at various stages between NT, 2k, Solaris and Linux with no changes required or problems whatsoever. Very impressive.
FWIW I'm liking the XML/XSLT more and more. JSP is sooo '99 ;-).
Re:Pick and choose (Score:1)
Some app server vendors advise against this pure approach, and the resulting methodology ends up looking a lot like session beans anyway.
I prefer to use session beans to query the database and create lighter-weight, serializable objects encapsulating database state, (e.g. application specific objects or beans, or Maps). Then, instead of accessing entity beans remotely (using more bandwidth), I just pass the objects where needed. Having access to objects passed by value can save lots of round-trips to get data remotely.
Yes, I've ported w/out problems. (Score:1)
But seriously, I did copy the [Java classes] files over to my Linux laptop and was able to get the system up and running just fine. The only porting problems were file paths in config files (unrelated to Java, which doesn't care about forward-vs-backward slashes) and the registration of servlets (which was a major pain).
Re:CLASSPATH nightmares! (Score:1)
Pick and choose (Score:2)
- 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.
Re:Pick and choose (Score:1)
There are also plenty of times where you need to do something as simple as "get a list", where our teams have just accessed the database 'directly' (through a connection pool) as it were...
Yes - J2EE is outstanding, but watch your step (Score:1)
In terms of portability across app servers, most of your problems will be with deployment descriptors (the XML files) and entity bean finder methods. The representation of this data has not been standardized. EJB 2.0 spec will fix this.
I second the comments about entity bean to DB tables - it's difficult to express any but the simplest object-relational mappings. Again, EJB 2.0 promises to fix this and add a lot more, such as mapping Entity beans to arbitrary data sources (LDAP, anyone?)
Ask again in a year (Score:2)
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.
Java Network Programming *almost* rocks... (Score:3)
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
Re:Pick and choose (Score:2)
Re:Java Network Programming *almost* rocks... (Score:1)
http://java.sun.com/aboutJava/communityprocess/
Re:Yes, I've ported w/out problems. (Score:1)
Re:Pick and choose (Score:1)
If you have one middle-tier JVM and the EJBs and all JSPs and servlets and session beans live in it, then entity beans aren't that bad.
But the same problems creep in again when you have multiple JVMs in the middle tier, e.g. with clustering. You might have a servlet communicating with lots of entity beans in different JVM located on different boxes.