issue 6692 proposal

For issue 6692 I think we might be getting ourselves confused by trying to 
do too many things at once.  I'd like to back things up a bit and propose 
that WS-Eventing not give itself any special treatment.  By that I mean we 
don't define a _default_ delivery mechanism.  Technically the wse:NotifyTo 
element is just an extension - it should not be anything special.  It just 
happens to be defined by WS-Eventing for convenience.  By doing this we 
avoid the risk of giving certain extensions (ours) precedence over others 
and creating confusion.  So, if we don't give ourselves any special 
treatment, then wse:Delivery could be reduced to something like this:

[Body]/wse:Subscribe/wse:Delivery 
This element contains the information necessary to convey notification 
messages from the event source to the event sink in a manner required by 
the subscriber. This element MUST contain at least one child element.

I added the MUST since w/o any children we have no idea what to do with 
Notifications. Clearly, we do need to provide at least one basic delivery 
mechanism, so we could then add this:

[Body]/wse:Subscribe/wse:Delivery/wse:NotifyTo
This specification defines one extension element, wse:NotifyTo, that MAY 
be used by a subscriber as a child of the wse:Delivery element.  When 
present this element indicates that notifications MUST be asynchronously 
sent to the EndpointReference identified by this element.

So, what does this buy us?
Well, let's say someone defines a <frog/> delivery extension and it 
requires the wse:NotifyTo element.  They would then need to define, in the 
ws-frog spec, the <frog/> element and say that wse:NotifyTo MUST also be 
present.  We've now forced people who write extensions to very clearly say 
what their prereqs are.  With the current proposal it wasn't clear if 
<frog/> could assume that wse:NotifyTo would always be present.

Now, let's say someone defined a <broadcast/> extension that didn't need 
wse:NotifyTo.  In the ws-broadcast spec it wouldn't even mention 
wse:NotifyTo - nor should it.

And, let's say someone defined a <trashIt/> extension that meant all 
Notifications should be trashed (like using a wsa:None wse:NotifyTo EPR). 
Again, no need for ws-trash to even mention wse:NotifyTo.

Finally, let's say someone defined a <ack/> extension that meant a 
response must be sent back to the event source for each notification. This 
extension, like <frog/>, would need to do one of two things.  It would 
either need to mandate the use of wse:NotifyTo or it would to define its 
own EPR - their choice.  Either way , its very clear what's expected.

The point of all this is that we force people to very clearly define their 
extensions and what their prereqs are.  Having a "default" delivery 
element means we need to explain when/how/if it interacts with extensions 
- and its not even clear when extensions can assume its present.  The 
above would remove this ambiguity and force a cleaner design.

Now, the other question that we seemed to get hung up on is what to do 
with conflicting extensions.  We need to assume that all of the above 
extensions were written without knowledge of each other (including 
wse:NotifyTo).  So, on the call today we talked about what an event source 
would do if it were given something like this  (assume all extensions are 
understood):

<wse:Delivery>
  <wse:NotifyTo/>
  <trashIt/>
</wse:Delivery>

Well, the answer would be the same as if this were sent in:
<wse:Delivery>
  <broadcast/>
  <trashIt/>
</wse:Delivery>

In other words, the event source would need to be written to handle both 
of these cases. And, IMO, it should deal with both cases in the exact same 
way.  It would need to detect that in both cases the two extension 
elements created a problem and a fault should be thrown.  The fact that in 
the first example we're conflicting with a ws-eventing defined extensions 
isn't really relevant - nor should it be since "our" extensions aren't any 
more special than any one else's. 

Now let's change it up a bit and say someone defined a real add-on 
extension- one that could be used with other extensions - like Gil's 
<pauseable/> example.  This one wouldn't need to mention wse:NotifyTo or 
any other extension - it just talks about queuing up Notifications. 

Now, what if someone sent in this:
<wse:Delivery>
  <pauseable/>
</wse:Delivery>

Again, the event source would need to detect that something is missing - 
some extension that said what to do with the notifications.  This is 
really no different from the above two cases.

ps. I don't think this has any impact on Wu's issue/proposal of using 
ws-policy.  Whether we choose to adopt that option is orthogonal to this.

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.