Posts Tagged ‘WMQ’

IBM MQ Light – What’s in a name?

October 3, 2014

“A picture paints a thousand words”. A well-known phrase. Undoubtedly true, but a single word can be critical. Change a single word and the meaning of a sentence, a paragraph, maybe a whole book or more could be altered. So what about IBM MQ Light? Is it MQ, but Light? And what does Light mean in this case?
We see the description ‘Light’ every day. Some product advertises itself as “Light – all the flavour, half the fat”. You know the sort of thing. So does it apply to IBM MQ Light? How does this new product compare to IBM MQ itself?
Well, I would say that maybe the best way to think of it, is not IBM MQ but “Light”, but rather IBM MQ for those “Lightbulb” moments, such as when Archimedes shouted “EUREKA!”.

IBM MQ after all already delivers the benefits of messaging to millions of applications running in tens of thousands of businesses around the world. I have described some of those benefits on these pages already. It does this primarily for enterprise critical applications, written in C, Java or even COBOL, dealing with Systems of Record. These applications handle business critical transactions, moving key customer and enterprise data between applications systems and services. And it makes a lot of sense to ensure these applications, and the associated data can benefit from IBM MQ’s reliability, robustness, security and scalability. After all if you are moving and updating business transactions, you want to scale, be secure, and be highly available.
However, there are many millions more applications that don’t face the same requirements, but yet are still critically important to the business. Maybe the app helps the business interact with customers with more immediacy. Maybe it shares information more widely with partners. Maybe it is building brand awareness or promoting the business across different platforms and devices. These type of apps are written by a different type of developer, using different languages, for very different purposes to the more traditional application that works with the systems of record. These are unlikely to be updating business critical information systems or processing transactions, although they will need to interact with existing systems. So maybe they don’t need everything that IBM MQ has to offer. But does that mean they don’t need anything that IBM MQ has to offer?
Messaging as provided by IBM MQ, does after all benefit program architecture and operation. Applications can be simpler. Applications producing and consuming data at different rates can be easily buffered. And aspects of security can be built in. Along of course with the ability to connect and exchange data across different systems, even if one application is down.
If messaging can bring all these benefits, why would the programmers of all applications not use it, when there is a widespread and well proven technology like IBM MQ? We have already called out many of the reasons. The developers are a different set of people, with different skills, and code in languages that IBM MQ doesn’t natively support. And IBM MQ is designed around the needs of those critical business transactions. That doesn’t mean that it can’t handle simpler needs, but if you are not familiar with using IBM MQ, there can seem to be a lot more options in the API to deal with than maybe are needed for a different, more straightforward use case. So why not produce a messaging product, which takes everything from IBM MQ that would be useful to this new set of developers, but presents it to them with a simpler API, more in line with the restricted needs of the type of applications they are producing. This is what IBM has done with IBM MQ Light.
IBM MQ Light is a new and different messaging product from IBM. It aims to bring the benefits of messaging to a new set of developers building the latest applications for a rapidly changing world.
The goals of MQ Light are as follows:
• Provide messaging that application developers will love to use
• Help applications be responsive and scale to meet demand
• Make it easy to get access to the code and to start to use it – simply download, unzip, use
• Run on premise or on Bluemix in the cloud
• Offer simple, open APIs in a mix of popular scripting languages
• A new breed of tooling to ensure developers know what is happening to their messages
You can see by these goals, this is something new. And also MQ Light is not trying to be an alternative to IBM MQ. It is very different. It focuses on the needs of the new developers. And in keeping simple, it means that it doesn’t provide some of the key characteristics of IBM MQ. There is no clustering, no high availability, and no transaction support. If your application is likely to need those functions, then the right choice should be IBM MQ. If however your application doesn’t need any of those, but it still could benefit from messaging, allowing it to buffer and scale workload, respond to events, schedule actions or queue responses, then MQ Light may be a good match for them and their developers.
For development use, MQ Light is of course free to download, and is available on Windows and Linux for x86 or Mac OS X. Once applications are developed and ready to be put in production, they can be run on premise in the MQ Light runtime (payable per Install), or deployed using MQ Light in Bluemix (payable per Message). And in the future, as mentioned in the IBM MQ V8 announcement letter, there will be the ability to run MQ Light applications in IBM MQ itself.
All in all, enough to make a lightbulb go off in anyone’s head. If it is going on in yours – check out the MQ Light webcast to learn more. Or even better download it today and be using it in a few minutes.



Message in a bottle, or shipping in a container – changing the world every day

September 20, 2013

One of the joys of twitter is that your friends and other tweeps can bring excellent items and articles to your attention. And thankfully not all of them are pictures of cats – although some are (thanks @PlatoSays). Anyway earlier this week, Richard Brown (@gendal) tweeted a link to this article on how shipping containers built the modern world. Now this sparked something in me because a few years ago I was working in IBM’s marketing team for WebSphere – looking mostly at Connectivity and Integration, which of course includes WebSphere MQ.

What was amusing to me was that Richard, when tweeting the article, said to think about the shipping container as the Internet of Things, and in my marketing role we had actually nearly done a large marketing push/campaign around the similarities between messaging and shipping containers – and indeed shipping goods themselves. I probably have on my laptop somewhere various images and presentation drafts about it. However it was too easy to get too deep into the shipping analogy, and to lose track of the actual points about Messaging. But given with a blog entry I have absolute control, I will try to make the key point I was trying to do beforehand – and you can let me know if I lose focus.

Let’s start with the shipping container and how it succeeded. It starts by looking at what came before it – every item loaded into a ship individually, and unloaded individually. This involved a tremendous amount of manpower, incurred a lot of breakages (and theft) and also took a huge amount of time. The shipping container of course changes all this. All types of goods can simply be loaded into a container elsewhere. The container itself can then be simply moved from place to place, with the unloading and unloading from the ship being capable of being automated. So the complexity of moving and dealing with multiple types of goods has gone, replaced with a simple, repeatable process. No longer are goods delayed, with ships held up in port. Everything runs like clockwork.

The parallels with messaging are uncanny. Data is packed into messages. The message contents themselves then become irrelevant. The messages are all moved programmatically, with the applications that loaded the data no longer involved, and not delayed by the process of moving the data, which can be subject to a lot more scrutiny and checks without overcomplicating the application program. By applying messaging to move data between all your applications you now have simple, repeatable and reliable methods to move your data anywhere without over working your applications. When a program receives a message, it is because it has been designed to handle the data within it, just like a shipping company expects a container and can handle what is in it, thanks to the bill of lading.

So if a simple box has changed the world, just think what a simple message can do for your IT infrastructure. Much like today’s shipping container, WebSphere MQ is probably the most widely used commercial messaging product, moving more bits of data daily than there are goods shipped daily in shipping containers. Changing the world, one message at a time. Image

New updates for WebSphere MQ Managed File Transfer

July 16, 2013

One of the biggest ‘new’ use cases for MQ over the last few years has been for managed file transfer – that is making use of a MQ network to send files as messages, as well as the typical use of connecting applications. This is actually something that MQ has been used for over many years, but the release of WebSphere MQ File Transfer Edition, now called WebSphere MQ Managed File Transfer has helped bring that to the fore, and this capability is front and center in the benefits that WebSphere MQ Advanced brings to customers. 

We have had many successes with this offering – not least because so many businesses make use of files pretty much everywhere in their infrastructure and WebSphere MQ MFT not only moves the files, but as it moves them as messages, allowing the data in the file to be created or consumed seamlessly, without secondary processes and delays. 

Some of the businesses that have been fastest on the uptake of this have been retailers – which has historically been very file-centric. They have enthusiastically been using, or exploring how to use WMQ Managed File Transfer in both their head office and in each and every store. However some of these retailers use 4690 hardware in their stores – a dedicated retail platform – and they have been asking for us to supply WMQ Managed File Transfer Agents to run on the 4690 Store Controller, simplifying their store management and IT admin. 



I am pleased to say that on July 9th we announced a new platform for our WMQ Managed File Transfer Agent – the 4690 Store Controller. This will be delivered as part of the second fixpack for WebSphere MQ V7.5 and should be available on July 26th. You can read the announcement here

I hope that many of our retail customers will be able to take advantage of this enhancement.

There has been even more good news for WebSphere MQ Managed File Transfer users – as in June we also had another announcement about improvements in monitoring WebSphere MQ Managed File Transfer. From the wider IBM portfolio, our colleagues have extended the IBM Sterling Control Center product to enable monitoring of WebSphere MQ File Transfer Edition and WebSphere MQ Managed File Transfer. This is a great benefit from those customers who might already use that with IBM Sterling Connect:Direct or who are simply using WebSphere MQ Managed File Transfer but wanted more powerful and configurable monitoring than that provided by the WebSphere MQ Explorer. You can again read the announcement here