II. Server Application Tools Solution
Development tool vendors, recognizing the limitations of pure CGI, have developed tools that address these limitations out of the box. HTTP vendors, Microsoft and Netscape offer alternatives to CGI which utilize server resources in a much more efficient manner. These alternatives are known as Internet Server Application Programming Interface (ISAPI) and Netscape Server Application Programming Interface (NSAPI) respectively. The combination of the two provides a solution, which manages context and provides easy access to all popular relational databases, as well as maximizing server resources.
The development tools now offered provide context management and other utility functions that are tested and well documented, allowing developers to focus on application-specific functionality. Most of the tools offer a choice of CGI or CGI alternatives. Offering CGI as an alternative serves to prevent the risk of HTTP server vendor lock-in.
Figure 2 illustrates the components of the Server Application Tools approach and their relationships. Figure 2 also shows a configuration where the development tool utilizes an HTTP server CGI alternative.
Figure 2 Server Application Tool Approach
Rapid Development. The tools in this category come with easy-to-use database access, utility functions to create dynamic pages, and resolution of client request parameters. WYSIWYG HTML editing prevents maintenance headaches. In addition, sample applications and tutorials may be included to speed developers along the learning curve.
Scalable Architecture. The alternatives to CGI provided by HTTP vendors are much more efficient that CGI, enabling a significantly larger number of concurrent users to be supported.
New and Untested Technology. The vast majority of these products are immature and untested. Until you build your application and stress test it, there is no guarantee the products will perform to your expectations.
Uncertain Vendor Future. The number of vendors competing in this space is very large. Vying for this market are startup companies with roots in Internet technology, and traditional client/server tools vendors, Web-enabling their development environments. Since it remains uncertain which of the startup vendors will survive, it is wiser to select tools developed by an established and stable supplier.
III. Distributed Objects Solution
The distributed objects solution represents the most advanced of the three approaches presented here. The Distributed Objects approach is utilized for mission-critical or heavy on-line transaction processing systems. Its architecture comprises three tiers. The client platform (tier 1) consists of any workstation platform running a Java- or ActiveX-enabled Web browser. The client provides presentation logic only. The middle, or second tier, provides objects which contain business logic. The third tier contains data, usually a relational database.
The Distributed Objects solution allows clients to have more traditional interface tools such as tab folders, spreadsheets, and tree views. In addition, the client tier has a direct connection to the second tier. All communication between the client and business objects is handled by distributed objects middleware, Common Object Request Broker Architecture (CORBA -- See http://www.omg.org for details) and Distributed Component Object Model (DCOM -- See http://www.microsoft.com for details).
Figure 3. Distributed Objects
Client Application. The application is implemented as an applet embedded in an HTML Web document on the Website. This applet is downloaded from the HTTP server along with the HTML documents and run in tier 1 on the client workstation. Each user is required to provide a log-in I.D. and password before any database activities will be permitted. Once authenticated, the user will interact with the system in a manner similar to traditional GUI client/server applications. All data access is handled by the data server application.
Data Server Application. The server is a collection of business objects that are exposed through DCOM or CORBA. The business objects perform data validation and database transactions to fulfill client requests. In most cases, these servers are multi-threaded.
Richest User Interface. The Distributed Objects approach provides a sophisticated client/server application look-and-feel combined with multimedia capabilities to the graphical front-end.
High Portability (Java only). Highly portable on clients and servers, this solution allows you to leverage the current platform as both HTTP and application server.
High Scalability. Multi-threaded server implementation scales well. Each user request is handled by a separate thread, which is significantly more efficient than a separate process.
Superior Development Environment. Excellent development environments, including fully functional debuggers for both client and server, support Java and ActiveX environments.
Requires High Level Development Skills. Support personnel would be required to know both Java and CORBA. This level of knowledge is in line with the complexity of C++ today.
Higher Cost. The middleware for the Distributed Objects solution can carry a substantial cost, potentially as high as $10,000 per deployed server and $5,000 per developer. Thus, the time required to gain the backing for this decision within an organization may slow initial development.
All three of these Web application development approaches have their place, depending on the specific application requirements and budget constraints. However, CGI alone should rarely be used. The productivity of server application tools is money well spent. Applications developed with these tools are best suited for reporting and automation of paper-based systems. Going further up the complexity scale, if you are developing a mission-critical or On-Line Transaction Processing application, the Distributed Objects approach offers more sophisticated user interface and scalability, thus ensuring your technology investment throughout the useful life of the application.
About the author: