Adaptable Protocols

There are situations where an application’s message protocol may change while the application is running. First we’ll examine the ways in which a message protocol can vary during runtime, then we’ll see how our message-passing facility would need to be modified to support these adaptable message protocols.

Variable Number of Arguments

The most common situation encountered in message passing is a message whose argument list varies in length. Some arguments are actually lists of values, whose size is not known by the receiver beforehand. A multiuser server may provide a way to ask for its current list of users, for example. Optional arguments are another cause for variable-length argument lists. Continuing with the multiuser server example, a request for its list of current users may be a message with some optional arguments that control how much data is returned. A “verbose” argument may indicate that the caller wants all available information on the current users. When this argument is not present, a more condensed set of data is returned.

These possibilities imply that the recipient of a message may require information on the number of arguments to expect. In our previous examples, the message objects handling incoming messages were hardwired to expect a given number of messages, with each argument always having the same meaning. The readArgs() method on MoveMessage in Example 6.7 reads in the expected argument list, then waits for the end-of-message string. ...

Get Java Distributed Computing now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.