This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: "Michael A. Nachbaur" <mike@nachbaur.com>
From: Nathan Torkington <gnat@frii.com>
Subject: Re: [OT] JMS-like event framework for Perl
Date: Sun, 11 Mar 2001 08:35:51 +1300
"Michael A. Nachbaur" wrote:
>
> Since today seems to be "The Day of the Off Topic(tm)", I thought I'd jump
> in with my question.
>
> Is there a event messaging framework available for Perl, similar to JMS?
> I'd like to be able to have an object registered as a handler for certain
> "events", and have perl code throw those events causing the object to be run
> automatically (publish / subscribe model).
I think there's an Event.pm, but you're probably after something like POE:
http://www.perl.com/pub/2001/01/poe.html <- intro and tutorial
http://poe.perl.org/ <- homepage (down?)
http://poe.dyndns.org/ <- Rocco's dialin machine
===
To: jeff saenz <jeff@planetoid.net>
From: Nathan Torkington <gnat@frii.com>
Subject: Re: [OT] JMS-like event framework for Perl
Date: Sun, 11 Mar 2001 09:25:59 +1300
jeff saenz wrote:
> Might be possible that soap is addressing messaging issues.
> > > Is there a event messaging framework available for Perl, similar to JMS?
> > > I'd like to be able to have an object registered as a handler for certain
> > > "events", and have perl code throw those events causing the object to be
> > > run automatically (publish / subscribe model).
You're right, SOAP::Lite can do these things (and more). I was hallucinating,
thinking that you wanted to write a program in an event-driven style.
http://www.soaplite.com/
http://guide.soaplite.com/
===
To: Modperl Mailing List <modperl@apache.org>
From: Gunther Birznieks <gunther@extropia.com>
Subject: Re: [OT] JMS-like event framework for Perl
Date: Sun, 11 Mar 2001 15:24:30 +0800
Although SOAP::Lite interfaces with SMTP and POP3, I don't know if
SOAP::Lite really qualifies to be in the same class as products like JMS,
Neon, or Microsoft MSMQ.
However, I think the description of what the author is interested in is a
bit vague. The words seem to indicate that he would be satisfied by setting
up a SOAP service on an HTTP server that listens to calls made to it (the
events) and then runs.
This is a simpler model and does not really describe publish/subscribe as
being a feature he wants. That is, to me, IMHO ...
Publish/subscribe entails a lot of headaches about allowing multiple
subscribers (consumers of data), maintaining the integrity of those
messages, and making sure that all subscribers have a fair chance to get
them. In larger environments the idea behind messaging is that you
sacrifice speed for reliability of having a central queueing mechanism that
may or may not be backed up by a persistent storage and that can notify
clients that are subscribed in sort-of real time that a new message exists
on the queue (without having to poll).
And it doesn't sound like this user needs that. Also has not made clear
what the relationship is between the event-driven objects. If the client is
always requesting from the server or if the server needs to "call back" to
the client to notify the client that something has occured. The former is
obvious and easy with SOAP while the later is somewhat less trivial.
POE seems more interesting, but is also not precisely publish/subscribe. It
seems a bit more generic than that. Again, not quite the same as JMS, but
something like it could be built from POE it seems.
The thing that would be interesting to me is a more detailed description of
what is needed. What features of JMS specifically are interesting to the
original poster. Perhaps a project written on top of SOAP::Lite or POE
would be in order. Or perhaps maybe the problem is just simpler than it's
made out to be by asking for JMS features.
===
To: modperl@apache.org
From: Paul Kulchenko <paulclinger@yahoo.com>
Subject: Re: [OT] JMS-like event framework for Perl
Date: Sun, 11 Mar 2001 09:35:33 -0800 (PST)
Hi, Gunther!
>Although SOAP::Lite interfaces with SMTP and POP3, I don't know if
>SOAP::Lite really qualifies to be in the same class as products like
>JMS, Neon, or Microsoft MSMQ.
I think not or at least not yet :).
>However, I think the description of what the author is interested in
>is a bit vague. The words seem to indicate that he would be
>satisfied by setting up a SOAP service on an HTTP server that
>listens to calls made to it (the events) and then runs.
>This is a simpler model and does not really describe
>publish/subscribe as being a feature he wants.
Agree. It can be built as simple SOAP call against your server.
Though I'm finding many similarities between publish/subscribe and
async messaging they share common problem in this aspect: client has
to tell server where to run callback or response in async model. You
don't need it if you have static environment (when you're responsible
for client and server and client has fixed endpoint), but that's not
interesting case for us.
What can be done in my understanding (and I'm working on it), we can
pass either URL for service description that is able to handle
callback, or even fragment that describes it.
----------------------------------------------------------
Notification service.
Author creates the resource (something that can be pointed by URL and
may be interesting for others) and registers it:
manageResource(URL, {name, description})
System responds with status of the request: registered or not.
Registration may fail if URL is already registered or system decided
you may not register such URL (it