Why Distribute Objects?
In Chapter 1, we discussed some of the optimal data/function partitioning capabilities that you’d like to have available when developing distributed applications. These included being able to distribute data/function “modules” freely and transparently, and have these modules be defined based on application structure rather than network distribution influences. Distributed object systems try to address these issues by letting developers take their programming objects and have them “run” on a remote host rather than the local host. The goal of most distributed object systems is to let any object reside anywhere on the network, and allow an application to interact with these objects exactly the same way as they do with a local object. Additional features found in some distributed object schemes are the ability to construct an object on one host and transmit it to another host, and the ability for an agent on one host to create a new object on another host.
The value of distributed objects is more obvious in larger, more complicated applications than in smaller, simpler ones. That’s because much of the trade-off between distributed objects and other techniques, like message passing, is between simplicity and robustness. In a smaller application with just a few object types and critical operations, it’s not difficult to put together a catalog of simple messages that would let remote agents perform all of their critical operation through on-line transactions. With ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access