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.

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.