HomeOracle Page 3 - J2EE Applications: Maintenance and Monitoring
TWO-MINUTE DRILL - Oracle
In this final article of a six-part series, you will learn how to deploy, maintain, and monitor J2EE applications. You'll also review the content of all of the parts; a self-test is included at the end. It is excerpted from chapter eight of the Oracle 10g Application Server Exam Guide, written by Sam Alapati (McGraw-Hill; ISBN: 0072262710).
J2EE is used to build and deploy Web-based applications.
JTI is used by applications deployed in the OracleAS to demarcate transactions.
JNDI is an independent directory service that enables Java applications to access various naming and directory services.
JMS provides a standard messaging API that enables application components to pass data among themselves.
RMI helps distributed applications communicate by invoking procedure calls.
Data sources encapsulate database connections and help provide database connectivity to J2EE applications.
The J2EE Connector Architecture (J2CA) provides a standard architecture for connecting the J2EE platform to non-Java-based enterprise systems.
Servlets are small programs that run on the server and are used to enable dynamic content in Web pages and JSP documents.
JavaBeans are reusable components that implement the functionality needed in J2EE applications.
A J2EE container contains the framework for running EJBs, such as starting an EJB, and provides necessary support services for EJBs.
Enterprise JavaBeans (EJBs) are Java components that implement business logic.
Session EJBs support clients during the execution of their tasks and last for the duration of a session.
Entity EJBs represent an object of data, usually of a persistent nature, such as the table rows in a database.
Entity EJBs can reﬂect two types of persistence: container-managed persistence (CMP) and bean-managed persistence (BMP).
Message-driven EJBs represent the integration between the JMS (Java Message Service) and EJBs.
J2EE applications can have three types of application deployment files, also called archives: JAR files, WAR files, and EAR files.
Oracle Containers for Java
OC4J is a set of containers that enable J2EE application deployment.
When you create a new OracleAS instance, you automatically install a set of default OC4J instances, to support the various OracleAS components.
You must use the Oracle Application Server to manage OC4J.
The two command-line tools you can use to manage OC4J instances are the familiar opmnctl and dcmctl utilities.
Creating an OC4J Instance
The name of the default OC4J instance is home.
You can create new OC4J instances with either the dcmctl utility or the Application Server Control.
The dcmctl createComponent command helps you create a new OC4J instance.
The ListComponents command helps you view all OC4J components.
You must start a newly created OC4J instance using the Application Server Control or the opmnctl utility.
You use the destroyInstance command to clear repository information about a removed OracleAS instance.
Managing the OC4J Instance
The recommended way to manage the OC4J instance is to use the Application Server Control.
To start or stop a single OC4J instance, use the opmnctl command with the ias-component option.
To start or stop all the OC4J instances in an OracleAS instance, use the opmnctl command with the process-type option.
Every OC4J instance has a separate OC4J home page in the Application Server Control Console.
You can start and stop an OC4J instance either from the Application Server Control home page or from the OC4J home page.
You can edit the server.xml file either by using the Server Properties link on the Administration page or by clicking the Advanced Properties link.
The Website Properties home page lets you specify which Web applications are loaded when you start an OC4J instance.
You can deploy a .ear file to a single OC4J instance or to all OC4J instances in a cluster.
You canít directly redeploy an application; you must first undeploy and then deploy the application again.
You use the dcmctl updateConfig command to let the OracleAS instance know that you have manually updated the configuration files using the standalone tool admin.jar.
An OC4J instance has three types of configuration files: mod_oc4j files, server configuration files, and application deployment files.
The default port for the Oracle Web Cache on a UNIX system is 7777.
The mod_oc4j module facilitates communication between the Oracle HTTP Server and the OC4J instance.
The mod_oc4j module helps to provide transparent failover for clustered OracleAS instances.
The server.xml file is the key OC4J server configuration file.
The server.xml contains references to other configuration files, including J2EE configuration files.
The server.xml, application.xml, and the default-web-site.xml files together define an applicationís configuration.
The default-web-site.xml file contains the default Web site configuration details.
The jazn.xml and jazn-data.xml files are used for security configuration, if youíre using the Java Authentication and Authorization Service (JAAS).
Logical data source objects are published in the JNDI tree.
Applications retrieve database connections through the java.sql.DataSource objects and look up the objects through the JNDI.
The java.sql.DataSource object specifies the properties and methods of the data source objects.
You use the data-sources.xml file to configure the OC4J database sources used by various applications.
An application can also specify data sources at the application level, using the <data-sources> tag in the application.xml file.
Each application has a separate JNDI namespace.
Managed data sources are directly managed by OC4J, whereas native data sources are provided by vendors and implement the java.sql.dataSource interface but arenít wrapped by OC4J.
The principals.xml file contains user, group, and other security-related information.
Web application modules are contained in WAR files and include servlets and JSP pages.
EJB applications are contained in EAR files and include EJBs.
Client applications (JSPs) are contained in JAR files.
To deploy an application to OC4J, you archive the JAR and WAR files into an EAR file.
Each J2EE application type has two types of OC4J application configuration files: an OC4J specific file (Orion files) and a J2EE deployment descriptor file.
If you donít explicitly create the OC4J-specific deployment file, theyíll be automatically created at deployment time.
The J2EE application.xml file is the global configuration file for all applications.
Each application has its own local application.xml file.
The orion-application.xml file is the OC4J-specific global configuration file for all applications.
The autocreate-tables and autodelete-tables attributes determine whether to automatically create and delete tables for CMP beans.
You must set autocreate-tables to false if you want to bind EJBs to existing tables.
The orion-ejb-jar.xml file contains the mapping of EJBs to the OC4J server environment.
The OC4J Server Configuration Files
The OC4J server configuration files help configure the OC4J server.
The configuration settings in the OC4J configuration files apply directly to the OC4J server and not to the deployed J2EE applications.
The server.xml file is the key OC4J server configuration file; it contains references to most of the files used by the OC4J server.
The jazn-data.xml and the jazn.xml files are used for security configuration if youíre using the Java Authentication and Authorization (JAAS) Service.
The data-sources.xml file lets you configure OC4J database sources used by the various applications hosted by the OC4J instance.
The principals.xml file contains user and group information as well as permissions and certificates.
The rmi.xml file contains Remote Method Invocation (RMI) configuration information.
The jms.xml file contains the OC4J Java Messaging Service (JMS) implementation configuration information.
The web-site.xml file contains Web site configuration information.
There are two basic types of application configuration XML files: J2EE deployment (configuration) files and an OC4J-specific configuration file.
There are four J2EE application types: EJB, Servlet (Web Modules), JSP, and Client.
Each J2EE application has a J2EE deployment descriptor XML file and an OC4J-specific deployment descriptor XML file.
In addition to the different J2EE deployment XML files, there is also a set of four common global configuration files for all types of applications.
Deploying J2EE Applications
Application directory naming conventions must be consistent with the appropriate directory structure for creating necessary JAR, WAR, and EAR files.
You can deploy applications through dcmctl or the Application Server Control.
You can also deploy applications by manually editing the configuration files and if you do so, you must run the dcmctl updateconfig command to record, in the Metadata Repository, the changes you made.
When you are specifying JNDI locations as part of a data source creation, you must specify the XA and EJB locations only if you plan on having the EJBs use the database for CMP. Otherwise, specify only the Location attribute.
The default data source (OracleDS) is emulated, which means you can connect only to a specific database.
You must use a non-emulated data source if the application must access multiple databases.
When you deploy a WAR file for the first time, itís wrapped inside an EAR file.
EJB deployment descriptors are saved in the ejb-jar.xml files.
Web providers are regular J2EE applications.
All Web providers must be registered with the OracleAS Portal, using the OracleAS Portal Web user interface.