Is a queue server the right solution?

[lazzha]

Hi you all,

Here is the deal, in our company (ok I wish it was my company), we are implementing a mobile phone activation system, the main idea is that a client (ivr), talks to an Activation Server (composed by Spring + Pojos + Hibernate) and that the client sends every data that we need for the activation.

But, if for some reason, once we have all our data collected, the activation can’t be completed, because the databases are down, the ivr lost the connection with the activation server, or whatever other problems, we need to store all that data somewhere and wait until the server, databases or activation resources are available so we can complete the activation.

We have in mind 2 solutions

The first one, an awful not so elegant one, but that could work, is to use a database to store all that data (Persist our ActivationData Pojo) and then use a daemon to se if there are any activations awaiting in that database, once the resources are available again.

And the second one, a more elegant one is to use ActiveMq, to queue all our activation objects (Pojos), and once our activation resources are ready to go, ActiveMq, would talk to the Spring Facades to complete the activation.

That’s what we have in mind, but we would like to hear your opinion, if you think we are on the right track with the ActiveMq idea (because that is the one we are inclining for), or if there’s a more easy way to do this please tell, or a more elegant way… we would like to hear your comments… Also we would like to know if anybody has used ActiveMq with Spring, or if our idea is viable or no…

Thanks to everybody
Cheers

[Colin Yates]

If you are going to JMS/queues then you will want some way of persisting the messages for fault tolerance, in which case you will probably still end up persisting them in the DB

To me it seems to you need to decide whether the operation is synchronous, asynchronous or synchronous unless errors, in which case it is retried in an asynchronous manner

To be honest, both ways seem viable. It is quite common to have off load retries into an asynchronous queue, so don't worry about it, you aren't doing anything "wrong"

You might find it simpler just implementing it using asynchronous messages from the start.

HTH

[manifoldronin]

I would go with JMS. The first choice seems to be reinventing JMS essentially.

[jbetancourt]

I second the JMS solution. Plus, some JMS providers support persistence, guranteed delivery, and all sorts of other goodies. Now whether they really work and won't add wrinkles to your forehead getting it all to work, ....

[Colin Yates]

I think "guaranteed" delivery is actually part of the JMS spec isn't it?

[jbetancourt]

Probably, haven't used it in a while, or needed to consider it in any recent project. My main point was that JMS and/or products supporting it, already "solved" many of the issues.

[lazzha]

Indeed now that I think again the first solution it would be reinventing the wheel :roll: :lol:, but now, from the blackboard to the byte code, once we have the solution, I'll post it if its any good to any body...

Once Again Thanks to everybody

Cheers