Tad~ Thanks very much for taking the time to write this thoughtful reply.
Thanks for the portability guildelines about stateless session EJBs, servlets and JSPs, JDBC, RMI over IIOP, and JMS. I will pay attention to these. ~akb On Mon, 10 Jan 2005 10:36:29 -0500, Tad Stephens <[EMAIL PROTECTED]> wrote: > 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 > > -- ~akb ----------------------------- A. Kevin Baynes _______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
