The Challenge:

For years IBM has provided a stable, scalable Java / J2EE container server. However, the support for Hot (on-line) deployment has been a work in progress. With WebSphere versions 3.x, only content like HTML, image files and JSP pages were Hot Deployable. All other elements like Servlets, class files and third party jar files and EJB jars required a restart at least. More was required of EJB deployment changes. With WebSphere 4.x, IBM provided optional support for class file reloading, but this support was not consistent. WebSphere 4.x also does not allow for any form of Hot EJB deployment. With WebSphere 5.x, the class reloading options improved, but did not provide for re-loadable archives, EJBs or the ability to deploy individual JSP pages under all circumstances. For instance, even in WebSphere 5.x consider the following scenario. If a JSP page called main.jsp includes three JSP pages called header.jsp, body.jsp and footer.jsp. If the “header.jsp” page is Hot deployed, only the header.jsp page will be recompiled. Since the main.jsp page will not be recompiled, the change will not appear to work until the Servlet/Web container is restarted.

Many companies have turned to load balancing and other expensive solutions to address a need for a highly available application environment. One way to address the issue of high application availability is to duplicate servers and run a WebSphere cluster configuration. With this cluster in place, it is possible to deploy certain changes to one side of the cluster, stop and restart it, and then repeat on the other side of the cluster. However, there are many limitations to even this approach. For one thing, as each side is upgraded, half of the logged in users are disconnected and forced to re-authenticate to the application on the side that remains up. If the end users remain if for the length of time that it takes to process the upgrade, then the same user could be disconnected from the application twice, before they are able to complete their core task.

The other obvious disadvantage of duplicate hardware is cost. The upside is of course a measure of failover availability. This is predicated on the type of failure. If the failure is a simple component level failure, then duplicate hardware works well. If it is a regional failure, like external network failures, then the duplicate hardware needs to be located beyond the influence of a local or regional failure to be completely effective.

The Solution:

At Infinity Systems, we have solved this and other deployment problems. With our “ DeploymentManagerServlet ” or “ DeploymentManager ” stand alone JAVA jar file, it is possible to deploy entire applications or any portion of an application without stopping or restarting the application server. Infinity Systems Deployment Manager technology is 100% pure JAVA and enables the following Hot Deployment features:

• Ability to Hot deploy JSP files (even included JSP fragments)
• Ability to Hot deploy any Servlet class
• Ability to Hot deploy any JAR files
• Ability to Hot deploy changes to Already Deployed EJB JAR files
• Ability to Hot deploy new EJBs (Note: Requires multiple steps and only available on WebSphere version 5.0 or higher)

How does it work? Infinity Systems Deployment Manager technology installs into the same JVM that contains the code to be Hot Deployed. It works with IBM/WebSphere's native class loader and caching algorithms to intelligently deploy different types of J2EE code, content and archives.

Unlike the stand along “ DeploymentManager ”, the “ DeploymentManagerServlet “ option also allows for dynamic “fast” restart option**. This option is useful for more complicated changes such as JVM startup options, profiling / monitoring cold start options and recognition of resources like new Data Sources for new JDBC drivers requiring warm restarts. How fast is fast? Many “fast” restarts are accomplished in less than 30 seconds and Most in less than 1 minute. This is much faster restart performance than using WebSphere native Administration Console to restart the Application Servers or even IBM's own command line stop / start scripts. Note that Infinity Systems “fast” restart option is a smooth single option.

** The “fast” restart option requires a non-JAVA (C++) companion program that must be locally compiled on the target middle (application) tier server.

Frequently Answered Questions:

Q: Can I Hot deploy a JSP included fragment without knowing which calling JSP files include this fragment file?

A: Yes. The DeploymentManagerServlet works with IBM’s JSP cache control to resolve this issue at runtime.

Q: Can I Hot deploy an existing Servlet.class file in WebSphere version 4.x as well as 5.x?

A: Yes. This option is available natively from WebSphere and does not require any help from 3rd party add-ons.

Q: Can I Hot deploy a “NEW” Servlet.class file in WebSphere version 4.x and / or 5.x?

A: Yes. The DeploymentManagerServlet intelligently handles this deployment by updating the appropriate files in the correct sequence and again, working with WebSphere’s native class reloading options.

Q: Will a “NEW” Servlet.class file still run it’s “Init()” method automatically?

A: Yes. This is also handled by the DeploymentManagerServlet.

Q: Can I Hot deploy a JAR file that is part of my project, but is not supported by IBM/WebSphere’s built in class loader?

A: Yes. Infinity Systems has figured out a way to even support the Hot deployment of JAR files as well as Servlets.

A: No! It is not necessary to have the “source code” for any JAR file that you want to Hot deploy. JAR files can be composed of only “pre-compiled” class files and the deploy

Q: How is the DeploymentManagerServlet licensed?

A: The DeploymentManagerServlet is licensed by server regardless of the number CPU’s. Separate pricing levels are given for Intel, RISC and Main Frame server types.

Q: Is there a trial version available?

A: No, Sorry, at this time Infinity Systems does not offer a trial version, but we do offer consulting and installation assistance to insure your successful deployment and continued satisfaction.