[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]