http://www.informix.com/informix/dbweb/grail/deploy.htm (PC Press Internet CD, 03/1996)
The WWW is being used in many ways. The Web can be used to enhance internal company communciations as well as external/customer interactions. The uses of the Web are endless. Some of the most beneficial uses of the Web include:
The benefits of connecting databases to the Web are extraordinary. There are issues, however, that need to be addressed before launching a database-WWW project. The strength of the WWW project is also its greatest weakness. To promote transfer speed, data integrity checking is minimal. Packet switching is used for moving data, making it difficult to provide for secure transactions. Data transfer is asynchronous, making it difficult for the client and server to keep track of each other's state.
A casual examination of the technology behind the World Wide Web quickly reveals that a trade-off was made between reliability and security, AND speed and near-universal access. The fact is that the architecture and application programming interface (API) of modern databases is nearly opposite to that of the Internet. Access is unrestricted, error checking is non-existant, there is no awareness on the part of the server of the client, and the client knows the server only through a near-endless series of anonymous, unguarded low- to medium-speed connections.
In other words, the Web is asynchronous and stateless. The server and client aren't aware of each others state - or even if they are on or off line. This is a particular challenge for database development because today's database technology makes constant use of the state of the relationship between client and server, starting from the apparently simple issues of 'next' and 'previous.'
In such an environment some of the familiar elements of the transactional model become difficult. Here are some common transactional scenarios and some issues associated with attempting to use them in conjunction with a Web server:
You want to take an order for a product or brochure. There aren't any limits to quantity or availability. Delivery of the product or brochure isn't time sensitive, and if you run out, you can always produce more.
This is an ideal application for today's technology. You simply do an insert to your connected flat-file or relational database and process the data (pass key information to the order fulfillment area of your company) as is convenient.
You want to take an order for a product or service with limited availability. Example: 8 p.m. reservations at a local restaurant.
Things get complicated fast. The reserations may be placed either through the Web or by calling the restaurant. The number of slots available is obviously limited. Every time a reservation is taken, it needs to go in the database. Users of the system may make or change their reservations several times. Since the Web offers no ability to establish a database connection and lock records, you have no way of making certain that there is actually a slot for the customer making the reservation - over the net, by phone or in person.
You want to take a credit card order for a $500 product from your client.
There are several challenges here. First, you need to create a secure transaction, to prevent unauthorized parties from intercepting and using the credit card or other personal information in a way that neither you or your customer would agree to. Secondly, you need to protect yourself from the possibility of being defrauded by your client. It is difficult to identify with certainty a client connected to your Web site. It isn't difficult to masquerade on the Web. Someone could have a stolen credit card, and order merchandise based on it. Pranksters also might enjoy ordering merchandise in someone else's name. In addition to the financial risk, there are also legal risks to consider in terms of collecting and retaining customer information, including credit card specifics.
You just have an informational database--no security concerns and no financial transactions. You'd like to surface the entire 20,000 item database for your associates worldwide.
Although selecting one record at a time is simple, if you surface the ability to query for multiple records, a number of issues arise. If your customer does a SELECT ALL, for example, how are you going to manage the transmission of 20,000 records across the Web? If you prevent that with your application program, how do you communicate the problem to your end user, who won't be willing to wait long for some live data to come back across the net?
Another consideration is the type of queries your users can perform. Performance problems can occur because of the number of layers required to access the database and return data. HTTP servers do not yet support the use of shared memory and multithreading, and although designed for simplicity and compact size, they tend to be rather slow.
In order to deploy internet commerce applications, security issues need to be addressed. Several third parties are presently working on creating secure extensions to HTML to enable the secure transmission of personal information across the Web, including passwords, credit card numbers, and other sensitive information.
Today a typical application will use a shell script (sh, csh, ksh, perl) to either directly execute the HTTP instructions or populate environmental variables and then invoke an application. Without the INFORMIX-ESQL/C and INFORMIX-4GL Interface Kits, Informix languages do not allow the setting of environmental variables and reading from standard input. Therefore, these applications need to be run from a shell script, negatively impacting response time and loosening security.
CGI programs, or scripts, are external executable programs which can be run by the HTTP server. They are external to the server in order to provide maximum flexibility for execution by a number of means. Gateways conforming to the specification can be written in any language that produces an executable file. Some of the languages include the C shell, the bourne shell, the lkorn shell, Perl, C/C++, TCL, and most 4GL or object languages, including those used in Informix products. (More information on HTML client/server interactions.)
One of the first decisions you must make in connecting a database to a Web site, is whether to make the connection visible to the user. This not only determines the appearance and content of your Web page, it also may influence your choice of database access technology. For example, if the users of your Web site are looking for some particular piece of information, like searching on a single field, it isn't necessary to display any of your database. Web searchers such as Web Crawler and Yahoo are great examples. Obviously there is some form of database behind the scenes, but it is completely invisible to the user.
At other times you will definitely want to display portions of your database, possibly making it look exactly as if the user is accessing data from a graphical (or non-) database front end. Frequently this is the case for database interfaces that are deployed internally to organizations using local Web sites as companywide servers.
Another thing to consider is whether you even need a database. For some applications, it is faster and easier to use a product like Informix Software's CISAM combined with a flexible Perl, Awk, or SED script. Obviously this will only go so far. Complex problems such as multiple joins across multiple tables require the power of C or a fourth generation language like INFORMIX-4GL and INFORMIX-NewEra.
A Quick Overview of Architecture and Terminology
What Products Can I Use to Connect Databases to the Web?
[ Home ] [
Table of Contents ] [ Search ] [
Comments ] [
WWW Databases ]