1
Introduction to OC4J Services

Oracle Application Server Containers for J2EE (OC4J) supports the following technologies, each of which has its own chapter in this book:

• Java Naming and Directory Interface (JNDI)

• Java Message Service (JMS)

• Remote Method Invocation (RMI)

• Data Sources

• Java Transaction API (JTA)

• J2EE Connector Architecture (JCA)

• Java Object Cache

This chapter gives a brief overview of each technology in the preceding list.

Note: In addition to these technologies, OC4J supports the JavaMail API, the JavaBeans Activation Framework (JAF), and the Java API for XML Processing (JAXP). For information about these technologies, see the Sun Microsystems J2EE documentation.

Java Naming and Directory Interface (JNDI)

The Java Naming and Directory Interface (JNDI) service that is implemented by Oracle Application Server Containers for J2EE (OC4J) provides naming and directory functionality for Java applications. JNDI is defined independently of any specific naming or directory service implementation. As a result, JNDI enables Java applications to access different, possibly multiple, naming and directory services using a single API. Different naming and directory service provider interfaces (SPIs) can be plugged in behind this common API to handle different naming services.

See Chapter 2, "Java Naming and Directory Interface", for details.

Java Message Service (JMS)

Java Message Service (JMS) provides a common way for Java programs to access enterprise messaging products. JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product.

See Chapter 3, "Java Message Service", for details.

Remote Method Invocation (RMI)

Remote Method Invocation (RMI) is one Java implementation of the remote procedure call paradigm, in which distributed applications communicate by invoking procedure calls and interpreting the return values.

OC4J supports both RMI over the Oracle Remote Method Invocation (ORMI) protocol and over the Internet Inter-ORB Protocol (IIOP) protocol.

By default, OC4J uses RMI/ORMI. In addition to the benefits provided by RMI/IIOP, RMI/ORMI provides additional features such as invoking RMI/ORMI over HTTP, a technique known as "RMI tunneling."

See Chapter 5, "Oracle Remote Method Invocation", for details on RMI/ORMI.

Version 2.0 of the Enterprise Java Beans (EJB) specification uses RMI over the Internet Inter-ORB Protocol (IIOP) protocol to make it easy for EJB-based applications to invoke one another across different containers. You can make your existing EJB interoperable without changing a line of code: simply edit the bean's properties and redeploy. J2EE uses RMI to provide interoperability between EJBs running on different containers.

See Chapter 6, "J2EE Interoperability", for details on interoperability (RMI/IIOP).

Data Sources

A data source, which is the instantiation of an object that implements the javax.sql.DataSource interface, enables you to retrieve a connection to a database server.

See Chapter 4, "Data Sources", for details.

Java Transaction API (JTA)

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

See Chapter 7, "Java Transaction API", for details.

J2EE Connector Architecture (JCA)

J2EE Connector Architecture (JCA) defines a standard architecture for connecting the J2EE platform to heterogeneous Enterprise Information Systems (EISs). Examples of EISs include ERP, mainframe transaction processing, database systems, and legacy applications that are not written in the Java programming language.

See Chapter 8, "J2EE Connector Architecture", for details.

Java Object Cache

The Java Object Cache (formerly OCS4J) is a set of Java classes that manage Java objects within a process, across processes, and on a local disk. The primary goal of the Java Object Cache is to provide a powerful, flexible, easy-to-use service that significantly improves server performance by managing local copies of objects that are expensive to retrieve or create. There are no restrictions on the type of object that can be cached or the original source of the object. The management of each object in the cache is easily customized. Each object has a set of attributes that are associated with it to control such things as how the object is loaded into the cache, where the object is stored (in memory, on disk, or both), how it is invalidated (based on time or by explicit request), and who should be notified when the object is invalidated. Objects can be invalidated as a group or individually.

See Chapter 9, "Java Object Cache", for details.