The Artima Developer Community
Sponsored Link

Object versus Document, Part I
Comparing Two Ways that Software can Interact with Software
by Bill Venners
First Published in JavaWorld, June 2000

<<  Page 5 of 11  >>

Advertisement

Data models and network protocols
Lurking behind all the communication approaches between Moreover.com and Artima.com is an important assumption: that the client will fetch the document via the HTTP's GET command. In fact, perhaps a better way to look at Moreover.com's document formats is as a part of several high-level protocols that define the interaction between Moreover.com's clients (such as Artima.com) and its server. The combination of a news category URL, the low-level HTTP GET protocol, and Moreover.com's XML DTD, for example, combine to form a high-level network protocol, which can be summarized as follows:

A fetch protocol

  1. The client opens a socket to the Web server at Moreover.com.
  2. The client requests the most recent news of a particular category using the HTTP GET command over the socket, passing the document name given in the news category URL.
  3. The Web server sends an XML document containing the news in a format defined by XML and the Moreover.com DTD.
  4. The client closes the socket. (In HTTP 1.1, the client closes the socket so that the socket can be reused to grab other pieces of a Webpage, such as images, referenced from the original document. In this case, there are no other pieces to grab.)
  5. The client uses the XML DTD to parse and interpret the document.

An alternative protocol
The Python script currently executing at Artima.com plays the client role in a protocol that corresponds closely to the Fetch protocol. The difference is that my Python script fetches a TSV, not an XML, document. The TSV format does not come with an official DTD, but conceptually its structure corresponds to the same data model described by the XML DTD.

Now although my Java news page seems to be working fine, the truth is, I'd prefer that Moreover.com notify my Website whenever it changed the contents of its Java news feed. That way I would need to rewrite my Java news page only when its contents actually change. Since I would be notified of changes rather than polling hourly, my news page would be updated more promptly whenever new news appeared.

If Moreover.com is ever to offer such a notification-based approach, it will have to define a protocol that implements one. Given that the server will be "pushing" a notification down to the client, rather than relying on the client to "pull" the latest news from the server, the client will probably have to have some kind of server running. For Moreover.com to know where those client-side servers are, and what categories of news each client-side server wants, a protocol that lets clients subscribe to the notification service will be necessary (in addition to the notification protocol itself). Here are outlines of a subscription protocol and a notification protocol, in which I call the client-side server a "listening" server:

A subscription protocol

  1. The client opens a socket connection to a subscription server at Moreover.com.
  2. The client sends an XML document that adheres to a subscription DTD (also defined by Moreover.com) to the subscription server. The DTD lets a client subscribe to one or more news categories or cancel one or more previous subscriptions.
  3. From the XML document, the subscription server parses the IP address and host of the client's listening server and the news categories that the client wants either to subscribe to or unsubscribe from.
  4. The registration server performs the requested subscription/unsubscription actions and sends to the client a polite thank you, in XML of course, and both sides close their sockets.

A notification protocol

  1. Whenever the contents of a news feed changes, a notification server opens a socket to the listening server for each registered subscriber.
  2. The notification server then sends an XML document that adheres to the news-feed DTD described earlier in this article and closes the socket.

This is a quick first sketch of news-feed subscription and notification protocols. In an actual protocol design project, the details of the DTDs would need to be specified. In addition, many other issues, including what should happen if a listening server disappears from the network without canceling its subscription, should also be considered.

<<  Page 5 of 11  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us