When you start to get involved with Microsoft Transaction Server, you start to hear an awful lot about “three-tier applications”. So what precisely is a three-tiered application?
We’re all familiar with the idea of breaking down functionality into layers. In this sort of software model, each layer performs a specific role on behalf of the layer above. Each layer can then be developed using the most appropriate tools, by programmers with the most appropriate skills and experience. Provided that the interfaces between the layers are correctly defined, development can proceed in parallel, and we can even substitute alternatives for one layer without affecting the others.
In the three-tier model, the bottom tier handles all the nitty-gritty database stuff — what we've done so far. As far as we are concerned with MTS, this is where the resource managers sit. The top tier handles the user interface (i.e. all the web page or Visual Basic stuff) — MTS calls it the base client. The middle tier is the most interesting one, because that’s the one that forms the bridge between the two. This is the tier that defines the business logic of the application, and is the absolute heart of the application. Leave the bottom layer to the database experts and the top layer to the user-interface whizzes — the middle tier is to be our territory.
Let’s get a little more concrete, and consider what the middle tier might look like in our kidnap game example. Remember, we’re looking for processes here. One good way to identify processes is to look for the type of people who might be involved, for instance, a negotiator. A negotiation process will certainly be in progress during the kidnap game, involving the offering of a sum of money for the release of a hostage. Can we represent this as a COM object?
Of course we can. We’ll give it an interface called
and this definition:INegotiator
| Method | Parameters | Description |
|
|
Offer amount for hostage, and find out if this is sufficient to free them |
| Property | Type | Description |
|
|
Hostage name |
|
|
Account to take ransom from |
This is actually a pretty good example of a COM business object, in that it gets instantiated for a short period of time, it does its job and then goes away again. Business objects are a bit like specialized consultants: you hire them for a short-term contract, they do the job that they were hired to do and then you let them go. In our kidnap case, we hire a specially trained hostage negotiator.
Where does MTS fit in with all this? Well, as I’m sure you won’t be surprised to find out, MTS is excellent at making use of COM business objects. In fact, you can make a business object transactional simply by registering it with MTS, provided it meets some simple criteria. And, in the most basic case, you can set it up so that a transaction is automatically started whenever the object is instantiated, and completed when the object is destroyed. Everything that goes on in the meantime is treated as part of a transaction.
Needless to say MTS offers you more control and flexibility than that, through the use of a context object, but it doesn't get any more difficult than that.
Can you see why we have moved away from the traditional data-focused view of objects? If we used objects that represented data, we wouldn’t be able to use their instantiation and destruction to signal the start and end of a transaction. And if data hung around in objects in between transactions, the MTS environment (full as it is of phrases like "recycled object instances" and "multi-user") might very well have invalidated it the next time you used it. Thus the only valid data is in the underlying database.