Data and Access Services

WebLogic Server implements standard J2EE technologies to provide data and access services to applications and components. These services include the following APIs:

• Java Naming and Directory Interface (JNDI)
• Java Database Connectivity (JDBC)
• Java Transaction API (JTA)
• J2EE Connector Architecture

The following sections discuss these services in detail.

JNDI

       The Java Naming and Directory Interface (JNDI) is a standard Java API that enables applications to look up an object by name. WebLogic Server or a user application binds the Java objects it serves to a name in a naming tree. An application can look up objects, such as RMI objects, Enterprise JavaBeans, JMS Queues and Topics, and JDBC DataSources, by getting a JNDI context from WebLogic Server and then calling the JNDI lookup method with the name of the object. The lookup returns a reference to the WebLogic Server object.

WebLogic JNDI supports WebLogic Server cluster load balancing and failover. Each WebLogic Server in a cluster publishes the objects it serves in a replicated cluster-wide naming tree. An application can get an initial JNDI context from any WebLogic Server in the cluster, perform a lookup, and receive an object reference from any WebLogic Server in the cluster that serves the object. A configurable load-balancing algorithm is used to spread the workload among the servers in the cluster.

JDBC

        Java Database Connectivity (JDBC) provides access to backend database resources. Java applications access JDBC using a JDBC driver, which is a database vendor-specific interface for a database server. Although any Java application can load a vendor's JDBC driver, connect to the database, and perform database operations, WebLogic Server provides a significant performance advantage by offering JDBC connection pools.

A JDBC connection pool is a named group of JDBC connections managed through WebLogic Server. At startup time WebLogic Server opens JDBC connections and adds them to the pool. When an application requires a JDBC connection, it gets a connection from the pool, uses it, and then returns it to the pool for use by for other applications. Establishing a database connection is often a time-consuming, resource-intensive operation, so a connection pool, which limits the number of connection operations, improves performance.

WebLogic Server also provides JDBC multipools for achieving load balancing or high availability capabilities with database connections in single-server configurations. Multipools are a "pool of pools" that provide a configurable algorithm for choosing which pool to provide a connection for a given request. Currently, WebLogic Server provides algorithms to support either high availability or load balancing behavior for database connections.

To register a connection pool in the JNDI naming tree, define a DataSource object for it. Java client applications can then get a connection from the pool by performing a JNDI lookup on the DataSource name.

Server-side Java classes use the WebLogic JDBC pool driver, which is a generic JDBC driver that calls through to the vendor-specific JDBC driver. This mechanism makes application code more portable, even if you change the brand of database used in the backend tier.

The client-side JDBC driver is the WebLogic JDBC/RMI driver, which is an RMI interface to the pool driver. Use this driver the same way you use any standard JDBC driver. When the JDBC/RMI driver is used, Java programs can access JDBC in a manner consistent with other WebLogic Server distributed objects, and they can keep database data structures in the middle tier.

WebLogic EJB and WebLogic JMS rely on connections from a JDBC connection pool to load and save persistent objects. By using EJB and JMS, you can often get a more useful abstraction than you can get by using JDBC directly in an application. For example, using an enterprise bean to represent a dataful object allows you to change the underlying store later without modifying JDBC code. If you use persistent JMS messages instead of coding database operations with JDBC, it will be easier to adapt your application to a third-party messaging system later.

JTA

      The Java Transaction API (JTA) is the standard interface for managing transactions in Java applications. By using transactions, you can protect the integrity of the data in your databases and manage access to that data by concurrent applications or application instances. Once a transaction begins, all transactional operations must commit successfully or all of them must be rolled back.

WebLogic Server supports transactions that include EJB, JMS, JCA, and JDBC operations. Distributed transactions, coordinated with two-phase commit, can span multiple databases that are accessed with XA-compliant JDBC drivers, such as BEA WebLogic jDriver for Oracle/XA.

The EJB specification defines bean-managed and container-managed transactions.When an enterprise bean is deployed with container-managed transactions, WebLogic Server coordinates the transaction automatically. If an enterprise bean is deployed with bean-managed transactions, the EJB programmer must provide transaction code.

Application code based on the JMS or JDBC API can initiate a transaction, or participate in a transaction started earlier. A single transaction context is associated with the WebLogic Server thread executing an application; all transactional operations performed on the thread participate in the current transaction.

J2EE Connector Architecture

            The J2EE Connector Architecture adds simplified Enterprise Information System (EIS) integration to the J2EE platform. It provides a Java solution to the problem of connectivity between the multitude of application servers and EISes. By using the Connector Architecture, it is no longer necessary for EIS vendors to customize their product for each application server. By conforming to the J2EE Connector Architecture, BEA WebLogic Server does not require added custom code in order to extend its support connectivity to a new EIS.

The J2EE Connector Architecture is implemented both in WebLogic Server and in an EIS-specific resource adapter. A resource adapter is a system library specific to an EIS and provides connectivity to the EIS. A resource adapter is analogous to a JDBC driver. The interface between a resource adapter and the EIS is specific to the underlying EIS, and can be a native interface.

The J2EE Connector Architecture comprises the system-level contracts between WebLogic Server and a given resource adaptor, a common interface for clients to access the adaptor, and interfaces for packaging and deploying resource adaptors to J2EE applications.