The J2EE Diaries
My journey into the depths of hell running J2EE applications on multiple application servers.

Friday, March 01, 2002  

Ok - finally I've had enough of people saying that J2EE applications are portable. Let's talk about it.

If you're using vanilla session beans with no user authentication or authorisation, no CMP entity beans and a basic web application - yes, it's maybe going to be portable. This is before you run into non-specification compliant J2EE servers.

In reality, this just doesn't cut the mustard. EARs are not portable without a lot of work.

Want proof? Pick up your EAR and try to deploy it on another server - go on, I dare you! See? Didn't work did it? No.

So what are the porting issues? Well this is what I'm trying to document in this forum.

Why should I comment? Well I've spent the last 2 weeks solidly trying to get our first J2EE product running on Orion, JBoss and Weblogic and my experiences will be valuable for the J2EE community at large.

Most people say that if you stay away from vendor specific APIs you'll be OK, but it's actually a lot more complex than that.

Here are the issues we've faced so far:

  • User management, authentication and authorisation - Want to manage users from within your application? Modifying users and groups, authenticating and authorising users are tasks that most J2EE applications need to do. Every server currently has it's own user management API and as soon as you touch that - your porting efforts are finished. What the J2EE community needs is a generic user API that can plugin to every server. We're using OSUser to achieve this at the moment but it requires a lot of work to get providers and adapters for many other servers.

  • Deployment descriptors - Do orion-application.xml, jboss.xml, weblogic-rdbms.xml, jaws.xml sound familiar? If you've ever written or edited one of these you've also waded into the porting danger zone that keeps J2EE application developers up late nights. The specification itself allows for separate development and deployment roles - which is fine - but it means that we need vendor specific deployment descriptors. This is where XDoclet came to our rescue - by adding simple JavaDoc tags to our entity beans, it will automatically generate descriptors for Orion, JBoss, Weblogic and a gaggle of other servers. (Oh, and did I mention it generates home and remote interfaces for you too? Neat!).

  • Container Managed Persistence - CMP entity beans are beautiful but deadly - they attract developers with their simplicity and ease of use but strangle them with vendor specific management. EJB 2.0 will solve a lot of the 1.1 CMP problems, but it will be at least 6 months before most of the application servers support EJB 2.0 fully. I could write entire books on CMP and the new features it needs (such as table autocreation and modification, size limited finders etc) but right now that's not much use to us. We're currently evaluating replacing our CMP 1.1 entity persistence layer with the entity engine from the OFBiz project - I'll let you know how it goes.

Sometimes applications (especially internal ones) only need to run on a particular server - which is fantastic because then you can use vendor specific features without feeling guilty. However if you're building J2EE applications or components to sell to other developers, or to deploy on multiple servers - these issues are probably very important to you. In the future I'll write in more detail about the different issues we faced, and how we solved them.

Have you had these or other issues? How did you solve them? Write me.

posted by grok | 5:29 PM