Web Application Architectures

There are essentially only two ways to access databases over the Internet: 1. Using Web browser (and forms) as the client. That is, to develop web forms applications using web server backend tools. This architecture typically relies heavily on the CGI gateway. This approach grants access to anyone with a web browser. 2. Using a programming language such as VB as the client. This alternative permits you to use the development tools that you are familiar with, like VB, VC, Powerbuilder or MS Access. You can develop your application on a local database, then deploy the application using the Internet to access your database.

In addition to the above primary access themes, there are multiple variations on these themes including:

using front-end database application development tools enriched with Web access;
using Web servers and browsers augmented with database-aware features;
communicating with a database server via an HTML browser with embedded scripts enriched for Web access;
communicate directly with a servers via a programming language with imbedded HTML capabilities; or
deploy Web servers and browsers augmented with database-aware features.

For the purpose of this discussion only the first two scenarios will be considered.

Using a Web Browser as the Client

The formatting capabilities of the browsers are relatively powerful, but do have some limitations. Documents are formatted by the browser to fit the display area, so the HTML documents must be designed to be displayable in any reasonably sized window.

Data entry is made possible by using 'forms'. These can include radio buttons, push buttons, pull down pick lists and user entry fields of any size (single line or scrollable text areas). When the form is submitted by the browser to the server, the data entered in the form, the position of radio buttons, and which button may have been pressed to submit the form are all passed as parameters to the server which in turn will pass this information to the CGI program which will process the data.

The only data entry validation which can be done when the user enters data is to place items in pick lists and/or to limit the length of the data entered. Any other validations must be done by the receiving CGI program when the form is submitted, or through the introduction of a scripting language such as Java Script or VB Script, which would enable some additional client-side validation and control.

The form may originally have been loaded (sent to the browser) from an HTML document file, or may have been generated by a CGI program.

Using a Programming Language such as VB as the Client

An alternative to using a standard browser is to use a Visual Basic application as the Client. This application would be written for a specific application and would appear to the server as if it were a normal browser. Data entered via the VB client program is sent to the HTTP server in the same form as a Browser would have sent it, data from the server would be processed and/or displayed by the VB client.

However, since the data entry is being handled by the VB application, the entry form can include any of the elements allowable in VB, and some entry validation can be done at entry time by the application. In addition, while normal processing would probably mean that the data entered is only sent when the form has been completed, the VB application could send data at any point during entry for processing/validation/data retrieval by the CGI program.

Data returned from the CGI program via the server can also be formatted or processed in any way required by the VB Client since this aspect is no longer limited by the capabilities of a browser. An additional advantage is a speed gain, since the returned data does not need to include the HTML formatting code or any of the image data - the formatting would be done by the VB program and any images would be part of that program.

Alternatively, one can write VB application that bypasses the Web (or FTP, etc.) server and talks directly to the database connector by deploying Windows sockets. Of course, this would require low level calls the WinSock layer to manage the connection. This is the application architecture deployed by most Internet mail client packages such as Eudora.

Browser vs VB as a Client

There are advantages and disadvantages to either type of client. The best client to use would be dictated by the business objectives of the application. Moreover, it is important to note that both the browsers technology and the application development tools are undergoing rapid change, incorporating each others strengths. Thus, what might be lacking in one tool today may well be a feature of that tool next week.

A summary of the advantages/disadvantages of these client programs based on today's technology is presented below.

Browser Advantages
- No distribution required. Since all formatting is controlled by the HTML codes included in the documents sent to the browser, any modifications to an application are only made in the CGI program and any related HTML documents. These changes will be effective immediately without having to send any software to the users.
- Hypertext Capabilities. Any required program documentation, such as user guides, could be stored as HTML documents and would be available on line to the user at all times. Changes to the documentation become immediately available.
Primary Browser Disadvantages
- Less control over the final appearance of a document.
- Limited validations at entry time. During data entry almost no validation can be done. The entry screen must be sent to the server where the CGI program would do any validations required. (In the event of errors, the CGI program could send back the form, complete with the data already entered, along with an appropriate error message.)
- Everything to be displayed must be transmitted to the browser - including any images or icons.
- All data accessed would have to reside on the remote system - nothing could be stored locally.
VB Client Primary Advantages
- Screen layouts are entirely under control of the application and can include any allowed VB elements.
- Interaction between the VB client and the server/CGI program are entirely under control of the VB client - a screen does not have to be completed before any data is sent or retrieved.
- The VB client could access both local and remote data, and could store data both locally and remotely. Thus the client program could access a local database as well as a remote data base. This could significantly improve response.
- The VB client can do some local validation of data entered - both validation which can be handle internally in the program (allowing only certain types of data to be entered in specific fields) or validation against a local database.
VB Client Disadvantages
- Any changes to the application affecting the client would require up to date version of the software being sent to the user (although this update process could be automated).
- Programming is more difficult since the processing of the data is split between two programs - the VB client and the server CGI program. In practical terms, developers must have PC's capable of running a server so they can develop applications in an independent environment (without affecting a live server).
- At the present time, VB cannot take advantage of Hypertext technology.

Programming Considerations

Programming for this new environment requires some restructuring of the traditional windows programming approach:

When using a VB client, the GUI is separated from the processing CGI program on the server. This requires a different approach in programming from programs where the GUI and processing are in the same application.
When using a browser client, the processing program must generate HTML documents or forms as part of the response output. When data is returned by the CGI program, this would be included as part of the HTML output. This is a different approach from just placing data in fields or display areas contained within the same program.
Since the server will launch the CGI program for each request, the size of the program becomes important, as a large program takes longer to launch (as well as use more machine resources), this will add to the response time. This means that the server side processing requirements are best handled by a series of smaller programs rather than one large program, as would be done in a traditional approach.
Since each request to the server is completely independent of every other request, each execution of a CGI program is 'new' (It has no memory of what was done for the specific user the last time it ran.). That is, current web browser/server implementations do not support persistent connections. Thus, when an invocation of the CGI program must know about something that occurred previously (such as user validation via ID and password), this information must be passed back to the client as a hidden item (hidden field(s) for a browser, or undisplayed data for a VB client), and would then be passed by the client back to the server for the next operation.
Because of the need for a different structure, initial design time may take longer as the various aspect of this new environment have to be taken into account. Consideration also needs to be given to the learning curve involved for programmers learning to deal with this new environment.

Skill Sets

Choosing and building the right Internet architecture means taking into account your existing application development skills and hardware support skills. Factoring in existing skills may prove to be more important than any of the architectural components. If you have VB skills in house, then it makes sense to deploy an Internet strategy that leverages those skills. The cost of not doing so may mean additional training and support costs.