Re: WS-DD comments on WS-Eventing WD-ws-eventing-20090924

Toby/WSDD members,
  For point #1 we opened issue 8198 [1].  We'd like to better understand 
your concerns with the changes that have gone into WS-Eventing and how we 
might be able to address them. 

  First a bit of history/background..., as observed in your note the 
mechanism by which a Subscriber can determine the shape of the events, and 
the notifications that are sent, has changed from the member submission. 
In the member submission, there was a single portType that contained the 
Event Source's operations (e.g. Subscribe) as well as the definition of 
the outgoing Notifications as output-only operations.  As I'm sure 
everyone knows, the output-only operations were removed mainly due to our 
attempt to be WS-I Basic Profile compliant.  However, there are other 
factors that play into it.

  One of the first changes that we made in WS-Eventing was to define the 
notion of a Notification Format. This allows a Subscriber to ask the Event 
Source to format the Notifications in a particular way.  For example, one 
Format may ask for the Events to be transmitted in a 'raw' format, meaning 
pretty much untouched and each Event is simply copied into the SOAP Body 
of the Notification message.  While another format may ask for them to be 
'wrapped' with a well-defined/common element - thus allowing Event Sinks 
to have a single operation/receiver to process all Notifications.  With 
this ability, and extensibility point, a single Event Source might support 
sending out Events in a large number of different formats.  This means 
that even if we did allow the use of output-only operations, putting all 
of these into a single portType would be quite overwhelming - almost to 
the point of being useless unless there was a way for a Subscriber to know 
which operations/messages/notifications were actually of interest it. 
Thus, as you've noted, the Event Source's WSDL was separated from the 
description of the Events as well as the description of the Notification 
messages themselves.  Given the potentially large number of WSDLs 
available, it makes more sense to have people ask for the Notification 
WSDL based on the Format used within their particular Subscribe request. 
And, all of this is available through the use of WS-MetadataExchange with 
the Event Source.

  Now, to your note... it talks about the need to be able to associate the 
events produced by an event source with the event source's portType. 
However, I'd like to dig a little deeper into this by asking some 
questions:
1 - why does the description of the events need to be associated with the 
event source's portType?  Is there something special about the portType 
that is of interest to the WSDD community or is it simply because that's 
where the information was available before? 
2 - would it be sufficient for the same information to be available but 
just someplace else that's just as easy to examine?
3 - is it the shape of the events that's of interest or is it the shape of 
the notifications?  or both?   To be clear, events represent the raw data 
itself, while notifications represent the format/serialization of those 
events on the wire within a SOAP envelope.
4 - for what purpose is this "shape" needed?  For example, is it because 
the sink needs to know what kind of soap messages to expect, or is it so 
the Subscriber knows what kind of xpath expression to create for the 
filter?  Or for event process later on down stream long after the event 
has been extracted from the soap envelope?
5 - the topic of having access to this information at design time, rather 
than runtime, is mentioned - this implies that the use of WS-MEX to get 
the EventDescription data or Notification WSDL might not be an option. 
However, if the WSDL of the Event Source is available at design time how 
was this made available to the Subscriber?
6 - is there something special about the Event Source WSDL, or the 
mechanism by which it was made available, that would preclude other 
metadata from also being made available through this same mechanism?  For 
example, does this mechanism only allow a single document to be shared 
instead of multiple?

I'm trying to get a sense of the higher-level requirements that are trying 
to be addressed rather than focus on one particular solution.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8198

thanks
-Doug Davis
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Toby Nixon <Toby.Nixon@microsoft.com> 
Sent by: public-ws-resource-access-comments-request@w3.org
10/13/2009 01:07 PM

To
"public-ws-resource-access-comments@w3.org" 
<public-ws-resource-access-comments@w3.org>, Bob Freund 
<bob.freund@hitachisoftware.com>
cc
"ws-dd@lists.oasis-open.org" <ws-dd@lists.oasis-open.org>, Toby Nixon 
<Toby.Nixon@microsoft.com>, Lawrence Lamers <ljlamers@vmware.com>, Michael 
McIntosh/Watson/IBM@IBMUS, Chris Kaler <ckaler@microsoft.com>, "Anthony 
Nadalin" <tonynad@microsoft.com>, Mike Edwards <mike_edwards@uk.ibm.com>, 
Alain Regnier <alain@ussj.ricoh.com>, Xiao Chuan <cxiao@fudan.edu.cn>, 
"Gert Sylvest" <gert.sylvest@avanade.com>, Josh Cohen 
<joshco@microsoft.com>, Jonathan Marsh <jonathan@wso2.com>, Marc Goodner 
<mgoodner@microsoft.com>, Paul Fremantle <paul@wso2.com>, Mikkel Hippe 
Brun <mhb@itst.dk>
Subject
WS-DD comments on WS-Eventing WD-ws-eventing-20090924






Dear colleagues in W3C WS-RA WG:
 
The OASIS Web Services Discovery and Web Services Devices Profile (WS-DD) 
Technical Committee reviewed the draft WS-Eventing, WS-MetadataExchange, 
and WS-Transfer specifications as requested in your email on September 26 
(we did not review the other specifications because they are not 
referenced in DPWS). As a result of this review, we submit to you the 
following substantive comment and several minor editorial/clarification 
comments on WS-Eventing:
 
1.     A mechanism to relate the portType(s) of an event source Web 
Service to the abstract description of the events it can produce is 
needed. This mechanism cannot be solely based on WS-MetadataExchange, as 
this information may be needed by clients at design time, before any 
service endpoints are available. The draft replaces the previous mechanism 
for advertising events produced by a source, based on a portType extension 
(using both the wse:EventSource attribute and notification and 
solicit/response operations), by two new mechanisms, one introducing a new 
language (Event Descriptions), the second one using a WSDL definition for 
the sink. Both mechanisms provide an abstract description of the events, 
but no mechanisms to relate them to the portType of the event source. 
Rather, it is suggested to use new WS-Eventing dialects in conjunction 
with WS-MetadataExchange to retrieve the descriptions at runtime. 
 
2.     Minor comments / requests for clarification:
 
In Section 4.1 Subscribe, it would be helpful to clarify if there is any 
difference in behavior between a missing Filter element and a Filter 
element that is present but empty.
 
In Section 4.1 Subscribe, the description of wse:Filter says that the 
Event Source MUST generate a wse:EmptyFilter fault if it receives a 
Subscribe request with a filter that will never evaluate to true for the 
lifetime of the Subscription, but Section 6.11 EmptyFilter says that the 
fault MAY be sent. This should be made consistent. A similar inconsistency 
exists with the wse:UnusableEPR fault.
 
In Section 4.4 Unsubscribe, the text references faults defined for Renew, 
mentioning that they are also applicable to Unsubscribe. However, the only 
fault defined in Renew is wse:UnableToRenew, which does not seem 
applicable to Unsubscribe. 
 
In Section 4.4 Unsubscribe and Section 5 Notifications, the term 
"subscribing event sink" is used several times. Should these be replaced 
with the term "Subscriber" (defined in section 3.4 Terminology) to avoid 
confusion?
 
In Section 4.2 Renew and Section 4.4 Unsubscribe, the status of the 
subscription after the failure of either request could be clarified (e.g., 
that any existing subscription is unaffected).
 
In Section 5 Notifications: Uses of the XPath expression 
/s:Envelope/s:Body/wse:Subscribe/wse:NotifyTo/ should be replaced by 
/s:Envelope/s:Body/wse:Subscribe/wse:Delivery/wse:NotifyTo/ (in two 
instances).
 
Thank you very much for the opportunity to participate in the preview of 
the Last Call drafts.
 
Best regards,
 
Toby Nixon
Alain Regnier
Co-Chairs, OASIS WS-DD TC
 

From: Bob Freund [mailto:bob.freund@hitachisoftware.com]
Sent: Sat 9/26/2009 7:32 AM
To: public-ws-resource-access@w3.org; 
public-ws-resource-access-comments@w3.org
Cc: Toby Nixon; Lawrence Lamers; Michael McIntosh; Chris Kaler; Anthony 
Nadalin; Mike Edwards; Alain Regnier; Xiao Chuan; Gert Sylvest; Josh 
Cohen; Jonathan Marsh; Marc Goodner; Paul Fremantle; Mikkel Hippe Brun
Subject: To WS-RA reviewers
Dear WS-RA Reviewers,
The WS-RA working group has published new Working Drafts on 2009-09-24:

WS-Enumeration at http://www.w3.org/TR/2009/WD-ws-enumeration-20090924
WS-Eventing athttp://www.w3.org/TR/2009/WD-ws-eventing-20090924
WS-MetadataExchange at 
http://www.w3.org/TR/2009/WD-ws-metadata-exchange-20090924
WS-Transfer at http://www.w3.org/TR/2009/WD-ws-transfer-20090924

Please review these specifications and provide comment to 
public-ws-resource-access-comments@w3.org

The WS-RA Working group hopes to be able to transition these 
specification to Last Call status in the month of November 2009, so to 
make that work well, and to help prevent comments received after Last-
Call causing a return to that status, we are seeking your comments 
early and within the next three weeks (2009-10-12)
The working group will endeavor to resolve those comments received 
before Last Call publication.

There are still some issues being worked in parallel with your review 
as well as a few that have been resolved after the publication 
preparation date of the 2009-09-24 WDG which was 2009-09-02.  Those 
may be seen on our bug list at 
http://www.w3.org/Bugs/Public/buglist.cgi?product=WS-Resource%20Access

The following specification was also published, but we are not seeking 
review of it at this time
WS-ResourceTransfer at 
http://www.w3.org/TR/2009/WD-ws-resource-transfer-20090924

Thank you
Bob Freund
Chair W3C WS-RA Working Group