Posts Tagged ‘MQ client’

Buried Treasure – embedding IBM MQ clients and MFT Agents into applications

June 13, 2017

treasure

I haven’t been doing this blog so long that I am going to repeat myself. Or at least not yet. But last year I did a blog on why you would use MQ – and that is broadly the topic of this entry as well but it comes from a specific use-case perspective. Plus – warning – it is longer than usual – sorry. Why do businesses, in their thousands, use IBM MQ – and its many different yet critical functions? Sadly, and I say this as the Offering/Product Manager for MQ, no one wakes up in the morning and decides they want to buy more IBM MQ – but they do so because of the benefit using MQ provides for the applications that run their business.

 

IBM MQ enables the exchange of data between applications, systems, services and files with reliability and security. It does this with scalability and simplicity. It has proved itself in doing this over the last 20+ years that much of the modern online business world takes IBM MQ, and its capabilities for granted.

 

The IT infrastructure is evolving rapidly – as it always is. As such there is both growth in new applications and existing applications are being updated and enhanced. Today’s applications typically have to be more resilient than ever, but also more portable – to be deployed pretty much anywhere. In most businesses applications will be extended out to business partners as the wider ecosystem is more tightly integrated than ever before.

 

These changes drive a greater need for seamless connectivity throughout the infrastructure and it makes it more important that all business data can be simply and quickly moved inside and outside the business. So how has IBM been working on IBM MQ to enable this? And will IBM MQ be able to help all customers – whether they are trying to connect and exchange data between applications, systems, services and files – not just the latest and greatest APIs?

 

IBM MQ allows for connectivity and exchange of data through MQ Clients and MQ MFT Agents and to make it easier for these to be used in many different use cases, IBM has been making changes to the packaging and licensing of these.

MFT Agents

One of the key changes was at the end of 2015, there was an update to the license documentation to allow for the redistribution of MQ Clients. IBM makes the MQ client libraries available for free download. These are then built into the MQ enabled applications to allow these applications to send and receive MQ messages. There is no cost for the MQ Clients – as they require a licensed MQ Queue Managers in order to function. However, until late 2015, the license prevent redistribution of these MQ Client files. This meant that if a business built the MQ Clients into an application, it wasn’t permitted to then distribute this application outside the business – i.e. it couldn’t share it with a business partner to allow that partner to work closely as an integrated partner. To allow this under the terms, the partner would need to either install the MQ Client library themselves or agree licensing terms to redistribute the MQ Client with IBM. This restriction was not helpful to these businesses or to the IBM MQ business and therefore it was changed to allow redistribution.

 

Now let’s look at a scenario – Company A uses MQ to exchange information throughout its business. It has suppliers (Company B and Company C) and it wants to streamline the manufacturing processes to enable them to get production statistics and thus help to plan for more efficient resupplies to their factories and warehouses. To do this it wants to provide them with a copy of their own in-house written application that uses MQ. Now that IBM allows for redistribution of the MQ Clients, Company A can simply provide their application to the partner companies to enable them to communicate seamlessly with no need to even be aware of the MQ Client embedded within the application. MQ messages can flow securely between the companies – and as only Company A has a MQ Queue Manager, they are the only ones licensed for MQ – and there is no additional MQ cost for this configuration. Note that companies exchanging MQ messages like this might want to make use of the MQ Internet Pass-thru feature to simplify passing messaging through their firewalls.

 

Now let’s imagine Company D. They are also part of the supply chain ecosystem for company A, and also many other businesses. But the stock control and distribution management systems are built mainly on files and file data. They keep these files updated with stock quantities and prices, but they find it simpler to keep using this method rather than online application updates and exchanges. They are used to sending these files to their customers using FTP but they always have a number of issues around FTP failures, reliability issues, and having to spend time diagnosing the problems inherent in these transfers.

 

Company A have a solution – the Managed File Transfer capability that is a part of IBM MQ Advanced. In place of regular FTP, the data inside the files can be sent as MQ messages from Company D to Company A, taking advantage of MQ’s reliability, security and management of data. And best of all Company D don’t need to change the way they handle data as they can still focus on keeping the file contents updated, but Company A can provide a program that can also embed the MQ MFT Agent which can run and extract the contents of the file and send it as MQ Messages to Company A. Just as with the MQ Client, the MQ MFT Agent is designed for easy embedding in an application, and benefits from also being redistributable under the license. The key difference is that MQ MFT Agents are free but only when they connect to MQ Queue Managers that benefit from the MQ Advanced license entitlement or are in the MQ Appliance. In providing this application making use of the MFT Agent to Company D, Company A is taking advantage of the recent change to make the Agent license redistributable, as well as the fact there is now no cost to embed MFT Agents and distribute them anywhere, as long as they connect to their MQ Advanced Queue Managers. Also, the packaging changed to ensure the MFT Agent was available as a standalone zip file for easier embedding.

 

As a business, your buried treasure may be hidden in your data. You owe it to yourself to ensure it is used as widely as possible and as timely as possible. But to do this you need buried treasure in your applications as well – and this time the buried treasure is the MQ Clients and MQ MFT Agents you can now embed in those applications. Hidden in your code, but providing value every day – maybe not buried treasure, but the goose that lays golden eggs?

Goose Golden Egg

Advertisements

When is a quantum leap not really a quantum leap?

November 3, 2015

Electronimage

A quantum leap, if I remember correctly, is the movement of an electron from one energy level to another energy level. So it is not really a big change – just the change from one discrete level to another discrete level. However the phrase “quantum leap” is often used to describe a big change, when in fact it is describing a very small change. Just like a quantum leap, MQ get updated from one fixpack to another. Sometimes this can be thought of as a small change. However in the case of the latest update to MQ V8, this change can represent significant change and new opportunities for MQ users. When an electron does a quantum leap and drops down to a lower energy level and emits a photon, let’s shine a light on the changes in the latest update to IBM MQ.

Last week, on October 23 2015, IBM brought out an update to IBM MQ V8 that included not just fixes, but some really important new features and functions. I will call out some of these here, and hopefully also link to some other sources of information to find out more about the parts I don’t cover.

The key enhancements I am going to cover are the addition of full MQ Light API support within IBM MQ, and also what we are calling the redistributable MQ Client. There are plenty of others (another interesting new feature is setting a Message Expiry Cap) and these are described in Mark Taylor’s short presentation – which can be found here 

Let’s start with the addition of the MQ Light API as a fully supported option. You can read my previous blog on MQ Light here   – but as a recap, MQ Light is a new API for messaging which is designed to allow developers working with Javascript, Ruby, PHP, etc. to make use of messaging as a part of their applications. This enables them to code microservices, and build applications making use of buffering, but doesn’t force them to learn the richer, more complex MQ API or JMS, or require them to code in C or Java. MQ Light is a good way for many enterprises to start to change some of their infrastructure into Hybrid deployments, supporting both on-premise and cloud deployments.  In this latest update, IBM MQ itself now supports the MQ Light API. So these developers can continue to script their applications making use of the MQ Light API in whichever environment they prefer, but now IBM MQ itself acts as the messaging provider. As these MQ Light  applications publish their messages or listen for their subscriptions using the AMQP protocol, this means that AMQP clients can now for the first time connect in to IBM MQ which is then receiving published messages and forwarding them on, or routing the subscriptions to the applications. By ensuring that only a single messaging runtime environment is needed, this lowers the operational burden, reducing complexity for the infrastructure team, and keeps costs down, while keeping the application developers happy with their preferred development environment and API. And the infrastructure team can ensure they support the growing demand for Hybrid infrastructure for cloud deployed applications, while still meeting their enterprise qualities of service for their middleware infrastructure.

The other key update concerns the MQ Client. The MQ Client is how many MQ customers make use of MQ, embedding the client libraries in their applications which then send and receive MQ messages. In this new update the MQ Clients are now also available as tar or zip files for easy embedding in the applications themselves. As well as removing the requirement for a separate install process, the license has been updated to allow applications that include the MQ Clients to be distributed inside and outside the enterprise without requiring permission from IBM as had been the case in the past, which had prevented the easy inclusion of the MQ Client libraries in many solutions. From now on, the MQ Client can be included in any solution, easily packaged and distributed to allow the seamless distribution and deployment of MQ connected applications anywhere required. I am looking forward to seeing many more customer and vendor applications including the MQ Client libraries from now on.

These two changes are substantial enhancements and dramatically change the options available for businesses looking to use IBM MQ for messaging, making this a real leap into the future, for both on-premise business critical applications and the rapidly changing world of Hybrid Integration.

For more details on using MQ Light and AMQP with IBM MQ to enable Hybrid deployments and more see here.

And for more information on the re-distributable MQ Client see here.

A leap into the future, and into the past was the subject of another ‘Quantum Leap’ – this time a TV series from the late 80s/early 90s. Scientist Sam Beckett would ‘leap’ from body to body throughout time. I guess that’s another example of a quantum leap not being quite a quantum leap. As he used to say when he leapt into someone else: “oh boy”.

QL-ohboy

Did you remember to lock your car?

November 12, 2013

Image

We’ve all done it. You have driven your car to a car park, walked away, and then had a momentary pang of doubt about whether you locked your car. It has become second nature to lock your car. To keep it secure. The car even locks the doors itself when it is in motion. But when you park it and walk away, that’s when the uncertainty comes in, and also when your car is most vulnerable.

It is the same with your enterprise messaging. What happens when you use a product like WebSphere MQ to send a message across your enterprise? Well, of course, what is happening is the application takes some data and packages it in the contents section of a message structure, along with some header information to describe the message and the destination. The message is then dispatched. All in all that’s pretty similar to you getting in your car and driving to the shops to buy something like food for dinner, or presents for a birthday. There is a destination and something of value to be transferred. With a car, you have to park in a space in a car park. With messaging, instead of a car park you have a queue manager and queues.

Messages start in an application and a MQ Client packages the information to be moved into a message. This then is sent to a queue manager, to be written into a queue. According to the destination or other information, the message is then sent on to either another queue, another queue manager, or to the destination client application.

As far as securing the message goes, when the message is moving between the client application and the queue manager, then the MQ resources are secured by MQ built-in security definitions and the message and contents itself is secured while moving over the ‘wire’ by use of SSL. However while the message is encrypted by SSL as it moves, once it reaches the queue manager, and is written to the queue, it is unencrypted and thus sits on the queue without any encryption. Thus if the system with the queue manager is penetrated, the messages on the queues are available in the clear. This is the same as parking your car in a ‘secure car park’ but leaving the car unlocked as the car park is secure. Would you do that? I’m pretty sure I wouldn’t.

Now what would we like to happen? What would be smart would be a routine that ensured our car was locked, pretty much at all times unless people wanted to get in and out of it – subject to key rules – such as ensuring people could actually get out or in when they needed. For messages we would want to make sure the message contents were secure at all times, including when sitting in queues, but would continue to be available to the receiving applications, and of course would still expose the header information needed for routing etc.

What IBM offers for WebSphere MQ is WebSphere MQ Advanced Message Security, which is also available as part of the entitlement of WebSphere MQ Advanced. This is a policy-based encryption capability which allows message contents to be encrypted from sending application to receiving application. So the contents are encrypted while it flows over the network and while it sits in intermediary queues. The applications are unchanged, with just updated client libraries to be used. And the security is based on policies, so different rules might apply for different message contents, or different queue managers. After all there are some times when you have to leave your car unlocked. So I’m pretty sure you have rules for securing your car. Isn’t it about time you had rules for securing your messages?

Image