Umit:
I have considered the
message-as-Policy-subject option, and maybe it is just a lack of familiarity with
the Policy attachment rules that led me to propose the other option,
which I initially thought as simpler. I am quite willing to reconsider if my
concerns were unfounded.
Let me explain my reserve on using the
message-level attachment:
1- I observe some reluctance to associate RM
policies with portType (WS-RM Policy, section 2.3) , the rationale being that RM
assertions specify a concrete behavior that should not be directly associated
with an abstract definition. But if we follow that line, Message is also part
of this abstract definition in WSDL, and I believe subject to the same reserve
that led to NOT attach to portType:
"...For WSDL type
definitions (portTypes and messages), the [Effective Policy] for a WSDL
type definition is considered an
intrinsic part of the type definition and applies to all uses
of that type, in particular, to
every implementation of that WSDL portType.
In the case of policies that apply
to deployed resources (services or ports), the [Effective
Policy] applies only to the
deployed resource itself...."
PolicyAttachment
seems to clearly distinguish policies that apply to the deployed resource, from
policies that are inherently associated with the definition of the service. That
we might now attach RM assertions on either kind of artifact was my main
concern, given the prohibition in WS RM Policy. (if we want message-level
granularity, maybe should we attach * inside* a binding?)
2. If we
attach at message-level granularity, we need to be explicit about possible
inheritance conflicts - or about just conflicts (say between binding and
message, or port and message, as I am not sure if we can talk of inheritance in
such cases - I guess we can). PolicyAttachment seems to discourage any
form of overriding ("...It is RECOMMENDED that additional
policies at lower levels only further qualify inherited policies....")
And there is no clear statement of what is the
Effective Policy in case of conflicting assertions.
On
the other hand, I do not think the policy scoping solution is requiring a
change in WS Policy framework: only in RMAssertion schema which this TC
controls. But I concede such a change may call for a generalization that goes
beyond RM. (and instead of the notion of "scope", the notion of "role"
might be more common in Policy dialects)
Anyway,
open to more discussion on this - but wanted to point out that there is
no easy answer here.
We may
also decide to leaving out the "scoping" issue and just keep for
now the first clarifying statement about the endpoint to which the Policy is
attached, always acting in the role of the Destination w/r to this
policy.
Regards,
Jacques
From: Yalcinalp, Umit
[mailto:umit.yalcinalp@sap.com]
Sent: Tuesday, October 11, 2005
2:21 PM
To: Jacques
Durand; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [i021]: a
proposal
Hi Jacques,
I am somewhat baffled with your conclusion
to arrive to a finer granularity of policies and trying to solve the problem
within the functionality already available from policy attachment perspective.
Instead of introducing a scoping mechanism
to the assertion itself, it seems to me that allowing the assertion to
apply to either Message Policy Subject (scope=input/scope=output) or Endpoint
Policy Subject (scope=in-out), you will get what is needed instead of
reinventing the wheel. I observe that the scope that you have defined
is not adequate for MEPs that may have multiple inputs and outputs in the same
operation. I realize that such MEPs are not common today, but the scoping
mechanism proposed appears to be very restrictive. Message Policy Subject will
not have the same problem. We could restrict attachment to either Endpoint
Policy Subject or Message Policy Subject and further disallow putting the RM
assertions to wsdl:portType/wsdl:operation/wsdl:{input/output} in order for the
assertions not to appear at the portType level in our spec so that message
level granularity is only achieved in the binding.
Further, we will not be changing the
WS-Policy Framework if it is going to be used. By inventing a scope, it seems
to me we are reformulating the attachment to a Message Context with your
proposal, but maybe I am missing something since I can not follow how you came
to the conclusion of introducing the scope is a better solution rather than the
one I described above. Perhaps you could clarify.
Thanks.
--umit
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Tuesday, Oct 11, 2005 11:45
AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] [i021]: a
proposal
Proposal for i021:
Instead of the finer-granularity attachment of policies
(e.g. at message level) option, would propose the other option that is more in
line with the intuitive scoping of policies, which are generally understood as
applying to messages sent to the endpoint (and not sent by).
After Line 187 in Oct 6th WS-RM Policy doc:
"As seen above, elements of an RM Policy assertion
may concern the behavior of either an RM Source (e.g.
wsrm:BaseRetransmissionInterval), or of an RM Destination (e.g.
wsrm:AcknowledgementInterval). When attached to a service endpoint, although
the endpoint may alternatively act as a Source and a Destination for operations
that use both input and output messages, an RM Policy assertion will by default
only apply to this endpoint in its Destination role. By default, any client to
this endpoint must comply with the RM Policy assertion elements that concern
the Source role."
That would be the minimal update needed to remove
ambiguity.
Other side of the issue 021: how do we attach a
policy to a service endpoint that governs output messages - say, a service
endpoint is requiring its clients to use RM protocol and send back Acks with
some AcknowledgementInterval T (possibly different from the policy assertions
that govern the input messages)?
Proposal is to add an attribute to wsrmp:RMAssertion
element: @scope.
- If @scope="in" (default) then the
assertion applies to input messages only (service endpoint acting as RM
Destination)
- If @scope="out" then the assertion
applies to output messages only (service endpoint acting in RM Source role).
- if @scope="inout" then the assertion
applies to both input and output messages.
I'll draft the formal proposal for that schema
update after getting some feedback on the idea.
-Jacques