MSMQ/JMS Bridge,

Actually it is not so difficult to interact with MSMQ though java. I have done so many R&D on it.There is very cool approach to make c+ dll by using JNI concept in visual studio c++ 6.0.I have wrote so many dll on it and able to receive the messages from MSMQ by using this dll in java class u will get String message and send it to JMS.If you need more information on it just mail me in and one more think everything is free.And one more think as per your requirement i can also create a dll without any cast.You can send me mail on pthakre@gmail.com

If you want download the sample code and dll please clink on blow link

http://msmqtojms.sourceforge.net/

http://javamsmq.codeplex.com/


Please find the below best fittest architecture:-



Brief description of above architecture:-

1) Windows machine 1:- This machine will contain the MSMQ(from where we have to receive the messages) and Jboss server (to receive the messages from msmq and sending to another MSMQ (resides in win machine 2) by using the JMS and DLL).
1.1. Jboss server contains the ear file which is responsible for receiving and sending the messages from msmq by using the dll. In step 1 listener will receive the messages from MSMQ and send it to JBOSS JMS followed by doing some business login on received message (Step 2).
1.2. The Jboss server’s ear also contains MDB which is responsible to receive the messages from JMS (Step 3) and send it to MSMQ (Step 4).

2) The logging mechanism will be there only in windows machine 1.Logging will be done in two stages.
1.1. In first stage when and receiving the message form MSMQ and sending to local JMS.
1.2. In Second stage when and receiving the message form JMS and sending to another MSMQ.

3) Windows machine 2:- It contains only the MSMQ which is the just destination for all incoming messages.

Pros:-

1) JMS is responsible for holding all the messages and it will not loose any messages even if something will get crash.
2) Monitoring and debugging has to be done only in one machine. We don’t have to bother about windows machine 2 because there we have not deployed anything.
3) No need of any other machine to deploy the ear file.
4) Jboss is open source and its JMS is reliable for no message loss.

Cons:-

1) It is not fully distributed architecture. Load will be high in JBOSS server if messages frequency is too high.



Brief description of above architecture:-

1) Windows machine 1:- This machine will contain MSMQ and adopter 1. Adopter 1 is just using to receive the messages form MSMQ and sending it to JBOSS JMS which resides in foreign server.

2) Windows machine 2:- This machine will contain only the JBOSS server JMS. This is kind of messages temporary destination (To prevent any message loss).

3) Windows machine 3:- This machine will contain MSMQ and adopter 2. Adopter 2 is just using to receive the messages form JMS and sending it to MSMQ which resides in same server.

Pros:-

1) JMS is responsible for holding all the messages and it will not loose any messages even if something will get crash.
2) Monitoring and debugging has to be done only in windows machine 1 and 3.
3) It’s a 100% fully distributed architecture.
4) Jboss is open source and its JMS is reliable for no message loss.
5) In this architecture JBOSS JMS can be deployed anywhere its just platform independent.

Cons:-

1) Require extra machine.



Brief description of above architecture:-

1) Windows machine 1:- This machine contain only one adopter which is responsible for everything receiving the messages, parsing the messages, doing business logic and finally to send it foreign MSMQ.

Pros:-

1) Not required JBOSS JMS .

Cons:-

1) Fully tight coupling.
2) Possibility of messages loss.
3) Monitoring and debugging very difficult.
4) Will not work in very high frequency of incoming messages in MSMQ.