The Multi-Tiered Architecture

for RuBoard

On Day 1, you learned that one of the design goals of ADO.NET was to efficiently support a multi-tiered programming model. However, before we discuss how you can take advantage of the features of ADO.NET in an application that uses the multi- tier architecture, we need to define it.

Note

There are a variety of terms used in the industry for the approach described in this section. Two of most prevalent are multi-tier and n-tier , so, as I mentioned earlier, these are the two I will use interchangeably in this discussion. In addition, the terms design, approach, architecture, and programming model are all used to convey the same idea: the way that multi-tier applications are put together.

At the most basic level, multi-tier simply means multiple layers , so a multi-tier architecture is one in which the code you write is divided into layers that interface with each other and that have specific responsibilities. In most discussions of this approach, you'll see three layers or tiers, as shown in Figure 15.1.

Figure 15.1. Multi-tier architecture. This diagram shows the three primary tiers of a multi-tier design.

Each of the three layers has certain responsibilities:

• Presentation Services Tier . The primary responsibility of the presentation services tier is to provide the interaction with the client, either graphically or programmatically. For example, the presentation services are responsible for how the data is displayed and how the user can interact with the data, but not for actually retrieving or saving the data. As shown in Figure 15.1, the presentation services of a .NET application are written using the classes of the .NET Framework to create Web Forms, Windows Forms, XML Web Services, Windows Services, and Console Applications. In addition, the presentation services layer is responsible for adapting the presentation interface to variations in the client device's capabilities. In VS .NET, this is made much easier by the concept of ASP.NET server controls, which can render HTML for both up- and down-level browsers, and the Microsoft Mobile Internet Toolkit (MMIT), which enables you to build Web Forms that render markup language for different devices by, for example, outputting HTML for Pocket PCs and WML (Wireless Markup Language) for Web-enabled phones.

Note

The MMIT is available for download from msdn.microsoft.com by searching for Mobile Internet Toolkit. After it is installed in the Global Assembly Cache (GAC), the assembly can be referenced in your ASP.NET projects and used to build mobile forms using a suite of mobile controls.

• Business Services Tier .

  

  The primary responsibility of the business services tier is to ensure that business processes are able to be carried out by the presentation services tier. The business services classes, sometimes referred to as controller classes, are typically designed with very coarse-grained methods that encompass an entire process and map to a logical unit of work (transaction). For example, a business services class might contain a PlaceOrder method that accepts customer, order, and order detail data. This is then used to update one or more backend data stores (message queues, relational databases, and XML documents) using classes in the data services tier, all within the scope of a single transaction. If distributed transactions are required, controller classes can be run under Component Services by inheriting from the System.EntepriseServices.ServicedComponent class. Because the business services tier is used to provide a standard interface to coordinate or control the activities of other classes, it follows the fa §ade design pattern. As a result, you'll sometimes see this tier described as a business fa §ade.

• Data Services Tier . Finally, the data services tier is responsible for retrieving, manipulating, and updating data in the underlying data stores and making it available to the business and presentation services. There are several approaches to doing this, as shown in Figure 15.1. For example, the data services tier could expose the data through ADO.NET DataSet objects that are then passed between the presentation and business services tiers and finally synchronized again with the data store. Alternatively, it could expose the data through the classes of the System.Xml namespace such as the XmlDocument or XmlReader , work with message queues, or expose data through an object layer created with custom classes. In addition, as you'll learn at a high level later today and in detail on Day 17, "ADO.NET in the Data Services Tier," and Day 18, "Building a Data Factory," the data services tier can itself contain multiple layers of code in order to abstract the provider used and take advantage of implementation inheritance. In addition, because I recommend using a stored procedure layer for communication to the data store, the data services tier includes the stored procedures as well.

Perhaps one of the biggest stumbling points for developers when first considering the multi-tier architecture is their natural tendency to want to follow it rigidly. For example, developers might assume that the presentation services tier should always and only communicate with the business services tier. Although this would provide the greatest abstraction and therefore allow the data services tier to be changed independently of the presentation services tier, it can increase complexity and the cost of maintenance for simpler scenarios.

You'll notice that, as depicted in Figure 15.1, the presentation services tier can communicate directly with the data services tier. This makes good sense because not all the behavior of an application needs to be abstracted. Doing so often results in lots of methods in the business services tier that do nothing more than act as wrappers around methods in the data services tier. This is both more complex and wasteful of resources. Where appropriate, I advocate invoking the data services directly, although that implies that the data services tier must expose a set of meaningful methods.

What About Web Services?

You'll notice in Figure 15.1 that XML Web Services are placed in the presentation services layer of the model. This might seem strange because you generally think of Web services as a means of interacting with data, so you might think they should be placed in the data services tier. However, in many scenarios, Web services simply provide an additional SOAP-based programmatic interface to the data accessible through the firewall, and therefore will call the same business and data services code behind the scenes that a Web Form might rely on.

Having said that, you can certainly create a design in which all your data access flows through Web services that are published internally within your organization. In this design, the Web service layer becomes the external API for the data services tier. In fact, Windows .NET Server will ship with a UDDI (Universal Description, Discovery, and Integration) server that you can use to publish Web services within your organization. However, such a design incurs a performance hit because of the extra processing required to build and parse the SOAP messages. As a result, this approach will be most useful in large and distributed organizations. Generally, within the firewall, the most efficient way to access your data is to use a set of data access classes, in the data services tier, that use specific .NET Data Providers.

Relation to Physical Tiers

It is important to keep in mind that the multi-tiered approach discussed in the previous section is a logical construct that doesn't require you to physically distribute the tiers on separate machines. In other words, when you create a data services tier, it doesn't have to be isolated on a separate server or farm of servers. In fact, many Web-based multi-tier applications will locate all their code on a single Web server. However, the design decisions you make when coding your data services tier will influence scalability if you decide to distribute the tiers on multiple servers. For example, the use of the streamed programming model with data readers in ADO.NET is optimal when the data services code runs in the same process as the presentation and business services, but it can cause performance problems when used across machines due to the number of roundtrips that would be incurred. Generally, the goal with a multi-tier architecture is to be able to physically distribute the application at a later time if scalability becomes an issue. This is referred to as the scale-out approach because it attempts to amortize the processing of the application across multiple machines. This is contrasted with scale-up , which focuses on increasing the resources available on a single server.

Note

Although scalability and performance are related , they can be thought of as two different concepts. For example, an application can perform very well (have high throughput) when serving 100 clients, but can slow to a crawl when serving 1,000 clients. In this case, the application performed well for its normal workload, but wasn't scalable because its increase in throughput did not track linearly with the number of clients. Making an application scalable means keeping the throughput high even as a greater number of clients use the system. Although this can be done to some extent by designing your application to use resources (memory, CPU, network bandwidth) efficiently, at some point, any application will overwhelm the resources of a single server. Scaling-out seeks to increase by scalability by isolating either tasks or clients or both on dedicated servers.

In that respect, there are several different physical architectures for scale-out that you might employ . A typical one is shown in Figure 15.2.

Figure 15.2. Physically distributing an application. This diagram shows how the logical tiers might be distributed across machines.

You'll notice from Figure 15.2 that one approach might be to isolate all the presentation services code on a cluster or farm of identical Web servers using the Network Load Balancing ( NLB ) clustering feature of Windows 2000 Advanced and Datacenter Server. NLB distributes incoming IP traffic across a cluster of up to 32 servers that appear to the client as a single IP address. Traffic is processed by the servers based on priority and other configurable settings. When you use this approach, it's important that the presentation services code be as stateless as possible so that subsequent requests from a particular client needn't be handled by the same server ( server affinity ). Although NLB supports server affinity (or "sticky IP"), doing so compromises scalability and fault tolerance because the cluster needs to maintain the mapping of clients to servers, and losing a server might wipe out the client's state information (or session state). The risk of losing a client's session state is mitigated by the fact that ASP.NET allows session information to be stored directly within SQL Server or using a separate Windows Service configured through the Web.config file for the ASP.NET Web site. NLB can be configured both independently and as a part of Application Center 2000 to ease the administration of the cluster.

Tip

NLB is a software-based approach used on Windows server. Two other means of building Web farms include using round- robin domain name system (RRDNS) at the network layer, and using load-balancing switches such as the Cisco LocalDirector at the hardware layer.

Figure 15.2 also indicates that the business and data services code might utilize the component load balancing (CLB) feature of Microsoft Application Center 2000. Simply put, CLB allows for the creation of a cluster of servers used to load balance requests to components configured in Component Services. As a result, CLB is useful only for business and data services classes that use Component Services by inheriting from the System.EnterpriseServices.ServicedComponent class. These classes can also be decorated with the LoadBalancingSupportedAttribute to indicate that they support CLB if installed.

However, not all business and data services classes will utilize Component Services, so for many applications, scaling-out simply means running all three tiers on a farm of servers, perhaps using NLB. For those applications, it might be more efficient because the extra latency and complexity introduced by isolating the services on their own servers will wipe out any benefits. Alternatively, as mentioned previously, you can also expose your data services tier through XML Web Services, and then use NLB to create a cluster of servers that expose the Web services for the presentation services tier to use.

You'll also notice that if the business and data services are to be isolated on their own cluster of servers, the issue of server affinity also comes into play. In other words, you want to design your business and data services to be stateless so that any client from the presentation tier can access any of the servers in the CLB cluster. A stateless design is one in which the methods are given everything they need to do their work and do not store any private data between calls. This design also pays dividends even on a single server where the business and data services components can be pooled and reused by Component Services if they are stateless.

Finally, the data store itself can be isolated in a separate fault-tolerant cluster of database server machines. For example, Windows 2000 Advanced and Datacenter Servers support the Microsoft Cluster Service (MCS) that SQL Server 2000 Enterprise Edition can utilize. With MCS, you can create a failover cluster in SQL Server that allows one of the two server machines in the cluster to provide fault tolerance by taking on the workload of the other server if it goes down. As indicated in Figure 15.2, this works by the two servers utilizing a shared disk subsystem and a "heartbeat" that allows the passive machine in the cluster to determine whether the active machine is still functioning. Although SQL Server 2000 can support a fully distributed database scenario using distributed partitioned views (DPV), for all but the largest applications, it's typically more cost effective to scale-up the servers in an MCS cluster rather than designing and maintaining a distributed database.

Which physical configuration you use is, of course, totally dependent on your particular application and its requirements.

Benefits of a Multi-Tier Approach

In addition to the benefit of being able to scale-out the application, there are several other advantages to using a multi-tier approach:

• Maintainability . By separating the responsibilities of the application into separate layers, it will be easier in the long run to isolate problems to a specific layer and fix them while not affecting the other layers. Although this isn't always the case, and occasionally a change ripples through all the layers, by paying attention to design ideas such as loose coupling, encapsulation, and well-thought-out and defined interfaces, you can isolate changes to a specific layer and avoid introducing bugs in other layers.

• Reusability . Because the layers will be isolated, they should also be able to be reused in different applications. This is particularly true of the business and data services tiers, which might need to be repackaged and reused by a different user interface. For example, the same business and data services might be used both by an ASP.NET application targeted to desktop browsers and one built with MMIT targeted for mobile devices. A second example of reusability is the opportunity to take advantage of implementation inheritance in the .NET Framework to, for example, create base classes that can be used in the data services tier of multiple applications.

• Extensibility . As an offshoot of maintainability, the introduction of new requirements should be able to be handled more easily because the tiers are separated. Once again, in conjunction with the use of good object-oriented design patterns, the code in one tier can be extended while not affecting the others.

• Specialization . Because not everybody can know everything, splitting the responsibilities of the application into separate layers provides the opportunity for developers to specialize in the techniques and issues inherent in developing for a particular tier. For example, a presentation services specialist might be well versed in writing ASP.NET server controls and the ins and outs of Dynamic HTML, whereas a data services specialist thoroughly understands connection pooling and how to write stored procedures in SQL Server.

• Rapid Development . Although not generally thought of as a benefit for multi-tier applications, I submit that multi-tier applications are in fact faster to develop because they clearly delineate the responsibilities of various parts of the application and provide a mental map that makes it simpler for developers to write appropriate code. In many ways, this is the same issue as maintainability because in every software development project, the requirements aren't fully known when development begins, so following an approach that allows for abstraction will typically result in less rewritten and reworked code.

Note

For a good introductory discussion on object-oriented design patterns, see Design Patterns Explained : A New Perspective on Object-Oriented Design by Shalloway and Trott, published by Addison-Wesley. ISBN: 0-201-71594-5.

for RuBoard