6.7 Performance Problems of Asynchronous Drawbridges

Now that I have convinced you to use asynchronous drawbridges based on message queues, I will take the opposite viewpoint: I'll tell you why you shouldn't.

The biggest problem with asynchronous drawbridges based on message queues is that they force you to involve our old friend DTC, the distributed transaction coordinator . Remember DTC? She's the one required when a transaction involves more than one transactional resource ”say, a database and a message queue. These are the types of transactions we're using when our donor fortress both updates a local database and makes an asynchronous interfortress request from within the same transaction.

There is a huge difference between a tightly coupled multiple-resource transaction (one involving DTC) and a tightly coupled single-resource transaction (one that doesn't require DTC). You can see the distinction easily in a sequence diagram showing the communication that must occur among the various parties in both the multiple-resource case (Figure 6.6) and the single-resource case (Figure 6.7).

Figure 6.6. Sequence Diagram for Multiple-Resource Transactions

Figure 6.7. Sequence Diagram for Single-Resource Transactions

The question is, can we eliminate the cost of DTC without giving up either the coordination between the donor transaction and the insertion of the infogram or the coordination between the receipt of the infogram and the recipient transaction? And the answer is, sometimes.

The way to eliminate DTC is to get rid of all but one of the transactional resources involved in the transaction. Who can we eliminate? We have only two transactional resources: the database and the message queue. The database isn't going anywhere , so that leaves only one candidate: the message queue. How do we get rid of the message queue? We have two options.

The first is to have the message queue vendors replace the underlying data storage that is now used by the message queue with a database. And not just any database, but the one we are using for the donor and recipient fortresses . Consider, for example, Microsoft. If Microsoft rewrote MSMQ (its message queue technology) to use SQL Server (its database technology) rather than MSMQ's native data store, then any fortress that used SQL Server as its data strongbox would be able to use MSMQ without having to involve DTC. IBM could take a similar approach with its message queue and database.

In fact, most of the major database vendors have announced plans to do exactly this. But until this work is completed, we have to follow the second approach to banishing DTC. In this approach we build our asynchronous drawbridges on top of the database instead of on the message queue.

Building an asynchronous drawbridge on top of a database is more difficult than building one on a message queue, but it is not an impossible chore. For example, I could allocate a table named ProcessPayment that represents the ProcessPayment drawbridge used by the CreditCard fortress to make requests of the Payment fortress. The rows in ProcessPayment could include these fields:

CreditCardNumber
PaymentAmount

The envoy implemented in the CreditCard fortress would append a new record to the ProcessPayment table. The guard implemented in the Payment fortress would check to see if there is a row in the ProcessPayment table. If there is, the guard would read the first such record, process it, and delete the row. Not too horrible, all things considered .

The major problem with the database approach is that it pays the jack pot only when both fortresses are using the same database as their data strongbox. If one fortress is built on Microsoft's .NET and the other is built on IBM's WebSphere, the two fortresses will probably not be using the same database. Even if both fortresses are using Microsoft technology, they will often be using their own private versions of SQL Server. Which one, then, becomes the holder of the message table?

The use of a database as an asynchronous drawbridge technology could be criticized as violating trust laws. Remember, the fundamental idea of a software fortress is that is represents a trust boundary. One can argue that the sharing of a database between two different fortresses requires a higher-than-reasonable degree of trust between the two fortresses.

My own opinion on this subject is that a data strongbox does not necessarily need to be a fully self-contained database. Using a logical partition of a database is an acceptable implementation of a data strongbox. What is critical is that the database be configured so that the logical partition is accessible only to the processes within that fortress.

If you accept this argument, you can use a single physical database to implement not only the data strongboxes in two different fortresses, but also the asynchronous drawbridge tying the two together. From a security perspective, we would logically divide the database into three pieces, as shown in Figure 6.8. Only the donor fortress would be able to access the portion allocated to the donor strongbox, and only the recipient fortress would be able to access the portion allocated to the recipient strongbox. Both fortresses would be able to access the portion allocated to the drawbridge.

Figure 6.8. Logical Partitioning of a Database

I can't say I'm delighted with having to implement an asynchronous drawbridge myself . I would prefer to have someone else ”such as Microsoft, Oracle, or IBM ”physically unify the various storage technologies.

Even when the vendors unify their storage technologies, new problems will be created. Let me take Microsoft as an example. Sooner or later, we can expect the different groups in Microsoft to unify all storage under the umbrella of SQL Server. This unification will allow the different systems to work together much more efficiently (no DTC!).

But what happens, in this new Microsoft world, when we need to tie in an Oracle database to a fortress that is otherwise built on Microsoft technology? You guessed it: Suddenly DTC is crawling out of the woodwork. So in the Microsoft world, the cost of using Oracle for some specific applications will be much higher than the cost of using SQL Server for those same applications. Presumably you will not have the choice about whether or not you use SQL Server because every Microsoft application, including the operating system, will depend to some extent on SQL Server. Your only choice will be whether or not to introduce Oracle (and therefore DTC) into the fray.

The fact that DTC is required with the Oracle implementations is a powerful incentive to ban Oracle from the Microsoft fortresses. Not only will Oracle be much slower than SQL Server (through no fault of Oracle's), but Oracle may potentially slow down Microsoft applications that have little to do with Oracle other than having the misfortune to be somehow transactionally related to the Oracle-based work.

Clearly there is no cut-and- dried solution. Every fortress and every drawbridge has a unique problem that requires a unique solution. That's why you, Mr. or Ms. Enterprise Architect, are paid the big bucks.