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: better description?


Jacques:

The RM Source would not "declare", it would request (via sending the 
first message) and the RMD would then either accept or reject the 
request based on its' current status.  This would allow the RMD to be 
autonomous in its decision to accept a proposal to start a new RM Sequence.

It would be assumed that the source can support what it requests 
(otherwise it would not request such) and it would allow the RMD to 
dynamically allocate resources to ensure it can support the potential 
maximum sequence capacity.

If the RMD declares a maximum, then accepts 5 new sequences from other 
sources, then the maximum declaration may no longer be feasible to 
declare.  If in that meantime, another RM Source started the sequence 
based on the declared capability, it may become problematic. 

I actually see no other way this could be dynamic since there may be a 
lag between declaration and acceptance of the first message.

Duane

Jacques Durand wrote:

> Duane:
>
> I also prefer a more dynamic solution, though I am surprised you 
> suggest that the RM Source declares the limit instead of the RM 
> Destination.
>
> (I believe it is never a problem if the Source has a lower sequence 
> capacity than the Destination, but the reverse is a problem, so only 
> the Destination needs to announce its limits.)
>
> Dynamic variant:
> - the RM Destination declare the maximum sequence number it can handle 
> in the CreateSequenceResponse message.
>
> Note that allows for *very* dynamic situations where the length of an 
> authorized sequence may actually vary with the memory available to the 
> RM Destination at that time: an RM Destination may have to allocate 
> many sequences to its senders, and maintaining the state of these 
> sequences takes space (remembering the sequence number of received 
> messages can be done as a list of intervals, yet even this can become 
> very big as the sequence is "aging" - you might have billions of such 
> intervals to remember for each sequence...)
>
> Here is where I see the use of a Policy: an RM Destination may 
> allocate its sequences according to some predefined policy, either 
> always allocate the same fixed size (and turn down requests that it 
> cannot satisfy due to space shortage), or reduce the size of new 
> sequences so that many more can be allocated.
>
> Cheers,
> Jacques
>
> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com]
> Sent: Monday, August 01, 2005 9:36 AM
> To: Duane Nickull
> Cc: Jacques Durand; wsrx
> Subject: Re: [ws-rx] Issue i013: better description?
>
> Another way to solve this may be to have the RM Source send a second
> attribute that logically declares "out of a maximum of n" with the first
> message transmitted in the session.  This could essentially request that
> the RMD reserve resources for n.  This has the advantage of being far
> more dynamic that the suggestion below and also mitigates any
> unnecessary dependencies upon WS-Policy.  If the RMD does not have
> resources, it can flag such to the RMS after the first message.
>
> Architecturally, I would prefer something along these lines rather than
> the one below.
>
> Duane
>
> Duane Nickull wrote:
>
> > Jacques et al:
> >
> > My gut reaction to the re-wording would be to use WS-Policy (since it
> > is an existing mechanism that intends to declare things like this) and
> > define a custom policy for the RM Destination that can be read by the
> > RM Source, possibly prior to each WS-RX session that might exceed the
> > last.
> >
> > example:
> > ...
> > <wsp:Policy
> >  xml:base="http://corporate.adobe.com/policy"; wsu:Id="WHATEVER">
> >   <wsp:All>
> >     <msp:EndpointMaintenanceSchedule>
> >        <!--blah, blah , blah-->
> >     </msp:EndpointMaintenanceSchedule>
> >       <msp:OrderPolicy>
> >          <msp:RMDestinationSequenceMaximum msp:maximum="400"/>
> >         <!--also needed?
> >         <msp:RMDestinationMessageSizeMaximum msp:maximum="1048576"/>
> >            -->
> >       </msp:OrderPolicy>
> >   </wsp:All>
> > </wsp:Policy>
> >
> > Technically, this could work.
> >
> > Questions:
> >
> > 1. Does this TC think this is a viable technical solution?  Is it
> > architecturally the best way?
> > 2. Is it politically acceptable to all?
> > 3. Is this TC okay with creating a dependency between WS-RX and
> > WS-Policy?  Are there any reason why this should not be done?
> > 4. Assuming it is okay, would this TC specify a
> > RMDestinationSequenceMaximum schema fragment in our spec or would the
> > WS-Policy define it in theirs?
> > 5. Does this really address the problem?  Is it simply the sequence
> > max integer or is it the resources which may largely be based on the
> > size of the messages and number of concurrent service consumers that
> > determine QoS?
> >
> > Apologies if this is a naive, idealistic and overly simplistic attempt
> > to find an answer.  If this is not the answer, it would be healthy to
> > eliminate it and focus thinking of the TC in the correct direction.
> >
> > Duane
> >
> > Jacques Durand wrote:
> >
> >> Doug D:
> >>
> >> 
> >>
> >> Mostly an editorial aspect, but could create confusion w/r to future
> >> resolution of your issue:
> >>
> >> I find the description of i013 a bit inaccurate: it merely summarizes
> >> the solution proposed in the proposal section, instead of stating
> >> what the real issue is:
> >>
> >> 
> >>
> >> <description>
> >>
> >> define a policy assertion that defines the highest message number the
> >> RM destination will accept.
> >>
> >> </description>
> >>
> >> 
> >>
> >> Would that be OK (meaning aligned with your intent) if you reworded
> >> it as:
> >>
> >> 
> >>
> >> <description>
> >>
> >> There is no common way to communicate to an RM Source the highest
> >> message number the RM destination will accept, in case it is lower
> >> than the maximum authorized in the specification.
> >>
> >> </description>
> >>
> >> 
> >>
> >> 
> >>
> >> Regards,
> >>
> >> Jacques
> >>
>


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