Re: issue 6692 proposal

+1 This makes a lot of sense. I particularly like how it clarifies those 
situations that don't require wse:NotifyTo.

- gp

On 7/7/2009 6:12 PM, Doug Davis wrote:
>
> 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.