Jms appropriate for this? + related questions

Question

Hello
so we currently have 2 separate systems.
On the external system usesr can enter info into a db.
On the internal site, a process runs every 15 minutes to pull all new entries on the external site db into the internal site db.
I am about to suggest that jms be used to replace that process, because
1. it seems appropriate
2. the current process is buggy.
the client is extremely worried about security. Are there any known jms vulnerabilities that can be exploited if a firewall port is left open for JMS? (of course, a port is currently left open for the existing process, but I have to ask...)
from my understanding of jms, if an insert fails on the internal side, we can shunt the messages off to an error queue, and use jmx to try and reinsert. Is that correct?
Is there any way to stop an MDB from reading more messages off the Q if there is an error?
thanx
Message was edited by:
shrndegruv

Answer 1

Are there any known jms vulnerabilities that can be exploited if a firewall port is left open for JMSYou'll have to check with the JMS vendor you decide upon. Industrial strength implementations like MQ allow you to encrypt traffic between the two systems using digital certificates, which makes things about as secure as you're likely to get.
if an insert fails on the internal side, we can shunt the messages off to an error queue, and use jmx to try and reinsert. Is that correct?JMS is just a specification. You have to decide how you want to handle errors then write your code accordingly. Some general principles that may help...
Treat business errors and system errors differently. A business is one where the data is invalid, e.g. field too long for a database column. It doesn't matter how many times you attempt to reinsert the message it will always fail. The only way to handle this error is to fix the message or fix the data in the database.
Technical errors are things like network outages which can be recovered from. In this case it may be a good idea to keep retrying the message, but also raise some kind of alert.
Error queues can be a great idea in some circumstances, but you need to consider whether message order is important. What happens if update 1 gets moved to an error queue and update 2 is inserted before update 1 was applied. Is your data still valid?
You also need to think about transactionality. Unless the entire transaction (from remote db to local db) occurs in a distributed transaction you will always run the risk of lost or duplicate messages. Will duplicate creates be rejected? will duplicate (and out of sequence) updates cause problems? Can you afford to lose the occaisional message?
These problems aren't unique to messaging and if they haven't been thought about could explain why your current system is buggy.
Is there any way to stop an MDB from reading more messages off the Q if there is an error? Don't know about this one (maybe with JMX). You can certainly do the equivalent if you write your one JMS Listeners (just stop the connection), or if you use a middleware product such as IBM Message Broker (WBIMB).
Last thing to think about is that while JMS is a reasonable solution for this type of problem there must be data synchronisation tools out there to do this type of thing for you.