Managing OC4J and Configuring J2EE Applications

This article will help you get a better grasp of how Oracle Application Server 10g supports Java 2EE applications. It is excerpted from chapter eight of the book Oracle 10g Application Server Exam Guide, written by Sam Alapati (McGraw-Hill; ISBN: 0072262710).

Oracle Application Server 10g provides support for Java 2 Platform, Enterprise Edition (J2EE) applications, and support for J2EE is a crucial and integral part of Oracle Application Server 10g. This chapter is devoted to explaining how J2EE applications work and how the OracleAS component OC4J (Oracle Containers for Java) provides support for enterprise J2EE applications. This is in addition to supporting the work of several other OracleAS components, such as the OracleAS Portal and Delegated Administrative Services (DAS).

CERTIFICATION OBJECTIVE 8.01

Introduction to J2EE

The Java 2 Platform, Enterprise Edition (J2EE) offers a component-based framework for designing, developing, and deploying Web-based enterprise applications. J2EE defines the specification for EJBs. J2EE is a set of Java technologies, with each of them being designed for a specific purpose, such as providing security, enabling transactions, or sending email. Let’s start our review of J2EE with a short summary of the various J2EE components.

J2EE Components

In this section, the main J2EE components are explained. In addition, I explain how Oracle Application Server 10g supports each of these essential features.

Java Authentication and Authorization Service

The Java Authentication and Authorization Service (JAAS) is Java’s security package, which provides user authentication and user access control capabilities. OC4J implements JAAS order to provide developers a way to offer secure access to J2EE applications. You can also integrate Oracle’s implementation of JAAS with the OracleAS Single Sign-On and the Oracle Internet Directory.

Java Transaction API

Java Transaction API (JTA) is the specification of standard Java interfaces between a central transaction monitor and all the parties in a distributed transaction system. JTA is used by applications deployed in the OracleAS to demarcate transactions. For single database-based transactions, JTA helps provide the Single-Phase Commit to demarcate transactions and for transactions involving multiple databases, JTA provides the Two-Phase Commit mechanism. As you’ll see later, OracleAS lets you use non-emulated databases to provide support for the Two-Phase Commit mechanism.

Java Naming and Directory Interface

The Java Naming and Directory Interface (JNDI) is an independent directory service that enables Java applications to access various naming and directory services with a common Application Programming Interface (API). OC4J implements the JNDI service to provide necessary naming and directory functionality to applications.

Java Message Service

The Java Message Service (JMS) provides standard messaging API, which enables application components to pass data among themselves. Java programs use JMS to access enterprise message systems. JMS helps you integrate heterogeneous systems using the standard messaging API.

Remote Method Invocation

Remote Method Invocation (RMI) helps distributed applications communicate through invoking procedure calls. Using RMI, methods of Java objects can be invoked remotely from other Java Virtual Machines. OC4J provides RMI support over two protocols: the Oracle Remote Method Invocation (ORMI) protocol and the Internet Inter-ORB Protocol (IIOP). EJBs, by default, use the RMI/ORMI protocol to communicate, instead of the alternative RMI/IIOP protocol.

Data Sources

Data sources are encapsulations of database server connections that help provide database connectivity to your J2EE applications. OracleAS provides support for emulated and non-emulated data sources, which are discussed in detail later in this chapter.

Java Transaction API

EJBs use Java Transaction API (JTA) 1.0.1 for managing transactions. These transactions involve single-phase and two-phase commits.

J2EE Connector Architecture

The J2EE Connector Architecture (J2CA) provides a standard architecture for connecting the J2EE platform to non-Java-based enterprise systems such as ERPs and relational database management systems and legacy applications.

Java Object Cache

The Java Object Cache provides Java classes to improve performance by caching local copies of Java objects within a process.

Terminology

Because the main topic in this chapter, OC4J, is all about enabling J2EE-based applications, it’s important for the reader to understand the common terminology used when dealing with J2EE applications. The following sections are devoted to that.

Servlets

Servlets are small programs that run on the server, and you use them to enable dynamic content in your Web pages or JSP documents. During their execution, servlets can access the Enterprise Java Beans (which are defined later).

Java Server Pages

Java Server Pages are HTML pages that contain embedded Java code.

JavaBeans

JavaBeans are reusable components that implement the functionality you need in J2EE applications. You can use various JavaBeans in your J2EE applications.

J2EE Containers

A J2EE container contains the framework for running EJBs, such as starting an EJB, and provides necessary support services for the EJB to perform its magic. OC4J is one type of J2EE container, and you’ll learn a lot about it later in this chapter.

{mospagebreak title=Enterprise JavaBeans}

Enterprise JavaBeans (EJBs) are Java components that implement business logic. EJBs follow JavaSoft’s specifications. You use Enterprise JavaBeans to implement the business logic in your J2EE applications. While you must use JavaBeans as part of an application, Enterprise JavaBeans are self-contained J2EE components that can service users’ requests. EJBs live inside, and are always run inside, an EJB container, which provides the necessary support infrastructure, such as connectivity to clients and other EJBs, as well as access to server resources, connectivity, and transactional support.

Note that you must deploy an EJB inside a J2EE container, unlike regular JavaBeans. A client application can access an EJB, which contains the business logic, only through a container.

An EJB can either use JDBC connections to connect directly to a database or let the container handle the database connectivity for it. The container holding an EJB is responsible for satisfying requests made by clients by either instantiating an EJB afresh, or letting the client access an already running EJB. The container will maintain the transactions, security issues, and other EJB operational details.

There are three basic types of Enterprise JavaBeans, which are described briefly in the following subsections.

Session EJBs   Session EJBs support a client during the execution of its tasks and last only as long as the client’s session does. You can have stateful or stateless EJBs. A stateless session EJB won’t store the state between method calls, whereas a stateless session EJB maintains state. Each stateful EJB is associated with a single client only.

Entity EJBs   Entity EJBs represent an object of data, usually of a persistent nature, such as the table rows in a database. Similar to database data, Entity EJBs have a primary key to uniquely identify them. Usually, the container wherein the Entity EJBs resides will implement the database connectivity for the entity EJBs.

Entity EJBs can reflect two types of persistence: container-managed persistence (CMP) and bean-managed persistence (BMP). Persistence in this context refers to database transactions. When session beans choose container-managed persistence, the bean writer declares necessary transaction attributes in the deployment descriptor. The EJB container then manages the transactions automatically, without the bean writer having to write code for transaction management. Under bean-managed persistence, the user transaction interface is used to manage transactions. The bean writer decides when, exactly, the transactions are committed or rolled back instead of the container itself deciding it. The recommended approach is to use CMP in preference to BMP.

Message-Driven EJBs   Message-Driven EJBs represent the integration between Java Message Service (JMS) and EJBs. These EJBs perform asynchronous messaging within the server, serving as JMS Message Listeners instead of interacting directly with clients and becoming involved in client transactions. When clients publish messages to JMS destinations, the JMS provider and the EJB container coordinate their work in delivering the message to the message-driven EJBs.

With this quick review of J2EE, let’s turn our attention to OC4J, which is the framework for the development and deployment of EJB applications in the Oracle Application Server.

{mospagebreak title=Deploying EJBs}

You deploy EJBs as well as all the other components of your J2EE application by packaging together all the necessary modules for an application. You put all relevant components into a zipped file, ending with a specific extension denoting the type of file; the Java Virtual Machine will then execute that single file. J2EE applications can have three types of application deployment files, also called archives: JAR files, WAR files, and EAR files.

JAR Files   JAR (Java Archive) files can represent an application’s EJB application module as well as a client application. The EJB JAR files, which include the Enterprise JavaBeans (EJBs) along with the JSP files, images, and the like are packaged together into one file archive, named a JAR, that’s executed by the Java Virtual Machine as one. JAR files have the extension .jar.

WAR Files   A WAR (Web Application Archive) file is used to package Web application module components such as HTML pages, servlets, and JSP pages. Typically, a WAR file contains an XML file named web.xml, which serves to describe the various Web components inside the WAR file.

EAR Files   You use an EAR (Enterprise Archive) file to package an entire enterprise Java application, including both the Java and the Web components, for deployment to OC4J. Therefore, an EAR file can contain both JAR and WAR files. The application.xml XML file included in an EAR file describes the contents of the EAR file.

Java provides a utility to zip the deployment files, in order to create the three types of archives. You can use the jar utility to create a JAR and a WAR file, as shown here:

  $ jar -cvfM <application-name>.ear
  $ jar -cvfM <application-name>.war

{mospagebreak title=CERTIFICATION OBJECTIVE 8.02}

Oracle Containers for Java

The Oracle Application Server 10g provides its own J2EE container, called the Oracle Containers for J2EE (OC4J). OC4J is an easy-to-use, lightweight, and highly scalable J2EE container that is written entirely in Java. OC4J is a complete Java 2 Enterprise Edition (J2EE) environment that runs on the Java Virtual Machine (JVM) of the standard Java Development Kit (JDK). OC4J runs on the standard JDK that’s a part of your operating system. Oracle bases its OC4J framework on technology licensed from Ironflare Corporation, developers of a leading J2EE container called the Orion Server. Thus, you’ll see several references in the OracleAS OC4J documentation to the Orion Server, and some of the OC4J executables contain their original Orion Server–based names.

OC4J is a set of containers that enable J2EE application deployment. For example, OC4J provides a Web Container to support JSP page translation as well as execution with a servlet engine. OC4J also provides an EJB container. As mentioned earlier, OC4J provides J2EE services such as JNDI, JDBC, JTA, JCA, and JAAS.

In this chapter, OC4J is discussed as part of the full OracleAS 10g product set, not its alternative pure Java standalone distribution. The pure Java standalone distribution is easy to download (one Zip file), install, and configure. However, the standalone distribution is really suited for development and testing only. For large-scale applications, you must use OC4J with the full OracleAS environment to take advantage of the full-fledged Oracle HTTP Server, Single Sign-On, and many other advanced features.

However, because the standalone and the OracleAS-based OC4J distributions are identical, you can use the standalone version to develop enterprise applications that you can later deploy on the Oracle Application Server 10g.

on the job:  The mod_oc4j module routes requests from the Oracle HTTP Server to OC4J.

{mospagebreak title=Default OracleAS OC4J Instances}

When you create a new OracleAS instance under the Portal and Wireless middle-tier option (and also have the OracleAS Infrastructure instance installed), you automatically have the following OC4J instances:

  • Home   This is the default OC4J instance that comes with every OracleAS installation.
     
  • OC4J_Portal   This contains a servlet to support OracleAS Portal (middle tier).
  • OC4J_Security  This supports Identity Management Services (infrastructure).
     
  • OC4J_Wireless  This contains a servlet to support OracleAS Wireless (middle tier).
  • oca   This supports the OracleAS Certificate Authority (infrastructure).

Although you can manage the OC4J process running inside OracleAS by editing the OC4J configuration files directly, that’s not the recommended way to manage OC4J when you use it as part of the OracleAS, as compared with using it in a standalone mode. The purpose behind including OC4J inside the OracleAS stack is to help manage J2EE enterprise systems. You must use the Oracle Application Server to manage all components of OracleAS, including OC4J.

Using the Application Server Control, it’s possible to manage and configure clustered OC4J processes across multiple OracleAS instances and hosts. Application Server Control provides clustering, high availability, load balancing, and failover capabilities to help you manage multiple OC4J instances.

on the job:  You must run OC4J with the JDK that is installed with Oracle Application Server Release 2 ( JDK 1.3.x) for optimal performance.

You can use either Application Server Control or command-line tools to start, stop, configure, and deploy applications. The two command-line tools you can use to manage OC4J instances are the familiar opmnctl and dcmctl utilities.

Please check back next week for the continuation of this article.

[gp-comments width="770" linklove="off" ]

antalya escort bayan antalya escort bayan Antalya escort diyarbakir escort