Kevin, I'm sure folks from some of the other application server vendors will answer with a similar response but here is my experience over the years. Basically, while it is possible to write J2EE applications that are portable between the various containers, the level of "portability" is impacted by a number of factors. Following some basic "lowest common denominators" you can write applications that are portable between the various application servers.
What I've found over the years is that your business logic should be almost completely portable, while the interfaces into the underlying J2EE services will range from completely portable to basically custom. Things are much better today than they were back in 1997 when many of us started down this path. If you stick with stateless session EJBs, servlets and JSPs, JDBC, RMI over IIOP, and JMS you're going to have an application that is very portable between the various J2EE compliant application servers. There may be a few areas that are specific to each application server, such as deployment descriptor formats, but the basic API support will be consistent. The areas of J2EE where you are likely to encounter portability problems are stateful services, especially CMP and entity beans, Java 2 connector services, and "advanced" features such as clustering and administration. Most of the basic interfaces into CMP are consistent across containers but the way those interfaces are implemented can be quite unique from server to server. Advanced features like clustering and administration won't affect your application at the API level, meaning the application can be ported between containers. For example, support for JMX ranges from extensive in some of the application servers to almost non-existent. However, these features are mostly outside the scope of J2EE compatibility and where vendors differentiate their products. The cool thing is it allows you to move between the application servers until you find the one that matches your availability, reliability, and scalability needs, without requiring extensive rewrites. With support for things like extended free downloads, comparing multiple application servers is even easier. I have worked with customers who, for example, develop on one vendor's application server and deploy on a different platform. While this does add significant cost to the development effort - you have to maintain two environments, separate scripting and administration, etc. - it is possible and relatively straightforward to follow this approach if it meets your needs. Let me know if you have any additional questions. Of course, I'd love to see BEA added to your list ;-) but I'm all about seeing J2EE proliferate, even if it is with the other guys. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Kevin Baynes Sent: Saturday, January 08, 2005 3:20 PM To: [email protected] Subject: [Juglist] Application Servers In theory, one should be able to create an application that is portable between application servers, correct? In practice, how difficult is this? The company I work for has relationships with IBM and JBoss. I'm rewriting a webapp to take advantage of services offered by an application server and I would like to support WebSphere, JBoss, and Sun. Is this a practical goal? Also, our default distribution will probably be bundled inside of either JBoss or Sun, since they are freely redistributable. Is there any 'big' advantage to using either one? Thanks! ~akb ----------------------------- A. Kevin Baynes _______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org _______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
