Tag Archives: MQ

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.

Advertisements

What’s up with MQ?

I haven’t blogged about my core work for a while, so it’s probably about time. This is a bit of a round-up of some of the things I’ve observed happening around in the MQ space lately.

WebSphere MQ stuff

It’s a year of anniversaries. Apart from IBM Hursley hitting 50 (reminding me that I’ve yet to post my Spitfire photos from the celebratory open day weekend), IBM Warwick is 30 and WebSphere is celebrating 10 years. WebSphere MQ was formerly called MQSeries, of course, and has been around a few years longer than the “parent” brand, with a 15th birthday this year.

I’m sure the numbering is merely a coincidence, but there’s a good article on IBM developerWorks entitled The top 15 WebSphere MQ best practices.

WMQ reached version 7 this year. I had some very positive experiences with the alpha version of the product last year, although I’ve not yet had a play with the GA release. The new HTTP support is particularly interesting from a Web 2.0 perspective, and I keep meaning to build some demos around that that feature.

In related news, WebSphere MQ now has a Twitter account, so if you want to catch the latest news and announcements you might want to follow that.

I picked that last nugget up from my friend and US colleague T.Rob Wyatt, who has been blogging for a while now… T.Rob is an expert who is absolutely worth following if you work in the MQ space. He’s also pointed out that there’s a new blog for IBM’s new Managed File Transfer product which was announced last month.

Other messaging-related notes

For some non-IBM messaging middleware updates, just to note that 0MQ (ZeroMQ) sounds intriguing (via Matt Perrins, who notes that it is nothing to do with Project Zero). I’ve done a lot of work with clients in the financial sector in particular, so I’ll be interested to see how this develops. One of the nice things about my other “pet” product, WebSphere Message Broker, is that it sits in the sweet spot of connectivity between different transports and protocols, so I guess I’ll be looking at how to make things talk to one another if 0MQ takes off.

Large files and WebSphere technologies

My friend and colleague Ben Thompson has been writing again – his latest developerWorks article Handling large files with WebSphere Transformation Extender has just been published. It describes a useful technique where a WTX map can be used to split a large file into multiple MQ messages each containing a single transaction, using the group header fields to keep the transactions together. Worth a read if you are interesting in processing these kinds of files.

Hostnames and MQ Explorer

I haven’t blogged about my day job for a while, but an interesting technical issue came up today.

A customer was trying to add a new queue manager to MQ Explorer. However, they could not enter the hostname into the relevant field in the GUI.

It turned out that the hostname had_an_underscore character in it. The entry field in MQ Explorer prevents the user from entering this character.

This restriction makes sense. As per several RFCs (RFC952, RFC1035, RFC1178) and the Wikipedia entry on hostnames, underscores_are_not_valid characters in hostnames.

… hostname labels can only be made up of the ASCII letters ‘a’ through ‘z’ (case-insensitive), the digits ‘0’ through ‘9’, and the hyphen. Labels can not start nor end with a hyphen. Special characters other than the hyphen (and the dot between labels) are not allowed, although they are sometimes used anyway. Underscore characters are commonly used by Windows systems but according to RFC 952 they are not allowed…

So, now you know.

A solution could be to reference the IP address of the queue manager in question, or possibly to alias the hostname in the hosts file so that it does not contain underscores. Note that I have not tested the latter solution, but it should work.