Re: output-only operations break WS-PolicyAttachment semantics

I thought of another, more compelling use case for differentiating the 
policies that are applied to the Subscription Endpoint and the Event 
Sink. Suppose you want to authenticate your subscribers so that you can 
control who does and doesn't get to subscribe. You'll need a WS-Sec 
policy on the Subscription Endpoint that describes how this should be 
done (username/token, X.509, which ciphersuites, supported CAs, etc.). 
Suppose that your Notification volume is so high that you can't support 
the use of WS-Sec on Notifications or perhaps you want to apply a 
different profile or use WS-SecureConversation, etc.? I can't see any 
reasonable way to support this under the model where the Subscription 
Endpoint implements a binding of a portType that contains output-only 
operations which describe the Notifications.

- gp

Gilbert Pilz wrote:
> Here's an argument against output-only operations that has nothing to 
> do with BP compliance. Suppose I have the following situation: I have 
> pub/sub situation in which I want to require that Notifications must 
> be sent reliably but (because I don't send enough of them to make it 
> worth the overhead) I don't want the Subscribe, Renew, or Cancel 
> messages to be sent reliably. Here's a first cut at what a WSDL for 
> this might look like if we used the mechanism in Appendix I of the 
> Member Submission:
> <wsdl:definitions . . .>
>
>   . . .
>
>   <wsp:Policy wsu:Id="RMPolicy">
>     <wsrmp:RMAssertion>
>       . . .
>     </wsrmp:RMAssertion>
>   </wsp:Policy>
>
>   <wsdl:portType name="Warnings" wse:EventSource="true" > 
>     <wsdl:operation name="WindOp" > 
>       <wsdl:output message="tns:WindMsg" /> 
>     </wsdl:operation> 
>   </wsdl:portType>
>
>   . . .
>
>   <wsdl:service name="WindService>
>     <wsdl:port name="soap12port" binding="tns:WarningSOAP12Binding">
>       <soap:address . . ./>
>       <wsp:PolicyReference URI="#RMPolicy">
>     </wsdl:port>
>   </wsdl:service>
> </wsdl:definitions>
>   
> This is wrong. According to WS-RM Policy [1] and WS-PolicyAttachment 
> [2], this means that I require WS-RM for all messages sent to the 
> "soap12port" of "WindService" (which includes Subscribe, Renew, etc.) 
> and I don't want to do that. So let's take another stab at this and 
> attach the policy to the wsdl:binding:
> <wsdl:definitions . . .>
>
>   . . .
>
>   <wsp:Policy wsu:Id="RMPolicy">
>     <wsrmp:RMAssertion>
>       . . .
>     </wsrmp:RMAssertion>
>   </wsp:Policy>
>
>   <wsdl:portType name="Warnings" wse:EventSource="true" > 
>     <wsdl:operation name="WindOp" > 
>       <wsdl:output message="tns:WindMsg" /> 
>     </wsdl:operation> 
>   </wsdl:portType>
>
>   <wsdl:binding name="WarningsSOAP12Binding" type="tns:Warnings">
>     <soap:binding style="document" . . ./>
>     <wsp:PolicyReference URI="#RMPolicy"/>
>     <wsdl:operation name="WindOp">
>       <soap:operation/>
>       <wsdl:output>
>         <soap:body use="literal"/>
>       </wsdl:output>
>     </wsdl:operation>
>   </wsdl:binding>
>
>   <wsdl:service name="WindService>
>     <wsdl:port name="soap12port" binding="tns:WarningSOAP12Binding">
>       <soap:address . . ./>
>     </wsdl:port>
>   </wsdl:service>
> </wsdl:definitions>
> This still isn't correct however. WS-RM Policy states that doing the 
> above means that the RM applies to the Endpoint Policy Subject. 
> Endpoint Policy Subject means *all* messages sent to the endpoint. We 
> (the WS-RA WG) could assert that the wse:EventSource="true" means that 
> any policies attached to the binding apply only to the Notification 
> messages but that contradicts WS-RM Policy and WS-PolicyAttachment. 
> (You could also attach the RMPolicy to individual messages, but WS-RM 
> Policy get's complicated when you do that - we could dig into this if 
> anyone wants).
>
> Now generalize the above problem. For any policy (security, 
> transactionality, reliability, etc.) that you might wish to apply to 
> Notifications but not the Subscription Endpoint (or vice versa) you 
> have to override the language that specifies the relationship between 
> where the policy is attached and its intended subject. This is because 
> that, for many years now, the model has been that a WSDL describes the 
> service *as a receiver*. The use of the wse:EventSource on portTypes 
> containing output-only operations has the effect of combining two 
> interfaces into a single endpoint; the WS-Eventing-defined interface 
> (Subscribe, etc.) and whatever, app-level interface has been extended 
> with wse:EventSource. The former is an inbound interface and the later 
> an outbound interface, but they share a single wsdl:port declaration. 
> None of the current specs and functionality based on WS-Policy and 
> WS-PolicyAttachment, nor these specs themselves, takes into account 
> this kind of endpoint.
>
> The "define the Notification interface/binding in a separate WSDL" 
> proposal does *not* suffer from these problems. You could specify the 
> Notification WSDL like so:
> <wsdl:definitions . . .>
>
>   . . .
>
>   <wsp:Policy wsu:Id="RMPolicy">
>     <wsrmp:RMAssertion>
>       . . .
>     </wsrmp:RMAssertion>
>   </wsp:Policy>
>
>   <wsdl:portType name="Warnings">
>     <wsdl:operation name="WindOp" > 
>       <*wsdl:input* message="tns:WindMsg" /> 
>     </wsdl:operation> 
>   </wsdl:portType>
>
>   <wsdl:binding name="WarningsSOAP12Binding" type="tns:Warnings">
>     <soap:binding style="document" . . ./>
>     <wsp:PolicyReference URI="#RMPolicy"/>
>     <wsdl:operation name="WindOp">
>       <soap:operation/>
>       <*wsdl:input*>
>         <soap:body use="literal"/>
>       </wsdl:output>
>     </wsdl:operation>
>   </wsdl:binding>
>
> </wsdl:definitions>
>   
> then link the Subscription Endpoint to this WSDL using the 
> wsep:EventSinkWSDL nested policy assertion. Because the Notification 
> interface/binding is in a separate wsdl:definition, you don't have the 
> problem of attempting to distinguish between two interfaces that share 
> a common endpoint. The RMPolicy in the above WSDL has Endpoint Policy 
> Subject (as WS-RM Policy says it does), but the endpoint in question 
> is clearly the Notification Endpoint *not* the Subscription Endpoint.
>
> Based on the above I assert that it will be much easier to enhance 
> existing, policy-aware, WSDL tools to support wsep:EventSinkWSDL than 
> it will be to make such tools support the idea of "two interfaces, one 
> endpoint" and attempt to sort out which policies apply to which interface.
>
> [1] 
> http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.2-spec-cs-02.html
> [2] http://www.w3.org/TR/2007/CR-ws-policy-attach-20070228/
>
> - gp