- From: Doug Davis <dug@us.ibm.com>
- Date: Mon, 16 Feb 2009 09:17:23 -0500
- To: Geoff Bullen <Geoff.Bullen@microsoft.com>
- Cc: Gilbert Pilz <gilbert.pilz@oracle.com>, Katy Warr <katy_warr@uk.ibm.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, public-ws-resource-access-request@w3.org
- Message-ID: <OF3609661F.1C31178D-ON8525755F.004C2AAF-8525755F.004E8A23@us.ibm.com>
My view on this... (inline)
thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
Geoff Bullen <Geoff.Bullen@microsoft.com>
Sent by: public-ws-resource-access-request@w3.org
02/13/2009 06:50 PM
To
Gilbert Pilz <gilbert.pilz@oracle.com>, Katy Warr <katy_warr@uk.ibm.com>
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
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.
<dug> it means the event sink is expected to support that policy - this is
no different that the wsdl itself. If the event sink can not support the
wsdl/policy then they can't play in this game </dug>
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.
<dug> Actually, both happen in this case. In this situation the event
source is the driver of these MEPs so its the one that decides what it
will send and how it will send it. If the event source only supports
sending Notifications with RM then its policy needs to clearly indicate
that - and the Subscriber can decide to subscribe (or not) based on this
information. If the event source doesn't care (meaning it can send them
with and w/o RM and it includes the RM policy assertion as an option in
its Policy) then unless the subscriber indicates that the Notifications
are to be sent using RM (by including the RM Policy in its NotifyTo EPR)
then the event source is free to turn on RM as it wishes. </dug>
1. Must the sink implement the policy provided by the source?
<dug> yes </dug>
2. Since it is a one way message, how can negotiation take place?
<dug> The negotiation takes place between what's in the NotifyTo EPR and
what's in the EventSinkWSDL </dug>
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?
<dug> The NotifyTo EPR and policy matching </dug>
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?
<dug> Not fetching but examining the NotifyTo EPR and doing policy
matching. I guess it could fetch it if it really wanted to as well, but
it should return the same stuff as what's in the EPR. </dug>
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
Received on Monday, 16 February 2009 14:18:33 UTC