| Author |
Message
|
| nonstopmark |
 Posted: Thu Aug 06, 2009 1:44 am Post subject: Cloning... |
 |
|
Newbie
Joined: 24 Nov 2008
Posts: 7
|
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Aug 06, 2009 6:36 am Post subject: Re: The answers so far (abridged)... |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
With the obvious point this is supplied as a sample code and isn't intended to be used unmodified (or at least unreviewed) in a production environment.
Everyone knew that, I'm just underlining it. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 06, 2009 7:56 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
and I am stipulating again... this should not be an MQ function but some kind of ESB function... Without more context information this is pretty pointless.
Anything can be done to duplicate messages including message exits, distribution lists, and / or little user programs to pick them up and send them to multiple different destinations in the same UOW... available on all platforms...
The question here is really what should you do... and for that there is not enough context... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 06, 2009 8:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| Without more context information this is pretty pointless. |
In one of the other places that nonstopmark apparently duplicated this request message, a statement was made that it would serve to inform a talk that he was attempting or planning to give at some conference.
So to that purpose, it is sufficient to say "you can use an ESB, or an exit or a publication mechanism, or". |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Aug 06, 2009 9:03 am Post subject: Re: The answers so far (abridged)... |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Vitor wrote: |
With the obvious point this is supplied as a sample code and isn't intended to be used unmodified (or at least unreviewed) in a production environment.
Everyone knew that, I'm just underlining it. |
Yes, I made it bold when I first mentioned it  |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Aug 06, 2009 9:05 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| fjb_saper wrote: |
| and I am stipulating again... this should not be an MQ function but some kind of ESB function |
And ill say my bit again... just because you have MQ, this does not mean that you have / need an ESB! |
|
| Back to top |
|
|
| nonstopmark |
| Posted: Tue Aug 11, 2009 2:53 am Post subject: |
|
|
Newbie
Joined: 24 Nov 2008
Posts: 7
|
Thanks for the input guys... I think I have enough input for the PowerPoint... here is another response on a newsgroup...needless to say...it would be hard enough convincing a financial body to purchase a third-party product to track.... it would be impossible I think to convince them to buy something to add to MQ so that a third-party could track (unless their was a serious business case to solve)... this really was a discussion and focus group on what could be done in theory and what was likely in practice... the message below acts as good summary.... as regards my own view... I have been in IT 20+ years so I am not naive when it comes to what people will buy or configure at length to help a product do a job... especially during a recession... this thread was as much about judging the emotional reaction by experts in a Dragons Den type way... as such, no reaction was a bad one... just an indicator...Cheers..... 
It seems you are creating a lot of extra overhead in the messaging infrastructure in order to prove where a message has gone and how long it took to process. The onus of auditability should really be in each application, not tacked on top of infrastructure. ie. There should be sufficient logging in each application so that it can provide evidence that message X arrived at Y and took Z time to process.
MQ has assured delivery of messages, but it may not be able to meet SLA due to network outages or system degradation. Network or remote system outages can be detected by monitored transmission queues and channel status. Apps that are unable to process messages or keep up with the volume can be detected by monitoring queue depths.
All I can really add is that I have never seen your proposed technique implemented in real world app designs. You need to build auditability and accountability and transaction flow point monitoring into the main apps and not impose it on the messaging infrastructure. You could be creating a rod for your own back.
_________________
Blog: https://mark-whitfield.com/home/purchase-buy-project-management-tracking-templates/
Website: https://mark-whitfield.com |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 11, 2009 6:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Nice summary of the situation from the newsgroup. I couldn't have put it better myself....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
