Sponsored Link •
This article fleshes out the advantages and disadvantages of objects compared to documents when sending a service across the network to software, in the absence of a client-side user.
In Part 1 of this series, I demonstrated two approaches to defining the interaction between a client and a news feed server -- one involving documents and protocols and the other involving objects and interfaces. Now I'd like to compare their relative merits. First I'll look at the advantages of objects compared to documents, and then I'll cover their disadvantages.
One obvious difference between the object and document approaches is that developing news feed protocols involves network handshake and data-model design, whereas developing the news feed API requires object-oriented design. The object approach's object-oriented nature enables client and server programmers to work at a higher level of abstraction compared to the protocol and document approach. To explain what I mean, I'll relate a story about Bjarne Stroustrup, the creator of C++.
I first learned C++ in early 1992 from Borland's "World of C++" videotape, which begins with a short introduction by Stroustrup. He begins by saying that the main goal of C++ was to raise the level of abstraction in programming. As I watched the videotape, I was able to grasp the object-oriented concepts and C++ syntax presented, but I was puzzled by Stroustrup's comment. I wasn't sure what he meant by "raising the level of abstraction," and why he thought it was desirable.
In April 1999, I attended a small C++/Java conference in Oxford, England, at which Stroustrup gave a keynote. In the keynote, he claimed that the two ideals for programming should be: keep independent things independent, and work at the highest level of abstraction you can afford.
After the keynote, I asked Stroustrup why he felt working at as high a level of abstraction as possible was a fundamental programming ideal. He answered that it allows details to be hidden, which makes code shorter. "The more details, the more mistakes," he said. Plus, code size impacts maintainability: the more code you have, the harder it is to maintain. He also mentioned that code at higher levels of abstraction is amenable to tools that analyze and optimize. He summarized by saying that code written at a higher level of abstraction is easier to understand, write, and maintain.
I believe one advantage of the object approach is that programmers get the benefits, outlined above in Stroustrup's comment, of working at a higher level of abstraction. To a great extent, these are the same benefits reaped by programmers when they switch from procedural programming to object-oriented programming. When you write a client program that interacts with a server via an object sent across the network, you reap the benefits of object-oriented programming in your distributed system.
One of the benefits of object-oriented programming, for example, is its clean way of separating interface and implementation. One of the main strengths of Jini's architecture is that the network protocol by which a Jini service object talks across the network to a server is part of that object's implementation. Although a client and server need to agree on a network protocol to get the first object sent from server to client, once the first object is in place, client-server communication can take place via object interfaces.
Unlike an object, of course, a document cannot make a socket connection back across the network. Thus, for clients to interact with the documents they receive from a server, the client and server need to agree on a protocol as well as the document's data model. For example, if a user types information into a form contained in an HTML document, and presses Submit, the Web browser opens a socket to the Web server, and does, most likely, an HTTP POST that contains that information. The Web server processes this POST and returns another HTML document. If a client program wishes to interact with the server via documents, rather than just silently consume documents, the client and server must agree on protocols beyond the initial protocol that gets the document to the client.
Once a Jini service object has been downloaded into a client, by contrast, the client and server need only agree on that object's interface. The network protocol, which is part of the service object's implementation, can be different for different service vendors, and can change over time for the same vendor. (Note that because the service object is sent across the network to the client from the service provider, it will always be up to date. It will always be compatible with the service provider -- and will talk the correct network protocol.) As the network is one of the fussiest and most dynamic parts of the hardware being programmed, it is useful to be able to choose the most appropriate protocol for each situation.