Database Connectivity in WebLogic^TM

This paper reviews DBMS client-server architecture, introduces the multitier concept, and explains how WebLogic's JDBC is ideally suited for creating data-oriented or multitier applications for both intranet and Internet applications, particularly on the World Wide Web.

Contents

A brief review of DBMS client-server architecture

The next generation: Multitier architecture

WebLogic

Database applications and the World Wide Web

Database transactions in a DBMS session

Database transactions on the Web

WebLogic solutions for Web transactions

Summary

A brief review of DBMS client-server architecture

Relational database management systems (RDBMS or DBMS) represent all data in a uniform way as rows or records of data in tables. All operations on the data are done using commands in SQL (Structured Query Language). (For more detailed information about the client-server model, see Lloyd Taylor's Client/Server FAQ.)

The first DBMSes, developed in the early 1980s, had a simple but inefficient scheme: each application program that wanted to access a relational database called its own data management libraries, or started its own invocation of the DBMS program. There were several disadvantages to this approach; it was very wasteful of computer resources, it was not suitable for local area networks (LANs), and could provide only limited support for transactions across multiple programs and users.

In the mid 1980s the database industry began a shift to a client-server architecture. In the client-server model, a single multithreaded DBMS server starts up before any client program. Client requests, in the form of SQL queries or updates, are received over the LAN by the DBMS server, which sends back SQL rows or status information in response to each request. The client-server model proved to be far more efficient and successful in coordinating and managing computer and network resources.

For the past decade, client-server architecture has enjoyed great success. But as computing has evolved in the 1990s, a number of problems with traditional two-tier architecture have become apparent:

• In the client-server world, each vendor supplies a different variant of SQL, and a different client library with a different API for communicating with its servers, such as DBLIB for Sybase or OCI for Oracle. Applications must have completely different logic to communicate with DBMS servers from different vendors. Microsoft's ODBC is an attempt to standardize the interface, but it suffers from a lowest common denominator approach and incomplete implementations.

• Both the DBMS-vendor client libraries and ODBC suffer from too low-level an abstraction. Application programmers must write code that deals with fetches and updates on individual records, rather than high-level operations on sets of records.

• In a large organization, client programs may reside on thousands of network PCs. Each time a DBMS vendor comes out with a new version, client libraries must be updated on every PC, which is expensive as well as a system management headache.

• In a world-wide organization, DBMSes and applications are distributed across machines all over the globe on a relatively slow Wide Area Network (WAN). In this environment, each round trip between SQL request and rows returned can be agonizingly slow. Encapsulating multiple requests into a single stored procedure can reduce the number of round trips, but may not yield enough savings to be acceptable.

• Client applications are usually deployed on desktop PCs with limited memory and disk capacity. As client-server applications and the PC operating systems become larger and more complex, the cost to equip every client PC becomes prohibitive.

The next generation: Multitier architecture

To address these problems, a new multitier architecture has evolved for the 90s.

Multitier architecture (sometimes called three-tier) extends the standard client-server architecture (also known as two-tier) by placing a multithreaded application server between the client and the DBMS. Clients communicate with the DBMS through the application server, using high-level, vendor-independent requests and replies. The application server is responsible for executing those requests, and makes calls as needed into each DBMS vendor's client library to communicate with DBMSes. Properly applied, multitier architecture can solve each of the problems of the traditional two-tier client-server.

WebLogic^TM

WebLogic brings the full power of multitier architecture to the Java development environment with WebLogic, its flagship Java application server. In addition to its many other server services, including event handling and remote-server-side class invocation for distributed processing, WebLogic's multitier framework also supports database connectivity. All WebLogic applications may share cooperative access to many services inside the WebLogic framework: event handling transaction control, remote method invocation, name and directory services, security, global logging, instrumentation, and resource management.

For database connectivity, WebLogic licenses a subset of WebLogic's features called WebLogic Express^TM. WebLogic Express includes WebLogic JDBC, WebLogic's pure-Java, multitier implementation of the JavaSoft JDBC API, also offers security, built-in HTTP servlet support, and client access via multiple protocols, including HTTP tunneling and IIOP. With the multitier WebLogic JDBC driver to provide connectivity between the client and the WebLogic Server, the developer also uses one or more JDBC drivers to connect the WebLogic Server to remote DBMSes, to which clients of the WebLogic Server have access to database data, as well as other sources of data that are being handled within WebLogic.

WebLogic JDBC handles multiple requests to heterogeneous databases for multiple clients via any JDBC-compliant database driver, (including the WebLogic jDriver for Oracle^TM native JDBC driver). In addition, WebLogic's dbKona^TM offers a higher level of abstraction for database access than JDBC. All of these products work together to provide database access services in WebLogic.

WebLogic solves several problems in integrating database data in a distributed, networked, Web-based intranet or internet environment:

• The problems of proprietary, low-level interfaces are solved with dbKona for database connectivity. (See also the companion whitepaper on dbKona.) dbKona deals with DBMS data at the level of DataSets. A DataSet is a high-level set representation of DBMS data that is vendor-independent; dbKona has methods for automatic generation of SQL that frees the programmer from the need for specific knowledge of each vendor's SQL. (Of course, dbKona also allows you to issue raw SQL with vendor-specific syntax, if needed, and dbKona methods for data definition -- for example, creating tables -- allow you to specify vendor-specific data types as well as generic ones.)

• The problem of DBMS client vendor libraries on every client PC is solved by the structure of WebLogic. Client programs make all DBMS requests through pure-Java WebLogic JDBC, which requires no client-side libraries. WebLogic is linked to each database by a single JDBC driver for each DBMS, to reduce upgrade costs and maintenance headaches.

• The problem of slow network times across a WAN is solved by several features of WebLogic:
  • Queue-based protocol. Each client has its own set of multiplexed, efficient queues for fast, packet-based data transfer.

  • Cached data and connections for a single user, connection pools for groups of users. Cached connections and named cached datasets substantially reduce the number of logins required on the DBMS, which lowers the acquisition cost of the server and the quantity of network traffic, as well as the length of time necessary for a client to establish a DBMS connection. Connection pools allow several WebLogic Users to share a configurable, tunable number of connections to the database that are established at WebLogic startup, which allows trusted WebLogic Users to access database data without any client knowledge of usernames or passwords, and also reduces client wait for a connection. Cached data can also improve performance, since the client's use of data is independent of the DBMS's supplying of data; the client can view the first record immediately, and while the client is viewing the first record, the retrieval of DBMS data can be cached on the WebLogic Server.

  • Saved client workspaces. A WebLogic JDBC client has its own workspace within the WebLogic Server that can be saved between sessions. A client can log back in to its previous state -- including a set of cached connections to the DBMS -- to continue work. Within the client workspace any arbitrary object, for example a DataSet, can be saved for long-term use, thus reducing DBMS workload and network traffic.

  • Named queries, a technique of performing a DBMS query once and making it available to all the clients of the WebLogic Server. Named queries improve response time and save cycles for popular queries. A named query can be executed (or re executed) as the result of an arbitrary trigger, such as an INSERT/UPDATE/DELETE action in any database, or after a certain amount of time has passed.

  • Support for stored procedures, reducing the amount of SQL and records to be sent.

• Moving DBMS-specific libraries off the client frees up limited disk storage and memory of client PCs.

• WebLogic's WebLogic Remote^TM extends the client's power. With WebLogic Remote, a client can invoke remotely located Java classes within WebLogic to carry out compute-intensive or privacy-sensitive operations on its behalf. This allows the developer to write "thin" clients that, in spite of their small local requirements, have the computing power of the entire network at their disposal.

Database applications and the World Wide Web

Transactions in a DBMS session

One of the most important tasks of a database system is to perform transactions. A transaction is a set of operations, all of which must be completed in order (known as a commit), or not completed at all (a rollback). The classic example is a money transfer from one bank account to another, where the same amount must be debited from the first account as credited to the second account. In the DBMS client-server environment, a client application must perform the following steps to do a transaction.

• Start a session on the DBMS server by logging in with name and password
• Issue a SQL BEGIN TRANSACTION command
• Issue one or more SQL INSERT, DELETE, or UPDATE statements
• Issue a SQL COMMIT or ROLLBACK transaction command
• End the session by logging out or disconnecting

A transaction can be optionally tagged with an ID. Ending a session while a transaction is pending causes an automatic ROLLBACK.

As described in the steps above, a client-server transaction is inherently a session in which each step requires the context information (or state) that was created by previous steps. The necessity to maintain a session makes DBMS computing on the Web difficult, as the next few paragraphs explain.

Transactions on the Web

All Web browsers and servers use a protocol called HTTP to communicate. HTTP is stateless; that is, an HTTP server has no memory of previous requests. For example, if you are viewing a Web page in your browser, and you click on a link that requests http://bigserver.com/this, and then 5 minutes later click on a link that requests http://bigserver.com/that, the server at bigserver.com has no way of knowing that the two requests this and that came from the same person browsing the same page.

For most applications, this stateless property of HTTP is a benefit that permits clients and servers to be written with simple logic and run lean with no extra memory or disk space taken up with information from old requests. Unfortunately, however, the stateless property of HTTP makes it difficult to support the concept of a session that is essential to basic DBMS transactions.

Developers have come up with various schemes to compensate for the stateless nature of HTTP, such as returning Web pages with hidden fields containing transaction IDs, and using Web page forms where all the information is entered locally and then submitted it as a single transaction. All of these schemes are limited in the kinds of applications they support and require special extensions to the HTTP servers. WebLogic provides a set of elegant and simple solutions for transaction processing on the Web.

WebLogic solutions for Web transactions

WebLogic Express fully supports DBMS transactions in two ways.

• First, in the 2-tier configuration, applications built with WebLogic jDriver for Oracle can maintain a DBMS connection, using the appropriate client-side libraries. WebLogic provides a non-ODBC, native JDBC driver for Oracle.

• Second, in the multitier configuration, the WebLogic Server maintains a connection to the DBMS on behalf on a Java WebLogic Client. Each WebLogic Client has its own workspace, which can be allowed to persist over multiple client sessions. A WebLogic JDBC applet or application can log in to the WebLogic Server, issue any number of requests, disconnect, and then come back to its client workspace at a later time and find that same connections are still active and ready for more requests.

After release 2.4, WebLogic supports secure sessions between a WebLogic Server and its clients via Secure Socket Layer (SSL), which offers both encryption and authentication services. In addition, WebLogic also offers tunneling of Java-to-Java WebLogic Connections over HTTP for transfirewall and transproxy access.

Summary

This paper has shown how WebLogic products within WebLogic's multitier framework are ideally suited for Java database connectivity in the multitier client-network, for both intranet and internet business applications.

Copyright © 2000 BEA Systems, Inc. All rights reserved.
Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.
Last updated 01/13/2000