Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Objects versus documents for server-client interaction, Part 1

Comparing two ways that software can interact with software

By Bill Venners, JavaWorld.com, 05/26/00

These days the dominant way that servers interact with people across the network is by sending HTML documents to Web browsers. Recently, XML has generated a lot of excitement among developers as an alternative document format that offers many advantages over HTML. Like HTML, XML enables servers to interact with people across the network via their Web browsers. But unlike HTML, XML also enables servers to easily interact with client software that has no user present.

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

• Comparing two ways software can interact with software
• Determining the best approach when there is no client-side user

:END_TEXTBOX

In the Jini universe, in contrast to the document approach of both HTML and XML, servers interact with client programs by sending objects across the network. Like XML, Jini enables servers to interact with client programs regardless of whether a user is present at the client.

In this three-part series, I will compare and contrast two fundamental ways that servers can interact with clients: using documents and using objects. In this article, the first of three parts, I'll look primarily at how objects and documents compare when servers interact with client programs that have no user present.

Creating a Java news page

I recently wrote a Python script to generate a Java news page for my Website, Artima.com. I planned to get the news items from Moreover.com, which offered a free news feed devoted to Java. As a Webmaster, I had several options, all of which involved servers sending documents to clients.

Perhaps my most straightforward option was to insert a large, hairy chunk of JavaScript code, kindly provided by Moreover.com, into my page. Whenever a user visited my Java news page, the embedded JavaScript would land in his or her browser, contact Moreover.com, grab the most recent Java news data, and construct the news page on the fly. I discarded this option partly because I have found JavaScript to be unreliable (as a result, my site contains no JavaScript), but primarily because I didn't want the user to have to wait for the JavaScript to make a socket connection to Moreover.com in order to grab the data. One of my main goals for Artima.com is to have pages that load quickly, and every socket connection takes time.

Another option was to use a script that ran on the server. In that approach, the URL of my news page would actually refer to a script. When a user hit the URL, the Web server would run the script. The script would contact Moreover.com and obtain the news information in the same way the JavaScript would. Again, I discarded this option because I didn't want the client to have to wait for that socket connection to Moreover.com.

Ultimately, I decided to write a script that contacted Moreover.com, grabbed the most recent Java news data, generated my Java news page, and saved the page in a file. I planned to set up a cron job that automatically ran the script every hour, so that the file would be refreshed regularly. In this approach, the user wouldn't have to wait for a socket connection, because it would be made behind the scenes once every hour. Given that Moreover.com seemed to be updating the contents of its Java news feed at most once or twice a day, I decided that an hourly poll would yield a sufficiently fresh page for my Website.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.