1 / 14

OO Abstractions for Distributed Programming

OO Abstractions for Distributed Programming. August 1999 Communications of the ACM. R. Guerraoui and M. Fayad. Going beyond wrapping existing toolkits with OO-like dressing. An OO program reflects a problem’s structure through a correspondence between objects of the

steve
Download Presentation

OO Abstractions for Distributed Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OO Abstractions for Distributed Programming August 1999 Communications of the ACM

  2. R. Guerraoui and M. Fayad Going beyond wrapping existing toolkits with OO-like dressing

  3. An OO program reflects a problem’s structure through a correspondence between objects of the application domain and objects of a computational model. If the application domain is a university then there are: student objects graduate students undergraduates course objects registration objects exam-cram objects...

  4. Success of OO model is that it seems to improve productivity and the quality of software development. One application domain that has been particularly successful is that of GUI window, mouse, buttons, event-handlers,…. A distributed system is just another example of an application domain

  5. Viewing a distributed system as an application domain means: identify the fundamental abstractions classify and organize these abstractions build the appropriate API However: Current practice is to wrap built-in toolkits with an OO dressing. “The Outfit does not make the monk”

  6. 1. Built in prototypes or products are wrapped in OO interfaces 2. A marketing campaign accompanies this wrapper that advertises the benefits of the new OO line 3. Particularly true for distributed programming toolkits that are made CORBA compliant through a redesign of interfaces using IDL. “While an OO interface tends to make the functionality of the distributed toolkit easier to understand, it does not fundamentally improve its modularity, extensibility, or the reuse of components, all concepts of what OO programming is about.”

  7. The main problem here is that of granularity. Wrapping a large monolithic toolkit behind an OO interface and calling it a service does not make it object oriented. CORBA is partially to blame. They are in the process of standardizing CORBA transaction service CORBA event service CORBA fault-tolerant service (entity redundancy)

  8. transaction service a set of interfaces for transaction manipulation and atomic commitment supports the two-phase commit protocol event service set of interfaces for event manipulation event manipulation uses the publish/subscribe design pattern fault tolerant failure of an object is hidden by group membership. CORBA SERVICES(proposed)

  9. What’s wrong? 1. The services are considered separately. “their underlying common components are not captured. An OO design of the underlying problem domain would have led to the capturing and factoring out of common underlying concepts such as persistence, failure detection, multicast, and distributed agreement.” 2. There is no extensibility “given the large-grain level at which the interfaces are provided, it is not clear at all how one could extend any of these services.”

  10. Situations needing better designed services Extending the transaction service to provide an alternative commitment protocol. A fault tolerant service or event services may need some form of globally ordered view requiring a transaction service. “The OMG has specified the most advanced distributed system infrastructure that turns out to be viable from an industrial perspective. Our observations mainly state that complying with those specifications does not make a distributed service object oriented, nor does it mean that the service is more modular and extensible or that its components are easier to share and reuse.”

  11. Good design means 1. identify the basic abstractions 2. build classes to encapsulate these abstractions 3. build support for the relationships and interactions between these abstractions. For distributed programming issues are fundamentally how to represent the concepts of message, machine, process, failure, agreement,… RMI, Distributed event processing,…should be built out of these basic abstractions. A programmer can use a high-level abstraction of RMI if it fits the requirements

  12. Good design means following the ‘Hollywood principle’ “Don’t call us, we’ll call you.” for components that may not fit some needed application.

  13. An event driven threaded communication system built on top of RMI has more overhead and is much more difficult to coordinate than one using the more basic abstractions of message and port.

  14. In summary: distributed programming is not about hiding distribution. distributed programming should be about exhibiting and understanding the characteristics of distribution distributed services are useful, but should be viewed as abstractions that are made of lower level abstractions that are yet to be appropriately defined.

More Related