RE: [wsdm] MEP Edits from todays Conference Call

["Dan Foody" <dan@actional.com>]

When using http with SOAP one-way messages, the HTTP 200 OK response
serves as an a "I received it" notification.  If the sender gets HTTP
200 OK, the sender can assume that the message was correctly received.
Otherwise (if a different outcome than 200 OK), the sender needs to
resend it (unless it's a persistent failure).  This behavior gives you a
guarantee of at-least-once delivery.

My question about [FR003.3] (Must support guaranteed notifications) is
whether the intent is guarantee of once-only delivery or at-least once
delivery?

To support once-only delivery semantics, we would need to require
something like WS-ReliableMessaging (rather than trying to layer our own
once-only semantics on top of standard at-least-once delivery).

Cheers.

--
Daniel M. Foody
CTO, Actional Corporation
701 N. Shoreline Blvd. 
Mountain View, CA  94043 

http://www.actional.com


> -----Original Message-----
> From: John DeCarlo [mailto:jdecarlo@mitre.org] 
> Sent: Wednesday, June 04, 2003 12:39 PM
> To: Heather Kreger
> Cc: wsdm@lists.oasis-open.org
> Subject: Re: [wsdm] MEP Edits from todays Conference Call
> 
> 
> Hello,
> 
> I also have another quibble that I didn't want to get into on 
> the call. 
>   I don't know if anyone else considers this important or not.
> 
> By at least one definition, a notification is an unsolicited message 
> (typically from managed resource to manager).
> 
> While we often assume notifications are asynchronous (such as an SNMP 
> Trap), it isn't necessarily so.  Other related discussions talk about 
> using request-response approach, but simply having an "I received it" 
> response automatically sent.  This would work for 
> notifications as well.
> 
> In fact, one could argue that if you want FR003.3, guaranteed 
> delivery 
> of notifications, that having an "I received it" response from the 
> receiver would be beneficial.
> 
> In summary, I present the case that we need not link 
> Notifications being 
>   originated from the managed resource with asynchronous messaging.
> 
> Thanks.
> 
> Heather Kreger wrote:
> 
> > [FR003]  MUST support delivery of notifications from manageable 
> > resources to manager. (Source: IBM, HP, MPTC)
> > 
> > 
> > 
> > 
> >       [FR003.1] The notification receiver SHOULD be able to control 
> > what notifications are sent to it. (filtering and/or 
> subscription at 
> > managed resource side) (Source: HP)
> >       [FR003.2] The notification receiver SHOULD be able to 
> indicate 
> > whether it wants to receive notifications asynchronously as 
> and when 
> > they happen or poll them periodically. (Source: HP) {#90}
> >             [FR003.2C] SHOULD support asynchronous delivery of 
> > notifications
> >             [FR003.2.D] MUST support synchronous polling 
> for notifications
> >             [FR003.2.E] The managed resource MUST be able 
> to indicate 
> > if it supports asynch or polling notifications mechanisms.
> >       [FR003.3] Must support guaranteed notifications. {#90} (and 
> > advertise its support)
> >       [FR003.4] Must support ordering of notifications from 
> a managed 
> > resource's perspective. {#90}
> >       [FR003.4] Support synchronous as well as asynchronous. {#142}
> > <Delete: Dup of 3.2>
> 
> -- 
> 
> John DeCarlo, The MITRE Corporation, My Views Are My Own
> email:      jdecarlo@mitre.org
> voice:      703-883-7116
> fax:        703-883-3383
> DISA cube:  703-882-0593
> 
> 
> 
> You may leave a Technical Committee at any time by visiting 
http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgrou
p.php