The Web Computing Model for Business

Because today's businesses are models of dynamic change—often growing quickly and instituting rapid directional shifts—the Web model is ideally suited for business computing. Web sites can grow exponentially with demand and provide a full range of services that can be tailored to meet user requirements. These services are often very complex and need to be integrated with other services in the organization.

In this section, we'll take a look at the architectural goals and elements of a business Web site, as well as some typical site topologies. For more information about building scalable n-tier sites, refer to the white paper, "A Blueprint for Building Web SitesUsing the Windows DNA Platform," which is in the Appendix.

Architectural Goals

The foundation for an architecture that adequately addresses business computing needs must meet these goals:

• Scalability—Enabling continuous growth to satisfy user demands and respond to business needs by providing near-linear cost effective scaling.
• Availability and reliability—Ensuring that there are continuous services to support business operations by using functional specialization and redundancy.
• Management—Providing management with ease of use and completeness to ensure that operations can keep pace with growth and reduce the total cost of ownership (TCO).
• Security—Ensuring that adequate security is in place to protect the organization's assets, namely its infrastructure and data.

Architectural Elements

The key architectural elements of an n-tier business Web site, illustrated in Figure 1.3, are as follows:

• Clients
• Front-end systems
• Back-end systems

For the site architect and application developer, all of these elements must be considered in the context of scalability and reliability, security, and management operations.

Figure 1.3 Architectural elements of an n-tier business Web site

Figure 1.3 shows the split between the front-end and back-end systems as well as the firewall and network segmentation, which are key security elements in site architectures. Let's examine the elements of this model in more detail, starting with the clients.

Clients

Clients issue service requests to the server hosting the application that the client is accessing. From the user's perspective, the only things visible are a URL that identifies a page on a site, hyperlinks for navigation once the page is retrieved, or forms that require completion. Neither the client nor the user has any idea of the inner workings of the server that satisfies the request.

Front-End Systems

Front-end systems consist of the collections of servers that provide core services, such as HTTP/HTTPS and FTP, to the clients. These servers host the Web pages that are requested and usually all run the same software. For efficiency's sake, it is not uncommon for collections of these servers (Web farms or clusters) to have access to common file shares, business-logic components, or database systems located on the back-end (or middle-tier in more extended models) systems in our model.

Front-end systems are typically described as stateless because they don't store any client information across sessions. If client information needs to persist between sessions, there are several ways to do this. The most common is through the use of cookies. Another technique involves writing client information into the HTTP header string of a Web page to be retrieved by the client. The last method is to store client information on a back-end database server. Because the latter technique can have significant performance implications, but increases reliability in a non-trivial fashion, it should be used judiciously. You'll learn more about state and persistence—concepts that are central to good application design—in later chapters.

Scalability of the front-end systems is achieved by increasing the capacity of an individual server—scaling up or by adding more servers—scaling out. We'll examine availability/scalability issues and options later in this chapter.

Back-End Systems

The back-end systems are the servers hosting the data stores that are used by the front-end systems. In some cases, a back-end server doesn't store data, but accesses it from a data source elsewhere in the corporate network. Data can be stored in flat files, inside other applications, or in database servers such as Microsoft SQL Server. The following table summarizes data and storage areas.

Table 1.2 Different Types of Data Stores

File systems		Databases	Applications
Example	File shares	SQL Server	Ad insertion, Service Advertising Protocol (SAP), Siebel
Data	HTML pages, images, executables, scripts, COM objects	Catalogs, customer information, logs, billing information, price lists	Banner ads, accounting information, inventory/stock information

Because of the data and state they must maintain, the back-end systems are described as "stateful" systems. As such, they present more challenges to scalability and availability. These topics are covered in detail later in this chapter.

Security Infrastructure

Securing the assets of today's businesses, with their mobile workers, business-to-business computer direct connections, and a revolving door to the Internet, is a complex and costly endeavor. The consequences of poorly implemented computer security can, however, spell disaster for a business.

At a high level, security domains—not to be confused with Internet or Microsoft Windows NT/Windows 2000 domains—provide regions of consistent security with well-defined and protected interfaces between them. Large organizations may partition their computing environment into multiple domains, according to business division, geography, or physical network, to name but a few types. Security domains may be nested within one another or even overlap. There are as many security architectures as there are security mechanisms.

At a low level, the basic model for securing a single site involves setting up one or several perimeters to monitor and, if necessary, block incoming or outgoing network traffic. This perimeter defense (firewall) may consist of routers or specialized secure servers. Most organizations use a second firewall system, as shown in Figure 1.4. Security specialists refer to this area between the firewalls as the DMZ (demilitarized zone).

Figure 1.4 Using firewalls to establish a secure zone

Remember, this is only a model; every organization builds their security architecture to meet their own business requirements. Another factor in this decision is the performance cost of providing more protection. Some, in fact, put their Web servers on the Internet side of the firewall, having determined that the risk to, or cost of reconstructing, a defaced or damaged Web server isn't high enough to warrant more protection.

We'll cover security in greater detail later in the book as it applies to the Application Center environment specifically, with its aggregated servers and their applications.

Management Infrastructure

Site management systems are often built on separate networks to ensure high availability and to avoid having a negative impact on the application infrastructure. The core architectural elements of a management system are as follows:

• Management consoles serving as portals that allow administrators to access and manipulate managed servers.
• Management (also called monitoring) servers, which continuously monitor managed servers, receive alarms and notifications, log events and performance data, and serve as the first line of response to pre-determined events.
• Management agents, which are programs that perform management functions within the device on which they reside.

As systems scale or their rate of change accelerates, the management and operation of a business Web site becomes a critical factor, in terms of reliability, availability, scalability, and TCO. Administrative simplicity, ease of configuration, and ongoing health/failure detection and performance monitoring become more important than application features and services.