Re: [ws-rx] Re [ws-rx] i137: No mechanisms to convey that messagesshould be polled.

[Paul Fremantle <paul@wso2.com>]

Doug

We need to write the concrete proposal! I guess I was assuming that the 
MessagePending header was only included on a response sent on a 
backchannel, and that it applied only to the criteria for that 
MakeConnection.
In other words I'm expecting this message to say ... "there's more where 
that came from". It simply stops you polling extra times. So in that 
case there is an implicit criteria which is the criteria used in a 
MakeConnection.

As regards the boolean. I agree, since its optional its useful to have 
the boolean. I'm now wondering if it should be mandatory. If its only 
returned on backchannels then I don't see its that important that it is 
optional.

Paul

Doug Davis wrote:
>
> I think there are two situations when this header (MsgStatus) would 
> appear in a message
> 1 - when the message is in response to a polling request
> 2 - when the message is a WSA response and the request carried a 
> MsgStatusRequested header
>
> In both cases you can think of the presense of the header as being a 
> direct result of
> a request message specifically asking for messages based on some 
> particular
> query parameters.  It could be the seqID, the EPR/URI, or the 
> extensibility bits. Either way,
> the request message requested the status (either directly thru the 
> MsgStatusReq header or
> indirectly thru a MakeConnection) - so I don't think we have a i119 
> issue again.
>
> The other part though, is the MsgStatusReq Header.  This is very 
> useful in cases where
> other messages just happen to be going between the two endpoints and 
> we want to
> save the overhead of issuing a dedicated polling request just to find 
> out that nothing
> is waiting for us.
>
> As for the other bits of the MessageStatus header, I think they may be 
> needed:
> - boolean attribute is there because the absence of the header can not 
> mean
> "nothing is ready to be polled" since the header is optional.
> - the query params are needed because I wonder if people may want to put
> multiple headers (both MsgStatus and MsgStatusReq) in the messages
> and the other side needs to know which (of possibly many) sets of 
> messages
> are ready to be polled.
>
> thanks,
> -Doug
>
>
>
> *Doug Bunting <Doug.Bunting@Sun.COM>*
> Sent by: Doug.Bunting@Sun.COM
>
> 06/20/2006 12:06 PM
>
> 	
> To
> 	Paul Fremantle <paul@wso2.com>
> cc
> 	Anish Karmarkar <Anish.Karmarkar@oracle.com>, wsrx 
> <ws-rx@lists.oasis-open.org>
> Subject
> 	Re: [ws-rx] Re [ws-rx] i137: No mechanisms to convey that messages 
> should be polled.
>
>
>
> 	
>
>
>
>
>
> Is this yet-another i119 (EPR comparisons overly restrictive) and "when
> to piggy-back" situation?  Now that we have something in the
> specification, "targeted at the sequence" seems narrow.
>
> On 20/06/06 03:02, Paul Fremantle wrote:
> > Oh no! 2 mistakes.
> > 1) forgot to update with the issue number and
> > 2) <wsrm:MessagePending/>  forgot a /!
> > Paul
> >
> > Paul Fremantle wrote:
> >> Anish
> >>
> >> I like the idea. However, can I propose a simplification.
> >>
> >> I suggest that we simply allow an RMS to add a header
> >>
> >> <wsrm:MessagePending>
> >>
> >> to any message targeted at the sequence to indicate there is a
> >> message that could be polled for. I propose this should be optional
> >> (even if there is a message pending), but recommended.
> >>
> >> Paul
> >>
> >>
> >>
> >>
> >> Anish Karmarkar wrote:
> >>> Title: Polling mechanism does not provide a way for the RMS to let
> >>> the RMD know that there are pending messages that should be polled.
> >>>
> >>> Description/justification:
> >>>
> >>> We have a polling mechanism that allows messages to be polled. This
> >>> is quite helpful for RMDs that are behind the firewall. But there is
> >>> no mechanism for the RMS to let the RMD know that there are messages
> >>> that the RMD should poll for. I.e., unless the RMD polls for a
> >>> message, it will not know whether it should have polled!
> >>>
> >>> Having a mechanism for the RMS to let the RMD know that there are
> >>> pending messages is helpful in at least two scenarios:
> >>>
> >>> 1) RMD just polled for a message (perhaps because it periodically
> >>> does that), and would like to know if it should poll again because
> >>> there are additional pending messages. The RMD wants to minimize
> >>> message delivery delays, but the only way to do that is to increase
> >>> the polling period, which can result in unnecessary
> >>> sending/receiving/processing of messages. Given that the RMD has
> >>> already polled for a message, it is extremely convenient (with a
> >>> minimal cost) to allow the RMS to inform the RMD that there are
> >>> additional message waiting.
> >>>
> >>> 2) The RMD and RMS have ongoing communication (not necessarily a
> >>> wsrm:MakeConnection), it is advantageous for the RMD to let the RMS
> >>> know that there are pending messages by allowing the pending status
> >>> to be piggy-backed on ongoing communication messages.
> >>>
> >>> Core: core
> >>>
> >>> Type: design
> >>>
> >>> Proposal:
> >>>
> >>> Outline of the proposal --
> >>> Allow two new headers wsrm:MessageStatusRequested and
> >>> wsrm:MessageStatus, which can be piggybacked on other messages, that
> >>> query and convey that there are pending messages.
> >>>
> >>> <wsrm:MessageStatusRequested  ...>
> >>>   [<wsrm:Identifier> xs:anyURI </wsrm:Identifier>]?
> >>>   [<wsrm:Address> xs:anyURI </wsrm:Address>]?
> >>>   ...
> >>> </wsrm:MessageStatusRequested>
> >>>
> >>> <wsrm:MessageStatus pending="xs:boolean" ...>
> >>>   [<wsrm:Identifier> xs:anyURI </wsrm:Identifier>]?
> >>>   [<wsrm:Address> xs:anyURI </wsrm:Address>]?
> >>>   ...
> >>> </wsrm:MessageStatus>
> >>>
> >>>
> >>> -Anish
> >>
> >>
> >
> >
>


-- 

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com