Creating client applications for high-performance n-tier systems is easy and flexible when developing in the COM/DCOM world. When building large-scale enterprise solutions, developers have a wider variety of languages and tools to choose from than ever before. System developers have the flexibility of using programming languages like Visual Basic® and user tools such as Microsoft® Office to quickly create large-scale enterprise solutions. The only caveat is that developers must put a lot of forethought into designing these systems to ensure efficiency and scalability as the system grows.
In last month's article, I created several ActiveX™-based servers that ran in Microsoft Transaction Server (MTS), Microsoft's new transaction monitor/object broker. MTS provides a robust, easily manageable, and scalable environment in which to run ActiveX-based business servers in the Windows® world. ActiveX-based servers running in MTS can be accessed via a wide variety of languages and tools through COM/DCOM.
This month I'll build two client applications that will utilize these business servers, as well as several client-side objects. One client will be written in Microsoft Visual Basic 5.0 and the other in Microsoft Outlook™. Both clients will utilize COM/DCOM to communicate with business servers running in MTS.
Last month's example centered on a distributed, n-tier time and billing system called Timecard. Originally, the Timecard system consisted of a traditional two-tier client/server application employing a Windows-based front-end application and a Microsoft SQL Server™ database back end. This system performed adequately at first, but experienced performance problems as its user base increased and became more dispersed. The need for a more scalable application combined with management's desire to integrate Timecard functionality with other applications led to a decision to redesign the system utilizing an n-tier architecture.
Having already created and tested the MTS servers, I'm now going to create several client applications capable of utilizing the power of these servers. The first client will be an Active Document intranet application written in Visual Basic 5.0 that will constitute the primary means for entering Timecard information. In order to provide flexibility in entering information, I'll also build Timecard functionality into Outlook. Finally, I'll build two client-side ActiveX-based servers in Visual Basic that will be used and shared by both the Active Document and Outlook applications.
In writing this article I have the benefit of creating client applications after the completion and testing of the MTS servers. However, in most real-world situations client and server development occur concurrently, often designed and implemented by separate groups of developers, possibly in different locations.
This development scenario can pose many problems if you don't allocate adequate time for the design process. During the design stage, system architects should construct the contract that the client and server developers will adhere to throughout their development cycles. This contract establishes characteristics for the server interfaces that both development teams will be coding to throughout the development process. Tools such as Microsoft Visual Modeler (included in the Enterprise Edition of Visual Studio™) are invaluable at this stage because they allow developers to quickly and easily design the object model and even to generate skeleton code for each of the objects.
When dealing with object models, countless hours will be saved if adequate time is spent during the design stage. If a system is well-constructed and a comprehensive object model is created, the server interfaces should remain fairly static throughout the development cycle. Through compartmentalization of system components and strict adherence to the contract, each object can be developed as a black box. This type of approach enables you to station development teams at different locations without adversely affecting the process.
Of course, changes can occur even using this strategy; system requirements almost always change during the development cycle. An advantage of n-tier architecture is that most of these changes will affect server development, but never client-side developers, unless changes to the server interfaces are required. In such cases, there should be a central owner of the object model with the responsibility to design for the implementation of the change and coordinate with both the client and server developers. Large-scale development efforts lacking such a coordinator are often doomed; interface changes can result in serious delays and rampant miscommunication in both development camps.
As stated in the previous article, one of the most important requirements of large-scale distributed systems is the minimization of network traffic in order to maintain efficient system operations. Reducing the number and size of transmissions between client and server will maximize system potential. Last month, my discussion centered on several key server design issues for both the n-tier and MTS worlds. Client developers will find that they have their own unique set of issues to consider when building large-scale systems.
Probably the biggest challenge to developers is meeting all of the users' expectations while retaining system efficiency. Many GUI metaphors that users are accustomed to finding in small database programs (grids, lookup lists, automatic refreshing of data) are impractical in larger systems. While these are great features that certainly add an aesthetic dimension to an application, they can adversely affect performance if used incorrectly. Therefore, some concessions will have to be made to keep the system running efficiently; developers and users must work together to strike a balance between functionality and efficiency.
In the past, numerous systems have been created with a grid metaphor that allows the user to peruse large amounts of data as if they were inside a Microsoft Excel spreadsheet. However, this approach can cripple larger systems, requiring large amounts of data to be passed via numerous network hits. Rather than giving the user a full perusal of the database, consider filtering the view as much as possible, providing only small chunks of data at a time. A great example of this approach is an Internet search engine. Typically, a user will type in a keyword and a resultset of 10 records will be returned. Network traffic is minimized and users quickly receive results on their query.
Careful attention should be given to lookup lists in client applications. Lookup lists, possibly containing tens or even hundreds of records, will usually reside on multiple screens. They are loaded every time a screen is loaded into memory. Though guaranteeing data currency, this architecture can slow down the network in systems with a large user base. System designers should investigate whether it is feasible to load these lists once and cache the results to be used throughout the program. This strategy speeds up the client and reduces network traffic. Additionally, the type of data residing in data lookup lists is usually fairly static, so keeping data current is often not as important in practice as it is in perception. Under circumstances where the data is less static, two alternatives would be to consider a user-initiated refresh function or to construct MTS servers capable of evaluating data changes and only returning data when it has changed.
Strict adherence to the n-tier model by the development team is another design issue that generates lots of debate. Many n-tier purists would claim that all logic should reside in the business server level. In my opinion, adhering to this methodology will slow down large systems through increased network traffic and decreased system scalability. Certain low-level pieces of functionality, such as field-level verification, can be handled easily by the client application. Verification of correct field entries on the client prevents depletion of precious network bandwidth. This also increases the scalability of servers by relieving them of the minor duties of field-level verification, instead allowing them to be utilized for what they were designed to doæprocessing key pieces of business logic.
One of the biggest benefits of MTS is that the servers are easy to interact with through code. If a developer has ever programmed an application that uses an ActiveX-based server, he or she already has all the experience needed to access MTS servers. Calling an MTS server is as simple as:
Dim obj as object
Set obj = CreateObject("Projects.clsProjects")
obj.Method
Set obj = Nothing
MTS handles all of the complex issues, completely shielding the client developer. The only criteria to which the
client developer must adhere is that the MTS server application will be registered on the client machine. Depending on where the ActiveX-based server resides, COM (if local) or DCOM (if distributed) will handle the call from the client to the server.
Two key components, Project and Security, were created as ActiveX-based servers that could be shared by the various front-end clients. These components reside on the local machine and are shared by the Active Document and Outlook applications, as shown in Figure 1.
Figure 1: Timecard Components
Both of these components were developed in Visual Basic 5.0 as ActiveX executables that are instantiated out-of-process from the calling client program. The first client program to access the server will pay the price of instantiation, with all subsequent calls to the server utilizing the already running instance. The server will be removed from memory after the last application has been terminated. This is accomplished in Visual Basic by creating an ActiveX EXE-type application. The Visual Basic project consists of one basic module, one private class, and one public multiuse class. An object of the private class type will be globally created in the basic module. The public class will be created once for every client application that utilizes the server and acts as a hook into the server. The private class will only be created once when the server is first instantiated and will remain in memory until the server is terminated. Any state information that will persist among the various clients using the server will be contained within the private class.
The Project component presents users with a hierarchical listing of the client/project/subproject relationships in a treeview control (as shown in Figure 2). From this list the user can choose the correct relationship with which to associate a particular time entry into the Timecard system.
A user has hundreds of clients and thousands of project options to choose from every time he or she enters a time entry into the system. Each client, project, and subproject has been assigned its own unique alphanumeric code. These codes must be entered into the Timecard clients for each time entry. Users can simply type in the codes for frequently worked on projects without having to call the project component. This helps reduce the time it takes for a user to select the correct relationship for a time entry. In the event a user does not know the code, he or she will view the Project component and select from the list of valid client/project/subproject combinations.
The hierarchy represents a large data transfer across the network each time it is requested by the user. Since this data is primarily static, I decided to lessen the time required to use the system and reduce the amount of data transported across the network by only loading this list the first time it is requested by the user. After the data is retrieved from the MTS Project server, it is cached to provide quick availability the next time it is requested. The component is not destroyed until the parent application is finally terminated.
Unfortunately, due to the large number of clients and projects, this initial hit still represents a huge amount of data-that will likely never be used-being passed across the network. It also creates a substantial delay the first time the user calls the project list. For this reason it was decided to initially retrieve only the first level of the client/projects/subprojects hierarchy, as shown in Figure 3. Upon loading this screen for the first time, the user is presented with a treeview that has all the clients in the first level.
If the user decides to drill down into a particular client, the component will once again call the MTS Project server and retrieve only the projects that are linked to the chosen client. If the user has previously retrieved this information, the application is intelligent enough to not retrieve it again. Although this approach strays from the model of passing all needed information between the client and server at one time, it drastically decreases the amount of information being passed across the network, optimizing speed for the entire system. The code for this example can be seen in Figure 4.
Each front-end application requires the user to log in to the Timecard system by entering a user identification and password. The system then validates the user and determines which pieces of information this user should be able to view and modify. After the user successfully logs into the system the first time, subsequent applications can piggyback off
this connection.
The term connection, when used in an application context, should not be confused with a database connection. I'm not accessing the database directly from my Windows clients; all database communications are facilitated through the ActiveX-based servers running in MTS. The security application calls an MTS server to verify the user and then assigns a security key. This key is maintained throughout the user session in the security component and is shared among the various Windows clients that access the Timecard system.
Active Documents are one of the best new features of Visual Basic 5.0, allowing a developer to create Web browser applications in the same way as traditional Visual Basic-based applications. Visual Basic 5.0 even allows developers to port existing Visual Basic-based applications to Active Document applications through the ActiveX Document Wizard in Visual Basic. This ability allows shops with years of Visual Basic experience to instantly become Web developers without any retraining. Users still experience the rich user interface features of traditional Windows programs from within a browser.
Developers should consider one issue that could possibly pose limitations when creating Web solutions with Active Documents: browser support for ActiveX technology. Currently, Microsoft Internet Explorer (IE) is the only major browser to support ActiveX technology (support for Active Documents and ActiveX controls), although you should expect to see most major browsers supporting ActiveX technology in the near future. An application's target audience could preclude the use of ActiveX technology in some circumstances. In situations where the target audience will be using a wide variety of browsers, developers will probably have to go with a solution that will be supported by all browsers. This type of application can be developed with tools, such as Microsoft Visual InterDev™, that help create Web solutions that are based on Active Server Pages (ASP). ASP can even utilize the business logic contained in the ActiveX-based servers running in MTS.
I chose to use Visual Basic Active Documents for the Timecard solution for a variety of reasons. First of all, my company has a large number of experienced Visual Basic developers, which allowed us to quickly and efficiently create the Timecard system without any retraining costs. Additionally, we will be able to easily maintain and modify the system in the future with our current base of developers. The target audience also helped justify an Active Document solution since all the users are guaranteed to have IE 3.0 or higher as their browser.
In my opinion, one of the biggest benefits of Active Document applications is that development does not differ significantly from the development of standard Visual Basic executable-type applications. All of the code behind the Active Document Timecard application is the same as in a regular Visual Basic-based application.
Another benefit of Active Documents is the ease with which they can be deployed. The user experiences a one-time hit the first time the application is downloaded (all of the ActiveX controls, the program itself, the Visual Basic runtime, and any other supporting files are downloaded at this point). Every time a user runs the application, a check is made to see if any of the required files have changed. If a change has occurred, the newest version of the file is downloaded to the user's machine. This mechanism is extremely useful for Internet and, particularly, intranet applications since high-speed lines usually connect the network.
The Active Document application for Timecard consists of only one screen, which is meant to be used as a single page that would exist on a corporate intranet. Users navigate to this screen through their browser, log into the system, and then enter their time information (see Figure 5). This screen has two main responsibilities: retrieving existing data and saving new data. The code for these two functions can be seen in Figures 6 and 7. Notice how this code is identical to the code needed to access regular ActiveX servers.
The Setup Wizard in Visual Basic 5.0 makes distributing Active Document applications quite easy. After determining which files are needed by the application at runtime, the Setup Wizard then compresses them into a series of .cab files, and generates some sample HTML code that points to your Active Document. The primary .cab file will contain the ActiveX DLL or EXE, an .inf file, any files that are not in the secondary .cab file, and space for digital signatures. The .inf file contains links to other .cab files that contain Visual Basic support files and controls, as well as registry and security information. This file replaces the setup.lst file that the Setup Wizard creates in standard EXE setups.
The secondary .cab files include all runtime components, such as msvbvm50.dll, and any controls that the Active Document uses. These files are packaged into separate .cab files, digitally signed by Microsoft and placed on the Microsoft Web site (http://www.microsoft.com/). You have the option to link your .cab files to the files on the Microsoft site or to local copies of these .cab files.
The strategy you use depends upon a number of factors. The most important is whether the users will have access to the Internet; if so, then two additional factors to consider are download speed and security. Even though downloading only occurs the first time the application is run or something changes within the app, there are instances in which you might want the .cab files to reside on your internal network in order to increase download speed. All of the users of the Timecard system have access to the Internet through the
corporate intranet, so I decided to download the .cab files
from the Microsoft site. This guarantees that users will always have the most up-to-date copies of the controls and supporting files.
The business servers do not need to be copied to the local machine along with the client since they will be running on remote machines. However, the business servers must be registered on each local machine with the necessary information for the client to remotely instantiate these servers through DCOM. Here again, the Setup Wizard will take care of this registration.
The Setup Wizard determines whether the application accesses any remote server components. In the Timecard application, there will be several server components that the application utilizes. When the ActiveX-based server is created, it will create a .vbr file that contains information about the server. For each remote object, the Setup Wizard will prompt the developer for this file. After selecting this file, the developer will be prompted with another screen asking for information about where the server will reside and the type of remote transport to use (DCOM or its predecessor, Remote Automation). All servers that run in MTS must be accessed by COM/DCOM, so I selected DCOM. I also typed in the name of the Windows NT® Server that this business server will be running on: FDI_MTS1. After supplying this information, the rest
of the steps are identical to those for building a standard
EXE installation program.
Deploying clients that utilize MTS servers becomes even easier with the release of MTS Service Pack 2. The administrator of the MTS server simply exports a package from the MTS Explorer. This package contains an executable that includes all the registry information required by MTS clients. You can easily add the execution of this application to your installation programs or you can mail this executable to the users and have them run it. After running the application, the user will have all the required
registry entries to utilize the MTS servers.
Highly scalable ActiveX-based servers running in MTS can be accessed from almost any development environment, not just traditional languages such as Visual Basic and C++. In the Timecard example, I need to access the appropriate servers with Outlook, the Microsoft Office scheduling/mail/contact management/do everything program. Many potential users already keep track of their busy schedules (meetings, phone conversations, to-do lists, and so on) within Outlook. By allowing access to the Timecard system through Outlook, users can easily enter time and billing information into the system as they enter new tasks, engagements, and journal entries.
Through Microsoft Forms and VBScript, I was able to customize Outlook to integrate it with the Timecard system. The standard Outlook calendar, tasks, and journal features were all modified to create hooks into the Timecard system (shown in Figure 8). The user can also customize Outlook to view the Timecard information as shown in Figure 9. Coding VBScript in Outlook to access the MTS servers is fairly simple, as shown in Figure 10. All declared variables are variants. When accessing an MTS server, you utilize the CreateObject function just like in Visual Basic. The only difference is that you must traverse down the Outlook object model to get to CreateObject.
There are several issues you will run into when developing in Outlook. The most obvious is that all coding must be done in VBScript, which is much more limited than Visual Basic. This is easily circumvented by creating ActiveX-based servers in Visual Basic that can then be accessed from within Outlook. Another issue is that all programming in Outlook is performed at the item level (contact, task, calendar, and so on). You can write code to be executed when the user interacts with any of the individual items in Outlook. However, it is impossible to create global variables or procedures that can be shared by all the items (unless written as ActiveX servers). Despite these limitations, Outlook gives developers lots of flexibility to create custom applications.
Applications written in Outlook can be easily deployed to a wide user base. The Outlook application written for the Timecard sample could be run just as easily by standalone users as by those who are currently utilizing a Microsoft Exchange system. The developer simply deploys the newly created forms to the appropriate users. In situations where users are running Microsoft Exchange, the developer can distribute the new forms by placing them in public folders accessible to the whole organization. In other situations, where it's important to restrict the availability of forms to certain groups, you would publish the new forms to the Personal Forms Library for only the people who will use the application. If you are looking for more in-depth information on how to deploy and maintain Outlook systems check out Building Applications with Outlook 97 (Microsoft Press, 1997), an excellent resource for development in Outlook.
Creating applications in the distributed world requires special planning and design for all system components. This careful planning applies to all aspects of the system, be it the front-end clients, the middle-tier servers, the database back ends, or even the system configuration and tuning. Once a good design has been decided upon, development can occur in a quick and efficient manner, using a wide variety of languages and tools.
A comprehensive, well-integrated system design can provide for fast, efficient collaboration among development teams using a wide variety of tools, and results in an application displaying seamless interaction among components throughout a distributed environment. MTS and Windows NT provide an excellent infrastructure for deploying n-tier systems and allowing for scalability to accommodate system growth. After the business servers have been created and correctly installed in the MTS environment, developers can write applications to utilize the servers' power and flexibility. The open architecture of COM/DCOM allows applications written in almost any Windows-based development language to access MTS servers.
Upon completion of the system framework, developers have the flexibility to utilize ActiveX business servers from anywhere within the corporation and from within almost any tool they choose. MTS and COM/DCOM provide the flexibility for new systems to integrate into existing systems, while allowing for enough scalability to handle the additional load placed upon a system by an ever-growing user base. Whether the requirement is scalability, performance, or ease of development, client systems leveraging COM/DCOM and MTS provide a formula for efficient, painless company growth.