Sponsored Link •
To me, the primary advantage of the object approach over the protocol approach is flexibility. By moving the contract between parties of a distributed system from the bits and bytes of network protocols to the higher level of abstraction of object interfaces, you gain flexibility in how you fulfill and evolve that contract. Because the contract of an object interface is couched in terms of behavior, not in terms of information (as with a document's data model), the contract of an object can be more abstract than the contract of a document. The more abstract a contract is, the more ways that contract can be fulfilled.
Perhaps the most important flexibility offered by the Jini service object is the service provider's ability to decide what protocol, if any, its service object will use to talk across the network. A service provider could, for example, fully implement the service locally in the service object itself. Or, a service provider could make the service object an RMI or CORBA stub that forwards all method invocations across the network to a remote object. The service object could also simply translate client requests received through the object's interface into the bytes of some proprietary socket protocol understood by the server. Or the service object could be a "smart proxy," which partially implements the service locally but sometimes enlists the help of a server or servers across the network. In short, a Jini service object gives the service provider the flexibility to choose the best protocol for each situation.
In his article, "The End of Protocols" (Resources), Jim Waldo, Sun's chief Jini architect, put it this way:
Systems that are based on a protocol [...] need to fit the needs of all clients and services to the single protocol. The protocol must be completely general, and as is often the case when something needs to be good for everything, these protocols are often less than optimal for particular, specialized communications. Protocol design, like any engineering design, is often a trade-off between efficiency and generality. In systems that are designed around a one-size-fits-all protocol, such decisions need to favor generality. [...] This [Jini's mobile proxy object] approach gives great flexibility to what protocol is actually used. Different services can invent their own specialized protocols that are optimized for that particular pair of proxy and service. Protocols can evolve over time as new ideas are tried out.
This flexibility in deciding how to implement the service object interface amounts to flexibility in managing the network -- whether to talk across the network at all, and if so, what protocol to use. This flexibility is extremely useful when working with distributed systems, because you get more choices in dealing with the most variable and unpredictable part of the distributed system: the network itself.
To discuss the material presented in this article, visit my discussion forum at: http://www.artima.com/jini/jf/objvsdoc2/index.html.
To discuss the material presented in this article, visit my discussion forum at: http://www.artima.com/jini/jf/objvsdoc1/index.html
About the author
Bill Venners has been writing software professionally for 14 years. Based in Silicon Valley, he provides software consulting and training services and maintains a Web site for Java and Jini developers, artima.com. He is author of the book: Inside the Java Virtual Machine, published by McGraw-Hill.
This article was first published under the name Objects versus Documents for Client Server Interaction, Part 2 in JavaWorld, a division of Web Publishing, Inc., July 2000.