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 

- 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
events occurs after any filtering. This ensures that regardless of what 
type of formatting might occur, the same Filter dialect/expression can
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
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
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
source for the WSDL that sinks need to support.  While Gil's proposal
that a mechanism needs to be defined so that sinks can generate the 
appropriate WSDL, there are clearly some people who really really want
source to provide it to the sink.

- we need a clear mechanism by which the sink can know exactly which
file to use based on the FormatURI used.  Wu's proposal (
) 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
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
1 - an event source SHOULD expose EventDescriptions retrievable thru:
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
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.


Received on Tuesday, 4 August 2009 13:42:47 UTC