[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]