6.2 Implementation of Asynchronous DrawbridgesKnowing that asynchronous drawbridges use message queues is only part of the problem. We still have to decide on these issues:
On the donor side, the envoy deals with the message queue. The envoy acts as a single exit point that deals with all the ugly details of formatting the infogram , setting up any security requirements, and handling error conditions. This architecture is shown in Figure 6.1. Figure 6.1. Asynchronous Drawbridge Architecture
When a subsystem within the donor fortress needs to communicate with the recipient fortress, that subsystem makes a request of the envoy. The envoy is built in an appropriate native (for that fortress) technology, and requests to the envoy use native communications. If the donor is a business application fortress built on .NET, the envoy will probably be either a COM+ component or a .NET class, and the internal communications to that envoy will probably be transported via the .NET Remote Binary Protocol or a variant of RMI/IIOP. On the recipient fortress side, the guard is often implemented as a dedicated process, one whose only purpose is to execute a tight loop in which it waits for a message to appear on the queue, grabs the message, and passes it on to a guard component. If the recipient fortress is a business application fortress, the guard process will probably invoke a component-style method on the guard component. The guard component will check the message for appropriate security clearance, tease out its data, and repackage it for consumption by other business components inside the fortress. |