Posts Tagged ‘middleware’

No waiting in these queues. IBM MQ V9 and the MQ Appliance M2001 delivers fast, reliable and secure message queuing

June 29, 2016


Recent weeks have been pretty busy on this blog, reflecting just how busy the MQ development team has been in bringing out new and updated offerings in MQ V9 and the MQ Appliance M2001 here and here. And of course in our cloud messaging options.

As both of these have been fairly full of new content I thought I would do just a short update to focus on a couple of key benefits which are specifically measurable in these 2 refreshed offerings. After all, a lot of the new and improved features can sometimes be hard to quantify in terms of the benefits they provide, but in each offering this time there are some easy to define benefits.

As you may have seen in my most recent update, the MQ Appliance M2001 added large capacity SSD storage which enables much faster throughput for persistent messages. These are the messages that get written to storage to ensure they are still available in the case of failure before the message has been successfully deliver to all consumers. At high rates of message throughput, there can be a lot of contention for access to storage with traditional hard drives. With the new MQ Appliance M2001, this potential bottleneck has been removed. You can now read the latest MQ Appliance M2001 performance report here which shows that the performance in those scenarios which saw large volumes of persistent messages sees improvement of up to 3.5 times the previous message rate.

Clearly this represents a significant improvement and given that persistent messages are used in those business critical situations where IBM MQ delivers so much value, it is a hugely important benefit.


In MQ V9 there were a number of enhancements but the one I specifically want to call out is, as part of the MQ Advanced package, the enhancement to MQ Advanced Message Security (MQ AMS). The change here was to add a new mode of operation – Confidentiality. This new mode changed the way in which the encryption operations are performed on the message contents (MQ AMS offers policy based encrypted message contents which ensures data at rest is protected in case of a security breach). The goal of this change was to continue to offer a strong level of security for the message contents without too big of an impact on the performance and throughput from the effects of the encryption used.

Now instead of new asymmetric keys being generated for every exchange, the feature can be configured to allow for reusable symmetric keys to be used after the initial generation of an asymmetric key. This still provides a very high level of security, but depending on the reuse count before a new asymmetric key is generated, can drastically cut the performance overhead. The benefits can see more than an order of magnitude increase in throughput. You can see a quick snap shot of some of the early results in Jon Rumsey’s blog here – which includes a small table showing performance improvements exceeding 10x gains. With everyone concerned about security these days, the ability to better protect your information and customer data with little performance impact has to be a good thing.


So what are you waiting for? With secure, reliable enterprise messaging for on-premise deployments, cloud deployments or physical appliances, there is no waiting with IBM MQ V9 or IBM MQ Appliance M2001.


[An interesting history of Wile E. Coyote here]


MQ in the Cloud – Your messaging ‘silver lining’

May 16, 2016

MQ clouds puttenham

As the senior product manager for a product like IBM MQ, I don’t just spend my day writing blogs – but frequently get questions from both colleagues and our many customers. And recently, one of the most common questions I get is whether MQ runs in the cloud.

The answer is “Yes” – that was easy wasn’t it.

However maybe there is some more information to share, to help describe the journey to cloud and to exploit the benefits provided by IBM MQ at every step, whether you are looking for enterprise grade business critical messaging in your private cloud infrastructure, in a public cloud (hosted or not) or a hybrid cloud spanning the combination of these.


Mostly the cloud environment that IBM customers I have been talking to are thinking about is best described as “Hybrid”. Almost all of our customers are starting to explore some aspects of the benefits of cloud – and what it means to them. But deployment, especially of business critical applications, is likely to happen in stages. Today many customers run virtually all application workload on-premise, but typically this will be in virtual machine environments. There is a shift to deploy selected workload in the cloud. Perhaps this might start with engagement or marketing applications, but these applications and the associated workload doesn’t run in isolation on the cloud but in conjunction with the rest of the enterprise running on-premise, or connecting to partners in the wider business ecosystem. Then as businesses shift some of their critical back office applications to cloud deployment options, the hybrid nature of infrastructure will increase.

Fundamental to the success of this change is the availability of reliable and secure connectivity to allow the safe and scalable exchange of information between applications independent of whether they are running together in the cloud, on-premise or any other combination.

How does IBM MQ work in this type of deployment? Well, as has been proven for more than 20 years, IBM MQ provides a way to exchange data in the form of messages between applications, systems and services and to do so reliably, securely, rapidly and simply. Messages are moved through MQ Queue Managers that can be deployed locally to the application – wherever that application may be, or remote from the application but accessed by MQ Clients bound to the application.

In pretty much any type of hybrid environment, MQ continues to be a critically useful middleware tool. Either the application running in the cloud environment can make use of the MQ Client to connect to a MQ Queue Manager running elsewhere (such as on-premise) or the MQ Queue Manager can itself be deployed in the cloud environment along with the application. And you might use your own tools to deploy MQ, or you could use tools such as Chef to deploy MQ. Other options for deployment include a MQ plug-in for IBM UrbanCode Deploy.

MQ offers support for running on IBM SoftLayer, Microsoft Azure, Amazon Web Services, and OpenStack cloud. It leverages a Bring Your Own Software License to make it simple for customers to choose where to deploy the IBM MQ license entitlements they may already have. For deployments of IBM MQ on SoftLayer you might choose to use the MQ Advanced pattern designed for IBM PureSystems which can run on the SoftLayer environment.

In addition to this deployment style, IBM recently confirmed MQ is supported to run in Docker environments which further extends where MQ might be deployed to meet customer needs, such as hosted PaaS environments like IBM Bluemix.


So basically for every cloud environment, or virtualised environment, or container, your business can continue to take advantage of the benefits of IBM MQ – whether by running MQ Queue Managers in the cloud environment, or continuing to run them on-premise (perhaps as the physical MQ Appliance), or in any hybrid combination.

So what are you waiting for? For MQ on cloud – the answer is yes.

*UPDATED to add link to the AWS example – see above*

IBM MQ V9 – A fast, secure, reliable and more agile MQ

April 19, 2016


Some of you reading this blog may recall the great athlete Ed Moses – who had a record 122 race winning streak in just about the hardest event – the 400M Hurdles. You need to be strong, fast, and agile just to compete, and to keep winning you need to be reliable. Well, this is how we view IBM MQ, especially with the latest release – IBM MQ V9. You may have seen a recent blogpost on here that had a Statement of Direction talking about a new way of delivering IBM MQ – one that provided a Long Term Support release, and a Continuous Delivery release. The aim of this model is to give customers more choice to select either highly stable releases with just fixes, or releases that benefitted from additional function in the fixpacks.

TRY IT: Click here to get a free trial of MQ

UPDATE: There is a FAQ on the new support model. Read it here.

On April 19th, IBM announced MQ V9 which is the first release that moves to this new more agile delivery model. As such at the initial release it delivers a small set of additional capabilities that will be available to all customers. Then subsequent mod-level updates will deliver even more updates to customers choosing the continuous delivery stream, but all customers moving to V9 will get the benefit of the new capabilities being delivered in this release.

As with previous releases of IBM MQ, customers have a lot of choice in where and how they may want to deploy this version. IBM supports deployment of MQ – and MQ Advanced pretty much on every commercial IT environment where business critical applications may be exchanging data reliably, securely, and at scale. This could be on-premise, deployed in cloud environments like IBM Softlayer, Microsoft Azure or Amazon AWS. IBM also supports virtualization with many customers deploying in VM images, and also in Docker containers, which can be deployed anywhere, including in IBM’s Bluemix platform. This flexibility enables customers to make use of enterprise messaging to support deployments on-premise, on cloud or in hybrid environments.

So what are the key new features of MQ V9 being delivered in this release? Well there are a number of them that are called out in the announcement letters – so you can read the MQ V9 distributed announcement letter here. And the MQ V9 z/OS MLC announcement letter here. And you can read the MQ V9 One Time Charge announcement letter here. But below I will call out a few of the features that I think will be most important to customers.

One of the features likely to be most interesting is a change to the MQ Client Channel Definition Table (CCDT), which is needed by the MQ Client application to provide the channel definitions needed to connect to the MQ Queue Manager. This file is created automatically and prior to MQ V9 needed to be distributed to the client application prior to use. The big change from this new release is that the CCDT can be a web addressable file instead of needing to be distributed out to every client, and to then need to do that with every change. By having a web addressable CCDT accessed by URI, then there are much lower administration needs, and also the MQ infrastructure can be much more dynamic as changes can be made centrally and take effect quickly and without application disruption.


The second big change to the new release of MQ is in MQ Advanced Message Security (MQ AMS). This feature, which is a priced extension to MQ (available either separately or as a part of MQ Advanced) provides policy based encryption at rest of the MQ message contents. By using this capability, businesses can be assured that their message contents can only be unencrypted and read by the targeted application destination, and there is no risk of exposure should any security breach take place which provides access to the system or storage where the MQ Queue Manager holds its queues. This privacy and integrity has been assured by the generation of asymmetric keys for every exchange between client and queue manager, which provides an extremely high level of security, but can introduce a high overhead in terms of the processor cost of the asymmetric key generation.

MQ AMS performance

With MQ V9, a new mode of operation is added to MQ AMS, called ‘Confidentiality’. In this mode there is an initial asymmetric key exchange then subsequent exchanges can reuse (to an extent that can be configured) a symmetric key. This still provides a high level of security and protection for the message content, but with a dramatically lower level of overhead in terms of encryption workload cost. IBM expects that due to the increasing importance of security and protecting systems and data from breaches, that this new feature of MQ AMS will help more customers protect their message contents and therefore their business and customer data. IBM expects to produce performance data for the new AMS configuration around the time that MQ V9 is generally available. But the early testing shows considerable improvement.


A further change for MQ AMS is the support of non-IBM JREs for use with MQ AMS. Previously applications written in Java that relied on a non-IBM JRE wouldn’t work with MQ AMS. In MQ V9 this has now changed so that suitable non-IBM JREs can be used, as well as IBM JREs, extending the ability of more customers to use MQ AMS.


There are a number of other new functions and capabilities available in MQ V9, such as updates to MQ Managed File Transfer capabilities – which are described in the announcement letter, and with the movement to a Continuous Delivery model customers should expect to see more capabilities being delivered in mod levels on top of MQ V9 in the future.


With the recent announcement of the End of Support for MQ V7.1 – announced here – along with the related end of support of the older separate versions of MQ FTE and MQ AMS, this latest release of MQ V9, along with the recent announcement of the update to the MQ Appliance provides customers with a strong set of choices of how to take advantage of the latest new releases as they plan to move off the older releases of MQ they may be using, keeping their deployment of MQ up to date and supported.

When you are taking advantage of the benefits of IBM MQ, you may not need to have to work as hard as Ed Moses did to be #1.

UPDATE: Mark Taylor has provided one of his highly useful videos detailing more of the new function in MQ V9. Watch it here.


Going faster by not moving – IBM Appliance M2001

April 19, 2016


Go faster. Faster. Move it! Or actually don’t move it. There are times when to go faster you need to stop moving. We are all familiar with the parable of the tortoise and the hare – where slow and steady wins the race. But what about not moving at all? Sometimes that makes you go much faster. And in the case of the latest update to the IBM MQ Appliance that is exactly what we are doing. Hopefully you already know about the MQ Appliance, which IBM releases early in 2015, and have continued to enhance since its release. You can read my original entry here, and the update at the end of last year here.


But today, April 19th, IBM is announcing another update to the MQ Appliance which not only provides additional functional enhancement, by allowing queue managers to both synchronously replicate for HA and also asynchronously replicate for DR, and adds support for the AMQP based MQ Light API, but also sees a small but important hardware update, making this a slightly refreshed model – the MQ Appliance M2001.


There are 2 key hardware changes in this model update. To help support the simultaneous HA and DR function, which would use both existing 10Gb network cards, the existing 2 port connection is being replaced with a 4 port connection, providing 4 of these 10GB network ports, enabling 2 to be used for HA and DR and ensuring 2 can be used by applications connecting to the appliance, as well as the existing 1Gb ports.


The second hardware change is the replacement of the existing pair of 1.2TB hard disk drives (HDD) with a pair of 3.2TB solid state drives (SSD). As well as the benefit of the greatly increased storage capacity, the major benefit of using SSDs is the increase in performance for persistent message throughput. The MQ Appliance is a highly capable system which can process a lot of MQ messages. However, when using persistent messaging, which needs to be written to disk, it is critical that the storage can keep pace with the high rate of workload being handled by the system and at times with heavy workloads the spinning disk simply couldn’t move fast enough. IBM has selected the latest generation of SSDs to provide large capacity, high performance for both reading and writing data at high rates, and also this latest generation of SSDs, even if the MQ Appliance is used heavily all day, every day, should last for the 5 year supported lifespan of the MQ Appliance. Therefore, this provides the payoff from our ‘tortoise and hare’ parable – with no moving parts in the SSDs, they can be a lot faster than spinning disks. Expect to see updated performance figures for the new MQ Appliance M2001 around the time of its availability (June 10th 2016), but early figures suggest for some workloads performance improvements of up to 3 times have been seen.


There continue to be 2 editions of the MQ Appliance – the M2001A, providing full access to all the processor cores, and the M2001B, which provides access only to a subset of the cores – with an upgrade available from the B to the A system if needed. For customers who may have already purchased the MQ Appliance M2000, please talk to your IBM sales rep to see whether your appliance can take advantage of an upgrade of the HDDs and network card if available.


With the improved HA and DR functions, the increased storage capacity and the greatly increased performance, IBM believes this enhanced MQ Appliance makes even more sense to be used as the heart of your IBM MQ deployment, or as a highly available pair of appliances that can be deployed anywhere you need MQ capability. And for customers who may be running older versions of MQ which were recently subject to an announcement of End of Support – as can be seen here – then the latest version of the IBM MQ Appliance can represent a very good deployment option which is then far simpler to deploy as well as to maintain.


By moving from spinning disks, to SSDs with no moving parts, you really can go faster by standing still.



Setting out markers for MQ’s road ahead

February 16, 2016


Working as the Offering Manager for IBM MQ and the IBM Messaging Portfolio, there are lots of parts of my day-to-day work that I can’t share on here until we announce it. However there are times when we can provide a small look ahead at what’s coming. This is called in IBM a “Statement of Direction”. And today IBM MQ has released a Statement of Direction for both IBM MQ and for the IBM MQ Appliance.

You can read the Statement of Direction here.
As you will see in reading it we are talking about a couple of important points. I will deal with the MQ Appliance statement first. As covered elsewhere in this blog, there has been a lot of interest in the MQ Appliance since we announced it at IBM InterConnect 2015 – just about 1 year ago. One of its key features has been about the High Availability function – the simple way to connect up two appliances and to allow for seamless failover between them benefitting from synchronous replication.
At the end of 2015, as detailed here IBM extended this High Availability option with asynchronous replication to other MQ Appliances, which could be deployed further away, offering Disaster Recovery. However, deployments needed to choose either one style of replication or another, on a Queue Manager by Queue Manager basis. So a Queue Manager on a MQ Appliance could be defined for High Availability, or for Disaster Recovery, but not both.
This created an obvious question when we discussed this with customers, who in some cases would want to have local MQ Appliances offering High Availability, but in the case of a whole site failure, wanted to then offer Disaster Recovery off-site. As giving forward looking statements can be an issue without legal clearance, we have ensured that with this Statement of Direction we can clearly state and assure customers that IBM indeed does intend to support the ability of Queue Managers to be configured for both High Availability and Disaster Recovery in a future update.


For MQ itself the Statement of Direction covers less function, and more the delivery and support approach used for MQ itself. For many years IBM has released updates to IBM MQ every 2-3 years as major new versions, and sometimes with additional interim updates as incremental releases. But over the last few years IBM has been adding function into the regular fixpack deliverables where we also include maintenance updates alongside the new function.
While this approach allows IBM to add useful new functions between releases, and thus getting it to customers earlier, it can lead some customers to choose to keep their MQ implementations on older releases until IBM stops adding new function to that particular release. The concern is that adding new function in a release that will be used in production can create the need to have a major new testing cycle, even if IBM has designed that the new function is off by default.
As IBM thinks customers would benefit from being at the latest level of code, and certainly IBM wants to encourage customers to stay up to date with the latest fixpacks, IBM has decided to offer two separate code delivery and support options.

One option will be the Long Term Support Stream. A new version of MQ will be released, and from that point on, there will be no new function shipped on that code-stream. The fixpacks that IBM will continue to ship on a regular basis will only contain fixes to existing functions and no new functions will be added. As such it should be simpler and safer for customers to move more rapidly to this level of code and to then stay on it as fixes are rolled out, improving stability and performance.
The second option will be the Continuous Delivery option. Based off the same original code drop as the Long Term Support option, subsequent updates will be delivered containing not just fixes but also incremental new function. Each mod-level update will be designed to continue to add new function. And, important to understand, customers who choose to deploy the Continuous Delivery stream will have to keep taking the additional functional increments and fixes if they want to stay on that stream by moving to the most recent mod-level. If they decide they want to be on the Long Term Support stream then will need to change the MQ installed which will likely cause a degree of disruption as they will effectively be moving to a different release. While this continuous delivery of function will ensure that customers of MQ will have new functions that enhance MQ and the operation of their environment, those customers will need to be able to continue to update their environment with each update as it is delivered. For many customers this might be appropriate as they have a need for the new function or they may want to apply it only to a particular environment and set of applications.


After a number of functional updates to the Continuous Delivery Stream of IBM MQ, over probably a period of 2 years or so, it is expected that the incremental set of new functions delivered in the Continuous Delivery Stream will be released as the new starting point for the next version of the Long Term Support stream, and will reset the version for the Continuous Delivery Stream as well. The cycle them will repeat again, with fixes applied to the Long Term Support Stream and new mod-level updates with new function (as well as fixes) delivered to the Continuous Delivery Stream.

This new approach for delivering MQ may be significantly important for some customers as they make future plans, and IBM therefore thought it was important to set this out in a Statement of Direction prior to a future announcement of a new release of IBM MQ supporting this model.

As for when any new releases to backup these Statements of Direction are coming out? Well, keep watching this space.

A message awakens: What is IBM MQ and why do you need it?

January 5, 2016


Why are we here? Not in the existential way. The answer to that is not in this blog. That would probably require more than the page of general MQ related discourse that I generally include. No, this is more why are you reading about IBM MQ? And maybe more pertinently why am I writing about it.

Do you ever read the book of the film? The novelisation. It’s what happens when instead of a book being turned into a film, generally with about 2/3 of the detail and exposition cut out, you have an original film, and then it is made into a book. Generally these tend to be less satisfying than an original novel.

Earlier in 2015, in an effort to try and communicate more with the tens of thousands of people who use IBM integration products, the team in IBM Hursley have been doing live Google Hangouts on multiple subjects – and these are then saved as YouTube videos. With my colleague John McNamara I have done a number of these and 3 of them have been titled “What is messaging” to try to cover why you might find messaging valuable and useful as opposed to some of the other choices around for communicating and exchanging data.

You can see the 3 videos here: Part 1  and Part 2 and also Part 3 

John and Leif

In those videos we tried, as best we could, to be product agnostic – to focus instead on messaging as an approach rather than a specific implementation such as IBM MQ. However the question naturally arises why should you specifically use IBM MQ?

Now in the years I have been writing this blog I have written a few posts that talk to the usefulness of IBM MQ – see here, here and here. However why is it that IBM MQ is still the selection of so many businesses today?

Again, as with the ‘why are we here’ question above, this isn’t something that can be quickly and easily summed up in an easy to read blog entry. So what I will do is try and call out some of the major reasons in simple terms, and then hopefully, as time permits through the year, I will try to add more detail.

Why use IBM MQ then?

  • It works – it does what you need it to do
    • There are many thousands of the world’s leading businesses using IBM MQ, and not just using it – but they are depending on it. They trust it to work, and do what it is asked to do, connecting their business simply, securely, rapidly and reliably.
  • Businesses depend on it – as above – for critical parts of their business – at its heart IBM MQ is built around transactions
    • The business world, and IBM MQ, is largely based on the notion of ‘once and once only’ transactions. While there are other approaches, so much of the critical aspects of business depend on this style of transactionality.
    • It is not easy to offer reliable, persistent messaging that provides once and once only delivery. That’s why many other messaging providers can’t offer this, and why many businesses select IBM MQ
  • IBM MQ scales to meet your business need
    • Developing a small scale application that needs messaging is great and it can be simple to use one of many different messaging tools
    • Ensuring this messaging tool works as the application usage scales is another matter. IBM MQ scales horizontally and vertically, running highly efficiently on single machines or spanning multiple machines in large clusters.
    • Whether sending a few messages per day or scaling to a billion messages per day, it is likely you want good performance. As well as being efficient in scaling, IBM MQ also offers high performance to move messages rapidly between application endpoints.
  • Your business is at risk – how secure is your messaging software?
    • You can’t afford to take risks with your business data, or the information your customers entrust with you. IBM MQ has multiple layers of security on the system itself and the data being moved and supports the latest encryption standards. Can you afford not to protect your messaging layer?
  • Highly available – it’s what you need and your customers expect
    • You can’t afford to go offline – you need to run all day, everyday. IBM MQ can be right there with you, with built-in support for High Availability as well as being able to use multiple different approaches such as vendor-based clustering, or virtualization.
  • Everything you need, functions and tooling
    • While the problems solved by messaging are well understood – and there is a great benefit from simplifying applications, some of that is lost when the need for additional functions require multiple different messaging offerings. With richness of function and a complete span of capabilities IBM MQ offers a single solution
    • Deploying a messaging solution is only part of using the solution. There is a need for management and tooling to provide insight in what is happening to all the messages, and to identify exceptions etc. With support from multiple different tooling vendors, and dozens of additional free tools and add-ons, as well as the ability to create your own utilities, IBM MQ can be tailored to meet the needs of your business solution.
  • Help when you need it, where you need it
    • With more than 20 years of leadership, and substantial market presence, there are thousands of skilled professionals able to provide guidance in how and why to use IBM MQ, how to configure it, how to program with it, and how to deploy and maintain it. And all that supported by IBM’s global 24×7 support organization to help when needed.

So that’s a few of the high points about IBM MQ. I will look to write more in detail about some of these through the year ahead – although I am also pretty sure I will be adding some new entries about product announcements and enhancements as well. Watch this space.

Appliance close up

What can go wrong will go wrong! How the MQ Appliance helps save the day.

November 30, 2015


Since IBM announced the MQ Appliance earlier in 2015, there has been a huge amount of interest in the solution from pretty much everyone. All the customers and business partners I have talked to (along with the many my IBM colleagues have also been talking to) have almost always seen a place for the MQ Appliance in their organizations.

As expected some of these use cases reflect one of our anticipated scenarios of using the MQ Appliance – deploying in a remote location away from the main data centre. Other use cases are based in the data centre with the MQ Appliance being used either to roll out new MQ capacity quickly and simply or to consolidate an existing MQ deployment that might be installed and running on multiple different machines which can make it complex and expensive to maintain, especially when deploying updates or making configuration changes.


Other that the simple and quick deployment and the ease of maintenance that the MQ Appliance provides, probably the function which generates the most interest from customers and potential customers is the High Availability function. MQ is used pretty universally for work that is critical to the business. The messages being moved between applications and systems contain business critical data and it is crucial that these messages are delivered once and once only and in the case of failure at any point, the messages are recoverable and the business can continue. No one wants to lose the message with the new customer details or the big order.


So the High Availability (HA) in the MQ Appliance was seen as key – it was simple to set up – essentially just a single menu selection when defining a new Queue Manager and you would have another appliance ready to synchronously replicate the persistent messages and logs so that in the case of a failure in the production Queue Manager, a replacement queue manager is started on the second MQ Appliance with full access to the messages and logs already available on that appliance. This simple yet rapid and usable solution is compelling, and can also be used, with manual failover control, to enable seamless operation while applying fixpacks on the appliance.


However one of the key details to understand about the HA support was that this used synchronous replication of the data between the disks on each appliance, and as the original message can’t be counted as complete until the replication is also complete, the HA appliance needs to be close enough so that the latency of the replication doesn’t impact the application writing the message. The published recommendation is for latency of less than 10ms, but for best operations latency of 2ms or less is preferred.


Now, with the fixpack available on the MQ Appliance from November 30 2015, we have added another key feature – which addresses the need for replication over longer distances where latency is always going to be too high for synchronous replication. The fixpack adds asynchronous replication enabling offsite replication over far longer distances than supported for HA as there is no impact to each individual message completion – the replication takes place independently. This style of replication is typically used for requirements such as Disaster Recovery (DR), to enable business continuity out of region with the ability to continue work as close to the point of failure as possible.


Customers using this DR feature with the MQ Appliance will be able to configure individual Queue Managers in their appliance to replicate their persistent messages to another MQ Appliance that can be hundreds, or even thousands of kilometres away. And unlike the HA configuration where appliances need to be a defined and fixed pair, there are much more flexible options for this style of asynchronous replication.


As mentioned the DR configuration is done on a Queue Manager by Queue Manager basis – but different Queue Managers on the same production appliance can be replicated to different DR appliances. Also Queue Managers defined on different production appliances can all replicate to the same individual DR appliance.


As before with the HA appliance, there can be ongoing work and other active Queue Managers on the appliance being used as the DR appliance – there is no formal limitation for appliances to be DR or HA appliances – any appliance can be configured to offer this in conjunction with the other workload running on it.


With the addition of this asynchronous replication for Disaster Recovery, the MQ Appliance can be used for more deployment use cases as the ability to recover from failures to a running environment in another data centre is always going to be crucial, as so many businesses depend on MQ to keep them running.

<BLOG UPDATE> With this MQ Appliance fixpack delivering such an important update we also have blogs from our Appliance development lead Ant Beardsmore here, and from our Appliance HA and DR architect John Colgrave here going into more details on the enhancements and the technical details of how DR works.

With simple configuration for all these scenarios, rapid deployment and ‘push-button’ maintenance, it is no wonder so many businesses are looking at using the IBM MQ Appliance. Want to know more? Check out our main webpage. After all, if things can go wrong, they will go wrong. That’s why you use IBM MQ after all. It is better to be ready and to be able to cope with these disruptions. Your business needs to keep running. With the MQ Appliance you can do that with the minimum of effort.


Finding your Yellow Umbrella

September 9, 2013

I don’t know about you but I am getting pretty excited about the upcoming final season of How I Met Your Mother (HIMYM). We have been laughing and crying through 8 seasons so far. Ok mainly laughing. And some of it has been legen—wait for it—dary. But now, as with all good programmes, it is coming to an end. Ted will finally meet the mother of his children. What do we know of her? Well one thing the writers have been using as a plot device is a Yellow Umbrella. A few seasons ago we were told the Mother had a Yellow Umbrella, and at one point Ted found it, and used it for a while, before losing it. So the Yellow Umbrella has been used to cue up this important relationship. It is used to flag something important in developing the plot and getting closer to the end. And finally, finally we are getting there.

So far, so what? I could continue about many other things that either reflect on the main plot, or the characters, but I want to try to relate the plot device of the Yellow Umbrella (and indeed the Mother), to your IT infrastructure. Maybe it’s a bit of a stretch. Let’s see. Because the thing is that in your business you will have (obviously) lots of data. Some of that data, hopefully most of it, will be important. Some of it is more important than others. Just like all the women Ted dated through the years. Some were fun. Some were nuts. One left him at the Altar. And of course there was Robin. And there were times where he nearly left New York to go to Chicago. But there was a right time and a right place for everything. Ted needed to be in New York. He needed to be in the right frame of mind. He needed the right woman. Just like it is important to get and process the right data at the right time and place. And that’s what WebSphere MQ is all about. The right information in the right place and time.

Business is becoming more and more connected. Each connection opens up the opportunity to share more data across the business, which in turn opens up the opportunity to take action in response to that data. Think of it as a tremendous speed dating opportunity. But if there is valuable data out there, how do you know you can get to it? How do you know it won’t get lost? What you need is a reliable way to move data around your business. And this is, of course, WebSphere MQ. To continue the analogy it is a way of getting all your potential dates in the room with you, and not getting lost along the way. After all with your business data, you are creating it and consuming it for a reason. Don’t just move it from application to application, or from system to system. The value is in the context AND the content of the data. Making use of it is the value to it. And to create value from consuming it, you need to get it to the right place at the right time.

After all – supposing you are building medical devices that monitor the heart beats of patients who suffer from heart disease. Timing is critical here – not just getting the data. Especially if you want to be able to take action to help save a life. WebSphere MQ is proud to be a part of the solution for a major medical device manufacturer in helping to provide time critical action.  Harking back to HIMYM, we learned some years ago that the Mother was in a lecture that Ted gave when he was a professor of Architecture at University of Columbia. The timing wasn’t right there.  

So timing is important. But it is not just about timing. It is also to be able to get the right data – there is of course a lot of data about. In HIMYM Ted dated the Mother’s roommate for a while, without ever meeting her. In your business, data is being generated all the time. Both within the corporate environment, and out in Clouds or Mobile solutions. How do you know that you aren’t losing some of that data? That it isn’t simply slipping by? Whether it is a simple query for information, that could turn into your biggest order, or a payment being processed by your bank to ensure you can make payroll. Data matters. So you need to be sure you are moving it reliably. When building a new payments system, SEB – a leading Nordic bank – made sure that WebSphere MQ was at the heart of their payments, ensuring the reliable and secure delivery of payments as they complied with SEPA to be able to exchange money across 32 European countries. 

And of course in the real world, things don’t always run smoothly. You don’t always get a scripted happy ending. And things outside of your control can make things take a turn for the worse. Things like the weather can disrupt anyone’s plans. Especially if you can be impacted by bad weather, such as in places like the Netherlands, protected by levees. These levees would need to be inspected, and more so in bad weather. IBM worked with the local flood control teams to put WebSphere MQ at the heart of new sensor based monitoring, allowing for levees to be inspected instantly, no matter the weather. And certainly without the need for a yellow umbrella. 

I could go on, but we have probably extracted enough analogies from this at the moment. Who knows what the final season of HIMYM will bring? But I know what WebSphere MQ has brought over the last 20 years to thousands of businesses. It has delivered the right information, to the right place, at the right time. Businesses could get on with their focus on their business, instead of having to build and maintain their own messaging middleware. They could simple rely on IBM and WebSphere MQ to do what needed to be done, meaning they could get on with their lives, and not get continual calls that interrupted their time outside work, giving them the chance to catch up on their TV viewing. Image

Enterprise Messaging and beer – putting the fun into fungible

August 28, 2013

So how many articles or blog posts have you read that have something to say about Enterprise Messaging Middleware, yet also are about beer? This might be the first one, although that is probably a shame as certainly most coders I know like a decent beer every now and again, or perhaps more often than that. But the spark for this post was when I was putting the weekly shop away this weekend.

We order online from Ocado, and I had ordered a dozen bottles of real ale, which I do every 2-3 weeks. I don’t order any specific ones regularly, as I just see what is on offer and buy them. To me bottles of ale are fungible goods. On the whole most of them will be fine, so I will just buy whatever is on offer, and the next time I will buy whatever is on offer. Some I might like better than others, or might go better than others with a particular meal, but on the whole there is no reason, give the wide enough choice, to buy anything other than the ones on offer. Even if Ocado have to substitute on the delivery, pretty much anything will be fine.

But how widely does this this apply? Is everything fungible? Or is ale different? Does it help that we are only talking about items which are typically (on offer) 3 bottles for £5? How about messaging systems, given they are also close to my heart? There are certainly lots of choices in the market today. Some which are focused on the enterprise market. Some are focused for cloud deployments. Others make virtue about being open source, or standards-based, and so on. All in all we could probably imagine them sitting on a Supermarket shelf next to one another, with colourful packaging, trying to tempt you into making a purchase.

Let’s consider an example from consumer packaged goods again – tomato ketchup. There was an interesting article, from nearly 10 years ago in The New Yorker, on Tomato Ketchup, written by Malcolm Gladwell. He contended that Heinz Ketchup is an example of what is effectively a non-fungible product. A product that people would not want a substitution, as it is the only satisfactory option. He even compared it to other markets, such as mustard or pasta sauce which have been disrupted through greater choice, but nothing has done so to Heinz Ketchup – it was, in effect, a Platonic ideal product.

So let’s look at Enterprise Messaging. What is it there to do? Why do you use it to move data? You use messaging to connect your enterprise applications with reliability and security. You are probably looking to move the data without any noticeable delay, to keep your applications simple, and to ensure that it works well from a development and test point of view, but also as you scale up your production deployment, and offers you high availability in the form of a failure.

When Malcolm Gladwell was writing about ketchup he was able to give examples of people doing customer taste tests, of rival products which claimed to be better, of careful and scientific analysis, but the market has for years spoken clearly, and people just keep buying Heinz. There were some examples given of other sauces with different formulas, that people might like, but none of them has stood the test of time. Maybe there were flaws in their product. Maybe it didn’t have a good shelf life. Maybe it responded badly to heat, or cold. Maybe the flavour profile only really worked with some types of other foods, or clashed with typical meal drinks. Either way it is very difficult to beat a product which is actually that good in its market. A product that has stood the test of time. And yet they have undoubtedly evolved the product. I am sure it is lower in salt and sugar than before. And certainly I prefer the squeezy bottle to repeatedly hitting the bottom of the glass bottle. I personally have on occasions bought other ketchups – typically store own brands. But yet I choose Heinz. Would I like to have substituted product? No.

So does this have anything to do with WebSphere MQ and the Enterprise Messaging market? Well I would contend that just as Heinz has had to make ketchup that appeals to the widest possible set of people, eating the widest possible range of meals. And despite peoples’ appetites changing, they continue to be the top choice. And WebSphere MQ has been around for 20 years. If you look at the middleware message market, and customer needs over the years, then both have changed. But MQ has changed over the years. It still delivers the same ‘taste’. It is still used in the widest range of ways. And it is still the most widely deployed Enterprise Messaging product bought and deployed by companies all over the world. Is it fungible? If you are looking to move data around your applications in your enterprise, across multiple systems, multiple users, varying security requirements and your business needs to rely on this data being moved, knowing it has been moved once and once only, is this something you want to leave to chance? Would you be happy with any old messaging system? How fungible is your enterprise IT? I would suggest that at least with Enterprise Messaging, it is something you want to choose, and choose well. More and more IT systems are selling themselves as commodities. They are almost selling themselves on their lack of differentiation. And yet you have to know, when you are buying something, that you know what you are buying. Would you take a random selection of items in your shopping basket? Or do you want a choice? Would you deploy your IT to a cloud solution that has a random set of technologies, or do you want to pick the solutions that you actually want to run your business, whether on the cloud hardware or on-premise.

Not everything is as fungible as beer. Not everything is as tasty as beer either. But certainly there are no Enterprise Messaging Systems like WebSphere MQ. Image

TV or not TV. The benefits and risks of open source software

July 5, 2013

Everyone likes free right? Free food. Free drinks. Free money. Free software. Except when it is free you always need to look for the catch don’t you? After all there is no such thing as a free lunch is there? If it is free, then follow the money. What is being sold? Is it you? Is it your future? Is it a risk you are willing to take?

Let’s start with TV. About 10 or 11 years ago, here in the UK, I bought one of the last Tivo Series 1 boxes that was sold. Tivo was ahead of its time in the UK market. People were still struggling with the concept of recording TV on anything other than VHS tapes, so Tivo sadly failed to capture a market which was then exploited by UK satellite TV provider Sky, with their Sky+ boxes, which did pretty much the same thing.

Now I liked my Tivo box – it did what I wanted it to do – worked nearly flawlessly – and the only problem was that they weren’t around to sell me updated hardware that might record more channels or a higher resolution. And so last year, it finally got decommissioned, to be replaced not with a commercial offering, but with a home-built MythTV solution. We bought a basic PC, stuck in a 4-tuner HD card, and installed and configured MythTV on Mythbuntu – an open source free TV recording software solution that pretty much again meets our needs.

So is this a parable that we can compare against the market for commercial middleware solutions? After all buying from Tivo all those years ago, only to be effective marooned would be pretty much like buying a promising product from some fledgling software company only to see the company go out of business leaving you high and dry.

(I must point out at this point that Tivo re-entered the UK PVR market a year or so ago in partnership with cable TV firm Virgin, and also that they continued to support their old TV boxes for many years – so did much better than many firms would.)

So when looking for middleware solutions, should businesses be looking at free and open source solutions, rather than taking a bit of a punt on a small commercial provider who might be gone in 6 months, or change their market focus even if they do stay around?

Well, let’s look at our MythTV solution. Are we happy with it? Does it do the job. Yes, and Yes. But still there are issues. It records pretty much as many programs as we want, and we can stream them direct over the home network to the TV. We didn’t pay a penny for the software – just the hardware, and on a regular basis it tells us there are fixes to be installed. But here’s the thing. As good as it is there is a recurring, seemingly random error with the TV tuner card being ‘lost’ by the software so it tries to record, but has a blank recording. We have figured various ways round it, so on the whole it’s survivable. But it is not something I would put up with in a commercial offering. It would have gone back. In fact the only reason we went with MythTV was that no commercial offering did what we wanted.

So why do we put up with it? As I mentioned above, we can work around it, and on the whole it does what we want. And let’s face it, the worst thing is we don’t get a TV program recorded. And at the end of the day, that’s not important. What is important is your customers, your business data, your transactions, your partner orders. These are not something you take a risk on. These are something that when you are handling in your business you take care of.

So when you are evaluating your middleware software – maybe comparing WebSphere MQ to other solutions that promise you ‘free’ or ‘open source’, then maybe you need to figure out what it is for. Is it for something you care about? Does it matter to you? Maybe you actually ought to invest in it a little to ensure you get the best. The companies producing these software solutions need to invest to build and support them. Providing them as open source, or free is simply one distribution option – but the goal is still to make money.

IBM recently contributed the MQTT standard, and the source for our MQTT clients to the Eclipse Paho project. It is actually rewarding that this standard has been picked up by many vendors, who are producing their own clients and support. And this was essential for the success of the protocol. In order to be taken up by M2M vendors, and to better penetrate the mobile space, a wide range of support was needed. And this was accelerated by making it a standard and providing source code. It is a means to an end. Just like in the TV world if you subscribe to Sky, they give you a Sky+ box – something I needed to buy from Tivo all those years ago. They can offer this for free because it provides you with a stronger reason to be committed to buying their TV subscription. Stop doing that and you lose the benefit of your free solution. Not so free then after all.

So when looking at your middleware options, make sure you think carefully, about the value your place on your business, and the need you have for freedom of movement for your business and its future, rather than free software for todayImage.

By the way, if anyone wants 4 (yes 4) old Tivo Series 1 boxes, please let me know.