Deploying J2EE Applications

In this week’s part of a multi-part series covering OC4J and J2EE applications, you will learn how to deploy J2EE applications, create data sources, and more. This article is excerpted from chapter eight of the Oracle 10g Application Server Exam Guide, written by Sam Alapati (McGraw-Hill; ISBN: 0072262710).

CERTIFICATION OBJECTIVE 8.07

Deploying J2EE Applications

Oracle recommends that you use consistent and meaningful naming conventions when developing Web applications. You must create your applications as a set of modules and place them under a directory that’s named for the application. All your directories under the main application directory should be consistent with the directory structure for creating the necessary JAR, WAR, and EAR archives to facilitate the archiving of the application modules. Here’s the standard development application directory structure for J2EE-based Oracle applications:

  Applications/<application_name>/
             META-INF
                   application.xml
            <ejb_modules>/
                   EJB classes
                   META-INF/
                       ejb-jar.xml
                       orion-ejb-jar.xml 
            <web-module>/
               index.html
               JSP pages
               WEB-INF/
                 |      web.xml
                 |     orion-web.xml
                 |     classes/
                 |      —-Servlet classes
                 |—————Lib/  
  <client_module>/
            Client classes
           
META-INF/
                
|
                
———   application-client.xml
                           
orion-application-client.xml

Note that the application.xml file, which is the main application descriptor file, defines each of the modules. When you create a directory structure such as the one shown here, the modules are easily distinguishable from each other. For example, the EJB package class "testapp.ejb.Prod" should be located in the directory <testapp>/<ejb_module>/testapp/ejb/Prod.class.

Deployment Methodologies

As mentioned previously, you can deploy Web applications as well as EJB applications through OC4J. You can deploy applications through the Application Server Control, or by using the dcmctl utility. The recommended approach is to use the Application Server Control. You can also deploy applications by manually editing the configuration files, of course, as well as by unpacking the deployment archive files in their deployment directories.

Data Sources

A data source is an object that lets you retrieve a connection to a database server. Data sources are encapsulations of connections to a database server, and they are instantiations of objects implementing the javax.sql.dataSource interface. Data source objects are bound to the JNDI name space, and the J2EE applications use the JNDI tree to look up various DataSource objects. Data sources offer you portable methods for creating JDBC connections across servers.

on the job:  Because of their vendor-independent nature, Oracle Corporation recommends that you use data sources to retrieve database server connections.

{mospagebreak title=Types of Data Sources}

There are three types of data sources you can use in OC4J:

  • Emulated data sources
  • Non-emulated data source
  • Native data sources

Emulated Data Sources   Emulated data sources emulate the XA (Transactional) protocol for JTA ( Java Transaction API) transactions and offer features such as OC4J caching and pooling and Oracle JDBC extensions (for Oracle databases). The need for emulated data sources arose because many JDBC drives didn’t offer XA capabilities in earlier days.

An emulated data source doesn’t provide full XA global transactional support, such as the two-phase commit, which is unsupported under emulated data sources. However, because they lack full transactional support, emulated data source connections tend to be quite fast in nature. If you’re using local transactions or global transactions that don’t require the two-phase commit mechanism, emulated data sources are the recommended type of data source for you to use.

The following is a data-sources.xml configuration entry for an emulated data source:

  <data-source 
      class=
"com.evermind.sql.DriverManagerDataSource"
      name=ÓOracleDSÓ
      location="jdbc/OracleCoreDS"
      xa-location="OracleDS"
      ejb-location="jdbc/OracleDS"
      connection-driver="oracle.jdbc.driver.OracleDriver"
      username="scott"
     
password="tiger"
      url="jdbc:oracle:thin:@// localhost:5521/oracle.regress.
  rdbms.dev.us.oracle.com"
     
inactivity-timeout=Ó30Ó
  />

Although you specify values for the location, ejb-location, and xa-location attributes when configuring an emulated data source in your data-source.xml file, you must only use the value specified by the ejb-location attribute when looking up that emulated data source. By now, you’re well aware that you use a JNDI tree to look up a data source. You must look up a data source in the following way (only the "jdbc/OracleDS" value is used in the JNDI lookup):

 

  Context ic = new InitialContext(); 
  DataSource ds = (DataSource) ic.lookup("jdbc/OracleDS");

Or this:

DataSource ds = (DataSource) ic.lookup("java:comp/env/jdbc/OracleDS");
Connection con = ds.getConnection();

exam watch:  In the data-sources .xml file,
you must specify values for the location, xa-location, and ejb-location attributes. The first two attributes, however, are actually deprecated now, and only the value you specify for ejb-location is actually used as the location string. To be used in a JNDI lookup for retrieving the data source. Applications, EJBs, Servlets, and JSPs should use the ejb-location value to look up emulated data sources in the JNDI tree.

on the job:  If you want true two-phase commits in your transactions, you must use a non-emulated data source.

Non-Emulated Data Sources   A non-emulated data source provides full JTA services, meaning that the two-phase commit mechanism is provided as well. Oracle Corporation recommends you use non-emulated data sources. A non-emulated data source provides higher recovery and reliability as well as distributed database features, unlike the emulated data sources. Note that to run a non-emulated data source, you must use a Java-enabled database, such as the Oracle Database.

Here’s a typical data-sources.xml file for a non-emulated data source:

<data-source  
  class= "com.evermind.sql.OrionCMTDataSource"
  location="jdbc/OracleDS"
  connection-driver="oracle.jdbc.driver.OracleDriver"
  username="scott"
  password="tiger" 
  url="jdbc:oracle:thin:@//localhost:5521/ oracle.regress.rdbms.dev.us.oracle.com"

</data-source>

Note that JNDI lookups are performed using the value of the location attribute in the data-sources.xml file.

In the data-sources.xml file,

  • Location refers to the JNDI name bound to the data source in the JNDI name spaces.
  • The url, username, and password attributes refer to the database and default user name and password for retrieving connections to the database.
  • Class is the type of data source class to bind in the name space.

Native Data Sources   Native data sources are supplied by JDBC vendors, and are used to implement data sources. Vendors provide extensions to facilitate capabilities such as caching and pooling. OC4J supports native data sources, but because they don’t provide JTA services such as commits and rollbacks, they can’t be used in global transactions. Here’s how a data-sources.xml file looks for a native data source:

  <data-source 
      class= "com.my.DataSourceImplementationClass"
      name=ÓNativeDSÓ
      location="jdbc/NativeDS"
      username="user"
      password="pswd"
      url="jdbc:myDataSourceURL"
 
</data-source>

Exam watch:  Native data sources don’t support JTA transactions. Both emulated as well as non-emulated data sources support JTA transactions, but only the non-emulated data sources support true two-phase commit (an emulated data source can only emulate a two-phase commit).

You can manage data sources through the Application Server Control’s Application Data Sources page. You can reach this page by clicking the Administration tab on the OC4J home page, and then clicking on Data Sources under the Application Defaults section. From the Application Data Sources page, you can perform the following functions:

  • View data source information for all applications, including the data source name, the JNDI location, and class and JDBC Driver information.
  • Create, delete, and modify data sources.
  • View performance statistics for data sources (only for non-emulated data sources).

The Data Sources page can be used to connect top Oracle as well as non-Oracle databases. For Oracle database connections, you must either configure a non-emulated Data Source that is purely Oracle based or use an emulated Data Source, which involves a wrapper around an Oracle Data Source.

on the job:  Use the com.evermind.sql.DriverManagerDataSource with the Merant JDBC drivers to connect to Oracle databases.

{mospagebreak title=Creating Data Sources}

I’ll briefly describe how you can create data sources using the Application Server Control. Here are the steps:

  1. Go to the OC4J home page, click the Administration tab, and then click Data Sources.
  2. In the Application Data Sources page, click the Create button (you can also click the Create Like button if you want to pattern a new data source after an existing one).
  3. There are several sections in the Data Source Properties page (actually titled Create Data Source), which appear next. In the General section, fill in the name and description of the data source as well as the following information: 

    • Data source class
    • JDBC URL
    • JDBC driver
    • Schema

On the Job:  Your default data-sources.xml file provides predefined data sources that may suit your needs.

  1. In the Data Source Username and Password section, specify the username and password using the schema you chose in the previous section.
  2. In the JNDI Locations section, you specify the JNDI location string that is used for JNDI tree lookups when the application is retrieving the data source. Of the three attributes—Location, Transactional (XA) Location, and EJB Location—you are required to specify only the Location attribute. If you plan on having the EJBs use the database for Container Managed Persistence (CMP), you must specify the XA and EJB Location attributes. For a non-emulated data source, you must specify all three JNDI location attributes, although only the ejb-location is actually used.
  3. In the Connection Attributes section, you specify various connection-related attributes, such as the following:

    • Connection retry interval

    • Maximum connection attempts
    • Inactivity timeout period
    • Maximum and minimum number of open connections

  4. In the Properties section, you can specify properties for any custom or third-party data source you may be configuring.
  5. Once you have made the necessary configuration, click the Create button to create your new data source.

A DataSource object is used by developers to provide a logical representation of a database. It’s the job of the deployer to map this logical representation to a physical database. Using the logical DataSource object to look up the JNDI, the J2EE applications will retrieve the database names so they can connect to them. The deployer first uses the J2EE application file (EAR file), to locate the DataSource references in the deployment descriptor. The deployer will then create mappings between the database schemas matching the DataSource requirements, so the application can connect to it.

You must use an emulated data source for a single-phase commit, and you can utilize the default data source (data-sources.xml) for this purpose. Here’s the default data-sources.xml file:

  <data-source
 
   class= "com.evermind.sql.DriverManagerDataSource"
    name="OracleDS"
    location="jdbc/OracleCoreDS"
    xa-location="jdbc/xa/OracleXADS"
    ejb-location="jdbc/OracleDS" 
    connection-driver="oracle.jdbc.driver.OracleDriver"
    username="scott"
    password="tiger" 
    url= "jdbc:oracle:thin:@//localhost:1521/ORCL"
    inactivity-timeout="30"
  />

Plug in your database URL information instead of the default URL shown in the data-sources.xml file. You must do this for each of the databases that are part of the transaction. The data source retrieval, as mentioned earlier, is done through a JNDI lookup. The JNDI name is shown by the ejb-location attribute.

Retrieving the Data Source Connection   Your first task before using the database for queries is to retrieve a connection to the database. To retrieve the database connection, you can perform a lookup on the JNDI name bound to the data source definition. Note that you may also perform a JNDI lookup by looking up the logical name that you defined in the environment of the bean container. You retrieve the database connection using the getConnection method. Using the data source definition, for example, you retrieve a database connection as follows:

  Context ic = new InitialContext();
  DataSource ds = (DataSource) ic.lookup("jdbc/OracleDS");
  Connection conn = ds.getConnection();

Because the data source already contains the username and password attributes, you can use the getConnection method without the username/password attributes.

{mospagebreak title=Managing Data Sources}

Here are the steps that enable you to manage data sources using the OC4J home page of the Application Server Control:

  1. On the OC4J home page, click the Administration tab.
  2. In the Application Defaults section, click Data Sources.
  3. In the Application Data Sources page (titled Data Sources), you’ll see a list of all the available global data sources, which all the deployed applications can use. Figure 8-5 shows the Data Sources page. Notice the OracleDS default data source shown in that page, which is an emulated data source. This means that applications can use only a specific database through this data source. A non-emulated data source will let the application access multiple databases.
  4. You can create a new data source by clicking the Create button or edit a data source by clicking the Edit button in the Data Source Properties page. You’ve already seen how you can create a new data source in the previous section. Let’s see how you can edit a data source’s properties by using the Edit Data Source page, which you reach by clicking the Edit button.
  5. In the Edit Data Source page, shown in Figure 8-6, you can configure data sources so they are mapped to Oracle and non-Oracle databases. You can configure the following data source-– related attributes from this page:


    Figure 8-5.  The Data Sources Page



    Figure 8-6.  The Edit Data Source Page
    • Data source name
    • Data source class
    • JDBC URL
    • Database username and password
    • JNDI locations
    • Connection attributes

Now that you have learned how to create and manage data sources, let’s turn to a discussion of the deployment methodologies for Web and EJB applications in the following subsections.

{mospagebreak title=Deploying Web Application Modules}

You can use either the Application Server or the dcmctl utility to deploy Web applications. In the following subsections, examples are given of both approaches to Web application deployment.

Using the dcmctl Utility

Using the dcmctl utility, you can deploy, undeploy, and redeploy Web applications by using the supplied WAR files. Here’s an example showing how to use dcmctl to deploy a WAR file:

  dcmctl deployapplication -file /test/testapp.war -a testapp
  -co home -rc /myiAS/myWebapps

In the preceding dcmctl command, the various options stand for the following:

  • file refers to the WAR file (it could also be an EAR file) that you want to deploy.
  • a refers to the name of the application being deployed (testapp in our example). 
  • -co (component name) specifies the OC4J instance to which this WAR file will be deployed. If you leave this parameter out, the application will, by default, be deployed to the home OC4J instance.
  • The -rc option specifies the base path a URL will use to access the Web module (for example, http:// hostname:port/context_root) you are deploying. Note that the -rc option applies only when you’re deploying WAR files.

Note that you mustn’t use the -rc option when deploying EAR files.

To redeploy a Web application, use the dcmctl command as in the foregoing example, but with the redeployApplication option instead of the deployApplication option. To undeploy an application, use the undeployApplication option.

Using the Application Server Control

You deploy WAR files in order to deploy Web applications. However, when you deploy a WAR file for the first time, the Application Server Control wraps the application in an EAR file, thus making it a J2EE application. Use the following steps to deploy a Web application through the Application Server Control’s Deploy Web Application page, which displays a list of all OC4J applications deployed on the OC4J server:

  1. Go to the OC4J home page and click the Applications tab.
  2. In the OC4J server Applications page, click the Deploy WAR file, under the Deployed Applications section.
  3. In the Deploy Web Applications page, supply the path to the Web application, the Web application’s name, and the URL it should be mapped to. Figure 8-7 shows the Deploy Web Application page.


    Figure 8-7.  The Deploy Web Application Page
  4. Click the Deploy button to deploy the Web application.
  5. Note that once you deploy a Web application file through the Application Server Control, you can’t redeploy it by using the EAR file created for it by the Application Server Control. You must first undeploy the application and then deploy the WAR file again.

Please check back next week for the conclusion to this article.

Google+ Comments

Google+ Comments