4.3. Reference Architecture

While the infrastructure describes and characterizes the main components that support an electronic business, a reference architecture covers not only the components, but the way those components are structured and the way they interact with each other. In other words, an infrastructure model provides a static description of resources and services, whereas the architecture includes the dynamics of the system. A reference architecture of a system describes its structure, its components, and their interrelationships. The importance of an architecture is emphasized by the following quotation: "If a project has not achieved a system architecture, including its rationale, the project should not proceed to a full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process" [2]. The architecture of an electronic business system provides a framework for its evolution and for making decisions about the future, such as what technologies to adopt and when to change the system. Thus, the architecture of an electronic business is an essential element in any kind of quantitative study. Figure 4.4 depicts the overall architecture of an electronic business. The architecture is composed of two blocks: one represents the services provided by the site and the other indicates external services that may be required by the business. The Internet connects internal services and third party services. An e-business site is usually structured in layers to improve system functionality, performance, scalability, and reliability.

4.3.1. Components

A component is a modular unit of functionality, accessed through defined interfaces. This section discusses the role of the main components of a typical infrastructure for electronic business.

4.3.1.1. Web Server

As shown in Fig. 4.5, a Web server is a combination of a hardware platform, operating system, networking software, and an HTTP server. Web server software, also known as HTTP server or HTTP daemon, are programs that control the flow of incoming and outgoing data on a computer connected to an intranet or to the Internet. The HyperText Transfer Protocol [19] is an application-level protocol layered on top of TCP used in the communication between clients and servers on the Web. HTTP defines a simple request-response interaction, which can be viewed as a Web transaction. In the original version of the protocol, HTTP 1.0, a new connection is established per request. In the version HTTP 1.1, also called persistent connection, one TCP connection may be used to carry multiple HTTP requests, eliminating the cost of many opens and closes. Basically, Web server software listens for HTTP requests coming from clients over the network. The server program establishes the requested connection between itself and the client, sends the requested file, and returns to its listening function. To speed up the service, HTTP servers handle more than one request at a time. Usually, this is done in three different ways [19]: by forking a copy of the HTTP process for each request, by multithreading the HTTP program, or by spreading the requests among the processes of pool of running processes.

Latency and throughput are the two most important performance metrics for Web servers. The rate at which HTTP requests are serviced represents the connection throughput. It is usually expressed in HTTP operations/sec. Due to the large variability in the size of the requested Web objects, throughput is also measured in terms of megabits per second (Mbps). The time required to complete a request is the latency at the server, which is one component of client response time. The average latency at the server is the average time for handling the requests. Customer response time includes latency at the server plus the time spent communicating over the network plus the processing time on the client machine (e.g., formatting the response).

Thus, customer-perceived performance depends on the server capacity and the network load and bandwidth as well as on the client machine.

4.3.1.2. Application Server

An application server is the software that handles all application operations between browser-based customers and a company's back-end databases. For example, an application server in a travel agency Web site translates search requests for flight scripts that access the back-end database. In general, an application server receives client requests, executes the business logic, and interacts with transaction servers and/or database servers. Usually, application servers exhibit the following characteristics: i) host and process application logic written in different programming languages (e.g., Java, C, or C++), ii) manage high volumes of transactions with back-end databases, iii) are compliant with all existing Web standards, including HTTP, HTML, CGI, NSAPI, ISAPI, and Java, and iv) work with most of the popular Web servers, browsers, and databases.

Application servers can be implemented in many different ways, as shown in Figs. 4.6 and 4.7: as CGI scripts, as FastCGIs, server-applications, and server-side scripts. Figure 4.6(a) shows the CGI approach. In this case, a new process is created to handle each request (see part 2 of the figure). When the request is complete, the process is killed (see part 3 of the figure). The advantage of this approach is that there is complete isolation between the application and the Web server. So, if the application crashes, it will not bring the Web server down. Isolation is also important for security reasons. The drawbacks of using CGI scripts are 1) the overhead involved in creating and killing processes, and 2) the fact that it becomes harder to build persistent applications, i.e., applications that require several interactions with the user. Since the process that implements the CGI script is killed after each interaction, other methods (e.g., cookies) have to be used to pass the application state from one interaction to the next within the same transaction.

To overcome some of the problems of CGI scripts, one can use FastCGI scripts (see Fig. 4.6(b)), which are persistent processes that communicate with the Web server either through TCP or local interprocess communication mechanisms. Fast CGIs provide isolation and persistency as well as better performance than CGI scripts. As shown in Fig. 4.6(b), the FastCGI script is present throughout the entire life of one or more requests. The communication between the Web server and FastCGI scripts usually involves system calls.

The third approach, shown in Fig. 4.6(c), is that of applications that run within the context of the Web server. The application is invoked through APIs (Application Programming Interfaces) provided by the Web server software. Examples include ISAPI for Microsoft's IIS Web server and NSAPI for Netscape's Web server. While this approach provides application persistency and exhibits better performance than any of the other methods, it suffers from poor isolation. If an application fails, it can bring down with it the Web server process. Security is also a problem here due to lack of isolation between the application and the Web server.

The last approach is the use of server-side scripting as shown in Fig. 4.7, which shows the sequence of steps that take place when a request for an HTML page arrives. The page, retrieved from the document tree, contains HTML code and a script written in a scripting language. Microsoft's Active Server Pages (ASPs) allow the use of JavaScript and VBscript with ActiveX controls in a page and Netscape's Livewire allow the use of server-side JavaScript. A script interpreter at the Web server interprets the script and dynamically generates an HTML page that is returned to the browser.

The performance tradeoff between CGIs and server-side scripting is illustrated in the following example.

Example 4.3

A Web server is connected to the Internet through a T1 link. Measurements on the server indicate that it takes 5 msec to process the incoming HTTP request to determine that an application needs to be executed at the server, 20 msec to start and kill a CGI process, 40 msec to execute the CGI script, and 5 msec to reply to the request. The size of an incoming request is 200 bytes and the size of the HTML page returned is 5,000 bytes. How does the Web server throughput vary as a function of the number of concurrent requests in the system for the CGI case and for the case in which the application runs within the Web server context.

The maximum throughput is given by the inverse of the service demand for the bottleneck device (see Chapter 8). In other words, we need to find the device in which a request spends most of its time receiving service. This is the bottleneck. The inverse of the total service time at the bottleneck device is the maximum throughput. The total CPU time, or service demand, for the CGI script case is given by

Equation 4.3.3

The CPU service demand for the case in which the application runs within the Web server does not include the time to start and kill the CGI process. Thus,

Equation 4.3.4

The service demands at the incoming link and outgoing links are, assuming a 40-byte protocol overhead in the incoming link for the HTTP request and 120-byte protocol overhead in the outgoing link for the HTTP reply,

In any of the two cases, CGI or application within the Web server, the CPU is the bottleneck. The maximum throughput for the CGI case is

and the maximum throughput for the non-CGI case is

The overhead incurred by CGI scripts reduces the maximum throughput from 20 to 14.3 requests/sec, a reduction of 28.5%. Figure 4.8 shows the throughput curve for the two cases. This curve was obtained with the models described in Chapters 8 and 9.

A commerce server is a software platform that combines most of the services required by an e-commerce store, such as an online catalog, transaction processing, payment handling, tax and currency offerings, workflow automation, and online ordering. It also has the capability to integrate with database systems and other corporate applications (e.g., inventory). The following metrics are used to evaluate the performance of application servers: throughput, measured in transactions per second (tps) or transactions per minute (tpm), and response time.

4.3.1.3. Transaction and Database Servers

A transaction processing (TP) monitor [1] [7] comprises three major functions: i) an application programming interface, ii) a set of program development tools, and iii) a system to monitor and control the execution of transaction programs. A TP monitor provides a seamless environment that integrates all the components needed to execute transactions: the database system, operating system, and communication system. The growth of e-commerce transactions over the Internet makes TP monitors a key component to guarantee performance, reliability, and scalability.

Like a TP monitor, a database server executes and manages transaction processing applications [1]. It can be a relational database system that supports stored procedures that can issue SQL requests to the database, as shown in Fig. 4.9.

The Transaction Processing Performance Council (TPC) [17] is a nonprofit organization that defines transaction processing and database benchmarks. TPC-C, -H and -R are commonly used industry benchmarks that measure throughput and price/performance of online transaction processing (OLTP) environments and decision support systems [7]. TPC-C measures the maximum sustained system performance. It is defined as the number of New-Order transactions completed per minute while the system is executing four other transaction types (Payment, Order-Status, Delivery, and Stock-Level). The response time of all transactions should be less than five seconds. The TPC-H (ad hoc, decision support) benchmark represents decision support environments where users do not know which queries will be executed against a database system. TPC-R is similar to TPC-H, but users run a standard set of queries against the database.

4.3.1.4. Mainframe and Legacy Systems

Mainframes and legacy systems are important components of electronic business infrastructure. Very large volumes of business data exists on mainframes [16]. Legacy systems with databases (e.g., IBM's IMS and DB2, Oracle, and Sybase) and online transaction applications (e.g., IBM's CICS) have been used by companies for decades and represent a valuable asset for them. Electronic commerce applications make use of legacy data that reside on back-end mainframes. There exists a number of techniques used to help the integration of Web and mainframes, such as wrapping and back-end scripting. Wrapping refers to hiding the existing legacy applications behind an abstraction layer, representing a programming model [14]. Usually, wrapping is done at the same level as the business logic layer, as discussed in Section 4.3.2. Due to their reliability and capacity, mainframes have been also used as Web servers.

4.3.1.5. Proxies and Caches

Proxy servers and caches are techniques used for improving Web performance, scalability, and security. Caching reduces access time by bringing the data as close to its consumers as possible. Thus, caching improves access speed and cuts down on network traffic, as objects (i.e., pages and documents) often get returned from a nearby cache, rather than from far away servers. Caching also reduces the server load and increases availability in the Web, by replicating objects among many servers. Frequently requested objects are stored at sites close to users, in terms of connectivity. Although caching is a proven technology for static objects (e.g., HTML pages), its use for dynamic objects is still restricted. Dynamic pages, generated by cgi-bin scripts, are a very common approach for implementing e-commerce services.

A proxy server is a special type of Web server. It is able to act as both a server and a client. A proxy acts as an agent, representing the server to the client and the client to the server. A proxy accepts requests from clients and forwards them to Web servers. Once a proxy receives responses from remote servers, it passes them to the clients. Originally, proxies were designed to provide access to the Web for users on private networks, who could only access the Internet through a firewall.

Caching has a widespread use in the Web. Basically, it has been used in three ways. On the client-side, browsers maintain small caches of previously-viewed pages on the user's local disk. The second form of use is in the network (i.e., ISPs and backbone providers), where a caching proxy, also known as network caching, is located on a machine on the path from multiple clients to multiple servers. Caching proxy servers can be located near a large community of users, such as on campus or at an intranet server of a company. A different type of proxy is called reverse proxy, which is located side-by-side with the servers of a website. Although for browsers and other proxies, the reverse proxy acts as a final server, its main function is to distribute the load among the back-end servers of the site.

Caching effectiveness can be measured by three quantities. Hit ratio is defined as the number of requests satisfied by the cache over the total number of requests. Because of the high variability of Web object sizes, it is important to have a metric that includes the size of the object (e.g., HTML document, an MP3 file, and a video file). The byte hit ratio is equal to the hit ratio weighted by the object size. The third metric, called data transferred, represents the total number of bytes transferred between the cache and the outside world during an observation period. The following example illustrates the use of these metrics.

Example 4.4

The website of an e-retailer receives 3,200,000 requests per month. To postpone a new T1 link to the ISP. the manager of the site is considering using a caching proxy that is available on the ISP. Because caching is useful mainly for static pages, the manager wants to know, a priori, the benefit of a caching proxy for an e-commerce site.

By analyzing the Web server logs, the performance analyst found the following statistics: 65% of the total requests are for GIF files and the rest of the requests are dynamically generated HTML pages. The average size of a GIF file is 7,300 bytes and the HTML pages are 13,500 bytes. If the caching proxy is used to hold GIF pages, what are the cache performance metrics?

The estimated hit ratio is 65%, assuming that the cache stores the GIFs for a long period of time. The saved bandwidth from the e-store site to the ISP is calculated as follows:

These results show how caching proxies can contribute to save bandwidth.

4.3.1.6. Internet Service Provider (ISP)

Internet service providers (ISPs) have an important contribution to the quality of service offered by electronic business. Physically, customers and merchants connect to an ISP, which in turn connects to one or more backbone network providers. Depending on the ISP installed capacity and traffic, performance problems and delays may occur at that point of the path between customers and business, contributing to an increase in response times.