2.2 Fixed and adaptive protocols
The protocol described above for a simple naming service is an example of a fixed protocol. This is a protocol whose vocabulary is fixed: it is embedded in the client and server's code and data and does not change. An adaptive protocol is one where the protocol changes. A fixed protocol could change over a period of time because the functionality provided by a server changes. However, this change will be over months or years rather than over seconds.
There are some instances where a strictly fixed protocol is not adequate. The most common reason for this is where an application supports variable numbers of arguments. For example, a protocol for a server which supports the functions of reporting on system usage might consist of a command which asks for the identities of the current users of the system. The reply to this service request might consist of anything from zero to thousands of user identities. Another example is where the types of the entities in a protocol command might vary, for example a banking application might require the balance of an account to be returned for either the name of an account holder or the unique integer key which identifies the account.
Another example where an adaptive protocol might be used is when a client and a server have to negotiate some subset of a protocol which they both understand: for example, the client may only understand an early subset of a protocol while the server understands the full up-to-date version of the protocol. This type of negotiation occurs in client-server systems which form part of multimedia applications.
A further example of a need to make protocols adaptive is where a highly reliable service is required and where circumstances such as functional changes necessitate a protocol being modified without a server being taken out of service for a significant time or, ideally, not taken out of service at all.
There are a number of techniques used for implementing adaptable protocols; these range from simple ones such as adding extra arguments to a protocol command to indicate the number of arguments that have been provided or an argument which identifies the type of the argument, to the use of serialisable objects which embed the functionality of a command within the protocol.
Serialisation is the process whereby objects are turned into raw data so that they can be sent over a transmission medium. Many Java distributed technologies such as the RMI distributed object technology need to send such objects over a network and hence they need to be able to be converted into their raw data. In Java this is done very simply by specifying that a class implements the interface.