A Giant Leap into JBoss

Several issues ago, Paulo Merson presented a thorough method for assessing your team's readiness to dive into distributed application development with Java 2 Enterprise Edition (Managing J2EE Risks, July 2004). Recently, I've encountered another risky situation that companies or government agencies may confront in the near future: leaving

proprietary J2EE servers for open source options.

Most of the time, the reason to leave a vendor is purely economical or political—the decision will be handed down from the top and suffer few, if any, objections. But that doesn't mean it'll be easy. Based on my own experience, I've assembled some pointers for migrating to JBoss, the popular open source J2EE application server.

Know Thyself
To estimate the migration's impact, you must have a clear picture of all your existing applications, be they in production or under development. Some simple applications will gracefully deploy on the new platform without any changes; others will require developer intervention to adapt scripts or even pieces of code.

[click for larger image] A Miserly Management Console JBoss's built-in management consoles are feature-poor compared to those of other vendors. All configuration is done in XML files, which can be off-putting.

In an ideal world, all the running applications are perfectly identified and documented—but in reality, with dozens of them developed years ago and maintained in different locations, it's essential to centralize a small set of core information. "The App Stats Questionnaire" is a simple survey that I use to capture a snapshot of the situation. It helps identify those applications that may be hard to deploy on the new platform because it pinpoints the critical aspects of J2EE, where dependency on the application server is hard to avoid. It also allows you to estimate the amount of configuration that will be needed, especially for container services.

For nontrivial applications, I find it necessary to interview the development or maintenance team that owns the application. The survey provides a quick overview of a project and allows you to ask focused questions.

Where Are You Going?
Acquiring a deep understanding of the new platform is essential, not only for the development teams but also for the deployment teams. Thus, even if JBoss is freely available as an open source project, it's worth investing in training and support services. This approach is in line with the current trend of buying software services instead of licenses.

Though constantly improving, JBoss's built-in management consoles (see "A Miserly Management Console") are poor in terms of features compared to those of the major vendors. All configuration is done in XML files, which can be off-putting. The deployment teams must learn to feel at ease with these new tools, because they're often in charge of creating, configuring and tuning development and production.

You also need a solid understanding of the basics of the server (like the JMX "bus" and the class-loading mechanism). For example, you usually have an operational and not a development choice to colocate applications on the same server (that is, in the same Java virtual machine), so the class-loading mechanism and its challenges must be understood.
Make sure you don't forget the change's impact on the development teams. My experience shows that they're less likely than the deployment teams to resist platform change—which makes perfect sense when you consider that their operational responsibilities (quality of service, stability and so on) are different from the programmers'.

That said, don't be fooled by programmers' enthusiasm to jump on a new platform. Such innovation carries a serious risk of productivity loss, especially if the programmers are using such advanced tools as BEA Workshop or JBuilder EJB Designer.

Beating the Joneses
The "version race" is another trap to avoid. Vendor servers are usually stable version-wise, with a slow release rate (fewer than one per year). When you switch to an open source product like JBoss, with regular releases (several per year), you're in danger of jumping on the version merry-go-round, getting lost racing after the latest issue, as a minor revision can prove bigger than expected. (An example: The version switch of the embedded Tomcat from 4 to 5 within the 3.2.x branch provides a new version of the JSP/Servlet engine and a slightly different configuration method for the embedded Tomcat, and that's enough to force you to rewrite homemade guides or change your JSTL default version!)

Make sure you control the versions allowed in the company and prevent teams from downloading and installing any version they want. This gives you the opportunity to repackage JBoss in a distribution that fits your actual needs; for example, removing all the nonrequired features (clustering, messaging and so on).

For all this, do not go alone: JBoss Inc. provides professional services including online support, training and on-site "right start" sessions that really make a difference. Having core JBoss developers tuning the server to your site's specifics is really valuable.

Then, Boldly Go!
As I've said, consider adapting the development environment to minimize the possible productivity impact of the migration to JBoss. This kind of migration is the perfect moment for making things right, so don't hesitate to introduce a new IDE. After swallowing the server-migration pill, people are ready for other improvements, especially if you provide good reasons for them.

Further, if the server platform has changed successfully, that means it can change again. To avoid getting tied to the new platform, try to target "pure" J2EE mechanisms—without getting too orthodox, of course. If pragmatism dictates that vendor-specific features drastically cut development time or improve performance, go ahead and implement them while carefully isolating the components. No vendor can be blamed for having palliated the flaws of J2EE in a proprietary manner. The good news? J2EE 1.4 will make it easier to stay in the norm, as EJB-driven Web services, timers and other features are now available in the specification.

The introduction of a tool like Xdoclet can help, it not only simplifies the coding of EJBs, but also generates the deployment descriptors. By generating rather than handwriting the standard (web.xml, application.xml and so on) and the specific (jboss.xml, jboss-app.xml) deployment descriptors, programmers feel less bound to the target server.

Eclipse offers a good open source platform for building a new IDE to support the migration effort (see also www.myeclipseide.org). I've found that productivity can be achieved with a blend of open source and commercial plug-ins. For example, Texas-based Genuitec offers a very attractive set of plug-ins that greatly enhance J2EE development (including XDoclet and Struts support, easy server deployment and many more). Another tool to consider is the MC4J Management Console; it leverages JMX to provide an excellent monitoring and control tool.

Some applications will take longer than others to migrate. You may need to negotiate limited vendor licenses (fewer CPUs or allowed users) until you can complete the switch.

Pragmatism v. Orthodoxy
A migration to JBoss is likely to give birth to a passionate polemic. Whether it's your decision or not, get ready to take on the consequences! When it comes to application servers, people tend to become highly religious. Transparency is your best weapon.

David Dossot is the vice president of technology and cofounder of Agile Partner SA Luxembourg. Contact him at [email protected].