RE: raw proposal for addressing several WS-Eventing issues

Gil,

If we would like to require some of the Eventing messages to be protected, how would we specify that, if the EventSource portType and its binding are implicit? Or, in general, how does this proposal compose with WS-SecurityPolicy or other policy assertions?  How would we specify if the optional operations in Eventing are supported or not?

We believe Eventing is an app protocol and different from infrastructure protocols such as SRT protocols.

The WS-Policy Guidelines for Policy Assertion Authors document recommends [1] that assertion authors should clearly specify how an assertion may compose with other related assertions, if any.

--Geoff

[1] http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#bp-specify-composition


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

Actually the "tns:ResvSOAP12Binding" points to some application-specific binding that, in this case, is presumed to have something to do with reserving rooms. Like WS-RM and other infrastructure protocols, the "EventSource" portType is implicitly added to an endpoint when it advertises that it supports WS-Eventing via the wsep:Eventing assertion. It is worth noting that, if you wanted an endpoint that functioned *only* was a Subscription Endpoint, you could create an "empty binding" with no operations then attach wsep:Eventing to a wsdl:port that supported that binding.

I'm not sure what you mean by saying that my policy statement does not replace any WSDL statements?

- gp

Geoff Bullen wrote:
Gil,
Thanks for providing this example below, it does help to further understand you proposal.
The binding tns:ResvSOAP12Binding would point to a Eventing "EventSource" porttype, as defined in the spec, correct?  Your policy statements does not replace any WSDL statements, correct?
--Geoff

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
Sent: Monday, February 02, 2009 4:37 PM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>
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