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 proposal


Anish

I understand. I think that was also the motivation behind Gil's proposal 
(make it easy to tag all the inbound or all the outbound messages). 
However, I think that the most likely case is that the whole binding 
will be tagged. Typically not every binding is suitable for RM, because 
many systems generate HTTP bindings. So I think using PolicyAttachment 
to do the main work is probably the best case.

WSDL and WSP are not exactly human friendly anyway - so we aren't really 
making things worse than they are already :) I'm guessing most systems 
will generate this automatically from a systems admin GUI.

Paul

Anish Karmarkar wrote:
> 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
>>>>
>>

-- 

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com



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