RE: [wsn] Issue: define queue in WSN

["David A. Chappell" <chappell@sonicsoftware.com>]

That may be where we end up, but I don't want to leave it too open for interpretation.  As I have been pointing out in the f2f, if you are going to have a specification about messaging-related concepts, it should at least contain the things that people who use messaging would expect to see...even if in the case of point 3a) it might be stating the obvious.  I think policy assertions or WSDL definitions are a good thing, but we should define some minimal behaviour in the spec that help the policy-maker describe the decisions to be made.

Dave

---

From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: Friday, July 30, 2004 3:50 AM
To: Anish Karmarkar
Cc: David A. Chappell; Lily Liu; wsn@lists.oasis-open.org
Subject: Re: [wsn] Issue: define queue in WSN

This is an  interesting discussion.
Just a thought here, these sound like policy assertions on the Quality of Service of the subscription and related notifications.  Is the way we express this work going to look like policy assertions or WSDL-based message exchange defintions?

sgg

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

Anish Karmarkar <Anish.Karmarkar@oracle.com> 07/29/2004 01:39 PM

To:        "David A. Chappell" <chappell@sonicsoftware.com>         cc:        Lily Liu <lily.liu@webmethods.com>, wsn@lists.oasis-open.org         Subject:        Re: [wsn] Issue: define queue in WSN

David A. Chappell wrote:

> Agreed.  Here are some things that Sonic has been thinking about
> regarding the semantics of queuing -
>  
> 1) When a subscriber subscribes, should  it expect to receive messages
> that were published before the subscription took place?  If queuing
> semantics were being used underneath the subscription model, then there
> could be messages queued up that are waiting to be consumed (waiting for
> hours, days, weeks).
>  
> 2) In JMS there is a notion of a durable subscription, where a
> subscriber can go offline and have messages queued for it on its behalf
> while it is unavailable.  Should  we have something comparable in WS-N?
>  
> 3) exactly-once delivery is a generally accepted trait of queues.  A
> common implementation pattern is load-balanced queue receivers, where
> multiple receivers listen on the same queue, yet only one of them will
> receive each individual message.  If I were to overlay WS-N pub/sub
> topics onto queues in this situation, that would imply a consumption
> pattern where multiple consumers can subscribe to a given 'Topic', yet
> only one would recieve each message.
>  
> 3a) That being said: Even in the current draft spec we don't explicity
> say that in the pub/sub model, all active subscribers are expected to
> receive a copy of the same message.

I think this is a good point regardless of whether we support queues or
not. We need to say exactly what the model is.

> Dave
>
>     ------------------------------------------------------------------------
>     *From:* Lily Liu [mailto:lily.liu@webmethods.com]
>     *Sent:* Thursday, July 29, 2004 8:05 AM
>     *To:* wsn@lists.oasis-open.org
>     *Subject:* [wsn] Issue: define queue in WSN
>
>     WSN should address basic messaging queuing concepts.
>      
>     Lily