Chapter 16
SQL on the Internet

In This Chapter

• Comparing the Internet with a local access network
• Discussing client/server and Web architectures
• Defining the role of SQL on the Internet

The Internet, and particularly that portion of it known as the World Wide Web, has mushroomed in importance in the last couple of years. Just about every aspect of computing seems to be viewed in light of how it relates to the Web. Database is no exception. The World Wide Web lives up to its name. It provides a web of connectivity that envelops the globe. Anyone anywhere who has an Internet connection can access data residing on a Web server on the other side of town or, just as easily, on the other side of the world.

The ability to make your data available to anyone anywhere in the world opens up a whole new kind of database usage. This new usage, database publishing, is more akin to book publishing or radio broadcasting than it is to the point-to-point communication characteristic of operations on a local area network. The information you make available on the Web can be accessed and used by thousands or even millions of people that you will never meet. The most popular sites on the Web today receive more than a million visits, or hits, a day. You can make a substantial impact with your Web-based database, even if you are nowhere near that league.

The LAN is SQL's Ancestral Home

SQL was originally created by IBM to facilitate communication between large databases residing on mainframe computers and users on client machines that were connected to those mainframes by a local area network (LAN). SQL gradually became a defacto standard means, and then an official ANSI and ISO standard means, of communicating between users and databases. Companies producing relational databases designed to operate across local area networks embraced the SQL standard and made it the communications medium of choice on systems in which the user was located on a different machine from the database, with a LAN running between them.

SQL, coupled with ODBC, enabled an application running on a user's machine to simultaneously access data located on two or even more server machines. This combination proved to be a great boon to organizations whose information processing infrastructure had grown up over time without the benefit of centralized planning. Different machines, running different operating systems and different applications, could share information. Marvelous as this kind of flexibility is, it pales in comparison with what is possible over the Internet.

How the Internet Differs from a Classic LAN

A local area network (LAN) is a collection of computers that are all in physical proximity (that's where the local comes from). The computers, forming nodes on the network, are interconnected by wired or wireless communication links. Many local area networks are small, having anywhere from 10 to 50 nodes. Large organizations may be served by LANs that have more than a thousand nodes. In either case, you can exercise some centralized control over the network. This makes specifying a proprietary database interface possible, and you can expect all the users to be using access tools that are compatible with it.

The Internet is an entirely different story. It has millions of nodes, and they are not in physical proximity. No one has centralized control over what goes on. In this environment, the owner of a database server cannot make any assumptions about what kind of access tools the user has. The user has a Web browser, possibly supplemented with a plug-in that hosts the client end of a client-server database system. Because the most popular Web browsers run on all the popular client platforms, the client software does not have to be specifically tailored to run on a specific back-end database.

Note: The ordinary Web browser, such as Netscape Navigator or Microsoft Internet Explorer, comes close to being that Holy Grail of database access, the Universal Front End. If it existed, the Universal Front End would interface seamlessly with any database server that you want. It would allow the user to create tables easily, manipulate data, and operate database applications regardless of what kind of server the database is on or what kind of DBMS is controlling it. By itself, a browser cannot do this, of course. But by downloading the appropriate Netscape plug-in or ActiveX component (see Chapter 15 for more about these) before attempting to deal with the database, the browser can come very close. When a connection is established, state-of-the-art database publishers check the client machine for the appropriate plug-in. If they find it, they download the client part of their application and proceed. If they do not find the appropriate plug-in, they download the plug-in, followed by the client part of their application. This whole sequence can be relatively transparent to the user.

Two areas where operation on the Internet may differ significantly from operation on a LAN are network protocol and security. If you are considering allowing remote access to your database from over the Internet, you should carefully consider the impact of these two aspects of operation.

Network protocol

In order for the nodes on a network to communicate with each other, they must all speak the same "language." When one node sends a message, it must be formatted in such a way that the intended receiving node can understand it and take appropriate action. The people who first hooked personal computers together to form local area networks were not concerned with making their systems compatible with the Internet. At that time, the Internet was running only on large mainframe computers that ran the UNIX operating system and that were located at government organizations and research universities. The personal computer world seemed far removed from that of the mainframes used by "big science." Consequently, the "languages," or protocols, that were developed for PC LANs were different from what the Internet used.

Today, many PC LANs still operate with protocols that have evolved from those early PC protocols. The IPX/SPX protocol and the NetBEUI protocol are probably the most common of these. In contrast, the Internet uses a protocol named TCP/IP (Transmission Control Protocol/Internet Protocol). Anyone who wants to engage in database operations over the Web must do so using TCP/IP. Generally, this doesn't require any kind of a hardware change, but it can require a software reconfiguration.

Security

Security is a much bigger issue on the Internet than it is on any organizational LAN. On a LAN, you can be reasonably sure that no one is going to purposely try to sabotage your system. On the Internet, that would be a very foolish and dangerous assumption to make. All kinds of people are out there on the Internet, and some of them may want to hurt you -- just for the sheer, twisted fun of it. Competitors or even enemies may have stronger reasons to give you trouble. When you are exposing your database server to the Internet, you must take significant extra precautions, beyond what would be normal for a LAN.

The principal defense against attacks by hackers or other malefactors on the Internet is to install a firewall between your organizational network and the Internet. A firewall is a software system, or combination of hardware and software, that insulates your network from the Internet. All traffic, both in and out, must pass through the firewall. The firewall authenticates the packets passing through it according to standards that you set up. It passes packets that meet your criteria and throws away those that don't. It also allows you to monitor traffic for suspicious activity and to trace attempts at breaching your security.

When you make the decision to take the big step of putting your server on the Internet, be sure to provide adequate protection to sensitive information that you do not want inquisitive outsiders to know or malicious outsiders to damage.

From Client/Server to Internet-based Database

Most database systems found on LANs are structured according to client/server architecture. Data is stored on one or more servers whose specific task is providing access to that data. Smaller, client machines are spread throughout the organization. They host the user interface of the applications that access the database. Users, interacting with the client part of the application, access the data on the server by communicating over the LAN.

Compelling reasons exist to make database data available over the Internet. A commercial enterprise may want certain of its operational data to be available to vendors or customers with which it works closely. Such an enterprise may want to make detailed information about its products available to the general public, in hopes that some of them will become customers. Entities that are in the information dissemination business, such as libraries, may want to make their information available to a wider audience than those who are able to make a physical visit. For these and other reasons, many groups have decided to establish a presence on the Internet.

Beyond putting up a simple Web page, many organizations are engaging in database publishing, making selected internal information available to those who access their Web site. Some such information is freely available to anyone who logs in to the Web site. Using passwords, publishers can restrict access to authorized users, enabling them to access proprietary databases on the site or databases for which a fee is being charged.

The client/server architecture provides many of the key ingredients of a successful Web database publishing installation. Clients on the Web have similar equipment and operating environments to what is typical for clients on a corporate LAN. The database server of a Web-based system is no different from what serves that purpose on a LAN. Yes, you must address protocol and security issues, but good solutions exist for both. Investigating how client/server architecture may be applied to Web database publishing makes sense.

Two-tier client/server architecture

The original implementation of client/server computing on PC LANs used a two-tier architecture. This architecture had two main elements -- the database client and the database server -- connected by the LAN. You can implement a two-tier client/server system in several ways. One way, the so-called fat client architecture, places most of the computational burden on the client machine and relatively little on the server. A second major architecture is the thin client (also called fat server) model. Here, most of the computation is done by the server, and the client provides little more than the user interface. Figure 16-1 is a schematic representation of a two-tier client/server system.

Regardless of how a two-tier client/server system is implemented, all the necessary functions are performed by either the database client software on the client machine or by the database server software on the server machine.

Three-tier client/server architecture

Three-tier client/server architecture is a relatively new development that is rapidly replacing the older two-tier model. It adds another functional block or level to the server side of the system. This new functional block, often called middleware, assumes some of the responsibilities normally handled by both the database client and the database server, allowing both of them to be thinner. Thinning the client is good, because potentially so many of them exist, and the less capable the client machines need to be, the cheaper overall the system will be. Thinning the database server is also good because, when freed of computational tasks, the server can concentrate on moving data into and out of the database, speeding up operations. The higher level of modularization in a three-tier system also makes maintenance and troubleshooting easier. Figure 16-2 is a schematic representation of a three-tier client/server system.

Two-tier Web architecture

The traditional architecture of the World Wide Web can also be viewed as a two-tier structure. A Web server hosts HTML (HyperText Markup Language) pages, which are accessible over the Internet to Web browsers running on client machines. This architecture is similar to a two-tier client/server system in that the Web browser on an Internet client performs the same function as the user interface running on a client/server database client. The Web server performs a similar job to that of the client/server database server -- dispensing information. The main differences are that a Web browser is thinner than even the thinnest database client in a thin-client client/server system, and a Web server is incapable of the database manipulation required of even a thin-server implementation of a client/server system. This state of affairs is fine as long as you are not trying to perform database operations over the Web. If all you are doing is putting HTML pages up for people to read, you don't need to do anything more. Figure 16-3 shows the structure of a two-tier Web system.

Three-tier Web database architecture

To effectively perform database operations over the Web, you must combine elements from a two-tier client/server system with elements from a two-tier Web system to produce a composite three-tier solution. On the client side, the Web browser, perhaps enhanced by a Netscape plug-in or ActiveX component, provides the database application user interface. On the server side, the database server interfaces directly with the data source, just as it does in a classic client/server system.

The three-tier Web database architecture differs from the three-tier client/server database architecture in the middleware. The third tier (middleware) of a three-tier Web database system incorporates the Web server of a two-tier system and adds to it a server extension program. The signals and protocols handled by the Web server grew up in the Web environment and are accepted as standards in that realm. The signals and protocols that the database server is accustomed to seeing grew up in the client/server environment and are accepted as standards in that realm. The server extension program translates between these two incompatible standards. When requests are traveling from the client out on the Web to the data source behind the database server, the server extension program translates HTML to a form that the database server can understand, such as ODBC-compliant SQL. When result sets are traveling in the opposite direction, the server extension program translates them back into HTML for transmission over the Web. Figure 16-4 schematically shows the structure of a three-tier Web database system.

The Role of SQL

SQL was originally developed as a means for a remote client to communicate with a database. Local area networks (or wide area networks) passed the SQL from client to server, encoding it according to a network protocol on the source end and decoding it at the destination end. A Web-based system adds an additional level of complication. The Web browser on the client end transforms a user request into packets in TCP/IP format for transmission over the Web. At the server end, the Web server passes these packets on to the server extension program, which translates them back into SQL that the database server can understand and respond to. So, whether you are accessing a database over the Web or on a LAN, SQL is the means by which communication is conducted.

Where ODBC fits in

Whereas SQL is a standard language for communicating with a database, database vendors comply with that standard (commonly called SQL-92) to a greater or lesser extent. An application using SQL for database access is by no means guaranteed to successfully communicate with a DBMS that claims to be SQL-92 compliant. You have two ways to address this problem. One is to write native drivers for all the popular database servers. A native driver is specifically written to communicate with a particular database server, and no other. For example, Netscape provides native drivers for Informix, Oracle, and Sybase databases and is working on a native driver for IBM's DB2 database. Microsoft provides native driver support for its own SQL Server database.

Native drivers are fast and efficient because they are specifically written for the database client and database server that they are connecting. The disadvantage is that a different native driver must be written for each database that you want to access -- for each database client to which you want that access to be provided. The magnitude of the task of providing all those drivers for all those combinations of clients and servers motivated Microsoft to develop, and the industry to adopt, ODBC as a standard method of conveying SQL statements from clients to servers. If the SQL on the client end is always ODBC compliant, only one driver must be written for each type of server, and far fewer different server types exist than do clients. ODBC-compliant drivers are now available for the overwhelming majority of servers that anyone would want to connect to.

Java and SQL

Java is a language developed by Sun Microsystems specifically for use on the World Wide Web. It is similar in many respects to C++, but simpler to learn and use. People maintaining Web sites create applications written in Java, called applets, that reside on their Web server. When a user connects to a database server, the server downloads an applet to the user's browser, where it serves as a client-side extension to the browser. This system allows the user to access much more of the functionality available on the server than what's possible with just a "plain vanilla" browser.

SQL is a data sublanguage. It was never meant to be a complete language in itself, but was designed to be embedded in programs written in some other "host" language. Java can serve the function of being that host language just as well as can C++, Basic, or any other commonly used programming language. Sun has published a specification for JDBC (Java DataBase Connectivity) that performs the same function that ODBC performs in making a client-generated SQL statement understandable to a wide array of possible database servers. The JDBC standard provides writers of Java applets with the ground rules they need to produce applets that will work with multiple, different database servers.