Posts Tagged ‘FTP’

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

Catch up blog – closing on ESBCON

September 29, 2009

So it has been too long since I found time to write a blog entry. And we have a busy time with the Business Agility Now launch coming hard on the heels of the Smart Work launch. But before I cover some of the key areas these look at I feel I ought to finish off the last 3 tough questions from ESBCON8.

Here are the last 3 questions:

Discuss how your ESB supports SLA, zero downtime and cross-department integration ?

For current ESB users, can you detail popular second-generation projects with quick ROI?

How does your ESB accelerate ‘Design-to-Deployment’ with tooling, widgets, automated integrations, etc?

Lets see whether I can give my thoughts on these in a succinct manner. First what about SLA, downtime and cross-department integration? As ESBs become more pervasive and their presence is assumed, they need to no be seen as a problem – to become a utility…that is how they must be seen – as something to plug into and just work. Of course integration is about more than just the ESB – the connected applications must also be available and so the ESB layer must also be able to tolerate application and other failures well. In IBM solutions we are seeing this extension of always-on availability to include files moving through the ESB layer with the WebSphere MQ File Transfer Edition. This boosts the enterprise nature of the ESB solution, and the ability to exist in a Cloud or cluster environment where needed by the business is also a strong choice factor.

Second question = about second generation ESB projects for quick ROI. This is when an initial investment has been made in an ESB and subsequent integration projects in the business want to leverage this. Of course ideally project selection, from the first step would have been done based on business benefit – addressing the key needs first. A study like an SOA Healthcheck would be a good way to do this. However in terms of picking second projects, anything that reuses some of the investment already made would be a good idea. Once assets are available as services through an ESB they become reusable. This any other part of the business that needs them should be able to reuse them as a part of a composite application, accelerating deployment, reducing cost and boosting ROI. This may drive the selection of projects to enable greater reuse, driving ROI.

Finally how to accelerate design to deployment, with widgets, tooling and automation? This is a pretty broad topic to cover – one of the simpler answers would be that for some requirements, customers could deploy our SOA appliance – WebSphere DataPower XI50 as an ESB – this is exceptionally fast to deploy, simplify needing to be plugged in and configured. However other options, to be used with other ESBs, or with the appliance, would include using WebSphere Transformation Extender which can accelerate tricky integration deployments, including by using Industry packs to address key needs. These, and the best practices we can recommend can all really speed your deployment, again increasing ROI.

ESBs and common industry issues

June 19, 2009

One of my key tasks this year is to take a look at our Smart SOA Connectivity & Integration marketing from an Industry perspective. Something I have been keen to do for a number of years to ensure that our sales reps can always provide the best and most relevent information to our clients about the solutions we have on offer. To start to do this I have been looking at some of the hundreds of references and case studies of IBM clients using our offerings – specifically for now those references that include WebSphere MQ, WebSphere Message Broker, WebSphere ESB and WebSphere DataPower.

Now you can easily review some of the references – or as they are described on the IBM website – Success Stories – for yourself, but as I have been going through them, industry by industry, some common themes seem to be jumping out.  I have to say that one of the most common motivators for our clients choosing to deploy solutions that include ESB Messaging and Enrichment is the need to be able to quickly add new or change existing offerings to rapidly address new market opportunities.

This makes a lot of sense to me – there seems to be a tremendous amount of evidence that without selecting messaging and ESB solutions for Connectivity, then infrastructure becomes highly complex, slow to change and costly to maintain. None of these results are good for businesses looking to save money, and respond quickly to changes. It follows then that a key reason to implement WebSphere solutions for ESB and Messaging Enrichment will be to address these – and a good business case to justify funding will be a new business opportunity to require these changes.

In many customer engagements in the current economic climate we are seeing it become harder for clients to justify any expense – maybe we should get them to discuss this problem with some of the UK Members of Parliament? 🙂 But on a more serious note, with businesses feeling the pinch they need to have clear justification that the costs associated with acquiring and deploying IBM solutions will deliver the expected return, and thus a demonstration that other similar problems have been soloed – and that IBM has the skills required to assist can be a major assistance to making that business case. It also helps that WebSphere MQ itself has a fairly strong cost justification anyway as opposed to hand-crafted point-to-point interfaces or standard FTP. You can read more about this cost justification and the risks of not using WebSphere MQ at this link.

Next week I hope to write another entry looking at some of the industry content in more detail – but it is friday night now, so that will do for this entry.