Developing XML Solutions (DV-MPS General)

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.

Buying, Reusing, or Building 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.

Locating Logical Components

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.

Extending the Windows DNA Model

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

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.