I'm seeing some applications where it appears that there would be
value in introducing asynchronous messaging, ala "message queueing."

The "granddaddy" of message queuing systems is IBM's MQ-Series, and I
don't see particular value in replicating its functionality.

On the other side, the "big names" these days are:

a) The Java Messaging Service, which seems to implement *way* more
   options than I'm even vaguely interested in having (notably, lots
   that involve data stores or lack thereof that I do not care to use);

   <http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol> which
   again is a big, complex, protocol-oriented thing that seems mighty big
   and complex;

c) There are lesser names, like isectd <http://isectd.sf.net> and the
(infamous?) Spread Toolkit which both implement memory-based messaging

There's a simple + free system called MQS that is implemented in Perl
and uses XML-RPC; <http://www.foo.be/mqs/> that seems perhaps a little
*too* primitive.

FYI, here's its simple schema (filtered into PG):

create table mqname (
  name varchar (255) not null default '',
  id serial,
  priority integer not null default 10,
  primary key (id));

create table message (
  id serial,
  timestamp timestamptz NOT NULL
  cid varchar(255),
  queue integer not null references mqname(id),
  body text not null,
  priority integer not null default 10,
  flag integer default 0,
  primary key(id)

My bias would be to have something that can basically run as a thin
set of stored procedures atop PostgreSQL :-).  It would be trivial to
extend that to support SOAP/XML-RPC, if desired.

It would be nice to achieve 'higher availability' by having queues
where you might replicate the contents (probably using the MQ system
itself ;-)) to other servers.

There tend to be varying semantics out there:

- Some queues may represent "subscriptions" where a whole bunch of
  listeners want to get all the messages;

- Sometimes you have the semantics where:
  - messages need to be delivered at least once
  - messages need to be delivered no more than once
  - messages need to be delivered exactly once

Is there any existing work out there on this?  Or should I maybe be
looking at prototyping something?
(format nil "[EMAIL PROTECTED]" "cbbrowne" "linuxfinances.info")
Q: How many Newtons does it take to change a light bulb?
A: Faux!  There to eat lemons, axe gravy soup!

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to