|
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.
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.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
