This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
WS-Eventing defines an output-only operation: <wsdl:portType name="EventSource" > ... <wsdl:operation name="SubscriptionEnd" > <wsdl:output message="wse:SubscriptionEnd" wsa:Action=" http://schemas.xmlsoap.org/ws/2004/08/eventing/SubscriptionEnd"/> </wsdl:operation> </wsdl:portType> WS-I Basic Profile R2303 says the following: 4.5.2 Allowed Operations Solicit-Response and Notification operations are not well defined by WSDL 1.1; furthermore, WSDL 1.1 does not define bindings for them. R2303 A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition. Proposal: Remove this operation.
Doug, Our understanding to your proposal is: it intends to propose a BP compliant (e.g. reverse into in-only at client) alternative of Eventing. It is not to eliminate the SubscriptionEnd function of Eventing. The SubscriptionEnd is a critical function of Eventing for server to notify the subscriber that its subscription has ended un-expectedly. Without it, client is totally in the dark, when the eventing service needs to end unexpectedly. Please confirm if our understanding to your proposal is correct. - Wu Chou. (In reply to comment #0) > WS-Eventing defines an output-only operation: > <wsdl:portType name="EventSource" > > ... > <wsdl:operation name="SubscriptionEnd" > > <wsdl:output > message="wse:SubscriptionEnd" > wsa:Action=" > http://schemas.xmlsoap.org/ws/2004/08/eventing/SubscriptionEnd"/> > </wsdl:operation> > </wsdl:portType> > WS-I Basic Profile R2303 says the following: > 4.5.2 Allowed Operations > Solicit-Response and Notification operations are not well defined by WSDL > 1.1; furthermore, WSDL 1.1 does not define bindings for them. > R2303 A DESCRIPTION MUST NOT use Solicit-Response and Notification type > operations in a wsdl:portType definition. > Proposal: > Remove this operation.
Wu, yes, given the current proposal on the table for doing the events as input-only ops, I think it would make sense to do the same for this operation as well and put it in the same WSDL. One thing I'd like to hear your opinion on is whether we really need a separate EPR for this notification or whether it can just be the last event in the event stream sent to the NotifyTo EPR? I have a hard time understanding why they wouldn't always be the same endpoint. Seems like an over complication for very limited benefit.
Proposal of 2009-03-10 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0051.html
Agreed 2009-03-10 with proposal in comment#3 but over-night review requested by Wu
reviewed and agreed on 2009-03-11 with the change: SubscriptionEndPort to SubscriptionEndPortType