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?

Working for an Indepedent Software Vendor

Welcome to the ISV Diaries!

If you've stumbled upon this blog, it may be because you are working for an Independent Software Vendor (ISV).

To give you a bit of background, I've been working for a mid-sized ISV (200-300 employees) for close to 8 years.  I work as a software architect in the R&D department of the company, which sells a large JEE-based (Java Enterprise Edition) product to our customers.

During my time working for this company, and with my interactions with the IT departments of our customers, I have noticed that there are numerous constraints that must be considered during various stages of the product lifecyle of which our friends working in IT departments are not burdened.

These constraints affect, but are not limited to, the following:

• Technology stack
• Systems architecture
• Customized business functionality
• Software versioning
• Product support

Now, what are these constraints that I'm talking about?  Let's delve deeper into each of the above concepts and see how decisions may differ between IT departments (ITDs) and ISVs.

Technology Stack

ITD: I need to choose a single technology stack to host my solution starting from disk, to hardware server, to operating system, all the way to the middleware stack.  I can choose the exact hardware-software combination that works best together.  I can pick a technology vendor that offers me the best price and solution.

ISV: I need to support multiple technology stacks as my customers each have investments in their own choice of technologies.  My customers use a wide array of hardware and supporting software, and my product needs to be able to run on them.  My customers each have their technology vendor of choice, and I need to be able to support their choice of vendor.

Systems Architecture

ITD: I am a big organization with serious SLA demands, and I know that I need to architect my product in a distributed design, with server clustering, load balancing, and disaster recovery strategies.  Or, I am a very small organization, and I know that I need to architect my product such that it is lightweight and runs on limited hardware, since I cannot afford more than that and my SLA demands are not onerous.

ISV: My customers range from very large organizations with IT departments of thousands of people, to very small organizations that barely have a functional IT department.  My product must be able to support extreme High Availability with plenty of redundancy to meet crucial uptime for my largest customers.  My product must also have the ability to be implemented on a limited scale using open-source technology in order to minimize licensing and deployment costs.

Customized Business Functionality

ITD: I know all my business requirements during the project, and I am designing the solution to meet these requirements.  I know all the external systems to which I need to integrate, and I can design the solution to interact smoothly with the business interfaces of these systems.

ISV: I know the core requirements for my product that are applicable for all my customers.  However, aside from the core requirements, my customers have varying different needs that need to be served by the product.  Since most of these needs are not known during the development lifecycle, I must design my application to be highly configurable, with the ability to to plug in custom code into well-defined integration points.

Software Versioning

ITD: The product that we are designing is for a very specific deployment within the organization.  While we will have multiple code streams in our SCM repository, we will only ever have the most current, stable release live in production, and so we do not need to actively maintain multiple code streams.

ISV: We have many versions of our product, with customer deployments on all versions.  We need to make decisions on which support streams to decommission, and which ones we need to maintain, based on an analysis of our ongoing maintenance costs for each support stream.

Product Support

ITD: Our organization is our single customer, with one deployment of our product.  Our Helpdesk staff provides support of our live environment to our end users.  If they find what appears to be a product defect, they will escalate the issue to the development team.

ISV: We have many customers, all using the product in different ways, with different configurations.  They use a multitude of supporting technologies, including a variety of hardware and operating systems.  Our support team must have the skill set to deal with all these technologies, as well as understand how the product is customized at each customer site.  In addition to the 1^st line support team, there is a 2^nd line support team that can analyze problems in more depth in order to ascertain whether there is a defect in the product.  Finally, the 3^rd line support team in R&D fixes product defects and releases patches.

---

Of course, any particular ISV or ITD may differ somewhat from the above scenarios.  The strategies involved in an ITD may overlap with those of an ISV, but for the most part, their core decision making will be based on very different criteria.