Re: [wsrm] [REL-49]proposal for REL-49

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

 Jacques,

 Comments below.

Jacques Durand wrote:

Sunil:A few comments, which I don't see critical, but even if we keep the annotationas you propose, we need to explicitly state which of the following semantics it has:- It should be possible to express that only input messages are concerned by the RM features
 

If you meant that we should clarify that RM capabilities only apply for
Request in a R-R MEP case, then yes, we could do that.
 

even when attaching a service config annotation at service / port / op level, (i.e. without having to"override" at message level, in order to exclude the output message.)E.g. scope="input", (future versions will handle: scope="output", scope="input-ouput")- The annotation you propose is not always about capability: in some cases the RM features *must* be usedby the client. In other words, the annotation may have different meaningfor each side. Consider the following cases, each gives the annotation a different meaning:

Actually I forgot that we decided to have an attribute (usage="required') on all 3 sub-elements. This will be an optional attribute.
 
 

1. server capability (this is your service config I think): WS supports this RM feature if client asks for using it. Attribute: clientuse="possible".
2. client requirement: client must use the feature, because the WS implementation assumes it does for a proper WS behavior (e.g. ordering required, when using repeatedly a monitoring operation)Attribute:  clientuse="required".3. server requirement: E.g. WS1 is a deployed pay-per-use WS, which will respond to users via requestsissued to users. The user then has to implement a "response" WSDL, describing a service WS2 that supports these requests. So we may want to specify in the WSDL 2 that the WS implementation ordeployment  MUST support the RM feature, because the client (here the deployed WS1) will use it.Attribute: serveruse="required" (or clientuse="possible"?) Beyond this, it becomes user-specific (e.g. according to an SLA) and would require more advancedpolicies or agreements attached to user ID.
 

I don't fully understand yet why we need 2 different attributes (clientuse and serveruse). What we decided at the F2F (which I forgot to incorporate into my proposal) was to have an attribute called "usage". If the value of the attribute is " required", then the consumer of the service (aka Client) must use those RM Features. If the attribute is not present, then it will be upto to the Client to use it or not. So I would believe this captures the requirements you have mentioned above. Please let me know If I misunderstood your requirement.

-Sunil

> >