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


 

> -----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? 

--umit


> -- 
> ----------------------------------------------------
> 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]