Triggering PHP from ActiveMQ

Background: Our current system involves two services (one written in Java, the other in PHP) that communicate with each other using HTTP callbacks. We would like to migrate from HTTP callbacks to a message-based architecture using ActiveMQ (or another, if necessary). We'll probably use STOMP to communicate between them. Eventually, the PHP service will be rewritten in Java, but that's not part of this project.

Question: How can the ActiveMQ system notify PHP that a new message has been posted to the queue that the PHP system is subscribed to? In the current system, the callback inherently calls into the PHP and triggers it. This goes away with a message-based architecture.

Possible solutions:

• Cron regularly calls a PHP script that checks for new messages. yuck.
• A long-running PHP process that loops and sleeps and checks for new messages. less yuck?
• ActiveMQ calls a PHP script when a new message is posted. good, how?开发者_如何学编程
• ??

Check out Camel. It can run within ActiveMQ or by itself. Camel creates "routes" for messages. In this case I would suggest that you leave the PHP callback URL as is, and set up a route in Camel that takes messages from the queue and posts them to the callback URL. Then you can use Stomp within PHP to send messages to ActiveMQ. Your Java code can just use JMS for both incoming and outgoing messages.

Can you have ActiveMQ execute shell commands ? If so, just have ActiveMQ execute the PHP script through the command line whenever there is a new message to process. This saves you from running cron jobs and from having a long-running PHP loop.

Question: How can the ActiveMQ system notify PHP that a new message has been posted to the queue that the PHP system is subscribed to? In the current system, the callback inherently calls into the PHP and triggers it. This goes away with a message-based architecture.

I think you are working in the wrong direction. Consumers check with the queue periodically for new messages, not the other way around. If the queue needs to notify the consumer to read from it, then you haven't really decoupled these applications like you think you have.

I think the problem they are trying to solve is that a LAMP stack ( of which PHP is a part) is inherently tied into the request/response mechanism that the HTTP protocol forces on it, so having a Consumer ( which checks the ActiveMQ) queue written in PHP is workable, but the processes lifetime is naturally limited by any timeout in the HTTP protocol. the solution is one of:

1 - Don't run the PHP Subscriber inside apache/HTTP, and as a result you can then do a set_time_limit(0), and have the php Subscriber run forever ( till it crashes anyway), OR

2 - Realise that a Subscriber really does just do "periodic" checks, with lots of nothing in-between, so instead of while(1){ do_queue_stuff(); sleep(); } you remove the sleep, remove the while loop, and call it repeatedly from Cron or similar.

Each has it's own benefits, but both is equally good, IF the cron() frequency is tuneable enough. My Cron is limited to running every minute, which isn't very often, so I'd have to do a combination of the above two: called from cron every minute:

time = what_minute_is_it(); while ( what_minute_is_it() == time ) { do_queue_stuff(); sleep(1); }

I think what people may be after is a way to have the ActiveMQ system "hint" to the PHP Consumer system that there may be stuff in the queue that needs processing, and as a result save on all this queue processing start/stop/sleep/etc stuff if there's actually nothing really to do. Camel appears to be the way to do this.