i090 - Offer, let's get back to the original question

Let’s get back to discussing the original issue i090. The discussion has been entirely hijacked by issue i089 at this point which isn’t helping us. I’ll take my share of the blame here since I offered a compelling use case for Offer that involved an anonymous uri in the ReplyTo, but that isn’t the only use. So let’s leave that completely to the side and see if this still makes sense. I think it does.

The original issue i090 noted that the RMD does not know where to send protocol messages and has to make assumptions (which is bad). Proposal 2, which I made, was that the protocol messages for the accepted Offer should go to the ReplyTo. I accept that this proposal may need to be revised, but I do stand by the direction there. That is, if an Offer is included in a CS then the Offered sequence MUST be associated to a well-known EPR; the ReplyTo of the CS in my proposal. This provides for simple usage of Offer in non-multiplexing scenarios.

The example given in the issue is not a good one for the use of Offer. This example has two applications are sharing a presumably long running sequence to a common endpoint. It then asks in this scenario if when the RMS were to Offer the reverse long running sequence, which endpoints would that sequence be used for? I would suggest that Offer is not for the establishment of long running sequences that service multiple applications. Offer could easily be used here if each application had its own sequence. It is the multiplexing of multiple apps over the same sequence that confuses the proper use of Offer and deserves further clarification in the spec beyond what has been proposed to date.

Let’s turn this around for a second. How did the RMS in this example establish a sequence to the RMD, possibly even absent an application request to do so, and the RMD establish a reverse sequence back to the RMS (now acting as an RMD)? How did the RMS know the two apps should share the sequence to the RMD? How does the RMD know that it has a reverse sequence back to the RMS that it can use for application replies? Does it have a catalog of the many possible EPRs that possibly pertain to the reverse sequence? What if an EPR is related to more than one sequence established with one or more RMS(s)? These are all implementation details that are not spelled out in the spec. Does that mean that we should prohibit multiplexing multiple apps over a single sequence? Not in my opinion. It seems useful. It will take a clever implementation to do it right though. Especially to do this securely if all those apps are sharing the same sequences.

Let’s imagine we have an application that wants to invoke a service one or more times over a short period of time over an unreliable network and get its responses reliably. Say the address book query program described in issue i090 running on a notebook tethered via Bluetooth to a handi connected to the internet over GSM. Not unreliable enough? Let’s add a VPN connection to the corpnet where the address book app is running. In this scenario providing an Offer removes a full req/resp leg. Whether you want to call it an optimization or not I don’t care, this seems of some benefit.

Marc Goodner

Technical Diplomat

Microsoft Corporation

Tel: (425) 703-1903

Blog: http://spaces.msn.com/mrgoodner/

ws-rx message