| Author |
Message
|
| chauhangaurav |
 Posted: Wed May 15, 2013 8:33 am Post subject: Help required to design flows for message decomposition |
 |
|
Novice
Joined: 15 May 2013
Posts: 11
|
Hi ,
I have to design one MB service for following scenario.please suggest me appropirate design pattern for same.
Mb service has to take input and send to downstream system.now main input has to decomposed into several parts.it may be 1,2 and upto 7 max depending upon the case
Now flow has to send first decomposed & transformed message to down stream systemaand waits for the reply.now after successfull reply,it has to send second decomposed & transformed message from the original message and send to downstream ,waits for reply. and so on sending next messages.
So my first doubt is this type of design pattern will be possivle in message broker because for this long running process,we have to maintain the original request.and as per esb concepts,MB is stateless esb layer and very tedious to maintain long running message staTE.
Plesae suggest me possible design pattern for above scenario if there is any. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed May 15, 2013 8:50 am Post subject: Re: Help required to design flows for message decomposition |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| chauhangaurav wrote: |
| Plesae suggest me possible design pattern for above scenario if there is any. |
Possible designs include (but are not limited to):
- use the Aggreation fan-in / fan-out
- use a Collector
- pass the original message as part of the downstream request and perform the processing asyncronously
- if the second & subsequent messages do not rely on the reply (as is implied in your post) simply send them downstream and handle as normal request / replies.
Other and possibly better solutions are undoubtably possible.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| chauhangaurav |
| Posted: Wed May 15, 2013 7:29 pm Post subject: |
|
|
Novice
Joined: 15 May 2013
Posts: 11
|
Hi,
Aggregation are mailnyl used to to send same request to multiple system and built the one single reply (fan-in) from multiple system.#
but here requirement is sending original message one by one to same same sytem and take thier reply. after getting first reply then we have to send decomposed message from original message and so on same scenario.
i dont think aggrergate nodes will help us.
same case with collector node....as we dont need to collect multiple inputs.
we have to deal with only single input and output one time...but all these in seuential manner.
its same case like WPS do with state machine. |
|
| Back to top |
|
|
| chauhangaurav |
| Posted: Wed May 15, 2013 7:41 pm Post subject: |
|
|
Novice
Joined: 15 May 2013
Posts: 11
|
Requirement is like:
MB Service Downstream system
original msg------>
1st msg------req--------->
<------rep---------
2nd msg--------req------->
<------rep--------
and this sequence is goin on..... each decomposed message has to be transformed from original message ...next message is only sent to downstream sytem when reply of first message will be recieved. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 16, 2013 4:53 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| chauhangaurav wrote: |
Requirement is like:
MB Service Downstream system
original msg------>
1st msg------req--------->
<------rep---------
2nd msg--------req------->
<------rep--------
and this sequence is goin on..... each decomposed message has to be transformed from original message ...next message is only sent to downstream sytem when reply of first message will be recieved. |
Why? There is nothing in the next message referring to contents of the previous reply (each decomposed....) right?
So making all the calls in parallel under the aggregation pattern will likely save you quite some time.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 16, 2013 5:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| chauhangaurav wrote: |
| next message is only sent to downstream sytem when reply of first message will be recieved. |
What's the implication of the reply to the next message down? Is the content of reply included in the second message request or is it just a sequencing thing? If sequence, then why are the messages sequenced like this?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| chauhangaurav |
| Posted: Thu May 16, 2013 6:26 am Post subject: |
|
|
Novice
Joined: 15 May 2013
Posts: 11
|
| Reply of first message has not to be included in next request.if teply is success then we gave to make another message transformed from original request in next sequence and so on.. just like the same scenario which wps state machine di..decomposition of message and sending next message after successful reply |
|
| Back to top |
|
|
| chauhangaurav |
| Posted: Thu May 16, 2013 6:31 am Post subject: |
|
|
Novice
Joined: 15 May 2013
Posts: 11
|
| I can not make paralle calls with aggregation.becsiuse I have to check thr reply of first call..if reply is success,only then next message has to send...so I doubt that aggregation will work here..because aggregation is for paralle call and to be formed commmon reply ,ollecting from all system calls |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 16, 2013 6:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| chauhangaurav wrote: |
| I have to check thr reply of first call..if reply is success,only then next message has to send... |
Ok that's the key quetion you need to answer for us. Why is it significant that the first request must be successful before the second request is made? An answer of "because we currently do it with a WPS state engine doing decomposition and we're migrating to WMB" is not acceptable.
| chauhangaurav wrote: |
| so I doubt that aggregation will work here..because aggregation is for paralle call and to be formed commmon reply ,ollecting from all system calls |
I doubt it too. Aggregation is not suitable for what you're describing. We now need to determine what is.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| chauhangaurav |
| Posted: Thu May 16, 2013 7:17 am Post subject: |
|
|
Novice
Joined: 15 May 2013
Posts: 11
|
With the use of WPS ,this decomposition requirment can easily met..and with use of mb we can do transformation...
But here due to lack of resources and budget,they are not supposed to introduced wps tool with wmb.
Hence looking for design pattern for this scenario only in wmb. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 16, 2013 7:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| chauhangaurav wrote: |
| Hence looking for design pattern for this scenario only in wmb. |
Yes, but why this design pattern? If you took me on and I designed a solution which did all of the requests without waiting for any of the replies but simply correlated the correct reply with the correct request, what would be wrong with that?
Decomposition is easy with WMB. Why do you need the state engine part?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu May 16, 2013 7:35 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
But the requirement is... to implement a state machine 
There's an easy asychronous way to implement this. If you take a look at your diagram above it's quite obvious, even.
Exctract the first message, put it in the request queue and capture the newly created message id.
Put the unprocessed part of the input message in a staging queue, using the captured message id.
Write another flow to process the reply messages.
When a reply comes, use MQGet to read the corresponding message from the staging queue. Get the message with msgId matching the correlId of the reply message. (it that is the way the server correlates replies with requests).
Extract the next message and repeat the procedure untill you have processed all parts of the original input message. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 16, 2013 7:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Esa wrote: |
| But the requirement is... to implement a state machine |
I know, but I continue to bang away at this. I know the requirement to build a state machine comes from the requirement to build a state machine, but I try to make the world a better place.
| Esa wrote: |
Write another flow to process the reply messages.
When a reply comes, use MQGet to read the corresponding message from the staging queue. Get the message with msgId matching the correlId of the reply message. (it that is the way the server correlates replies with requests).
Extract the next message and repeat the procedure untill you have processed all parts of the original input message. |
My original response suggested the use of a Collector node, which will pick up the original messge and it's matching reply by correl id without code and supply both to the downstream flow you suggest. The OP didn't like this & seems determined to create a WPS state engine.
IMHO this is better when you have 1-n possible itterations as it removes the need for an MQGet and removes the tempation to put it in a loop....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| chauhangaurav |
| Posted: Thu May 16, 2013 7:53 am Post subject: |
|
|
Novice
Joined: 15 May 2013
Posts: 11
|
I also tried with the same logic using.mqget to extract original message in reply flow ..but stuck in part..when after extracting original message and sending original msg back to previous request flow from where first part of msg is sent,,unable to decide on which factor or flag condiion it will deterimine to form 2nd transformed msg .bcos after entering to same,it should not go towards first decomposed transformed logic..some comdition shd be dere to route towards second transformation logic.
Or instead of routing original msg back to previous same req flow from where first msg is generated,,i would make seperate flow to generate second msh.
By doing so,it will increase number of req flows..[/quote] |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 16, 2013 8:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| chauhangaurav wrote: |
I also tried with the same logic using.mqget to extract original message in reply flow ..but stuck in part..when after extracting original message and sending original msg back to previous request flow from where first part of msg is sent,,unable to decide on which factor or flag condiion it will deterimine to form 2nd transformed msg .bcos after entering to same,it should not go towards first decomposed transformed logic..some comdition shd be dere to route towards second transformation logic.
Or instead of routing original msg back to previous same req flow from where first msg is generated,,i would make seperate flow to generate second msh.
By doing so,it will increase number of req flows.. |
You've still not answered why you need to sequence the requests this way and go to all this trouble, but I suspect you never will because the requirement is the requirement and no mortal man dare challenge the requirement save that the gods become enraged.
So why not do this:
- Original message goes through Flow 1, extracts the first message, formulates the request, sends it, removes that stanza from the XML and puts the resulting XML (with requests 2-n still in it) on a staging queue
- Reply queue consumes the reply and either gets the staged message with an MQGet or has a Collector node do it. The reply message is processed however the reply message is processed, the staged message (with requests 2-n in it but with request 2 now in the first position) is placed on the original queue for Flow 1 to process.
- Flow 1 processes the message, extracts the first message not realising it used to be the second message and the loop continues.
- When Flow 1 receives a message with no requests in it, it exits happy in the knowledge of a job well done. If you need a copy of the original message sent on someplace when all this is finished, store a separate copy of it in a 2nd queue and have Flow 1 forward it when it gets an empty request and exits as I indicate above.
Simple. And I still don't know why you'd bother.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
