TIBCO's JMS foolishness

I must admit, I am somewhat baffled by some of the strange things that ‘old school’ MOM (messaging-oriented middleware) vendors do. They often seem to operate in a bizarre world where it’s perfectly reasonable to treat developers like scum, as people who enjoy nothing more than an obtuse and obfuscated development process, and are fanatical about cryptic and unhelpful error messages.

This is understandable somewhat given their background. They deal with mainframe freaks, historically sex appeal has never been part of their message, and revamping that now just isn’t that high of a priority. Their customers would likely feel threatened and befuddled by this new sexuality anyway, preferring instead the ‘professionalism’ of a tedious boring run-of-the-mill type product.

Enter JMS, the potential for sexiness is suddenly within grasp. JMS allows those MOM vendors to be sexy to those who like that type of thing (JMS kids), and remain staid and plainjane to those who don’t (every other endpoint). Everyone wins! Nobody is threatened. The new kids feel they’re working on something cool, the old kids don’t feel threatened and upstaged by the newcomers. Through the wonders of a JMS layer on top of the old crap, you get them talking to one another like they’ve known each other for years. They can focus on the message format and its contents, and let the vendor worry about everything else. All good and well.

Except that one vendor that doesn’t seem to ‘get’ it is Tibco. Tibco’s JMS solution is a completely different product to their Rendezvous-based ActiveEnterprise crap. The latter has its own SDK (more on how horrific that is some other day), which is completely divorced from JMS. So if you have the old school guys and want to hire new kids who are JMS savvy, you have to go out and buy a whole separate product. Note, it isn’t an add-on, or an extra feature. It’s a whole separate product with its own broker, that does not integrate at all with the ‘main offering’. Well, that’s not entirely accurate, it is possible to set up topics to publish to or receive from Rendezvous equivelants, but there are a bunch of restrictions and it’s a royal pain in the ass. Your middleware group ends up having to support two MOM products that are for all intents and purposes doing the exact same job.

I don’t get it. I thought part of the coolness of JMS stems from the fact that you can get a standard-based API over a ‘traditional’ solution that allows you to talk to all sorts of different languages and platforms without knowing a thing about them. You just shoot our your message into the ether and magically it can be picked up by almost anything. As a vendor, what on earth is the advantage of a JMS solution that has little to nothing to do with your ‘old’ underlying messaging product?

13 Responses to “TIBCO's JMS foolishness”

  1. jb Says:

    Tibco and SeeBeyond are prime reasons why in-house EAI tools still rule the roost. These dinosaurs are a kludge. I’ve seen nothing perform EAI quickly except custom connectors. And while XML is arguably nicer than EDI, there still is a huge impedence mismatch between trading partners.

  2. JavaGeek Says:

    And webmethods is equally horrendous, imo. It is just a ‘hack’ of two or three companies gobbled together in a big slow dinosaur. Worse yet, for the next release it will come with JBoss integrated for EJB connectors.

  3. Anonymous Says:

    your rss feed is broke btw

  4. Gerald Bauer Says:

    > As a vendor, what on earth is the advantage of a
    > JMS solution that has little to nothing to do with
    > your ‘old’ underlying messaging product?

    Hani, how come that you as an outspoken open-source critic, don’t “get” it. Follow the money and you will see how everything starts to make sense.

  5. Gabriel Mihalache Says:

    Hani is NOT an “open-source critic”, he is an “open-source realist”.
    Open Source worshipping like yours is worse than 100% proprietary, IMHO.

  6. Jason Carreira Says:

    Ummm… maybe I missed something, but Hani is just a CRITIC. This post has nothing to do with opensource.

  7. Gerald Bauer Says:

    > Open Source worshipping like yours is worse than
    > 100% proprietary, IMHO.

    May I point out that I also sell commercial licenses and hold your breath closed-source, proprietary tools. I’m not an open source fanatic.

    > This post has nothing to do with opensource.

    Well, the point is TIBCO doesn’t want to interoperate and charge twice because they hope it brings in more money. If they had a modern service -oriented business model using open source the story would be much different.

  8. OS Says:

    > If they had a modern service -oriented business model
    > using open source the story would be much different.

    Yeah, less money, less profit. More adoration from the open source masses.

  9. Zohar Says:

    Enough already with this OS Bauerfest.

    Too the point :
    Rendezvous could never be the basis of a complete JMS implementation.

    You need a server based broker to do the p2p transactional stuff in any decent way.

    The topic based stuff ( pubsub ) is not only doable, we have actually written a (partial ) JMS binding to RV in house in about 3 days, and it happily works with MDB’s in AppServer X.

    The EJMS stuff is OK to use , and is certainly a breath of fresh air compared to that old mainframe staple MQSeries which is a major pain to use….

    However , as a Tibco customer, I could not agree more with your observations of Tibco.

    They have not been getting it for quite some time…

  10. Guilherme Says:

    Tibco really doesnt get it right with RV and Message Broker…
    Not only are your comments true, but Message Broker really sucks when it comes down to scalability and memory issues…

    And we still get to see some “Tibco RV Specialists” jobs around…..

  11. diprey Says:

    I am a TIBCO customer. I’m not associated with TIBCO in any way: I am a happy customer, and I must say…

    The benchmark was unfair, IMHO. I rather like E4JMS. I used it, I know it well. It’s a good product, finally (after a few iterations, ahem….) E4JMS is NOT built upon Rendez-Vous, rather on AE.

    Why won’t you learn how it works before you leap. I hate TIBCO lawyers kicking in, myself. I do realize that one’s benchmarks depend on the app specifics. IMHO, the bashing of E4JMS was unwarranted.

    Gimme a break, will ya? Shut up that big mouth: take time to learn. May I send you the docs?

  12. Paul Brown Says:

    I might be wrong, but I’d guess that the JMS seems like a separate product because… it is. I believe that TIBCO’s JMS came from their acquisition of Talarian in early 2002; see, among others:

    http://www.sdtimes.com/cols/middlewatch_048.htm

  13. Baloo Narayanan Says:

    That isn’t all that true about Tibco’s E4JMS. I have myself deployed it in a real-time solution and it works fine till now.

    I had that doubt of TIBCO’s JMS using RV internally. It is actually not so. TIBCO’s JMS doesn’t use RV for messaging.

    - baloo

Leave a Reply