RE: [wsrm] Poll mechanism as a service of RMP

["Goodner, Marc Andrue" <marc.andrue.goodner@sap.com>]

I think the difference here is that in the callback pattern we are sending back only acknowledgements. As these are processed from the headers in all of the other reply patterns I could see specifying this as an operation to be complicating things for an implementation. 

Another question raised here is when is the callback triggered and by who? If triggered solely by the RMP then there is certainly an argument that the operation should be defined similarly to the proposal for the poll operation. If it is possible to trigger the callback from an application at the receiving RMP node it is possible that the acknowledgement is only in the header and again we have application data in the body and leaving it in the headers makes sense. I could see that this might actually be a scenario that would be useful in cases of intermittently connected devices.

The scenario would be an application on an intermittent connected device is sending reliable messages using the callback pattern. These are being sent during times of high load on the device or when connection time is expensive and immediate confirmations are not required. Later during specific times when either load is reduced or connection time is cheap this device is addresses by an application on a server that needs to update records. This application has been tied into the RMP on the server to find all queued callback acknowledgements and send them during this connection. So in this case you would have an application operation being addressed and the RMP on the device would pickup the acknowledgements from the header as in the other patterns. I can imagine several other variations of this as well, i.e. sending the acknowledgements to an additional server rather than the device but again as piggybacking on some other application communication.

So I would recommend that it makes more sense to leave the callback features in the header to allow for this type of implementation flexibility.

Marc g


-----Original Message-----
From: Tom Rutt [mailto:tom@coastin.com] 
Sent: DMon, Oct 06, 2003 7:37 AM
To: Goodner, Marc Andrue
Cc: 'wsrm@lists.oasis-open.org'
Subject: Re: [wsrm] Poll mechanism as a service of RMP


What about the callback reply pattern.  It has an operation, which is 
now defined in a header.

Tom Rutt

----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133



Goodner, Marc Andrue wrote:

>In thinking about the conversation we have been having as to whether the RMP should be addressed directly by defining services such as the poll mechanism I looked to see if I could find examples in related protocols that are similar.
>
>I have found one example I would consider relevant in XKMS[1]. Within this specification there are messages that are defined for locating and validating keys that have corresponding SOAP 1.1 and 1.2 bindings defined[2]. These bindings specify the messages to be passed in the SOAP body so that a XKMS implementation exposes services. The SOAP 1.1 binding is required for implementations and the 1.2 implementation is recommended.
>
>I think that this does provide justification for approaching the poll mechanism as a service of the RMP as other protocols seem to be taking a similar approach. If I look further I believe I will find more examples. I think we are going to run into this issue for configuration parameters as well. I firmly believe that for some scenarios we can best accomplish our objectives by directly addressing the RMP. This should make the usage and implementation of the protocol simpler, not more difficult. Other wise I would argue against it.
>