Points 2 and 3 do seem to fall under
Quality of Service (ws-ReliableMessaging?). Point 1 however would
extend the current WS-N functionality to cover "history" queries in
addition to "latest" queries (as it is now). History queries
are useful when one wants to do predictions for example. If this feature is
allowed we also need to be able to specify how far back in time (or how many
events) in a request. Another related issue is how long is an event kept in the
system.
Abdeslem
-----Original
Message-----
From: Steve Graham
[mailto:sggraham@us.ibm.com]
Sent: 30 July 2004 08:50
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