Supporting multiple application servers

For a variety of reasons, it may be in your best interest to have the ability to deploy your application on multiple application servers.  If your customers tend to have rather large IT departments, then they may already have skills for a particular application server, or an agreement with a particular application server's vendor.

In theory, coding your application to the JEE specification makes it portable across different implementations.  In practice, it most definitely is NOT a seamless transition from one application server to another.

Why is this?  Here are some reasons:

• Gaps in the specification: Certain behaviours or assumptions are not explicitly defined in the JEE specification.  JEE implementations will then interpret and define these behaviours and assumptions differently from each other.
• Configuration is outside the scope of the specification: Configuration of application resources (e.g JMS queues/topics, Datasources, etc.) is the outside the scope of the specification, and will be completely different between application servers.
• Unintentional coding to vendor implementation: Even though there may have been a conscious effort to code the application to the JEE specification, it is likely that a few areas of the application were coded to vendor-specific behaviours as "spec behaviour" and "vendor behaviour" cannot be differentiated on only one platform
• Intentional coding to vendor implementation: Vendors supplement the JEE specification with advanced features and components that are beneficial for applications.  An application may have required usage of vendor-specific features to fulfill its requirements.

Therefore, supporting multiple application servers is not as straightforward as one may think.  However, there are strategies that can be employed to make it easier for your application to be portable across application servers:

• Create a common set of configuration data that represents the resources to be deployed on the application server.  Then create a technical process that can map the data into the format required for each supported application server.  The mapping procedure can then be integrated into an automated build process.
• Try to avoid using vendor-specific features.
• For the parts of the application that must rely on vendor-specific features, use the Delegator or Adapter software pattern to create a common component that can delegate calls to custom adapters that interact with vendor-specific features.

Choosing a JEE application server

If you are an ISV that is building a JEE-based software product, you will have chosen (or will choose) an underlying application server that will act as a container for your software solution.  There are many choices out there, but they will fall into two general categories:

1. Open-source application servers - e.g. Apache Geronimo, JBoss, Glassfish
2. Commercial application servers - e.g. Oracle WebLogic, IBM WebSphere

The open-source application servers are great in they are free (no license costs) and can be embedded with your software to provide a complete, out-of-the-box solution.  Debugging tends to be easier because you have the capability to step through the application server code itself, since it is freely available.  As well, paid commercial support for the application servers is available if that is required.

The main area where open-source application servers are deficient is administration and configuration.  Typically, the application server configuration is modified by adjusting the values in flat property files or XML files.  While this may be efficient/desirable for a developer or an experienced administrator, it is by far not the best scenario for most administrators, as it tedious and error-prone.  By comparison, commercial application servers provide fully-functional web applications that can be used to change configuration settings.  In addition, they provide an administrative scripting interface (e.g. Jython-based scripting) that allow for the automation of configuration changes.

Commercial application servers tend to be more robust at high user loads, provide for automated configuration management, and are usually packaged with supporting tools from the vendor.  The major downside is that license fees are quite expensive.  Also, because the source code is not available, the application server code cannot be stepped through using a debugger, and is therefore more of a "black box".  Delivery of your software is complicated by the fact that you cannot package the application server with your product (unless you enter a reseller agreement with the application server vendor, which will also reduce the license fees by more than 50%).

When choosing an application server to power your software, answer the following questions to help you determine what the most important factors are:

• Is my application lightweight that will be minimally stressed, or is it a heavyweight product that needs to be able to scale up?
• Lightweight: open-source will be the most cost-effective option
• Heavyweight: commercial will let your application scale as needed, with technologies such as clustering available for High Availability configurations
• Are my customers small organizations or large organizations?
• Small: cost is more of a factor for smaller organizations, and so open-source may be best
• Large: would be more open to more expensive technologies such as commercial application servers
• Do I require an end-to-end install of my software?
• Yes: use open-source app servers that can be embedded with the product, or enter a reseller agreement with a commercial vendor to allow for product embedding
• No: commercial application servers can be pre-installed before running your software installer
• Do my customers already have a certain application server that is preferred corporately or already in widespread use?