Distributed Objects—A Welcome Abstraction
Today most developers accept object-oriented design and programming as the tenets of modern software development. Whenever humans have to deal with anything as complex as creating large software systems, using effective abstractions is critical. Objects are the fundamental abstractions used today. Therefore, if developers acknowledge the benefits of objects, it makes sense to apply them to distributed scenarios.
Distributed object technologies allow objects running on a certain machine to be accessed from applications or objects running on other machines. Just as RPC makes remote procedures seem like local ones, distributed object technologies make remote objects appear local. DCOM, CORBA, Java RMI, and .NET Remoting are examples of distributed object technologies. Although these technologies are implemented quite differently and are based on different business philosophies, they are remarkably similar in many ways:
They’re based on objects that have identity and that either have or can have state. Developers can use remote objects with virtually the same semantics as local objects. This simplifies distributed programming by providing a single, unified programming model. Where possible, developers can factor out language artifacts specific to distributed programming and place them in a configuration layer.
They’re associated with a component model. The term component can be defined in a number of ways, but for this discussion we’ll say that a component is a separate, binary-deployable unit of functionality. Components represent the evolution of object-oriented practice from white-box reuse to black-box reuse. Because of their strict public contracts, components usually have fewer dependencies and can be assembled and relocated as functional units. Using components increases deployment flexibility as well as the factoring-out of common services.
They’re associated with enterprise services. Enterprise services typically provide support for such tasks as transactions, object pooling, concurrency management, and object location. These services address common requirements for high-volume systems and are difficult to implement. When the client load on a distributed system reaches a certain point, these services become critical to scalability and data integrity. Because these services are difficult to implement and commonly needed, they’re generally factored out of the developer’s programming domain and supplied by the distributed object technology, an application server, or the operating system.