Enter the Dragon

One of the most exciting developments in COM is the emergence of Microsoft Transaction Server (MTS). Up until pretty recently, transactions were one of those areas in systems development which were surrounded by an aura of voodoo, black magic and, above all, exorbitant consulting fees. All this is about to change. Transaction-based development is going mainstream, and one of the prime movers here is Microsoft. Precisely how mainstream is indicated by the fact that, some time back, Microsoft actually merged their Transaction Server and COM teams together. Microsoft Transaction Server is absolutely central to the future strategy of Windows — so much so that, from Version 5 of NT onwards, MTS is actually going to be part of the operating system itself.

Why is this?

Very simply, it’s because transactions are central to all human activity.

But what exactly is a transaction?

We’ll get onto a more precise definition in a little while, but for the time being, we can take a transaction as meaning simply a number of events that must either all take place or none at all. The standard example is taken from the world of commerce and usually involves transferring money from account A to account B. The money must either end up in account B (and nowhere else), or, if something goes wrong, stay in account A (and go nowhere else). But, just to show how universal the concept of a transaction is, here are a few more examples:

Software change control. Each new version of a software package potentially involves changes to several of the underlying source files. The new version is only defined when every single one of the changes has been made. Just try supporting a product with loads of intermediate versions.
Arranging a tennis match. A time must be agreed when all four players can be there. If only three can turn up, it won’t be much of a game. The actual transaction may fail many times before a mutually convenient time is agreed.
Almost any military maneuver involving more than one unit.
Taking off in an airplane. This involves an enormous of elements. For example, all the fuel must be on board, all the doors must be closed, air traffic control must have granted clearance, all the baggage must be on, etc. etc..

Inevitably, most transactions in life are to do with commerce, and basically involve ensuring electronically that money transfers, foreign exchange deals and so on do happen in a controlled manner with the minimum risk of something going wrong. Once you get into this, you start looking for transactions everywhere ... every time you use your credit card, for instance. It’s fascinating stuff.

This is why Microsoft has invested so much time and money into developing the product that they code-named Viper. The next three chapters will all look at various aspects of MTS:

This chapter examines what we can do with our DCOM applications to take advantage of Microsoft Transaction Server (including a look at how we can use ActiveX Data Objects to access database resources)
The next chapter looks at how it fits in with Microsoft Message Queue Server.
The third chapter in the sequence opens up the hood a little and looks at how we can develop resource managers to work with MTS. You won’t often need to do this, but, believe me, MTS will make a whole load more sense after we’ve done it.

In this chapter, we'll look specifically at:

Transaction theory
Setting up SQL server
How to use ActiveX Data Objects
Object-oriented programming, components and tiered application development
How MTS runs the show
Transaction context
Resource dispensers
The shared property manager