Re: raw proposal for addressing several WS-Eventing issues

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