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