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

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

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