Oracle Application Server Containers for J2EE (OC4J)

Java development and deployment is discussed in detail in Chapter 13.

Note  

It is important to note that while OC4J is an integral part of Oracle Application Server 10g, it is also available as a separate download from the Oracle Technology Network (http://otn.oracle.com).

Most Java applications are built using a variety of Java technologies, some of which were discussed in Chapter 1. When an application made up of these different Java technologies is deployed, the Java 2 Platform, Enterprise Edition (J2EE) specification mandates that the files that constitute your application be placed in specifically named directories and include deployment files that describe your application s directory structure. These deployment files are used as the application is deployed under an OC4J container in the middle tier of your application server farm. Oracle takes the information contained in these deployment files and automatically constructs various web pages that allow deployed applications to be monitored via the Enterprise Manager Application Server Control web site. Figure 2-1 shows an example of an Enterprise Manager web site page for an application named portal, deployed under the OC4J container named OC4J_Portal.

click to expand
Figure 2-1: An Enterprise Manager web site page for application portal
Note  

In this example, the page displayed in Figure 2-1 gives metrics for all aspects of the Oracle Portal environment, including development, administration, and the generation and delivery of Oracle Portal pages. If you have a heavily or moderately used Portal environment, viewing the metrics on this page can give a good indication of the types of metrics that can be used to tune any of your OC4J instances.

Some terminology needs to be explored before the structure and content of the files that make up an OC4J server and the application to be deployed can be discussed. Some of the terminology discussed here may be thoroughly understood by experienced Java developers, but it is important to remove any ambiguities before proceeding.

A servlet is a small Java program that runs on a web server, as opposed to an applet, which is a Java program that runs in a client browser. When a client HTTP request calls a servlet, the web server passes the HTTP request to a container (discussed shortly). The container translates the HTTP request into a Java method invocation and then passes the request to the servlet. Servlets take client HTTP requests from a browser, generate dynamic content (with data queried from an Oracle database as an example), and provide an HTTP response back to the browser. Unlike a Java client program, a servlet has no static main() method. Therefore, a servlet must execute under the control of an external container.

The Apache server, however, does not have a Java Virtual Machine (JVM) built into it. Sun Microsystems maintains the specification of the Java language and the Apache Foundation maintains the Apache web server. If the Apache web server had a JVM built into it, coordinating changes in the Java specification with Apache would be almost impossible as Sun and the Apache Foundation have different (and sometimes conflicting) motivating factors. In response to the attempt to create a Java environment that Apache could use, the concept of a container was born.

Strictly speaking, a container is a component that contains other components , but for our purposes, we can think of a container as a program that provides a Java environment and associated services to support that Java environment to the Apache web server. Because the container is not part of the Apache server, it can be updated to reflect Sun s enhancements of the Java language, independent of any changes (such as upgrades, bug fixes, or security patches) made to the Apache web server. Traditionally, the container is associated with and communicates with the Apache web server by way of an Apache module called mod_jserv. When a client HTTP request calls a servlet, the web server passes the HTTP request to the container. The container translates the HTTP request into a Java method invocation and then passes the request to the servlet. The servlet container calls the methods of the servlet and provides services to the servlet while it is executing. A servlet container is usually written in Java and is either part of a web server (if the web server is also written in Java) or otherwise associated with and used by a web server. The servlet container provides the servlet easy access to properties of the HTTP request, such as its headers and parameters.

In general, there are two types of containers:

  • Web containers , which provide support for servlets and JSPs

  • EJB container s, which provide support for Enterprise Java Beans (EJBs)

The Apache server provided with Oracle Application Server 10 g has the mod_jserv module disabled by default as Oracle has created its own module, mod_oc4j (Oracle Containers For J2EE), which encompasses all of the functionality of the mod_jserv module and adds many features to it. mod_oc4j can be considered both a web container (as it provides all the services needed by servlets and JSPs) and an EJB container (as it provides support for EJBs). OC4J includes a fully standards-compliant servlet container. In addition, Oracle provides Oracle Business Components for Java (BC4J), an XML- powered framework that enhances the EJB architecture and helps developers quickly build, test, and deploy multitier database applications from business components. BC4J greatly assists in the development of EJBs by implementing many of the common patterns used by developers of Oracle-based web applications. Oracle encourages all developers of applications deployed through Application Server 10 g to use BC4J and OC4J.

Tip  

Not only is mod_oc4j much faster than mod_jserv, but it also has an EJB container and much greater functionality

Most of the administration tasks of creating and editing the files associated with an OC4J instance, as well as the tasks associated with deploying applications to an OC4J instance, can be handled through the Oracle Enterprise Manager Application Server Control web site, although it is not a requirement to do so. Through this web site, you can create OC4Js, deploy applications, and monitor the container s performance as well as set characteristics that can be used to cascade down to other applications deployed within an OC4J instance. Figure 2-2 shows the main page of an OC4J instance.

click to expand
Figure 2-2: The main page of an OC4J container

Chapter 15 will explore the various tasks that need to be performed when deploying Java applications to an Application Server 10 g OC4J instance. This chapter discusses the basic tasks involved in OC4J creation and administration. As part of the Application Server 10 g installation, a number of OC4J instances are created automatically. To see what has been installed and configured already, point your browser to:

 http://<Middle-tier>:<Enterprise Manager Port> 

The development machine used for all examples contained in this book is named xpas10 g , and the Enterprise Manager Application Server Control web site is listening on the default port of 1810; the Uniform Resource Locator (URL) to access the site is

 http://xpas10g:1810 

After you log in, the farm page is presented (a farm is an infrastructure and all of its associated middle tiers). Select the middle-tier instance. A page similar to the one in Figure 2-3 should be displayed.

click to expand
Figure 2-3: Components installed in the middle tier

The components displayed may look different depending on the type of installation you have chosen , but at the very least, a couple of components that begin with OC4J_ should be visible. These components are OC4J instances and are created, by default, to support Oracle processes. Some of the other Application Server 10 g system components are dependent on the OC4J servers. For example, if the Portal and Wireless or Business Intelligence options were chosen during your install, a component named portal:portal will be displayed with its check box grayed out. The portal:portal component check box is grayed out because it is dependent on the OC4J_Portal instance and cannot be started or stopped manually. If the OC4J_Portal instance is up, then the portal:portal component will also be up, and vice versa, unless there has been an unexpected event on your server.

If the two components are dependent on each other, you may wonder why they are separate on the system components page of the Enterprise Manager Application Server Control web site. When an OC4J instance is created, a home page for that instance is also created automatically. This page provides various real-time information metrics about the OC4J instance and the applications deployed to that instance as well as access to the configuration files that make up any applications deployed there. In most cases, this is sufficient for a developer s or administrator s purposes. In the case of Oracle Portal and the Business Intelligence products (Oracle Forms, Oracle Reports, and Oracle Discoverer), Oracle has created other metrics and administration pages specific to those products, as there are parameters for each of these components that can affect their performance and behavior outside of the parameters associated with the OC4J instance. In the portal:portal component, for example, an administrator or developer can view the performance of the providers (a grouping of Portal objects, most commonly portlets) that have been created in your Portal environment and even drill down to individual components in the provider (such as Portal forms or Portal Reports ) to view their metrics (see Figure 2-4). In the Forms system component (which is dependent on the OC4J_BI_Forms instance), you can view metrics for the users currently connecting to Application Server 10 g via an Oracle Forms application (see Figure 2-5) and change the configuration files that drive the Forms server.

click to expand
Figure 2-4: Metrics of a Portal component
Tip  

The parameter em_mode must be set to 1 in the Oracle Forms configuration file (formsweb.cfg) to see the metrics in Figure 2-5.

click to expand
Figure 2-5: Metrics for users connecting to Oracle Application Server 10g via a Forms application

Although you could deploy your application to one of these existing OC4J instances, it is a much better idea to go ahead and create your own OC4J instance.

Note  

The existing OC4J instances have settings that are unique to the applications deployed there. The OC4J_Portal instance, for example, has settings that influence the behavior of the Portal application. Deploying an application there and changing any of the settings for the OC4J_Portal instance could, at the very least, cause the Portal application to behave erratically and, at the very worst, stop the Portal application from functioning altogether.

All of the administrative actions associated with an OC4J instance (creating a new instance, deploying an application, etc.) could be performed from the command line. As we will see, however, there are a number of configuration files that must be in place and the Enterprise Manager Application Server Control web site will handle a lot of the work of creating these files and populating them with values for us if we choose to use it to create our OC4J instance. The configuration files fall into two categories:

  • OC4J server configuration files Those files that affect the behavior of the OC4J instance

  • Application deployment files Those files that describe the structure of the application we wish to deploy

This chapter will take a look at the OC4J server configuration files. Although it s mentioned briefly in this chapter, the content and directory structure associated with application deployment files will be explored in depth in Chapter 15.

The major advantage of using the Enterprise Manager Application Server Control web site, aside from its graphical user interface (GUI) interface, is its capability to do a lot of the work for us by setting up the location and structure of many of the files needed to configure OC4J instances. If the Enterprise Manager Application Server Control web site is used to create an OC4J instance, the files are created and populated automatically, as shown in Table 2-1.

Table 2-1: OC4J Server Configuration Files

Configuration File

Can Be Viewed and Edited via the Enterprise Manager Application Server Control Web Site

server.xml

Yes; file can be edited on a text editor-like page (see Figure 2-6)

application.xml

No

data-sources.xml

Yes; file can be updated via a web interface

default-web-site.xml

Yes; file can be edited on a text editor-like page (see Figure 2-6)

global-web-application.xml

Yes; file can be edited on a text editor-like page (see Figure 2-6)

http-web-site.xml

No

internal-settings.xml

No

java2.policy

No

jazn-data.xml

Yes; file can be updated via a web interface

jazn.xml

Yes; file can be updated via a web interface

jms.xml

Yes; file can be edited on a text editor-like page (see Figure 2-6)

mime.types

No

oc4j-connectors.xml

No

oc4j.properties

No

principals.xml

No

rmi.xml

Yes; file can be edited on a text editor-like page (see Figure 2-6)

click to expand
Figure 2-6: Page listing configuration files that can be edited via the Oracle Enterprise Manager Application Server Control web site

While it is certainly possible to use command-line tools to create OC4J instances and deploy applications, the approach taken in this book is to use the Enterprise Manager Application Server Control web site to perform these tasks. Oracle strongly recommends using the Enterprise Manager Application Control web site as errors introduced into these files can corrupt your repository.

Note  

If you would like to see the process of configuring the various XML files manually and using the command-line interface to deploy applications, see Oracle9iAS Building J2EE Applications by Nirva Morisseau-Leroy, et al (Osborne Oracle Press, 2002). Although that book is aimed at the version of OC4J included with Oracle9i Application Server Release 2 (9.0.3), the process is, with very minor exceptions, the same. Remember, however, that Oracle strongly recommends using the Enterprise Manager Application Server Control web site to update these files.

The OC4J server configuration files are located in <ORACLE_HOME>/j2ee/<OC4J instance name >/config. They are listed below in alphabetical order except for server.xml, which, among other things, serves to reference other configuration files.

server.xml

This file maintains configuration information about the OC4J server. It is considered to be the root configuration file as it contains references to other configuration files. The configuration parameters specified in a server.xml file include:

  • Library path , located in the application deployment descriptor

  • Global application, global web application, and default web site served

  • Maximum number of HTTP connections the server allows

  • Logging settings

  • Java compiler settings

  • Cluster ID

  • Transaction time-out

  • SMTP host

  • Location of the data-sources.xml configuration

  • Location of the configuration for Java Message Service (JMS), an interface providing point-to-point queuing and publish/subscribe behavior, frequently used by EJBs that need to start another process asynchronously; and Remote Method Invocation (RMI), a technology that allows Java programs to access the objects of another Java program running on a different computer

  • Location of the default and additional web sites

  • Pointers to all applications for the container to deploy and execute

The server.xml provides a good example of the benefits of using the Enterprise Manager Application Server Control web site to deploy applications: every time a new application is deployed to an OC4J instance, an entry must be created in this file. By using the Enterprise Manager Application Server Control web site, the process of updating this file is handled automatically, eliminating possible syntax errors. Here is an example of the server.xml file for the OC4J_Portal instance (the line numbers have been added for discussion after the listing):

 1  <?xml version="1.0" standalone=yes?> 2  <!DOCTYPE application-server PUBLIC "Orion Application Server Config"    "http://xmlns.oracle.com/ias/dtds/application-server-9_04.dtd"> 3  <application-server 4  application-directory="../applications" 5  deployment-directory="../application-deployments" 6  connector-directory="../connectors" 7  > 8  <rmi-config path="./rmi.xml" /> 9  <! Interoperability config link > 10 <sep-config path="./internal-settings.xml" /> 11 <! JMS-server config link, uncomment to activate the JMS service > 12 <jms-config path="./jms.xml" /> 13 <javacache-config path="../../../javacache/admin/javacache.xml" /> 14 <log> 15 <file path="../log/server.log" /> 16 <! Uncomment this if you want to use ODL logging capabilities 17 <odl path="../log/server/" max-file-size="1000" max-directory-     size="10000"/> 18 > 19 </log> 20 <global-application name="default" path="application.xml" /> 21 <application name="jocdemo" path="../applications/jocdemo.ear" auto-start="true" />  22 <application name="ojspdemos" path="../applications/ojspdemos.ear" auto-start="true" />  23 <application name="reportsDemo" path="../applications/reportsDemo.ear" auto-start="true" />  24 <application name="sqljdemos" path="../applications/sqljdemos.ear" auto-start="true" />  25 <application name="jazndemos" path="../applications/jazndemos.ear" auto-start="true" />  26 <application name="BC4JJSPDemo" path="../applications/BC4JJSPDemo.ear" auto-start="true" /> 27 <global-web-app-config path="global-web-application.xml" /> 28 <! <web-site path="./secure-web-site.xml" /> > 29 <web-site default="true" path="./default-web-site.xml" /> 30 <!  Uncomment to add http-web-site, and make sure theres no 31 port confliction among multiple OC4J instances. 32 <web-site path="./http-web-site.xml" /> 33 > 34 <! 35 Demos available for download at: 36 http://otn.oracle.com/tech/java/oc4j/demos/904 37 Refer to the iAS Admin or OC4J Users Guide for details on dcmctl and 38 Oracle Enterprise Manager (EM) tools for J2EE application deployment. 39 > 40 <! Compiler, activate this to specify an alternative compiler such 41 as jikes for EJB/JSP compiling. > 42 <! <compiler executable="jikes" classpath="/myjdkdir/jre/lib/rt.jar" 43 > 44 </application-server> 

All lines beginning with <! “ and terminating with “> are comment lines.

  • Lines 1-2 provide the header and document type definition for the XML parser.

  • Lines 3-7 provide the container with the locations of the various application deployment files relative to directory location of the OC4J server (by default <ORACLE_HOME>/j2ee/<OC4J name>/config).

  • Line 8 provides the location of the RMI (discussed shortly) configuration file.

  • Lines 9-10 provide the location of internal-settings.xml, which specifies server extension provider properties.

  • Lines 11-12 provide the location of the JMS (discussed shortly) configuration file.

  • Line 13 provides the location of the javacache.xml file, which is mainly used to specify the Java Object Cache port number.

  • Lines 14-19 provide the location and parameters of log files associated with this OC4J instance.

  • Line 20 specifies the default name of the default application associated with this OC4J instance. If an application deployed under this instance does not specify a value for a parameter, the application will take the parameter value from what is specified for the default application for the OC4J instance.

  • Lines 21-26 list applications deployed to this OC4J instance.

  • Line 27 specifies the location of the global-web-application.xml file (discussed below).

  • Line 28 is a commented line. If we wanted multiple web sites associated with this OC4J instance, they could be specified like this commented line.

  • Line 29 tells the OC4J server that the web site specified in Line 20 is the default for this OC4J instance.

  • Lines 30-33 are similar to Line 28; we could comment out these lines for an additional web site (see entry for http-web-site.xml below).

  • Lines 34-39 are comments provided by Oracle.

  • Lines 40-43 allow the specification of an EJB/JSP compiler other than the default provided by Oracle.

  • Line 44 is the closing XML tag for the server.xml file.

application.xml

There two categories of application.xml files:

  • Global An application.xml file associated with the OC4J container

  • Local Individual application.xml files associated with each application deployed to that container

This chapter, given we are looking at the creation and administration of OC4J instances, will deal with the global application file. The local application file will be discussed in Chapter 15.

The global application.xml file contains common settings for all applications in a particular OC4J instance. It also defines the location of the security definition file (jazn-data.xml) and the data source definition file (data-sources.xml). Here is an example of a global application.xml file:

 1  <?xml version="1.0" standalone=yes?> 2  <!DOCTYPE orion-application PUBLIC "-//Evermind//DTD J2EE Application    runtime 1.2//EN" "http://xmlns.oracle.com/ias/dtds/orion-application-    9_04.dtd"> 3  <! The global application config that is the parent of all the other 4  applications in this server. > 5  <orion-application autocreate-tables="true" default-data-    source="jdbc/OracleDS"> 6  <web-module id="defaultWebApp" path="../../home/default-web-app"/> 7  <web-module id="dms0" path="../../home/applications/dms0.war"/> 8  <web-module id="dms" path="../../home/applications/dms.war"/> 9  <commit-coordinator> 10 <commit-class class="com.evermind.server.OracleTwoPhaseCommitDriver"/> 11 <property name="datasource" value="jdbc/OracleDS"/> 12 <! Username and password are the optional properties 13 replace with your commit_co-ordinator_super_user 14 <property name="username" 15 value="system" /> 16 <property name="password" 17 value="->pwForSystem" /> 18 > 19 </commit-coordinator> 20 <persistence path="../persistence"/> 21 <! Path to the libraries that are installed on this server. 22 These will be accessible for the servlets, EJBs etc > 23 <library path="../applib"/> 24 <library path="../../../BC4J/lib"/> 25 <library path="../../../jlib/ojmisc.jar"/> 26 <library path="../../../ord/jlib/ordim.jar"/> 27 <library path="../../../ord/jlib/ordhttp.jar"/> 28 <library path="../../../jlib/uix2.jar"/> 29 <library path="../../../jlib/share.jar"/> 30 <library path="../../../jlib/regexp.jar"/> 31 <library path="../../../jlib/jdev-cm.jar"/> 32 <library path="../../../lib/dsv2.jar"/> 33 <library path="../../../rdbms/jlib/xsu12.jar"/> 34 <! Path to the taglib directory that is shared 35 among different applications. > 36 <library path="../../../j2ee/home/jsp/lib/taglib"/> 37 <library path="../../../uix/taglib"/> 38 <library path="../../../lib/oraclexsql.jar"/> 39 <library path="../../../lib/xsqlserializers.jar"/> 40 <! Comment the following element to use principals.xml > 41 <principals path="./principals.xml"/> 42 <log> 43 <file path="../log/global-application.log"/> 44 <! Uncomment this if you want to use ODL logging capabilities 45 <odl path="../log/global-application/" max-file-size="1000" ma 46 x-directory-size="10000"/> 47 > 48 </log> 49 <jazn provider="XML" location="./jazn-data.xml"/> 50 <data-sources path="data-sources.xml"/> 51 <connectors path="./oc4j-connectors.xml"/> 52 <namespace-access> 53 <read-access> 54 <namespace-resource root=""> 55 <security-role-mapping> 56 <group name="administrators"/> 57 </security-role-mapping> 58 </namespace-resource> 59 </read-access> 60 <write-access> 61 <namespace-resource root=""> 62 <security-role-mapping> 63 <group name="administrators"/> 64 </security-role-mapping> 65 </namespace-resource> 66 </write-access> 67 </namespace-access> 68 </orion-application> 
  • Lines 1-2 provide the header and document type definition for the XML parser.

  • Lines 3-4 are comments provided by Oracle.

  • Lines 5-68 provide information that will be used as default settings for all applications deployed in this instance. The tag is called orion-application as the OC4J technology has been licensed by Oracle from IronFlare, makers of the Orion application server.

  • Line 6 specifies the location of any files associated with the default web application.

  • Lines 7-8 specify the location of the Dynamic Monitoring Service (DMS); do not modify these lines.

  • Lines 9-19 specify a Java Database Connectivity (JDBC) data source, a default username and password for that data source, and a Java class to handle transactions. See the data-sources.xml file section below.

  • Lines 20-39 specify the various libraries to be used in the applications deployed in this OC4J instance.

  • Lines 40-41 specify the location of the principals.xml file. See the principals.xml file section below.

  • Lines 42-48 specify logging information for all applications deployed to this OC4J server.

  • Line 49 specifies the location of the jazn-data.xml file. See the jazn-data.xml file section below.

  • Line 50 specifies the location of the data-sources.xml file. See the data-sources.xml file section below.

  • Line 51 specifies the location of the oc4j-connectors.xml file. See the oc4j-connectors.xml file section below.

  • Lines 52-67 specify the namespace (naming context) security policy for RMI clients , resources with specific security settings, and the run-time mapping (to groups and users) of a role.

  • Line 68 is the closing XML tag for the application.xml file.

data-sources.xml

This file provides configuration information for data sources used by applications deployed in this OC4J instance. In addition, it contains information on how to retrieve JDBC connections. In the data-sources.xml file, you can specify the following:

  • JDBC driver

  • JDBC URL

  • Java Naming and Directory Interface (JNDI) paths to which to bind the data source. JNDI is a set of Application Programming Interfaces (APIs) that assists with the interfacing to multiple naming and directory services.

  • User/password for the data source

  • Database schema to use

  • Inactivity time-out

  • Thread policy

  • Garbage collection granularity

  • Maximum number of connections allowed to the database

Tip  

Creating JDBC connections with data sources is described in detail in Chapter 13.

Here is an example of a data-sources.xml file:

 1  <?xml version="1.0" standalone=yes?> 2  <!DOCTYPE data-sources PUBLIC "Orion data-sources"    "http://xmlns.oracle.com/ias/dtds/data-sources-9_04.dtd"> 3  <data-sources> 4  <! 5  An example/default DataSource that uses 6  Oracle JDBC-driver to create the connections. 7  This tag creates all the needed kinds 8  of data-sources, transactional, pooled and EJB-aware sources. 9  The source generally used in application code is the "EJB" 10 one - it provides transactional safety and connection 11 pooling. Oracle thin driver could be used as well, 12 like below. 13 url="jdbc:oracle:thin:@host:port:sid" 14 > 15 <data-source 16 class="com.evermind.sql.DriverManagerDataSource" 17 name="OracleDS" 18 location="jdbc/OracleCoreDS" 19 xa-location="jdbc/xa/OracleXADS" 20 ejb-location="jdbc/OracleDS" 21 connection-driver="oracle.jdbc.driver.OracleDriver" 22 username="scott" 23 password="->pwForScott" 24 url="jdbc:oracle:thin:@localhost:1521:oracle" 25 inactivity-timeout="30" 26 /> 27 </data-sources> 
  • Lines 1-2 provide the header and document type definition for the XML parser.

  • Line 3 is the beginning of the data sources specification.

  • Lines 4-14 are comments provided by Oracle.

  • Lines 15-16 specify the class containing JDBC driver manager.

  • Line 17 specifies the name of the data source (referenced in Line 11 of the global application.xml file).

  • Lines 18-20 are the location, xa-location, and ejb-location attributes. These are JNDI names that this data source is bound to within the JNDI namespace. While all three must be specified, Oracle recommends that only the ejb-location JNDI name in the JNDI lookup for retrieving this data source be used.

  • Line 21 specifies the class containing the actual JDBC driver.

  • Lines 22-24 specify the default connection information for the JDBC driver.

  • Line 25 specifies the parameters associated with this JDBC driver specification.

  • Line 26 is the closing XML tag for this data source.

  • Line 27 is the closing XML tag for the data-sources.xml file.

default-web-site.xml

Multiple web sites, under the control of a single server.xml file, can be defined. Each of these web sites can have its own configuration files and act independently of the other web sites. If only one web site is used, the configuration parameters for that web site will come from this file. If multiple web sites are used, a file called web-site.xml can be used to specify different parameters. Each web site that is recognized by the server has a web site XML file to configure it. In Oracle Application Server, there is just one web site. OC4J standalone is a separate download available from Oracle that provides just the OC4J containers included with Oracle Application Server 10 g . In the OC4J standalone, there is typically one web site; however, you might use a second web site for shared applications. For example, you might do this where some communication is through HTTP and some through HTTPS. It is also possible for there to be no web sites, if the OC4J instance is not used for web modules. The default-web-site.xml file provides configuration information for a default web site and contains the following:

  • Host name or IP address, virtual host settings for this site, listener ports, and security using Secure Sockets Layer (SSL)

  • Default web application for this site

  • Additional web applications for this site

  • Access-log format

  • Settings for user web applications (for /~user/ sites)

  • SSL configuration

  • Restrict access to the site from one or more hosts

 1  <?xml version="1.0" standalone=yes?> 2  <!DOCTYPE web-site PUBLIC "OracleAS XML Web-site"    "http://xmlns.oracle.com/ias/dtds/web-site-9_04.dtd"> 3  <! change the host name below to your own host name. Localhost will    > 4  <! also add cluster-island attribute as below 5  <web-site host="localhost" port="0"  protocol="ajp13" 6  display-name="OracleAS Java Web Site" cluster-island="1" > 7  > 8  <web-site port="0"  protocol="ajp13" 9  display-name="OracleAS Java Web Site"> 10 <! Uncomment the following line when using clustering > 11 <! <frontend host="your_host_name" port="80" /> > 12 <! The default web-app for this site, bound to the root > 13 <default-web-app application="default" name="defaultWebApp"    root="/j2ee" 14 /> 15 <web-app application="default" name="dms" root="/dmsoc4j" /> 16 <! Access Log, where requests are logged to > 17 <access-log path="../log/default-web-access.log" /> 18 <! Uncomment this if you want to use ODL logging capabilities 19 <odl-access-log path="../log/default-web-access" max-file-size="1000"    ma 20 x-directory-size="10000"/> 21 > 22 </web-site> 
  • Lines 1-2 provide the header and document type definition for the XML parser.

  • Lines 3-8 are comments provided by Oracle.

  • Lines 9-10 specify parameters to be used by the default web site associated with this OC4J instance. ajp13 in Line 9 stands for Apache JServ Protocol (version 1.3).

  • Lines 11-12 are comments showing how to configure OC4J clustering.

  • Lines 13-15 are information about the default web application deployed to the default web site associated with this OC4J instance.

  • Line 16 is information about the DMS application referenced in Line 8 of application.xml.

  • Lines 17-22 provide logging information regarding this web site.

  • Line 23 is the closing XML tag for the default-web-site.xml file.

global-web-application.xml

This file contains OC4J-specific global web application configuration information that contains common settings for all web modules in this OC4J instance.

http-web-site.xml

This is the default web site descriptor in an OC4J standalone environment. As this book concerns itself with Oracle Application Server 10 g , it is not discussed.

jazn.xml and jazn-data.xml

These files provide security information for the Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider. JAAS is a set of Java packages that enable services to authenticate and enforce access controls upon users. These files define the user and group configuration for employing JAZNUserManager, the default user manager with the primary purpose of leveraging the JAAS Provider as the security infrastructure for OC4J. The jazn.xml file tells OC4J which data source to use, although by default, OC4J uses the jazn-data.xml file. The following are specified in the jazn-data.xml file:

  • Username and password for the client-admin console

  • Name and description of users/groups, and real name and password for users

jms.xml

This file contains the configuration for the OC4J Java Message Service (JMS) implementation. JMS is an interface to provide point-to-point queuing and topic (publish/subscribe) behavior. JMS is frequently used by EJBs that need to start another process asynchronously. In the jms.xml file, specify the following:

  • Host name or IP address, and port number to which the JMS server binds

  • Settings for queues and topics to be bound in the JNDI tree

  • Log settings

oc4j-connectors.xml

This file contains global OC4J-specific configuration for connectors. Sun Microsystems defines a connector as a standard extension mechanism for containers to provide connectivity to enterprise information systems . A connector is specific to an enterprise information system and consists of a resource adapter and application development tools for enterprise information system connectivity. The resource adapter is plugged into a container through its support for system-level contracts defined in the connector architecture.

principals.xml

By default, the JAAS Provider types (discussed in the jazn-data.xml section above) are used to enable services to authenticate and enforce access controls upon users. In the orion-application.xml file (discussed in Chapter 15), you can specify the <principals> element to tell OC4J to use the UserManager described in a principals file, normally principals.xml. A <principals> element in the orion-application.xml file has one attribute, <path>, which specifies a path for the principals file, normally principals.xml. For example, <principals path= myprincipals.xml />.

The principals.xml file contains a <principals> element; this contains two sub-elements, <groups> and <users>. The <groups> element contains one or more <group> elements, and the <users> element contains one or more <user> elements. Groups in principals.xml correspond to roles in the JAAS Provider. The principals.xml file does not support any equivalent of the JAAS Provider s concept of realms. Permissions granted to groups may be checked explicitly, and OC4J does check for the special permissions listed above. However, group permissions are not integrated with the usual permission checking performed by a Security Manager. The XMLUserManager class is supported for backward compatibility in that Oracle recommends you use one of the JAAS Provider types. Figure 2-7 shows how to specify the User Manager for a deployed application. Figure 2-8 shows the Security page for an application where users, groups, and roles can be entered, modified, and deleted via the web interface.

click to expand
Figure 2-7: The User Manager section of the Properties page of a deployed application in the Enterprise Manager Application Server Control web site
click to expand
Figure 2-8: The Security page for a deployed application

rmi.xml

This file provides configuration information for the RMI system. RMI enables communication between different Java programs running in different JVMs, or in our case, different OC4J instances. This can be incredibly useful for creating distributed applications. Say, for instance, you have created an application that uses critical business logic encapsulated in an EJB. A second application needs the same business logic. If you have coded your EJB with enough flexibility to satisfy the request of the second application, you can use RMI to remotely call (invoke) the EJB and get access to its logic. OC4J supports RMI over HTTP, a technique known as RMI tunneling . By using the technique of encapsulating RMI calls within an HTTP POST request, Java programs can make outgoing RMI calls without being stopped by a local firewall. The following are specified in the rmi.xml file:

  • Host name or IP address, and port number to which the RMI server binds

  • Remote servers to which to communicate

  • Clustering settings

  • Log settings

Here is an example of an rmi.xml file:

 1  <?xml version="1.0" standalone=yes?> 2  <!DOCTYPE rmi-server PUBLIC "Orion RMI-server"    "http://xmlns.oracle.com/ias/dtds/rmi-server-9_04.dtd"> 3  <rmi-server port="23791" > 4  <! A remote server connection example > 5  <! <server host="the.remote.server.com" username="adminUser"    password="123abc" /> > 6  <! path to the log-file where RMI-events/errors are stored > 7  <log> 8  <file path="../log/rmi.log" /> 9  <! Uncomment this if you want to use ODL logging capabilities 10  <odl path="../log/rmi/" max-file-size="1000" max-directory-size= 11 "10000"/> 12 > 14 </log> 15 </rmi-server> 
  • Lines 1-2 provide the header and document type definition for the XML parser.

  • Line 3 specifies the port RMI will communicate on.

  • Lines 4-6 are comments provided by Oracle providing an example of how to configure an RMI server. The host specified in Line 5 is where the remote method exists.

  • Lines 7-13 specify logging information for the RMI process.

  • Lines 14 is the closing XML tag for the rmi.xml file.

Creating an OC4J Instance

To create an OC4J instance, click the Create Instance button on the top right of Figure 2-9. When you create an OC4J instance, an OC4J home page for configuring and managing your OC4J instance is created, along with the necessary files to configure the new instance. Each OC4J instance has its own OC4J home page. You can drill down to any of the running OC4J instances by selecting the name of the instance in the System Components table. The Application Server Control displays the OC4J home page for that instance (see Figure 2-9).

click to expand
Figure 2-9: The home page for an OC4J instance

As you can see, the Home tab shows basic metrics regarding the OC4J instance. Other than the Start (not pictured because the OC4J instance is currently running), Stop, and Restart buttons , there is not much you can do to the OC4J. The Applications tab (see Figure 2-10) gives us a lot more opportunity to actively work with our OC4J instance.

click to expand
Figure 2-10: The Applications tab of an OC4J home page

In this tab, we can view and get information about applications deployed to this OC4J instance. Also of note are the Deploy EAR file and Deploy WAR file buttons in the top right of the page. Clicking these buttons will start wizards that will do much of the work of configuring the various deployment files we will need to successfully deploy our application.

Java Archive Files (EAR, WAR, and JAR files)

What, exactly, are EAR and WAR files? E nterprise Ar chive (EAR) and W eb Ar chive (WAR) files are special types of J ava Ar chive (JAR) files that incorporate the different types of Java components (or programs) that comprise your application. It is not uncommon to have an application use a number of different Java technologies: for example, EJBs to store business logic and JSPs to handle the look and feel of an application and compiled class files that make up a servlet. Each of these components must be stored in a structured set of directories, with various directories containing .xml files describing the contents of subdirectories. Once these directories, XML files, and various Java files are in the correct locations, they can be grouped together into a single file using the jar command-line utility. In Chapter 15, we will look at the creation of an application with various Java components and how the jar utility is used to create an EAR or a WAR file.

The difference between an EAR file and a WAR file depends on the types of Java components that make up your application, and thus define your application type. An application that does not contain EJBs is considered a web application and is usually deployed as a WAR file. An application that contains EJBs is considered an EJB (or Enterprise) application, and is deployed as an EAR file (see Table 2-2). Note that we said that web applications are usually deployed as WAR files ”you could deploy a web application as an EAR file by leaving the directories for EJB modules empty. This is commonly referred to as wrapping a WAR file into an EAR file. If the application contains EJBs, however, it must be deployed as an EAR file. EAR files are further complicated by the fact that they contain WAR files ”the web-tier components of the application.

Table 2-2: Java Components and Their Deployment Locations

Technology

Service Category

Purpose

Where Deployed

HTML, images, PDFs, etc.

Communication Services

Present the user interface of the application

WAR file

JSPs, servlets

Presentation Services

Build dynamic pages, maintain state, control page flow

WAR file

EJBs

Business Logic Services

Maintain business rules for application

EAR file

Note  

The method of wrapping a WAR file into an EAR file is what Oracle does when you click the Deploy WAR file button on the home page for the OC4J container.

Note  

Technically, you could deploy your applications without first grouping them into an EAR or WAR file. This is referred to as deploying an exploded (or expanded) directory. There is certainly nothing wrong with this approach, but it has been the authors experience that the use of EAR and WAR files makes development, deployment, and maintenance of applications a much simpler process. If you choose to do your Java development using Oracle JDeveloper 10g, most of the steps needed in the packaging of EAR and WAR files can be handled automatically.

The question then becomes, Should my application contain EJBs or not? There is, unfortunately , no definitive answer to this question. In general, applications with EJBs are much more complex and require a greater effort to code, test, and implement, but have a much higher level of scalability ”the measure of a system s capability to handle a greater load by applying more hardware to it. A number of questions regarding development resources, in-house knowledge, desired flexibility, and maintainability of the application will have to be addressed before beginning any design and development work.

Building applications using EJBs is closer to the spirit of the J2EE specification, which encourages distributing an application s various technologies among discrete tiers outlined in the services discussed in Chapter 1 and in Table 2-2. By using EJBs, the presentation layer remains thin (less code) while the business logic layer is robust (more code). In a web application, the presentation layer contains the business logic (violating the basic J2EE premise that encourages the separation of business and presentation logic) and the business logic layer is not used at all.

The simpler of the two types of files is the WAR file. A WAR file contains all web-tier components for a J2EE application (see Table 2-2), including servlet .class. EAR files have the added functionality of giving the developer the option of either deploying the entire EAR file or just deploying selected components of the EAR file. Figure 2-11 depicts an application directory structure.

click to expand
Figure 2-11: A development directory structure

The directory names enclosed in <> are arbitrarily named. The directories and filename in italics must be named exactly to the specification. If your application does not contain any EJBs, you can create a WAR file by running the JAR utility from the <web module> directory. You can create an EAR file by running the JAR utility from the < appname > directory. It is important to note that the application.xml file in the META-INF directory is the local application.xml file, which serves a different purpose than the global application.xml file discussed earlier in this chapter. The content and structure of the italicized files in Figure 2-11 will be explored in detail in Chapter 15.



Oracle Application Server 10g Web Development
Oracle Application Server 10g Web Development (Oracle Press)
ISBN: 0072255110
EAN: 2147483647
Year: 2004
Pages: 192

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net