In the real world, sometimes it pays to leave traces of DNA everywhere. Windows DNA makes it easy to tie together disparate parts of a corporate solution while providing a consistent interface for users and developers.

There has been a lot of talk about how the Internet will reshape the way you work, the way you think, and the way enterprises conduct their day-to-day business activities. This case study focuses on an Internet-based application called the Project Distribution System (PDS) that is revolutionizing the way building construction projects are designed, developed, and managed in the architectural/engineering/construction (AEC) industry.       The AEC industry has long sought an easier way for disparate entities participating in building construction projects to collaborate. A construction project may involve architects, civil engineers, surveyors, estimators, building contractors, the local zoning commission, and many other entities. Often, pulling these different factions together and getting a project completed has been difficult, especially on larger assignments. Project delays and budget overruns are epidemic in the construction industry; some of these could be easily eliminated by improved communications.       PDS is a subscription-based extranet, developed by Projects-OnLine/InterNova, that enables construction projects to be accessed efficiently and securely over the Internet. Project participants can collaborate without the hassles of phone calls, faxes, or snail-mail; it's estimated to reduce costs by about 30 percent. PDS also allows subscribers to review Request For Proposals (bid packages) on upcoming projects nationwide, which needless to say offers subscribers a tremendous opportunity to increase revenues.       One of the daily routines of architects and engineers is the printing of large-scale blueprints, which require specialized printers and plotters. In the past, users have had to submit print jobs to printing houses by physically driving over or sending documents by snail-mail—a slow and time-consuming process. With PDS, users can submit print jobs to the nationwide ReproCad network of print shops and have their documents delivered to their doorstep via UPS or FedEx—a vast improvement. Application Features       One of the key goals in constructing PDS was to build a highly graphical application that used concepts and metaphors familiar to business users.       The AEC industry predominantly uses Windows® on the desktop, owing to its wide variety of CAD and graphics tools. With this in mind, the development team decided to base the PDS system on the Microsoft® Windows Distributed interNet Application (DNA) architecture. DNA offers a complete set of tools and technologies necessary to build scalable, extensible, distributed systems.

Figure 1: The PDS Interface

With a user base familiar with Windows, the design team felt that using a Windows Explorer-like interface was a good choice (see Figure 1). The PDS application extends the Explorer paradigm by providing a seamless environment between the local network and the remote system. The remote system manifests itself as special folders called My Organization, My Profile, and My Session. The local system is called My Computer, containing all of the local and network drives.       The entire PDS system focuses on the concept of folders and objects. Every object in PDS belongs to a class, and a class is an abstract data type consisting of attributes and functions (or methods).       One such attribute is the viewer or editor of a class. For most document objects, PDS comes fitted with an ActiveX® viewer application capable of viewing 150 different document formats including Microsoft Excel and Word, GIF, JPEG, all AutoCad formats, HTML, and PDF. The PDS Viewer is an ActiveX server that uses an MDI window. It's capable of panning, zooming, and manipulating drawings as well as red-lining and annotating (for high-end users at additional cost). The PDS Viewer also allows documents to stay in their native format without conversions to preserve their attributes (see Figure 2).

Figure 2: PDS Viewer

Business classes also have editors. One such editor is the Project Editor, a key part of PDS. Figure 3 shows the Project Editor, where privileged users can manipulate the attributes of a given project. Owing to its object-oriented roots, PDS makes it easy to accommodate additional classes without requiring modifications to the client application.

Figure 3: PDS Project Editor

A major concern of any mission-critical business application is security. Besides the fundamental security provisions such as packet filtering, firewalls, virus protection, and Secure Sockets Layer (SSL), this system includes a comprehensive set of object privileges. Privileges on objects can be granted to individuals or groups, similar to the system used by many file systems. Privileges can also be granted to classes of objects instead of individual objects.       Drag and drop capabilities were added to PDS as well. Users can drag and drop files from their local environment to the remote system. PDS will upload the files to the destination folder, provided the user has sufficient privileges. Drag and drop makes ordering print jobs extremely easy. Users can submit orders to ReproCad print shops by simply dragging and dropping files to the Print Services tray. Users can then select from a variety of different print options such as binding, laminating, and so on for each order. Orders and documents are zipped up and shipped off to the print shop of the user's choosing (see Figure 4).

Figure 4: Prnting PDS Projects

PDS also includes the Microsoft WebBrowser control that allows users to access Web resources within business applications. The WebBrowser control is used to submit user feedback and customer service queries to an online helpdesk system, as shown in Figure 5.

Figure 5: PDS Uses the WebBrowser Control

Architecture Overview       The PDS infrastructure is based on the Microsoft Windows DNA architecture. PDS uses a multitier architecture: presentation tier, application services tier, and database tier (see Figure 6).

Figure 6: The PDS Architecture

This architecture has the following advantages: PDS can grow easily along with its user base. New services can be added to the existing system easily because all ser-vices communicate with one another through clearly demarcated COM interfaces. Business logic can be modified without affecting the presentation layer. The architecture enables the system to have a Windows-based client interface (as compared with HTML).       Complementing this architecture is a supporting cast of high-end servers, round-the-clock backup systems, uninterruptable power supplies and generators, tech support, and a staff of trained technicians. Let's take a closer look at each facet of the system. Presentation Tier       The presentation tier houses the client application developed in Visual Basic® 5.0. The client is a standalone ActiveX server application, not an Active Document housed within Microsoft Internet Explorer. This allows greater flexibility and consumes less memory without having to run within the browser's memory space. Some limitations of user documents, such as the inability to open nonmodal windows, is also removed. The PDS Viewer is a separate ActiveX server application.       PDS uses Microsoft Remote Data Services (RDS) to access data over the Internet. RDS is packaged with Internet Explorer, but is also available separately. PDS uses RDS outside the browser. The Microsoft Knowledge Base article Q176874 describes how to deploy RDS clients.       The PDS user interface layer is object-oriented. All objects in the system belong to a class. Each class specifies how to manipulate instances of that class, including the editors to use, context-sensitive menus, and icons to display. Class information is maintained in a remote registry on the database. This registry is similar to the Windows registry in that it provides basic behavioral information about classes of objects in the system. New classes can be added using system administration tools.       Classes in PDS that access remote business objects are called proxy classes. CDeviceProxy, shown in see Figure 7, is used by system administrators in PDS to create database devices on the fly; it's a simple business object with some database interaction. The PDS graphical user interface calls on the CDeviceProxy object, which in turn gets a reference to a remote object. Whenever methods are called on CDeviceProxy, it delegates the actual task to the remote object.       As you can see in Figure 7, in order for CDeviceProxy to get a reference to a remote object, it makes a call to a utility class called CObjectLocator. This class accesses the remote object much like any local object, using the CreateObject function in Visual Basic. It includes an additional parameter supplying the HTTP address of the remote object. CObjectLocator performs all the necessary exception handling when accessing remote objects. It also simplifies development and testing.       One of the most arduous tasks during the development of a distributed application is debugging. Since Visual Basic 5.0 you've been able to start multiple copies of Visual Basic and run both the client and the server on a single machine, set up the necessary project references, and simulate a distributed environment before deploying the server components. CObjectLocator simplifies development because you can easily comment/uncomment the appropriate lines shown in Figure 8 and test the application locally. CObjectLocator can also play a role in load balancing by pointing clients to different servers if necessary. Figure 9 shows the interactions on the client side for invoking remote objects.

Figure 9: Invoking Remote Objects

One of the primary functions of PDS is to facilitate sharing of documents; constant uploading and downloading of data consumes bandwidth and slows down the user. To combat this to some degree, PDS has its own caching scheme, which saves download time. When a document is viewed for the first time, it is downloaded to the user's hard drive; on subsequent occasions the locally cached copy is read unless the user requests to download a new copy. Application Services Tier       For scalability, the PDS system was partitioned into a number of different services in the form of ActiveX DLLs running within the process space of Microsoft Transaction Server (MTS). Business logic is housed on the application services tier, utilizing Microsoft Internet Information Server (IIS) 4.0 and MTS 2.0. Business logic in PDS has been grouped into services such as Administration, Order, System, File, Zip, Membership, Message, Print, and Project. Each of these services is an ActiveX DLL housing a number of business classes. Each class carries out a distinct business function and interacts with one or more tables on the database.       Since the business logic is split into separate services, multiple copies of a frequently used service can be started on separate server machines for better load balancing. Also, there may be other uses for wanting to have some users hit the Membership service on server A, and other users hit the Membership service on server B—perhaps for security or geographical reasons.       Unlike DCOM, where COM objects can be passed as parameters to methods on remote objects, RDS allows simple types (integer, long, string, and so on) and ADO recordsets to be passed. These ADO recordsets are packaged by RDS into MIME-encoded Advanced Table Datagrams during transmission via HTTP. Business objects on the client side access data via these recordsets. PDS takes advantage of the just-in-time activation and as-soon-as- possible deactivation features in MTS to conserve memory resources when loading and unloading ActiveX DLLs.       Figure 10 shows the CDevice business object within the polAdminSvc.DLL on the server. This business object simply accesses certain stored procedures on the database server. CDevice enlists the help of the Database service (polDBSvc.dll) and utilizes some of its public interfaces, namely CSPExec, CSPParams, and CSPMaster. The Database service handles interacting with databases. Business objects can also be used to access multiple database servers and enforce transactions across databases using the GetObjectContext, SetComplete, and SetAbort predicates.       PDS has a multiple-server configuration consisting of a number of high-end Windows NT®-based servers. Some PDS system information is stored in the Windows NT registry, providing access that's faster than storage in a database. When multiple servers are involved, keeping their registries synchronized may be tricky. Fortunately, the Win32® API provides a very useful function called RegConnectRegistry that enables one machine to connect to another machine's registry.

LPTSTR lpszComputerName, HKEY hRootKey, // Must be HKEY_LCAL_MACHINE // or HKEY_USERS PHKEY phAssignedKey);

Using the handle that is returned, one machine can update another machine's registry entries using other registry API functions like RegCreateKeyEx and RegDeleteKey. Database Tier       The database tier utilizes SQL Server™ 6.5, although migration to SQL Server 7.0 is imminent. PDS employs a distributed database architecture consisting of two types of databases. The system databases manage core functionality such as membership and administration data. The project databases hold project information, references to documents, and store business objects as well as privileges within the project. This architecture enables easy offlining of dormant projects and simplifies the management of the system. The multidatabase architecture used by PDS is similar to that of the Unix file system, where external file systems can be mounted and dismounted at mount points.       PDS takes advantage of stored procedures to a large degree to improve database performance. Although you might think that stored procedures could only do static SQL statements, a feature that has proven very valuable is the ability to construct dynamic SQL strings and execute them within stored procedures. Using this syntax

EXEC[ute] ({@str_var | 'tsql_string'} [+{@str_var | 'tsql_string'}...)}

lets you concatenate several varchar or char or text strings. Conclusion       PDS demonstrates the completeness of the Microsoft suite of tools and technologies for developing scalable, distributed business applications. PDS is also a clear statement of how the Internet can be used effectively to build business systems without employing a Web interface. Above all, PDS is a true e-business, providing users with a compelling need to use the Internet to save time and money.       Currently, PDS is used by several large architectural firms, a number of nationwide department store chains, state and local agencies, and more. The capabilities of this product extend beyond the AEC industry and can be used in any project management situation.

http://msdn.microsoft.com/xml/scenario/texcel.asp http://msdn.microsoft.com/workshop/components/offline/offline.asp

From the February 1999 issue of Microsoft Internet Developer.