Deploy Multi Tier App

8/8/2019 Deploy Multi Tier App

http://slidepdf.com/reader/full/deploy-multi-tier-app 1/26

My favorite Seinfeld episode is the one that goes backward. If you’re aSeinfeld fan, you know which episode I’m talking about. It did not literally go backward—it’s not as though they reversed the videotape, resulting in

people talking and walking backward. Instead, the episode showed littlesnippets of different events, then showed the event before that one, and soon. The interesting thing about this episode was that you knew how theepisode was going to end. Knowing this information got your attention, and

you became curious to see how it was going to start. I wonder just how wellthe episode could have kept your attention if it had been played out in thetraditional fashion—from beginning to end?

This book will begin with an overview of what multi-tiered applica-tions are and how to deploy them. Naturally, deploying a multi-tieredclient/server application would be the final step in development. So why start there? The reason is that the methodology used to develop multi-tiered

applications is quite foreign to most developers, so I’ll present the develop-ment process backward, using a completed 3-tier application. This will help

you to see the benefits and challenges of developing applications using thismethodology. Like my favorite Seinfeld episode, I hope I can keep yourinterest by illustrating the ending, so that you become curious about thestart.

A word of warning before getting started: You’ll need to follow theinstructions presented in this chapter very carefully to be successful. Becausethese steps will have you modifying your registry, as well as creating newMicrosoft® SQL Server™ databases, it is imperative that you perform these

O N E

Deploying aMulti-Tiered

Client/Server

Application



2 Chapter 1 • Deploying a Multi-Tiered Client/Server Application

steps on a development machine that does not perform a critical function. You should back up your system(s) before proceeding with these steps.

Application Architectures

The industry now recognizes three distinct architectures for applicationdevelopment. What the industry fails to agree on, however, is exactly whatconstitutes each type of architecture. In Microsoft circles, there are generally considered to be three types of architectures: desktop, 2-tier, and 3-tier.

Desktop Application Architecture Overview

The term desktop architecture is applied to most legacy applications, whichare completely self-contained and, therefore, monolithic. In a desktop archi-tecture, all layers exist on the client machine, including the database itself, asshown in Figure 1–1. When the database is remote, the application is nolonger considered to be a desktop architecture and is probably considered a2-tier architecture.

Desktop application architectures are monolithic. A singleapplication contains user interface, business, and databaseaccess logic. The database is local.

Many, if not most, of the applications that use the desktop architecturedo not have a clean separation between the traditional layers of an applica-tion. These layers include the user interface, business logic, and database

access logic layers. The less distinction between these layers, the more diffi-cult it is to convert the desktop application to any type of distributed appli-cation architecture.

2-Tier Application Architecture Overview

An application that accesses a remote database is, at a minimum, a 2-tierarchitecture. The database can be accessed by any client/server database

API, such as ActiveX Data Objects (ADO), Remote Data Objects (RDO), theOpen Database Connectivity (ODBC) API, and others (see Figure 1–2).

FIGURE 1–1

APPLICATIONUser Interface Logic

Business LogicDatabase Access Logic

DATABASE



In a 2-tier architecture, the database is remote, but thebusiness and database access logic still reside on theclient, along with the user interface code.

Converting a desktop application to a 2-tier architecture can be easy. Infact, with all mentioned database access APIs (ADO, RDO, ODBC), the con-

version may be as simple as modifying the attributes of a data source toenable the application to access a remote database instead of a local one.This fact contributes to one source of confusion regarding the classificationof distributed applications—is a “2-tier-capable” application considered to bea desktop architecture when the database is deployed locally? In other

words, does the term n-tier apply to a logical model or to a physical(deployment) model? Experts disagree on this issue. However, as distributedarchitectures become more commonplace, a growing number of developersare beginning to consider the term n-tier to apply to the logical model, andthat is the working definition for this book. For example, all components,including the database, of a 3-tier application can be deployed on a singlemachine. Implementing such a deployment plan does not make your appli-

cation a desktop architecture, because it is capable of being deployed in adistributed environment.

3-Tier Application Architecture Overview

An additional layer between the user interface and the database will makesuch an application a 3-tier architecture (see Figure 1–3). This middle layer isoften referred to as the business rules or business logic, and this layer is typi-cally deployed on the server, along with the database.

FIGURE 1–2


Business LogicDatabase Access Logic

DATABASE

SERVER

ADO/RDO/ODBC

Application Architectures 3




In a 3-tier architecture, business and database access logicare separated from the user interface and can be deployedon the server.

Because the Visual C++® MFC/AppWizard development environmentmakes it easy to develop dialog-based applications with event proceduresthat are invoked as a side effect of user interaction with controls, many exist-

ing C++ applications can be difficult to move to a 3-tier model.The 3-tier architecture proposed by many experts suggests placing

business logic and database access logic together in a separate componentthat is deployed on the server and remotely accessed from the user interface.

Although any type of remote communication may be used between the userinterface and the server, including TCP/IP sockets, named pipes, networkDDE, and others, the best approach is to use the Distributed ComponentObject Model (DCOM). Furthermore, it is best to use DCOM via MicrosoftTransaction Server (MTS), which provides a superior environment overDCOM utilities in terms of deploying and monitoring server-side objects, as

well as a run-time environment for managing objects, pooling database con-nections, managing security, and coordinating distributed transactions.

Clearly, in the 3-tier architecture, an additional potential bottleneck hasbeen introduced between the user interface logic and the business logic— the network. In effect, one bottleneck has been traded off for another. The3-tier model gains performance from processing data where it resides. Thatis, by moving the business logic over to the database server, less data mustbe moved from the client to the server. However, communication betweenthe user interface and business logic has now gone remote. Depending onhow much communication is required between the user interface logic and

FIGURE 1–3


DATABASE

ACTIVEX COMPONENTBusiness Logic

Database Access Logic

ADO/RDO/ODBC

DCOM

SERVER



the business logic, the performance gain from processing the data locally may be washed away by the resulting increase in network round trips.

The solution to this problem is to design objects in the middle layer tobe stateless. Unlike traditional objects, stateless objects cannot have persis-tent properties. Typically, such objects have only methods (functions), whichmust declare sufficient parameters to accomplish a given task in a singlefunction call. In this scenario, state is held in the client until sufficient infor-mation has been gathered from the user interface, at which time a method isinvoked on an object in the middle layer. Although the use of this techniquecan result in a more scalable application, invoking methods with numerousparameters is undesirable to many programmers, especially those schooledin good object-oriented design techniques. This dilemma, along with a solu-tion, is discussed in further detail in the following section.

N-Tier Application Architecture Overview

If yet another layer is inserted between the presentation layer and the data-base, would one then have a 4-tier client/server architecture? Such a questionis perfectly valid and illustrates how the terminology has gotten out of hand.In general, the industry has adopted the term n-tier to refer to a new architec-ture in which layers of an application are cleanly separated and accessed via

well-defined interfaces. Therefore, you are not likely to encounter the term 4-

tier in much of the technical literature describing distributed applications.I bring up the issue of 4-tier architectures because there is a tremendous

amount of controversy surrounding the 3-tier architecture, mainly concerningthe stateless nature of the objects in a 3-tier architecture’s middleware. Theconcept and importance of stateless objects is discussed throughout thisbook, beginning with this chapter. I will mention at this point that statelessobjects are objects with no properties (attributes). Stateless objects have only methods (functions), and these functions often have a far greater number of parameters than properly schooled object-oriented programmers are com-fortable with. Stateless objects are designed primarily for Internet- orintranet-based client applications, in which the presentation layer, or userinterface, runs within a web browser.

In this book, I present an approach to distributed application develop-ment, which considers both Internet/intranet clients and Win32 clients (seeFigure 1–4). In using this approach, I suggest that Internet/intranet presenta-tion layer clients use the stateless objects of the business rules layer (alsoknown as the data services layer ). In-house Win32 presentation layer clientsuse an object model, which consists of stateful objects and acts as a thinlayer of object-oriented code over the stateless objects in the business ruleslayer. Because I have introduced yet another layer between the presentationlayer and the database, one may suggest that this book presents a 4-tierarchitecture. However, I would prefer to think of the object model as anextension to a Win32 client application’s presentation layer.





The 3-tier architecture, with client-side object model, is themodel used in this book.

About 2-Tier Client/Server Applications

In a 2-tier client/server application, database access is from the client side ,either directly from the presentation layer (user interface), or via an object

model, if present (see Figure 1–5). The object model is typically distributedon the client side because its objects must hold state. In general, code thatexists between the presentation layer and the database is referred to asmiddleware , although many client/server developers apply this term only to 3-tier client/server applications, but this is not correct. The term middle-

ware applies to any layer of custom software that exists between the pre-sentation layer and the database.

In a 2-tier client/server application, the presentation layeraccesses the database via an object model , which in turn

accesses a database API, such as ADO.

FIGURE 1–5

FIGURE 1–4

MTS

WIN32 APPLICATION

DATABASE

ACTIVEX COMPONENTData Services Layer(Stateless Objects)

ADO/RDO/ODBC

ACTIVEX COMPONENTObject Model

(Stateful Objects)

INTERNET APPLICATION

DCOM

IIS/ASP

SERVER



To access the database, the presentation layer or client-side middleware typically uses a remote database API or set of objects that encapsulatea remote database API, as in the set of interfaces provided by OLE DB or theobjects, properties, and methods of ADO. In the logical model of 2-tierclient/server applications, there are the presentation and database layers.Business logic is deployed client-side in a 2-tier architecture, either directly in the presentation layer or in a client-side object model.

As the diagram shown in Figure 1–5 suggests, code in the presentationlayer does not have to access an object model. Instead, code to carry outbusiness logic can be contained in one application, which implements boththe user interface logic and business logic. However, this is not recommend-ed, because the key to a successful distributed application lies in the separa-tion between the layers of logic: user interface, business logic, and database

access. The role of the object model in a 2-tier client/server architecture isboth to implement the business rules and to provide database access to thepresentation layer. Note that this is not the case in a 3-tier architecture,

which uses a client-side object model to provide an object-oriented encap-sulation of the stateless server-side business objects; the object model in a3-tier architecture does not normally implement the business logic. Thisissue is discussed in greater detail later in this chapter.

In a 2-tier architecture, client applications are somewhat monolithic,although not entirely so. Because the database is remote but the businesslogic is contained on the client side, such applications are considered 2-tier.Had the database been located on the same machine as the code imple-menting the presentation and business logic layers, the application wouldhave been considered to be a desktop architecture.

Applications developed according to the 2-tier model may use storedprocedures defined in the database. Such stored procedures may be simpleor complex; in fact, many database designers come close to implementingbusiness logic in stored procedures. Strictly speaking, however, applicationsthat access remote databases via stored procedures are still considered to bea 2-tier architecture.

Physical Deployment of 2-Tier

Client/Server Applications

In the physical model, which specifies how the components of theclient/server application are deployed, you have the option of deployingboth the presentation layer (or user interface) and the object model (which,in a 2-tier architecture, implements the business logic) client-side.

Alternatively, you can deploy the presentation layer client-side and deploy the object model server-side, preferably on the same machine as the data-base(s). Because the object model consists of stateful objects, it is recom-mended that it be deployed on the client machine, along with the presenta-





tion layer. This will minimize the number of network round trips. Strictly speaking, of course, there does not have to be an object model, in whichcase, there is only the user interface, which can directly access the database

via a remote database API, such as OLE DB or ADO.Deploying stateful business objects on a remote machine has advan-

tages in the way of maintenance. As for performance, it is generally accept-able for modest (under 100 clients) work loads, although this, of course,depends on the nature of the objects.

Many developers disagree on what is considered a 2-tier model. Many experts suggest that the tiers refer to physical deployment. If you accept thisdefinition, the model discussed here would be considered 2-tier when thepresentation layer and the object model layer are deployed on the samemachine (with a remote database). The same logical model would be con-

sidered 3-tier (according to this interpretation) when the object model layeris deployed on the server. The correct interpretation is to consider the tiersas referring to a logical model. An application follows the 2-tier client/serverarchitecture if the presentation layer accesses a remote database, eitherdirectly or via an object model that does so directly.

About 3-Tier Client/Server Applications

In the 3-tier client/server architecture, neither the presentation layer nor theobject model implements business rules, nor does either directly access thedatabase. Instead, business logic and database access is implemented in yet

another tier. This tier is commonly known as the business rules layer ,although many developers, including myself, prefer to apply the term data

services layer to this tier (see Figure 1–6). Objects in the data services layer

In a 3-tier client/server application, the object modelaccesses the database via the data services layer, whichconsists of stateless objects.

FIGURE 1–6



are generally transactional and stateless, and are designed according to therequired transactions of the business. Examples from the Video Store casestudy presented in this book include renting videos, returning videos,signing in new members, and so on. Although it is certainly possible (andgenerally recommended) that the objects in the data services layer usestored procedures defined in the database, in many ways, the methods of these objects are, in a manner of speaking, advanced stored procedures.Creating transactional code in a language such as Visual C++ or Microsoft

Visual Basic® (VB) provides you with a much richer set of features than theSQL language can provide. Additionally, data services layer objects, whendeployed with Microsoft Transaction Server (MTS), can take advantage of just-in-time activation and connection pooling, two features that considerably improve the scalability of a multi-tiered client/server application.

Because methods of objects in the data services layer must be statelessto ensure scalability, it is not unusual for their methods to contain an unusu-ally large number of parameters. This is why it is an excellent idea to wrapaccess to the data services layer with a thin layer of object-oriented code— this is the purpose of the object model. Only Win32 clients use the objectmodel. Internet clients, which have a browser-based presentation layer, mustuse only the stateless objects of the data services layer—this ensures properscalability and, when combined with ASP and IIS technologies, can eliminatethe need for downloading custom components to the client.

The 3-tier model provides the greatest amount of flexibility in deploy-ment. Applications (actually presentation layer “front-ends”) can be writtenthat either directly access the database, directly access the data serviceslayer, or directly access the object model layer. With proper design, all typesof front-ends can, and should, coexist without interference.

I should reiterate that, for Internet-based (browser-hosted) applications,using the object model layer is generally inappropriate. Browser-based appli-cations should use the data services layer, whereas “in-house” applications(written as Win32 clients in, for example, VB or Visual C++) should use theobject model layer. The reason for this is that objects in the object modelhold state and should, therefore, be deployed on the client side. This isclearly inappropriate for Internet applications. However, the possibility exists

for the development of efficient intranet applications that use a client-sideobject model, because broad-reach capability is often not as critical an issue

with intranet applications. Technologies such as ASP, VB, and JavaScript(JScript/ECMA Script), Dynamic HTML, and ActiveX Controls/Documentsprovide rich development environments for intranet applications that will beaccessed from Microsoft Internet Explorer.





Physical Deployment of 3-Tier Client/Server Applications

To physically deploy a 3-tier client/server application, the data services layer

is installed on the same machine as the database(s), whereas the objectmodel is installed client-side, along with the Win32 application(s) in thepresentation layer.

For proper scalability, only stateless objects can exist in the dataservices layer. Stateless objects contain virtually no properties (other thanperhaps read-only or constant properties), and their methods must be ableto run to completion without retaining state. Objects in the data serviceslayer are typically deployed using MTS. In addition to providing utilities todeploy and monitor objects, MTS provides an excellent run-time environ-ment that developers use to create scalable objects that use just-in-time

activation and database connection pooling. Microsoft Transaction Server isintroduced in Chapter 7, and an in-depth case study of MTS components ispresented in Chapter 8.

About the Object Model

Most literature and courseware covering multi-tiered application developmentfocus entirely on Internet clients with user interfaces hosted in a web brows-er. Such literature proposes the development of n-tier client/server applica-tions using only a presentation layer and a data services layer. Typically, thedata services layer is referred to in such documents as the business rules orbusiness logic layer. However, a growing number of developers is beginningto realize that many of us have forgotten a tier: the object model.

Examine any reference on 3-tier client/server applications and you’llsee countless examples of objects that have methods with well over a dozenparameters. Any good programmer will recognize that this as a bad idea and

will suggest breaking such methods into smaller methods that can besequentially invoked by the caller or by adding properties that have conve-nient default values that can be referenced by the called methods. However,

when the object is hosted remotely, calling methods and accessing proper-ties involves network round trips. Furthermore, data structures for holdingproperties of objects always reside with the object, which means that remote

objects with properties must hold their state on the server. Such an imple-mentation will not scale to a large number of clients. This situation has givenrise to a new type of object, the stateless object.

Can an object be stateless and still be an object? If you’ve been throughthe traditional schooling of object-oriented design , you’ll agree that it cannot.

You have undoubtedly been taught that objects have both attributes andbehavior, which translate to properties and methods, which translate to dataand code. All objects in real life have both state and behavior. For example,my dog, Pepper, has a weight, which is one of his properties (or state), and



can speak on command, which is like a method. Pepper is an object, specifi-cally, an instance of a dog class object.

If you approach many experts on scalable multi-tiered applications andcomplain about the use of stateless objects, you will be branded as an“object-oriented purist.” You may additionally be told that object-orientedprogramming does not scale. However, there is a common ground, and it isan excellent approach to client/server application development. Theapproach is to develop presentation layer clients that use a client-side objectmodel that consists of stateful objects whenever possible, as in, for example,

Win32 clients. Code in the object model is primarily just a thin layer of object-oriented code over the stateless objects in the data services layer.Internet-based presentation layer clients will directly use the stateless objectsin the data services layer. This is the approach presented in this book.

A point of objection for many developers in using an object model isthat it will complicate the distribution of applications, because the objectmodel must be distributed on the client side. To counter this objection, letme first state that it is not essential to distribute the object model on theclient machine. You can deploy a single copy of the object model on a serv-er and use DCOM to deploy it. For a small (i.e., departmental) work load,this deployment technique works well. However, this point is moot becauseusing an object model does not really complicate the distribution of anapplication. Whereas it is true that you should create a single setup programthat distributes both the object model and the Win32 presentation layerclient (typically, a VB standard executable or a Visual C++ MFC dialog-basedapplication), this is not difficult to do. Let me also counter this objection

with another point. If your Win32 clients directly use the stateless objects of the data services layer, consider the impact of changing one of those meth-ods that require over a dozen parameters (and you will have to). If you usean object model to wrap the methods of the data services layer, you’ll gener-ally have far fewer places in your code that you’ll have to change. So usingan object model that consists of stateful objects can actually make it easierfor you to maintain your software.

THE OBJECTS OF THE OBJECT MODEL

Objects in the object model are traditional in the object-oriented design sense. A properly designed object model consists of both concrete and abstractobjects, and should represent the results of a thorough object-oriented analy-sis. The same cannot be said for stateless objects in the data services layer,

which cannot be discovered and designed using traditional object-orienteddesign techniques.

Traditional object-oriented design techniques often initially involve ananalysis to discover the objects of the so-called problem domain. Onceobjects are discovered, their properties and methods are typically identified.





Of course, this approach is iterative and varies according to the methodol-ogy used and its degree of formality. Regardless of the approach, however,the resulting set of objects is often quite concrete, each having real-worldcounterparts. For example, an object-oriented analysis of the Mom-n-Pop

Video Store requirements reveals objects, such as Video and Member , andcollections, such as Videos and Members . Abstract objects, which typically have no real-world counterparts, are also identified with object-orientedanalysis. For example, analysis of the Mom-n-Pop Video Store requirementsmay reveal such objects as Categories and LateCharges .

A major point to emphasize regarding objects in the object model isthat they are identified with a high-level analysis of the business. Low-levelimplementation details are typically not considered in designing an objectmodel. For example, whether or not the Mom-n-Pop Video Store uses an

SQL Server database or an Oracle database is not a consideration in objectmodel design. Regardless of the type of database used or its schema, theMom-n-Pop Video Store has members that rent and return videos. The busi-ness rules of the video store can be described independently of the imple-mentation of any automated approach to running the business.

STATELESS OBJECTS COMPARED WITH STATEFUL OBJECTS

Traditional object-oriented design technologies fail when applied to thedesign of the stateless “objects” of the data services layer. Proper design of stateless objects requires an approach I like to call composition through

decomposition.Most of the programmers from my generation originally mastered a

design technique known as functional decomposition. Basically, thisapproach involves taking a complicated problem (designing a large system)and breaking it down into smaller, easier-to-solve problems—breaking a sys-tem down by fundamental functions. The result is ultimately a set of func-tions and their parameters, which were designed, specified, and documentedprior to their development. This approach was the first to emphasize inter-faces—this emphasis is even more important today, as developers createapplications that make remote procedure calls to functions implemented inexternal processes that may even be executing on a remote workstation.

Functional decomposition is required in designing stateless objects,because it identifies what functions (methods) will be required on the serverto support the services promised to the presentation layer and object model.

A significant difference in functional decomposition when applied to design-ing stateless objects is to bear in mind always that the function must be ableto be implemented without saving state. Presuming a sequence of callsand/or making use of global data must be avoided.

Once the fundamental set of functions has been identified, the objectscan be defined. Note that this is not consistent with traditional object-orient-ed design, which requires that objects be identified first. This is why I call



this approach composition through decomposition. First, you define the func-tions, then you find a way to group those functions into “objects.”

Grouping stateless methods into objects is really done only for packag-ing convenience. Naturally, one looks for common functionality first, but thisis not really the primary factor in designing stateless objects—you must alsoconsider the transaction and security attributes of each function. Because of the way that MTS implements transaction and security services, you must becareful how your methods are grouped into objects. For example, when anobject is deployed under MTS, you must indicate whether or not the object,and not its individual methods, requires a transaction. If an object requires atransaction, all of its methods will run under a transaction. There are similarconcerns with security attributes, although these can be applied on amethod-by-method basis.

BENEFITS OF AN OBJECT MODEL

An object model provides several benefits:

s The object model provides an object-oriented encapsulation of access-ing the business rules, resulting in a much easier interface than thatprovided by the stateless objects running under MTS.

s The object model is a convenient place to cache information client-sideuntil sufficient information exists to invoke a method on the server.

s The object model can implement frequently used business logic for thepurposes of improving performance. This includes simple but often-executed validation rules.

It is significant that the object model provides an object-orientedabstraction of the business logic (although it does not actually implement thebusiness logic). Most businesses do not change their business rules thatoften. There are many examples of businesses that have been in existencefor decades—from the point of view of their customers, there is often noapparent difference in how such businesses carry out their business,although successful ones usually become more and more efficient. Also,most businesses become more efficient not by changing their business rulesbut in how such rules are automated. At any given moment, businesses areconverting from this database to that one, from this operating system toanother, and so on. The object model can provide uniformity to presentationlayer clients. As implementations change, the object model can be adjustedaccordingly.

Building a Suite of Applications

Application development today consists of the development of several pro-grams, really a suite of programs that, taken together, define an application.

We are past the days of creating monolithic applications that do everything.





Today, using a modular, n-tiered approach to application development, wecan create Win32 clients with rich user interface features while we alsodevelop broad-reach browser-based front-ends for globally distributed appli-cations. Not all of these applications need to be scalable, but they can, andshould, share common code whenever possible (see Figure 1–7). For exam-ple, there is no need for the Mom-n-Pop Video Store application (presentedlater in this chapter and throughout this book) to be able to support thou-sands of users of the point-of-sale application , which is used in-house by aclerk when videos are rented by members of the video store. However, theMom-n-Pop Video Store application also has several Internet-based front-ends so that members (and potential members) can browse the database of available videos. If, in the future, the Mom-n-Pop Video Store applicationneeds an Internet-based front-end for renting videos, that user interface will

need to use the scalable objects in the data services layer.

A properly designed n-tier architecture permits entry by user interface applications into the appropriate tier.

FIGURE 1–7



Reiterating, the Mom-n-Pop Video Store application presented in thisbook is actually a suite of applications, most written using Microsoft VisualC++, but a few of which are written in VB. The most visible application inthe suite is the point-of-sale application, which is used in-house at the videostore. As a Win32 client application, it uses the object model to carry outactions entered by the user. Technically, the point-of-sale application is apresentation layer application and is a client of the object model, which, inturn, is a client of the data services layer. In Chapter 5, I will show you howto create an object model.

Another Mom-n-Pop Video Store application presented in this book isan Internet presentation layer client that uses Active Service Pages (ASP),

which is discussed in Chapter 9. As you can see, presentation layer clients can use either the object

model interface or the data services layer interface. However, these are notthe only options. Some client applications will continue to access the remotedatabase directly through a remote database API, such as ADO. In the Mom-n-Pop Video Store suite of applications, for example, there is a reportingapplication (written using VB and ADO) that creates a report of rented

videos. Database reporting and maintenance applications do not need to useeither the object model or data services interfaces.

Separating the traditional components of an application—user inter-face, business logic, and database access—has a number of advantages.Code is reused to its maximum potential, and the application can scale to alarge number of users.

WIN32 PRESENTATION LAYER APPLICATIONS

A Win32 presentation layer application is a client application written specifi-cally to run on a Windows platform. Such applications can use the rich userinterface features of Windows, including common controls, such as the list

view and tree view controls. A Win32 presentation layer client’s entry pointinto a distributed application should be via the object model, which is oftendeployed client-side to keep state management away from the server.

In the Mom-n-Pop Video Store suite of applications, the point-of-saleapplication (UI.EXE ), written as an MFC dialog-based application using theMFC AppWizard, is the most important Win32 client. This application andany other Win32 presentation layer clients enter into the distributed architec-ture via the object model (see Figure 1–8).





The point-of-sale program is a Win32 presentation layerclient, entering into the distributed application via theobject model.

BROWSER-BASED PRESENTATION LAYER APPLICATIONS

Because presentation layers hosted in Internet browsers may reach a muchlarger number of users and because such clients may run on many differentplatforms, this type of application enters into the distributed application viathe stateless objects in the data services layer. A presentation layer client

written for a browser may use ASP or can be written using InternetInformation Server Application Programmer Interface (ISAPI) extensiondynamic link libraries (DLLs) (see Figure 1–9). In Chapter 9, I will explainhow to develop ASP applications.

DATABASE REPORTING AND MAINTENANCE APPLICATIONS

There is little motivation for encapsulating tasks related to database mainte-nance and reporting into objects in either the object model or data serviceslayer. Such applications can be written according to the 2-tier architecture,coexisting with Win32 and browser-based clients.

For example, the Mom-n-Pop Video Store suite of applications includesan application that produces a daily report of rented videos (see Figure1–10). This application is written in Visual Basic and is discussed in detail inmy first book, Distributed COM Application Development Using Visual Basic

6. The application, including all of its source code, is included with the CD-ROM that accompanies this book.

FIGURE 1–8

MTS

POINT-OF-SALE(UI.EXE)

VIDEO STOREDATABASE

MOM-N-POP DATASERVICES LAYER(MPVCSVR.DLL)

ADO

MOM-N-POP OBJECT MODEL(MPVCOBJ.DLL)

DCOM

SERVER



A browser-based presentation layer client uses ActiveServer Pages, which bypass the object model and directly

use the stateless objects in the data services layer.

Win32 report generation and database maintenance appli-cations do not need to use either the object model or dataservices layer. They can simply use ADO, effectively mak-ing them a 2-tier architecture.

FIGURE 1–10

MOM-N-POP REPORTINGAPPLICATION

(DAILYREPORT.EXE)

VIDEO STOREDATABASE

ADO

SERVER

FIGURE 1–9

MTS

BROWSER

VIDEO STOREDATABASE

MOM-N-POP DATASERVICES LAYER(MPVCSVR.DLL)

ADO

HTTP

IIS/ASP

MOM-N-POPWEB SITE

SERVER





The Legacy Systems of Tomorrow

As a Microsoft Certified Trainer and Solution Developer , I often joke with my

students that they are creating the legacy systems of tomorrow. This generatesan interesting reaction, due to the stigma associated with the term, at least

when applied to software systems. However, it seems that it is only in ourindustry that legacy is a bad word. For someone whose career is in sports, forexample, to be called a legacy is an honor. The same should be true of lega-cy systems. If you think about it, a legacy system has stood the test of timeand clearly must have provided immeasurable value to a company to survivelong enough to be called a legacy system. Although today’s software must bedesigned to withstand change, I certainly hope that you don’t plan to discardthe systems you are developing today any time soon.

I conclude from my own analysis and experience that the best modelof client/server application development is the one that I present in thisbook. You must design a normalized and efficient database that contains effi-cient stored procedures that can be accessed directly with ADO for databasemaintenance and reporting programs. On top of this tier, you must design astateless and scalable set of objects with methods that can be accessed by browser-based applications driven by HTML and scripting languages, using

ASP and/or other server-side technologies. On top of this tier, you mustdesign a set of stateful objects that provides an elegant abstraction of yourbusiness model and that simplifies the interface to the data services layer.Finally, for your “in-house” Win32 clients, you must use a language such as

VB or Visual C++ with MFC to easily access the rich, native user interface fea-tures provided by the Windows operating system. This approach to softwaredevelopment scales from small to medium to large applications and providesa growth path for future development. Such systems will be the legacy sys-tems of tomorrow, except that we will, perhaps, by then have learned thatthat is, after all, a compliment to the original designers of the system.

Deploying the Sample Application

In the following sections, I will guide you through the installation of thesample multi-tier application included with this book. The application wasdesigned and developed for a fictitious company, the Mom-n-Pop VideoStore. It is written completely in Microsoft Visual C++ using ATL and MFCand is moderate in size—large and complete enough to include examples of

virtually every aspect of an n-tier architecture application. The steps that fol-low will be similar, if not identical, to the steps that you will follow once

you have completed your n-tier application.



Deploying a 3-Tier Client/Server Application

The Mom-n-Pop Video Store application requires MTS, Internet Information

Server (IIS), and SQL Server, in addition to the custom software provided onthe accompanying CD-ROM. The following steps assume that you will installthe data services layer and the database on one machine and the presenta-tion layer and object model on another. As an overview, you will first installthe server-side components:

1. Restore the SQL Server Database on the server machine.

2. Create a Data Source Name (DSN) on the server machine if the dataservices layer requires one.

3. Using the MTS Explorer Utility , create a package for the data services

layer.4. Install the data services layer components into the package created in

the previous step.

5. Export the package to create a client setup program. Make sure thatthe client setup executable is located on a shared directory, accessiblefrom the client machines.

Next, you’ll deploy the client-side components. The following is anoverview of the steps involved:

1. Install and register the object model.

2. Run the client setup program that you created from step 5 above.

3. Install the presentation layer application(s)

Deploying the Mom-n-Pop Video Store Application

Included with this book is a 3-tier version of the Mom-n-Pop Video Store, which uses an SQL Server database. The instructions that follow assume that you will be installing the database and the data services layer (using MTS) onthe server. Refer to the README.TXT file on the CD-ROM for information about

where to locate these files and for the latest information regarding installation.

CREATING THE SQL SERVER VIDEO STORE DATABASE

The batch file MKVSDB.BAT , located in the Database folder under Demos ,creates the Mom-n-Pop Video Store sample database for Microsoft SQLServer (version 6.5 or later, including version 7.0 of SQL Server). The batchfile uses the isql and bcp utilities to create and populate the database. To runthe script, after copying the VCENT directory to your hard drive, open an MSCommand Prompt window and set your default directory to theVCEnt\Database directory. Then execute the batch file MKVSDB.BAT , sup-

Deploying the Sample Application 19




plying the username and password of the administrator account for SQLServer. For example, to install the database using the username of SA and nopassword, use:

cd c:\vcent\database

mkvsdb sa

To install the database using the username SA and the password PASS123, use:

cd c:\vcent\database

mkvsdb sa pass123

CREATING THE DSN ON THE SERVER FOR THE 3-TIER VERSION

The Mom-n-Pop data services layer uses a hard-coded DSN of SQLVideoStore , which must be created on the server machine, using the fol-lowing instructions:

1. Start the ODBC Data Source Administrator from the Control Panel .

2. Select the User DSN tab. Select SQL Server and click the Add button.

3. In the resulting Create a New Data Source dialog, enter SQLVideoStorefor the name. Select the proper server (local), then click Next .

4. Click Next (use defaults for authentication).

5. Check Change the default database and choose VideoStore . Then click Next .

6. Click Next (use defaults for translation and regional settings).

7. Click Finish (use defaults for the final screen).

8. It is recommended that you click the Test Data Source button in thelast screen.

9. Exit the ODBC Data Source Administrator .

CREATING THE MTS PACKAGE

Data services layer objects are typically deployed in an MTS Package. I’ll dis-cuss exactly what these are and what they do in Chapter 7. The followingsteps take place on the server. Once accomplished, you’ll have installed thedata services layer components on the server. The next step will be to gener-ate a setup program that can be run from the clients. To create the MTSpackage used by the Mom-n-Pop data services layer components:



1. Start the MTS Explorer utility from the NT Option Pack program groupand expand Microsoft Transaction Server , Computers , My Computer ,then Packages Installed .

2. Select Packages Installed by clicking it with the left mouse button.Then right click on Packages Installed and select New , then Package .

3. Click the Create an Empty Package button. Enter Mom-n-Pop as thename of the package, then click Next .

4. Click Finish (use defaults for package identity).

5. Under Packages Installed , expand Mom-n-Pop.

6. Under Mom-n-Pop, select Components by clicking it with the leftmouse button. Then right click on Components and select New , thenComponent .

7. Click the Install new components button.

8. Click the Add Files button, then navigate to and select MPVCSVR.DLL,located in the Mpvcsvr\ReleaseMinSize folder under \Demos\MomPop.

9. Click Finish.

GENERATING A CLIENT INSTALL PROGRAM

Microsoft Transaction Server makes it easy to perform the required client-side setup. Using the Export feature of MTS, you can create an executable

that clients can run to set up for server access. The following steps also takeplace on the server:

1. Back in the MTS Explorer utility, select the Mom-n-Pop package by clicking it with the left mouse button, then right click on Mom-n-Pop

and select Export .

2. In the resulting Export Package dialog, enter (or browse to) a file spec-ification for the exported package. Be sure that it is in a shared folderso clients can get to it. Call the package VSPackage .

3. Click the Export button.

CLIENT-SIDE SETUP FOR A 3-TIER APPLICATION

You will be installing both the presentation layer and the object model onthe client. The object model for the 3-tier version of the Mom-n-Pop VideoStore is already built and located in the file MPVCOBJ.DLL, which is locatedin the Mpvcobj\Debug folder under \Demos\MomPop. You need to registerthe server by issuing the following command from the Run dialog:

regsvr32 \VCEnt\Demos\MomPop\Mpvcobj\Debug\MPVCOBJ.DLL





To set up for remote access to the data services layer components, youmust also run VSPackage.EXE , located under the Clients subfolder, in thefolder into which you placed the exported package during the previous step:

1. Register the object model component on the remote client machine, asdiscussed above.

2. Run the VSPackage.EXE program, located in the Clients subfolder inthe folder into which you placed the exported package.

RUNNING THE APPLICATION

Once you’ve followed the previous steps, run the program UI.EXE fromthe \UI\Release folder under \Demos\MomPop. Some tips on using the

application:

1. You can search by a member’s last name or member ID. The membersof Mom-n-Pop Video are actually taken from the employees of the

Northwind Traders Database (i.e., Davolio, Leverling, etc).

2. Member IDs range from 12000 to 12009.

3. To search by last name, enter any part of a last name that matches.

4. You can search by a video’s title or ID. Videos include such (once)popular titles as Airplane , Forest Gump, and Maverick .

5. Video IDs range from 52000 to 52028. There are initially 20 copies of each video available for rental.

6. All videos can be rented for three nights at a price of $2.00. The latefee is $1.00 per night.

7. A feature is provided for advancing the date ahead to test late charges,etc. When you use this feature of the program (discussed shortly), youare not changing your system clock.

RENTING VIDEOS

Next, you should rent three videos to member Nancy Davolio, using the fol-lowing instructions:

1. Click the Rent Videos button.

2. For Member ID , enter 12001, then click the Find Member button (orpress Enter ).

3. For Video ID , enter 52000 and enter 1 for Copy No. Then click the Rent

Video button.

4. Repeat the above step twice, renting 52001 and 52002. Select copy 1for both videos.



5. Click the Finish button. Click OK to dismiss the Point of Sale dialog(see Figure 1–11).

Follow the instructions to rent three videos to memberNancy Davolio.

ADVANCING THE SIMULATION DATE

The Mom-n-Pop Video Store program has a feature to advance the date forsimulation purposes. When this feature is used, it does not actually advance

your system’s date. When the application starts, it sets “today’s” date as thelatest of either the latest due date in the Rentals table or the latest returneddate in the LateCharges table. If no records exist in either table, “today’s”date is set to the actual date.

At this point, you should advance the simulation date by five days toexperiment with late charges handling. This is done as follows:

1. From the main window, select the Date button.

FIGURE 1–11





2. Select a date that is five days ahead of the simulation date (see Figure1–12).

3. The caption of the main window should indicate the new date.

The Mom-n-Pop Video Store program has a feature thatallows you to advance the date to test late charges.

RETURNING VIDEOS FROM THE DROP BOX

Assume that Nancy Davolio returns her videos (now several days late) by dropping them off at the desk as she shops for some new videos to rent.Processing the returns would be as follows:

1. From the main window, select the Return Videos button.

2. Make sure that the Return From option is set to Desk (see Figure1–13).

FIGURE 1–12



Customers can deposit returned videos in the drop box orat the desk when they rent new videos.

3. Enter each video ID and copy number, selecting the Return button foreach. Recall that Nancy Davolio rented videos 52000, 52001, and

52002, all of which were copy number 1.4. Select the Close button when finished.

COLLECTING LATE CHARGES

Now, perform the following steps to allow member Nancy Davolio to renttwo new videos:

1. Select the Rent button from the main window.

2. Enter 12001 for Member ID and click the Find Member button. The late

charges should appear in the Late Charges frame (see Figure 1–14).3. Enter two new videos for rental, using copy number 1 for each of

52005 and 52006.

4. Select the Finish button and click OK in the resulting messagebox.

To continue the demos for this book, it’s recommended that you keepthese two videos rented to Nancy Davolio.

FIGURE 1–13





When Nancy Davolio appears back at the point of sale torent new videos, she will also be assessed some latecharges.

FIGURE 1–14