Re: [wsdm] MEP Edits from todays Conference Call

["Ben Bloch" <ben_b54@hotmail.com>]

+1 on using WSRM for once-only delivery and possibly for at least once (i.e.
persistence is required) rather than rolling an WSDM one.  WSDM has enuf to
do already.

The big question for WSDM is what type of message delivery it should
proscribe for whatever MEP it supports, eg:
- once and only once (once only)
- at least once
- at most once
- best efforts

as well as how dups are handled.

A strong case can made that numerous modes need to be supported, eg:
- best efforts is sufficient for certain types of notifications such as a
threshold condition that doesn't go away and continues to fire notifications
- at least once is needed for such elements as performance data required for
historical analysis but dups are OK since data is just overridden
- once and only once may be needed for some actions, such as provisioning
another server. (Alternatively,  if not once and only once, then a provision
for dup detection and handling is required so that action is executed once
and only once even if message delivery is at least once.

Ben


----- Original Message ----- 
From: "Dan Foody" <dan@actional.com>
To: "John DeCarlo" <jdecarlo@mitre.org>; "Heather Kreger"
<kreger@us.ibm.com>
Cc: <wsdm@lists.oasis-open.org>
Sent: Wednesday, June 04, 2003 4:32 PM
Subject: RE: [wsdm] MEP Edits from todays Conference Call


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


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php