Lesson 1: Defining a Web Application Strategy

As a result of the Internet, its related technologies, and the adoption of Internet standards, many organizations, particularly larger ones, have a growing need for data access that’s faster and more reliable than the client/server application model provides. Consequently, these organizations have moved toward a distributed application design that divides computing tasks along application tiers, which usually include a presentation layer, a business logic layer, and a data layer. Although this strategy requires more analysis and design at the start, in the end it greatly reduces maintenance costs and increases functional flexibility. In this lesson you’ll be introduced to the distributed application model. From this information you’ll learn how to determine where to place Web components to work within this distributed topology and how to develop an application deployment and synchronization strategy.

After this lesson, you will be able to

• Determine where to place Web components
• Develop an application deployment and synchronization strategy

Estimated lesson time: 30 minutes

Application Integration

In the past, the two-tier model’s ease and flexibility drove the development and deployment of business applications, and it still does for many smaller companies. However, with the advent of the Internet, many organizations have adopted a multitiered architecture for their applications. This distributed design must take into account two considerations: determining where to place the components that support distributed applications and determining how to deploy and synchronize these applications.

Placing Components That Support Distributed Applications

A distributed application divides computer tasks along logical layers so that major pieces of functionality are isolated. In most systems the multitier model is divided into three layers, which are described in Table 9.1.

Table 9.1 Distributed Application Model

Layer	Description
Tier 1 (presentation layer)	The client tier represents the entire user experience. At this layer, the user can input data, view the result of requests, and interact with the underlying system. In a Web environment, a browser acts as the user interface to carry out these functions. In a non-Web environment, a stand-alone, front-end application acts as the user interface.
Tier 2 (business logic layer)	The middle tier encapsulates an organization’s business logic. This layer connects the user at one end and the data at the other end through the use of processing rules that closely mimic everyday business tasks. In a Web application the middle tier might include Active Server Pages (ASP) files and COM objects.
Tier 3 (data layer)	The data tier provides the data store for the application and, subsequently, the client using the application to access that data. The third tier might contain a structured data store such as Microsoft SQL Server, an unstructured data store such as Microsoft Exchange, or a transaction-processing mechanism such as Message Queuing.

Note that application tiers don’t always correspond to the network structure. For example, IIS and ASP might run on a front-end cluster to handle incoming requests, while the COM objects might run on a separate cluster on a separate network. Or they all might run on the same front-end cluster (but still be considered separate application layers).

Figure 9.1 illustrates how application services can be provided through a distributed design.

Figure 9.1 - Three-tier application architecture

Unlike client/server applications, the distributed application is flexible and not limited to one or two computing tiers. A multitiered network structure allows you to scale out your applications through the use of additional tiers, additional computers, additional clusters, or even additional geographic locations. In addition to increasing scalability, the distributed model can increase availability and reliability through the use of redundant services and components.

Application-Specific Technologies

The distributed model relies on application-specific technologies to provide services to the client. Some of these technologies exist on the client tier. For example, client-side scripts run within the browser, using the processing power of the user’s computer. Another example of a technology that runs in the client tier is ActiveX controls, which you can use to customize the user interface or use as plug-in applications (such as the RealNetworks streaming audio/video player).

In addition to client-side technologies, the distributed application also uses middle-tier technologies, which include Common Gateway Interface (CGI) applications, Internet Server Application Programming Interface (ISAPI) extensions and filters, and ASP. Table 9.2 provides a brief description of each of these technologies.

Table 9.2 Middle-Tier Technologies

Technology	Description
CGI applications	A CGI application is an executable program that runs on the Web server. Remote users can launch a CGI application by requesting a Uniform Resource Locator (URL) that contains the name of the CGI application. CGI applications scale poorly on the Microsoft Windows operating system.
ISAPI extensions and filters	An ISAPI extension is a run-time dynamic-link library (DLL). An ISAPI extension performs better than a CGI application, although ISAPI presents some maintenance problems. An ISAPI filter allows you to intercept specific server events before the server itself handles them. As a result, you can create filters to provide such services as customer authentication or automatic redirection. ISAPI filters can cause performance degradation.
ASP	ASP is a scripting environment that allows you to create dynamic content and Web-based applications. Scripts in ASP pages are easier to write and modify than CGI or ISAPI, and you can use ASP to perform the same kinds of tasks. However, when ASP pages are first compiled, they can be much slower than plain Hypertext Markup Language (HTML) and ISAPI, but after the compiled version is cached, subsequent requests are significantly faster.

IIS and Distributed Web Applications

IIS plays a pivotal role in making distributed applications available to the Web client. IIS provides the following core functionality:

• Establishing and maintaining Hypertext Transfer Protocol (HTTP) connections
• Reading HTTP requests and writing HTTP responses
• Modifying HTTP headers
• Obtaining client certificate information
• Managing asynchronous connections
• Mapping URLs to physical paths
• Managing and running applications
• Transmitting files

At the heart of many distributed applications is ASP. ASP extends the basic functionality of IIS by providing a link to the COM architecture. IIS and Component Services work together to provide the following functionality:

• Isolating applications into distinct processes
• Managing communication between COM objects
• Coordinating transaction processing for transaction ASP applications

In IIS, Web application resource files are grouped together into a logical namespace, which allows you to share data throughout the namespace and run the application in an isolated process. When an ASP file is requested, IIS processes the request by using the ASP DLL, which is an ISAPI DLL.

Figure 9.2 illustrates how an ASP request is processed in IIS. The numbered steps shown in the illustration are described below.

When a browser from a client computer requests an ASP page, the following events occur:

1. The client browser sends an HTTP request for the ASP page to the Web server.
2. When IIS sees the .ASP extension on the requested page, the service recognizes the page as a script-mapped file and sends it to the Asp.dll ISAPI extension for processing.
3. The Asp.dll extension compiles and caches the ASP file. The extension processes any include directives before compiling any server-side script.
4. IIS creates the resulting HTML page, which is then sent back to the client.
5. When the client receives the page, it loads any client-side objects, executes client-side script, and displays the Web page according to HTML specification.

Figure 9.2 - An ASP request from IIS

IIS and ASP work together to support the distributed application. IIS essentially coordinates the efforts of the application so that COM objects, and subsequently data from the data store, can be accessed in order to generate a response to the initial request.

Deploying and Synchronizing Application Content

Application deployment refers to the process of moving a set of code from one distributed environment to another. In the case of Web applications, this set of code includes all files, COM objects, scripts, configuration settings, and any other required components that support the application.

Ideally, your deployment process should move through three distributed environments—development, testing/staging, and production, as shown in Figure 9.3. You create content in the development environment and administer it in the production environment. Once in the production environment, you should be able to synchronize changes throughout a cluster to maintain the consistency of the content within that cluster.

Figure 9.3 - The application deployment process

Many tools have been developed to support the deployment of application content. For example, Microsoft Application Center 2000 includes the New Deployment Wizard, which allows you to deploy applications from a source server to a specified target. Tools like the New Deployment Wizard help system administrators maintain a secure, yet usable, buffer between their testing and production environments.

When deploying your applications into a clustered environment, you should consider several factors:

• Whether you want to avoid any downtime
• Whether you use scheduled downtimes for maintenance
• Whether there are times when a live update will have minimal impact on your users

Ideally, if you schedule downtime for maintenance, you should deploy your applications at that time. However, this isn’t realistic for organizations that strive for high availability. If this is the case, you must choose a time that will affect the fewest users.

You should also take into account the type of application that you’re deploying. An application that contains COM+ components requires a different strategy from an application that contains only static content. This section provides an overview of deploying applications with static content and deploying COM+ applications.

Deploying Applications with Static Content

When you deploy an application that consists solely of static Web pages and graphics, you don’t have to reset the Web services because there are no ISAPI filters or COM+ components that require resets. This provides far more flexibility in your deployment strategy than if ISAPI filters or COM+ components are included.

In most cases you can deploy applications that contain only static content by first performing a single deployment from the stager to the Web cluster controller. From there, you can replicate the content to the other members of the cluster. With some administrative applications, such as Application Center 2000, replication occurs automatically as cluster members are synchronized. However, you can disable automatic synchronization on the target cluster and manually synchronize the new application across the cluster after the deployment has finished.

In some cases you might decide that a particular cluster member shouldn’t be serving content at the same time that new content is being replicated to the system because a particular computer has a lower capacity than other members. If so you can take that member out of the load-balancing loop, synchronize the cluster, and then bring that member back online.

Deploying COM+ Applications

When you deploy COM+ applications, Web services are reset on the target computers. As a result, you can’t deploy COM+ applications without affecting the existing client connections, so you should plan your deployment strategy around times that will affect the fewest users.

If you’re deploying your applications to a Web cluster that contains the COM+ components, your strategy should include several fundamental steps:

1. Take the cluster controller and one member of the cluster out of the load- balancing loop.
2. Deploy the applications to those two computers.
3. After the services have been reset, bring the two servers back online for load balancing.
4. Repeat the process for the remaining members.

If you’re deploying your applications to a Web cluster and a separate COM+ application cluster, you should deploy your applications in two phases:

1. Deploy the COM+ objects to the COM+ application cluster.
2. Deploy the rest of the application to the Web cluster.

When you deploy your COM+ objects, you’ll most likely have to deploy the controller and each member of the cluster separately. If you’re using CLB on the Web cluster, you should remove the COM+ controller or member from the routing list as you’re deploying the COM+ objects. Be sure to add the server back to the routing list once you’ve deployed the components. After you’ve deployed the COM+ objects, you can deploy the rest of the applications to the Web cluster by following the same steps used to deploy applications to a Web cluster that contains the COM+ components.

Making a Decision

When integrating distributed applications into your Web environment, you must take into account the placement of components that support those applications and how to deploy application content. Table 9.3 describes the factors that you must consider when planning your distributed applications.

Table 9.3 Integrating Distributed Applications

Strategy	Considerations
Determining where to place the components that support distributed applications	Web applications are distributed across multiple tiers: the presentation layer, the business logic layer, and the data layer. The presentation layer contains the client browser, which acts as a user interface to the application and data. The business logic layer includes the Web services, ASP, files, and objects that support the organization’s business logic. The data layer provides the data store for the application.
Developing an applica- tion deployment and synchronization strategy	A deployment strategy should take into account whether downtimes are scheduled for maintenance or when the fewest users access the system. In addition, deployment strategies are different for applications that contain static content only and COM+ applications.

Recommendations

When determining where to place the components that support distributed applications, you should determine your application requirements and apply those requirements to a distributed environment. For example, all your Web applications will rely on the presentation layer and the business logic layer. At the very least, the client browser (in the presentation layer) will access services by connecting to an IIS computer (in the business logic layer). The business logic layer will contain HTML pages, ASP pages, or both, in addition to other static content, such as graphics. This layer will also contain any of the server-side technologies that support the application. If your application includes access to a data store, you should incorporate a data layer into your design.

When planning a strategy for deploying Web applications into your distributed environment, your first approach should be to deploy your applications during scheduled downtime. If this approach isn’t possible, you should adhere to the following guidelines:

• When you deploy applications with static content, perform a single deployment from the stager to the Web cluster controller. From there, replicate the content to the other members of the cluster.
• When you deploy COM+ applications to a Web cluster that contains the COM+ components, deploy the applications to one or two members at a time, starting with the controller.
• When you deploy COM+ applications to a Web cluster and a separate COM+ application cluster, do it in two phases: deploy the COM+ objects to the COM+ application tier and then deploy the rest of the application to the Web tier.

Example: A Distributed Application for Trey Research

Trey Research is implementing Web-based services to support its customer base. It plans to develop an application that allows clients to access information from a data store. The application will be distributed across a multitiered environment, as described in Table 9.4.

Table 9.4 Trey Research Application

Tier	Description
Presentation layer	At this tier users will access the Web site through a browser. Client-side scripts will be used to validate form inputs.
Business logic layer	This tier will include IIS. ASP will be used to process client requests. ASP will call COM+ objects, which, in turn, will access the data store. The COM+ objects will be stored in the Web cluster.
Data layer	This tier will include SQL Server, which will be used to store data.

Figure 9.4 shows how the components are distributed across the environment to support client requests and application processing.

Figure 9.4 - Trey Research application

Lesson Summary

When you integrate an application into a distributed environment, you must take into account where to place components that support the application and how to deploy and synchronize that application. A distributed application divides computer tasks along logical layers so that major pieces of functionality are isolated. In most systems the multitier model is divided into three layers: the presentation layer, the business logic layer, and the data layer. The distributed model relies on application-specific technologies that exist either on the presentation layer (such as ActiveX controls) or the business logic layer (such as ASP). ASP extends the basic functionality of IIS by providing a link to the COM architecture. IIS and ASP work together to support the distributed application. When deploying your applications into a clustered environment, you should consider whether you want to avoid any downtime, whether you use scheduled downtimes for maintenance, and whether there are times when a live update will have minimal impact on your users. You should also take into account the type of application that you’re deploying. An application that contains COM+ components requires a different deployment strategy from an application that contains only static content.