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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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


Subject: Re: [ws-rx] Issue i013 - proposed text changes


Doug:

Thanks for the clarification. I wasn't sure what the scope was on i013.  

Sounds good!  Have a good weekend.

Duane

Doug Davis wrote:

>
> Duane,
>   I believe that Jacques is planning on opening a new issue to address 
> a more dynamic
> solution.  Issue i013 is just focusing on the cases where the 
> Destination wants to advertise
> a max # less than the max unsigned long as a general max for all 
> sequences.  If on a sequence
> by sequence basis it needs to be lower then I think some other 
> solution (like what Jacques might
> propose or your suggestion) will be used.  While these are a bit 
> related because they deal with max message #,
> on the last conf call we decided to split out the dynamic solution 
> into a different issue.
> thanks
> -Doug
>
>
>
> *Duane Nickull <dnickull@adobe.com>*
>
> 08/05/2005 08:07 PM
>
> 	
> To
> 	
> cc
> 	ws-rx@lists.oasis-open.org
> Subject
> 	Re: [ws-rx] Issue i013 - proposed text changes
>
>
>
> 	
>
>
>
>
>
> Doug:
>
> While I like what you are attempting to resolve, however I still see
> potential problems with the methodology suggested below.  In addition to
> the MaxMessageNumber declaration, there may need to be another mechanism
> to ensure a more dynamic and accurate contract for establishing
> MaxMessageNumber.
>
> Assumptions:  I am assuming that by attempting to cap the
> MaxMessageNumber you are addressing the issue of resources, not simply
> just the value of the sequence token.  If this is errant, we may need to
> discuss this under a different thread.
>
> Problems:  If a RMD makes a static declaration that it supports 'n' as a
> static MaxMessageNumber, it has no idea that it can support that at any
> specific future time.  A source could parse this information and assume
> that it is ready to receive a new sequence of up to [some arbitrary
> number] of messages, but if a delay occurs in sending the next message,
> the RMD may start too many other sequences and not have the resources
> ready to process the messages up to the max number.  This may invalidate
> the MaxMessageNumber capability declaration if there are not enough
> resources to process all the messages.
>
> Addendum to suggestion: In addition to what you proposed, I would
> suggest a pattern to have the RM Source request the RMD allocate
> resources for a potential maxNumber of messages when sending the first
> message of the sequence.  No reply or a negative reply would mean it was
> not accepted, a positive reply would mean that the RMD has dynamically
> allocated resources and the source can now proceed with the sequence.
>
> Not sure of the exact syntax but something like this could be the first
> message in the sequence:
>
> <wsrm:Sequence ...>
>    <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>
>   <!--added "@maxPossible" -->
>    <wsrm:MessageNumber maxPossible="55"> xs:unsignedLong
> </wsrm:MessageNumber>
>    <wsrm:LastMessage/>?    
>     ...
> </wsrm:Sequence>
>
> The real issue is not the actual sequence number itself IMO, it is the
> resource requirements resulting from high numbers of messages.  If a RMD
> is accepting RM sequences from multiple sources, it may be
> architecturally more elegant to have each one request resources be
> allocated rather than a static declaration, which would still be subject
> to verification.
>
> Thoughts?
>
> Duane
>
>
>
> Doug Davis wrote:
>
> >
> > Per my AI on the last conference call here are the list of changes I
> > propose for the resolution of issue i013:
> >
> > In the WS-RM Policy doc:
> >
> > After line 173, add to the normative outline:
> >         <wsrm:MaxMessageNumber Number="xs:unsignedLong" ... /> ?
> >
> > After line 202, add to the more verbose section of the normative 
> outline:
> >         /wsrm:RMAssertion/wsrm:MaxMessageNumber
> >         A parameter that specifies the maximum message number that the
> > RM Destination will accept.  If omitted, the default value of the
> > maximum unsigned long will be assumed.
> >
> >         /wsrm:RMAssertion/wsrm:AcknowledgementInterval/@Number
> >         The maximum message number.
> >
> > After line 434, add to the schema:
> >         <xs:element name="MaxMessageNumber" minOccurs="0" >
> >           <xs:complexType>
> >             <xs:attribute name="Number"
> >                           type="xs:unsignedLong" use="required" />
> >             <xs:anyAttribute namespace="##any" processContents="lax" />
> >           </xs:complexType>
> >         </xs:element>
> >
> > thanks
> > -Doug
>
>


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