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
