5.2 Homogeneous Synchronous Drawbridges

A homogeneous synchronous drawbridge is designed to connect two fortresses, both built on similar technology bases (e.g., both .NET or both WebSphere). In contrast, heterogeneous synchronous drawbridges allow any two fortresses to work together, whether they are on similar technologies or not. Why, then, should we bother with homogeneous synchronous bridges at all?

Homogeneous synchronous bridges have two redeeming features that make them worth considering. First, homogeneous synchronous bridges are faster than heterogeneous synchronous bridges. Second, at least today, they have more built-in functionality, especially in the security area.

The reason they are faster is that they are hardwired to the underlying component model. Remember that all modern synchronous drawbridges are based on remote method invocations on components . When the donor and recipient fortresses are using the same component model, both the infogram and the transport protocol can be optimized for the component technology of the two fortresses (say, .NET).

When both fortresses are built on a J2EE system (such as WebSphere), the homogeneous synchronous drawbridge usually uses a variant of RMI/IIOP (pronounced "RMI over IIOP"). RMI stands for Remote Method Invocation. IIOP stands for Internet Inter-ORB Protocol. (ORB, by the way, stands for object request broker.) IIOP is the old CORBA (Common Object Request Broker Architecture) component protocol. It is owned by the OMG (Object Management Group).

The fact that RMI and IIOP appear together in the same term suggests a relationship between the J2EE and CORBA protocols. And in fact there is ”at least a political relationship. Originally, the Java-Sun folks came up with their own component protocol, which they called simply RMI. As originally conceived, RMI had nothing to do with CORBA. However, Sun was also a leading member of the OMG, which was officially pushing the CORBA IIOP protocol. The fact that the OMG-Sun folks were advocating one protocol and the Java-Sun folks were advocating another was quite embarrassing to all involved. Eventually these two protocols came together in a shotgun marriage orchestrated primarily by IBM. The combined protocol was called RMI/IIOP.

RMI/IIOP was supposed to be a Java standard that could link together any two Java vendors, and even Java and CORBA vendors. In fact, however, each vendor evolved its own proprietary version of RMI/IIOP, and the modern perspective is that two different Java vendors are no more homogeneous than a Java vendor and Microsoft are. If you need to synchronously link two or more fortresses that are built with different Java implementations (say, WebSphere and WebLogic), I recommend that you link them using heterogeneous synchronous drawbridges, which I will cover in Section 5.3.

The major competition to RMI/IIOP in the homogeneous synchronous drawbridge space is Microsoft. Microsoft really has two homogeneous synchronous drawbridge technologies. The older technology is known as DCOM (for Distributed Component Object Model, whatever that means!). The newer technology is known as .NET Remote Binary Protocol, which does not seem to have, as yet, attached itself to an acronym. (I know, it's hard to imagine Microsoft passing up an acronym opportunity!)

Homogeneous synchronous drawbridges have three unique capabilities not found today in heterogeneous synchronous drawbridges:

Autosecurity
Instance management
Transaction flow

Autosecurity refers to the ability of the system to automatically provide some security features administratively. Because this capability is more relevant to the discussions of guards and walls, I will cover autosecurity in Chapter 7 ( Guards and Walls).

Instance management refers to the ability of the system to provide for the sharing of component instances (and the resources they require) among many clients . This capability can be useful if your architecture makes extensive use of rich clients. Fortress architectures are less likely to use rich clients, favoring instead thin clients, so I won't be covering instance management in this book.

Transaction flow refers to the ability to carry a transactional context across process boundaries. From a fortress perspective, this means that work done by the donor fortress can be transactionally coordinated with work done by the recipient fortress.

As I pointed out in Chapter 3 (Transactions), there are three types of transactions: (1) tightly coupled single-resource, (2) tightly coupled multiple-resource, and (3) loosely coupled multiple-resource. Transaction flow across drawbridges is most relevant to tightly coupled multiple-resource transactions. Loosely coupled multiple-resource transactions can also be coordinated across a homogeneous synchronous drawbridge, but transactional flow is not relevant to this type of coordination today, although this may change in the future. For now, you will be doing any loosely coupled coordination yourself. I will discuss the coordination of loosely coupled multiple-resource transactions in Section 12.2.4, on loosely coupled transaction managers.

Figure 5.6 shows a tightly coupled multiple-resource transaction crossing a homogeneous synchronous drawbridge. As discussed in Chapter 3, DTC (the distributed transaction coordinator ) is managing the overall transaction coordination.

Figure 5.6. Tightly Coupled Multiple-Resource Transaction Crossing a Homogeneous Synchronous Drawbridge

All homogeneous synchronous drawbridge technologies allow you to flow the transaction from fortress to fortress. However, just the fact that you can flow a transaction across fortresses does not mean that you should . The problem with flowing transactions across fortresses has to do with the relationship between database locks and trust boundaries.

To guarantee consistent updates, databases use database locks extensively. Database locks prevent users from updating records until those record updates can be done safely ”in other words, until existing transactions already accessing those records have completed.

When the transaction spans fortresses, one fortress is forced to hold onto its database locks until the other fortress is ready to complete its transaction. Unfortunately, this means that the donor fortress is at least partially blocked until the recipient fortress completes its updates.

This is a violation of the basic trust rule, the rule that states you trust your fortressmates and nobody else. In particular, you never allow anybody outside your fortress to dictate how long you will hold database locks, and you can't have tightly coupled transactions across fortresses without holding locks. Ergo, we don't like transactions across fortresses.

This is not to say that flowing transactions across distributed components is a bad idea. In fact, that capability is used extensively inside fortresses, a topic I will discuss further in Chapter 11 (Business Application Fortresses). It is fine to have components blocked on other components, as long as those two components are in the same fortress and therefore, by definition, trust each other. So transaction flow within a fortress is fine. Transaction flow across fortresses is a no-no.

You might think that I am against the use of homogeneous synchronous drawbridges. After all, their built-in security offers nothing at the drawbridge level. Their instance management is useful only for rich clients. Their ability to flow transactions is a violation of the trust rule. What's left?

One thing that's left is speed. If response time is your name , then homogeneous synchronous drawbridges are your game. But do be careful here. Speed is generally overrated. What you do is usually more important than how fast you do it. If the recipient fortress is going to do any substantial amount of work (and if it isn't, you have a poor software fortress architecture), then even relatively slow drawbridge traversal times will usually be white noise in the background. Speed usually doesn't matter as much as size ”at least, the size of the workload.

The autosecurity features should also not be dismissed lightly. They may have little to offer at the drawbridge level, but they have quite a bit to offer in constructing guards and walls. I will come back to that topic in Chapter 7 (Guards and Walls).