Oracle Application Server 10g Essentials [Electronic resources] نسخه متنی

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 availablethat 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 invalidatedthat is, flagged as no longer
cachedby 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.