| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Design consideration for using MQ in on-line application |
« View previous topic :: View next topic » |
| Author |
Message
|
| claire |
 Posted: Mon Apr 19, 2004 8:33 pm Post subject: Design consideration for using MQ in on-line application |
 |
|
Apprentice
Joined: 10 Apr 2002
Posts: 32
|
Hello,
Typically, MQ is designed for asynchronous model application.
If I want to use it to develop N-tier on-line application(for example, internet banking), what kind of design issues should I take into consideration? Thanks a lot. |
|
| Back to top |
|
 |
| tkane |
| Posted: Tue Apr 20, 2004 10:48 am Post subject: |
|
|
Voyager
Joined: 23 Dec 2002
Posts: 82
Location: Kansas City
|
Claire,
One thing to plan for it 2033's. I'm more of a Java and JMS newbie, but I've worked with online applications in realtime in a call center environment for several years.
There will be cases when the online back-end system can't reply in the time that the front end application can't tolerate.
In many of those cases you'll get data back later.
You'll need to deal with that at both times.
What do you do when the application gets no response from the back end?
What happens to the message that eventually comes back?
It's possible to build up a large message queue of entirely expired or "effectively expiered" messages.
In my case the back end application is IMS using OTMA. And I don't think that they can set an expiry on that message. When those messages come back after the client side application has given up, then they were piling up on my queues. And they had to be manually removed. That process needs to be automated with something that looks for messages older than 5 minutes and deletes them.
Those are the first things that occur to me.
Good Luck
Tom |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Apr 20, 2004 3:57 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Tom, prior to MQ 5.3.1 on the mainframe, the OTMA bridge ignored the Expiry value of the incoming Request message, and simply tagged the reply with an unlimited Expiry. And the orphaned reply message sit forever in the reply queue.
I also wrote a scavenger program to clean these up everday, but I choose 5 days, not 5 minutes, for the criteria to remove the messages. I want to have a 5 day running backlog of orphans. If present, their put times and volumes help identify problems. Frequently the front end apps never complain about a 2033 and just issue the request again.
At 5.3.1 (that version is only available for the MF), you can set a flag in the IIH (or CICS) header that will tell the OTMA to respect the incoming Expiry when it puts the reply.
Claire, tell your customer this: MQ assures THAT your message will make it, not WHEN your message will make it. For apps that need roundtrip times between multiple servers in seconds, let them know from day one that 99.9% of the time they will be happy. But, networks go down or get slow, servers go down or get slow, apps go down or get slow, and yes even MQ sometimes has an internal problem. Its those .1% of times that they will come crying "I thought MQ was fast and reliable!  Why did you design my system on MQ? ". Let them know from day one....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Apr 21, 2004 1:38 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
| Claire, tell your customer this: MQ assures THAT your message will make it, not WHEN your message will make it. For apps that need roundtrip times between multiple servers in seconds, let them know from day one that 99.9% of the time they will be happy. But, networks go down or get slow, servers go down or get slow, apps go down or get slow, and yes even MQ sometimes has an internal problem. Its those .1% of times that they will come crying "I thought MQ was fast and reliable! Why did you design my system on MQ? ". Let them know from day one.... |
is there a banner or t-shirt version of this??? 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Apr 21, 2004 2:48 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Despite the asynchronous history - the majority of new applications using MQ tend to using it in a synchronous manner - certainly in my experience.
IBM have highly optimised the performance of non-persistent messages over recent years and you should have no concerns about the MQ aspect of the overall response times.
Make sure you use non-persistent messages, set an expiry time and use GET with WAIT to receive the responses (typically matching on Correlid). |
|
| 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
|
|
|
|
