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

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Sunil:

-----Original Message-----
From: Sunil Kunisetty [mailto:sunil.kunisetty@oracle.com]
Sent: Tuesday, January 20, 2004 11:48 PM
To: Jacques Durand
Cc: wsrm@lists.oasis-open.org
Subject: Re: [wsrm] [REL-49]proposal for REL-49

 
 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.
[Jacques Durand] yes. (the notation needs to allow for covering all of R-R in the future, and only Request for now)
 

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.
[Jacques Durand] I forgot too. that should work. 
  
 

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.
[Jacques Durand] I think even if the Client is free to use the service or not, it makes a difference to specify: usage="optional" or "possible", because that tells the developers or deployers for this WSDL, that their WS must support the feature on server side. (people who write the WSDL and who implement it are not always the same: this is my point in my case #3). Does that make sense? Other than that, it seems a single attribute is indeed sufficient.

Jacques

-Sunil