Sunil:
-----Original Message-----
From: Sunil Kunisetty
[mailto:]
Sent: Tuesday, January 20, 2004
11:48 PM
To: Jacques Durand
Cc:
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
