Microsoft Windows DNA is based on a distributed system architecture. Distributed systems contain components on more than one computer. An Internet-based system is a typical example of a distributed system, as it contains an application running on a client computer (usually a browser-based application) and one or more applications running on a Web server. The Web server can also communicate to other servers. In this tutorial, we'll focus on building Windows DNA systems, but the discussion is equally applicable to other distributed systems.
One of the primary goals of distributed systems is to be highly scalable. A highly scalable system can easily expand from thousands of users to tens of thousands of users. Over the last two decades, we've witnessed a steady evolution from Windows systems that can handle a few hundred users, such as a department-size application, to systems that can handle tens of thousands of users, such as an Internet application. This tutorial will demonstrate how a distributed system can be highly scalable.
Because distributed systems contain a variety of components located on several computers, these systems are usually extremely complex. Without a framework such as the one provided by Windows DNA, designing and building such a system would be impossible. The Windows DNA architecture provides two models for designing and building large, complex distributed systems: the logical three-tier model and the physical three-tier model. The logical three-tier model is used to define and design the components of the system. The physical three-tier model is used to specify the placement of these components within the distributed system. Let's begin by looking at the logical three-tier model.
When you build components in a Windows distributed system, you will define the components based on the services they perform. For example, the Web page running in the Web browser will perform services for the user, such as allowing the user to enter information, select information, or navigate to another Web page. Components placed on the Web server will receive requests from the Web browser to perform services such as accessing a particular Web page, searching the catalog for all occurrences of a particular word, and so on. The services that a system can perform are divided into three categories: user services, business services, and data services. Thus, you can form three tiers: the user services tier, the business services tier, and the data services tier. Each of these tiers consists of one or more components.
The user services components are responsible for passing information to and from the user. Specifically, they gather information from the user and then send the user information to the business services components for processing. After the information is processed, the user services components receive the processed results from the business services components and present them to the user. Typically, the user is a person and the user services components consist of user interface components such as Web pages in a browser, an .EXE application containing forms, and the like. A user could also be another system¡ªin which case, there's no visible interface. An example of this scenario would be an application that verifies credit card information.
To design user services components, you must interview the potential users of the system. Based on these interviews, you can create a detailed description of the steps required to complete each of the tasks that the system will be asked to perform. These descriptions can then be turned into Unified Modeling Language (UML) use cases. UML is a set of models used to design object-oriented systems, although it can be used to design virtually any system. A use case is a text description of how a user will perform a task; each use case has a specific format such as a flowchart, a flow diagram, or a step-by-step outline in a table format. These use cases will help you organize the steps required to complete your tasks, will help you define the components your system will need to perform these tasks, and can be used as the basis of the design for your entire distributed system.
For the most part, user services components are designed to meet a specific need and are not reusable. For example, the user components specifically created for entering employee information are not likely reusable in an application that's used for obtaining order information from customers.
Besides communicating with the user, most applications must process data. For these applications, you will also need to define a set of business rules that govern how data is handled. Examples of business rules could be the requirement that every customer have a name, a customer ID, and a billing address. Business rules are similar to use cases, except that they are text descriptions of the requirements to be met to ensure a business is run correctly. In a two-tier architecture model, some or all of the business rules regarding data processing are placed in the user services components. In a three-tier architecture model, the business rules are moved from the user services components to the business services components.
The business services components receive input from the user services components, interact with the data services components to retrieve or update data, and send the processed result to the user services components. The business services components ensure that the business rules are followed. For example, a user services component may ask a business services component to save a new customer record. The business services component will then verify that this new record fulfills all of the rules for a new customer record. In another example, the user services components might request that the business services components retrieve a particular Web page containing data from a database. The business services components will get the data and format it according to a set of rules and then build an HTML or XML page for the user services components.
If the business rules change, only the business services components that contain those rules will need to be changed. If the business rules are placed within the user services components, the user services components will have to be updated every time a rule changes. If such a user services component were an .EXE application installed on thousands of computers, a change in the business rules would mean reinstalling the component on all the client computers.
Separating the business rules from the user services components is only one benefit of using business services components. Business services components usually contain logic that is highly reusable. For example, if you create a business services component to retrieve product information for a Windows-based application, you don't need to rewrite this component if you want to create a Web-based application that requires the same business logic.
Using business services components also simplifies the building of your user services components. As previously mentioned, the business rules in the three-tier model are moved from the user services components to the business services components. Thus, the user services components are simplified. In addition, if you build business services components as objects that expose methods and properties, your user services components can be simplified further since the code in your user services components will consist of setting properties and calling methods of the business services objects.
For example, let's say your application requires validation of new orders. You can implement the validation logic in the user services components, but you can also separate this logic from the user services components and implement it in an Update method in the business services components. Thus, the validation of a new order will be done when you call the Update method.
The business services components usually handle data processing. To get the data, they make requests to the data services components. The data services components are responsible for storing and retrieving data and maintaining data integrity. They communicate directly with a data source. A data source can be a database, a text file, an XML file, an XML document stored in memory, and so on. When a system performs the Create, Read, Update, and Delete (CRUD) operations, the business services components will validate these operations. If the operations are valid, the business services components will make a request to the data services components to actually perform the operations. If the CRUD operations are invalid, the business services components will raise an error and will not have to communicate with the data services components.
A common confusion associated with the DNA model is between the data services component and the database. A data services component can be either a component that is running on a server (usually not the database server) or a stored procedure. Often a system will have the data services tier that consists of both stored procedures and components. (Some authors refer to the database as a "fourth tier of the logical model.") Either way, the actual physical database is not the data services tier, although it may contain the data services components in the form of stored procedures.
Like business services components, data services components are highly reusable. For example, an e-commerce application, an order entry application, and a reporting program for management could use the same data services component that performs CRUD operations on customer records.
Over the past year, the view on stored procedures has been changing. Earlier it was generally believed that stored procedures were the best location for data services components. Stored procedures could use the security features of the database and be centrally controlled by the database administrators. The major problem with stored procedures, however, is scalability. Replicating databases is difficult and usually inefficient. If you build all of your data services components as stored procedures and the server you are using runs out of memory or other resources trying to run these stored procedures for thousands of users, you cannot easily build a second database server and share the load between the two database servers. Your only option is to upgrade the server. If you reach a point at which the server is already at the maximum capacity the current technology can offer, your server will no longer be able to handle the required loads.
If you build data services components that are placed on a server other than the database server, you can increase the capacity of the system by adding another server. If you use some method to balance the load between the servers, the business services components can call whichever server has the least load. Since the data services components are performing services only for the business services components, it doesn't matter on which server a data services component performs the service.
Of course, if you don't build data services components as stored procedures you will probably not be able to use the database's security mechanisms directly. Instead, you will have to implement security features within your components. This security code should go into the business services components, as they will contain the rules for validating users.
NOTE
Regardless of whether you use stored procedures or components for your data services tier, you should still place validation rules in your database, in the form of triggers, constraints, and so on. Although this means that you are placing the rules in two locations: one in the database and the other in the business services tier, doing so prevents users from performing invalid CRUD operations directly on the database.
So far you've learned that by using Windows DNA, you can split your application's services into three parts: user services components, business services components, and data services components. Now you will learn how you can tie the three parts together. In Windows DNA, this is done by exposing system and application services through the Component Object Model (COM).
The foundation of Windows is COM, which has become COM+ in Microsoft Windows 2000. (COM as used here refers to both COM and COM+.) COM provides a way for applications to communicate with COM objects. COM also enables one object to communicate with another object through method calling and property setting. How a COM object actually performs its services is not important. Objects hide or encapsulate the details of how they work. Because an object hides how it performs its services, you can change the way an object performs its services without breaking the application that uses the object.
If the services components in each tier are COM components, the communication between tiers will be COM method calls. To be specific, your user services components will call the methods of the business services components to request services from the business services tier, and your business services components will call the methods of the data services components to ask for services from the data services tier.
The physical three-tier model includes the actual computers on which the components will be placed. There are three groups of computers: client tier, middle tier, and database tier. The client tier computers provide user services, consisting mainly of the user interfaces. The middle-tier computers provide business services, consisting of enforcement of business rules and data validations. The database tier computers provide data services, consisting of the data and the ways of accessing and maintaining the data.
Several years ago, the two-tier model, also called client server, was popular. This model consisted of a client tier that communicated with a database tier. This model required the client computer to maintain a continuous connection to the database. The database could keep track of what records were being edited and place locks on these records so that only one person could change a record at one time. Locks insured that the data would be consistent. The main drawback of this model was that the systems were not very scalable. Since developers wanted to build systems that could scale to hundreds and even thousands of users, they needed another solution.
The solution to making systems more scalable was to break the connection the client had with the database. Originally, the data was passed to the client computer where CRUD operations could be performed on the data. If the data was updated, this data could be sent back to the database. With this disconnected model, the database could no longer lock records because the client had no connection to the database. Thus, the database had no way to reconcile inconsistencies. An alternative to locking records was developed that allowed the client to communicate with an application located on the server that could make changes to the database. This application is the data services component we have been discussing in this section. Instead of running this application on the database tier, the middle tier was added to host the data services components.
The idea of a middle-tier computer had existed long before the use of a disconnected model. In non-Windows operating systems, applications were commonly placed on a central server and used by many clients. These clients often had little functionality and were called dumb terminals. The middle-tier computer can still be used to host components, such as the business or data services components that can be used by multiple clients, but now modern clients are usually fully functioning and have many applications running on them.
Before we look at how to place components created in the logical model onto the computers in the physical model, which we'll do in the section "Locating Logical Components" later in this chapter, we must first examine the component state.
One of the most important aspects of creating scalable components is the use of stateful and stateless components. A stateful component can retain information from one call to the next. For example, a Microsoft Visual Basic .EXE application can be created that keeps track of the currently logged in user from the moment the user logs in until the time the user logs off. State is stored by using properties. In our Visual Basic example, we could use a read/write property named userName and a write-only property named userPassword. A stateless component has no memory from one call to the next. For example, a data services component that retrieves customer records retrieves customer records for one client and then retrieves records for a second client without any memory of what it retrieved for the first client. A stateless component does not have any public properties.
In the physical model, components that are placed on the middle-tier server and communicate with the client computer should be stateless. If a component on the middle-tier server maintained state (that is, retained information between calls from the client), these components would need to maintain information on every client that made a request to the component. As the number of clients making requests increased, the information that would need to be stored in memory would increase until the server ran out of memory. This would not be a scalable solution.
If components on the middle-tier and database servers do not maintain state, they can quickly perform a service for one client and then perform a service for another client. This feature works even better with a technique called just-in-time activation (JITA). With JITA, a component becomes active immediately before it is used. Once the component has been activated, it will quickly perform a service and then deactivate. As soon as the component has finished with one client, it is available for another client. These components can be built so that they require a minimum amount of time to perform their services. They reside in memory for only a brief time to service each client. Because these components are stateless, they will not require any memory usage between client calls. Thus, a stateless component that uses JITA will use the absolute minimum amount of server resources while still servicing a large number of clients. These types of stateless components can scale very well.
NOTE
It is possible to create stateful server components that communicate with the client. The most common example is stateful ASP. Using state for ASP-based systems that never have more than 100 possible users, such as a small departmental intranet application, might be appropriate. Using state in large-scale ASP-based Web applications, however, will seriously degrade performance of the system and should be avoided.As we've seen, the design of a distributed system begins with the logical three-tier model. Initially, the overall goals of the system must be defined. These goals are broken down into the series of tasks the system must perform. These tasks are defined in UML use cases that define the interaction between the user and the system, and then the use cases can be used to define the user services components. A hotel's guest registration system could have the following use case:
- Name Make a Reservation.
- Overview The purpose of this use case is to create a new reservation.
- Primary Actor The main actor is the Check-In Clerk.
- Secondary Actors None.
- Starting Point Request to enter a new reservation.
- Ending Point The Guest is either assigned a reservation or the reservation is cancelled.
- Measurable Result The Guest is either assigned a reservation or the guest is not assigned a reservation.
- Flow of Events
- Actor enters First and Last Name of Guest into the system.
- Actor enters address of Guest into the system.
- Actor enters room requirements for Guest.
- Actor requests room reservation.
- Use Case Extensions None.
- Business Rules
- Definition Business Rule Reservation
- Definition Business Rule Guest
- Definition Business Rule Check-In Clerk
- Outstanding Issues None.
You can also use the use cases to create UML diagrams, such as a sequence diagram, to define the system's business and data services components. Figure 10-1 shows a sequence diagram illustrating the interaction between objects in the system and the interaction between the user and the system over time.
Figure 10-1. A sequence diagram for a hotel's guest registration system.
After the sequence diagrams have been completed, class diagrams are created, as shown in Figure 10-2. As you can see, class diagrams define the components of the system and the services they perform.
Figure 10-2. A class diagram for a hotel's guest registration system.
Up to this point in the design process, there should be little discussion of how these components will actually perform these services, in keeping with the concept of encapsulation. When you have reached this point, you must decide whether to buy, reuse, or build your components.
Components can be bought from third-party vendors. If a third-party component can be found that performs the services you need, it is usually the most economical solution. On the other hand, third-party components typically perform a large number of services that you do not need and may not exactly fit the needs of your project. You must also verify that the maker of the product will update the component to accommodate new operating system and development program releases.
Reusing existing components is also an excellent option. Often the best way to make your component reusable is to carefully plan your system before you build it. With planning, you can often identify components of the system that can be used in many places. Sometimes an identical component can be used in numerous places; at other times only a part of the component can be used in multiple places.
In addition to reusing components, you can also reuse a component template. During the designing phase, you may find that some components can be built from a particular pattern. If you are building an order entry application, for example, you may find that all of your business services components perform the same CRUD functionality. Thus, all of your business services components have Create, Read, Update, and Delete methods. You can use this pattern of shared methods to create a template that can then be used to build all of your business services components with CRUD functionality.
Building a component is the most costly option in terms of time and resources, but with proper planning and design it will guarantee that the correct component is built. Using patterns and creating reusable components can offset the cost of designing and building components from the ground up.
The best option depends on the available resources. Finances, available personnel for development, and time allowed for development are the three most common resources that will influence your decisions. Each system should be carefully analyzed to find the best solution for that system.
The traditional view held that user services components belong on the client computer, business services components belong on the middle-tier computer, and data services components belong in stored procedures on the database computer. This placement is usually appropriate for smaller systems with a limited number of users or large Internet-style systems, but it is not always the best configuration for all systems. There are several factors you need to take into consideration when designing your deployment plan.
Performance considerations
Business services components can perform many different functions and the middle-tier computer is not always the optimal location for these components. For example, the business services components that validate input from the user services components will provide the best performance if they are located on the client computer. When the user inputs information into the user services components, the business services components can provide immediate validation because the user and business services components are both on the same computer. On the other hand, if the business services components that validate user services components are located on the server, requests to validate input must be sent to the server. Sending the validation to the server can slow down the process, especially when network traffic is heavy, and can affect the overall performance of both the application and the user.
However, some types of business services components might have better performance even though they are placed on a server. For example, you could have a business services component called by an ASP document that builds HTML pages. The Web server is communicating with the business services component, not with the client, as in the previous example. As long as the Web server has enough resources, which is usually the case, the business services components could be placed on the Web server. The data services components and the server-side business services components could also reside on the same server. The decision would be based on the expected load and the capabilities of the server.
Component state considerations
In smaller systems, business services components located on the middle-tier computer can maintain state. These systems are typical of department-size applications with users in the tens or hundreds instead of thousands.
For example, you could build an order entry application in which all the business services objects¡ªsuch as the customer, order, order details, and product objects¡ªare located on the server. The client application could call these objects and have them maintain state from the beginning to the end of each order. This would require you to maintain state on the server, but with only a small number of clients, doing so should not adversely affect server performance. However, in a larger system, maintaining state on the server will significantly slow the server's performance.
One scenario has no performance loss caused by stateful business services components on the server: when one component on a server calls a second component on the same server, it makes no difference in performance if the second component is stateless or stateful. If the two servers share a direct network connection, you can also put the second component on a second server. A common example of this is a Web server, such as Microsoft Internet Information Server (IIS). With IIS, you can use stateless ASP documents to communicate with the client. These stateless ASP documents can use stateful or stateless business services components, such as Visual Basic objects, to build the Web pages. These Visual Basic objects will be on either the Web server or another server directly connected to the Web server. Because the ASP document is stateless and will exist only for a few milliseconds (long enough to perform a service for the client), any object it uses will also exist only for a few milliseconds. The ASP document can be considered the main business services component; the Visual Basic objects are the secondary business services components. The ASP document orchestrates the entire process of performing the service for the client.
Installation considerations
In addition to performance issues, the ease at which business services components can be installed and upgraded on the client computers must also be taken into consideration. Ideally, corporations should be using a set of client computers with a limited number of configurations. For example, let's say a corporation buys only computer models V, VII, and VIII from Northwind Traders, and each of these models has only one standard software package installed. This means that there are only three possible configurations for the client computers. If you created a new business services component, you could test the installation process on one of each of the three computer models used by the corporation. If the component installs properly and none of the software that was originally on the computers is affected by the installation, there should be no problems with installing this businesses services component on all the client computers in the corporation. If you do run into installation problems, you could find the cause of the errors and change your installation techniques to fix them. In this type of controlled client environment, installing and upgrading a component on the client should be fairly easy. In brief, for the most part, the process of installing components onto the client can be greatly simplified by performing extensive testing. The installation of a new system onto a large number of clients (hundreds to thousands) using Microsoft Systems Management Server (SMS) could require up to six months of testing.
On the other hand, if a corporation has a wide range of unknown client computers, you could not use representative test computers to make sure that the new business services components would install properly on all the clients. Upgrading a component on these unknown clients could also result in problems. There are many possible solutions to this problem. For example, Norton Antivirus will check for updates to its virus-checking program at a set interval. When that interval is reached, a component will ask users whether they want to check for any updated components over the Internet. If any updates are found, they are automatically downloaded.
Components can also be installed in typical fashion over the Internet using .CAB files or using products such as SMS that can push components onto the client. Many techniques are available for getting the components onto the client. The major drawback with any technique is the possibility of dynamic link library (DLL) conflicts and a failure of the installation process.
As you can see, there are no standard answers as to the best location for business services components. The decision depends on the system that is being built, the configuration of the clients, the servers that are available, and so forth. Each decision usually requires the balancing of many factors.
We've now looked at several possible configurations for the logical components, and we've identified several ways of building scalable systems. This is what creating a model is all about: providing a framework that you can use to find the best way to construct your system.
It's time to get to work molding and shaping the DNA model to see just how far we can go with it. To begin, let's combine the two scenarios described earlier into an order entry application that works over the Internet. The user services components can be HTML pages in a Web browser. We can place business services components on the client computer that performs the CRUD validation. We can also place business services components on the Web server that builds the Web pages.
Now let's really extend this model. Our goal is to get the fastest performance from the user services components. If you could move some of the data into the client's memory and then use this data in memory as a data source, you could eliminate several trips to the data services components and the database. This can be accomplished in several ways. When you are working with Visual Basic, the usual way of transferring data over to the client is by using a Microsoft ActiveX Data Objects (ADO) disconnected recordset. The ADO disconnected recordset maintains a virtual table in memory; it does not maintain a connection to the database, which is why the name is "disconnected recordset." The full range of CRUD operations can be performed on the ADO disconnected recordset without making any connection to the database. If any changes are to be made to the database, the disconnected recordset can be sent back to the data services component. The data services component will then perform the update with the database and correct any inconsistencies. (Correcting inconsistencies during updates is another function of the data services components.) With ADO disconnected recordsets, correcting inconsistencies can be done only within a component, not in a stored procedure.
NOTE
For an example of a Visual Basic DNA system that works with disconnected recordsets and for a detailed description of UML, see Visual Basic UML Design and Development (published by Wrox, 1999) by Jake Sturm.There is another way of transferring data over to the client: by using XML. You can bring data over to the client in a Web application and create islands of XML data. This XML data can then be used as a local data source. If the user services components are HTML or XML applications running in Microsoft Internet Explorer 5, this will be fairly easy to do; the process is discussed in Chapter 13. If you use an XML data source on the client, you can also have business services components that communicate with the XML data source on the client. Communication with the middle-tier computers happens only when data needs to be retrieved or updated.
The Windows DNA architecture consists of a logical three-tier model and a physical three-tier model. These two models provide a framework that can be used to design and build your DNA systems. The models are extremely flexible and can be used for a wide range of systems.
In the next several chapters, we will look at how XML can be used in the three-tier model. You will learn how to create user, business, and data services components using XML. And you will learn how to use the BizTalk Server.
discuss this topic to forum
