6.2 OC4J Services

This section takes a high-level look at each service provided by OC4J to servlets and EJBs. Some of these are standard J2EE services while others are Oracle value-added services. The OC4J services consist of the following:

• Java Naming and Directory Interface (JNDI)

• J2EE Connector Architecture

• Java DataBase Connectivity (JDBC)

• Java Message Service (JMS)

• Remote Method Invocation (RMI)

• Server-side HTTPS

• Java Transaction API (JTA)

• Java Authentication and Authorization Service (JAAS)

• Java Mail

• Java API for XML Parsing (JAXP)

• Java Object Cache

We'll discuss JNDI first because it is often used to access other resources in the list.

6.2.1 Java Naming and Directory Interface

The Java Naming and Directory Interface provides Java programs with standardized access to various naming and directory implementations . Within OC4J, servlets and EJBs can access global resources, such as Data Sources, and environment variables defined in each servlet or EJB deployment descriptor with the default JNDI context. The OC4J's naming mechanism is implemented using an XML file.

If a servlet or EJB requires access to an external directory, such as LDAP implemented by the Oracle Internet Directory, the URI to the external directory can be specified as a parameter in the servlet or EJB's deployment descriptor, looked up via JNDI using the default context, and then used to create a new context that accesses the external directory once again using JNDI.

JNDI can access various naming and directory services using service provider interfaces (SPIs) to abstract the API for the naming or directory service. This capability allows JNDI to use any desired naming or directory service. The service can be enabled by configuring its SPI.

6.2.2 J2EE Connector Architecture

The J2EE Connector Architecture provides a standardized interface for J2EE applications to access existing Enterprise Information Systems (EIS), such as Peoplesoft, SAP, mainframes, and so on. A Java program can access any EIS for which a J2EE Connector implementation exists. A J2EE Connector is implemented in the form of a driver called a resource adapter . A resource adapter is a driver that connects to and communicates with an EIS.

A JDBC driver is an example of a resource adapter that allows a servlet or EJB to connect to a database. However, the JDBC API existed long before the J2EE Connector Architecture, and JDBC drivers are very commonly used, so they have their own configuration facilities.

There are two types of resource adapters:

Standalone resource adapter

This type of resource adapter is globally available ”that is, it is available to all applications.

Embedded resource adapter

This type of resource adapter exists within a deployed Enterprise Application aRchive (EAR) file, available to the components within an application, but not to other applications running on the same instance of the OC4J.

Resource adapters must abide by a set of quality of service contracts, which means that they must provide connection pooling, transaction management, and security management as follows :

Connection pooling

Provides a way to efficiently allocate resource adapter instances by caching them in a pool. This ability allows the connections to be checked out of a pool when needed, and then checked back in when they are no longer needed. Connection pooling reduces the instantaneous workload (the number of resources in use at the same time at both ends of a connection) on the OC4J and the host EIS.

Transaction management

Provides a facility whereby the resource adapter implements the Java Transaction API so that an EIS that is being accessed can participate in a global distributed transaction.

Security management

Provides a facility whereby the resource adapter supports authentication, authorization, and secure connections.

In addition, resource adapters must support both component- and container-managed security. Component-managed security is simple enough; all connection information is supplied programmatically. However, with container-managed security, information such as sign-on parameters is specified declaratively in the application's deployment descriptor.

6.2.3 Java DataBase Connectivity

The Java DataBase Connectivity API provides Java programs with standardized access to tabular data sources. Modeled after Microsoft's Open DataBase Connectivity (ODBC) API, JDBC was originally designed to access relational databases. JDBC has evolved, as has ODBC, to handle any tabular data, including comma- and tab-separated values in operating system data files. In addition, with the publication of the new SQL standard, SQL 1999, and Oracle's complete implementation of the new SQL standard, Oracle's JDBC drivers now support even object-relational data.

OC4J supports both Oracle and non-Oracle JDBC drivers. For the Oracle database, the Oracle Thin (type 4) and OCI (type 2) drivers are supported. For non-Oracle databases, Data-Direct (type 4) drivers for IBM DB2 UDB, Microsoft SQL Server, Informix, and Sybase are provided with OC4J. It is entirely possible to use any JDBC driver, because the OC4J is a standard J2EE server implementation.

Type 2 drivers are part Java and part operating-system executable code. Type 4 drivers are 100% pure Java.

Access to JDBC is configured globally through Application Server Control, which in turn makes an entry in the global data-sources.xml file. Configuration can also be made locally in a servlet, EJB, or enterprise application's deployment descriptor. In addition, an application can be packaged with its own data-sources.xml file.

A servlet or EJB uses JNDI to look up and retrieve a DataSource at runtime. A DataSource is a JDBC object that represents a logical JDBC connection to a tabular data source. A servlet or EJB manipulates the data in the host database through the methods of objects created by a DataSource .

OC4J has three types of data sources (not to be confused with driver types):

Emulated data sources

Emulate the XA API without providing a full XA implementation. (The XA API is discussed later in Section 6.2.4.) An emulated data source acts as though it supports JTA, but it doesn't support two-phase commits. This allows the emulated data source to perform better than its nonemulated counterpart , yet still support local transactions.

Nonemulated data sources

Provide full XA and JTA global transaction support. A nonemulated data source is recommended only for distributed transactions because the additional overhead of full support can unnecessarily impede the performance of transactions when full support isn't needed.

Non-JTA data sources

Provide no global transaction support.

OC4J supports the caching of data sources to efficiently allocate database resources and to improve application performance. Three caching schemes are available:

Dynamic scheme

This scheme grows the pool of cached data sources as needed, and later it removes unused data sources when they are no longer used. The minimum pool size can be configured so that data sources are already cached upon startup of the OC4J instance in which they reside.

Fixed wait scheme

This scheme uses a maximum parameter to limit the number of data sources in a pool. When the limit is reached, and a servlet or EJB requests a connection, it must wait indefinitely until another process returns a data source to the pool.

Fixed return null scheme

This scheme works in a way that's similar to the fixed wait scheme, but instead of waiting indefinitely, it immediately returns a null data source (effectively no data source) to the servlet or EJB if a data source isn't available in the pool.

6.2.4 Java Transaction API

The Java Transaction API provides a standardized set of interfaces for managing a distributed transaction. Java programs, such as EJBs, are intrinsically distinct components that are assembled into applications at deployment time. You can define transaction scope between various EJBs and their methods in either of two ways:

Bean-managed transactions (BMT)

Transaction scope is defined programmatically during development in each EJB's deployment descriptor.

Container-managed transactions (CMT)

Transaction scope is defined declaratively at deployment time in each EJB's deployment descriptor.

OC4J, like any other J2EE-compliant EJB container, supports both bean-managed and container-managed transactions. In addition, the OC4J supports two-phase commits. In the context of OC4J, a two-phase commit is a transaction that involves two or more Oracle databases. In other words, when two or more resources involved in a transaction are all Oracle databases, OC4J's two-phase commit process guarantees that all involved databases will commit or roll back a given transaction.

6.2.5 Java Message Service

The Java Message Service provides Java programs with standardized access to enterprise messaging systems. Messaging systems provide a persistent message queue: one or more programs can place messages on a given queue, while one or more programs can retrieve or consume messages from a given queue.

A queue is what gives messaging products the ability to support asynchronous messaging, and asynchronous messaging is, in turn, what makes enterprise messaging systems (EMSs) uniquely useful. An EMS provides guaranteed execution (delivery) of messages, without incurring the waits that an otherwise synchronous procedure call would incur. A servlet or session EJB can act as a JMS client message producer, able to place messages on a queue, or a synchronous message consumer, while a message-driven EJB can act as a JMS client message consumer, retrieving messages from a queue.

JMS provides two messaging models:

Point-to-point model

One message producer queues messages to one and only one message consumer.

Publish-and-subscribe model

One message producer queues messages to one or more message consumers.

OC4J provides a Resource Provider interface that allows you to transparently add JMS implementations to the server. JMS resource providers are looked up using JNDI through the local context similar to JDBC resources. Just like JDBC resources, JMS resources can be configured as standalone (available to all applications in an OC4J instance) or embedded (available only to the application in which it is configured).

Oracle JMS (OJMS) is a provider that can be used to access Oracle Advanced Queuing, the Oracle database's enterprise messaging system. Several third-party resource provider interfaces are also supplied that allow access to other systems, including SonicMQ, SwiftMQ, and WebSphereMQ.

As of the OC4J Release 9.0.4, OC4J has its own messaging system, OracleAS JMS, also known as OC4J JMS. OC4J JMS provides an in-memory and/or disk-based persistent JMS implementation in OC4J. With this addition, OC4J has become a complete enterprise messaging system in and of itself.

6.2.6 Remote Method Invocation

Remote Method Invocation is the protocol used by client-side applications, servlets, and EJBs to remotely communicate with EJBs. The remote communication is in the form of remote method execution. While RMI is a standard used by all J2EE-compliant EJB containers, OC4J provides value-added protocol extensions.

As part of the EJB 2.0 specification, EJBs can be configured to use the CORBA RMI/IIOP (RMI over IIOP) protocol to facilitate communication between EJBs deployed on different application servers. Using this form of component-to-component communication allows you to deploy components on any tier , provide dynamic load balancing, and enable horizontal scaling. However, the RMI/IIOP protocol doesn't support all these features when used with OC4J.

The default protocol used by OC4J is RMI/ORMI (RMI over Oracle RMI). Oracle RMI is a proprietary RMI implementation that is highly optimized for use with OC4J. ORMI supports application load balancing and failover between OC4J instances. ORMI also supports RMI tunneling. RMI tunneling enables EJBs to communicate through a firewall using the HTTP protocol, which is passed unscathed through most firewalls.

6.2.7 HTTPS for Client Connections

Oracle HTTPS for Client Connections (Oracle HTTPS) provides an SSL infrastructure inside OC4J to support SSL communication between the Oracle HTTP Server and OC4J, a client-side application program and OC4J, or a servlet residing in OC4J acting as a client program accessing another servlet or web site using SSL. Oracle HTTPS supports the following common cipher suites:

• Key exchanges of 512, 768, or 1024 bits using RSA or Diffie-Hillman

• Null, 40-, or 128-bit encryption using RC4 or DES

• Message authentication using MD5 or SHA1

Oracle HTTP Server SSL certificates are managed with Oracle Wallet Manager (OWM). OWM can generate public/private key pairs and certificate requests. A signed certificate request and the associated trusted certificate are added to OWM's wallet to create a complete wallet. That wallet, in turn, can be exported to use in a Java SSL-based client-side application.

OC4J's SSL certificates are managed using the JDK's keytool . keytool can also generate public/private key pairs and certificate requests. A signed certificate request and the associated trusted certificate are added to OC4J's keystore using keytool . Like OWM, keytool can export a client-side certificate.

Once signed certificates have been created for both the Oracle HTTP Server and OC4J, they can be exchanged to provide SSL communication between the two server components. In addition, configured OC4J can use its SSL configuration to enable SSL communication between a client-side application and OC4J or a servlet inside OC4J and another SSL server.

6.2.8 Java Authentication and Authorization Service

The Java Authentication and Authorization Service is the Java implementation of the standard Pluggable Authentication Module (PAM) framework. JAAS acts as a user -based adjunct to the Java 2 security model. In the Java 2 security model, access control is driven by a set of privileges, called a policy , that are granted to a code base. A code base is the location from which a Java program is executed.

With JAAS, code-base policies are effectively overridden by policies granted to a particular user logged into an application. As its name suggests, JAAS provides a standardized set of APIs that facilitate user login (authentication) and control over what a user may or may not do while logged in (authorization).

JAAS is a set of abstract classes that are implemented at runtime by a JAAS provider. OC4J supports JAAS with the OC4J JAAS Provider (JAZN). ^[1] JAZN supports two provider types:

^[1] Don't ask how they got JAZN out of OC4J JAAS Provider.

XML-based provider

This type of provider stores realm, user, and policy information in an XML file typically named jazn-data.xml that is co-located with an OC4J instance.

LDAP-based provider

This type of provider uses LDAP to access an LDAP directory, such as the Oracle Internet Directory, where it too stores realm, user, and policy information. The LDAP provider type is tightly integrated with OracleAS Single Sign-On, which enables a user to use one user ID and password to log on to all applications.

A realm is a high-level identifier that organizes users, roles, and policies. Using an external realm, you can import users from other systems: NT, LDAP, Unix password, DB, and so on.

Using JAAS requires program modifications; it isn't enabled transparently. First, an administrator must configure one or more login modules, and a set of policies for an application. Next, a programmer must make minor code changes so that affected class methods are called with a user's security policy instead of with the code base's policy.

OC4J has its own default login module, RealmLoginModule , but can be configured to use any JAAS-compliant login module. JAZN can be configured programmatically or by using a components deployment descriptor. The JAZN user manager handles authentication and authorization for OC4J. It can be configured through Application Server Control to use JAZN-XML for the XML-based provider or JAZN-LDAP for the LDAP-based provider.

You can configure the XML-based provider's users, roles, and policy using the command line-based JAZN Admin tool. You can configure the LDAP-based provider's users, roles, and policy using the Oracle Internet Directory's Delegated Administrative Service (DAS).

Managing policy assignment by user can become quite cumbersome. To improve manageability, both provider types support role-based access control (RBAC) by allowing you to create a principal (normally a user, but now a role name), add a policy to that principal (a role), and then add other principals (users as members ) to that role. Roles can also be added to roles, effectively creating a role hierarchy.

6.2.9 Java Object Cache

Java Object Cache is an Oracle value-added service provided by OC4J that exists to improve the performance of Java-based applications. Java Object Cache caches expensive-to-create or frequently accessed Java objects. Java Object Cache is both a memory- and/or a disk-based cache. It is meant to complement OracleAS Web Cache where applicable .

With Java Object Cache, cached objects can be shared between servlets and EJBs. They can be invalidated ”that is, flagged as no longer cached ”by the amount of time they have been present in the cache (time-to-live), by the amount of time they have not been accessed (idle), or on demand.

Java Object Cache provides a flexible resource organization structure based on a top-level identifier called a region . A region can be subdivided into more regions , appropriately called subregions . Each cached object belongs to one and only one region or subregion. Groups can be created that combine regions for mass property manipulation or invalidation of cached objects.

Java Object Cache also provides flexible management either programmatically or through its Java Object Cache properties file. Java Object Cache can be configured as either a local cache or a distributed cache. A local cache is available only to Java programs running in the same OC4J where the cache resides. When the Java Object Cache is configured as a distributed cache, cached objects are available to all OC4J instances that are part of the same cluster.

Web Object Cache is an HTTP-centric object cache implementation that uses the Java Object Cache for its repository. Web Object Cache is used solely with servlets (and JSPs that are actually servlets). It uses information from a servlet's HTTPRequest object to automatically define regions in Java Object Cache.

See Chapter 7 for more information on Java Object Cache and Web Object Cache, as well as a complete description of OracleAS Web Cache.

6.2.10 Other APIs

The previous sections briefly describe all of Oracle's officially designated OC4J services. However, keep in mind that all Java APIs can be used in Oracle Application Server with the appropriate configuration. The servlet API exists as a way to extend Oracle Application Server. Some of the other Oracle components available in Oracle Application Server are themselves J2EE applications. Hence, using J2EE you have basically unlimited capability to create a server-side solution.

Note that we haven't touched on XML or Web Services in this chapter. These two topics are described separately in Chapter 10 and Chapter 11, primarily because Oracle Application Server provides more than just Java support for these areas.