CS651

Database Connection System Architectures

2-Tier Architecture

OR

The above is a traditional 2-tier client-server architectures. The first uses Oracle and JDBC OCI driver (hence only for a Java Applicatio). The second diagram shows a 2-tier client-server architecture for Java Applet using the Thin JDBC driver.

ISSUES:

State Management:

In this configuration, the initial communication between the client and middle-tier web server occurs via the stateless HTTP protocol. Once the JDBC driver has been downloaded, it establishes a direct connection with the Oracle database. This connection is stateful and the JDBC driver therefore eliminates the need for the Java application programmer to explicitly handle the relationship between transaction state and various HTTP sessions. However, in this configuration the JDBC driver does establish a separate connection from each web browser to the Oracle database.

Greater scalability:

Since the JDBC driver does establish a separate connection from the web browser to the database server, there are two ways in which a user can achieve greater scalability i.e. support a large number of browsers connected concurrently to a single database. First, the user can connect the browsers to the database via the Net8 Connection Manager which essentially multiplexes connections between a number of different clients to a single physical database connection. This reduces the number of direct database connections and therefore provides greater scalability particularly on platforms which have limitations in the number of physical end points that they support. Second, with the Oracle8 database server, the user can transparently leverage a feature called connection pooling. Essentially the Oracle Multi Threaded Server's dispatcher establishes a pool of connections internally and hands connections from inactive to active clients thereby supporting more clients than connections and thereby facilitating greater scalability. The application developer does not need to write any application code to leverage this capability.

Security Considerations:

The communication between an applet that uses the JDBC driver and the Oracle database happens over Java TCP/IP sockets. In the case of the Java Applet, the connection can only be made if the web browser where the applet is executing allows a sockets connection to be made. In a JDK1.0.2-based Web browser, such as Netscape 3.0, an applet can only open sockets to the host from which it was downloaded. Therefore, to avoid violating JDK 1.0.2. security considerations, the Oracle Database server must be physically located on the same machine as the web server. However, this restriction has been eliminated for JDK 1.1 signed applets in which case the web server and the Oracle database can be deployed on two separate machines. In a JDK 1.1.1 based web browser, such as Netscape 4.0, an applet can request socket connection privileges and, if the user grants them, the applet can connect to the database running on a different host from the web server host. Another alternative besides signed applets, to avoid this security restriction is to use the Oracle Connection Manager.

3-Tier Architecture

OR

The above is a 3-tier client-server-server architecture using Oracle and JDBC OCI driver. Here there is a middle Java w/JDBC application that sits on the server and client application or applet communicates with it via HTTP calls (or you could use sockets).

The middle JDBC application is responsible for connecting to the Database and performing queries. This is done in the same way the 2-tier Java application connects.

Besides the JDBC application, the JDBC driver must be installed on the server.

The server which the middle JDBC application and driver sits on may be physically different or the same as the Database server machine.

HOW TO INVOKE THE middle JDBC application:

The user can use a CGI script that invokes it.

Implement the JDBC application as a Servlet.

Use Oracle's Web Request Broker API [if the application is deployed on Oracle's Web Application Server].

Have the JDBC application be persistant (continually running) and instead of invoking it using HTTP the client application/applet communicates via a Sockets to make requests.

Implement a IIOP style invocation. (short for Internet Inter-ORB Protocol, a protocol developed by the Object Management Group (OMG) to implement CORBA solutions over the World Wide Web. IIOP enables browsers and servers to exchange integers, arrays, and more complex objects, unlike HTTP, which only supports transmission of text. )

Advantages of 3-Tier over 2-Tier

State Management:

In this configuration, the communication between the client and middle-tier web server occurs via HTTP, a stateless or connectionless protocol; while the communication between the Java application on the web server and the database occurs in a stateful manner. The Java application programmer needs to explicitly manage all of the state information and handle all of the relationships between transaction state and various HTTP sessions.

Greater scalability:

Further, in this connection, a sophisticated Java application programmer will leverage the capabilities of the JDBC/OCI driver for greater scalability. For instance, rather than establish a separate database connection for every web browser, the application developer may choose to pool the state associated with multiple clients on a single or a limited number of connections to the backend database server. By choosing to allocate a pool of database connections which can then be reused, the Java programmer optimizes database server memory usage and significantly increases the number of clients i.e. browsers that the application can support.

Optimized response time:

Since HTTP is by its nature a stateless protocol, a simplistic Java application would essentially require a user to establish a database connection and login each time. With HTTP's stateless nature, this creates severe performance issues associated with a separate web server to database server round trip and a database login for each HTTP request. This can be prohibitively expensive from a performance and responsiveness standpoint. To avoid this, a sophisticated Java programmer will choose to establish a database connection and login the user on the initial invocation; after the initial connection, the programmer will cache the database connection and login context and reuse them on subsequent HTTP requests from the same user to avoid making mid-tier to database server round trips.