OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]