OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-dd message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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

-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

"public-ws-resource-access-comments@w3.org" <public-ws-resource-access-comments@w3.org>, Bob Freund <bob.freund@hitachisoftware.com>
"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>
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

From: Bob Freund [mailto:bob.freund@hitachisoftware.com]
Sat 9/26/2009 7:32 AM
public-ws-resource-access@w3.org; public-ws-resource-access-comments@w3.org
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
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
WS-Eventing athttp://www.w3.org/TR/2009/WD-ws-eventing-20090924
WS-MetadataExchange at
WS-Transfer at

Please review these specifications and provide comment to

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

The following specification was also published, but we are not seeking
review of it at this time
WS-ResourceTransfer at

Thank you
Bob Freund
Chair W3C WS-RA Working Group

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]