Robert Coleridge
Microsoft Developer Network
November 1998
Summary: Provides an overview of the migration of the Duwamish Books sample from Phase 3.0 to 3.5. (3 printed pages) Discusses:
In Phase 3.5 of Duwamish Books, we implemented Microsoft® Transaction Server (MTS) in order to migrate the sample to a distributed three-tier architecture. This affected all areas of the application: code, setup, and deployment. In this article I will discuss the issues we confronted, including deployment, transactional processing, remoting, and significant changes to the data access layer (DAL).
Distributing Duwamish Books across a number of machines adds complexity to the setup and deployment that we didn't have to deal with in other phases. While the MTS 2.0 SDK and Explorer provide a great deal of automation and support when it comes to setup and deployment, they still leave a bit of work for the developer.
While designing the Setup program for Duwamish 3.5, we realized that we needed to create a Setup program that allowed the user to install individual parts of the system. Most typically, a user may want to install the business logic component on one server and install the data access component on another. However, another user might want to install both the business logic and the data access components on the same server. While it may seem easy to accommodate these two installation scenarios, in fact they each require very different setup logic.
The biggest difficulty lies in informing the business logic component where the data access component is installed. Installing both components on the same machine is the easiest to accomplish because all that is necessary is to register both components—they would automatically have access to each other. However, installing each component on different machines presents challenges for the Setup program. The data access component could be registered via MTS on one machine and the business logic component could be registered on the other machine. So far so good, but how would the business logic component know where to find the data access component? For complete details on how this was accomplished, see Dale Smith's article "Remoting the Duwamish Components."
While designing the Setup program, we needed to decide how the components would be installed. There are three methods that we examined: pushing, pulling and encapsulating. Let's examine each method.
This method assumes that a user or application has the security privileges to "push" components to a remote machine. Due to security issues beyond the scope of the project, we decided not pursue this option. For more information, see "Working with Remote MTS Computers" in the MTS documentation in the MSDN Library.
This method assumes that a person or application has access to the required components on some remote location and can retrieve and install them onto the local machine. All that is required is for the components to be shared from one central location—they can be installed at any time. However, this method is not without potential problems. Setting up and configuring remote components, even through this method, may be too involved and complicated for an average user.
In the Setup program for Duwamish Books, we decided to use a modified "pull" method. The Setup application contains all of the required information and components and can install them on whichever machine the installer is running. The "pull" part of the process comes at run time when the install component needs more information—it pulls the information from the machine it is pointing to. For Phase 3.5 installation instructions, see "Installing a Distributed Application."
Did you know that installing components via an MTS package differs from installing via the MTS Explorer Remote Component folder? How you inform MTS of the remote components and/or install the MTS package could result in running the component on a different machine than you expected. To alleviate these potential problems, we decided to use a Setup application to perform the installation of the components. In "Remoting Duwamish Components," Dale Smith examines the process for manually remoting a component and provides the code we used to automate the process using the MTSAdmin API.
Where and how a component runs is just as significant an issue as how it gets installed.
The way you plan to install a component can have a significant effect on how you instantiate a component in code.
There are three ways to create an object: the New keyword, the CreateObject function, or the MTS CreateInstance function. Each method works differently and has different affects on performance and usability. Use the wrong method for the wrong scenario and your code may not even work. Understanding these differences is critical to the success of your application. See Dale Smith's article "Remoting Duwamish Components" for a more in-depth discussion of instantiation techniques.
The issues involved in creating transactions, their scope, connection pooling, and scalability-related issues are covered in detail in Michael Zonczyk's article "Hoisting the Duwamish Books Components into MTS." One of the more critical decisions we had to make was whether to use automatic transactions. MTS has the wonderful ability to wrap a transaction context around an object without the client having to deal with the creation of the transaction. This makes for very simple, easy-to-use automatic transactions. However, it also makes for extra overhead and resource usage because every invocation of the object involves a transaction, whether it needs one or not. Essentially, there are three ways to deal with transaction creation. The first is to use automatic transaction creation; that is, wrap each object in a transaction regardless of its transactional needs. The second is to split up a component so that the component contains multiple classes, those that need transactions and those that do not. And finally, the third method involves allowing only those methods that require transactional contexts to create them, as needed. Michael's article discusses these methods and when you may want to employ them.
In review, the Data Access Layer (DAL) component encapsulates the data access to and from the data source and contained 12 different methods in Phase 3.0. These methods involved or controlled such areas as transactional processing and database connectivity.
In Phase 1 (desktop model) such things as persistent database connections and connected recordsets were perfectly understandable and allowable. As Duwamish migrated to a two-tier model and eventually to a three-tier model, we had to take a serious look at all of these connections. In a distributed world, persistent connections are not scalable and are heavy resource consumers; therefore, we made the decision to move to a connectionless model for the DAL. In order to do this we needed to modify the DAL so that interaction with the data source was limited to a single method call, and not spread over several calls. To this end we reduced the 12 methods to only two.
We were able to accomplish this by adding MTS, which greatly simplified the object model for the DAL. We learned that with transaction processing an integral part of MTS, we no longer needed to have methods such as BeginTrans, RollbakcTrans, and CommitTrans. We removed these methods from the DAL and simply replaced their invocation in other code with the MTS SetComplete method and SetAbort method. Bear in mind that these two replacements were not functional equivalents but simply voting methods. For more details see my article "Moving a Data Access Layer into Microsoft Transaction Server."
What we learned in Duwamish 3.5 is that integrating MTS into an existing project (Phase 3.0) can take some time and resources, but is well worth the effort. What looked like a colossal task in the beginning—migrating to distributed three-tier—was actually fairly easy, thanks to MTS. If you are planning to migrate an existing system, or create a new distributed system, I would highly recommend using MTS to handle remoting, transactional processing, and deployment.