Re: raw proposal for addressing several WS-Eventing issues

Gil,

You wrote:
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.

In the example below, I'm wondering - would the security policy for the 
subscription requests need to be nested within the wsep:Eventing policy 
that was associated with the endpoint [2] or associated with the endpoint 
directly [1]?

<wsdl:service name="ReservationNotifyService">
 <wsdl:port name="soap12port" binding="tns:ResvSOAP12Binding">
   <wsp:Policy>
     [1]
     <wsep:WSEventing>
       <wsp:Policy>
          [2]
       </wsp:Policy>
     </wsep:WSEventing>
   </wsp:Policy>
 </wsdl:port>
</wsdl:service>

Thanks
Katy



From:
Gilbert Pilz <gilbert.pilz@oracle.com>
To:
Geoff Bullen <Geoff.Bullen@microsoft.com>
Cc:
Katy Warr/UK/IBM@IBMGB, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>
Date:
16/02/2009 20:16
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.
1.      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.
2.      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.
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?
See above.
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?
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] 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> 
To: 
Geoff Bullen <Geoff.Bullen@microsoft.com> 
Cc: 
"public-ws-resource-access@w3.org" <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"/>
   <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". 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".

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] On Behalf Of Gilbert Pilz
Sent: Monday, January 26, 2009 10:03 PM
To: 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 












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