| Oracle® Containers for J2EE Deployment Guide 10g (10.1.3.1.0) Part Number B28951-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Deployment Guide 10g (10.1.3.1.0) Part Number B28951-01 |
|
|
View PDF |
This chapter provides an introduction to deploying J2EE-compliant applications and standalone modules into OC4J. It includes the following topics:
As a J2EE 1.4 -compliant container, OC4J provides a J2EE-compliant infrastructure for deploying, undeploying, and redeploying J2EE-compliant applications and modules.
Deployment operations can be performed on a specific OC4J instance or simultaneously on all OC4J instances in a group. In Oracle Application Server 10g Release 3 (10.1.3.1.0), a group is a synchronized set of OC4J instances that belong to the same cluster topology, which is two or more loosely connected Oracle Application Server nodes. The connectivity provided within a cluster is a function of Oracle Notification Server (ONS), which manages communications between Oracle Application Server components, including OC4J and OHS. The ONS server is a component of Oracle Process Manager and Notification Server (OPMN), which is installed by default on every Oracle Application Server host.
Oracle Application Server 10g Release 3 (10.1.3.1.0) supports both application server clustering (with cluster topologies) and application clustering (for replication, load balancing, and transparent failover). An application cluster is the same set of applications hosted by two or more OC4J instances.
Oracle Application Server provides a number of deployment options with OC4J. See "Options for Deploying Applications into OC4J" for an overview of these tools.
These components can be deployed into an OC4J instance or to each instance in a group:
A Web application packaged as a Web Application Archive (WAR) file
Standalone modules packaged as Java Archive files (JARs) containing Web Services, Enterprise JavaBeans (EJB JARs), application clients (CARs), or resource adapters (RARs)
A complete J2EE application packaged as an Enterprise Archive (EAR) file, which can contain zero of more of the archives listed above
All J2EE-compliant archive files deployed into OC4J must be packaged in accordance with the guidelines specified in the J2EE 1.4 specification. This includes packaging the J2EE standard deployment descriptors required for each type of component, such as the J2EE Application Descriptor (application.xml) for applications and the J2EE Web Descriptor (web.xml) for Web modules.
See the ÒApplication Assembly and DeploymentÓ chapter of the Java 2 Platform Enterprise Edition Specification, Version 1.4 for details.
The OC4J deployment infrastructure implements the functionality outlined in the J2EE Application Deployment API (JSR-88), which defines a standard API for configuring and deploying J2EE applications and modules into a J2EE-compatible environment.
Specifically, the JSR-88 compliant features in OC4J provide the ability to perform these tasks:
Start an application immediately upon deployment, making it available to clients
Stop an application, making it unavailable to clients
Undeploy an application or module
Redeploy an application or module, essentially updating the currently installed application with an updated version
Create a deployment plan containing the aggregated OC4J-specific configuration data needed to deploy a component into OC4J. See Chapter 8, "Working with Deployment Plans", for details on the JSR-88 implementation in OC4J.
The term hot deployment refers to the process of deploying archive files - EARs, WARs, JARs, and so on - and their associated XML descriptor files on a production application server without shutting down or restarting (bouncing) the server.
In addition, libraries at the container level cannot be deployed in this manner. If an application is dependent upon a newer library, OC4J must be restarted.
See "Overview of Redeploying an Application" for details on redeploying applications to an OC4J instance.
Hot deployment or redeployment of an application or standalone module into OC4J is generally supported as long as the following conditions are true:
No changes are made during the deployment process to existing data source, JMS, or RMI configuration files.
The structure of an Enterprise JavaBean that replaces an existing EJB has not changed.
Shared libraries are loaded and managed at a container level. A change to a shared library does require a container restart.
If, however, a redeployed application has an import-shared-library declaration that goes from a lower to a higher version, such as from 2.2.8 to 2.2.9, then the version change in the declaration should not require a container restart. The application will be restarted on redeployment and should pick up the new shared library version (as long as the library is available).
You can use a number of options for deploying applications into OC4J, including utilities packaged with OC4J:
Most of these options enable you to deploy an application to a specific OC4J instance or to a group of OC4J instances within a cluster topology.
The Oracle Enterprise Manager 10g Application Server Control Console provides a Web-based user interface for completing deployment-related tasks:
Deploy an application (EAR), a standalone Web module (WAR), a standalone EJB module (EJB JAR), or a standalone resource adapter (RAR)
Undeploy an application, Web module, EJB module, or resource adapter
Create, modify, or remove shared libraries for an application
Start, restart, or stop applications
Restart or stop an OC4J instance or group of instances
Manage data sources and connection pools
Manage JMS resource
Create and edit reusable deployment plans
Set application-specific security and application-clustering configurations
See Chapter 9, "Using the Application Server Control Console for Deployment" for details.
OC4J includes a set of Ant tasks for performing deployment tasks on an OPMN-managed OC4J instance, a standalone OC4J server, or all OC4J instances in a group within a cluster topology. These tasks provide another option for scripting the deployment process.
Specifically, you can use Ant tasks to perform these tasks:
Deploy an application (EAR), a standalone Web module (WAR), a standalone EJB module (EJB JAR), or a standalone resource adapter (RAR)
Undeploy an application, Web module, EJB module, or resource adapter
Incrementally update a deployed EJB module with modified classes
Create, modify, or remove shared libraries for an application
Start, restart, or stop applications
Restart or stop an OC4J instance or group of instances
Add, test, and remove data sources and data source connection pools
Add and remove JMS connection pools and destinations
See Chapter 10, "Using OC4J Ant Tasks for Deployment" for an overview of the deployment-specific Ant tasks and guidelines for integrating the tasks into your application build process.
The admin_client.jar command-line utility provided with OC4J can be used to perform deployment tasks on an OPMN-managed OC4J instance, a standalone OC4J server, or all OC4J instances in a group within a cluster topology. Also, the administration client distribution enables you to use admin_client.jar from a remote client.
Specifically, you can use the admin_client.jar tool to perform these tasks:
Deploy an application (EAR), a standalone Web module (WAR), a standalone EJB module (EJB JAR), or a standalone resource adapter (RAR)
Undeploy an application, Web module, EJB module, or resource adapter
Incrementally update a deployed EJB module with modified classes
Create, modify, or remove shared libraries for an application
Start, restart, or stop applications
Restart or stop an OC4J instance or group of instances
Add, test, and remove data sources and data source connection pools
Add and remove JMS connection pools and destinations
See Chapter 11, "Using the admin_client.jar Utility for Deployment" for instructions on using this tool.
The admin.jar command-line utility provided with OC4J can be used to deploy applications to a standalone OC4J server only. It cannot be used to deploy applications to an OPMN-managed OC4J instance.
Deploy, undeploy, and redeploy a J2EE application packaged within an EAR file
Deploy, undeploy, and redeploy a standalone resource adapter packaged within an EAR file
Update an EJB module within a deployed application
Convert a data source from an earlier release to the format for the current release before deployment.
Deployment of a standalone Web module packaged in a WAR file is not supported by admin.jar.
See Chapter 12, "Deploying to Standalone OC4J with admin.jar" for instructions on deploying applications with this tool.
Oracle JDeveloper 10g is a J2EE integrated development environment with end-to-end support for developing, debugging, and deploying e-business applications and Web services.
JDeveloper enables you to build J2EE applications and Web services from scratch, or jump-start the process by beginning with a J2EE framework. Whichever approach you prefer, JDeveloper offers a full suite of productivity tools to support your work from start to finish.
JDeveloper provides the ability to deploy a J2EE application into an OC4J instance directly from within the project structure. It also enables you to create a deployment plan and optionally save it as an XML file.
See the online help provided with JDeveloper for instructions on deploying applications.
