| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| WESB vs WMB->is Broker going out of support in future |
« View previous topic :: View next topic » |
| Author |
Message
|
| JLRowe |
 Posted: Wed Mar 10, 2010 2:49 am Post subject: |
 |
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
| nathanw wrote: |
| dont forget as well that throughput on broker is immensly higher than WESB and other products, so if you are processing alot of data with alot of transformations Broker will chew it up and spit in out without breaking a sweat |
Sorry I would disagree. The last time I looked at XSLT transforms on broker, they relied on Java to do it, and furthermore had to parse/serialize between DOM and the native message tree. This is a whole magnitude of difference in performance.
Not sure if the v7 native message tree implements DOM, but this is only way you are going to get fast XSLT on broker. |
|
| Back to top |
|
 |
| gerdd |
| Posted: Mon Mar 07, 2011 3:46 am Post subject: |
|
|
Newbie
Joined: 04 Mar 2011
Posts: 8
|
| JLRowe wrote: |
| Sorry I would disagree. The last time I looked at XSLT transforms on broker, they relied on Java to do it, and furthermore had to parse/serialize between DOM and the native message tree. This is a whole magnitude of difference in performance. |
Well, if I read things like this I wonder if it wasn't a mistake that IBM put XSLT transforms into message broker. It opens them up to an argument about how good that implementation is. Never forget: It isn't there to be proud of, it's there to help people that have all these style sheets already and want to use them even though they aren't as fast as ESQL or mapping. But they have improved in V7, and if you don't use them where they are totally inappropriate they should be okay.
A couple of points here: IBM doesn't as a rule jazz up a piece of software massively - and enthusiastically, like they have been doing with message broker recently, showing no signs of stopping - for an upcoming funeral.
ICS was different in many ways. It was bought in and then discovered to have a number of expensive flaws (scalability being one of them.) It also overlapped significantly with WBI Server foundation and the budding Process Server/WESB functionality. And it wasn't going anywhere near BPEL, SOA, a proper ESB strategy and all that.
If you look at more than your own use case, there is a huge user base out there that has a clear need for message broker's (and MQ's) capabilities where WESB and the SI Bus would never do. The legacy connectivity, the vast range of supported legacy data formats, the ability to interact with dozens of non-JMS transport options directly from within a flow (which has huge performance benefits) - it all states clearly: "Here is the flagship ESB wiith a full house of capabilities."
Right. so, what do we have WESB for, then? One could also argue that DataPower, at least the XI50, is a full capabilities ESB and should displace both WESB and message broker. And I am sure there are use cases where that is the correct answer. But ...
DataPower - and mesasge broker - will never run inside a WAS. WESB will only run there. So, if your integration is 99% inside a WAS or two and you don't deal with "funny" formats or exotic transports, like LLM, MQTT, TCP/IP or even alien JMS implementations, then, WESB may be for you. If you work with Process Server a lot the SCA approach to building integration is already something you know well, so WESB is meeting you more than half way.
But the whole integration story is much, much bigger, and it includes lots of things we inherited from "Our Forefathers", and to integrate with them requires a somewhat different - and bigger - box of tools. Message Broker. And nowadays - with the JVM inside each execution group - it has grown into the ideal tool to bridge between the diverse world outside and the cosy Java-centric, fully standards compliant environment inside the WAS based integration tools. Isn't it significant, WPS and WESB run in WAS JVMs (Don't you just like Acronymitis?) but in Message Broker you run a JVM inside the broker (in fact, possibly many) - just for the things that need a java environment and those for which Java is "good enough" - - - Oops, I take that back! Of course, Java is good enough - and more. Once inside a JVM and under a just in time compiler, number crunching can be as efficient in Java as in C++ or - heaven forbid - in Assembler.
But there is an extra abstraction layer in that JVM, and if I run lots of I/O and networking (which is also I/O) and I have to cross all the abstraction layers in and out for every byte, then it does make a huge difference and we end up with the performance differences we see.
So, I never was quite clear on the intention of the original poster asking whether message broker would have a future. If you worried that your favourite piece of IBM middleware would suddenly disappear - don't! There have been attempts to argue WMQ/WMB away, but they have a big place in the hearts of those who need to get work done.
If you were trying to collect ammunition why you don't want to learn yet another technology - too bad, but this one should be a good investment. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 07, 2011 3:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Please don't reopen year old threads.
Much as your enthusiasm is appreciated. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
