Every day IT faces the challenge of delivering high levels of data and application availability across a wide array of operating systems, applications, hardware components and data center locations. As more and more mission-critical applications are deployed in a J2EE architecture, providing disruption-free services becomes increasingly important for J2EE server vendors. To achieve a high level of availability for applications in a live enterprise application upgrade is a major factor, along with other services such as clustering for redundancy, disruption-free server upgrades, improved visibility into the runtime operations for diagnosing issues, and flexible administration tools for customization.
These days, high availability is in demand. No one wants any services they deploy to be unreachable—even when the services are upgraded, especially since that downtime will almost undoubtedly cost them a lot of money. BEA WebLogic Server 9.1 provides a robust platform for deploying applications that support these considerations.
One feature introduced in WebLogic Server 9.1 is production redeployment (or side-by-side deployment) that allows you to upgrade applications without the need for downtime. This article discusses production redeployment, shows how it can help eliminate disruption, and points out how this is achieved through its extensions of the J2EE Deployment API, which is part of J2EE 1.4.
J2EE has been very successful in providing specifications for detailing the arrangement of resources within a server-side application, such as Web applications (*.war files), EJB components (*.jar files), and enterprise applications (*.ear files).
This in itself has helped to propel the popularity of J2EE across corporate enterprises. The next natural step is to ease the process of deploying applications across various environments by providing a uniform deployment API to be supported by different J2EE product vendors. Along with the deployment API, you would also expect different J2EE product vendors to support a uniform management API to manage the deployed application in production.
It is a common feature of any J2EE application server vendor to provide deployment tools along with the application server distribution. Today, administrators have to depend on the application deployment and application configuration tools provided by the application server vendors. Creating custom scripts or automating the deployment process involves implementing vendor-specific APIs. Standardizing this aspect will simplify the development of deployment and application configuration tools. They will only have one package to implement.
The J2EE Application Deployment API ( JSR 88) specification defines standard APIs that will enable any deployment tool that uses the deployment APIs to deploy any assembled application onto a J2EE-compatible platform.
The API will address the three-stage deployment process:
The three major players of this specification are the J2EE product provider, the tool provider, and the deployer. A J2EE product provider is an implementer of a J2EE-compliant product. It could be an application server vendor, a Web server vendor, or simply an operating system vendor. The J2EE product provider implements a deployment manager that can help J2EE applications to be deployed on it. It also provides deployment factories that can help access the deployment manager. The tool provider is the implementer of the tools used in the packaging of applications. It also has the job of deploying, managing, and monitoring J2EE applications. The deployer is responsible for configuring and deploying J2EE applications with the help of the tool provider.
To summarize the roles of the three players, the deployer deploys a J2EE-compliant application onto a J2EE product made by the J2EE provider with the help of the tool provider.
The J2EE Application Deployment API, in its current 1.1 version as part of the J2EE 1.4 specification, achieved many of the goals that we've just discussed—but in certain areas it can be enhanced to provide more features needed on a practical basis. For example, the redeployment process is not detailed, along with the omission of the maintenance of HTTP session objects during application updates. Versioning of applications is also not part of the deployment API in its current release.
Live application upgrade is one of the major factors in achieving disruption-free service. Even though the failover feature provided by a cluster will increase the availability of the application, live application update is vital to provide continual uptime of the service to clients.
This article's purpose is to discuss some of the needed enhancements to the specification, and to illustrate the possibility of these enhancements. We will detail the use of these enhancements in WebLogic Server 9.1.
Now that we have talked about the deployment API and the need for extending the API, let us explore the specific areas in which WebLogic Server 9.1 goes beyond the specification.
The following sections explore each of these extensions in turn.