RE: WS-Eventing Issue 6425 proposal

Hi Wu,
I have two questions for you:

1)      In your proposal doc you say: "Sometimes it is possible to express this information as a filter. But it depends on existence of a filter implementation. It also does not tie the lifecycle of subscription with that of the dynamic event sources."

Can you explain this a little more about the lifecycle tie in please?

2)      In the doc you partly describe an example.  Could you please describe a real world interop scenario for this?

Cheers,
Geoff


From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Chou, Wu (Wu)
Sent: Tuesday, February 10, 2009 11:29 AM
To: Doug Davis
Cc: Gilbert Pilz; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: WS-Eventing Issue 6425 proposal

Doug,

The whole proposal is quite simple and only one sentence: "The event source shall be addressed by a WS-Addressing 1.0 EPR and the request message shall be sent to this EPR, as defined in WS-Addressing 1.0 Core Section 3.1-3.3."

The intention is to prevent subscriber from using ad-hoc method (e.g. custom soap headers) outside EPR to indicate targeted event source. Normatively referencing REC version of WS-Addressing can mean too many things, e.g. core, soap/wsdl, meta information, etc. The concern is: some implementation may claim normative referencing to WS-Addressing and WS-Eventing, while using some additional information outside the EPR to indicate targeted event source. If this happens, interoperability will become an issue.

We are open to suggestions to refine this sentence. We had a discussion with Gil and he said he would give it a try.

Thanks,

- Wu Chou.

________________________________
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Friday, February 06, 2009 11:30 AM
To: Chou, Wu (Wu)
Cc: Gilbert Pilz; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: WS-Eventing Issue 6425 proposal

Hi Wu,
  thanks for the reply.  Can you elaborate a bit more on why this is needed?  While I understand what you said in your note, I'm struggling with why this one specification is special.  By this I mean, other WS specs don't make this kind of statement.  How the client obtains the reference to the service is really left as an exercise for reader.  Whether the reference came from WSDL, or from some registry, or whether its a full EPR or just a URI are all problems that the client just has to deal with.  And this is true for any interaction between a client and service.  We've agreed that WS-Eventing will normatively reference (and use) the REC version of WS-Addressing, so do we really need to say anything more?
  I get the sense that there's something deeper behind this that I'm missing.  Perhaps it would help me understand it better if I turn this around and ask what would break or cause an interoperability problem by not having this additional sentence?  Do you have an example of a case where even after both parties agreed to use the REC version of WS-Addressing, there were still interop issues?  Does this sentence imply any new requirements on either party?  For example, does this require the event source's WSDL to include an embedded EPR in the port?

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com

"Chou, Wu (Wu)" <wuchou@avaya.com>
Sent by: public-ws-resource-access-request@w3.org

02/06/2009 11:04 AM

To

Doug Davis/Raleigh/IBM@IBMUS, "Gilbert Pilz" <gilbert.pilz@oracle.com>

cc

<public-ws-resource-access@w3.org>, <public-ws-resource-access-request@w3.org>

Subject

RE: WS-Eventing  Issue 6425 proposal







Doug, Gil,

Thanks for your comments. The whole proposal 6425 is to add one sentence: "The event source is addressed by a WS-Addressing 1.0 EPR and the request message shall be sent to this EPR, as defined in WS-Addressing 1.0 Core Section 3.1-3.3."

We feel this more definitive statement  is needed, because there are multiple versions of WS-Addressing being used and there are multiple ways to interpret/use event source and EPR in current WS-Eventing.

You can ignore all the rest  in this proposal, i.e. the 2nd part (background/rationale), because the second part is just some background information. It is not part of the proposed change to WS-Eventing.

Regards,

- Wu Chou

Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs Research | AVAYA | 233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax: 908-696-5198 / 908-696-5401 | wuchou@avaya.com<mailto:wuchou@avaya.com>

________________________________
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, February 04, 2009 8:26 PM
To: Chou, Wu (Wu)
Cc: public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: Re: WS-Eventing Issue 6425 proposal


Wu,
 I don't understand the purpose behind the first part of your proposal.  I think WS-Eventing is pretty clear that the Subscribe is sent to the Event Source and that the Event Source's EPR turns into the WSA headers - per WSA rules.  Could you elaborate on why there is confusion on this?

 On the 2nd part of your proposal... I think what you are proposing, if I understand it, is mostly fine but out of scope for WS-Eventing.  When a Subscriber sends a Subscribe() message to an Event Source it had to get the Event Source's EPR from someplace - perhaps some WSDL.  Regardless of how it got that EPR, it is up to the Event Source to determine what the EPR looks like.  If it wants to have reference parameters that have a portType or csta ID then that's fine but its not really any of WS-Eventing concern how it makes this decision.  But most importantly, the subscriber should not need to know this or even care.  To it, the EPR is just an opaque bit of XML.

 Also, within your proposal you talk about using ref-params as a, sort of, filtering mechanism.  While this is legal because an Event Source can choose to define what its EPRs look like - I think moving ref-params from being used for identifications or routing purposes and into the realm of filtering an event stream is a poor design choice.  This mixing of concerns is bound to make for a much more complex and fragile system.  The WSA headers (and ref-params) are meant to address the event source and nothing more. As long as the event source's EPR is an opaque object then this mixing of concerns (while wrong, IMO) is not something we can stop since the Event Source is free to decide how its EPRs are made.  However, quoting your proposal:
The above use cases requires an event subscriber to provide some additional information, besides the
service location URI defined in the Event Source WSDL, to associate a subscription with the targeted
individual event source (a resource or a port type).
worries me because when you talk about an event subscriber "providing additional information" then it sounds like you want the subscriber to not just use the EPR provided to it by an Event Source, but rather you want it to modify the ref-params to add this 'additional information'.  At this point the EPR is no longer opaque and the subscriber must now understand the internal design choices that the Event Source made about how its EPRs are constructed.  This assumed shared knowledge is not something WS-Eventing (or other WS specs - like WS-Session) should promote.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
"Chou, Wu (Wu)" <wuchou@avaya.com>
Sent by: public-ws-resource-access-request@w3.org

02/03/2009 03:28 PM


To

<public-ws-resource-access@w3.org>

cc

Subject

WS-Eventing  Issue 6425 proposal










Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs Research | AVAYA | 233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax: 908-696-5198 / 908-696-5401 | wuchou@avaya.com<blocked::mailto:wuchou@avaya.com>
[attachment "wse_6425_2.pdf" deleted by Doug Davis/Raleigh/IBM]