Designing for Scalability with Microsoft Windows DNA

Designing for Scalability with Microsoft Windows DNA

by Sten Sundblad, Per Sundblad

Other Format


Product Details

ISBN-13: 9780735609686
Publisher: Microsoft Press
Publication date: 05/26/2000
Series: DV-MPS Designing Series
Pages: 450
Product dimensions: 7.37(w) x 9.19(h) x 1.28(d)

About the Author

Sten and Per Sundblad, father and son, jointly own ADB-Arkitektur, a Swedish company that teaches developers techniques for effective Windows DNA and client/server development in Microsoft environments, particularly COM+, Microsoft Transaction Server (MTS), Microsoft SQL Server and Microsoft Visual Basic.

Sten and Per Sundblad are among the top Regional Directors (recent award winners) in Microsoft's global RD program.

Read an Excerpt

Windows DNA is Microsoft's platform for the development of distributed applications. Figure 1-1 shows an architectural overview of a typical Windows DNA application. We produced this view of an application using Rational Rose 2000. The symbols that look like folders in Figure 1-1 are called packages. They are, however, Unified Modeling Language (UML) packages and not Microsoft Transaction Server (MTS) packages. An MTS package is a container for components. You install your compiled MTS components in MTS packages. So an MTS package is a physical thing in a computer, whereas a UML package is a logical container within a UML model of classes that helps categorize the classes of a model. (Note that in Microsoft Windows 2000 the term package has changed to application and MTS has been renamed Component Services.)

The broken arrows between the UML packages represent dependencies between the packages. Figure 1-1 shows that objects within the User Views package depend on objects within the Use Case Facades package for their functionality. In other words, objects in the former package will call objects in the latter package. Looking at Figure 1-1, you might notice even at this high level of abstraction how object oriented this architecture is. The model includes a UML package of set management classes and another of persistent entity classes. (We'll describe these packages in the "Business Services" section later in this chapter.) The architecture shown in Figure 1-1 is a good example of what an object-oriented purist would come up with. We'll show you examples of more scalable designs later in this book.

In the next section, we'll explain this figure. Then we'll take a step-by-step journey toward a complete description of a very efficient and much more scalable architecture for Microsoft Windows NT and MTS or Microsoft Windows 2000 and COM+ business applications.

Three Tiers-OR Five If You Like

The two vertical lines in Figure 1-1 divide the model into the three now well-known tiers:

  • User services

  • Business services

  • Data services

You can draw several benefits from using the three-tier model instead of the older two-tier model, often called the client/server model. In the two-tier model, clients are constantly connected to the database server, consuming resources such as server memory and processing time. If you consider the fact that a typical user spends much more time working with data locally than fetching from or updating the database, you can see that the two-tier model is wasteful. Clients shouldn't be allowed to hold on to resources when they aren't needed by the client. A large part of this book, spread over several chapters, deals with resource economy and how to achieve it, something that's much easier to do in the three-tier model than in the client/server model.

In Chapter 3, "On Rules and Their Locations," we'll talk about another benefit of the three-tier model. In short, this model allows you to use your favorite language to program your business rules without having to spread the rules around a multitude of client workstations. In the three-tier model, you place your business rules in a central application server, which makes it much easier to maintain and enhance them and also to reuse the same business rules objects in several applications. And that's what Internet applications are all about.

(If you want to read more about application architectures and their respective advantages and disadvantages, you should read Chapter 1 of Mary Kirtland's book Designing Component-Based Applications. You should read the whole book because it's filled with information interesting to anyone reading a book such as the one you hold in your hands right now.)

In the following paragraphs, we describe each of the three tiers of our architecture.

User Services

In Figure 1-1, the user services tier has one package only. According to this model, the package can contain different kinds of user services classes. Some of them might be instances of the new webclass in Microsoft Visual Basic 6.0. Others might be ordinary Visual Basic forms, dynamic HTML, or Active Server Pages.

Business Services

The business services tier contains four packages:

  • The first package contains facade classes. The purpose of these classes is to act as facades in front of the "real" business objects the user inter-face needs to communicate with. In Chapter 5, "Modeling the First Business Tier," we'll show you why facade classes are important and how they can help.

  • The second package contains persistent entity classes. It holds ordinary object-oriented business classes. Objects belonging to these classes have to save their data to a database before they allow themselves to be deactivated. Customer, Product, and Order are good examples of these types of classes.

  • The third package contains classes-set management classes-that are responsible for set-oriented operations. They might return recordsets and even handle set-oriented updates. They might also be stateful, managing collections of persistent entity classes, even if that should be considered optional. After all, stateful objects don't scale nearly as well as stateless ones do. We'll talk more about statefulness and statelessness in Chapter 8, "Designing the Main Business Tier." Later in this book, we'll combine the second and third packages into one. We'll modify them in other ways as well to increase their scalability.

  • The fourth package contains data access classes. The classes of this pack-age build SQL statements and stored procedure calls. These classes, and they alone, communicate (via ADO or the multidimensional version of ADO, ADO MD) with the database. This package also manages transactions. You should normally not allow classes other than your data access classes to support or require transactions. Classes in other packages should be free of that obligation.

Data Services

The third tier is the data services tier. In the model shown in Figure 1-1, the tier contains two packages:

  • An ADODB package that contains all the classes in ADO-Microsoft's strategic universal data library.

  • A database that could be anything you can access via OLE DB or ODBC. In the examples in this book, the database is Microsoft SQL Server, but it could just as well be an Oracle, an Informix, or a DB2 database.

This book also touches on the possibility of using data services from ADO MD and thus from the online analytical processing (OLAP) server available with SQL Server 7.0. You might be interested in accessing other kinds of data services as well: Lotus Notes and Microsoft Exchange Server are two prominent examples.

Five Rather Than Three Tiers

Many people prefer to divide the business services tier into three subtiers, thus creating a five-tier architecture.

  • The first of the three new tiers is the facade tier or, if you prefer, the application tier or the workflow tier.

  • The second is the main business tier.

  • The third is the data access tier.

An alternative tier division, using five tiers, would look like this:

  • User services

  • Business services

  • Facade services

  • Main business services

  • Data access services

  • Data services

One distinct advantage of dividing the business services tier into a facade tier, a main business tier, and a data access tier is this: the facade tier is more closely related to the user application than to the business logic, whereas the main business tier contains the actual business logic. Therefore, you should design the facade tier according to the requirements of a specific user application. You can also modify facade classes as the requirements of this application change over time.

Since the classes of the main business tier implement the business logic rather than any application-specific function, they must be designed for intensive reuse. Therefore, they must be extremely robust, and you shouldn't be allowed to modify them nearly as freely as the facade classes. Otherwise, you might very well make other applications impossible to run.

Thus, your facade tier isolates your user interface objects from the complexities of the main business tier. The facade classes might use the vocabulary of the user application, and they might present much easier programming interfaces than those that exist in the main business tier. Your gain is the added freedom to modify classes, easier development, and much easier maintenance and system enhancements over time. We'll talk about all these subjects at length in Chapter 8.

Likewise, the data access tier isolates the main business tier from the intricacies of the database. Furthermore, if you want to use the transactional services of COM+ and MTS effectively, separating data access from your main business objects is practically a necessity.

For the same reason, you should also use different classes for fetching data from the database and for inserting new or changed information. Separating transactional parts of a component from nontransactional parts is a sound practice, given the way in which both COM+ and MTS manage transactions. Figure 1-2 gives you an example, showing the data access classes package, which contains one fetcher class and one modifier class for the Customer persistent entity class.

We'll give you more details pertaining to this explanation in Chapter 12, "Delegating Data Access."...

Table of Contents

Chapter 2 Designing for Scalability..... 15
Chapter 3 On Rules and Their Locations..... 33
Chapter 4 Implementing the Rules..... 43
Chapter S Modeling the First Business Tier..... 81
Chapter 6 Reducing Time to Market..... 97
Chapter 7 Prototyping a DHTML User Interface..... 123
Chapter 8 Designing the Main Business Tier..... 133
Chapter 9 Using Separate COM Interfaces..... 145
Chapter 10 Implementing the Facades..... 165
Chapter 11 Making It Simpler..... 191
Chapter 12 Delegating Data Access..... 203
Chapter 13 Implementing the Managers and Data Access..... 211
Chapter 14 Using Microsoft Transaction Server..... 229
Chapter 15 A COM+ Overview..... 245
Chapter 16 Creating Some COM+ Components
Chapter 17 Securing Good Database Performance and Scalability..... 277
Chapter 18 Other Use Cases and Other Facades..... 297
Chapter 19 Heirarchical Recordsets-Pros and Cons..... 319
Chapter 2o An XML Overview..... 353
Chapter 21 XML with ADO 2.5 for Our Components..... 389
Chapter 22 What About the Business Rules?..... 403
Chapter 23 Some Final Issues..... 413

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews

Designing for Scalability with Microsoft Windows DNA 3 out of 5 based on 0 ratings. 1 reviews.
Guest More than 1 year ago
This book provides some good ideas and theory. However if you are just getting started with com, and component design, there is some other book out there that will give the necessary details to get started in thsi world of programming.