Web Applications

Unfortunately, the client-server architecture arguably presents a few management and administration challenges. Just about when people started realizing the challenges of client-server, the Internet and its promise of connecting everyone everywhere to everything became the next paradigm. More specifically, HTML pages were being strung together in a web of information. HTML offered a platform-agnostic, common, and simple way for users to interact with data and applications. Application development companies began to investigate the Internet as the next medium for information delivery.

When HTML first reached the mainstream, practically all of the content was static. It wasn’t long before users requested nonstatic HTML pages containing the most up-to-date information. Internet development began to eclipse the client-server architecture.

To build dynamic content containing the latest information, HTML pages had to be constructed from the results of the database queries submitted by an application. This was not an easy task. There were some technology issues to overcome, and many clever solutions were developed to overcome these challenges, particularly those concerning performance and security.

The Stateless Environment

Fast forward to today and the universal client application: the Web browser. In today’s world, you use the http protocol to connect users to application servers rather than directly to databases. This has important implications on application security, as you shall soon see.

Unfortunately, http, while useful for its original purpose, is stateless and in many cases is not optimal for many of today’s current demands. Stateless means that there is a new connection established for every request. As such, the state of individual and recurring connections can’t be supported by the protocol.

The stateless nature of http forces you to consider new ways of securing recurring communications. Recall that in the client-server analogy, you had a connection that lasted the duration of the application’s use (which was similar to the duration of a phone call). With the stateless http environment, every mouse click is a new network call—it’s like having to place a new phone call for every sentence in a conversation. The problem is exacerbated by the fact that the web server is conducting many conversations simultaneously. The challenge is not only to string together sentences among all the users, but also making sure the users don’t get mixed up. It would be considered a flaw if Bob asked the server for the latest sports scores, and it handed back the latest YTD figures from accounting.

The stateless aspect of http was solved by the application servers for client to application server communications. The solution utilizes browser cookies and the ability of the application server to create and maintain transparent “sessions” and thus state for each client. However, this represents only half of the architecture. The connection from the application server to the database still remains a challenge.

Web Databases

As database use and the value databases provided to organizations increased, so too, increased the user community. Assuming that a preponderance of HTML pages are actually dynamic pages created from a database, I can now focus on the heart of the problem.

Unlike host-based and client-server computing, web users no longer connect directly to the database. There is a middleman involved: the application servers. The application servers connect to the database on the user’s behalf. How this is done makes all the difference for two critical reasons: security and performance.

Connection Challenges

Web applications connect to databases to build dynamic and often personalized web pages. To do this securely, you would ultimately like to connect your users to the database using the 1:1 mapping model. That is, you connect each application user to a distinct database account. This is secure because the database knows who is connected and can employ its security capabilities—specifically access control and auditing.

In the host-based and client-server models, the user is always directly connected to the database. In a web environment, the user is rarely, if ever, directly connected to the database; the user is connected to the application, and the application is connected to the database. You might therefore conclude the application should connect each application user to a distinct database account.

Many security administrators dislike this connection model design. One important reason is password security. This design could require the application to know the user’s database password and there may be no secure way to manage these passwords. Most application servers today have built-in authentication services that obviate the need for the applications to perform the user authentication. Moreover, for security reasons, the applications are prevented from acquiring the user’s password.

Resource limitations are another key factor limiting the effectiveness of this design. Web applications typically support many end users. To connect each user to a private database account, you’ll have to establish a dedicated database connection for each user. If you have many users, you could exhaust memory and computing resources on your application server, database, or both by simply trying to create and maintain all the open database connections. For applications with a small number of connections, dedicated and individual connections may be possible.

Also, for web applications, there’s no guarantee a user will access the application on any given day, or once they have started accessing it, that they’ll continue to use it. I create web expense reports all the time and quite often decide, after logging in and looking at an enormous pile of receipts, that I don’t really feel like doing my expense report after all. So I click on the “home” icon in my browser. The expense report application has no idea that I have done this and expects me to submit an expense report. If you are building a web application, then you have to be concerned with these situations. In such cases, an application may be wasting resources on open, dedicated database connections for users that are not and will not be making use of the connections. In Chapter 6, you’ll see how to utilize the web session’s timeout period to close the database connections for the user.

Alternatively, you may decide to close the database connections between user requests. When a user makes a request, the application logs on to the database as that user, issues the query, and then disconnects. You will now see why this is generally not practical for performance reasons.

Performance

Suppose SCOTT wants to run a report. He connects to the application server from his browser and says, “Application, give me the YTD figures.” The application server (or application) translates this question—typically represented via a hyperlink or form button—into SQL queries for the database. Note SCOTT is not connected to the database; the application is connected to the database for SCOTT. To retrieve SCOTT’s report, the application has to connect to the database and issue the query or queries needed to satisfy the report.

In a web application environment, you need to support many simultaneous user requests. You assume that SCOTT is one of many users asking for a different database report. As such, you need to connect to the database, issue your queries to build your web pages, and return the results as quickly as possible.

The stateless environment is not optimal for application server to database communications. The reason is that database connections add significant time to the overall request. In some cases, the database connection time limits the overall ability of the application to scale to meet the requirements placed upon it.

The connection to the database is similar to placing a phone call. First, you dial the phone number, some switching happens, the phone rings on the other end, someone answers, and you say who you are. All this has to happen before your conversation can begin. For a database connection, you first have to figure out who you want to log in as, then you call the database over a network connection; the database answers, asks who you are, and sets up the context of the database session. At this point, the database is ready for discourse. This process of setting up a new database connection for each user request consumes precious time.

Connection Performance Example

A quick Java program can illustrate this point. The program will measure the time required to connect and then disconnect from a database. No queries will be made yet because the objective is to measure the time associated with creating and deleting a database connection:

package OSBD; import java.sql.*; import oracle.jdbc.pool.OracleDataSource;  public class ConnectionTest {   public static void main(String[] args) {     long connectTime=0, connectionStart=0, connectionStop=0;     try {       OracleDataSource ods = new OracleDataSource();       ods.setURL("jdbc:oracle:thin:scott/tiger@DKNOX:1521:KNOX10G");       // Start Timer       connectionStart = System.currentTimeMillis();       Connection conn = ods.getConnection();       conn.close();             // Stop Timer       connectionStop = System.currentTimeMillis();       ods.close();     } catch (Exception e) { System.out.println(e.toString()); }     // print connection time     connectTime = (connectionStop - connectionStart);     System.out.println("Database connection time: " +                          connectTime + " ms.");   } }

After running this several times, the average time was just over half a second to open and close a database connection.

Database connection time: 531 ms.

This is important because 500 ms may be too long for the high-throughput demands of some web applications. It may take more time to connect to the database than it does to query the database. The following code times a simple query that validates this point:

package OSBD; import java.sql.*; import oracle.jdbc.pool.OracleDataSource;  public class QueryTest {   public static void main(String[] args) {     long queryTime=0, queryStart=0, queryStop=0;     try {       OracleDataSource ods = new OracleDataSource();       ods.setURL("jdbc:oracle:thin:scott/tiger@DKNOX:1521:KNOX10G");       Connection conn = ods.getConnection();       Statement stmt = conn.createStatement();       // Start SQL Timer       queryStart = System.currentTimeMillis();       ResultSet rset = stmt.executeQuery(                          "select object_name from all_objects");     // Stop SQL Timer       queryStop = System.currentTimeMillis();       rset.close();       stmt.close();       conn.close();       ods.close();     } catch (Exception e) { System.out.println(e.toString()); }     queryTime = (queryStop - queryStart);     System.out.println("Database query time: " + queryTime + " ms.");   } }

The results from this program prove the theory—the time to execute the query was significantly less than the time to connect to the database:

Database query time: 60 ms.

In this example, you are only considering one user; the problem is exacerbated as the number of users simultaneously accessing the database increases. Therefore, this design—connecting to the database, issuing a query, and then disconnecting—is not scalable.