| Author |
Message
|
| fatherjack |
 Posted: Fri Jan 07, 2011 3:59 pm Post subject: The over-use of Message Brokers |
 |
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
In my role as retired, ex-alcoholic priest I often have time to consider, other than ecumenical matters, the need for integration brokers such as Websphere Message Broker.
For financial reasons, in my role as a Websphere Message Broker / Integration Consultant my consideration lasts a mere few nano seconds.
However, I have seen many projects use integration technologies like WMB simply because "thats our standard integration solution" or because "we need to do data transformation and that's what WMB does".
When I started doing integration for a living there were lots of good reasons for using message broker technologies (even though the technologies either didn't even exist or were crap) e.g. App 1 does not support App 2's interface technolgy / protocol, we can't change App1 cos it's not ours or we've lost the source or we just don't want to, our business process improvement initiatives need more real time integration and some process orchestration etc.
Today, I'm not so sure all of these arguments still stand up.
Most platforms support most technologies/protocols these days. Why, I even think the mainframe can do web services. And why not write your transformations in COBOL on the mainframe.
I'm not saying there's no place for tools like WMB, just that we are maybe using them for the wrong reasons e.g. it keeps us in a job and industry analysts say they are a good thing or simply because they are there. Are we just using the broker cos its there and it keeps us in a job. Praise be to the lord. I'm not sure anymore.
Thoughts on the added value of integration brokers and whether there's an over-reliance or unnecessary use are welcomed.
Now MQ is a different matter. Heaven (or was it IBM) gave us assured, once and once only delivery. I'm off to bed now, with my bottle of scotch / whisky / cup of tea, knowing my message has got through.
Bless you all.
Jack.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Jan 07, 2011 4:16 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Most platforms support most technologies/protocols these days. Why, I even think the mainframe can do web services. And why not write your transformations in COBOL on the mainframe. |
Cheap shot. Of course you know that z/OS does C, Java, JMS, all that stuff, too.
Back to The Broker... For me (and my clients), it's main selling feature is that it offers a consistent platform for mediation.
It may be more efficient, or initially cheaper, to write or buy COBOL, C, Java, OCO or whatever, solutions; but then you end up with a fleet of stand-alone solutions that will likely need tweaking or other support at some future date.
The Broker is a strategic direction, more than just a technology choice. Choosing between Oracle and DB2 is tactical. Deciding to implement a database is strategic.
_________________
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 |
|
|
| fatherjack |
| Posted: Fri Jan 07, 2011 4:41 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| bruce2359 wrote: |
| Cheap shot. Of course you know that z/OS does C, Java, JMS, all that stuff, too. |
No. Not intended as a cheap shot. I've done 30+ years on IBM and other mainframes. Just tongue in cheek. I love the mainframe. In fact if we'd stuck to 3270s and mainframes we wouldn't have the integration challenges we do today.
| bruce2359 wrote: |
Back to The Broker... For me (and my clients), it's main selling feature is that it offers a consistent platform for mediation.
It may be more efficient, or initially cheaper, to write or buy COBOL, C, Java, OCO or whatever, solutions; but then you end up with a fleet of stand-alone solutions that will likely need tweaking or other support at some future date.
The Broker is a strategic direction, more than just a technology choice. Choosing between Oracle and DB2 is tactical. Deciding to implement a database is strategic. |
Thanks. This is exactly what I'm lookng for. Your reasons for using WMB or other integration broker products. And whether the cost of tweaking stand-alone solutions outweighs the cost of heavyweight software such as WMB.
More please.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 07, 2011 4:55 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| In fact if we'd stuck to 3270s and mainframes... |
IBM (and us) blew it big time by calling 3270's (and 5250's) dumb terminals. If only we'd thought of calling them thin-clients (which they were).
IBM blew it, too, by refusing to rebrand mainframes to servers when everyone (according to the trade papers) was getting off mainframes to go to client-server. It took IBM more than a decade to catch on.
_________________
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 |
|
|
| fatherjack |
| Posted: Fri Jan 07, 2011 5:33 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| bruce2359 wrote: |
| Quote: |
| In fact if we'd stuck to 3270s and mainframes... |
IBM (and us) blew it big time by calling 3270's (and 5250's) dumb terminals. If only we'd thought of calling them thin-clients (which they were).
IBM blew it, too, by refusing to rebrand mainframes to servers when everyone (according to the trade papers) was getting off mainframes to go to client-server. It took IBM more than a decade to catch on. |
Hopefully this won't drag us too far off the topic of the overuse of message brokers but.....
Hindsight is a wonderful thing. Didn't Larry Ellison, Oracle, talk about thin clients (Net-PCs?) years ago but it was poo-poo'd by Microsoft and never took off. Now everyone is using the internet and talking about SaaS, Software As A Service.
Ah! Well!
Back to the overuse of message broker technologies ....................
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jan 07, 2011 5:53 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You've got it wrong, and backwards.
Too many people are trying to do anything outside of Broker.
Why do you need an App Server, or a .NET container, when you can just use ESQL or a Mapping node? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 07, 2011 8:59 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I notice that you seem to be somewhat focused on the transformation aspect of the broker...
I believe there is one strategic view that should not be forgotten. With WMB and the MQ network you achieve a complete decoupling of the client and server processes.
This means that at any point you can change the transformation and switch out the server process without the client having to be aware... This is a strategic direction that allows you to ultimately go to a server/service plug and play concept.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Jan 08, 2011 11:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
You've got it wrong, and backwards.
Too many people are trying to do anything outside of Broker.
Why do you need an App Server, or a .NET container, when you can just use ESQL or a Mapping node? |
I have an entire team using .NET, XSLT and web services because "WMB is too heavy for the simple transformation we want to do". They're only using WMQ because it's the only way into or out of the mainframe on this site, and only for that part of the journey. The rest of their inter-solution communication is done with TCP/IP.
Interestingly, one of the web services they're calling is a print function that some of our WMB flows call. They complained to the guy who runs it that his WSDL was too large, complex and needed information their service didn't currently hold. His suggestion was to pass their data into WMB and get us to do the call, as we've already solved the missing information issue and have existing code that builds the SOAP. "Oh no", they replied, "it's just a simple print we want. There's no point using WMB for that. You just have to provide a new, smaller WSDL for us".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jan 08, 2011 4:26 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| This means that at any point you can change the transformation and switch out the server process without the client having to be aware... This is a strategic direction that allows you to ultimately go to a server/service plug and play concept. |
 I smile when I hear this argument. How often does that really happen? About as often as you change your message infrastructure and your JMS apps don't have to change "anything" (re: "JMS is sooooo cool cause you can swap message providers and not have to change anything!")
If you stick WMB between App A and App B and App B changes its true that App A does not have to change at all. But the work still has to be done somewhere to accommodate the change! You just moved the work from App A changing to WMB changing.
If the change can be made more easily in WMB you come out ahead. If.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jan 08, 2011 11:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I was more thinking that you had WMB between appA and appB and you switch appB to a different platform. You may still have to do changes to accommodate the switch but this can be completely transparent to appA.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| fatherjack |
| Posted: Sun Jan 09, 2011 1:02 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| PeterPotkay wrote: |
If you stick WMB between App A and App B and App B changes its true that App A does not have to change at all. But the work still has to be done somewhere to accommodate the change! You just moved the work from App A changing to WMB changing.
If the change can be made more easily in WMB you come out ahead. If. |
Yes. This is exactly the sort of thing I've seen. My new App can't handle packed decimal so lets put the broker in between. It'll do the unpack and EBCDIC to ASCII and vice versa and Bob's your uncle. Rather than a new COBOL copybook and a MOVE CORRESPONDING in the mainframe program.
That said I do agree with earlier posts about trying to use other tools to do what Broker does best.
We all should be trying to use the right tool for the job but lots of us don't seem to have the right processes or decision criteria or whatever to make this happen.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Jan 09, 2011 4:41 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fatherjack wrote: |
| ...lots of us don't seem to have the right processes or decision criteria... |
I'd slightly disagree with that - we (generally) do, it's management/budget holders that don't.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Mon Jan 10, 2011 1:22 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| exerk wrote: |
| fatherjack wrote: |
| ...lots of us don't seem to have the right processes or decision criteria... |
I'd slightly disagree with that - we (generally) do, it's management/budget holders that don't. |
Fair comment.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jan 10, 2011 7:42 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
I like the nuances of today's vernacular: Service Oriented Architecture and Enterprise Service Bus. It sounds sexy and deserves budget approval.
I see the value of WMB as a multiplication exercise over time. At first, there is not much to be gained from an ESB. The value of the ESB increases exponentially over time as more and more connections are added. Whereas in past effort, you had to code inputs and outputs times two (one for platform A and one for platform B) for the application to communicate, now it is possible that one or the other or both is already coded. So all that is needed is some tweaking to the routing.
While your point about half a dozen of one or six of the other holds true at the beginning, the bang-for-the-buck comes more and more over time. I find ESB is in the same cultural place Java was two decades ago. Everyone liked C or C++ better then because they didn't see the value of Java and Java was slooooowww. But today, things are different for Java. I expect in two decades from now, WMB will be in more favorable light, just like Java is today.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
