[Twisted-Python] PB vs JMS
I looked at PB for an architecture with one client distributing some processing to several servers. Now I came across JMS and I have seen that using ActiveMQ with the Stomp protocol there would be a good support for Python. Surprising I couldn't find any article comparing the two technologies. I wonder if they target different problems (it doesn't look to me). Is anyone able to sketch advantages of one solution against the other? Thanks, Jacopo
On Mon, Oct 5, 2009 at 9:14 AM, <jacopo.pecci@gmail.com> wrote:
I looked at PB for an architecture with one client distributing some processing to several servers. Now I came across JMS and I have seen that using ActiveMQ with the Stomp protocol there would be a good support for Python. Surprising I couldn’t find any article comparing the two technologies. I wonder if they target different problems (it doesn’t look to me). Is anyone able to sketch advantages of one solution against the other?
I don't think there is a good comparison between the two because they're different technologies addressing different problems. JMS is a messaging middleware defined at the Java language API level (hence the need to for STOMP protocol and similar adapting layers for use with Python or other non-Java languages). PB is a "secure, easy-to-use Remote Procedure Call (RPC) mechanism." For the system you're descibing it seems like message middleware is more what you want. Unless you want to implement your own load balacing, work distribution and failover algorithms? Another alternative to ActiveMQ is RabbitMQ which implements AMQP, which a Python client can speak directly without using a limited protocol like STOMP. There's also handful of good AMQP python libs including one for use in Twisted: txamqp. -Drew
Drew Smathers wrote: Hi,
JMS is a messaging middleware defined at the Java language API level (hence the need to for STOMP protocol and similar adapting layers for use with Python or other non-Java languages).
A bit off-topic, but note that it's sometimes possible to use JMS almost as-is with Python too. Doing that is probably pointless if one's not coming from Java world and expect to see a similar API in Python and it probably doesn't make much sense for open source messaging middleware but it makes sense if you have to use proprietary software such as WebSphere MQ or webMethods that doesn't care much about open protocols, especially when there's a need for seamless integration with Java JMS clients. http://jira.springframework.org/browse/SESPRINGPYTHONPY-12 https://src.springframework.org/svn/se-springpython-py/sandbox/dsuch/jira/SE... https://src.springframework.org/svn/se-springpython-py/sandbox/dsuch/misc/jm... -- Dariusz Suchojad
On Mon, Oct 5, 2009 at 8:21 PM, Drew Smathers <drew.smathers@gmail.com> wrote:
On Mon, Oct 5, 2009 at 9:14 AM, <jacopo.pecci@gmail.com> wrote:
I looked at PB for an architecture with one client distributing some processing to several servers. Now I came across JMS and I have seen that using ActiveMQ with the Stomp protocol there would be a good support for Python. Surprising I couldn’t find any article comparing the two technologies. I wonder if they target different problems (it doesn’t look to me). Is anyone able to sketch advantages of one solution against the other?
I don't think there is a good comparison between the two because they're different technologies addressing different problems. JMS is a messaging middleware defined at the Java language API level (hence the need to for STOMP protocol and similar adapting layers for use with Python or other non-Java languages). PB is a "secure, easy-to-use Remote Procedure Call (RPC) mechanism."
For the system you're descibing it seems like message middleware is more what you want. Unless you want to implement your own load balacing, work distribution and failover algorithms? Another alternative to ActiveMQ is RabbitMQ which implements AMQP, which a Python client can speak directly without using a limited protocol like STOMP. There's also handful of good AMQP python libs including one for use in Twisted: txamqp.
-Drew
Thank you Drew. I should have sketched a bit more: I have to compute many self-contained jobs and then elaborate their results. Jobs are distributed to many machines and results are sent back to the Master. The Master should not wait for all the results to be ready but should start processing as soon as the first one arrives. After all the results have been collected and processed, everything starts over with newer data. I have implemented a mock example with PB but if I understand correctly a messaging system would put me to a higher level of abstraction taking care of many technicalities. I am now looking at rabbitmq and txamqp, it is a bit hard to find some documentations but slowly i am getting the full picture. Thanks Jacopo
Thank you Drew. I should have sketched a bit more: I have to compute many self-contained jobs and then elaborate their results. Jobs are distributed to many machines and results are sent back to the Master. The Master should not wait for all the results to be ready but should start processing as soon as the first one arrives. After all the results have been collected and processed, everything starts over with newer data.
I have implemented a mock example with PB but if I understand correctly a messaging system would put me to a higher level of abstraction taking care of many technicalities. I am now looking at rabbitmq and txamqp, it is a bit hard to find some documentations but slowly i am getting the full picture.
Thanks Jacopo
Hi Jacopo,
this article problably can give you a big picture http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ AMQP helps you distribute messages to clients that are network connected and can do some jobs when receiving messages. So you can distribute data to your clients using the json protocol to send messages containing data to the clients. And from the computing client you can send back the results always using the json protocol. This only if you don't want to use a central database... but this depends on how you design your app. HTH Fabrizio
participants (5)
-
Dariusz Suchojad
-
Drew Smathers
-
Fabrizio Mancini
-
Jacopo Pecci
-
jacopo.pecci@gmail.com