The Ins and Outs of the World Wide Web Building Web-based data entry applications
From "Integration",  Access to Wang, April 1997
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

The popularity of the World Wide Web has opened the possibility of universal access to information, regardless of physical location, workstation type, or other constraints. As this access to information becomes common, there is increasing interest in moving other information applications - including those that take data in - to this approach. But the Web's success in delivering information may not be easily duplicated when the goal is to accept information - a primary role of most business applications.

The key weakness of Web applications in a business context lie in user authentication and data integrity. The Web model is oriented to open information access. Verifying user rights and processing incoming information is inconvenient and the tools are primitive. Data integrity controls at the point of entry - such as field validation - are missing or substantially harder to accomplish than those found in a ACCEPT statement in a Wang COBOL application.

The lure of universal access to applications is strong, though, and it would be foolish to dismiss these benefits because of the difficulties involved in developing Web data applications. There are methods for handling these issues today, and serious data entry applications are emerging. Here are some ways to handle these issues and a comparison with the Wang development environment.

Identifying the user

One of the most important foundations to the architecture of the World Wide Web is the anonymous nature of connections made between systems. With no security information to impart, there is little hindrance to fast delivery of document content - the original purpose of the Web. This limitation can be overcome through passwords or by limiting access to the site based on the address of the requester. Password protection is easily broken, so limitation of access is usually the best approach.

Assigning rights to users, though, requires support from the application itself. Unlike Wang systems, there is no inherent security system built into Web application, so you must build it into your applications. Again, control over access to the point of entry can provide much of this control.

Workstation sessions: preserving "states"

Web connections are referred to as "stateless." This means that each request from a browser to the server is handled independently, without regard to any requests that have been made before. To compare with the host-terminal model of Wang systems, it's as if the user logs on the system, requests a single page of a program, receives that page, then logs off, repeating the process each time a new page is needed. Like anonymous connections, the stateless design of the World Wide Web protocol was intended to reduce overhead and thereby speed the delivery of content. It would be difficult to imagine an application program that would work well in this situation, however, so there are methods employed to retain state information in Web applications. Two of the most popular are the GET method of forms posting and cookies.

The GET method is one of three forms posting approaches, and most often used with search applications. Like most other forms posting approaches, it uses application programs known as CGI (Common Gateway Interface) to receive parameters from the Web page and return results in the form of other Web pages. The GET technique adds state information to the URL (Universal Resource Locator) as a means of preserving it between server requests. For example, the URL for a search session might include the base address of the search engine (http://www.myapp.com/search) with the addition of some search criteria you've entered (e.g. "search for the word 'database' in the 'UNIX' category with up to 25 'hits'" (returned items per page)). The resulting URL might look like this:

http://www.myapp.com/search?&search=database&category=UNIX&hits=25

Translated, three variables have been defined (&search, &category, and &hits) to pass the information to the program ("search") responsible for retrieving the data. Because the state information is now "stored" in the URL, the server can refer to it and proceed to the next step: returning its results. This address can also be saved and the results regenerated at will.

Cookies are small files stored on the client's workstation that can be read by the server to identify who has used an application before. They were very controversial when first introduced because they diverge from the Web ethic of avoiding any local storage (and its attendant security problems), so the major browsers offer options to warn users about cookies or prevent them from being stored. The contents of a cookie are determined entirely by the application programmer, but they must be named in a manner that can be identified and extracted by the same program later. Cookies are commonly used in "smart" Web sites, particularly on-line shopping services, to identify personal preferences and customize the information presented.

Other methods of preserving state information are being developed daily. While not widespread, there are a growing number of Web applications that can read and write local files, making it easier to retain session information. Whatever the method of retaining state information, however, it must be passed to the Web application with each request.

Workstation screen control

Once the user has been identified and the server is expecting information from the session, the application's entry form must be considered. Most business information must be entered in what I call a constrained form; that is, within specific limits of size, data type, and context. For example, a typical input screen might request a first name that is no longer than thirty characters and contains only letters. By context I mean that the information would be internally consistent, such as a birth date that is earlier than today's date or only those codes that are allowed by the application.

As a Wang application programmer, I expect to be able to control all aspects of the user entry and validation, including data types, field size, and other items. It should not be possible, for example, to enter an address in an area intended for the phone number, nor should the user be able to key in six digits when five is the maximum number allowed. All of these items can be easily controlled within a Wang application screen. Further checking can also be performed when the user has filled the screen and presses the ENTER key, and data exceptions can be noted with on- screen messages.

Wang users also expect visual clues about the application's data requirements, such as the size and data type of fields and what information should be entered next. As each field is filled, they expect the cursor to jump to the next field (automatic tab-out), allowing them to continue working. When data exceptions occur, they expect the application to highlight the specific items that must be corrected - not require them to re-enter the whole form.

In contrast, the HTML forms are very primitive, allowing little control over the size, type, or validation of the entered information. Limits to field size are possible, but type validation (number, letter, etc.) is not. It is not normally possible to highlight specific items to be changed nor present meaningful messages about how items should be corrected. If coded information is required, it is possible to allow users to select items from list boxes, but there are practical limits to the length these lists can be. Therefore, the most successful Web data entry forms are likely to be those with only a few simple items to enter.

Emerging technologies

The Web changes daily, and some of its tools do, too. Web integration with data bases is a very hot area right now, so there is a large amount of activity. All this interest results in a large number of interesting products, bad quality control, and confusion in the marketplace. Here are some alternatives to the tools and methods discussed above:

• Java: An application language in its own right, Java applications can be delivered within a Web browser to run on local machines. The primary benefits of this arrangement is portability across workstation types and better control of information integrity than that provided by HTML alone. Another advantage is version control: since the applications are delivered from a central source as needed, end users will always have the latest version. Requires support for Java at the client end, which is built into the major browsers already.

• Active Server Pages: A server-side application approach that allows database information to build Web pages dynamically, based on their request or other information. Generated pages appear to be regular HTML documents, so no special browser support is necessary. Available only on Microsoft's Web server products, though competitors will be developing similar products soon.

• ActiveX: A structure for building applications that can lie within Web browsers and perform most actions that other workstation applications can. Requires support for ActiveX components at the client end, either through the browser (Microsoft's Internet Explorer) or using plug-ins (Netscape).

• Script languages: Several languages with similar features compete in this arena. Popular choices include JavaScript and VBscript, Microsoft's language based on Visual Basic. Most script languages are browser-specific and do not have enough of an installed base to be practical at this time.

Are you ready for Web applications?

While the hype of web-based applications is nearing hysterical levels, there are notable problems in moving most applications to this environment. Chief among these is the fact that the web was designed for information retrieval without need for user identification and authentication, database update integrity, or any other mechanisms that add resource requirements and slow the process. Still, web- based data applications are ideally suited to many reporting needs, providing universal access for users regardless of their physical location or computing platform.