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:
We'll discuss JNDI first because it is often used to access other resources in the list. 6.2.1 Java Naming and Directory InterfaceThe 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 ArchitectureThe 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:
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 :
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 ConnectivityThe 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.
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):
OC4J supports the caching of data sources to efficiently allocate database resources and to improve application performance. Three caching schemes are available:
6.2.4 Java Transaction APIThe 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:
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 ServiceThe 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:
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 InvocationRemote 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 ConnectionsOracle 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:
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 ServiceThe 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:
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 CacheJava 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 APIsThe 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. |