RE: Re: issue 6401 - an outline of a proposal

+1
Few points in addition to Li's comments.

FormatURI can be addressed in NotificationWSDL by extending the binding
policy parameter as follows:

"<out:Binding name="BindingName (xs:qname)" FormatURI= "URI"? >
  Notification_WSDL_URI (xs:anyURI)
</out:Binding>
The default value of FormatURI attribute is the implied raw format
delivery of WS-Eventing as defined in Section 4."

I am also thinking to add the following single part text for
Notification WSDL to support efficient event filtering.

"In order to support efficient event filtering, wsdl:message in the
notification WSDL MUST have only one part."

The mex based method to get meta data should be an option, especially
for notification wsdl based approach, it supports regular web service
discovery mechanism through publication of event source wsdl (e.g. UDDI,
etc.) without requiring other additional mechanism.

Many thanks,

- Wu Chou

-----Original Message-----
From: Li, Li (Li) 
Sent: Tuesday, August 04, 2009 9:41 AM
To: public-ws-resource-access@w3.org
Cc: Chou, Wu (Wu); Doug Davis
Subject: Re: issue 6401 - an outline of a proposal

LL: All my comments are inserted after this marker "LL" without blank
line between paragraphs.

In thinking about the two proposals for 6401 I've come to the following
conclusions:

- we need some kind of Notification Data in order to allow for filtering
to be done independent of the format URI used.  This is needed to align
with what's in the spec:
When the Delivery Format feature is engaged the formatting of the
outgoing events occurs after any filtering. This ensures that regardless
of what type of formatting might occur, the same Filter
dialect/expression can be used to subset the event stream. 
Otherwise the filter expression would change as the FormatURI changes.

LL: I agree. 

- we need some kind of Notification Data in order to allow extra data to
be associated with events regardless of whether that data is transmitted
over the wire.  For example, topics might need to be associated with
events even though a Subscriber chooses a FormatURI that doesn't
serialize them on the wire.  Wu's proposal only allows for filtering of
data that appears in WSDL/on-the-wire.  Although, its not clear to me
how you can filter over info that appears as a soap header when the
filtering is done before serialization (see above) - its a catch-22
situation.

LL: I don't think Wu's proposal only allows for filtering of data
defined in WSDL, as WSDL itself is extensible. The two proposals all
agree the filtering applies to the raw event documents. The difference
is that how that raw event documents is represented. In Wu's proposal,
they are represented as WSDL whereas in Gil's approach, they are
represented by a newly invented XML dialect. 
Given that difference, there is no rule against anybody to attach event
metadata, say topic, to the WSDL, using the built-in WSDL extension
mechanism, to support filtering on information besides on-the-wire event
documents. By staying within WSDL architecture, I think the event
sources would have a much easier life to extend the functionalities by
leveraging many specs/standards already defined for WSDL.
As for filtering on soap header, the root cause is multi-part messages,
which is not necessarily dependent on SOAP per se. This is something we
can discuss and we believe it can be resolved within the framework of
WSDL as well (as that's how BP does its business and 6401 is really
trying hard to be BP compliant). 

- we need some kind of mechanism by which a client (the sink) can ask
the source for the WSDL that sinks need to support.  While Gil's
proposal says that a mechanism needs to be defined so that sinks can
generate the appropriate WSDL, there are clearly some people who really
really want the source to provide it to the sink.

- we need a clear mechanism by which the sink can know exactly which
WSDL file to use based on the FormatURI used.  Wu's proposal (
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/00
12.html
) shows the problem. Which of those policy refs go with which FormatURI?
In thinking about this problem I came to the realization that there is a
1-1 relationship between the FormatURI and the sink's WSDL - so let's
take advantage of this.

LL: This is a good question and I think your analysis also suggests a
solution within Wu's proposal. Since there is a 1-1 mapping between
Format URI and the sink's WSDL (called notification WSDL in Wu's
proposal), we could extend the policy assertions in Wu's proposal to
include the format URIs. Without going into syntax details, I think this
approach would allow 1) event sources to publish the supported formats
in the event source WSDL as policy; and 2) the subscribers to find out
which notification WSDL defines which format by inspecting the policy.


I'd like to propose that we solve this by doing both.  So, my proposal
is
this:
1 - an event source SHOULD expose EventDescriptions retrievable thru:
    mex.getMetadata(dialect=".../EventDescriptions");
2 - an event source SHOULD expose the expected event sink WSDL for a
particular FormatURI retrievable thru:
    mex.getMetadata(dialect=".../NotificationWSDL", id=FormatURI);

This allows for examination of the eventing information in a form that
isn't FormatURI specific, or even specific to which bits of data appear
on the wire.  But, it still supports the case of having the source
provide the WSDL that the sink is meant to implement.  Both are optional
and neither is favored over the other.

LL: This is an interesting proposal and we should consider it. Thanks.

Li

Received on Tuesday, 4 August 2009 15:27:03 UTC