Re: MetadataSection in WS-Eventing - Issue 10376

I actually think we're in agreement.  However, I'm not as eager to pick on 
poor old wrapped format  :-)
To me wrapped is just one example of how the Format stuff might be used. I 
can envision a case where someone defines a Format that looks exactly like 
'unwrapped' but includes the notion of putting extra metadata into a soap 
header.  Or another format that modifies the raw event data in some way - 
still unwrapped but tweaked from a normal raw/unwrapped mode.  To me the 
Format stuff is just a mechanism for the subscriber to specify the 
serialization mechanism to be used and that mechanism can be simple or 
very complex - don't forget about a batched format idea.  But in the end 
people will still need to know what the raw events look like (if for 
nothing else to specify the filter) - so evd stuff is needed.

Either way, I think we're also in agreement that the NotifWSDL is a 
by-product of the EVD stuff - dare I say redundant.  :-)    I'm waiting 
for Wu to correct me on this one.

thanks
-Doug
______________________________________________________
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.



Gilbert Pilz <gilbert.pilz@oracle.com> 
08/19/2010 04:56 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
Stephan Poehlsen <poehlsen@itm.uni-luebeck.de>, 
public-ws-resource-access@w3.org
Subject
Re: MetadataSection in WS-Eventing - Issue 10376






I agree with Doug's characterization of the wrapped/un-wrapped dichotomy, 
but I disagree somewhat with his explanation of the EVD/Notification WSDL 
axis.

>From where I sit, the need for EVD's is a direct result of the decision to 
support wrapped notifications. The effects of this decision are compounded 
by the ability to select wrapped or unwrapped notifications at 
subscribe-time (via the wse:Subscribe/wse:Format element). These decisions 
mandate a means to describe the structure and contents of the event data 
in a manner that is independent of the wrapped/unwrapped nature of the 
notifications. Notification WSDLs can't do that. This is why, if a 
Notification WSDL is present in a wse:EventSource assertion, it must 
appear as a child of the wse:FormatName element to which it applies.

The effects of supporting wrapped notifications pop up in other places. 
For example, suppose I want to subscribe to a subset of events from an 
Event Source that only produces wrapped notifications. I know I'm going to 
want to construct a filter to select the events I want, but if all I have 
is a copy of the wrapped Notification WSDL (
http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#wrappedWSDL), I 
don't have any information with which to structure my filter; I don't have 
any details about what the events look like.

I could go on, but you get the gist . . .

~ gp

On 8/19/2010 5:50 AM, Doug Davis wrote: 

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