This is fine, as long as wire-compatibility is not broken.
I agree that the current wire format for single-service implementations
must be kept.
But for multiple-service communication the wire format will be (slightly)
different, so clients written for single-service servers will not be able
to communicate with the multiple-service servers. The same holds for
multiple-service clients and single-service clients. Because a new wire
format is introduced it could also be extended with the following
possibilities if required:
- combining service and function selection in a single message instead of
using two messages
- a flag to indicate sequence IDs are not applicable
- out-of-band exchange of IDL information so less data has to be sent in
requests
Other ideas that people might have, could be supported by the new wire
format too.
Besides the wire format, whether synchronous or asynchronous communication
is used also determines which clients can communicate with which servers.
It is possible for a synchronous client to talk to a synchronous server
using sockets, servlets, etc., but a synchronous client would never be
able to talk to an asynchronous server, because what is expected by the
client and what is sent by the server do not match.
I want to prevent that a lot of clients and servers will be created that
won't be able to talk to each other just like everybody else does.
Therefore the supported scenario's should be documented:
- the request wire format
- the role of sequence IDs
- when and in what order messages are sent
- the response wire format
I believe currently the following scenario is known:
- synchronous with a single service per channel
- request: current wire format
- sequence IDs not used
- each request will lead to a corresponding response before next request
is handled by the server (except for one-way functions)
- response: current wire format
The following scenario can easily be added:
- asynchronous with a single service per channel
- request: current wire format
- sequence IDs are used
- the server accepts many requests simultaneously, and responses will
appear on the return channel in any order (except for one-way functions)
- response: current wire format
I would like to be able to use multiple services over a single channel, so
this would add another two scenarios:
- synchronous with multiple services per channel
- request: new wire format for the message/header
- sequence IDs not used
- each request will lead to a corresponding response before next request
is handled by the server (except for one-way functions)
- response: current or new wire format depending on possibilities
implemented
- asynchronous with multiple services per channel
- request: new wire format for the message/header
- sequence IDs are used
- the server accepts many requests simultaneously, and responses will
appear on the return channel in any order (except for one-way functions)
- response: current or new wire format depending on possibilities
implemented
I can't remember if there were feature requests or improvements for which
other scenarios are needed.
--
Kind regards,
Johan Stuyts
