[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] [i021]: update on NO proposal ... and maybe a hint of a proposal
Jacques Durand wrote: I like the idea of separating policy assertions for a sequence into RMS an RMD bundles. It simplifies explanations of semantics considerably. Tom Rutt > 1. More precise assessment of why attaching RMAssertion at message > binding level is not that exciting, at least in the context of i021: > > - really we are talking of a policy here that governs RMS and RMD > behavior w/r to entire Sequences (per WS-RM Policy definitions). not > to single messages (or message types) as subjects. E.g. > InactivityTimeout, AckIntervals, etc are behavioral properties of RMD > at Sequence granularity at best, not policies that apply to > individual messages (does not make sense). > > - assuming we still attach RMAssertion at message binding with the > understanding that the meaning is like "this message must be sent over > via an RMS and a sequence that follows policy XYZ" that still > requires a slew of precautions: prevent conflict with other RM > policies at endpoint level, make sure the client RMS uses different > sequences for sending messages related to different policies, have the > RMS know about which policy applies to which message / operation... > etc. Kind of getting more trouble than we were bargaining for. > > - I feel this is rather a kludge for what we really need here: a > role-based assignment of policies. We just want to say that the > endpoint will act in the Destination role w/r to this protocol policy, > regardless of the message type - nothing more. > > > > 2. Given the lack of support for roles in WS-Policy, and assuming > there is no reason to always force outbound messages to follow the > same RM policy as inbound messages, then I'd propose the following: > > > > - get rid of the RMAssertion container as we know it. > > - Replace it with RMSAssertion and RMDAssertion. Each one of > these will be container for assertion items that concern respectively > the behavior of a Source and of a Destination endpoints, relative to a > sequence. > > - Then if we want a policy that only concerns reliability of > received messages, we only use RMDAssertion in the policy. Same if we > want to express a policy for the endpoint as a Source -> use RMSAssertion. > > - Note that does not preclude a more fine-grained attachment > than endpoint. > > - If we want to add the client-related assertion items when > defining a Destination policy for an endpoint (like done today within > RMAssertion), but just for information purpose, we can do something like: > > <wsp:Policy wsu:Id="MyDestinationPolicy" > > > <wsrmp:RMSAssertion* wsp:Usage='Informational'*> ... </ > wsrmp:RMSAssertion> > > <wsrmp:RMDAssertion > ... </ wsrmp:RMDAssertion> > > </wsp:Policy > > > > > Opinion? > > > > Jacques > > > > > > > > > > ------------------------------------------------------------------------ > > *From:* Jacques Durand > *Sent:* Thursday, October 13, 2005 12:25 PM > *To:* Tom Rutt2; Yalcinalp, Umit > *Cc:* ws-rx@lists.oasis-open.org > *Subject:* RE: [ws-rx] [i021]: NO proposal ... > > > > OK, I thought we had two decent alternatives for i021, but I now > believe we have none... (sigh) See below: > > > > 1. First one I heard is: Attach an RM Assertion to message level in > the binding, e.g. with wsdl:binding/wsdl:operation/wsdl:input as > policy subject. At first that looks good, but: > > - really we are talking of a policy here that applies to RMS and RMD > behavior, not to single messages as subjects. E.g. InactivityTimeout, > AckIntervals, etc are behavioral properties of RMD as a QoS provider, > not properties that apply to individual messages. > > - assuming we still do that with the understanding that the meaning is > like "this message must be sent over via an RMS that follows policy > XYZ" that still requires a slew of precautions: avoid conflicting RM > policies at endpoint level, make sure the client uses different > sequences for messages related to different policies, have the RMS > know about which policy applies to which message... etc. Kind of > getting more trouble than we were bargaining for. I feel it is rather > a cludge for what we really need here: a role-based assignment of > policies. > > > > 2. Second one, is to declare that it is perfectly our right to say > that particular policy assertions (here RMAssertions) per their very > nature, only concern messages that are received by the endpoint to > which they are attached. That would not solve the problem of how to > deal with outbound message flow if we want to make these reliable too. > We could "tag" an assertion whether it applies to the endpoint itself > or to clients to the endpoint --> kind of ad-hoc substitute for a more > general missing role mechanism. > > 3. Other option: We could also decide to only attach to endpoint the > assertions that relate to Destination if we want to control its RMD > behavior only (meaning inbound messages only), and assertions that > relate to Source only if we want to control its RMS behavior (outbound > messages). But a policy that governs a communication RMS-RMD is now > split in two separate parts. > > > > The best way to get this solved is by fixing the policy framework: > - policy assertions may have roles tags > - when attaching a policy to a subject, the role(s) this subject acts > into must be specified. > > Otherwise it sounds like back to the old days when the notion of > "role" did not exist, policies had to be assigned directly to every > subjects 1 by 1... (that is what (1) above is about) > > > > Jacques > > -----Original Message----- > From: Tom Rutt2 > Sent: Thursday, October 13, 2005 10:12 AM > To: Yalcinalp, Umit > Cc: Jacques Durand; ws-rx@lists.oasis-open.org > Subject: Re: [ws-rx] [i021]: a proposal > > Yalcinalp, Umit wrote: > >> >> >> >> >>>-----Original Message----- >>>From: Tom Rutt [mailto:tom@coastin.com] >>>Sent: Thursday, Oct 13, 2005 8:46 AM >>>To: Jacques Durand >>>Cc: ws-rx@lists.oasis-open.org >>>Subject: Re: [ws-rx] [i021]: a proposal >>> >>>Jacques Durand wrote: >>> >>> >>> >>>>>you can attache message subject level at message Binding , just as >>>>> >>>>> >>>>you can >attach bound port for endpoint subject level >>>> >>>>Tom: not clear how to do that - although you can >>>> >>>> >>>technically attach a >>> >>> >>>>WS policy to any element of an XML doc, WS-RM Policy does >>>> >>>> >>>not address >>> >>> >>>>finer granularity than wsdl:binding elements. All this >>>> >>>> >>>needs be clarified. >>> >>> >>>>Jacques >>>> >>>> >>>> >>>> >>>section 4.1.4 of ws policy attachment >>>" >>>4.1.4 Message Policy Subject >>>The following WSDL/1.1 elements are used to describe messages: >>>* wsdl:message >>>* wsdl:portType/wsdl:operation/wsdl:input >>>* wsdl:portType/wsdl:operation/wsdl:output >>>* wsdl:portType/wsdl:operation/wsdl:fault >>>* wsdl:binding/wsdl:operation/wsdl:input >>>* wsdl:binding/wsdl:operation/wsdl:output >>>* wsdl:binding/wsdl:operation/wsdl:fault >>> >>>These elements MAY have Element Policy as per Section 3 of this >>>specification. The Policy Scope implied by these elements >>>contains the >>>Message Policy Subject representing the specific input, >>>output, or fault >>>message in relation to the Operation Policy Subject. Policy >>>attached to >>>a Message Policy Subject pertains to behaviours associated with a >>>particular message. This includes - but is not limited to - >>>sending and >>>receiving the message. The Effective Policy for a specific >>>WSDL message >>>(i.e., input, output, or fault message) is calculated in >>>relation to a >>>specific port, and includes the Element Policy of the wsdl:message >>>element that defines the message's type merged with the >>>Element Policy >>>of the wsdl:binding and wsdl:portType message definitions >>>that describe >>>that message. >>> >>>For example, the Effective Policy of a specific input message for a >>>specific port would be the merge of the wsdl:message element defining >>>the message type, the wsdl:portType/wsdl:operation/wsdl:input >>>element, >>>and the corresponding wsdl:binding/wsdl:operation/wsdl:input >>>element for >>>that message. >>> >>>Since a wsdl:message may be used by more than one >>>wsdl:portType, it is >>>RECOMMENDED that only policies containing abstract (i.e., binding >>>independent) assertions should be attached to this type of element. >>> >>>Since wsdl:input, wsdl:output, and wsdl:fault elements in a >>>wsdl:portType/wsdl:operation may be used by more than one >>>binding, it is >>>RECOMMENDED that only policies containing abstract (i.e., binding >>>independent) assertions should be attached to these types of >>>elements. >>>Care should be taken when attaching policies to outbound >>>messages as the >>>result may not be what is expected. For example, expressing a >>>choice on >>>a service's outbound message without a mechanism for a >>>requester of that >>>service to communicate its choice to the service before the outbound >>>message is sent may not result in the desired behaviours. >>> >>>It is therefore RECOMMENDED that Policy Alternatives on outbound >>>messages SHOULD be avoided without the use of some form of >>>mutual Policy >>>exchange between the parties involved. >>>" >>> >>>I am talking about attaching policy at the levels >>>* wsdl:binding/wsdl:operation/wsdl:input >>>* wsdl:binding/wsdl:operation/wsdl:output >>> >>> >>> >> >>This is exactly what I was suggesting as well in my email that >> >>-- RM assertion could apply to Message Policy Subject with the >>restriction that they should not apply to portType and be restricted to >>binding/operation/message. >> >>-- RM assertion to apply to either Message Policy Subject or Endpoint >>Policy Subject, but NOT both for simplicity. >> >> >>Wouldn't this solve the granularity problem? >> >> > Yes it would, but the question is "for what benefit" > > Since WSDL request/response operations are only mapped to synchronous > http request/response > (for whatever reason this restriction is still in the wsdl 2 soap > binding), it is difficult > to provide reliability on the synchronous response. > > Response reliability is much easier to provide if the application > response is sent as its own wsdl one-way > operation. > > For pragmatic reasons, I see no reason to go beyond specifying a default > behaviour in the spec > which attaches rm policy at the endpoint binding (or port) subject > level, leaving more detailed > attachments outside the scope of the ws-rm policy specification. > > Tom Rutt > >>--umit >> >> >> >> >>>-- >>>---------------------------------------------------- >>>Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com >>>Tel: +1 732 801 5744 Fax: +1 732 774 5133 >>> >>> >>> >>> >>> >> >> >> > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]