14.5 The CheckInventory Drawbridges

Now I'll turn my attention to the drawbridges used by the CheckInventory treaty, starting with the VendorGateway fortress. Figure 14.12 shows the SAD for CheckInventory.

Figure 14.12. New SAD for CheckInventory

Superficially the CheckInventory treaty looks like the ProcessOrder treaty, as you can see by comparing Figure 14.12 to Figure 14.9. Both treaties involve three fortresses . Both feature an asynchronous relationship with the Inventory fortress. However, this is where the similarities end.

The first difference is at the gateway level. The incoming request to the CustomerGateway fortress originated with emissary code ”that is, code that is properly owned by the fortress itself, although it is running on the browser ”notwithstanding the ever present suspicion that the request could have originated with a rogue system. The incoming request to the VendorGateway fortress, on the other hand, certainly did not originate with code that had anything to do with my fortress.

Although I may not know much about the originator of the incoming request, I can make two reasonable assumptions. First, there won't be just one originator; there will be many. All of my vendors will be using this portal to get information about their inventory status. Given that there will be so many vendors, it stands to reason that at least some of them will be using a different technology for their fortresses than I am using for mine. Therefore I must assume that the drawbridge is heterogeneous. My second assumption is that at least some of these vendors will need to be using the Internet to connect to my system. Given today's state of technology, this scenario implies SOAP requests delivered via HTTP.

Although SOAP/HTTP is a synchronous drawbridge technology, as I discussed in Chapter 5 (Synchronous Drawbridges), I really don't need this gateway to be synchronous. I don't plan to return anything to the requestor , at least not from this fortress. I also don't expect the bulk of the work to be blocking. If I could figure out how to deliver SOAP over HTTP asynchronously, I would do so. But like it or not, SOAP over HTTP is basically a synchronous drawbridge.

Why don't I expect the bulk of the CheckInventory work to be blocking? The answer is apparent in the SAD (see Figure 14.12). The VendorGateway fortress is just a SOAP veneer for the VendorInventoryCheck fortress, where the real work will be done. And the drawbridge connecting the VendorGateway and VendorInventoryCheck fortresses is CheckVendorInventory. This is an asynchronous drawbridge (as indicated by the half- arrowhead in the SAD). So we know the work is going to be nonblocking with respect to the VendorGateway fortress. And well it should be. I like my vendors, but I don't want them interfering with valuable computer cycles that could be better used for processing customer orders. I'll process vendor requests when I have absolutely nothing better to do.

The GetInventoryByVendor drawbridge used by VendorInventoryCheck to access the Inventory fortress is slightly different from the UpdateInventory drawbridge used by OrderManagement. The latter returns just a touch of information ”namely, an acknowledgment that the inventory was updated. The former returns quite a bit of information, the entire list of inventory "owned" by this vendor. A logical, heterogeneous approach to packaging this much information is as an XML document.

I have said that the drawbridges owned by the Inventory fortress are asynchronous, but I haven't discussed whether they are heterogeneous or homogeneous asynchronous. If you recall from Chapter 6 (Asynchronous Drawbridges), the homogeneous variety adds precious little functionality to what one gets with the heterogeneous variety, and it does add quite a few limitations. So in general, when I make a drawbridge asynchronous, I almost always make it heterogeneous as well.

This is quite different from the approach I would take with a synchronous drawbridge. When my drawbridge is synchronous, there are compelling reasons to look for homogeneity where it does not unduly restrict my fortress options.

The only remaining communications issue is the return of the inventory information to the vendor. This can't be done synchronously, even though the incoming request came in synchronously. Why not? Because the processing of the incoming request has long ago been completed. So I want to return the information asynchronously. Now you might think that no asynchronous technology works across the Internet and is technology agnostic . But if you did, you would be wrong. There is such a technology, and if you are reading this book, you probably use it almost every day of your life. This technology is e-mail. So I decide I will e-mail the final result back to the vendor. If I don't get around to sending out the e-mail until 2:00 in the morning, I don't think my vendor will complain.