WebSphere MQ 7.1 is out – here’s why it is cool…

I’ve been fairly quiet about the latest software from the Hursley lab here on my blog – although, over the past few weeks since the announcements back at the start of October during the European WebSphere Technical Conference, I’ve definitely been speaking about WebSphere MQ v7.1 and WebSphere Message Broker v8.0 – two exciting product releases.

I’m going to spend this post talking about WMQ 7.1, which became available in electronic download form for the distributed platforms last Friday (z/OS will follow shortly). I’ll return to talk about all the (über)-coolness in Message Broker a little closer to the release date for that product.

So what is the big deal in this release?

It brings parallel / multi-version install

From version 7.1 onwards, there is now the capability to install more than one copy of WMQ on a system, for Windows and UNIX platforms. This includes installing alongside WMQ v7.0.1.6 (fixpack 6 on v7.0.1, the minimum level for multi-version install to work) – you can have one copy of v7.0.1.6, and multiple copies of 7.1, for example – and future versions will also be able to be installed in parallel, should the need arise. This should make migration and testing simpler. Applications can now point to their “own” install of WMQ if required. The GSKit installation, which provides some of the security functions for the queue manager, now gets installed “inside” the main installation as well, to make the whole thing more self-contained, and potentially easier to embed into other solutions if needed.

Here’s a teaser image from a Windows system that my colleague “mqjeff” sent me earlier today 🙂 he has 7.0.1.6 and 7.1 on the same machine.

It’s (even more) secure

WebSphere MQ has always had a number of strong security capabilities, including SSL for channel authentication and encryption, and fine-grained access control of queue manager objects via the Object Authority Manager. It has also been possible to add transparent, per-message / per-queue / per-policy on-disk encryption and signing of message data via the Advanced Message Security feature. In v7.1, a renewed focus on end-to-end security adds the ability to authorise on a per-IP/user connection basis, as well as adding more crypto algorithms and additional authorisation options, and making much more of that security function available via the MQSC administration tool. T-Rob has a much more complete post about these changes so I won’t go into any more detail here.

It runs better, on bigger systems

Bigger systems… like the z196 mainframes? Well, that’s one example, yes, but WMQ v7.1 has been more optimised for big and multicore systems in general. On the mainframe, there are a bunch of great enhancements such as increased resilience in dealing with shared queues in a coupling facility, and the introduction of Shared Message Data Sets (SMDS) to significantly improve performance there as well. Let’s just say that the performance numbers for z/OS are looking really, really good… which brings me on to…

It continues to push the performance envelope

A major focus on performance in the v7.1 cycle has produced some fantastic results, and when the performance reports appear (as SupportPacs, within the next few weeks), you’ll see the “fastest WMQ ever”. This theme runs throughout everything: not just the base runtime messaging, but also things like making the WMQ Explorer tooling significantly snappier to operate as well (oh, and that’s now 60% smaller, and more sleek!)

There is also a new option for publish/subscribe applications – the ability to publish on a topic via multicast. This re-uses some of the technology from the WebSphere MQ Low Latency product so that it can run very fast. After the initial application startup, it means that applications can also operate when the queue manager is not available.

It adds Telemetry to the base install

No surprise that I’d highlight this one (it is also an important part of the overall story, per the next heading!) – I’ve been talking about the IBM implementation of MQTT, the open protocol which is being standardised and which it was just-announced will be part of the Eclipse Paho M2M project, for the past couple of years.

In WMQ v7.1, there is no longer a separate installation to run in order to add this support. On the platforms where the Telemetry feature is supported – Windows, Linux IA64, and (new in v7.1) AIX – this is now an optional part of the base installation. That means it is very easy to try out. Oh, and as well as being integrated with WMQ Explorer, the full range of Telemetry objects can now also be administered via the MQSC command line.

It brings the family together

This is a big one, in my opinion. I’ve mentioned that WMQ “base” can now interoperate with WMQLLM via the multicast publish-and-subscribe support; and the WMQ Telemetry functionality is “in the box” as part of the installer on the relevant platforms.

Why do these things that matter? Well, as I mentioned in my recent MQTT FAQ, something that IBM has observed over a number of years of building and delivering production-ready messaging middleware is that one size does not fit all. There’s the fundamental transactional messaging backbone (WMQ base) which needs to be solid, reliable, and easy to administer through comprehensive scripted and graphical tools… but beyond that, there are some additional qualities of service that need to be considered. There’s the very high speed, low latency use case which may be very specialised (WMQLLM), and there’s the need to deal with small and constrained devices and less-reliable networks (WMQ Telemetry / MQTT). Of course, you may also want to perform file transfer over that infrastructure (WMQ File Transfer Edition), secure your messaging (WMQ AMS), or route and transform your data and connect with “foreign” systems via different protocols (WebSphere Message Broker). I’ve been talking about this as part of IBM’s Messaging Vision for a number of years and it is really showing through in this release of WebSphere MQ. It’s a complete story.

It addresses many “papercuts”

On top of all of that… the team has really tried to address many of the common papercut issues, by which I mean the gotchas, annoyances, and the “wouldn’t it be so much better if….”s. Things like, gosh, I wish I knew what version of WMQ that client is using to connect to me? (yep, you can find out now).  How about “bind on group” for messages in a cluster? The ability to backup / dump and restore the configuration of a queue manager without needing to use a SupportPac? There’s a real sense of “fit and finish”, and I believe that shows that the development team have been listening to feedback and making the tweaks that users have been asking for where possible.

So – all-in-all, there’s a lot in this release that makes it worth a look, either from the perspective of users who are looking at an upgrade to gain performance, security and usability benefits; or for those looking for a solid, dependable messaging platform which can support modern applications. There’s a lot of excitement and innovation going on in the “traditional Message Oriented Middleware” space at the moment and WMQ and the related protocols like MQTT are right at the heart of those trends.

To learn more about the features I’ve talked about, and some that I haven’t, check out the online Infocenter. You can also check out the “What’s New in WMQ v7.1” presentation from the WebSphere Technical Conference, via T-Rob’s blog.