Articles : J2EE Deployment Specification :

J2EE Deployment Specification

by Benoy Jose

Introduction:

During software development it isn't uncommon to find that the deployment platform isn't ready or decided. It often happens that companies shift gears and move to a different platform or application server right when the application is due to go to testing. This could be due to licensing issues, cost, compatibility issues or scalability issues. Some companies may even need to move to a different application server due to traffic demands when the application is live. No matter what the issues are, it is a nightmare for the company to make the shift without a considerable amount of rework and in many cases redesign. In the initial days of the application servers' market leaders like IBM, BEA, Allaire decided how applications ran, got deployed and performed on their application servers. Each tried to push their own mechanism as the best way to do things. One clear example is deploying and running Enterprise JavaBeans (EJBs). Deploying the same EJB code on different application servers is a great challenge; this is because of different deployment parameters and configurations required by each application server. Moreover the procedure used by each application is different from the other. The result is the mess we are in today; programs are not cross deployable and not cross functional across different application servers. The end customer was to endure the nightmare of porting applications from one application server to another if one of these companies went off business. One of the reasons for this is the absence of any concrete guidelines in the EJB specification on the deployment procedures. The major companies took advantage of this and packed proprietary deployment interfaces to ease deployment and market their product over the others. This allowed these vendors to provide deployment tools in their own IDEs for ease of deployment.

Sun realized the importance of a unified, uniform standard of configuration and deployment that would help the end customer in the long run and that drove it to develop the J2EE deployment API. The specification defines the rules that can help tools from any application provider to deploy and configure applications on any J2EE compliant product.

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 webserver 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 which can help access the deployment manager. The tool provider is the implementer of the tools that are used in the packaging and 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 on to a J2EE product made by the J2EE provider with the help of the tool provider. We shall go into the individual details of these major components later in the article.

Deployment Manager:

The deployment manager is a service that is provided by the J2EE product provider. It is used to configure, distribute, start, stop and undeploy J2EE applications on any J2EE compliant product. Every J2EE product needs to be shipped with a deployment manager to do the above mentioned jobs. The deployment manager may be a part of the actual product or an add-on that is outside the product. A deployment manager running as a standalone application can only configure applications and may be unable to do administrative tasks on the product. If the deployment manager attempts to do any operations like start or stop the application an IllegalStateException would be thrown.

Usually the deployment manager is bundled with the administrative console shipped with most J2EE products. This helps in greater flexibility to the server administrator.

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.