11.6 Messaging Objects in Different Address Spaces

At this point in the uses case, the ATM needs to send a message to the Bank object, asking it to process a transaction (passing the Withdraw transaction object as an explicit argument). It is here that the developer realizes that the ATM object lives in one address space (the ATM application) but the Bank lives in a different address space (the Bank application). I argued earlier that the ATM and Bank objects can be viewed as being in the same address space. This is due to a technique that employs proxies for the ATM and the Bank objects in each other's address spaces. The ATM cannot send a direct message to a Bank, so it sends a message to a Bank proxy that lives in the ATM's address space (see Figure 11.7). This proxy packs up the request and transaction object and ships it across the network to an ATM proxy that lives in the Bank's address space. The ATM proxy unpacks the request, reconstitutes the transaction object, and sends the process message to the real Bank object. The real ATM and Bank are completely unaware that they are really talking to proxies. This allows a designer to ignore the distributed facet of a distributed application during high-level design, leaving the gory details to low-level design proxy classes. The high-level of our design simply shows an ATM object sending a process message to a Bank object, when in reality our system is significantly more complex.