Integrating MQ FTE with WebSphere Process Server/WESB

Ivan Smirnov, Senior Consultant

WebSphere MQ File Transfer Edition (known simply as MQ FTE) is a robust managed file transfer solution built on WebSphere MQ transport backbone. Product page is here: http://www-01.ibm.com/software/integration/wmq/filetransfer/index.html

This product is a recent addition to the storied and extremely stable WebSphere MQ – it came out after MQ version 7. I was excited to hear about its release because it creates new possibilities in file transfer that FTP, SCP and the like never delivered – like reliability and tolerance of transient network failures. Immediately a question arose: how can we take advantage of these new capabilities in IBM’s middleware. What is the best way to integrate IBM’s premier integration platform, WebSphere ESB (and by extension, WebSphere Process Server) with MQ FTE?

Integration between WESB and MQ FTE will occur on 2 ESB boundaries: module exports that receive files from MQ FTE and module imports that send files to a remote destination via MQ FTE. I argue that the simplest integration approach is also often the best.

On the SCA export (send files via MQ FTE) side, we will configure MQ FTE file transfer using the tool’s native interface (command line or GUI). We then will use Flat File adapter in outbound mode to create a file on local file system where it will be picked up by MQ FTE. Protection from incomplete file pickup is provided by using staging directory, which is built into Flat File adapter.

The following alternatives are possible:

1) Construct the whole MQ FTE messages on the fly in WESB (for instance, by engineering an MQ FTE import binding)

2) Put file on file system the same way, using Flat File adapter, but initiate transfer by putting a request message on MQ FTE agent queue.

The first alternative approach requires duplicating a lot of code that is already in MQ FTE while providing minimal savings in terms of disk I/O. It is not a worthy alternative.

The second alternative approach is close to the original design. However, there is no need to predefine file transfer – this will be done by sending an XML message to administrative queue of MQ FTE. Its benefit is zero administration effort, but it requires some upfront custom development.

On the SCA import (receive from MQ FTE) side, we can configure MQ FTE to transfer files to a local WESB file system. Files will be picked up by Flat File Adapter in inbound mode. MQ FTE has built in protection against picking up incomplete files.

As an alternative, it is certainly possible to receive MQ messages in WESB instead of letting MQ FTE create files on file system. This alternate solution will require complex code largely duplicating existing MQ FTE functionality to extract file payload from MQ messages and handle file-level acknowledgement and auditing. The only upside would be avoiding disk I/O by skipping writing file to file system by MQ FTE and reading it in by Flat File adapter. There is not much value in this, since at such high volume WESB will reach capacity much sooner then disk I/O becomes a bottleneck. This alternate solution is all cost and no benefit.

Conclusion: when integrating MQ FTE and WPS (WESB), simplest solution is very reasonable and will work best in many situations.

Ivan Smirnov is a Senior Consultant at Prolifics with extensive hands-on experience with the WebSphere family of products (including WebSphere Application Server and Process Server, WebSphere Studio/Rational and WebSphere MQ), Tivoli security offerings (including Tivoli Identity Manager and Tivoli Access Manager for e-business), DB2, XML and Web Services. With strong technical skills both in development and administration, as well as deep troubleshooting skills, Ivan handles aspects of implementation installation, configuration, securing and tuning/troubleshooting to development and architecture within a J2EE environment. He also possesses key Application Server migration skills and has helped several customers’ transition to the WebSphere platform from other J2EE platforms.

Good design and usability principles

Alex Ivkin, Senior IT Security Architect

I am a big proponent of usability. After all, regardless of how good something is, or how many cool features it has, if it is unusable – it is worthless. A hard to use application, website or in fact anything that interacts with a human, will not be popular, will lose out to competition or be ignored altogether. There are many articles on the web with examples and lists of usability principles, so I would not go into that here.

It seems, however, that many sites, like ss64.com or useit.com, suffer from a common pitfall in usability design, sacrificing design by going too far. They subscribe to the lowest common denominator in an effort to make it usable to the biggest possible crowd. This makes them very plain and downright ugly. Sure, they cover the 99% of the crowd out there, not the 95% a good design would cover, but in the push for these extra 4% they lose much in the beauty and attractiveness.

Ever wondered how Apple design wins praises so much? It’s not only created with usability in mind, it is also very attractive. Good, usable design after all has clues that are beyond simply making it readable or understandable. The clues are like little streaks of color on a bland background that make it come alive, make it stand out and win over a more “usable” background for most of people out there. Combining a creative effort with a usability agenda is the winning combination.

With that in mind here are the good usability design principles:

1. Start with a use-case. Run through how you think the users will approach the tasks and navigate through. You will be wrong, but that’s a start.
2. Think how it could be simplified. In many cases the simpler is the better. Many designs, like a single hand faucet handle, start off designed for the ease of use with simplicity and then they win over. Assume you are designing for people who are resource constrained: “the less brain I can devote to this task the better”
3. Be creative. Think how you can make it more attractive.
4. Consider performance. Yes it is a big usability factor.
5. Implement and fix bugs (another big usability factor).
6. Rinse and repeat.

What you can do to improve it if you have run out of ideas:

1. Think about HTTP/XHTML validation and CSS compliance
2. Focus on making it understandable by all kinds of colorblind people
3. Sprinkle with metadata, image tags and SEOs

An interesting twist to the discussion above was mentioned in a recent Wired article on ‘good enough tech’. The usability principles break down on the economics level somewhat. In other words if something is cheap enough, and usable enough, it will work for the most of us. So, think of where your design fits economically and how would it compete in that niche. If your stuff is cheap, it may work with a cheap design and being somewhat ok to use (think IKEA). If your stuff is free, it may limp by being somewhat unusable. Like this blog.

Alex Ivkin is a senior IT Security Architect with a focus in Identity and Access Management at Prolifics. Mr. Ivkin has worked with executive stakeholders in large and small organizations to help drive security initiatives. He has helped companies succeed in attaining regulatory compliance, improving business operations and securing enterprise infrastructure. Mr. Ivkin has achieved the highest levels of certification with several major Identity Management vendors and holds the CISSP designation. He is also a speaker at various conferences and an active member of several user communities.