Re: [ws-rx] i021 proposal

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Paul Fremantle wrote:
> Anish
> 
> I don't think I agree. The aim of the porttype is to provide an abstract 
> interface. The interface has not even been bound to SOAP. In fact if you 
> look at Apache WSIF (http://ws.apache.org/wsif  which I think Oracle 
> uses in your Collaxa BPEL server), that binds portTypes to all kinds of 
> other models including Java, EJB, CICS, etc. It isn't appropriate to 
> specify that those use RM.
> 

Makes sense.

> In the proposed model if you want to require RM on every binding you 
> need to add it to each binding.
> 

I was trying to see if there is an easier way (by tagging the portType) 
for the situation where there is a portType which is bound to SOAP/HTTP, 
SOAP/UDP, SOAP/SMTP, SOAP/XMPP, and SOAP/whatever. I guess, every 
binding/port will have to be tagged instead

-Anish
--

> Paul
> 
> Anish Karmarkar wrote:
> 
>> Paul,
>>
>> Thanks for sending this out. Generally, it looks good to me.
>>
>> One comment:
>>
>> > WS-PolicyAttachment [WS-PolicyAttachment] defines both abstract and
>> > concrete attachment points in WSDL [WSDL1.1]. Because the RM policy
>> > assertion specifies a concrete behavior, it MUST NOT be attached to
>> > abstract constructs
>>
>> Is that quite true or necessary?
>> 'Abstract,' I assume means binding/endpoint independent. For example, 
>> the sept 2004 policy attachment spec says in section 4.1.2:
>> "Since the wsdl:portType 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 this type of element."
>>
>> Now, if I want every binding/endpoint of a portType to support/require 
>> WSRM (say it is a banking application portType) would it not be 
>> reasonable to include the assertion in the portType?
>>
>> Thanks.
>>
>> -Anish
>> -- 
>>
>> Paul Fremantle wrote:
>>
>>> Proposal regarding issue 021. I'm not quite sure this is right yet, 
>>> so I would appreciate feedback from the Policy experts.
>>>
>>> Based on CDII
>>>
>>> Delete 142-154 section 2.3 and replace with.
>>>
>>> 2.3 Assertion Attachment
>>>
>>> The RM assertion can have Service, Endpoint, Operation or Message 
>>> Endpoint Policy Subjects [WS-PolicyAttachment].
>>>
>>> WS-PolicyAttachment [WS-PolicyAttachment] defines both abstract and 
>>> concrete attachment points in WSDL [WSDL1.1]. Because the RM policy 
>>> assertion specifies a concrete behaviour, it MUST NOT be attached to 
>>> abstract constructs:
>>>
>>>    * wsdl:portType
>>>    * wsdl:portType/wsdl:operation
>>>    * wsdl:portType/wsdl:operation/wsdl:input
>>>      • wsdl:portType/wsdl:operation/wsdl:output
>>>      • wsdl:portType/wsdl:operation/wsdl:fault
>>>    * wsdl:message
>>>
>>> The RM policy assertion MAY be attached to the following constructs
>>> * wsdl:service
>>> * wsdl:port
>>> * wsdl:binding.
>>> • wsdl:binding/wsdl:operation
>>> • wsdl:binding/wsdl:operation/wsdl:input
>>> • wsdl:binding/wsdl:operation/wsdl:output
>>> • wsdl:binding/wsdl:operation/wsdl:fault
>>>
>>> If the RM assertion is attached to the wsdl:service construct, it 
>>> MUST be considered to apply to all the wsdl:port's referenced in the 
>>> binding.
>>> If the RM assertion is attached to the wsdl:port construct, it MUST 
>>> be considered to apply to all the wsdl:binding's referenced in the port.
>>> If the RM assertion is attached to the wsdl:binding construct, it 
>>> MUST be considered to apply to all the wsdl:operation's referenced in 
>>> the binding.
>>> If the RM assertion is attached to the wsdl:operation construct, it 
>>> MUST be considered to apply to all the wsdl:input's, wsdl:output's 
>>> and wsdl:fault's referenced in the operation.
>>>
>>> WS-Addressing allows for policy assertions to be included within an
>>> EndpointReference. Per section 2.2 above, the presence of this
>>> policy assertion in an EPR specifies the level of support for
>>> WS-ReliableMessaging offered by that endpoint.
>>>
>>> Paul
>>>
>