Web application subscribed to message queue

Web have (1) a web application where a user creates some tasks and (2) other system (service based on Java) that processes the tasks.

The tasks are date/time dependent - user creates the task, sets its start date to e.g. tomorrow 1am and he is done. The Java service tomorrow at 1am starts processing the task and reports current status of the processing to the application.

We plan to use ActiveMQ for (a) notifying the service about new task, (b) notifying the web app about current task status. The (a) part is with no problem.

My question is - is (b) good idea? Web app has to be subscribed to the message queue so that it is called when there is a message that reports current task progress. The web app should process that and store the info in db.

I'm in doubt that we should do it in such a way, because if there is no traffic to the web app, it dies and so dies the subscriber. So the messages won't be processed.

Is it better to create .NET service that is permanently connected to the queue? The advantage to be subscribed in web app is that in case we would need to use 2nd level cache in Nhibernate, everything works.

If there are two processes (web app, new service) that use Nhibernate and 2nd level cache, this could cause problems because each of them could operate on different data.

The reporting could be done with ordinary web service, but colleagues reported, that it is quite complicated to communicate over wcf from java to .net and use certificate for secure communication.

WE do a similar thing,and use the message queue to hold tasks that need doing in differnet services, if the service dies, the message queue continues to be written to, we don't write to a sql server as we use a different machine AND that could also go down

We don't subscribe to the queue, we simply open and pop and messages of if there are any messges on there, based on a timer, we found this more reliable and we could set the time

We have built similar systems, in our case we did it slightly differently.

• We used a table instead of a queue. This allowed us to log when the item was processed and resend by changing the status to "not sent"
• We also polled the table with a timer service, instead of a trigger notification

The problem with notification is what happens if the system that should be listening for the notification is down when the notification is raised.