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:

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]