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  |  

The more I'm around some people, the more I like my dog.

Toby Nixon <>

Sent by: 

10/13/2009 01:07 PM

To

""
<>, Bob Freund <>

cc

""
<>, Toby Nixon <>,
Lawrence Lamers <>, Michael McIntosh/Watson/IBM@IBMUS,
Chris Kaler <>, "Anthony Nadalin" <>,
Mike Edwards <>, Alain Regnier <>,
Xiao Chuan <>, "Gert Sylvest" <>,
Josh Cohen <>, Jonathan Marsh <>,
Marc Goodner <>, Paul Fremantle <>,
Mikkel Hippe Brun <>

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

Sent: Sat 9/26/2009 7:32 AM

To: ; 

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 

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