| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Intercommunication? |
« View previous topic :: View next topic » |
| Author |
Message
|
| viki |
 Posted: Sat Apr 01, 2006 4:12 am Post subject: MQ Intercommunication? |
 |
|
Acolyte
Joined: 07 Feb 2006
Posts: 50
|
Hi,
The subject line is quite simple. But the question is not exactly same. Well, I have MQ installed on machine A. Another machine B uses JMS to put message (say: MSG) on machine A's queue. Now, there are other machines, say: P, Q and R, on which MQ is installed. These P, Q and R machines communicate with machine A and recieve there message (MSG).
In other words, Machine B put MSG (suppose for Machine Q) on Machine A and this MSG should only be recieved by Machine Q. That is, each MSG put by Machine B on A, will be specific for anyone of P, Q or R.
How this could be achieved? Right now Machine B is just putting MSG on machine A, which then SEND this MSG to ONLY one machine P. That is, right now, Machine A is not able to differentiate b/w messages that this partuclar message (MSG) is for which machine? P, Q or R?
I need to come up with a technique via which machine A is able to differentiate b/w messages and after identification it should send to the right machine P, Q or R?
I hope, I'm able to explain the scenario correctly.
Looking for the reply.
Bye,
Viki. |
|
| Back to top |
|
 |
| wschutz |
| Posted: Sat Apr 01, 2006 4:30 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
When you say:
| Quote: |
| should only be recieved by Machine Q |
Do you mean that even if the other machines tries to get the messages that should go to machine Q, they should not be allowed to?...or do you mean that when machine Q tries to get messages it only gets message intended for it?
The first case is an issue of "security", the second case is an issue of selecting the correct messages.
_________________
-wayne |
|
| Back to top |
|
|
| viki |
| Posted: Sat Apr 01, 2006 4:37 am Post subject: |
|
|
Acolyte
Joined: 07 Feb 2006
Posts: 50
|
Hi,
It is the second case. That is, when Machine Q tries to get message from Machine A, it should only get those messages which are intended for it only.
Bye,
Viki. |
|
| Back to top |
|
|
| wschutz |
| Posted: Sat Apr 01, 2006 4:43 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Read up on MessageID and CorrelID in the info center. You can use that to "selectely" get messages.....
_________________
-wayne |
|
| Back to top |
|
|
| viki |
| Posted: Sat Apr 01, 2006 4:54 am Post subject: |
|
|
Acolyte
Joined: 07 Feb 2006
Posts: 50
|
Hi,
Ok. But how about queue? I mean, creating two queues one for Input and for Ouput on Machine A Or sperate OUTPUT queue for each of P, Q and R?
If it is one OUTPUT queue on machine A, then it means all of P, Q and R will connect with this queue and read messages which are intended for them only.
Bye,
Viki. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Apr 01, 2006 5:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
MQ is not capable of routing messages based on content. It is only capable of routing messages based on certain fields in the MQMD header - mainly the destination queue name and partly the destination qmgr name.
If you have message 1 intended for program A, and message 2 intended for program B... then MQ can't look at the message and say "give this one to A and that one to B", unless you tell MQ "send this message to Queue A" and "send this message to queue B".
Pub/Sub makes this a little different. Pub/Sub uses a program (the broker), which contains a routing table that says "if the message is for this topic then give a copy to all of these queues". And then programs that want messages on a topic can register a queue in this table. When someone gives a message to the broker application (by publishing it to the broker queue), then all the currently registered subscribers will get a copy. Pub/Sub uses the MQRFH2 header on the message to describe what topic it belongs to.
You can also write your own program to examine messages and figure out where they belong, based on message content. So you can write a program that would read all your messages on Output Q from machine B, and then decide "this one is for machine P" and put it on another queue destined for machine P.
Or you can buy WebSphere Message Broker, and use it to write these programs, or use it's more advanced pub/sub broker to handle subscriptions based on message content as well as topic.
Or you can do what Wayne suggested, and use a fixed Message ID or Correlation ID on the messages that says "this message goes to Machine P" or "this message goes to Machine Q". Then all the P,Q, etc. can connect to the same queue and ask only for messages with their fixed MsgID.
This is not best practices, though. If you have messages piled up on this queue, you don't know why without looking at each message. Is it program A that's broken? Program B? And people have some difficulty working with message Id's and correlation Id's because they think they are strings when they aren't.
So usually I recommend that people either have the sending app put messages onto different queues for different destinations, or build a relatively simple routing or filter application that will take messages from one input queue to many output queues.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Apr 01, 2006 9:51 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Jeff very good advice.
Here is the shortcut for JMS.
In your JMS application define a different JNDI destination for each of Q, P, R.
Now in A create a default path to Q, P, R.
So when you (B) put the message on A it will automatically flow to Q, P, or R.
Note that if B is a qmgr and not just an MQ client you may have to create a default path for Q, P, and R on B as well. Nothing says that default path can't go through A.
Read the intercommunications manual about default paths:
xmitq with name of destination qmgr or qmgr alias.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Apr 01, 2006 10:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
Jeff very good advice.
Here is the shortcut for JMS. |
Except for the brief part where I get my transmission headers confused with my MQMDs.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| viki |
| Posted: Sun Apr 02, 2006 2:03 am Post subject: |
|
|
Acolyte
Joined: 07 Feb 2006
Posts: 50
|
Hi,
Actually I've achieved this task by creating seprate queues and channel-pairs for each of P, Q and R. Currently, all the queues are created under the same Queue Manager (since I do not have seprate machines for P, Q and R right now - But in real scenario, P, Q and R are different machines and situated physically on different locations as well).
Now for e.g. in future any new machine say: M comes, where role of M is same as of P, Q and R, then I just have to create a new queue and channel for M in MQ Explorer, and also have to define JNDI name in WAS admin console. No need to change the code  .
Bye,
Viki. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Apr 02, 2006 12:28 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Only if your code in WAS is already set up for adding an nth +1 destination.
As you retrieve the JNDI destination with a fixed string you need to be able to retrieve a array (through config or properties) which has the relevant JNDI names and the destination information.
Now if P,Q, R serve the same purpose (i.e. different app servers sharing the load) you can make A or B a gateway qmgr in a cluster and don't have to define a specific destination for P,Q,R as they are all sharing the same destination within the cluster. (Read up in the cluster manual)
Make sure however that you have a default reply path from P,Q,R to A and/or B so as to be able to satisfy a request /reply model.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| viki |
| Posted: Mon Apr 03, 2006 1:43 am Post subject: |
|
|
Acolyte
Joined: 07 Feb 2006
Posts: 50
|
| fjb_saper wrote: |
Make sure however that you have a default reply path from P,Q,R to A and/or B so as to be able to satisfy a request /reply model.
|
What is meant by "default path"? In real scenario, P, Q and R are actually different companies machine where MQ is installed. And these companies, P, Q and R has nothing to do with each other. That is, no type of intercommunication exist b/w P, Q and R. Only P, Q and R will interact with A. Whereas, B will talk with A using JMS.
The communication between P, Q, R with A is bi-directional. Normally, P, Q and R will GET some message from A and also will PUT some message back on A.
Bye,
Viki. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 03, 2006 3:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| viki wrote: |
| fjb_saper wrote: |
Make sure however that you have a default reply path from P,Q,R to A and/or B so as to be able to satisfy a request /reply model.
|
What is meant by "default path"? In real scenario, P, Q and R are actually different companies machine where MQ is installed. And these companies, P, Q and R has nothing to do with each other. That is, no type of intercommunication exist b/w P, Q and R. Only P, Q and R will interact with A. Whereas, B will talk with A using JMS.
The communication between P, Q, R with A is bi-directional. Normally, P, Q and R will GET some message from A and also will PUT some message back on A.
Bye,
Viki. |
Still there needs to be a default path between P and A, Q and A, R and A ... Otherwise there is no possibility for a request response scenario ( at least not with dynamic temporary queues)...
and possibly between P and B, Q and B, R and B all going through A....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sumit |
| Posted: Mon Apr 03, 2006 7:34 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
Hi Viki,
Is it right that the applications for which you want to build this architecture is scalable. I mean to say that is it possible that there can be an increase in the number of end application site i.e. currently you are having A, B and C. But in case if, it may rise to D, E, F, G etc. then? Each time you have to create a seperate channel to connect to all the end sites.
In this scenerio, Jif's idea of using a message broker is good. It will help to select the correct destination application on the basic of the message content and also with the use of a gateway queue manager, your overhead will also be decreased as you have to connect the new application with the gateway queue manager only. Just the addition of output nodes in the flow inside the broker can solve your problem.
Hope this will help you.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| viki |
| Posted: Tue Apr 04, 2006 5:39 am Post subject: |
|
|
Acolyte
Joined: 07 Feb 2006
Posts: 50
|
Hi,
Jif's idea about broker is good. But the problem is that, I have almost finish this task and there do exist a time-limit from my boss for each task. Well, initially, we have to create queue and channels but in future addition of new machines will be not frequent. It will be like 2-4 machines, if added. Otherwise, the probability is less.
What, I am worried/concern with this techniue/design is that, it should not be performance bottleneck? Otherwsie, adding new queue/channels on rare occasions are afforadable.
Bye,
Viki. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 04, 2006 5:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You won't know if it's a performance bottleneck until you test the performance.
And then you won't know if it's a bottleneck until you understand your performance requirements, and how the performance of the task affects the overall performance and whether it meets the requirements or not.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
