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’s not on your IP address) or for
any other reason.
User would like to know about any changes for specified resource. She
sends request and asks register her for this resource and send
notification if something changes:
manageNotification(URL, {notification} [, granularity])
Notification specifies how user would like to be notified (HTTP,
SMTP, etc), in which format and granularity specifies for which event
(resource updated, dropped, etc.). Notification registration may
succeed or fail for reasons similar to resource registration.
Author modifies the resource and would like to notify everybody who
is registered about update:
manageUpdate(URL, message)
It will register update with specified message for particular
resource and notify everybody who is subscribed for this resource.
User can be notified in two modes: active and passive. Active mode
supposes you have something that is able to accept notification, like
http server (for HTTP or SOAP requests) or mail account (for SMTP
requests), and passive notification will be stored on server and you
can come later and read notifications you’ve got (source, message and
time). You can combine these approaches: subscribe in active mode for
something you’re urgent to know about and in passive mode for
everything else.
----------------------------------------------------------
Notification is simpler because server knows exactly what parameters
he wants to pass. For example, I'd like to manage Meerkats checks
against my web site (for some sites one hour can be too often and for
others it can be to rare) and to achive that, I need to register URL
of my site with notification server (as author), Meerkat needs to
register (as User of this resource) and then I just need to send
updates to notification server and it will take care about the rest
and will notify eveybody who is subscribed for this service. Almost
nothing has to be changed on Meerkat's side, and other users can
register for the same service, like search engines, catalogs or
anybody else (like you and me).
Asynchronous messages are little bit different (actually it's not
neccessarily should be SMTP against POP3, it could be HTTP only, but
process on server side could take significant amount of time): A
calls B, then B calls A. Two problems: A should let B know how to
call it and pass something that will let Alater identify that this is
response for particular request, like messageID.
This model can definitely be built on top of SOAP (I hope to have
demonstration soon), but it'll require design changes in toolkit on
client side. I'd like to stay with 'collection' interface, when:
A collection server
--request-->
add MID --request-->
accept request with MID and
collection's endpoints
start process and
make fake response
<-response--
<-response-- with MID
time passed.....
client runs request for particular MID
--request-->
nothing for you yet
<-response--
finish process and
make real response
<-response-- with MID
--request-->
yes, we have something for your MID
<-response--
Collection could be both another thread in client's process, and
separate process that is running on the same (or even separate)
machine, and client doesn't need to keep process up and running all
the time.
>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.
I'm also not sure that that's something user asked about, but at
least it's something I'm working on :)) and it looks similar to what
was discussed.
Any comments, ideas, thoughts?
Best wishes, Paul.
Date: Sun, 11 Mar 2001 15:24:30 +0800
From: Gunther Birznieks <[EMAIL PROTECTED]>
Subject: Re: [OT] JMS-like event framework for Perl
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.
At 09:25 AM 3/11/2001 +1300, Nathan Torkington wrote:
>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/
>
>Nat
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
