| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Asynchronous Messaging |
« View previous topic :: View next topic » |
| Author |
Message
|
| solomon_13000 |
 Posted: Fri Oct 03, 2008 8:23 pm Post subject: Asynchronous Messaging |
 |
|
Master
Joined: 13 Jun 2008
Posts: 284
|
Does Asynchronous Messaging mean that a sending application can put messages on a queue and this messages can be picked up by the receiving application at any future point of time?. Time here refers to miliseconds or maybe months.
So consider a business scenario. Manufacturer and Supplier. Both manufacturer and Supplier have an order system. They must be up to process steel order. Now the issue is each company have their own CPU which are also commited to other processing activities. Now does the use of Asynchronous Messaging help to resolve this problem between the manufacturer and supplier?. Does it impact the business activities?.
Also I came across a reading that says Asynchronous Messaging does not generate a reply message. So does this mean that there is no chance of knowing if a transaction is successful?. |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Sat Oct 04, 2008 3:49 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
I define asynchronous messaging as the fact that the sender and the receiver do not have a direct, always running connection between each other.
Asynchronous messaging allows a sender to put a message onto a queue and for a receiver to get it at their convenience, do their work, and (if required) send a reply back to me. Of course, at this time, the sender may not be around and will get the reply at their convenience.
WMQ can be used to approximate synchronous messaging by having the sender and receiver always up and running so that they can process messages on the queues.
Regarding your question of "does it impact business activities", the needs of the business usually dictate what is and is not acceptable. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 04, 2008 3:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Also I came across a reading that says Asynchronous Messaging does not generate a reply message. So does this mean that there is no chance of knowing if a transaction is successful?. |
Asynchronous messaging is an application programming mode - a choice.
Nothing in the request-reply model precludes the replying application from acknowledging the requestor. Again, this is an application design choice.
There are several APIs that allow the requesting and replying applications to communicate directly. Google APPC. This type of coding requires the application establish a session, then coverse across it. Both applications must be written to maintain this conversation and recover from errors.
One of the big advantages of WMQ is that the application program doesn't need to concern itself with how the message gets delivered, or whether the replying program is currently available.
_________________
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 |
|
|
| solomon_13000 |
| Posted: Sat Oct 04, 2008 7:30 am Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
| Quote: |
| Asynchronous messaging is an application programming mode - a choice. |
So it means that from an MQ point of view there is no attributes to be set. But however since the receiving application can get the messages at their convenience from the local queue, therefore the messages should not be set to expire at any point of time. Is this correct?. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Oct 04, 2008 7:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Please get training.
Please do not use this forum as a training resource.
 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 04, 2008 7:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| So it means that from an MQ point of view there is no attributes to be set. |
There are no specific message attributes for asynchronous messaging.
| Quote: |
| But however since the receiving application can get the messages at their convenience from the local queue, therefore the messages should not be set to expire at any point of time. Is this correct?. |
Usually this is the correct. But, for an application that is time-sensitive (ATM banking machines, for example), the business requirement may specify that if the message can't be delivered in a timely fasion (in 5 seconds or 5 minutes, for example), the message should expire.
_________________
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 |
|
|
| gbaddeley |
| Posted: Sun Oct 05, 2008 6:33 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
| ...But, for an application that is time-sensitive (ATM banking machines, for example), the business requirement may specify that if the message can't be delivered in a timely fasion (in 5 seconds or 5 minutes, for example), the message should expire. |
Yes, that would be the case for a non-persistent message where its OK to lose the message. eg. An account balance enquiry.
However, for "update" type transactions, such as ATM deposit or withdrawal, persistent message should be used within syncpoint, and they should not expire. We don't want these to be lost !!!
It may be acceptable for a reply message to have an expiry interval, as the update transaction has been done at the bank, and the reply is just a confirmation that allows the receipt to be printed (if there is paper in the ATM!)
(ATM and bank used for illustrative purposes only)
_________________
Glenn |
|
| 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
|
|
|
|
