Re: Proposal for WS-Eventing Issue 6429

Gil,
   perhaps I'm not following your last paragraph, but wouldn't:
<wsp:WSEventing>
  <wsp:Policy>
    <wsep:EventSinkWSDL wsp:Ignorable="true">
      http://webservice.bea.com/RoomTracker/soap12WNotify?WSDL
    </wsep:EventSinkWSDL>
    <wsep:Wrapped wsp:Optional="true"/>
  </wsp:Policy>
</wsp:WSEventing>

allow an event source to indicate that it supports both wrapped and 
unwrapped notifications? 
The EventSinkWSDL will include both types of notifications (the individual 
events + the wrapped one).  And based on what the Subscribe looks like 
they will only need to support one flavor of the operations.  In this 
respect the WSDL would contain the list of 'possible' messages sent by the 
event source - which ones apply to which subscription/event-sink will vary 
depending on what's in the Subscribe.

ps. I'd prefer if the wrapped assertion was something like:
        <x:Format xmlns:x="http://www.w3c.org/.../policy/format/Wrapped"/>
This would be more consistent with the other extensible assertions.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com



Gilbert Pilz <gilbert.pilz@oracle.com> 
Sent by: public-ws-resource-access-request@w3.org
01/29/2009 07:45 PM

To
Li Li <lli5@avaya.com>
cc
public-ws-resource-access@w3.org
Subject
Re: Proposal for WS-Eventing Issue 6429






There was some discussion on the concall of Jan 27th, (2009 for future web 
services archaeologists) about how this proposal would dovetail with my 
meta-proposal (
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0051.html
). The following is some detail on how this might work:

First assume that support for wrapped Notifications is optional for both 
Event Sources and Event Sinks. To allow an Event Source to advertise that 
it supports and/or requires the use of wrapped Notifications we define the 
wsep:Wrapped nested policy assertion. An policy that used this assertion 
might look like the following:
<wsp:WSEventing>
  <wsp:Policy>
    <wsep:EventSinkWSDL wsp:Ignorable="true">
      http://webservice.bea.com/RoomTracker/soap12WNotify?WSDL
    </wsep:EventSinkWSDL>
    <wsep:Wrapped/>
  </wsp:Policy>
</wsp:WSEventing>

The above means that:
1.      WS-Eventing is supported by the endpoint to which this policy is 
attached (i.e. the endpoint is a Subscription Endpoint).
2.      The notification WSDL is at "
http://webservice.bea.com/RoomTracker/soap12WNotify?WSDL".
3.      The Subscription Endpoint supports wrapped Notifications only. If 
you send a Subscribe message with a @Format other than "wrapped" the Event 
Source will reject the request and generate a fault.
The WSDL at "http://webservice.bea.com/RoomTracker/soap12WNotify?WSDL" 
might look like the following:
<wsdl:definitions
  targetNamespace="http://.../reservations"
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
  xmlns:wse="http://www.w3.org/2009/08/ws-eventing"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
  <!-- Import GenericSinkPortType and messages from W3C site -->
  <wsdl:import namespace="http://www.w3.org/2009/08/ws-eventing"
               location=
"http://www.w3.org/2009/08/ws-eventing/GenericSink.wsdl"/>
  <wsdl:binding name=?CancellationNotificationsSOAP12Binding?
                type=?wse:GenericSinkPortType?>
    <wsdl:documentation>
      This is a SOAP 1.2 Doc/Lit binding of the WS-Eventing-defined 
wrapped interface.
    </wsdl:documentation>
    <soap:binding style="document"
                  transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name=?NotifyEvent?>
      <soap:operation/>
      <wsdl:input>
        <soap:body use=?literal?/>
      </wsdl:input>
    </wsdl:operation>
  </wsdl:binding>
</wsdl:definitions>
As you can see, this WSDL imports the GenericSinkPortType (with attendant 
message and type definitions). It then specifies a SOAP 1.2, Doc/Lit 
binding of this portType to use as the Notification Binding. This solves 
one of the problems with Li's proposal that I brought up at the F2F; "how 
do I know what kind of binding to use for generic notifications?"

You may have noticed that there is a bit of redundancy in the above model. 
Because it uses the GenericSinkPortType, the Notification Binding we've 
specified can't be used with anything but wrapped notifications, a fact 
which is also advertised by the wsep:Wrapped assertion. I can't really 
think of a way around this right now. I certainly wouldn't want Event 
Sinks and/or Subscribers to have to infer the @Format of the Subscription 
based on the Notification WSDL.

The other thing that is bother me is the treatment of the wsp:Optional 
attribute and the wsep:Wrapped assertion. Given a particular Notification 
Binding you either do or don't have to send wrapped Notifications; there 
isn't really any optionality allowed. In other words, in this model it 
isn't possible to define a Subscription Endpoint that simultaneously 
supports both wrapped and unwrapped versions of the same Notifications.

- gp