| Author |
Message
|
| dellv |
 Posted: Thu Apr 16, 2009 12:27 am Post subject: two applications talking to each other in a single QMngr |
 |
|
Newbie
Joined: 17 Mar 2009
Posts: 8
|
Dear all,
How do i design the communication between two applications?
Appl A is sending messages to Appl B and visaversa on a single Queue Manager. |
|
| Back to top |
|
 |
| sumit |
| Posted: Thu Apr 16, 2009 12:33 am Post subject: Re: two applications talking to each other in a single QMngr |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| dellv wrote: |
| How do i design the communication between two applications? |
May be MQ intercommunication mannual can help you if you need to understand how to send messages between 2 qmgrs.
| dellv wrote: |
| Appl A is sending messages to Appl B and visaversa on a single Queue Manager. |
Some more details on this please. 
From what I understood is, AppA can send msg to queue1 for appB to consume. AppB can send msg to AppA to consume. But then, why do you need MQ here? 
_________________
Regards
Sumit |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 16, 2009 12:34 am Post subject: Re: two applications talking to each other in a single QMngr |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dellv wrote: |
| How do i design the communication between two applications? |
However you like.
| dellv wrote: |
| Appl A is sending messages to Appl B and visaversa on a single Queue Manager. |
It makes no difference to Appl A if Appl B is on the same queue manager, a different queue manager or a queue manager with no direct connection to the queue manager Appl A is using.
From a WMQ point of view, it's all about message routing. In this example, I imagine the channel topology will be fairly simplistic.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Apr 16, 2009 12:37 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Appl A PUTs messages to a QLOCAL, and Appl B GETs messages from the same queue, and vice versa; don't use the same QLOCAL. Also define a couple of back-out queues, for your apps to dump any non-processable messages on.
This one's hardly rocket science...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 16, 2009 12:42 am Post subject: Re: two applications talking to each other in a single QMngr |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sumit wrote: |
| dellv wrote: |
| How do i design the communication between two applications? |
May be MQ intercommunication mannual can help you if you need to understand how to send messages between 2 qmgrs.
| dellv wrote: |
| Appl A is sending messages to Appl B and visaversa on a single Queue Manager. |
|
The poster's not using 2 queue managers
| sumit wrote: |
| why do you need MQ here? |
One possible reason: Appl B doesn't run all the time and messages are being queued up ready for it's run.
Another, less likely, reason: Appl B might one day move to a different server or platform. With WMQ that's an administrative change rather than a coding one.
Still a question straight out of the Intercommunication manual though...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Apr 16, 2009 12:42 am Post subject: Re: two applications talking to each other in a single QMngr |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sumit wrote: |
| ...But then, why do you need MQ here? |
1. He/she/it should use it because it keeps the likes of me in a job (the most important reason).
2. If you're thinking directly linking Appl A to Appl B, think about what happens when one of the apps is unavailable?
3. The apps are co-located on the same server at the moment, so what happens when one moves?
I could go on, but I'm tired now...
EDIT: Vitor, I think I'll just hit this  from now on, it should save me the effort of typing, as I think I'll never beat you to the buzzer!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 16, 2009 4:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...But then, why do you need MQ here? |
There are a variety of program-to-program communications methodologies, and MQ is one of them.
An alternative is APPC (Application Program to Program Communications) where you have a set of API calls to create a session between the two apps, and converse across the session. This works spectacularly, but requires the app to do network session management things.
Another is the traditional client-server protocol RPC (Remote Procedure Call).
MQ is another. The first chapter of many of thw WMQ manuals gives you an overview of what MQ offers.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Apr 16, 2009 5:53 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You need MQ (and a QM) to use the MQI, even when the apps run on the same server.
The benefit is that you could later separate them with no change to the application. Other forms of inter-process communication would not allow this.
The MQI is easy to use and has transactional (and asynchronous) features which are valuable. |
|
| Back to top |
|
|
| sumit |
| Posted: Thu Apr 16, 2009 6:27 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| Quote: |
| ...(and asynchronous) features... |
hmm... a possible reason which I forgot.
But thinking again, poster can also use a database instead of mq (considering poster has not already bought MQ software) as both apps are on same server and considering they will not move to seperate servers.
Some database softwares are free of cost and are easy to manage. So, if the requirement is to use MQ just to keep messages till other asynchronous app wakes up and get messages, a db would be better option.
Can't this a possible solution?
_________________
Regards
Sumit |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Apr 16, 2009 6:36 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sumit wrote: |
| ...both apps are on same server and considering they will not move to seperate servers... |
You must have crystal balls because I didn't get that from the original post. Basic common sense - plan for the worst case scenario, which in this case would be physical separation of the applications. And bear in mind, if you use a database, you have to code connection to it etc., and what's the betting it wont be local to the applications?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| sumit |
| Posted: Thu Apr 16, 2009 6:59 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| exerk wrote: |
| You must have crystal balls |
Not yet, my teacher says I have to practice for few more years.
| exerk wrote: |
| ...plan for the worst case scenario... |
sure.... I am learning it. 
_________________
Regards
Sumit |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 16, 2009 6:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sumit wrote: |
| Some database softwares are free of cost and are easy to manage. |
So you have a site that has paid good money to IBM for WMQ, and you're going to tell site management that you're bringing in free (open source) software. That will be an interesting meeting......
It's fair to assume that any site with WMQ will probably have a commerical db someplace. This does not alter the "database v message" discussion, which has rattled round the forum many times over the past few years.
It's a source of personal amazement the number of posts we get where people are storing messages long term in a queue and browsing them, rather than use a database. It's equally amazing that this number is balanced by the number of people trying to insert rows into a database table and use it like a queue.
Both solutions are technically feasable. Both solutions are not very good ideas.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 16, 2009 7:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
A simple and well-proven method of two applications 'communicating' is for one to create a flat (sequential) file, and the other to read the file. We could name this technique batch processing, or something.
Accessing a flat file takes substantially less resources than a db or an MQ app. And, this works well when both apps are on the same o/s instance.
You only need a db when you, um, need the capabilities of a db. You only need mq when you need asynchronous messaging, request-reply, assured delivery, application transparency, platform neutrality, clustering, multiple consumer, multiple requestors, ...
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Apr 16, 2009 7:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Files can cause loss or duplication of data (you can't read the same MQ message twice under normal circumstances). You certainly can't write to one file from multiple applications at the same time.
Databases are slower and it's also possible to duplicate data (by reading it twice) unless you are very careful with transactions.
Using non-persistent MQ messaging will allow communication in memory and at very high speeds.
MQ code is even optimised to bypass queuing if an app is waiting (MQGET) for a message which is being MQPUT.
So MQ works well for inter-process comms and long distance - it allows the use of a single API for all purposes and platforms. |
|
| Back to top |
|
|
|
|
