In-Depth
Beyond document publishing, to Internet transaction processing
Developers have a choice among a variety of Internet/Web execution architectures
when building Internet transaction processing applicationsUntil quite recently,
Web site authoring was where the bulk of Internet-related application development
was focused. Using advanced HTML editors, developers could quickly construct
static Web pages, build hypertext links to other Web pages and create icons
that defined a hyperlink.
Browsing for content is mainstay functionality for the Web and will remain so. Yet to limit exploitation of the Internet/Web to document publishing undervalues its potential for corporate sites. Following the release of new dedicated Web development tools, and the Web enablement of existing client/server tools, both at the low and the high end of the capabilities spectrum, organizations have begun to extend their use of the 'Net.
The current area of corporate interest (and vendor interest) in the 'Net is focused on the provision of basic data access capabilities from Web browser clients. Still, basic data access (even with simple write functionality) is too limited. While building Web pages and accessing databases from Web clients are important undertakings, the fullest potential of the Internet/Web will only be realized when it is also linked into conventional business systems (transactional systems).
Forward thinking organizations are already building their first Internet transaction processing (ITP) systems. The tools and techniques required to build such systems, while in their first generation, do exist at this time. The bulk of the industry is barely at the stage of providing database access from Web clients. But the world now operates on Web time. Now is the time for critical decision making with regard to selecting tools that support the development of ITP systems.
Logic dictates that development managers must have an understanding of both the various Web architectures that support Internet transaction process, as well as the individual tools that generate for these architectures. This article, the first in a series of two, generically describes the basic Web execution architectures, and how tools are exploiting them to deliver ITP systems.
A simple, stateless environment
The glory of the Web -- its simplicity -- is reflected in the limited number of Web protocols and the uncomplicated interaction model for Web client-to-Web server communication. For example, the Web is a stateless environment. To begin an interaction, a Web browser connects to the HTTP server and requests an HTML page. The Web server responds to the page request by returning an HTML page (See Fig. 1), or by triggering an external application via a server API or other mechanism. (See Fig. 2 and Fig. 3.) Once the page is delivered to the browser or the application executes, the transaction is complete and the connection closes.
|
Fig. 1: Browsing for content
The simple request/reply interaction model excels
at delivering static content.
Source: SPG Analyst Services
|
|
In the classical client/server model, connections between clients and database/application
servers remain open until the client logs off. It is not so with the Web. The
Internet/Intranet environment provides no mechanism for keeping the client-to-server
connection open, or for monitoring a user's activities (or persistently storing
a log of activities). Each time a new page is requested, the user, Web server
and any additional processing must be reidentified or reinitialized.
The stateless nature of the Web is perfectly suited to transferring hypertext
documents from Web servers to Web clients. However, the lack of "statefullness"
in the Internet/Intranet environment makes it difficult to create Web-based
applications requiring multiform client-to-server interactions, or applications
with even the most limited notion of transactional semantics.
What is required
Internet/Intranet development tools must support three general types of functionality to be successful in delivering Web-enabled transactional business systems. First, they must provide database access and some link into application servers. Second, the tools must provide an infrastructure for overcoming the stateless nature of the Web. Finally, the tools must build applications that integrate mainstream transactional business systems with the 'Net. That is, they should be capable of building Web-enabled, complex, high-integrity systems, supporting thousands of users, guaranteeing minimal response times and providing 7x24 uptime.
Common Gateway Interface
Currently, the most common method of interfacing Web servers to external database and application servers is via the standard Common Gateway Interface (CGI), which is supported by all Web servers. Using CGI, a browser can initiate or pass information to server-based programs written in any 3GL supported by the Web server OS such as Perl, C, C++ and others. Basically, the Web server receives a request that specifies the Universal Resource Locator (URL) of a CGI program (which are often referred to as scripts). CGI programs extract variables and data from a parameter list coming over from the Web client. The CGI application then passes the appropriate arguments to the external program (database or application server), receives the results from the called program after processing and then passes back this information to the Web client in the form of a HTML page. (See Fig. 2.)
|
Fig. 2: The CGI Interaction Model
CGI-to-server gateways are the most common mechanism
for providing databases any applications from Web browsers
Source: SPG Analyst Services
|
|
While the simplicity and ubiquity of the CGI approach has made it the most common
method for Web clients to access database and other back-end "services," the method
is not without its problems, especially in the area of performance.
First, simply determining that a URL is requesting a CGI script is a multistep process. For example, the Web server parses the URL to determine if the URL request is for a file in an executable directory (cgi-bin in the case of CGI). If so, the CGI program then executes. At this point, CGI's performance crippling parsing and parameter passing operations take place. To make matters worse, for each Web client-to-Web server connection, a new CGI process must be executed and then shut down. In addition, clients can make multiple CGI calls in succession.
Performance issues are not the only downside to using the CGI approach. CGI, for example, does not provide any mechanism for maintaining information about the state of the client or of the session. Also, database interfaces must be hand-coded in the CGI program using the specific SQL dialect of a target database server. This is a time consuming process and one which limits the portability of CGI programs. Finally, CGI presents a security threat. Inherently, CGI provides nothing in terms of security. Without the appropriate precaution taken by developers, it is possible for errant CGI programs to provide entry to the Web server OS from Web clients.
Web server APIs
The second way for Web browsers to interface with server back ends is to use proprietary Web server APIs such as Netscape's NSAPI and Process Software/Microsoft's ISAPI. The use of proprietary Web server APIs such as Netscape's NSAPI and Process Software/Microsoft's ISAPI in place of CGI address many of the limitations of the CGI model. The proprietary server API approach, which allows parameters and results to be passed directly between Web servers and application/database servers, is much more efficient in terms of performance than CGI. (See Fig. 3.) CGI's performance-crippling parsing and parameter passing operations are simply bypassed. The proprietary Web server APIs also offer more in the way of security than the CGI approach.
|
Fig. 3: Proprietary Web server APIs
Using proprietary Web server APIs, parameters
can be passed directly between Web clients and application/database
servers.
Source: SPG Analyst Services
|
|
The proprietary Web server API approach improves overall performance and also
offers more in the way of security than the CGI model, but still problems exist.
NSAPI and ISAPI APIs are proprietary, and therefore bring up questions of interoperability
and vendor lock-in. For example, systems written to ISAPI can be run against both
the Microsoft and Process Web servers, but not against Netscape's family of Web
servers.
Similarly, applications written to the Netscape API cannot be run against the Microsoft or Process servers. Developers creating applications that must run over a variety of Web servers must support both NSAPI and ISAPI. Except for CGI, no "standard" Web server API exists, nor is any on the horizon.
At this time, development tools can be differentiated as to their support, or lack thereof, for proprietary Web server APIs. Both Netscape and Microsoft are de facto standards as Web servers, and as a result, vendors will eventually support all three. Support will come sooner rather than later. Most products currently supporting only CGI "piping" to back-end database and application services will support all three APIs by mid-year '97.
Web server/DBMS hybrids
Proprietary Web server APIs offer advantages over the CGI model, but still they are an additional software layer between the Web client and the database. Database vendors have released products that eliminate this layer, further optimizing the Web/database link. (See Fig. 4.) The basic approach is to layer HTTP server functionality on top of a DBMS engine. Thus IBM's Merchant Server, Oracle's WebServer, Informix Web Datablade, Netscape's LiveWire Pro and Sybase's web.SQL are based on the DB2, Oracle, Informix, Informix (again) and Sybase RDBMS engines, respectively.
|
Fig. 4: Web server/DBMS hybrids
With Web server/DBMS hybrids, HTTP server functionality
is layered over a DBMS engine.
Source: SPG Analyst Services
|
|
The various Web server/DBMS hybrid implementations, like the CGI and proprietary
Web server API approaches, support dynamic construction of Web pages from data
returned from the database. They also are able to maintain transaction states,
something the other approaches do not. Moreover, Web server/DBMS hybrids can
be configured to open a database connection at server startup. All incoming
requests then use the open database connection, thereby improving performance.
In general, Web server/DBMS hybrids additionally provide much more functionality
in terms of security, than is typically obtained using the Web server API technique.
First, vendors exploit the standard security features of their own DBMS. In
addition, vendors have alliances with firewall vendors and support security
mechanisms such as the Secure Sockets Layer encryption standard.
The advantages of the hybrid Web server/DBMS approach is not without its downside. Depending on the actual implementation, the cost of the hybrid Web server/DBMS solution can be high compared to the generic CGI approach. Also, hybrid Web server/DBMS implementations are largely proprietary solutions. Coming from database vendors, the products, quite logically, are optimized to support Web access for the vendor's own DBMS. All DBMS vendors provide access to competitive databases through their own middleware products, but once again this adds an additional software layer to the mix, with the detriment to overall system performance that layer implies.
DBMS middleware options do not overcome that other major limitation of the hybrid Web server/DBMS approach -- namely application portability. Applications written for Web server/DBMS hybrids, especially those that involve the use of stored procedures, are not easily ported to other database back ends.
Client/server and INet development tools
Building Web-enabled applications using HTML, CGI, ISAPI, NSAPI and 3GLs is a difficult process. A number of tools have been released that reduce much of the burden by generating much of the required HTML, CGI and other code from "higher order" specifications. These products also automate access to database back ends. Both client/server RDA tools, as well as dedicated Web development environments provide such support.
While some tools are more 4GL-like, others are pure 3GL environments, albeit 3GL coding is limited to the specification of business logic. Typical of today's 3GLs tools, database access and GUI code is generated automatically. Both classes of tools generate some combination of CGI, NSAPI or ISAPI code.
|
Fig. 5: Tool-based 'INet execution environments
Development tools' proprietary execution architecture
maintains state and dynamically generates HTML.
Source: SPG Analyst Services
|
|
All dedicated Web development tools and Web-enabled client/server tools are able
to take database query results and merge them into HTML forms which are passed
back to the client. Both classes of tools typically make use of proprietary "gateway"
software to pass parameters to database and application servers, and return results
(or results sets) to the Web server. (See
Fig. 5.)
Gateway software is invoked via CGI, NSAPI, ISAPI or other means. Most tools make use of HTML templates to return database feeds, while others use a combination of templates and dynamically generated HTML.
Maintaining state
Both Web-enabled client/server tools and dedicated Web development tools overcome the Web's stateless nature. Products provide some type of a session management feature that allows the generated applications to track states, something the traditional Web cannot do. As one example, many products make use of a "context" pool. When transactions are begun, the Web server generates a unique process identifier which is maintained with state information on the server in the context pool. Additionally, the process ID (or context ID as it is sometimes known) is embedded in the HTML passed along to the client along with other state information. While state information may change during the course of a session, the process ID remains constant until the session terminates and the ID is discarded or returned to the context pool for reuse.
The combination of process IDs and storage of state information in a context pool, allow the execution environment of development tools to track the states of numerous clients connected to the Web server and allow the user to return to a Web page and view it in the state the user left it. It also insures that a session is active during the user's entire interaction with the application and keeps track of the state of the client's interaction, as well as any transactions that are in progress, making possible rollback and commit operations.
Which tool?
Dedicated Web development environments were designed for Internet (INet) development. As expected, vendors of such tools emphasize the difference between the Web and traditional client/server development, implying that RAD client/server tools may not be the optimal solution for developing for the Internet. However, like the rest of the computing universe, development tools vendors are now running, and releasing tools, in Web time. As a result, many client/server tools are already as capable as dedicated Web tools for building database access applications that can be accessed from common Web browsers. The remaining differences are diminishing daily with each new "point release" of the client/server tools.
High-end client server tools
Currently, most companies have progressed beyond simply "authoring" Web sites. The influx of dedicated Web development environments and the Web enablement of classic client/server tools have made data-driven Web applications all the rage. Yet many of the today's Web-based database access applications are read only, and those that support database writes are not necessarily "critical" systems by any stretch of the imagination. At this time, few serious, transaction-heavy, "critical" businesses on the Internet or corporate Intranets have been built.
There is a world of difference between Web-based database access and Internet transaction processing. Web-based E-commerce applications, as well as Internet/Intranet-enabled critical business process, must support the ACID (Atomicity, Consistency, Isolation and Durability) properties at the transaction level. State management systems within development/ execution environments must be extended to support ACID transactions. Server failover and automatic load balancing is also required functionality, and, of course, high performance is mandatory.
Most of the requirements for integrating mainstream business and E-commerce systems with the Internet are the same as for building high-end, strategic systems in general. However, the unique nature of the Internet/Web can also accentuate the requirements of Internet transactional systems compared to more traditional transaction processing systems. Security comes quickly to mind as does load balancing. For example, with traditional systems the upper limit of the client universe is known and traffic flow is somewhat predictable. With the Web, the number of potential users of a systems is unknown and unlimited. At any given time, the number of potential Web clients can range from zero to "whatever." Automatic load balancing, then, becomes even more important as a requirement for building Internet transaction processing applications than for transaction processing systems in general.
Dedicated Web development environments and Web-enabled client/server RAD tools can interoperate with third-party products to build INet-based critical systems. For example, the "gateway" (as seen in Fig. 5) can call into a third-party transaction monitor. Like the client/server RAD tools, high-end distributed systems development environments have also been Web-enabled over the last year. These products provide soup-to-nuts support for building the largest, most complex distributed systems. These products are important because they were specifically developed to build "core" transactional business systems, and the requirements for Internet enabling this class of application are the same as for building high-end, strategic systems in general.
Web-enabled "strategic" client/server tools provide the basic infrastructure for building critical business systems. All are repository based and most include integrated support for version control, configuration management, testing, performance monitoring and software distribution. Because they were designed for large, complex systems, many have some type of integrated modeling component. All tools in this class support application partitioning for performance enhancement and scalability, and the majority provide automatic support for server failover, access to legacy data and processing, as well as dynamic load balancing.
Distributed applets
Most Internet execution architectures have two features in common. (See Figures 1-5.) First, they support "thin" clients with little application logic running on the browser platform. Second, access to database and application services usually occurs through a Web server proxy. A second general approach supports distributed applets that can execute application logic on client platforms. Sun's Java language is representative of this approach for building applications for the Internet. Java applets built in the Java language can be embedded into the HTML code of a World-Wide Web page. Using Java-capable browsers, applets are dynamically downloaded from the Web server and executed by virtual-machine interpreters running on the client. (See Fig. 6.)
|
Fig. 6: The Distributed Applet Approach
Applets executing on the client can invoke server
processing through Web server proxies or directly.
Source: SPG Analyst Services
|
|
Most Java implementations are currently limited to executing Java applications
on the desktop solely for animating lifeless HTML pages. While to date the primary
focus for Java development has been to make static Web pages more dynamic and
interactive, embedded Java applets can perform any function that can be accomplished
with C++. Vendors of all classes have released products that are Java enabled.
For example, interfaces are available to link Java applets with DBMSs, application
servers and middleware such as object request brokers, RPC mechanisms and message-oriented
middleware. Java applets themselves can also execute on server platforms.
The downloadable applet approach is so flexible that it is difficult to create a diagrammatic representation of the architecture. Like the CGI and Web server interaction models, Java applets downloaded and executing on Web clients can connect to back-end services indirectly through Web server proxies.
Java applets are downloaded from the Web server to the Web client and executed there. (See Fig. 6.) The applet itself can interact with database and application server back ends directly using various types of middleware as the "pipe." (See Fig. 6, step 4a.) Alternatively, Web clients can execute Java applets pulled down from Web servers as Corba-compliant ORBS. These ORBs can connect directly to database or application servers over the Internet Inter-ORB Protocol (IIOP), a protocol that supports inter-ORB messaging over TCP/IP. (See Fig. 6, step 4b.)
Developers have a choice among a variety of Internet/Web execution architectures for building 'Net-enabled systems. Access to database and application servers via CGI and proprietary Web server APIs is the key piece of functionality that differentiates the first generation of document-centric Web systems from follow-on applications. Dedicated Web development tools and Web-enabled client/server RAD tools make the job of building Web applications easier by providing state management functionality and supporting the generation of HTML, CGI and other required code. Web enabled high-end development tools provide the core functionality for building ITP systems that support the ACID (Atomicity, Consistency, Isolation and Durability) properties at the transaction level. Tool level support is also provided for automatic load balancing, sever failover, and partitioning to maximize performance.
Developers also have choices among development tools that target specific
architectures. The follow-on piece to this article will discuss specific IPT
development toolsets and the various execution architectures they support.