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