Home > Articles

  • Print
  • + Share This
This chapter is from the book

Common Site Designs

Now that we've covered all the theory behind site design, you're probably wondering how to apply it to your business situation. The best way for us to help you do that is to show you some examples based on common business requirements. So, in the next few sections, we'll show you some common site designs. We'll focus on three main design categories:

  • Maintainability, which is intended to produce sites that are easy to manage and maintain throughout their life.

  • Scalability, which is intended to produce sites that can be easily expanded to handle an ever-increasing number of users.

Availability, which is intended to produce sites that can survive hardware and software failures and continue functioning normally from the user's perspective.

Our discussion of design theory in the first part of this chapter centered around three primary design components:

  • Web pages, which you create using ASP or ASP.NET.

  • The site itself, which consists of your Web servers and various pieces of server software.

The network that supports your site, including your Internet connections.

For each design category, we'll give you examples of specific Web page, site, and network design that meet various levels of maintainability, scalability, and availability.

NOTE

You may be wondering whether all of this design effort is necessary for an intranet e-commerce site, such as an internal e-procurement site, a company store for employees, and so forth. Absolutely!

What often differs between Internet e-commerce sites and their intranet cousins is scale. Certainly, intranet sites often have fewer users and you can more easily predict your maxmum user load because the site will be accessible only to employees. Scalability, then, becomes a less complex problem. Availability is often less crucial, too, because employees may be able to live without their company store for a while if a server fails.

None of these issues change your design process, though; they simply change the decisions you make during that process. Always be cautious when "shortchanging" an intranet site because it's "only for employees," though. Intranet sites have a way of becoming mission-critical components of a company, demanding the same levels of availability, scalability, security, and maintainability of an Internet-based site.

Designing for Maintainability

The key to maintainability is always asking yourself, "How easy will this be for someone else to understand and change in the future?" Even if you're the one who'll be maintaining things in the future, it's all too easy to forget why things were set up in a specific way six months or a year afterward.

The biggest key to ensuring maintainability is documentation. Document everything. Keep a master site document that describes the purpose of every Web page, every server, every network connection, and every configuration setting. Your documentation should be thorough enough to allow someone else to rebuild the site from scratch in case of a complete disaster (such as a meteor striking your data center). Aside from documentation, there are some other steps you can take to improve the maintainability of your Web pages, networks, and overall Web site.

Maintainable Web Pages

ASP pages can be made more maintainable by modularizing them. For example, almost every ASP page in your site will have to establish an ADO connection to your back-end database. You might program a few lines of code to do that within each page, as shown in Listing 3.1.

Listing 3.1 Creating an ADO Connection in ASP

<%
Dim oConn
Set oConn = CreateObject("ADODB.Connection")
oConn.Open "MyDataSource"

'rest of ASP page goes here
%>

There's nothing wrong with that technique, unless something changes in the future. For example, suppose you move to a new, more powerful SQL Server and change the data source name that the server uses. You would have to change every single ASP page in your site with the new, updated data source name—a maintenance nightmare.

ASP allows you to modularize your code through the use of server-side includes. Listing 3.2 shows a small ASP page that simply opens the ADO connection, and nothing else. You might save that file as i_ado.asp (the "I" prefix indicates that the page isn't a standalone page, but is instead intended for inclusion within other pages).

Listing 3.2 Writing an Include File

<%
Dim oConn
Set oConn = CreateObject("ADODB.Connection")
oConn.Open "MyDataSource"
%>

Listing 3.3 shows your original ASP page from Listing 3.1, modified to take advantage of the new include file.

Listing 3.3 Modified Asp Page That Includes i_ado.asp

<!--#include file="i_ado.asp"-->
<%
'rest of ASP page goes here
%>

Including files lets you make changes in only one place. For example, if you need to change your data source name, you just change i_ado.asp. The change then immediately takes effect in all pages that include i_ado.asp.

TIP

Anytime you'll use a given piece of code more than a couple of times, put it into an include file.

ASP.NET is based upon the .NET Framework, so it offers even more opportunities for modularization. ASP.NET pages are object oriented, offering the highest level of modularization and maintainability. You can create your own classes to perform specific functions—formatting product ID numbers, for example—and use those classes within ASP.NET pages. Any changes to the class will automatically be inherited by any classes based upon that class, and by any pages that use the class.

Maintainable Web Sites

Creating a Web site that's easy to maintain requires careful planning. If your site's servers are located in your office, or are otherwise attached to your private company network, maintenance is usually easy. You simply access the servers using the same network adapter that the servers use to communicate with back-end servers such as their database servers.

Maintaining servers that are located at a remote hosting facility can be more difficult. As we discussed in Chapter 2, you will probably have to go through a firewall to manage your servers, making a VPN an ideal solution. VPNs can also provide a solution for maintaining remote back-end servers, which aren't normally accessible across the Internet. Figure 3.3 shows a sample network diagram that includes a VPN server. Note that your administrative workstation is located at your office and creates a VPN connection to the remote VPN server. The VPN server then provides access to the remote back-end network, allowing you to easily administer all of your servers, despite the hosting facility's firewall (which must be configured to permit the VPN traffic).

Figure 3.3 Using a VPN for remote maintenance makes it easier to configure firewalls, because only the VPN ports need to be opened.

Maintainable Networks

The key to a maintainable network, as we've said before, is documentation, documentation, documentation. You should put together a sheet or two of documentation for each server in your Web site, such as the one shown in Figure 3.4.

Other network devices on your network need documentation, too, such as the sample router documentation shown in Figure 3.5.

Figure 3.4 Server documentation makes long-term maintenance easier by helping you remember why you configured things the way you did.

Carefully documenting every piece of information about your network will help both you and future administrators when changes are required, or when problems arise. You should also have any necessary network diagrams that show how your site's network fits together, such as the sample diagram shown in Figure 3.6.

Designing for Scalability

To ensure scalability, always ask yourself, "How easy will it be to expand this to support additional users?" The easier the answer seems, the more scalable your site is. Another good question is "How can we configure/program/design this to support the maximum number of users?" Don't overlook answers that seem to offer only minor improvements. For example, you might discover a programming trick that will allow a Web server to support a dozen extra users. That small of a number might not seem worth your while, but remember that your Web site may contain dozens of servers one day. If your programming trick can help each server support an additional dozen users, that's more than a hundred additional users for the whole site.

Figure 3.5 Router documentation is especially important, as it serves as the basis for your overall network documentation.

Scalable Web Pages

Creating scalable Web pages means avoiding technologies that impair scalability. In an ASP-based Web site, which is what you may be creating with Commerce Server 2002, the biggest obstacle to scalability is ASP session variables. Don't use them, and you'll definitely improve your site's scalability.

A more subtle way of improving scalability is to take every opportunity to improve performance, both on the Web servers and on their supporting database servers. Here are some tips:

  • When retrieving data from a SQL Server, execute a stored procedure that returns the data rather than executing a regular query. SQL Server executes stored procedures much more quickly than regular queries. In fact, everything you do to the SQL Server should be done through a stored procedure whenever possible.

  • Write stored procedures to return only the data you absolutely need. For example, if you frequently need to query product inventory levels, write a stored procedure that returns only the inventory number. If you sometimes need to query the inventory and the description, write a separate stored procedure for use in those circumstances. It won't hurt SQL Server to have a lot of stored procedures available, and minimizing the data a stored procedure returns will definitely improve performance.

Figure 3.6 Network diagrams should show relevant network components, such as servers, an estimate of client concentration, routers, and so forth.

  • Keep your servers up to date with the latest versions of ADO and other core object libraries. Microsoft improves the performance of these libraries with each new version, and even if the improvements are slight, the cumulative effect will be noticeable.

  • Use the absolute minimum amount of script code and database access necessary. Whenever possible, let IIS serve up static HTML pages instead of ASP pages, because IIS operates at peak efficiency when it doesn't have to deal with program code in your Web pages.

Product pages are an excellent example of that last tip. Some sites are designed with a single product detail page, named something like product.asp. The page accepts a parameter or two to indicate the product that the user is trying to view, and uses ASP code to dynamically query the appropriate product's information from the database and display the information for the user. Although that technique is an elegant solution, it requires IIS to do an incredible amount of work for one of your site's most common tasks.

Purely static product detail pages aren't usually feasible, because product information changes too frequently. Prices change, product descriptions change, and so forth. If you used static pages in your site, you and your staff would spend an enormous amount of time updating static HTML pages to match the information in Commerce Server's product catalog database.

The best solution lies in between totally dynamic and totally static pages. For example, you might write a Visual Basic application that runs automatically each evening. The application queries the Commerce Server database and creates static HTML pages for each product in the catalog. This technique gives you the high performance of static HTML pages, along with the benefits of dynamic pages that query product information from the database.

If your product information changes more than once a day, you might write a SQL Server trigger that generates a new static product detail page whenever a product's information changes. That way, your site will always contain the most recent product information in easily served static HTML pages.

Scalable Web Sites

If you've taken the time to create scalable Web pages, your overall site will be more scalable as a result. If you're not using ASP session variables, for example, adding capacity to your site can be as easy as adding another Web server to take up some of the user load.

In fact, your Web servers represent the most scalable portion of your Web site, because you can usually add another server to increase your site's capacity. Eventually, however, you'll add more Web servers than your back-end database servers can keep up with. The back-end portion of your site is usually the least scalable because everything comes down to a few SQL Server databases.

If you've already distributed the Commerce Server databases to the greatest degree possible, you'll have to start taking more complicated steps to add back-end capacity to your site. The most common means of adding back-end capacity is to split the site, as shown in Figure 3.7.

In this example, you create two identical, independent Web sites, each with their own Web farm and back-end database servers. A third set of database servers holds your master databases. SQL Server replication is used to replicate catalog and other changes from the master servers to the site's servers, and to replicate order information from the site's servers to the master servers. Although expensive and complex, this technique offers potentially unlimited scalability, because you can always create a new, independent Web site whenever you've reached the scalability limits of an existing site.

Figure 3.7 Splitting a Web site can also allow you to distribute your site's servers geographically, if desired.

Scalable Networks

Creating scalable networks is probably one of the most difficult tasks an e-commerce site architect must face. Although local area networks (LANs) are easily scaled by using switches and routers to break the network into smaller, independent networks, wide area network (WAN) connections are much more difficult to scale.

The most common (and affordable) form of WAN connectivity in the USA are T1 lines, which provide a bandwidth of about 1.5Mbps. That's about one-sixth the speed of a very slow Ethernet LAN, which runs at 10Mbps. Hosting facilities may provide higher-bandwidth connections, which you'll share with the facility's other customers.

If you're not using a hosting facility, and your Internet connection is no longer big enough, it can take a month or more to add another (or a larger) line to double your capacity. If you are using a hosting facility, you may be able to purchase additional bandwidth from the facility, up to the maximum size of their WAN connection. If the facility needs to expand their WAN connection to meet your needs, you should probably start shopping for a new facility, because it will ultimately cost less.

In the end, even the most expensive WAN connectivity available will provide significantly less bandwidth than even a cheap LAN. So, because WAN connections are inherently the least scalable component of your Web site, design your site to be efficient—even miserly—in the use of WAN bandwidth. Here are some tips:

  • Minimize the use of bandwidth-consuming graphics, sound, and video. If your site needs to make heavy use of these multimedia elements, consider outsourcing their delivery. Outsourcing companies such as Akamai.com maintain high-bandwidth Internet connections, and allow your Web pages to pull your graphics, sound, and video from the outsourcing company's network, rather than your own.

  • Schedule bandwidth-intensive tasks such as mass email campaigns for hours when your bandwidth isn't being heavily utilized by customers. For example, a retail clothing site such as HipThreads might see most of their customers in the evening hours, leaving the daytime open for other tasks.

  • Look into cache-encoding. Cache-encoding helps your customers' computers (and their ISPs' computers) determine which portions of your Web site don't change very often. By cache-encoding relatively static pages, you help those remote computers save a copy of the page, so that it doesn't have to be pulled from your Web site each time a customer requests it. Cache-encoding can be especially useful when a lot of your customers are from America Online (AOL), because AOL aggressively caches pages to help manage their own bandwidth issues. You can learn more about cache-encoding in Microsoft's ASP documentation.

Designing for Availability

The question to ask yourself for availability is, "Is there any one bit that will prevent the site from functioning normally if that bit fails?" Eliminating any single points of failure—pieces of the site that don't have any redundancy—will ensure that your site continues to operate even when hardware or software fails.

There's very little black and white when designing for availability. Instead, availability is a matter of degrees. For example, you can purchase uninterruptible power supplies (UPSs) for your computers at a fairly low price. Doing so will give you a few minutes' extra power if the electrical utility power fails. For more money, you could purchase larger UPS batteries, which will allow your site to run for additional minutes without utility power. For even more money, you could install a diesel backup generator that will provide hours of operation in the complete absence of utility power. The level of availability you design for depends on your business needs (how much money will you lose if your site is down for a few minutes?), your environment (how often does the power go out in your area, and what's the average duration of each outage?), and your budget (how much availability can you afford to buy?). Another example might be planning for a database failure (which will eventually occur). You could just use a single database server, and hope nothing goes wrong. You could build a clustered server, which will help protect against server hardware failures, but not against database corruption. You could use separate database servers that replicate data to one another, which will protect against a hardware failure and database corruption. Each alternative costs a little more, requires a little more administrative effort, and gives you a little more peace of mind. You just have to decide how much peace of mind you can afford.

Of course, availability involves more than just planning for power outages. In the next two sections, we'll cover various levels of availability for Web sites and for the networks that support those sites.

Available Web Sites

For Web servers, scalability and availability are almost the same thing. For example, if you have a dozen Web servers providing the same content, one of them can probably fail without severely impacting your site's overall ability to serve customers. For that reason, Web server computers are often smaller machines without the highly redundant hardware of more powerful servers.

Back-end servers, such as your database servers, are much more likely to be impacted by a hardware failure. Although you can (and should) purchase servers with redundant cooling fans, power supplies, and so forth, nothing can protect you from a total hardware failure (such as a processor or memory failure). What you need is the whole-server redundancy provided by a cluster. Clusters contain at least two servers capable of performing the same job. If one fails, the other simply takes over. Both SQL Server Enterprise Edition and Commerce Server Enterprise Edition are cluster compatible.

For more information on using clustering to build highly available sites, see "Recommendations for a Highly Available E-Commerce Site."

Available Networks

Network redundancy equals network availability. Here are some tips for creating a highly available network:

  • Configure servers with redundant network cards. High-end network cards can work in tandem, with one card mimicking the other's identity in the event of a failure.

  • Connect servers to two separate switches. In the event that one switch fails, it'll have the same effect as a network card failure. The server's redundant card can continue operating through the functioning switch. You'll need to use high-end switches that can be configured in redundant pairs, such as those available from Foundry Networks.

  • Use redundant routers on redundant Internet connections. If one connection fails, that router can route its traffic through the router connected to the remaining Internet connection. Routers should work in tandem with your switches, so that if one router fails, the switches will direct traffic to the surviving router.

  • Make sure every component on your network supports some form of network management protocol, such as the Simple Network Management Protocol (SNMP), and use a management console that checks the components for proper operation. That way, if a failure occurs, you'll be notified immediately and be able to take action.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020