Use case 6

Actors:

    * A server implementing a request/reply operation
    * A client invoking that operation
    * Optionally, a third party receiving the reply.

Subcase 1:

    At the application level, the client simply sees a request/reply
    operation.  The client-side infrastructure would like to be able to
    decide, as dynamically as possible, whether to invoke the operation
    synchronously or asynchronously.  In the first case, the anonymous
    reply-to will be fine (assuming the usual SOAP/HTTP binding).  In
    the second case, the reply-to will have to be a callback address.

Subcase 2:

    The party sending the request to the server is not the same as the
    party receiving the reply.  For example, the actual client sends a
    request to some broker, who forwards it to the proper server.  There
    is no reason for the server not to send the reply directly to the
    actual client (as opposed to forwarding it through the broker).  In
    other words, the broker's value add is finding the server, not
    forwarding per se.  Note that if the client supplied an anonymous
    reply-to (as with current proxies), the broker will have to forward
    the reply anyway.