14.4 The ProcessOrder Drawbridges

Now that I have a good overview of what fortresses I have and how they will work together, my next goal is to understand the drawbridge requirements better. I'll start with a SAD for the ProcessOrder treaty and look specifically at each drawbridge interaction. The overall SAD for ProcessOrder is shown in Figure 14.9.

Figure 14.9. New SAD for ProcessOrder

Now let me start going through the drawbridges. The first ProcessOrder interaction occurs between the browser and the CustomerGateway fortress. This interaction is specifically governed by CustomerGateway code running on the browser. As I discussed in Chapter 10 (Internet Fortresses), this is what Pat Helland calls emissary code.

The next drawbridge crossing occurs over the Place Order drawbridge, used by the CustomerGateway fortress to send an order for processing to the OrderManagement fortress. The SAD shows asynchronous drawbridge. You might wonder why I'm using a synchronous drawbridge in light of my emphasis on asynchronous drawbridges. And in fact, I do believe that we can probably design the OrderManagement fortress so that the overall order flow is asynchronous relative to the CustomerGateway fortress. But then why not use an asynchronous drawbridge?

The reason for the synchronous drawbridge is that I assume I want to let Claire, the customer, know two things before she leaves my Web site. First, I want her to know that her order has definitely been received into my processing queue. Second, I want to assign her order an ID so that she can return to my Web site and check on her order's progress. Although I haven't specified this functionality at this time, I assume it will be a straightforward extension of my basic architecture.

So I have conflicting goals. On the one hand, I want to process the order asynchronously relative to Claire sitting at her browser. As I discussed in Chapter 6 (Asynchronous Drawbridges), asynchronous processing gives me good load balancing and reliability, or at least good potential for these things. On the other hand, I don't want Claire to leave until I have at least assigned the order ID. This implies the need for a synchronous drawbridge. How do I resolve this problem?

The standard design technique, discussed in Chapter 13 (Software Fortress Design Review, Question 17) is to build a synchronous drawbridge fa §ade to an asynchronous fortress. I would probably build this fa §ade using a synchronous technology between the CustomerGateway fortress (the presentation fortress) and the guard for the OrderManagement fortress (the business application fortress). Then I would have a synchronous communications request between the guard of the OrderManagement fortress and the internal worker who assigns the order ID. The worker bee returns the order ID to the guard, who returns it to the presentation fortress, who can then send it back to Claire. Once the order ID assignment has been made, the guard can continue with the rest of the order processing. This part can be done asynchronously, as Figure 14.10 shows.

Figure 14.10. Synchronous Drawbridge Fa §ade and Asynchronous Fortress

The drawbridge that accepts the request from the CustomerGateway fortress is titled PlaceOrder. I have said that this is a synchronous drawbridge, but I haven't said yet whether I would use heterogeneous or homogeneous technology. In general, I prefer to use the same technology base for the presentation fortress as for the business application fortresses to which it is connected. The main reason is that some synchronous connection between the two is often necessary, and the most efficient synchronous drawbridges are of the homogeneous type. Therefore, I would probably make the PlaceOrder drawbridge a homogeneous synchronous drawbridge.

As long as we're dealing with drawbridges connecting the CustomerGateway and the OrderManagement fortresses, we might as well look at the gateway used to return the order number to the CustomerGateway fortress. The rule of thumb here is that when we have a drawbridge whose role is to return information from a synchronous drawbridge, it will be of the same type as the original drawbridge. If the original drawbridge (PlaceOrder) is homogeneous synchronous, then so will be the return drawbridge (OrderNumber).

As I have already discussed, all synchronous drawbridges are based on component systems. One way to implement the PlaceOrder and OrderNumber drawbridges is to have a dual function of envoy and guard on both sides of the fortress, as Figure 14.11 shows.

Figure 14.11. Component-Based Implementation of Synchronous Drawbridge

There is one more question. What kind of asynchronous technology do we use to communicate between the incoming guard of the OrderManagement fortress and the second worker bee, the one who will start off the asynchronous order processing? My answer is simple: Who cares? Let the fortress architect worry about that. It isn't my problem. I am an Enterprise-Level Architect. I have bigger fish to fry.

Speaking of bigger fish, let's look at the drawbridges connecting the two business application fortresses (OrderManagement and Inventory) that are involved with order processing. The Inventory fortress accepts the request through its UpdateInventory drawbridge and returns the answer through the OrderManagement's UpdateInventoryAck drawbridge. ( Ack , by the way, stands for "acknowledgment," and just means that the request has been completed.) This flow is most clearly shown in Figure 14.9.

But wait! What the heck does "returns the answer" mean? The SAD in Figure 14.9 shows the UpdateInventory drawbridge as an asynchronous drawbridge (that's what the half-arrow means). How does an asynchronous drawbridge "return" anything? Isn't the whole point of asynchronous that the requestor goes along doing whatever it chooses without waiting for an answer?

Yes and no. Keep in mind that the requestor here is not the normal kind of requestor. It is not a person. It is not a component. It is not even a process. It is a fortress . A fortress consists of many different processes, including processes that can check message queues for incoming messages and process them independently of whatever else is happening in the fortress. The asynchronous return represented by UpdateInventoryAck is like the next iteration in a workflow system.