| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| IIB design. please advise. |
« View previous topic :: View next topic » |
| Author |
Message
|
| Armageddon123 |
 Posted: Mon Jul 14, 2014 10:27 am Post subject: IIB design. please advise. |
 |
|
Acolyte
Joined: 11 Feb 2014
Posts: 61
|
Hi Experts,
need your advise with a new problem.
I have a requirement.
App A will put message to MQ Queue, . IIB needs to transform that message and call a Webservice and check if it is success or not.
simple and fairly easy.
MQInput- Compute- SOAPRequest-Compute.
But it becomes all the way complex with one more line of requirement.!
Due to *some* reasons, sometimes the Webservice may be down. but IIB needs to send the requests to the webservice in the order of the MQ request.
Under no circumstances should the order change (eg:, message 3 on MQ should never hit Webservice before Message 2.)
How do we do this gentlemen?
Retrying for n times and then backing out the message wont work out here. then the order/sequence is lost.
MQ Message sequencing cannot be done. because there is no group of messages in one sequence.
Everything is sequence. message2 should be processed only after message1. message100 needs to be processed only after message99. message10001 needs to be processed only after message10000.
Initial design that came to my mind is
If the previous webservice call is success, then put a trigger message to start the processing again. But what if there is no message available to be processed. So that removes the possibility of continuously processing messages as they come
one option that i feel viable is
MQInput-MQGet-compute-SOAPRequest-Compute
Every minute, have a cronjob in Linux which calls a java program that puts a trigger message to MQinput,,, it gets the app message from MQGet in transaction 'yes' mode and invokes the webservice.
If it fails, put appropriate exception handling so that message remains in the MQGet Queue.., to be retried next minute then.
This flow will get triggered every minute irrepective of the speed at which message comes from frontend app.
This is a design which i feel is possible. Could you experts please advise me if there are any better ideas for the same.
I am posting in general discussion page as i am not very sure if this kind of a design doubt can be posted in WMB specific forum.
Thanks |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Mon Jul 14, 2014 10:48 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Your requirement is suffering from what we call 'Message Affinity'.
This is generally regarded as a bad thing.
If your requirement is so hard and fast that there is no way to revise it then you are stuck between a rock and a hard place.
Ask the person who gave you this requirement, what should you do if the webservice is down for days, weeks or even longer? What then?
There has to be a way round this. Once you get the answer to that you can proceed with your design.
Perhaps the choice of using a webservice for such a business critical element is wrong? Why not consider making it use of a more reliable message system.... like WMQ? Then you wouldn't have this problem.
Sadly if you are stuck with this then you could keep it simple and let it retry forever.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Jul 14, 2014 1:20 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Web Services are newer than MQ - so must be better right? 
How many times have I said the same thing - if you want it to work - use MQ and let IBM solve all these issues (and more) for you.
Otherwise use the (cursed) web services and handle your own retrying, timeouts, queuing, ordering, priority, thread saturation, blocking, transactionality, connection rejection, and a thousand and one other things which really are nothing to do with application A talking to application B.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Armageddon123 |
| Posted: Mon Jul 14, 2014 10:02 pm Post subject: |
|
|
Acolyte
Joined: 11 Feb 2014
Posts: 61
|
Hi smdavies99 and zpat
Thank you for comments.
I will rework with the requirement team to have the backend webservice changed to MQ.
Thanks. |
|
| 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
|
|
|
|
