As you know, three-tier architecture offers many advantages in terms of scalability and reusability over two-tier architectures. Such applications are more manageable compared to their two-tier counter parts. In a three-tier application, you split the entire application into three distinct layers: presentation layer, business logic layer, and database layer, as shown in Figure A.
Figure A: Three-tiered architectures offer improved scalability
and manageability because changes in one layer are transparent to the
other layers.
The presentation layer provides the client interface; the business logic usually consists of a component running on a server; and the database layer maintains persistent data storage. The presentation and data layers are fairly straightforward. However, you may have wondered how to implement a business layer.
In this article, we'll provide a brief overview of what it means to develop and deploy a business component. More importantly, we'll explain how you can make business components exceedingly efficient with Microsoft Transaction Server (MTS).
The business layer's role in a three-tier application
In a nutshell, the business layer in a three-tier application contains the rules that most often govern data manipulation. For example, this layer might simply open a database connection, invoke a SQL query, and then return the result to the presentation layer. Or, it may house more complex rules, such as the classic bank account example. When you transfer money from savings to checking, the application must subtract the amount from savings, and must also add it to checking. In addition, some transactions may incur charges or penalties. All these rules need to be built into the business layer. Then, if the business rules ever change, you just modify or replace the business layer and there isn't any need to migrate the changes to the presentation or database layers.
Developing business layers in Visual Basic
Visual Basic lets you easily develop reusable components such as ActiveX DLLs and EXEs. Such components are the perfect tools for implementing business logic in three-tier architectures. Because you build these components based on COM technologies, they allow access by remote clients using DCOM technology. As a result, multiple servers can host different components to achieve load balancing and thereby improve the overall application performance by way of availability and scalability.
MTS benefits for business components
Once you develop a component, you can use the Package and Deployment Wizard to deploy them. This handy wizard creates a CAB file that can be deployed on a remote Web server. If you install these components on MTS, you can increase overall application performance. That's because MTS takes care of component management for you. As you know, in Visual Basic when you use the New or CreateObject keywords to create an instance of a component, Visual Basic immediately creates the object. It allocates any threads, memory, or other resources at the moment of instantiation. This remains true even if your code doesn't use the object right away. VB doesn't release these resources until you set the object variable to Nothing.
To overcome this behavior, MTS shares object instances between several clients without their knowledge. Whenever a client application instantiates a component, MTS searches for component instances already available in its pool of previously cached objects. If it finds one, it simply generates a pointer to that instance. If required, it may even snatch an instance from the original application and assign it to the new one. Then, if the original application needs the component back, MTS may create a reference to another instance from the existing pool.
How does MTS manage this? In essence, it creates a Context object for the component upon its initial instantiation. The Context object doesn't take up heavy resources and holds only the object's current state. When MTS switches component pointers, it assigns the same Context to the newly obtained object reference. So, as far as the client is concerned, it's using the same object throughout--even though internally MTS may cycle objects between various running applications. This component management greatly reduces the server load. (This process of caching components and using them on demand is also known as Just-In-Time [JIT] activation.)
MTS and transactions
In addition to component management, MTS supports transactions. Because MTS manages these transactions, you don't need to use the BeginTrans and CommitTrans keywords. (We'll discuss the code you actually do use later.)
MTS and database connections
MTS also provides automatic connection pooling for database connections, thereby reducing the number of simultaneous connections to a database server. Most times, an application doesn't need each component to hold an exclusive connection to a database throughout its lifetime. MTS pools and shares database connections the same way it does components, thereby reducing the load on the server. And of course, it all happens transparently to the client. Now that we've discussed the benefits of using MTS, let's look at some guidelines you'll need to follow when you create a component if you want to take advantage of MTS' features.
Rules for component development
Components developed for deployment on MTS must follow certain rules. First, they must acquire data connections as late as possible, and release them as early as possible. Also, when making a new connection your code should use the same connection information--user name and password. MTS can't share connections with different connection information. Second, MTS requires that, as much as possible, components remain stateless. To make a component stateless, send additional method parameters that contain the current state.
Building component transactions
As we mentioned, MTS also handles transactions. It provides a transaction support property for each component installed within it. The property consists of four options, as shown in Figure B.
Figure B: The Transaction tab on the component's Properties
dialog box determines how MTS handles the component's transactions.
It indicates whether MTS always starts a new transaction upon the component's instantiation (Requires A New Transaction); uses the client's existing transaction (Requires A Transaction); or whether MTS allows the component to participate in transactions at all (Supports Transactions or Does Not Support Transactions).
To explicitly control how MTS handles transactions, call the EnableCommit or DisableCommit methods. When you call DisableCommit, MTS won't commit the transactions until you enable them with EnableCommit.
Deploying MTS components
The MTS is an integral part of Windows NT and executes as a service. The MTS explorer, as seen in Figure C, provides the GUI-based tool that handles component configuration and deployment on MTS.
Figure C: The MTS Explorer provides MTS' user-interface.
For deployment on MTS, you can combine several components into a single package. You then install this new package on MTS using MTS Explorer. To do so, simply drag the component from Windows Explorer and drop it on to the console. MTS Explorer also lets you select multiple items to make simultaneous changes to more than one object. For instance, you could set the security for several components at the same time. Finally, you can view a component's execution status in the console.
In cases where you need to deploy and run a component on a remote server, you'll need to set up the clients so that they can locate the remote object. Microsoft Management Console provides a utility for client side installation. To create a package for distribution to remote clients, select the desired package on the MTS console. Right-click on the package icon and select the Export option. In the resulting dialog box, enter the name of the PAK file. After you click Export, MTS creates the package file in the specified folder, which you can then move to the remote machine for installation. MTS also copies the required files to the client machine. However, it doesn't copy the components themselves.
Accessing MTS components
Once you've developed a component and deployed it on the server using MTS, you must use a slightly different syntax to create an instance of the component. First, of course, you must add a reference to MTS, which appears as Microsoft Transaction Server Type Library in the References dialog box. Normally, when you create an object in Visual Basic, you use the New keyword or CreateObject method. However, to use an MTS object, you first create an ObjectContext object. To do so, use the GetObjectContext method. With this reference in place, VB can then call the ObjectContext's CreateInstance method, like so
Dim contextObject as ObjectContext
Set contextObject = GetObjectContext()
Set myObject = contextObject _
.CreateInstance("MyClasses.MyObject")
If you do use the New keyword to create an object, Visual Basic
generates a private object that MTS knows nothing about. The object, thus
created, won't become part of a transaction. Similarly, if you use
CreateObject, MTS creates a new instance and assigns a new Context object
to it. Once again, such objects can't participate in transactions. The
CreateInstance method, on the other hand, copies transaction information
from object to object. Context methods and properties
Once MTS creates the object, you can use it normally in code. Whenever the component completes execution, either fully or partially, and wishes to commit the changes, call the SetComplete method on the MTS Context object. This tells MTS to commit the completed work and frees up the object's resources. If an application needs to abandon the changes for any reason, call the SetAbort method. This informs MTS to roll back all changes made in the current transaction--including changes made by other components involved in the current transaction. This method conforms to the following syntax:
contextObject.SetAbort
When you use either of these methods, you're informing MTS that the
object has finished its current task and no longer requires maintenance of
its internal state. MTS then reclaims the object's resources, which it can
assign to other applications. If the original application references the
object again, MTS assigns a new instance to the component with properties
set to default values. (Remember, MTS components should be stateless.)
If an application requires data-sharing between several instances of a component, MTS provides the Shared Property Manager. This special-purpose resource dispenser enables concurrent access to shared data without the need for complicated locking mechanisms.
Conclusion
Three-tier applications have quickly become a recognized standard for many applications. Visual Basic and MTS have greatly simplified the development process for these separate layers, particularly the business layer. Visual Basic lets you create DCOM components, which you can then deploy on MTS. Aside from a few minor modifications, these MTS components don't require much in the way of special programming. MTS provides several benefits in terms of scalability, reusability, security, transaction management, and database management that far outweigh the effort involved in making these requisite modifications. In this article, we've covered how MTS makes deploying a business component easy and efficient.
Copyright © 1999, ZD
Inc. All rights reserved. ZD Journals and the ZD Journals logo are trademarks of ZD
Inc. Reproduction in whole or in part in any form or medium without
express written permission of ZD Inc. is prohibited. All other product
names and logos are trademarks or registered trademarks of their
respective owners.