Re: [ws-rx] Re [ws-rx] i137: No mechanisms to convey that messages shouldbe polled.

[Doug Davis <dug@us.ibm.com>]

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
>>
>>
>
>