Re: MetadataSection in WS-Eventing - Issue 10376

Stephan Poehlsen <poehlsen@itm.uni-luebeck.de> wrote on 08/19/2010 
05:28:11 AM:
> Hello,
> 
> On 2010-08-18 Gilbert Pilz wrote:
> >   Doug,
> >
> > Your changes look good. The whole "disambiguate the Notification WSDL
> > from other WSDL docs" problem is just another strike against
> > Notification WSDLs as far as I am concerned . . .
> 
> As an outsider (since I am not in the RA-WG) in the first place I did 
> not see the reasons why you specify two solutions: Notification WSDLs 
> and EventDescriptions. In addition, for me it is not clear why a wrapped 

> and an unwrapped notification exist. These redundancies increase the 
> complexity for interoperable implementations only, don't they?
>
>  From the phrase "is just another strike against Notification WSDLs" I 
> can assume that there exists a longer discussion. Can you point me to 
> any results of that? I am interested in it, because I am currently 
> considering how to provide metadata about SOAP-over-UDP multicast 
"events".

As you said, there's a lot of history behind this and I'll try to give my
version of it.  There are basically two different views of how event sinks
will want to process/see incoming events:

1 - the event will be the child of the SOAP Body element.  This is the
unwrapped model.  In this particular model the event sink will either
have an operation defined for each event - which means as new
events are added a new operation will need to be added - or it will
have a single operation catch for all events. If there are other SOAP 
messages
(non-events) that can be processed that single catcher will need to have 
some mechanism to know how to distinguish event from non-event soap 
messages.

Either way the point is that some people just want the raw event and do 
not
need or want the event to be wrapped in something else. Likewise, they're
ok with a variety of wsa:Action values and will know the complete set of
event action URIs.

2 - the SOAP Body element has a well defined child element (the wrapper) 
and
a single (well defined) wsa:Action value.  As hinted to above, this makes 
it
possible for someone to have a single catcher for all events regardless of 

their shape.  For some people this is just easier to process.  Its also 
handy
for logging service that don't process the events, rather they just save 
them
for someone else to process later.  In this model the sink doesn't need to
know anything about the events, or when a new one is created, it just 
blindly
take the child of the wrapper element as the event.

Personally, I can understand the need for both.

As for the EVD vs NotifWSDL discussion... its very related to the above.
If all you care about is the raw event (and this could actually apply to 
both
wrapped and unwrapped) then the EVD data is more meaningful.  For example, 
when
you go to construct your XPath filter expression, I think using the EVD 
data for
this is easier than NotifWSDL.

However, if your event sink is designed such that you really need to know 
the 
WSDL of the event messages (perhaps so that you can run it through some
WSDL2Java tooling) then the NotifWSDL becomes necessary.  Technically, the
NotifWSDL can be derived from the EVD data (and there's a mapping section 
that
describes how to do this), but it was decided that rather than requiring 
all
sinks that need this info to do it themselves, if the Event Source has it 
available
then it should offer it up.

Its worth noting that the EVD data is required when dealing with wrapped
notifications.  In this case the NotifWSDL will just contain a high-level
description of the messages - meaning the action and wrapper element.  The 

xsd of the events themselves can't appear - so in order for the sink to 
know
the shape of the events (for processing or for specifying the filter 
expression)
it needs to grab the EVD data.

I view the EVD data as the original source of the event xsd and the 
NotifWSDL
as a by-product of that information, something that might be made 
available out of
convenience but not as authoritative as the EVD data.  But I know that 
others
have almost the exact opposite view because they would prefer to deal with 
the
WSDL and not a new data type. 

Hope this helps.  I'm sure others will chime in as there are many 
different views.

BTW - does the resolution for this issue satisfy your concerns? 

-Doug