When I, back in 1998, first read about MTS it felt in a sense like coming home. Since my work almost always involves a relational database, transaction handling is utterly important to me. I had been doing distributed objects with CORBA, trying to figure out how to best achieve reusability. At this point, I realized that it was transaction handling I was missing in my earlier efforts.

With MTS, I could now build a new component that writes data to a database and uses an existing component, and it would all be handled in one transaction. In the figure below I’ve written a new component, called Bar, that stores information in a database. Bar also uses my good old Foo component. Bar and Foo both have the Requires Transaction transaction attribute. When using MTS, Bar creates a Foo with the IObjectContext::CreateInstance.

With these requirements fulfilled, the updates in the Foo and Bar databases will be handled in one transaction coordinated by MS DTC.

But what if Bar is ill behaved? You could miss a SetComplete. That could result in strange lock behavior in both BarDB and FooDB. You could also forget to create Foo with IObjectContext::CreateInstance (MTS). That would result in a transactional behavior that you didn’t expect. It could very well appear as if it is something wrong with the Foo component. If you have written both Bar and Foo it doesn’t matter if the problem is in Foo or Bar. It is still your mistake.

Now imagine there is a third party that has written Bar. The problems that occurs in your environment all scream error in Foo. The symptoms are remaining locks in FooDB, deadlocks, etc. But the problem is actually in Bar. The author of Bar was unfamiliar with the discipline of doing composition with MTS. As a result you might end up in endless discussions with him or her about whose fault it is. (I’m talking from personal experience here).

In COM+ this might be less of an issue. IObjectContext::CreateInstance is obsolete and there is also the AutoComplete feature, but you still have to understand what you are trying to accomplish regarding transactions.

This leads me to conclude that in this situation you cannot treat Bar as a black box and just install it in your environment. You need to look inside of it. You need to take a white box perspective. Preferably you should also rebuild it on location.

While I am at it, let me describe another scenario where black box treatment of MTS components isn’t recommended.

The situation is quite similar. Bar is provided by a third party. But this time let us focus on the role-based security of Foo. Foo and Bar are running in separate packages on the server, FooPack and BarPack, both with an identity called MTSExec (for example).

If you’re using implicit security, that is, you have a role on a component (or interface) and have enabled authorization checking on the package, the direct caller is checked for role membership. Take a look at the figure below. Let’s say that the BaseClient’s NT account is ingo. Hence, the direct caller of DoStuff is ingo. Direct caller of DoFooStuff is MTSExec (since BarPack is executed by NT account MTSExec). Foo has a role assigned to it, FooRole. MTSExec is included but ingo is not. Bar has a role called BarRole. Ingo is included in that role.

This means that ingo cannot create a Foo instance and call DoFooStuff. He can however create a Bar object and call DoStuff, which in its turn calls DoFooStuff. In other words, ingo has succeeded calling a method (via a “mediator”) that he can’t call directly. This might be perfectly all right, though it is not good if this situation occurs without you knowing about it.

This implicates, once again, that you cannot bring in a MTS component in your environment without looking under its “hood”. You need to take a white box perspective.

Although MTS gives you the means to compose new functionality from existing pieces, without worrying about how they are implemented, I have showed you two cases where a look under the “hood” is good advice. If you take a white box perspective in these situations you can avoid unpleasant surprises.

Ingemar (Ingo) Lundberg works for Banverket (The Swedish National Rail Administration, http://www.banverket.se) at the software development department. When it comes to development strategies, Ingo has been the driving force in bringing Banverket from terminal based solutions on VMS, via X-windows, to the current Windows NT environment. He has developed an MTS-based architecture that is used in all in-house applications of Banverket.
Reach Ingo at [email protected]