Based on your experiences, what would be the best technology stack you'd recommend for a client-server asynchronous messaging platform? Here're the scenarios: (details below are just examples and not the actual project I'm working on XD)
Thanks and hope to hear from you guys.
asked Oct 08 '09 at 05:58
Lightweight scripting languages like Ruby, Python are a joy to program in. Until you decide you need to provide redundancy/clustering or you need to scale dynamically to dozens of distributed nodes, or even just atomic, concurrent, persistent MQ.
Note that polling + SQL CRUD does not equate to an atomic, concurrent MQ, and that running two servers + memcached does not equate to a dynamically scalable distributed architecture.
All of the above are readily available (JavaMQ, JBoss MQ, Terracotta, various app servers) in the Java ecosystem which you're trying to avoid.
Use the right tool for the right job.
answered Oct 09 '09 at 00:33
Alistair A. Israel
It seems you are looking for an off-the-shelf lightweight middleware solution. SecondLife might answer your query at their wiki entry about a detailed evaluation of message queue brokers.
The best solution can be picked if you know well your requirements, esp. in terms of reliability / persistence / performance / scalability / language-support / protocol-support / manageability etc. Pick the trade-off, you can't have all IMHO. You can build if you're up to it, but then again, that will require a lot from you.
The Java ecosystem has a number of solutions as enumerated. Our only experience with a Java-based broker is with ActiveMQ, which supports practically most languages via STOMP + REST + Comet protocol
The non-Java open-source world practically has a lot of implementations coming from all sorts of languages with varying features. The popular ones are usually AMQP-based or Stomp-based (ActiveMQ, RabbitMQ, ZeroMQ). Others invent their own protocol (Kestrel Scala of Twitter, Memcachedq which is a variant of memcached protocol with queueing, Gearman for interlanguage async-calls, among others.
answered Oct 14 '09 at 20:36
Sounds like a perfect job for Adobe FLEX or Adobe AIR for the client and Tomcat as the server using BlazeDS (http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/).
Flex would be more ideal since it's easier to deploy (loads from a browser) you just need Flash player installed. It's really Flash under the hood just repackaged to suite the business world.
AIR in the other hand would require a manual app install of the client as well as the AIR runtime. What's good about that is that you won't require your users to re-download the client each time they need to use it.
That's cross platform, light-weight, able to communicate in JSON and a secure backend. And yes, JAVA can be lightweight too, contrary to popular belief.
answered Oct 08 '09 at 12:11
I dont know if this will help, but one time when I was in a trading company, we try to port its C# trading platform servers to C++ under fedora and we use EPOLL implementation for this. Its like an event driven client server , where the server tends to register all the descriptor of each client and sleeps until a client wakes it up. You can see more of the example in this site
answered Nov 01 '10 at 17:08
You may try node.js
There is no such thing as the best. It all depends on CONTEXT
answered Aug 29 '11 at 10:59