RE: raw proposal for addressing several WS-Eventing issues

Thanks for your feedback Gil, much appreciated.

As we understand it, the Event Source is providing the "EventSinkWSDL" - i.e. the WSDL that the Event Sink has to implement.  Also sent as part of this Event Sink WSDL is the Policy of the Event Source (note, it is not the Policy of the Event Sink).  This Event Source Policy is sent as part of the WSDL in exactly the place where the Event Sink Policy should be.  So the Event Sink can't implement this WSDL as it stands, (nor return it at part of MEX) because the Policy of the Event Sink may be different than the Policy of the Event Source - there should be overlap, but they do not need to be the same.

So when the Event Sink gets the WSDL from the Event Source, it needs to:

1.      Find the Policy bit in the WSDL

2.      Make sure that the Event Source and the Event Sink Policies overlap

3.      Delete the Policy from the WSDL and replace it with the Event Sink policy - which will most likely be different. Where will the actual Event Sink's Policy for this event/message be described before this point?  There seems no place in any WSDL to describe it in.

4.      Implement that WSDL instead.

5.      Make sure the Sink remembers the Event Source Policy, so that the Event Sink will subscribe in the right way and get events in the right form.

Now imagine that the same Event Sink subscribes to three different Event Sources for the same Event - a very normal thing to do.
The first time, it will do as above.  The rest of the times, it will:

1.      Get the WSDL as before

2.      Find the Policy bit in the WSDL (this time ignoring the rest, which it hopes is the same)

3.      Make sure that the new Event Source and the Event Sink Policy overlap

4.      Make sure it remembers the Event Source Policy, so that the Event Sink will subscribe in the right way and get events in the right form.

Does putting the Event Source's Policy in the place in the WSDL where the Event Sink's Policy should be seem like an architectural problem?
And it still does not quite answer the question where the Event Sink's Policy is to be described.

As another, related question: If the Event Source sends its security policy to the Event Sink (via the WSDL), offering three different alternates, and the Event Sink can only deal with the "weakest" security option of the three, how does the Event Source know which one the Event Sink chose?

--Geoff


From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
Sent: Monday, February 16, 2009 12:12 PM
To: Geoff Bullen
Cc: Katy Warr; public-ws-resource-access@w3.org
Subject: Re: raw proposal for addressing several WS-Eventing issues

Geoff,

You ask some good questions. Yes, it may seem strange to have the Event Source "client" dictate policy to the Event Sink "server" but I don't think that means there is anything technically wrong with the idea. I think that it would be helpful to let go of our rigid ideas about "what's a server" and "what's a client". The reality of this situation is that the Event Source is a provider of services and the Event Sink is the consumer of those services. As the provider it is incumbent upon the Event Source to indicate the policies that it is willing to support both as they pertain to the WS-Eventing interface and the Notification Interface. As a consumer the Event Sink either has to work within those policies or find another provider.

Specific responses inline:

Geoff Bullen wrote:
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.

Must the sink implement the policy provided by the source?
The Event Sink MUST implement the required (i.e. non-optional policy alternatives); it MAY implement the optional policies.


Since it is a one way message, how can negotiation take place?
At subscribe time the Event Sink should indicate in the Notification EPR (using either WS-Mex or WS-PAEPR - TBD) which policies it wants to support for this subscription.


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?
See above.


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?
Not the ones I envision. The Event Source produces the Notifications and it is the thing that dictates what the Notification Interface (including the policies that apply thereto) looks like.

- gp

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: Wednesday, February 04, 2009 3:05 PM
To: Katy Warr
Cc: public-ws-resource-access@w3.org<mailto: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