OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern



On Tuesday, September 16, 2003, at 03:59 PM, Sunil Kunisetty wrote:

>
>  Doug,
>
> Doug Bunting wrote:
>
>> Sunil,
>>
>> I believe John had a good point that, while it may not change the
>> suggested text, is certainly an important part of your proposal.  If  
>> we
>> were to accept this proposal and require it in all implementations  
>> (not
>> something that is entirely clear in this proposal), we may be changing
>> the persistence requirements.
>
>  How does this proposal change the "existing" persistence requirements?
>  As far as I recollect, it supports the existing ones without any new
>  requirements. Atleast my intent was not to jeopardize any existing  
> ones
>  or add new ones.

 >> If someone asks for the status of a message that was successfully
 >> passed on to the application layer or that expired and was purged,
 >> at sometime in the past, how do we know the status of the request
 >> without archiving beyond the current requirements of the  
specification?

>
>>
>>
>> I am curious why the StatusResponse contains a Status that seems to
>> include error conditions.  What rules decide whether a situation  
>> should
>
>  Are you referring to InvalidGroupId & InvalidSequenceNo? If so, they
>  are not the cause of the original msg., but rather the Status request  
> msg.
>  itself. If a receiving RMP receives a Status request for a msg with a
>  GroupId that was not never sent or was invalid, it will then send an
>  InvalidGroupId 'status' response corresponding to the 'status' request
>  and not the original request.
>
>>
>> result in a Fault versus a Status?  The current proposal leans toward
>> Status handling without explanation.
>
>  I didn't understand the above.
>
>>
>> Other issues arise due to the bundling suggested below.  When one
>> StatusRequest is invalid (should result in a Fault) but the bundled
>> business Request (or additional StatusRequest) does not, what happens?
>
>  This is a generic problem in the sense that we will have the same  
> problem
>  if we want to piggy-back Acks on other Requests & Responses. We ran  
> into
>  similar cases when Jacques is trying to propose a solution for  
> Response
>  Ack. pattern,
>
>>
>> If multiple StatusRequest elements are contained in one message, must
>> all related StatusResponse elements be included in a single message  
>> as well?
>
>  We could go either way, but for protocol simplicity we should say yes.
>
>>
>>
>> The existing patterns are focused on RMP-level signals and this  
>> proposal
>> puts handling the status requests at that level.  This leads to
>> potential handling delays if too many requests are bundled together.   
>> In
>> turn, this proposal leads to additional cases in which the patterns
>> cannot hold.
>
>  We should then come with recommendation and exclusion cases.
>
>  -Sunil
>
>
>>
>>
>> Many systems will impose security restrictions in the area of these
>> requests.  Some will refuse to respond positively to any request;  
>> others
>> will ignore requests not coming from the originator of the referenced
>> message.  These and other common situations should be described below.
>>
>> Finally a new (separable) issue, both this suggested Status text and  
>> the
>> existing description of faultcode values defined in our specification
>> are rather lax about qnames.  Restrictions such as requiring a value  
>> to
>> be a qname should be clear in the text, not just indicated in the  
>> schema
>> (not a problem below).  Any possible value examples and descriptions
>> should use a fully qualified name.
>>
>> thanx,
>>         doug
>>
>> On 16-Sep-03 12:51, Sunil Kunisetty wrote:
>>
>>>
>>> John Fuller wrote:
>>>
>>>
>>>> While I suppose it would add a diagnostic benefit, it sort of  
>>>> directly
>>>> addresses the RMP
>>>> as opposed to the RMP just knowing how to manage messages and hand  
>>>> them
>>>> off.
>>>
>>>
>>>  The above issue  while is  important is out-of-scope of this  
>>> particular requirement/proposal.
>>>  "Message management" was/should-be handled in the persistence/DE/RM  
>>> sections.
>>>
>>>
>>>> How long would you have to archive message information to know
>>>> when expired groups were purged?  Or does it not assume transient
>>>> services
>>>> that persist, but a daemon that would only respond with knowledge  
>>>> since
>>>> its startup?
>>>>
>>>> On Tuesday, September 16, 2003, at 01:51 PM, Sunil Kunisetty wrote:
>>>>
>>>>
>>>>> All -
>>>>>
>>>>> I had an AI @ the last F2F for coming up with a proposal for POLL
>>>>> pattern.
>>>>>
>>>>> Mark/Doug:
>>>>>
>>>>> Could you create a Spec. Issue for Requirement Issues 3.6 & 3.7?
>>>>>
>>>>> <ProposalBegin/>
>>>>>
>>>>>  I'd like to propose to have 2 new Headers:
>>>>>
>>>>>     StatusRequest
>>>>>     StatusResponse
>>>>>
>>>>>  StatusRequest will be the Header used by the Sender to send a
>>>>> poll/status
>>>>>  inquiry to the Receiver. It will have 2 sub-elements. A mandatory
>>>>> GroupId
>>>>>  and an optional SequenceNo. The types for these are the same as  
>>>>> the
>>>>> ones
>>>>>  in MessageHeader element.
>>>>>
>>>>>  StatusRequest
>>>>>      - GroupId  - Mid URI type - Mandatory
>>>>>      - SequenceNo - UnsignedLong - Optional
>>>>>
>>>>>  StatusRequest can be sent without a MessageHeader and hence can be
>>>>>  piggy-backed on another Request or can be batched with other  
>>>>> status
>>>>> requests.
>>>>>
>>>>>  StatusResponse Header will be used by a Receiver to send the  
>>>>> status
>>>>> back
>>>>>  to Sender. It will have the following sub-elements:
>>>>>        - RefToGroupId      -  mid URI type - Mandatory
>>>>>        - RefToSequenceNo - unsigned long  - Optional
>>>>>        - Status                    - QNAME        - Mandatory
>>>>>
>>>>>  Possible Status Values are:
>>>>>        - InvalidGroupId -  When the GroupId is invalid or
>>>>> un-recognized
>>>>>        - InvalidSequenceNo  - When the SequenceNo is invalid or
>>>>> un-recognized
>>>>>        - MsgExpired - When the message was expired (based on
>>>>> ExpiryTime)
>>>>>        - MsgReceived - When the message was received and ack-ed by
>>>>> the RMP/
>>>>>
>>>>>  Since all our Header elements are extensible, Implementations can
>>>>> extend with a
>>>>>  new element called 'sub-status' and send more implementation
>>>>> specific details
>>>>>  if desired. But I prefer that Spec. level requirements for Status  
>>>>> be
>>>>> simple.
>>>>>
>>>>>  Multiple StatusResponse(s)  can be batched or can be piggy-backed  
>>>>> on
>>>>> Response.
>>>>>
>>>>>  We should be able to share the above Status values with Fault  
>>>>> Codes.
>>>>> Note both
>>>>>  are QNAME types and hence shareable.
>>>>>
>>>>>  Error due to StatusRequest processing will result in a Fault with
>>>>> error code
>>>>>  InvalidStatusRequest.
>>>>>
>>>>>  <ProposalEnd/>
>>>>>
>>>>> Comments ???
>>>>>
>>>>> -Sunil
>>>>>
>>>>>
>>>>> To unsubscribe from this mailing list (and be removed from the  
>>>>> roster
>>>>> of the OASIS TC), go to
>>>>> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/
>>>>> leave_workgroup.php.
>>>>>
>>>>
>>>> To unsubscribe from this mailing list (and be removed from the  
>>>> roster of the OASIS TC), go to  
>>>> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/ 
>>>> leave_workgroup.php.
>>>
>>>
>>>
>>> To unsubscribe from this mailing list (and be removed from the  
>>> roster of the OASIS TC), go to  
>>> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/ 
>>> leave_workgroup.php.
>>>
>>
>> --
>> SunNetwork 2003 Conference and Pavilion
>> "An unparalleled event in network computing! Make the net work for  
>> you!"
>>
>> WHEN:  September 16-18, 2003
>> WHERE: Moscone Center, San Francisco
>>
>> For more information or to register for the conference, please visit:
>> http://www.sun.com/sunnetwork
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]