Re: [wsrm] Proposal to resolve REL-49

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Jacques Durand wrote:

> Anish:
> 
> that looks clean, not overloaded, and I believe can be introduced
> as naturally as any previous annotation mechanism.
> 
> See inline comments tagged <JD> in attached doc.
> 
> - I think the proposal needs be more explicit on how
> to express "required-to-use" features vs. ""supported" features.
> I gave it a try in my comments.
> 

Thanks for the comments.
The idea of the compositors is that, the compositor semantics specify 
whether something is required or just supported. Perhaps the examples 
need an explanation which might make things clearer.
Of the four compositors:
"all" : Every element (feature/property/extensibility-element) that is 
composed is 'required'.
"choice" : Exactly one element is required but all are supported
"one-or-more" : at least one is required but all are supported
"zero-or-more" : none is required but all are supported.

Comments and example in your <JD> annotation under section VI.A :

 >Let me know if I got these right:
 >- I guess we can use a "zero-or-more" composer to mean that the
 >composed
 >features are all supported but optional for client.
 >- to say that a feature below is NOT supported, would require a "false"
 >value
 >under an "all" composer (e.g. for message-ordering).
 >- to say that you must use either poll or callback but NOT response
 >reply,
 >would require:
 ><compositor "all">
 ><compositor "one-or-more">
 ><..callback-reply-pattern..>true<>
 ><..poll-reply-pattern..>true<>
 ></compositor>
 ><..response-reply-pattern..>false<>
 ></compositor>
 ></JD>

You got it exactly right!


> - these annotations map clearly to the notions of RM Agreement and RM 
> Capability,
> of which they are a concrete representation.
> I think it is the proof that WS-Reliability is open to externally defined
> ways to express WS policies, and proposes the right abstract notions to 
> help this.
> 
> Jacques
> 
>