Reputation: 1
I understand if both the message queues (receiver and response) are present in the same server location I can use the JNDI connection factory and queue name jms/myqueue_qcf1 jms/myqueue1, to connect to the queue and send message to jms/myqueue_qcf2, jms/myqueue2
But in case of Interserver connectivity, will this be the same When the firewall b/w both the servers is opened. The MQ myqueue2 is setup as remote mq in Websphere.
Any help with code reference would be appreciable.
public void myAppListener extends MessageListener{ //getting message from MQ1 -
//sent by some other application - MQ1 is Local
//in appServer1
private static final String JMS_LC_JNDI_NAME = "jms/liftcargo_lara_qcf";
private static final String JMS_LC_QUEUE_NAME = "jms/APP.OUT.REQUEST";
public void onMessage(Message msg){
try{
TextMessage requestMessage = (TextMessage) msg;
String reqMessage = requestMessage.getText();
String correlationId = requestMessage.getJMSCorrelationID();
sendXMLToNextAppMQ(reqMessage , correlationId)
}
}
public static void sendXMLToNextAppMQ(String message, String correlID) throws JMSException { //The MQ to which the message is forwarded to is a Remote MQ, in different server appServer2
try {
InitialContext context = new InitialContext();
QueueConnectionFactory queueConnectionFactory =
(QueueConnectionFactory)context.lookup(JMS_LC_JNDI_NAME);
System.out.println("Connection Factory data :: "+queueConnectionFactory.toString());
Queue queue = (Queue) context.lookup(JMS_LC_QUEUE_NAME);
System.out.println("Check Queue Name :: "+queue.toString());
QueueConnection queueConnection = queueConnectionFactory.createQueueConnection();
QueueSession session = queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
QueueSender queueSender = session.createSender(queue);
TextMessage message1 = session.createTextMessage();
message1.setText(message);
message1.setJMSType("Tunnel message from CCAM.LARA.OUT.REQUEST MQ to
LIFTCARGO.OUT.LARA.REQUEST MQ");
message1.setJMSDestination(queue);
message1.setJMSCorrelationID(correlID);
queueSender.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
queueSender.send(message1);
} catch (NamingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}catch (JMSException e) {
// TODO: handle exception
e.printStackTrace();
}
}
}
In Method sendXMLToNextAppMQ (i.e., tunnel the msg recieved in MQ1 in appServer1 to MQ2 in appServer2) is there any other jndi properties needed to mention to connect appServer1 to MQ2 in appServer2 (firewall is opened b/w appServer1 & appServer2)
Upvotes: 0
Views: 554
Reputation: 7609
If your target request queue is on a different server, your application will still have the same code, but the name you supply will not be the name of a QLOCAL on the queue manager you are connected to, but instead will be a QREMOTE. If you are using JNDI to refer to your queues, you don't even have to change the name of the queue, only the referenced real MQ queue name need be changed.
For example, if you were using the command line JMSAdmin tool, you'd change the name in the QUEUE attribute only:-
DEFINE Q(myqueue2) QUEUE(Q.FOR.REQUESTS)
Then on your two queue managers, there would be definitions that look something like these:-
Local QM (QM1)
DEFINE QREMOTE(Q.FOR.REQUESTS) RNAME(WORK.QUEUE) RQMNAME(QM2) XMITQ(QM2)
DEFINE QLOCAL(QM2) USAGE(XMITQ) DESCR('Transmission queue for messages to QM2')
DEFINE QLOCAL(MY.REPLY.Q) DESCR('My application queue for responses')
DEFINE CHANNEL(TO.QM2) CHLTYPE(SDR) CONNAME('(qm2.machine.com(1414)') XMITQ(QM2)
DEFINE CHANNEL(TO.QM1) CHLTYPE(RCVR)
Remote QM (QM2)
DEFINE QLOCAL(WORK.QUEUE)
DEFINE QLOCAL(QM1) USAGE(XMITQ) DESCR('Transmission queue for messages to QM1')
DEFINE CHANNEL(TO.QM2) CHLTYPE(RCVR)
DEFINE CHANNEL(TO.QM1) CHLTYPE(SDR) CONNAME('qm1.machine.com(1414)') XMITQ(QM1)
In addition, it is good practice in a request/reply application, to provide the name of the queue where the response should be sent as part of the request message, and to code the responding application to read those fields (ReplyTo fields) and use them to send the reply message back, thus not requiring an extra QREMOTE definition on the Remote QM (QM2 in my example).
Upvotes: 0