Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Objects versus documents for server-client interaction, Part 2

Determining the best approach when there is no client-side user

By Bill Venners, JavaWorld.com, 07/28/00

  • Print
  • Feedback
In Part 1 of this series, I demonstrated two approaches to defining the interaction between a client and a newsfeed server: using documents and protocols and using objects and interfaces. Now I'd like to compare their relative merits. I'll discuss the advantages of objects as compared to documents, then the disadvantages.

TEXTBOX: TEXTBOX_HEAD: Using objects versus documents for server-client interaction: Read the whole series!

The advantages of objects

In the following sections, I will identify a few advantages of using objects for client-server interaction.

Raising the level of abstraction

One obvious difference between the object and document approaches is that developing newsfeed protocols involves network handshake and data-model design, whereas developing the newsfeed API requires object-oriented design. The object approach enables client and server programmers to work at a higher level of abstraction. To explain, I'll relate a story about Bjarne Stroustrup, creator of C++.

I first learned C++ in early 1992 from Borland's World of C++ videotape, which includes a short introduction by Stroustrup. He begins by saying the main goal of C++ was to raise the level of abstraction in programming. As I watched the tape, I was able to grasp the object-oriented concepts and C++ syntax, but I was puzzled by Stroustrup's comment. I was unsure of what he meant by "raising the level of abstraction" and why he found it desirable.

In April 1999, I attended a small C++/Java conference in Oxford, England, at which Stroustrup gave a keynote. In the speech, he cited two ideals for programming: keep independent things independent, and work at the highest level of abstraction you can afford.

Afterwards, I asked Stroustrup why working at the highest possible level of abstraction was a fundamental programming ideal. He said it allows details to be hidden, which makes code shorter. "The more details, the more mistakes," he said. Code size also impacts maintainability: the more code you have, the more difficult it is to maintain. Stroustrup also said that at higher levels of abstraction, code is more amenable to tools that analyze and optimize. He summed up by saying that code written at a higher level of abstraction is easier to understand, write, and maintain.

I believe the object approach is bolstered by the programming benefits, outlined above by Stroustrup, of working at a higher level of abstraction. To a great extent, programmers who switch from procedural to object-oriented programming reap the same benefits. When you write a client program that interacts with a server via an object sent across the network, the advantage of using object-oriented programming in your distributed system is obvious.

Protocols become implementation

Object-oriented programming cleanly separates interface and implementation. One of the main strengths of Jini's architecture is that communication between a Jini service object and a server is part of that object's implementation. Although a client and server must agree on a network protocol in order to send the first object from server to client, client/server communication can take place via object interfaces once the first object is in place.

Unlike an object, a document cannot make a socket connection back across the network. Thus, for clients to interact with documents received from a server, the client and server must agree on the document's data model as well as a protocol. For example, if a user fills out a form contained in an HTML document and presses Submit, the Web browser opens a socket to the Web server and most likely issues an HTTP POST command containing 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 instead of just silently consuming documents, the client and server must agree on protocols beyond the initial protocol that gets the document to the client.

  • Print
  • Feedback

Resources