Oracle Application Server 10g Essentials [Electronic resources] نسخه متنی

6.3 Application Deployment

Application deployment
is the process of making a J2EE application available to end users on
an application server. OC4J can deploy a J2EE application in an EAR
file or a WAR (Web Application aRchive) file. When
deploying a WAR file, OC4J automatically wraps a WAR file in an EAR
file. OC4J provides a mapping mechanism so that differences in
deployment environments can be resolved during the deployment
process. OC4J also supports application development by accessing
servlets and EJBs from an operating system directory without
requiring OC4J-specific deployment descriptors. The remainder of this
section takes a closer look at how OC4J handles application
deployment, starting with standard J2EE deployment.

6.3.1 J2EE Deployment

J2EE applications

are typically composed of JSPs,
servlets, and EJBs. In a well-written J2EE application, each program
unit acts as a separate and distinct component. To facilitate the
composition of components into a working application, J2EE components
have a descriptor file. A descriptor file exposes any configuration
parameters, such as database resources, so that they can be specified
declarativelythat is, without changing a line of Java code.

EJBs are placed into a
Java ARchive (JAR)
file that contains the EJB, with any
supporting custom classes, and a deployment descriptor file named
ejb-jar.xml. There is typically one JAR file for
each session or message-driven EJB, whereas a JAR file usually
contains multiple entity EJBs because related entity EJBs must be
co-located.

All servlets under a particular application
context directory in a servlet container use the same
deployment descriptor file named
web.xml; so do any JSP files that reside in the
same application context directory because the JSP translator
automatically compiles them into servlets. The servlets, JSPs, any
supporting custom class libraries, JSP tag libraries, and the
web.xml file are all placed into a WAR file;
such a file facilitates deployment of a web application to another
web container.

To create an application that uses both EJBs and servlets, WAR files
and any required EJB JAR files are placed into a
EAR file, along with an
application deployment descriptor file appropriately
named application.xml.

Applications are usually developed on one server, deployed on a
second for quality assurance testing, and then deployed on a third to
put them into production. If the environments aren't
exactly the same, how do you resolve the differences? It is possible
to make the appropriate changes to the individual J2EE descriptor
files for the target environment before archiving the files into a
WAR or EAR file, but this is at best a deployment nightmare. Another
solution is for the host application server to provide a mapping
mechanism during deployment. That is how OC4J solves this deployment
problem.

6.3.2 OC4J Deployment

In
OC4J, each J2EE
deployment descriptor has an
OC4J-specific counterpart that can map a J2EE deployment resource
name to one that is available in the OC4J. Let's
look at an example. Suppose that a data source defined on a
development server is named DefaultDS and that the
appropriate entry in the web application's
deployment descriptor file, web.xml, references
that name, yet on the production server, a dedicated data source
named MyAppDS is defined for the web application.
You can map the J2EE deployment descriptor reference
DefaultDS to the dedicated data source name by
specifying the mapping in the appropriate OC4J-specific deployment
descriptor file orion-web.xml. Table 6-2 shows the relationships between the J2EE and
OC4J specific deployment descriptor files.

[2] Supplied with the
resource adapter

Using this mechanism, OC4J can deploy any J2EE-compliant application
without having to modify its deployment descriptors. Deployment
mappings are specified during deployment using Application Server
Control.

6.3.3 OC4J Development

You
can use OC4J as a
development
environment to compile EJBs, servlets, and so on, in the server
directory tree. Doing so requires you to create a standard deployment
directory structure and the appropriate J2EE deployment descriptor
files, and make a set of manual configuration changes through
Application Server Control.

If you create a separate development instance for each development
project, you can restart OC4J quickly, without incurring the wrath of
developers who may be working on other projects. When using OC4J as a
development environment, your application's response
times will be slower because nonarchived classes are loaded
as-needed, whereas archived classes (that is, classes in JAR files)
are cached in memory.