Chapter 2. Components and Architecture of Web Database

Web database applications make methods of new kinds of software components arranged in new patterns. Everything is still evolving, but a few reliable categories of software and architectures seem to be emerging. At this moment, program developers are going to find a way to explore the new architectures and describe how components are different from each other in addition to how programmers can use them to solve different kinds application problems.

2.1 The Two Tiers of Web Database

In a two-tiered client/server, the computing client talks directly to a server with no other intervening processes (Figure 2.1). The two-tiered client/server is the most common architecture on microcomputer-based LANs. Hence, clients manage the user interface, validate data entered by the user, dispatch requests from clients, execute database retrievals and updates, manage data integrity, control transactions, execute business logic, and send data to clients.

Figure 2. 1 Two-Tiered Client/Server Architecture [11]

2.1.1 Web Database on the Two-Tiered Client/Server

Web tools and databases are two distinct technologies that were developed separately, but both of them are based on two-tiered client/server architecture (Figure 2.2). The partitioning of functions between a Web browser and a Web server is very distinct. The Web server delivers HTML pages and the Web browser displays those pages by interpreting the HTML tags [11]. Neither side can alter this division of labor. Because of this standardization, many different vendors can create web browsers. This is one of the reasons why Web technology is being adopted so quickly.

But the partitioning of functions between database clients and database servers is much less distinct. Decisions about partitioning are often made by application programmers and are influenced by factors related to a project's requirements. This lack of standardization means that a significant programming effort is usually needed to implement changes to a database client and /or a database server. Part of the effort will involve bringing both ends into sync.

Figure 2. 2 Web Tools and DBMS tools are based on the two-tiered client/server [11]

2.2 The Three Tiers of Web Database

The three-tiered client/server architecture introduces a third layer of processing between the client and the server (Figure 2.3). On PC-based LANs, three-tiered is the more recent architecture and what goes on in the middle tier is much less strictly defined than what goes on in the client and server tiers [11]. An important advantage of three-tiered architecture over two-tiered is that it allows the client and the server to lose weight and become "thin clients" and "thin servers." This means that the partitioning of functions can be carried further, and greater modularity can be achieved. Advocates of three-tiered architecture usually agree that transactions should be implemented in the middle layer. Other processes that could be implemented in that layer include translating data from legacy applications on mainframes, handling security and authentication, and generating reports.

Figure 2. 3 Three-Tiered Client/Server Architecture [11]

2.2.1 A Typical Three-Tiered Web Database Application

Web database applications combine their two-tiered parent technologies into a new kind of system. The new system is based on the three-tiered client/server architecture. A Web browser occupies the client tier, a database server occupies the server tier, and the middle tier holds a Web server and a server extension program (Figure 2.4). This architecture reduces network traffic, makes components interchangeable, and increases security [15]. However, this architecture also makes database transaction processing more difficult because of the stateless nature of the HTTP protocol that is used to transfer data between the web browser and the database server.

The Web browser sends Web page requests or data requests to the Web server. The Web server services the page requests and passes the data requests to the server extension program. The server extension program then accepts the requests that are passed to it, converts them to a form that the database server. Next, the database server performs a database task, such as a query or an insert, and returns a result set to the server extension program. Finally, the server extension program converts the database results to a form that the Web browser will accept (for example, HTML), and passes them to the Web server, which in turn passes results to the Web browser.

Figure 2. 4 A Typical Three-Tired Web Database Application [10]

2.3 Server Extension Programs

One of the main reasons for using a server extension program in the middle tier is to take advantage of the standards that already exist at the two last tiers by translating between Web server and database server. Other methods for server extensions are handling database connections to reduce network traffic, and maintaining a pool of open database connections to reduce overhead associated with opening and closing the database [11]. Server extensions also support interchangeability at their standard interfaces. Thus, Web servers and database servers can be replaced or upgraded with relative ease.

2.3.1 ODBC for Server Extension Program

The server extension program translates Web browser requests into ODBC SQL statements, submits them to the data source by the ODBC driver, and retrieves the results. An example of an ODBC function call is SQLConnect, which connects to the data source when given a data source name, a user ID and password, and a few other parameters [22].

2.3.2 CGI for Server Extension Program

The common Gateway interface (CGI) is a standard way of interfacing external applications with Web servers.

A CGI external application executes in real-time and dynamically produces output information. It processes HTTP requests from Web clients and returns an HTML document. CGI external application usually accesses information.

2.3.3 RMI (Remote Method Invocation) Extension Program

RMI enables the programmer to create distributed Java-to-Java applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. A Java program can make a call on a remote object once it obtains a reference to the remote object, either by looking up the remote object in the bootstrap-naming service provided by RMI or by receiving the reference as an argument or a return value. A client can call a remote object in a server, and that server can be a client of another remote object [9].

2.3.4 WebBase for Server Extension Program

WebBase relies on special tags and SQL, but it is tightly integrated with a Web server specially tuned for databases. The WebBase supports the World Wide Web recently adopted standard for Dynamic HTML and Document Object Model. Dynamic HTML lets authors make interactive Web pages that use up far less bandwidth than conventional HTML pages. Dynamic HTML can dynamically modify HTML tags, style sheets, text, tables, ActiveX objects and Java applets without server intervention. WebBase automatically creates the database and the forms to add, update, search and view records in any browser. Users need no special viewers or plug-ins to use the add-on [30].

In addition, WebBase provides solutions ranging from simple access to real estate listings, product pricing, availability, and customer order status to complex catalog ordering applications. Users can make available anything in the database to anyone browsing the Web site or allow access to a specific audience that users control through password protection. Users can also make existing databases far more powerful by adding hypertext links into reports. This feature allows users to delve into a report in detail, while maintaining the simplicity of a high level view.

2.3.5 IDC for Server Extension Program

Many Web servers do not have a database, or other data access mechanisms built in. They rely on the Common Gateway Interface. The Microsoft Internet Information Server is different. It provides database connectivity to any ODBC-compliant database through the Internet Database Connector (IDC). Web page developers provide Web clients with real-time access to an ODBC data source through IDC [14].

Web page developers create an IDC file that resides on the Internet Information Server. The IDC file is a text file that specifies an ODBC data source name, login information, and an SQL query to retrieve data. Web page developers also create an HTX file. It is an HTML formatting template for the data retrieved from the ODBC-compliant database. The IDC file references the HTX file (Figure 2.5).

Figure 2. 5 IDC to Access the Internet Information Server Log File, Stored in the SQL Server Database [14]

2.4 Client-Side Extensions

A client-side extension is a program that adds to the capabilities of a Web browser (Figure 2.6). Users can use client-side extensions for many purposes, but one of their main functions is to perform input field validations. Although there are no formal classifications for client-side extensions, they currently fall into four categories: helper applications, pluggable applications, Java applets, and scripts [11].

 

Figure 2. 6 A Web Database Application with a Client-Side Extension [11]