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?


Title: RE: [ws-rx] Issue i013: better description?

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]