SLUG Mailing List Archives
Re: [SLUG] Lightweight message passing infrastructure?
- To: slug <slug@xxxxxxxxxxx>
- Subject: Re: [SLUG] Lightweight message passing infrastructure?
- From: Julio Cesar Ody <julioody@xxxxxxxxx>
- Date: Tue, 21 Sep 2004 16:36:38 +1000
- Reply-to: Julio Cesar Ody <julioody@xxxxxxxxx>
IMHO, I would use Jabber. There's A LOT of Jabber APIs for every kind
of language, and they all seem quite simple to be used. In case anyone
asks: yes, it's purpose goes beyond instant messaging. And if you're
feeling smart, it's very easy to modify the messaging system to
implement nice features such as cryptography, etc.
Julio C. Ody
-----BEGIN GEEK CODE BLOCK-----
GCS/SS/CC d@ s: a? C++(+++) ULB+++$ P++++ L+++$ !E W++(+++) N+ !o K- !w O- M
V- PS+ PE Y+ PGP++(-) t 5 X R+ tv-- b++ DI-- D+ G++ e h r+ y++*
------END GEEK CODE BLOCK------
On Tue, 21 Sep 2004 16:09:34 +1000, Andrew Cowie
> Quick survey: I'm building something that requires a lot of two-way
> (message/event) traffic between clients and servers, and could use some
> help picking a technology.
> The server->client direction is tricky in conventional web (and web-
> derived) models because it's always client request server response on
> the clients schedule (no good for passing messages from server to
> client, at least, not without client polling type behaviour, yuk). XML-
> RPC would have been perfect except for that. Given how absurdly simple
> and clean the Java APIs are, I may use it anyway.
> Someone at SAGE-AU suggested I consider ICE (an next gen CORBA, see
> http://www.zeroc.com/ ). It's pretty impressive, but seems like an awful
> lot of framework for what I would have hoped would have been a simple
> implementation, especially considering that I view the problem in
> message passing terms, not remote procedure calls or remote object
> invocation terms. That said, the scalability, availability, and just-
> works factor (once implemented) is alluring.
> In the Java world, there are obviously lots of frameworks, (ranging from
> J2EE EJB containers down to small things like picocontainer) but I don't
> really want a container at all - managing lots of objects, and
> persistence, isn't the problem I'm trying to fight.
> Further, I'd like the server to be a relatively stand alone thing, and
> containers introduce pretty massive installation headaches. OpenJMS
> would be good in theory, but it's very heavily J2EE based, and brings
> all that baggage.
> Any suggestions welcome.
> Andrew Frederick Cowie
> OPERATIONAL DYNAMICS
> Operations Consultants and Infrastructure Engineers
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html