Comments on: The Messaging Way : MSMQ & JMS http://tssblog.blogs.techtarget.com/2007/03/15/the-messaging-way-msmq-jms/ Sat, 07 Nov 2009 20:19:41 +0000 http://wordpress.org/?v=wordpress-mu-1.0 by: Old -timer http://tssblog.blogs.techtarget.com/2007/03/15/the-messaging-way-msmq-jms/#comment-996 Tue, 20 Nov 2007 21:14:22 +0000 http://tssblog.blogs.techtarget.com/2007/03/15/the-messaging-way-msmq-jms/#comment-996 The assertion that MSMQ is ubiquitous is simply nonsense. It only runs on Windows OS flavours. JMS implementations on the other hand run on any OS for which there's a Java Virtual Machine. Noter however that no two JMS implementations have to be able to interoperate. That's just missing from the spec. Also more ubiquitous is IBM's WebSphere MQ. It runs on something over 40 different operating systems, including all the Windows ones, most Linux, many Unix and several mainframes. The assertion that MSMQ is ubiquitous is simply nonsense. It only runs on Windows OS flavours. JMS implementations on the other hand run on any OS for which there’s a Java Virtual Machine. Noter however that no two JMS implementations have to be able to interoperate. That’s just missing from the spec. Also more ubiquitous is IBM’s WebSphere MQ. It runs on something over 40 different operating systems, including all the Windows ones, most Linux, many Unix and several mainframes.

]]> by: rogerv http://tssblog.blogs.techtarget.com/2007/03/15/the-messaging-way-msmq-jms/#comment-442 Tue, 24 Apr 2007 06:14:00 +0000 http://tssblog.blogs.techtarget.com/2007/03/15/the-messaging-way-msmq-jms/#comment-442 With a JMS implementation, such as Tibco EMS, one has a far superior interoperability story than what was related here for MSMQ. My production systems comprise C/C++ clients, .NET clients, WinCE .NET Compact Framework clients, and of course Java clients. We bridge to Oracle AQ and IBM MQSeries. My own developers build systems that are .NET on the client-side and Java in the middle-tier, but another product group at my company that uses .NET exclusively for all end-points, still went with Tibco EMS instead of MSMQ. A lot has to do with the superiority of JMS spec, but Tibco EMS proved to be a very excellent implementation relative to MSMQ. Tibco knows messaging much more deeply than Microsoft does. With a JMS implementation, such as Tibco EMS, one has a far superior interoperability story than what was related here for MSMQ.

My production systems comprise C/C++ clients, .NET clients, WinCE .NET Compact Framework clients, and of course Java clients. We bridge to Oracle AQ and IBM MQSeries.

My own developers build systems that are .NET on the client-side and Java in the middle-tier, but another product group at my company that uses .NET exclusively for all end-points, still went with Tibco EMS instead of MSMQ.

A lot has to do with the superiority of JMS spec, but Tibco EMS proved to be a very excellent implementation relative to MSMQ. Tibco knows messaging much more deeply than Microsoft does.

]]> by: Marcel http://tssblog.blogs.techtarget.com/2007/03/15/the-messaging-way-msmq-jms/#comment-441 Fri, 30 Mar 2007 11:07:53 +0000 http://tssblog.blogs.techtarget.com/2007/03/15/the-messaging-way-msmq-jms/#comment-441 This article is more a tutorial about MSMQ but less an article about interoperability. Having a robust JNI access is not so trivial, features like reconnect polling, client side queuing etc need to be addressed. Using real inter operable MOMs like xmlBlaster (http://www.xmlBlaster.org) support many OS and programming languages (C,C++,C#,Java,PHP,Python,Javascript etc) out of the box (having said that as an xmlBlaster developer :-). Integrating mobile phones with Symbian OS or Windows Mobile/Smartphone devices with highest streaming-compressed communication to server side HPUX/Linux/Windows boxes and back end servers transparently over fancy protocols like SSH encrypted or CORBA or email or http tunnels are real use cases to solve with MOMs. regards Marcel This article is more a tutorial about MSMQ but less an
article about interoperability.

Having a robust JNI access is not so trivial, features like
reconnect polling, client side queuing etc need to be addressed.

Using real inter operable MOMs like xmlBlaster (http://www.xmlBlaster.org) support many OS and programming languages (C,C++,C#,Java,PHP,Python,Javascript etc) out of the box (having said that as an xmlBlaster developer :-).

Integrating mobile phones with Symbian OS or Windows Mobile/Smartphone devices with highest streaming-compressed communication to server side HPUX/Linux/Windows boxes and back end servers transparently over fancy protocols like SSH encrypted or CORBA or email or http tunnels are real use cases to solve with MOMs.

regards
Marcel

]]>