4.1 Drawbridge Overview

A drawbridge is a gateway into a fortress. A drawbridge allows something outside of the fortress to pass information into the fortress. I call a unit of information that passes over a drawbridge an infogram . The drawbridge specification defines both the format of the infograms and the protocol used for their delivery. An infogram is a complete and self-contained information packet that meets the format and protocol requirements of a specific drawbridge.

Because what is outside the fortress is in a different process than anything inside the fortress (for trust boundary requirements, if nothing else), we can assume that a drawbridge will require some form of interprocess communication. Depending on the drawbridge technology, an infogram could take the form of a remote method invocation, a text string delivered over a message queue, or a SOAP call over HTTP, all of which are forms of interprocess communication. We would not expect to see an object method invocation used for a drawbridge because object method invocations are strictly intraprocess.

A fortress may have multiple drawbridges. In Figure 4.1, for example, a business application fortress can accept infograms from either a presentation fortress or another business application fortress, with drawbridges designed to meet the specific needs of each fortress.

Figure 4.1. One Fortress with Two Drawbridges

Infograms must come from somewhere, and usually that some where is an envoy in another fortress. The envoy, remember, is the specific fortress entity responsible for placing infograms on the drawbridge for delivery to the ally fortress. I refer to the fortress that is creating and sending the infogram as the donor fortress and the one receiving the infogram as the recipient fortress.

I use the term homogeneous to describe a situation in which both the donor and the recipient fortresses are on a common technology base (such as both .NET) and heterogeneous to describe a situation in which the two fortresses are on different technology bases (such as one on .NET and the other on J2EE).

It is helpful to know whether we are facing a homogeneous or heterogeneous situation because we can optimize our draw bridges in the homogeneous case. However, this optimization is usually not worth forcing both software fortresses to use a common technology. It is merely an optimization that we can apply opportunis tically when we happen to find ourselves in a homogeneous situation.

Some people advocate designing all drawbridges for the heterogeneous situation, assuming that these drawbridges can be used for new treaty relationships in the future. In my experience, recipient drawbridges are usually hardwired for only one treaty relationship, and it is not common that more than one donor fortress will be sending infograms through a single drawbridge. Should an existing fortress need to accommodate a new treaty, it will likely need a new drawbridge for that new treaty relationship, and that drawbridge can be optimized at that time. This situation is depicted in Figure 4.2.

Figure 4.2. An Unlikely Scenario

Although I often talk about a message being received into a fortress, in fact messages from outside the fortress never pass the guard. I will talk more about guard implementations in Chapter 7 (Guards and Walls). For now, assume that the infogram flow will go through the following typical sequence, as illustrated in Figure 4.3:

1. The infogram is created by the envoy of the donor fortress. In Figure 4.3 the donor fortress is a business application fortress.

2. The infogram is sent to a compatible drawbridge in the recipient fortress, which in this case is also a business application fortress.

3. The infogram is received by the recipient fortress guard.

4. The guard is highly suspicious and subjects the infogram to stringent security tests.

5. The guard decides that the infogram is from a trusted source, and that it meets all other security requirements.

6. The guard pulls apart the infogram and transforms it into a form that is useful within the fortress. Because the fortress in Figure 4.3 is a business application fortress, a reasonable internal form might be a distributed component method invocation,   la COM+ or Enterprise JavaBeans.

7. Information passes freely within the fortress without further need for security analysis until the fortress has fully processed the infogram.

8. If the recipient fortress needs to communicate back to the donor fortress, it does so through one of the donor fortress's drawbridges.

Figure 4.3. Infogram Flow

An infogram is therefore a packet of data that is intended for interfortress communication. It is targeted at the guard and usually does not correspond to data formats used within the fortress.

There is no standard for infograms, either for the format of the information they carry or for the communications protocols over which that information is delivered. However, there are some general categories of drawbridges, each with, if not a standard for infograms, at least some strong hints about the nature of the infograms they will accept. I will discuss these categories in Chapters 5 and 6.

Drawbridges can be either synchronous (blocking) or asynchronous (nonblocking), and either heterogeneous (connecting fortresses with different technologies) or homogeneous (connecting fortresses with the same technology). Because these characteristics are independent of each other, we can theoretically have four basic types of drawbridges: heterogeneous synchronous, homogeneous synchronous, heterogeneous asynchronous, and homogeneous asynchronous. In Chapters 5 and 6 I will cover synchronous and asynchronous drawbridges, respectively.