Tài liệu Module 5: Managing the Business Logic Layer pptx

Contents
Overview 1
Implementing State in a Shopping Cart 2
State vs. Scalability 15
Membership and Authentication 24
Adapting the User’s View of the Site 31
Commerce Server 2000 Personalization
Tools 36
Lab 5: Using Business Desk 44
Review 55

Module 5: Managing the
Business Logic Layer

Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any

license to these patents, trademarks, copyrights, or other intellectual property.

 2001 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveX, BizTalk Server, FoxPro, FrontPage, Hotmail, Jscript,
Outlook, PowerPoint, Visio, Visual Basic, Visual C#, Visual C++, Visual Studio, Windows, and
Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the
U.S.A. and/or other countries.

Other product and company names mentioned herein may be the trademarks of their respective
owners.


Module 5: Managing the Business Logic Layer iii


Instructor Notes

This module examines the problem of maintaining state in an e-business
application. It focuses on several approaches that can be used for saving useful
information between each request and response cycle. Where appropriate, this
module also covers some of the useful features of Microsoft
®
Commerce
Server 2000, including the Commerce Server Business Desk.
After completing this module, students will be able to:

Describe how to manage state for a Web shopping cart.

List some of the issues related to state and scalability and explain how they

can be addressed.

Identify the role of Microsoft

Application Center 2000 in software scaling.

List the mechanisms that can be used for identifying the users of an
e-business Web site.

Explain how personalization and customization can be used to improve the
usability of a site.

Explain how to use the tools in Commerce Server 2000 to implement
targeted campaigns, promotions, and cross selling in your e-business.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach
this module.
Required Materials
To teach this module, you need the following materials:

Microsoft PowerPoint
®
file 2260A_05.ppt

Module 5, “Managing the Business Logic Layer”

Lab 5, “Using Business Desk”

Preparation Tasks

To prepare for this module, you should:

Read all of the materials for this module.

Complete the lab.

Become familiar with Business Desk.

Read about Microsoft’s latest Customer Relationship Management (CRM)
initiatives at

Presentation:
100 Minutes

Lab:
70 Minutes
iv Module 5: Managing the Business Logic Layer

Module Strategy
Use the following strategy to present this module:

Implementing State in a Shopping Cart
Ensure that students understand what is meant by state before describing the
problem in maintaining state with Hypertext Transfer Protocol (HTTP).
After explaining the issues with HTTP, describe the techniques available to
a Web developer when implementing state on an e-business site. Ensure that
students understand the connection between state and shopping carts. Try
not to delve too far into personalization because it is also covered in the next
section.


State vs. Scalability
Discuss the problems with scalability in the context of coping with state
management. Although some of these problems have been covered earlier in
this module, this will provide an opportunity to introduce some best
programming techniques that can be used to resolve some of these issues.
Conclude this section with a discussion on how to support software
scalability using Application Center 2000.

Membership and Authentication
Point out the differences between state management and membership. Some
advantages of implementing membership are covered in this section.
However, you can also introduce your own examples to emphasize what
membership can offer users.

Adapting the User’s View of the Site
This builds directly on the concept of membership. CRM is covered in one
of the topics. Focus on the business needs of customers rather than on the
technical implementation of CRM.

Commerce Server 2000 Personalization Tools
Commerce Server 2000 is extensive in scope and it will not be possible to
discuss all of its features in this section. Tell the students that only a few of
the components—Business Desk, Profiling system, Business Analytics
system, and Targeting system—are discussed in this section. The discussion
must be limited to how these tools help a developer to build relationships
with clients by using powerful tools.

Lab 5: Using Business Desk
Students will implement state management in an e-commerce application by
using Commerce Server 2000. The Commerce Server 2000 Retail Solution

Site will be used in the lab. The students will implement promotions and
cross selling by using the tools supplied with Business Desk.

Module 5: Managing the Business Logic Layer 1


Overview

Implementing State in a Shopping Cart

State vs. Scalability

Membership and Authentication

Adapting the User’s View of the Site

Commerce Server 2000 Personalization Tools

*****************************I
LLEGAL FOR
N
ON
-T
RAINER
U
SE
*****************************
In this module, you will examine the issues involved in maintaining state in an
e-business application. The module describes how state is important to a Web
shopping cart and then explains the techniques that can be used to preserve

state. It also discusses how state impacts scalability and how to optimize state
and scalability in your application. At the end of this module, you will look at
how state maintenance enables personalization of a site and how to use
Microsoft
®
Commerce Server 2000 to implement personalization in your
e-business site.
After completing this module, you will be able to:

Describe how to manage state for a Web shopping cart.

List some of the issues related to state and scalability and explain how they
can be addressed.

Identify the role of Microsoft

Application Center 2000 in software scaling.

List the mechanisms that can be used for identifying the users of an
e-business site.

Explain how personalization and customization can be used to improve the
usability of a site.

Explain how to use the tools in Commerce Server 2000 to implement
targeted campaigns, promotions, and cross selling in your e-business.

Topic Objective
To provide an overview of
the module topics and

objectives.
Lead-in
In this module, you will
examine the issues involved
in maintaining state in an
e-business application.
2 Module 5: Managing the Business Logic Layer





Implementing State in a Shopping Cart

HTTP: A Stateless Protocol

Storing State on the Tiers

Identifying Users with Cookies

Managing State with ASP.NET Sessions

Session and Shopping Cart

*****************************I
LLEGAL FOR
N
ON
-T
RAINER

U
SE
*****************************
The shopping cart is a fundamental requirement of an e-commerce site. The
shopper needs to be able to add products to a virtual cart, review the cart,
remove items from the cart, and ultimately proceed to the checkout where they
pay for the goods.
Although the operation of a shopping cart appears straightforward, maintaining
state is a challenge that needs to be overcome before the shopping cart will
work successfully. Some of the issues that can arise as a result of bad state
management may not become obvious until some time after the site has been
running.
Topic Objective
To introduce the topics
covered in this section.
Lead-in
The shopping cart is a
fundamental requirement of
an e-commerce site.
Module 5: Managing the Business Logic Layer 3


HTTP: A Stateless Protocol

State: Information or data that affects the behavior of
an application

HTTP is a stateless protocol because the HTTP
connection breaks after each response/request cycle
Web browser

(Internet Explorer)
Web server
(IIS)
1. TCP/IP connection
2. HTTP request
3. HTTP response
4. Connection closed

*****************************I
LLEGAL FOR
N
ON
-T
RAINER
U
SE
*****************************
Maintaining state is an important functionality of any Web application,
particularly in e-commerce applications.
What Is State?
State is any information or data that affects the behavior of a Web application.
For example, if a user browses an e-commerce site and clicks a button to
indicate a preference for monetary currency, the site can be designed to reflect
that preference every time a price is displayed.
Information that constitutes state may be applicable to the user’s current visit
only. However, if such information can be retained for subsequent visits, it will
significantly enhance the user’s experience.
State and HTTP
It is important to understand why maintaining state on an e-commerce site can
be a problem. State-maintenance problems are caused by the use of Hypertext

Transfer Protocol (HTTP), the protocol that delivers information over the Web.
HTTP is used to transmit requests between Web browsers (clients) and Web
servers.
How HTTP works
HTTP is a Transmission Control Protocol/Internet Protocol (TCP/IP)
application layer protocol that is responsible for the communication that takes
place between browser and server and for the delivery of content to the Web
browser. The data that HTTP delivers in response to a successful Web request
is often written in Hypertext Markup Language (HTML).
HTTP is responsible for establishing the connection between the client and
server and establishing the syntax of the request and response cycle. As soon as
the request for a resource has been received and serviced at the Web server,
HTTP breaks the connection. This behavior is by design, and breaking the
connection allows HTTP to scale and support many clients on a single server.
Topic Objective
To describe how HTTP
works and how it impacts
state management.
Lead-in
Maintaining state is an
important functionality of
any Web application,
particularly in e-commerce
applications.
4 Module 5: Managing the Business Logic Layer

Typical Web browsing activity involves a user requesting a page, reading it,
and then clicking a link to another page. Users are just as likely to request a
page residing on a completely different server as they are to request another
page that resides on the current server. Therefore, all connections are broken

after a request has been serviced.
This lack of continuity between individual requests in HTTP means that there is
no awareness on the part of HTTP of an ongoing session. The lack of
permanent connection between the Web browser and the Web server leads to
the problem of maintaining state between successive pages that are accessed by
the same user. HTTP is, in effect, a stateless protocol.
Need for preservation of state
Implementing HTTP as a stateless protocol is ideal for many simple Web sites,
thereby offering the advantage of scalability mentioned above. However, more
comprehensive Web applications will require state to be preserved. The lack of
state preservation means that each request for a Web page is treated as a unique
transaction. HTTP does not remember or consider earlier requests from the
same client/user. Without preservation of state, there is no sense of history,
even a history that is only a few minutes old. You need to use extra mechanisms
to offer a user the ability to put products in a Web shopping cart and see those
same products again in subsequent page requests.

HTTP version 1.1 does contain the concept of an ongoing session
between client and server in which the connection is not broken after each
HTTP request. However, dedicating network resources to a client in this way
can impact site scalability. The issues related to sessions and scalability are
discussed later in this module.

Note
Module 5: Managing the Business Logic Layer 5


Storing State on the Tiers

State on the Client


Reduces server load

State on the Web server

Need not rely on the client’s ability to store state

State by Using the Shared Property Manager

COM+ feature for sharing state across multiple objects

State in a Database

Persistent storage

Sharing state across multiple Web servers is useful in
load-balancing scenarios

*****************************I
LLEGAL FOR
N
ON
-T
RAINER
U
SE
*****************************
A Web application can store state in various places. The location you choose
will depend on the type of application and the length of time for which state
needs to be stored.

Storing State on the Client
Storing state on the client reduces server load, but it requires the client to be
capable of storing state. Storing state on the client also may require the user to
explicitly accept storage of state data, for example, by agreeing to accept a
cookie or by agreeing to download and install custom software. In practical
terms, this method allows the user to disconnect from the site and yet recover
the state of the site when reconnected. Cookies are described in detail in the
following section.
Storing State on the Web Server
By storing state on the server, you do not have to rely on the client’s ability or
willingness to store state data in order to maintain state. A simple
implementation of state management might make use of the ASP.NET Session
object. This object enables the server to identify the client and maintain state on
the server.

ASP.NET introduces several improvements to the implementation of
session management. These will be discussed later in this section.

Storing State by Using the Shared Property Manager
COM+ provides the Shared Property Manager, which makes sharing state in a
multi-user environment as easy as it is in a single-user environment.
The Shared Property Manager provides a mechanism to share and access global
information among server processes. You can use the Shared Property Manager
for a range of tasks, including workflow, performance monitoring and
management, and process serialization through global locks.
Topic Objective
To describe the possible
locations for storing state.
Lead-in
A Web application can store

state in various locations.
Note
6 Module 5: Managing the Business Logic Layer

The Shared Property Manager eliminates the housekeeping tasks, which are
needed to share information among applications. The Shared Property Manager
takes care of memory management, thereby freeing developers to concentrate
on program logic.

To use the Shared Property Manager to store and share state between
different objects and applications, the objects must be running in the same
server process as the Shared Property Manager.

Storing State in a Database
State data that is already stored on a Web server can be also stored on a
database. This enables the server to retrieve a client’s current state from the
database. Having a central storage point for state, such as a database, allows
multiple Web servers to share state data, thereby removing the affinity between
a particular user and a single server in a multiple Web server scenario. The
ability to store state data in this manner in the back end (that is, in a database) is
very important for implementing load-balancing solutions.
However, there are also disadvantages to storing state in the back end. The
disadvantages are:

The database resources required in storing state information

The computing cost that is incurred by frequently moving data from the
client to the database

Note

Module 5: Managing the Business Logic Layer 7


Identifying Users with Cookies

Cookie is a name-value pair that is stored on the client

Issues with using cookies include:

Maintaining privacy of user data

Maintaining users’ personalization configurations
individually

Other methods for identifying users include:

Dynamically rewriting the URLs in pages

Adding hidden fields to forms
<a href="purchase.aspx?shopid=<%=request("shopid")%>">
Click to purchase</a>
<a href="purchase.aspx?shopid=<%=request("shopid")%>">
Click to purchase</a>
<input type="hidden" name="shopid" value="<%=request("shopid")%>">
<input type="hidden" name="shopid" value="<%=request("shopid")%>">
(View mod5ex1.asp and mod5ex2.asp from Sampapps)
(View mod5ex3.asp and mod5ex4.asp from Sampapps)

*****************************I
LLEGAL FOR

N
ON
-T
RAINER
U
SE
*****************************
As discussed in the previous topic, cookies can be used to store state on the
client side.
Cookies can also be used as part of the overall solution when state is being
stored on the server. A prerequisite for maintaining state on the server is the
ability to identify users. Cookies provide a very simple mechanism for enabling
user identification.
Using Cookies to Identify Users
In Web terminology, a cookie is a name-value pair that is stored on the client.
The value of a cookie is simply a text string. When a user visits a Web site, the
server can send down one or more cookies as part of the HTTP response header.
The browser stores the cookies in a cache or file. The cookies are then sent to
the server when the user requests subsequent pages from the same domain.
Technically it is possible for a cookie to contain all of the information about an
ongoing transaction, such as products in the shopping cart, the user’s name and
address, and even credit card details. Storing all information in cookies is a very
insecure practice and is discouraged. Most e-commerce sites will store a unique
identifier in the cookie and keep all of the shopping cart details on the server.
Issues with using cookies
You must be aware of the following issues involved with using cookies:

Maintaining privacy of user data
Cookies are very easy to impersonate and are not always stored securely on
the client’s computer—an issue of particular concern on computers shared

by several users. For this reason, any information stored as a cookie must be
restricted. For example, although it may be acceptable to retrieve the
contents of a shopping cart by sending a cookie to a Web application, it
should not be possible to use a cookie to retrieve a shopper’s credit card
details from an earlier purchase.
Topic Objective
To describe how cookies
can be used in identifying
users.
Lead-in
Cookies can be used to
store information on the
client or to identify the user.
8 Module 5: Managing the Business Logic Layer


Maintaining users' personalization configurations individually
As discussed later in this module, cookies can also be used to provide
personalization features, such as personal home pages on a site. In certain
environments, multiple users may share the same computer, browser, and
cookie cache. In this case, you do not want one user to inherit the personal
preferences of another.

Some users disable cookies in their browsers because they are concerned about
these issues. Therefore, you cannot rely on cookies as the basis for maintaining
user or session state.
Identifying Users through Other Techniques
There are some common alternatives to cookies.
Dynamically rewriting the URLs in a page that is sent to the browser
By dynamically rewriting the Active Server Pages (ASP) on a site, you can

append extra parameters at the end of each Uniform Resource Locator (URL).
One of these parameters could be used to identify a shopper. When a user
requests a page, the site can retrieve the parameter that you have designated as
the shopper identifier and can dynamically append it to every subsequent link
on the page. This technique can be used to identify a user on every page
accessed on the site.
Let us look at how you can implement this concept. First examine the following
URL:
http://localhost/shoppingcart.asp?shopid=12432354
The shopid parameter that has been included in the preceding URL is used for
identifying a particular shopper. Before a link is built on the shoppingcart.asp
page, the shopid parameter can be requested from the URL and included in the
hyperlinks. Links on the shoppingcart.asp page will look similar to the
following:
<a href="purchase.aspx?shopid=<%=request("shopid")%>">
Click to purchase</a>

Adding hidden fields to the forms in which the user is entering data
Many sessions involve users providing information about themselves and their
desired purchases in a form. When forms are being used, hidden fields can
contain session-tracking data. Every time users submit a form, they also submit
a hidden field that is used by the server to identify them. An example of a
hidden field that would be included within the FORM tags is as follows:
<input type="hidden" name="shopid"
value="<%=request("shopid")%>">

Delivery Tip
Open the files
mod5ex1.asp and
mod5ex2.asp in the

\InetPub\WWWRoot\2260\
Sampapps folder. These
files pass information in the
URL that identifies the
shopper.
Delivery Tip
Open the files mod5ex3.asp
and mod5ex4.asp in the
\InetPub\WWWRoot\2260\
Sampapps folder. These
files pass information in the
FORM tag that identifies a
hopper.
Module 5: Managing the Business Logic Layer 9


Problems with using these techniques
Although these techniques are suitable for session tracking, unlike a cookie, the
information will not persist over multiple visits. On closing the browser, the
session state data will be destroyed. On a subsequent visit, a new session
identifier needs to be created. These techniques are not useful for a site that
seeks to implement personalization because the information that is gathered to
implement a personalized Web site is gathered over multiple visits. To benefit
from these techniques and to implement personalization, the users would be
required to log on to the site and have their session details retrieved from a
database before passing them from page to page in a URL or passing them
through a hidden field on a form.
10 Module 5: Managing the Business Logic Layer

Managing State with ASP.NET Sessions


Enhanced Session Object with Built-In State
Functionality

Automatically manages requests from a single client into
a session on the server

Raises appropriate session lifetime management events

Automatically releases session information

ASP.NET Session Characteristics

Session State Storage

Sessions can trigger events in global.asax
<script language="VB" runat="server">
Public sub Session_OnStart()
Session("FavColor")= "Blue"
End Sub
</script>
<script language="VB" runat="server">
Public sub Session_OnStart()
Session("FavColor")= "Blue"
End Sub
</script>

*****************************I
LLEGAL FOR
N

ON
-T
RAINER
U
SE
*****************************
ASP.NET ships with an enhanced Session object containing built-in session
state functionality that provides you with an easy, robust, and scalable way to
implement state management. Sessions are created in the server-side code in an
ASP.NET page. By using session state, a shopping cart can easily be
maintained on the server.
ASP.NET sessions also offer the following advantages:

Automatically identify and classify requests from a single client browser
into a session on the server.
If ASP.NET session support has been configured, each time a user accesses
the application, ASP.NET identifies that the connection is new and
automatically configures a session that can be used to store shopping cart
items.

Raise appropriate session lifetime management events (Session_OnStart
and Session_OnEnd) that can be handled in an application code.
ASP.NET supports a global.asax file, which is similar to the global.asa file
in ASP. This file can contain code that is run when a new session is started
and when an existing session ends.

Automatically release session information if the browser does not revisit an
application after a specified time-out period.
By default, the session time-out value is 20 minutes. This time-out value can
be increased by editing the config.web file.

Topic Objective
To describe the advantages
and characteristics of
ASP.NET sessions.
Lead-in
ASP.NET provides an
enhanced Session object
that can be used to store
state on the server.
Module 5: Managing the Business Logic Layer 11


ASP.NET Session Characteristics
ASP.NET offers a session state facility that is familiar to ASP developers, while
offering the following improvements:

A reliable session that can be run in its own process space and is capable of
surviving Internet Information Services (IIS) failures.
ASP.NET session state is, by default, stored externally from the worker
process in a dedicated Microsoft .NET state server process. End-user code
cannot be run in the state server process, thereby reducing the chances of
faulty code crashing the service. In the event of a failure or system restart of
IIS, state for a user is preserved.

A scalable session state facility that can be used in both Web farm (multi-
computer) and Web garden (multi-processor) scenarios.
Because the ASP.NET session is stored externally from the worker process,
the state data can be accessed by another worker process. These worker
processes could be running on another processor on the same computer or

could potentially be running on an entirely different computer.

A session state facility that works with browsers that do not support the use
of HTTP cookies for privacy or legal reasons.
ASP.NET supports embedding a user identifier in a URL. This allows the
session Identifier (ID) to be automatically retrieved by IIS prior to invoking
the Session object. An example of an URL with an embedded session ID is
as follows:
http://localhost/litware/SESSION$0123456789ABCDEF/page1.aspx
In the above URL, the session ID has been embedded between the forward
slash following the application name (LitWare) and the forward slash
immediately before the filename (page1.aspx).

Session State Storage
Session state can be stored external to the ASP.NET process. Session state is
stored, by default, in an object called the Session State Store. The process that
manages this object is called the state server process. It is this reliable process
that can persist session state even if the ASP.NET process fails.
Alternatively, the contents of the ASP.NET Session object can be written to a
table in a Microsoft SQL Server
™
database. This feature provides another layer
of protection to the contents of the ASP.NET Session object—specifically
guarding against a complete computer failure, such as the case of a complete
power outage on the Web server. In this case, the contents of the ASP.NET
Session object can be reloaded after the computer has recovered from the
failure.
12 Module 5: Managing the Business Logic Layer

Creating an ASP.NET Session

A new ASP.NET session is created each time a user without a session interacts
with an .aspx page in a Web application. The session can trigger events in the
global.asax file. The following code creates a session-scoped variable with a
particular value in the global.asax file:
<script language="VB" runat="server">
Public sub Session_OnStart()
Session("FavColor")= "Blue"
End Sub
</script>

This can be retrieved on .aspx pages as shown in the following example code:
<HTML>
<Body>
Your favorite color is <%=session("favcolor")%>
</Body>
</HTML>

Global.asax
Favcolor.aspx
Module 5: Managing the Business Logic Layer 13


Session and Shopping Cart

Preserving shopping cart contents and state
information

Contents of the cart

A unique product identifier—SKU or ISBN number


The number of items required

The unit cost

A user-friendly description of the product

Save cart contents in a database to avoid losing
information because of Session objects time-outs

*****************************I
LLEGAL FOR
N
ON
-T
RAINER
U
SE
*****************************
After a session is created between the browser and server, you need to
determine exactly what information you want to maintain and store as part of
the user’s session. In an e-commerce store, there is a clear relationship between
state and a user's shopping cart. Along with the products that users put in their
carts, you may want to keep additional state information, such as the preferred
monetary currency of a user.
Contents of the Cart
The information contained in a shopping cart is specific to the application that
uses the cart. However, it generally consists of multiple items, each of which
consists of one or more of the following:


A unique product identifier, for example, a Stock Keeping Unit (SKU) or an
International Standard Book Number (ISBN)

The number of items required

The unit cost

A user-friendly description of the product

You must decide what information must be stored in the cart and what
information must be left in the database until it is needed. For example, you
must decide whether to hold the unit price of an item in the cart or retrieve this
directly from the database when the user proceeds to the checkout.
Also, a decision needs to be made on whether to write the cart information to a
database and, if so, how long it must be kept in the database. Also, the Session
object will time out if it is not used in a specified period; by default this period
is set to 20 minutes. Therefore, writing cart information to a database is a
common practice. In fact, the ASP.NET Session object provides a built in
mechanism for storing session data in a SQL Server database.
Topic Objective
To explain the relationship
between a session and a
Web site shopping cart.
Lead-in
We will now look at the
relationship between a
session and a shopping
cart.
14 Module 5: Managing the Business Logic Layer

Unfortunately, the session ID is unique only among all the current sessions. It is
not a globally unique identifier. This means that if the cart information is stored
in the database for a long period of time, it is possible that at a later time,
another shopper will receive the same session ID and retrieve a partially filled
cart in error.
Module 5: Managing the Business Logic Layer 15






State vs. Scalability

How State Impacts Scalability

Resource Recycling

Software Scaling

Using Application Center 2000

*****************************I
LLEGAL FOR
N
ON
-T
RAINER
U
SE

*****************************
So far, you have seen how state can be maintained by using several techniques.
However, state maintenance can sometimes lead to scalability issues. Let us
examine how a balance can be achieved between state and scalability.
Topic Objective
To introduce the topics in
this section.
Lead-in
So far, you have seen how
state can be maintained by
using several techniques.
However, state maintenance
can sometimes lead to
scalability issues. Let’s
examine how a balance can
be achieved between state
and scalability.
16 Module 5: Managing the Business Logic Layer

How State Impacts Scalability

Limitations of Increasing Resources

Session and state management use valuable server-
side resources

These resources are idle most of the time

Holding Server-Side Resources Results in Scalability
Problems


The Stateless Paradigm
1.
Acquire the required resources
2.
Use the resources to complete the task
3.
Release the resource as quickly as possible

*****************************I
LLEGAL FOR
N
ON
-T
RAINER
U
SE
*****************************
E-commerce applications must be able to scale appropriately when faced with
increased user demand. Holding state (or maintaining a session) for a user of a
Web application consumes valuable server-side resources. This approach can
cause scalability problems because additional users can quickly outnumber
limited resources.
Limitations of Increasing Resources
The server-side component of a user's session—for example, an ASP.NET-
based Web application—must use system resources to accomplish tasks for the
user. The resources acquired by a user's session form part of that user's state.
Although it is true that you can increase the number of users that the site can
simultaneously process by adding more resources, this is not always practical or
beneficial. Most of the resources dedicated to a user remain idle for most of the

time. Typically, both the time taken by the user to decide on their next action
and the communication time between client and server far outweigh the time
spent using the server resources. To service more clients without increasing
resources, your existing resources must be shared very efficiently.
The Stateless Paradigm
As we have seen, because HTTP is a stateless protocol, it does not maintain an
open connection between page accesses, which makes it ideal for scalability.
Each Web site has a maximum number of network resources. For example,
there are a limited number of TCP/IP sockets and they can be used by only one
client at a time. By using these resources for only as long as they are needed,
HTTP makes these resources immediately available to other users. However,
you must use cookies or dynamic URL rewriting to create virtual sessions.
Topic Objective
To explain the problems of
maintaining state in a
solution that needs to be
scaled and how to address
these problems at a higher
level.
Lead-in
We will closely examine the
issues in an e-business
solution when it needs to
continually scale.
Module 5: Managing the Business Logic Layer 17


While the mechanisms used to create virtual sessions solve the problem at the
network level, there are other resources that may be constrained on the server,
including:


Memory

Database connections

Onward connections to other servers

Such resources are acquired by the user's session on the server as the user
performs certain tasks. If the server leaves the user's session open for a
relatively long time, all of the resources it continues to consume are denied to
other sessions and users. Taking into account the stateless paradigm, every
individual task performed on behalf of a user must:
1. Acquire the resources it needs.
2. Use the resources to complete the task.
3. Release the resources as quickly as possible.

The above sequence is similar to how HTTP uses the underlying socket when
transporting a Web page. Recycling of resources is key to creating scalable
solutions.
18 Module 5: Managing the Business Logic Layer

Resource Recycling

In an infinite resources scenario, a resource can be held
on to for as long as it is needed

In a single resource scenario, the application must
follow the acquire-late-and-release-early principle

In a real-world scenario, apply the acquire-late-and-

release-early principle wisely

If reconstructing state is very time consuming, this can
lead to poor performance of the application

*****************************I
LLEGAL FOR
N
ON
-T
RAINER
U
SE
*****************************
Resource recycling is one of the most important strategies that you can adopt to
improve site scalability. For example, consider a typical application that uses
connections to a database. Database connections are typical resources that are
limited in a Web application. In this example, assume that each client session
requires a single database connection.
To understand how resource recycling can improve scalability, we will compare
the following two scenarios:

Infinite resources are available to your application

A single resource is available to your application

Infinite Resources Scenario
Let us examine a case in which you have an unlimited number of database
connections available to your application. Every client that accesses the
application is assigned its own database connection, and no client is ever denied

access because of a lack of resources. The client can hold on to that resource for
as long as it wants to because any new clients can be assigned another
connection from the infinite resource pool.
A Single Resource Scenario
Next, let us examine a case in which your site has only a single database
connection that must be shared between all clients. In such a situation, there is a
real danger that clients will be denied access if that resource is being used by
someone else. Because of this, it is vital that each client uses the resource for as
short a time as possible. Reducing this use time reduces the possibility that the
resource will be in use when another client requests it.
Topic Objective
To introduce the extremes
of resource management
and then look at a real-world
solution.
Lead-in
A site can be scaled easily if
resource recycling is
adopted.
Module 5: Managing the Business Logic Layer 19


Acquire late and release early
To understand how a site can be designed so that a resource is used for the
shortest time possible and as little as necessary, let us examine the exact points
in time that a resource is allocated and released. Many developers write code
such that all the needed resources are acquired at the start of a program or
method. These resources are retained until the program or method ends.
However, if there are only two short sections of code that use the resource in
the overall program or method, it makes sense to acquire the resource at the

latest possible point in time (that is, immediately before possessing the resource
becomes absolutely necessary). Similarly, after you no longer have an
immediate need for a resource, release it at once so that it can be ready for use
by another client.
Scalability vs. efficiency
The acquire-late-release-early strategy may appear to some developers to be
inefficient. However, the key issue here is not efficiency but scalability, and
scalability relies on rapid resource recycling. Also, remember that the use of
connection pools will reduce the overhead of acquiring a connection, so this
strategy is not as inefficient as it may at first appear. It is precisely the acquire-
late-release-early strategy that COM+ applies to achieve component scalability
through Just-In-Time (JIT) activation and As-Soon-As-Possible (ASAP)
destruction.
The Real-World Scenario
In the real-world scenario, of course, you will have neither a single resource nor
infinite resources. However, applying the lessons of how to maximize usage of
a single resource will help you achieve optimum scalability. Also, remember
that in the real-world scenario, scalability may be just one of many
nonfunctional requirements of your application.

If it takes a long time to prepare the state data that you need to acquire for
performing a particular task, the performance drawbacks of continually
discarding and reacquiring state may be prohibitive. The acquire-late-release-
early principle must not be applied to such cases.

Tip
20 Module 5: Managing the Business Logic Layer

Software Scaling


Benefits

Increased capacity

High availability

Drawbacks

Labor intensive

Complex

Lack of cluster monitoring tools

*****************************I
LLEGAL FOR
N
ON
-T
RAINER
U
SE
*****************************
A scalable Web application requires developers to have a good understanding
of how their design will impact the site’s ability to scale. Resource recycling is
a good example of a best practice that a developer must be aware of.
Application Center 2000, which is part of the Microsoft .NET Enterprise Server
family, provides a powerful tool for scaling Web applications. Many Web
applications implement software scaling—adding additional servers to the
overall solution and building a Web farm. Software scaling introduces several

benefits. However, it also introduces a number of issues that Application
Center 2000 will help you to resolve.
Benefits
The two key benefits of software scaling are:

Increased capacity
Software scaling allows companies to increase capacity by:
• Replicating the existing application onto a new server.
• Adding the server to an existing cluster of Web servers.
• Updating the load-balancing solution to make use of this new server.


High availability
Because each server is running identical applications, individual servers can
fail without interrupting the users of the application. An intelligent load-
balancing solution can redirect requests to the remaining servers in the
cluster.

Topic Objective
To introduce the benefits
and drawbacks in scaling
applications.
Lead-in
Adding servers to a Web
application is known as
software scaling. Although
very popular, there are
some drawbacks to this
approach.
Module 5: Managing the Business Logic Layer 21

Drawbacks
Some of the drawbacks in software scaling are:

Synchronizing applications is labor intensive.
Manually moving applications from one server to another can prove labor
intensive. This is compounded by subsequent updates requiring distribution
to all servers that are participating in the cluster.

Predicting required resources for peak loads is difficult.
Software scaling answers the question of how to scale. However, an
important issue that remains is the degree of scalability that is required.
Seasonal peaks are common in e-business stores. The store must be able to
cope with the peaks through the implementation of additional resources.
However, the cost of leaving those resources underused when the peak
recedes could be significant.

Managing and monitoring clusters is difficult.
The more computers that are added to the cluster, the more difficult it
becomes to monitor and manage them. Ideally, there should be a single
interface to manage all of the computers in the cluster.