Message queue

[Ruka]

Hi All,
I'm interested in pshb to be used as a message queue system. Still I'm
not sure if this use case is possible. Basically the system I need is
a kind of command router - modules which are command servers subscribe
to a message type (which is in pshb terminology topic or a feed). A
module which initiates a command would be a publisher of a certain
message type. As you can see, multiple modules can be publishers of
the same message type/topic which is not exactly what pshb is made
for? Also in this scenario subscriber comes first, not publisher - so
it might be reversed used case to standard publish/subscribe?

So my question is if Pubsubhubbub would be a good platform for this
system? I know about Advanced Message Queuing Protocol which might be
exactly what I need, but it's seems to heavy and I really like
Pubsubhubbub simplicity and http/rest orientation.

Thanks,
Milan

[Alexis Richardson]

Milan

Hi, Alexis here from RabbitMQ.

One way to look at 'push messaging' technologies is to think about
four different parts:

- messages
- pubsub
- queues (and 'hubs')
- storage

PSHB defines a model for the first two but is somewhat silent on the
latter two. This will make it difficult to use PSHB for what you want
('queues') unless you write some custom code, thereby killing any
benefit you may get from 'simplicity'.

Let's take a closer look:

On Sat, Feb 6, 2010 at 9:37 AM, Ruka <rukavi...@gmail.com> wrote:
> Hi All,
> I'm interested in pshb to be used as a message queue system. Still I'm
> not sure if this use case is possible. Basically the system I need is
> a kind of command router - modules which are command servers subscribe
> to a message type (which is in pshb terminology topic or a feed).

PSHB has a routing model based on *subscriptions* to *topics*.
Currently topics are publisher-defined URLs for Atom feeds.

(*) Publication occurs by posting content (somewhere) and updating the
Atom feed. At some point, when content is added to a feed, the hub is
notified by the publisher that this has occurred.

> A
> module which initiates a command would be a publisher of a certain
> message type. As you can see, multiple modules can be publishers of
> the same message type/topic which is not exactly what pshb is made
> for?

Currently, only if all modules can do (*) above.

In effect, the feed would then be the queue. The hub would simply
cache copies of that queue for subscribers, who would 'share' this
queue and (potentially) consume all messages on it.

I don't think that is what your use case requires. Am I right?

I *think* what you want is a way for publishers to publish messages
directly to a shared queue (called 'topic') on a hub, from where the
messages can be round-robined to subscribers. Doing this with PSHB
would be quite a contortion right now.

> Also in this scenario subscriber comes first, not publisher - so
> it might be reversed used case to standard publish/subscribe?
>
> So my question is if Pubsubhubbub would be a good platform for this
> system? I know about Advanced Message Queuing Protocol which might be
> exactly what I need, but it's seems to heavy and I really like
> Pubsubhubbub simplicity and http/rest orientation.

I think AMQP gives you exactly what you need. If you want
Pubsubhubbub or HTTP/REST for a 'simpler' interface style, then look
at:

- RabbitHub
- RestMS
- or one of the RabbitMQ HTTP interfaces

Separately, you may find XMPP gives you the functionality you want.

alexis

[todd hoff]

> Hi, Alexis here from RabbitMQ.
>
> One way to look at 'push messaging' technologies is to think about
> four different parts:
>
> - messages
> - pubsub
> - queues (and 'hubs')
> - storage
>
> PSHB defines a model for the first two but is somewhat silent on the
> latter two.  This will make it difficult to use PSHB for what you want
> ('queues') unless you write some custom code, thereby killing any
> benefit you may get from 'simplicity'.
>
> Let's take a closer look:
>

A nice summary of the differences between a queue and Pubsubhubbub
style event distribution, thanks. It brings up some things I've been
working on really want a queue. Pubsubhubbub seems most useful in the
lossy append style event scenario. If you are trying to work with
actors that implement state machines it doesn't really work. To make
it work, especially with a push model, events have to put on another
queue as they come in, which seems a little redundant. Other products
exist, like your fine program, but the prospect of large market place
of hubs is very attractive.

[Alexis Richardson]

On Mon, Feb 15, 2010 at 5:42 PM, todd hoff <toddho...@gmail.com> wrote:
>
> A nice summary of the differences between a queue and Pubsubhubbub
> style event distribution, thanks. It brings up some things I've been
> working on really want a queue. Pubsubhubbub seems most useful in the
> lossy append style event scenario. If you are trying to work with
> actors that implement state machines it doesn't really work. To make
> it work, especially with a push model, events have to put on another
> queue as they come in, which seems a little redundant. Other products
> exist, like your fine program, but the prospect of large market place
> of hubs is very attractive.

Thanks Todd.

I think one of the main attractions of PSHB is that it sidesteps
almost all questions of state management. It would be good to be able
to 'plug in' different kinds of state managing actors, either in the
middle points, or at the endpoints. Working out just what is and
isn't doable here, is kind of a head spinning activity ...!

alexis