RE: raw proposal for addressing several WS-Eventing issues

Gil,
It is not yet clear from below what setting policy on the notifications in the EventSinkWSDL  actually means here.
In this case things are reversed.  It seems strange that the event source (the "client" in this case) would send policy to the event sink (the "server"), expecting it to implement it.  Normally the server tells the client what it can handle (in terms of policy) and a negotiation takes place between the client and server.

1.      Must the sink implement the policy provided by the source?

2.      Since it is a one way message, how can negotiation take place?

3.      What if the source can use many different (say security) policies?  If they all are put in the EventSinkWSDL and the sink chooses to implement only one of them, how does the source know which one was chosen?

4.      Do eventing scenarios include an Event Source (perhaps after the initial subscribe has been received) fetching the Event Sink metadata (especially the policy) prior to sending event notifications to the Event Sink?
Thanks,
Geoff


From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert Pilz
Sent: Wednesday, February 04, 2009 3:05 PM
To: Katy Warr
Cc: public-ws-resource-access@w3.org
Subject: Re: raw proposal for addressing several WS-Eventing issues

Ha! Now I get to this email :-)

Yes Katy, as you can probably tell by my recent messages, I think you are right; policy is crucial to this discussion. Fortunately, for the "separate WSDLs" proposal, the answer is pretty straightforward. If you want to associate a policy with the Subscription Endpoint (the endpoint to which you send Subscribe messages) you include that policy in the WSDL that describes the Subscription Endpoint and attach it to the wsdl:port (or wsdl:binding, . . .) for that endpoint. If you want to associate a policy with the Notifications that will be consumed by the Event Sink you include it in the WSDL that describes the Notifications (the one referenced by wsep:EventSinkWSDL) and you attach it to the wsdl:binding; "Endpoint Policy Subject" in this case refers to the endpoint in /wse:Subscribe/wse:Delivery/wse:NotifyTo.

You are also right about using WST GET to retrieve the Notification WSDL.

- gp

Katy Warr wrote:

Hi Gil

Should we clarify how to associate other flavours of policy to the subscription request, in particular, is there a possibility that security may be required on these requests (or not)?  I'm just wondering whether we should discuss how these might fit with this proposal (or is this better as a separate issue if required?)

I suppose including/referencing EventSinkWSDL would also allow policy (again, I'm thinking security) to be specified for the notification operations?  This would mean that the EventSink was aware of any policies that the EventSource would require when sending its notifications.

Also, one small point - in the second example (returning the mex:MetadataReference to identify the EventSinkWSDL) you say:
"In this case the user would be expected to retrieve the Notification WSDL by doing a WS-Transfer GET or a WS-MEX GET on 'http://webservice.bea.com/RoomTracker/soap12WNotify'. "
I believe that this would require the user to retrieve this WSDL via WST GET and not WS-Mex.  WS-Mex GetMetadata targeted at the metadataReference would return the metadata reference's metadata.  My head hurts when I think about this :o)

regards
Katy


From:

Gilbert Pilz <gilbert.pilz@oracle.com><mailto:gilbert.pilz@oracle.com>

To:

Geoff Bullen <Geoff.Bullen@microsoft.com><mailto:Geoff.Bullen@microsoft.com>

Cc:

"public-ws-resource-access@w3.org"<mailto:public-ws-resource-access@w3.org> <public-ws-resource-access@w3.org><mailto:public-ws-resource-access@w3.org>

Date:

03/02/2009 00:39

Subject:

Re: raw proposal for addressing several WS-Eventing issues


________________________________



Geoff,

Again, this proposal is still in flux, but here is how I imagined it looking:

<wsdl:service name="ReservationNotifyService">
 <wsdl:port name="soap12port" binding="tns:ResvSOAP12Binding">
   <wsdl:documentation>
     This port supports the use of WS-Eventing to act a subscription endpoint
     for notifications on room availability and cancellations.
   </wsdl:documentation>
   <soap:address location="http://webservice.bea.com/RoomTracker/soap12"<http://webservice.bea.com/RoomTracker/soap12>/>
   <wsp:Policy>
     <wsep:WSEventing>
       <wsp:Policy>
         <wsep:EventSinkWSDL wsp:Ignorable="true">
           http://webservice.bea.com/RoomTracker/soap12WNotify?WSDL
         </wsep:EventSinkWSDL>
         . . .
       </wsp:Policy>
     </wsep:WSEventing>
   </wsp:Policy>
 </wsdl:port>
</wsdl:service>

The above declares a service with a single port/endpoint at "http://webservice.bea.com/RoomTracker/soap12"<http://webservice.bea.com/RoomTracker/soap12>. This endpoint supports a SOAP 1.2 binding of some portType (not shown here and not really relevant). This endpoint also acts a WS-Eventing Subscription Endpoint meaning that you can send it a wse:Subscribe message and expect to get a wse:SubscribeResponse. Event Sinks that are subscribed to this Subscription Endpoint will be expected to implement the WSDL at "http://webservice.bea.com/RoomTracker/soap12WNotify?WSDL"<http://webservice.bea.com/RoomTracker/soap12WNotify?WSDL>.

In WS-Policy speak, the subject of the wsep:WSEventing policy assertion is the endpoint. It seems to make sense to allow this assertion to be attached at either the wsdl:port or the wsdl:binding.

As using MEX there are two use cases that I'm thinking about. The first is the case where a user does a WS-MEX get on the Subscription Endpoint and the returned mex:Metadata element contains one mex:MetadataSection with the Subscription Endpoint WSDL (which contains the wsdl:port shown above), and another mex:MetadataSection with the Notification WSDL. This later section would be identified with a mex:@Dialect='http://www.w3.org/2009/02/ws-eventing/policy/NotificationWSDL' or some such. Rather than a URL, the wsep:EventSinkWSDL element in the above policy would refer to the mex:@Identifier corresponding to the section that contained the Notification WSDL. The whole point of this use case is to obtain all the metadata needed to both subscribe to the Event Source as well as implement the Event Sink in a single operation.

The second case is where the wsep:WSEventing policy explicitly declares the reference to the Notification WSDL as a mex:MetadataReference. For example, you might have a policy that looks like this:

<wsp:Policy>
 <wsep:WSEventing>
   <wsp:Policy>
     <wsep:EventSinkWSDL wsp:Ignorable="true">
       <mex:MetadataReference>
         <wsa:Address>
           http://webservice.bea.com/RoomTracker/soap12WNotify
         </wsa:Address>
       </mex:MetadataReference>
     </wsep:EventSinkWSDL>
     . . .
   </wsp:Policy>
 </wsep:WSEventing>
</wsp:Policy>

In this case the user would be expected to retrieve the Notification WSDL by doing a WS-Transfer GET or a WS-MEX GET on 'http://webservice.bea.com/RoomTracker/soap12WNotify'. I'm not sure if this is an important use case since it is basically the same as doing an HTTP GET on the URL (as in the original example), but I need to think about this . . .

- gp

Geoff Bullen wrote:
Gil,
We are not sure how to react to this proposal yet, and are trying to understand it better.
One thing that is not clear from your proposal is how (and where) your policy statements would be attached to the Event Source's WSDL.  You do give an example of how it might be returned using MEX, but there is also a requirement to allow tools to use this information at development time as well, and thus the assumption that these policies will also form part of the Event Source WSDL in some way.  We would appreciate it if you could provide an example of an Event Source WSDL containing these policy statements.
Thanks,
--Geoff

From: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org> [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert Pilz
Sent: Monday, January 26, 2009 10:03 PM
To: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>
Subject: raw proposal for addressing several WS-Eventing issues

Attached is a raw proposal for addressing several of the issues that have been filed against WS-Eventing (and some issues that have yet to be filed). This proposal is only an outline of some of our ideas on how to address the following problems:

 *   For a given Event Source/Subscription Manager, how do I (the potential Subscriber) know what filter types and delivery modes are supported? This issue will expand if/when we add more optional features to the protocol. For example, if we define optional Pause and Resume operations, we will need some way for a Subscription Manager to indicate whether or not it supports these. This issue corresponds to 6402.
 *   For a given Event Source, how do I (the potential Event Sink) know which Notification messages I can expect to receive and the form and content of these Notifications? The current solution is problematic for a number of reasons, the foremost being that it requires the use of out-only operations in the Event Source WSDL. This issue corresponds to 6401 and some parts of 6430.
Sometimes it is difficult to think about individual solutions to these issues as they all relate to one another; hence this proposal. The intent is to foster discussion along the lines of "what if we did something like this?" Again, I want to stress that this is a very raw proposal. It is still a work in progress and we're open to any constructive suggestions . . .

- gp



________________________________


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU