First, apologies it has been so long since I managed to find time for a blog entry. But now that I am here, what is it that I have to say. The origins of this blog topic go back to earlier in the year. We had a new wood-burning stove installed in our house – both for aesthetic reasons and to try to reduce our gas bills by heating the house using wood. Burning wood to heat your house is carbon neutral of course, and we could collect plenty of logs from the wood next to us.

So throughout the summer I have been slicing up dead trees and splitting logs, building wood sheds to build up our stock of wood, in the knowledge it would be cheaper than using our gas-fired boiler to pump water through all our radiators. Did I enjoy this? You bet I did – really makes you feel like you have achieved something, learned a skill – all that sort of thing.

And then we get to winter – and from September onwards we have been lighting the stove, and it has been great. Lots of heat – the house nice and warm. The fire looking good, and all my good work coming to fruition, with the added bonus of no heating bills with the heating off.

But then we get to proper winter as in the UK we get a cold spell with snow (currently filling up the twitterverse with the hashtag #uksnow). We found we needed the fire all day – and even though it is pumping out a lot of heat, and it sits in the center of the house, it can’t quite get all the extremities of the house warm – there are a lot of outside walls getting the heat sucked out of them, no matter how many logs we put in the stove.

So I started to think that maybe we would need to have the boiler on at least some of the time, and that maybe there was a reason that central heating with radiators has replaced fires (even efficient stoves). After all there may be a cost associated with central heating, but it is much less work, and it does ensure that the heat goes right where you want it, not spreading from one point.

Sure from an enjoyment point of view, it is less satisfying, but there is something to be said for progress, or at least a balance of solutions. And then it occurred to me that there was some similarity with the battles our customers have in deploying messaging middleware to connect and integrate applications. The programmers of course want to do it themselves, enjoy the task and it builds their skills. There is even some satisfaction at looking at what they achieve. But of course it can fail to scale up to meet the needs of the business. There might be a cost of buying WebSphere MQ, or an ESB like WebSphere Message Broker or WebSphere ESB, but the end result can be much less effort, and be more effective – at least in a number of deployment scenarios. And it doesn’t mean the programmers have to stop what they are doing – it just means that they don’t need to do all the heavy lifting – allowing them to get on with more tasks.

From a cost point of view, developers might say that it is a waste to buy a solution like WMQ, but in our heating analogy we are not talking about doing everything with the boiler, just taking advantage of its ability to heat the parts of the house the stove would find it more difficult to heat – much like WMQ can do things that roll-your-own solutions can find it difficult or complex to do. Does this seem to ring true?

In the meantime I need to put another log on the fire!

Last Friday saw the electronic GA (you can download it, not get the DVD yet) of WebSphere MQ File Transfer Edition 7.0.2. This is the 3rd release of the product, and the 2nd this year. I thought I would take a few moments to highlight some of the new features in 7.0.2 that might be of interest to you.

Protocol Bridge
This function allows you to access files stored on either an FTP or sFTP server, whilst still using an agent and everything else within FTE. An agent configured to access FTP or sFTP is known as a “Bridge Agent” and is a dedicated artifact in that transfers must involve the FTP/sFTP server. This can be used in a number of ways in the enterprise. You might for example have FTP internally as your current method of moving files from A – B and want to do a gradual role out of FTE to replace it, and with this new function you can. See the Protocol Bridge Infocenter page for more details.

Improved Security
The 7.0.2 release has some improvements to security, in particular you can now grant users authority to perform certain actions. This is a very detailed topic, and I will not try and capture it all in a short paragraph, it would be best for me to link to the relevant Infocenter pages. See the Security Overview Infocenter page and also the Managing authorities for resources Infocenter page for more details.

Multi Instance Queue Manager Support
WebSphere MQ 7.0.1 supports the creation of Multi-Instance Queue Managers and in WebSphere MQ FTE 7.0.2 we can use this functionality for agent queue managers and coordination queue managers. See the WebSphere MQ Multi-Instance Queue Mangers Infocenter page for more details.

IBM i (iSeries) Platform Support
This latest release of FTE supports the transfer of files that reside in the “root” (/), QOpenSys, and QSYS.LIB file systems on IBM i systems. See the Installation page for IBMi in the Infocenter, and also the IBMi Transfer Infocenter page for more information.

fteCreateTemplate
A new command has been introduced that allows you to create Transfer Templates on the command line. This enables you to create Transfer Templates in the same way as on the WMQFTE Explorer plugin. See the fteCreateTemplate Infocenter page for more information.

Improved concurrent transfer limit behaviour
In previous versions of FTE if an agent reached the maxSourceTransfers property then any incoming transfers would automatically be failed. In 7.0.2 we now queue these incoming transfers and wait until the agent has capacity to run them. We have introduced a new property called maxQueuedTransfers, which will limit the number of queued transfers, before rejecting transfer requests. See the Advanced agent properties Infocenter page for more information.

So there you have it, these are the main features of 7.0.2. I have only touched very lightly on all of them, please see the Infocenter, or contact your local IBM representative to find out more!

I’ve been trying out the latest version of WebSphere Commerce (version 7), and one of the first tasks I’m working through is enabling WCS to use MQ as an inbound / outbound transport adapter.

The instructions for this are fairly clear in the Info Centre, apart from the point where; if you are using the Developer Edition of commerce, you require to enable the MQ Listener in WCS.

This used to be carried out by changing the config file wc-server.xml; by searching for the line “Listener for WebSphere MQ (TransportAdapter)” and setting the enable variable to “true”. The issue I found is that this file has moved between v6 and v7.

In v6, this file is listed as being in this location: WCDE_installdir/xml/onfig/wc-server.xml

I’ve found in v7 this file has been moved to: WCDE_installdir/workspace/WC/xml/config/wc-server.xml (e.g C:\WebSphere\WCToolkit\workspace\WC\xml\config\wc-server.xml on my system)



Thing is, marketing has a bad name, some go as far as to say, “it is pointless and unnecessary”. “Without marketing, our lives would be so much clearer, enabling us the freedom of our own thoughts and choices.”

Of course I am writing this blog because there is a ‘but’ here.

Think of your favourite band/artist, now think how many times that band has played a show and you missed it. For me, plenty of times.

What I am getting at is that without marketing we wouldn’t know what is going on. We would miss out. How would we know there was an iPhone/better phone than we have, only by word of mouth? Perhaps it would actually take much more time for us to walk round every shop and search the internet every week to find out what is the newest & ‘bestest’ thing for us to buy. I actually wish artists would advertised their shows more, or perhaps I should figure out how to get automatic updates…!

With marketing, sometimes there is a solution/product to a problem you might not have even identified as a problem.

For example, there is a new product that I am working on called Websphere MQ File Transfer Edition. Now, this product is awesome. It moves files (ANY SIZE-and they mean it) from anywhere to everywhere. No more attaching it to emails or sharing through FTP server. Ergh no. Fluid yet robust file transfers that you can do all sorts of cleaver automated things with!

Now… if you are struggling with FTP, or even if you don’t realise you’re existing system is not as effective as it could be, as long as marketing does not exist/is not effective, you would be non the wiser about this Websphere MQ File Transfer Edition product and the benefits you could be achieving.

Marketing should be helping you know what is out there and decide whether to invest. In this example, you could now receive a higher level of security, more reliability, less errors etc etc. Basically all sorts of things you would never have known you could do, if marketing did not exist and if people like me did not tell you.

Jeremy Kyle style however, there are both sides to the story… Is all marketing done well? Perhaps those that do not market ‘properly’ are those who abuse its ‘power’ and are those who give marketing, this perhaps undeserved, bad name?

I briefly tweeted a few Fridays ago about one of the new products IBM announced at the start of this month.

Regular / long-term readers will know that WebSphere Message Broker is one of my technology specialisms – it’s a product that I’ve been working with for 8 or so years now, through various versions. A few days ago I also mentioned in passing about the new version of WebSphere Service Registry and Repository. Both of these products are part of my day job, working in product strategy and development in IBM Hursley.

So let’s just review the announcements in the WebSphere Connectivity portfolio, and pick out some my favourite new features and enhancements.

• WebSphere MQ File Transfer Edition v7.0.2 – extension of platform support, enhanced security, richer scripting, and bridges to FTP and SFTP. As Ben says, it’s “cram-packed… with lots of good stuff!”.
• WebSphere Message Broker v7 – w00t! further simplification of components and prerequisites, a much enhanced administration interface, a multitude of new nodes, better integration with WMQ v7 (pubsub and HA), slicker integration with the BPM suite through SCA support… this product just keeps getting more streamlined, refined, and functional.
• WebSphere Enterprise Service Bus v7 (and Process Server and Integration Developer) – currency with the WebSphere Application Server and MQ platforms, support for the new Service Federation Management features, Open SCA support, and Business Space widgets.
• WebSphere MQ Low Latency Messaging v2.3 – enhanced high-reliability and self-management.
• WebSphere DataPower firmware v3.8.0 – lots of enhancements here, but some of the nicer things I spotted in the release notes are the improved load balancing, WMQ v7 support, JSON and REST handling, and more B2B capabilities on the XB60 appliance.
• WebSphere Service Registry and Repository v7
• WebSphere Service Registry and Repository Advanced Lifecycle Edition v7 – taking these last two together, WSRR v7 offers some great improvements in integration with products such as Rational Asset Manager and Tivoli Composite Application Manager (ITCAM) for SOA and the Change Configuration Management Database, REST and ATOM interfaces, the new Service Federation Management Console for cross-domain management and sharing of services, and widgets that work within the Business Space framework to offer an easy-to-recompose business interface to services and policies. As I mentioned the other day, I’ve been working closely with my colleagues in the WSRR team recently and this is shaping up to be a great update.

Take a look at the announcement letters for individual products for full details of what to expect.

I was just reading my colleague Ben Mann’s latest blog entry on the need to tinker with presentations etc. and I am very much the same. No document or presentation is ever done or finished. There is always some way to improve it, to make it sing, to have a clearer message. I have been feeling this more and more this summer as I have been building new presentations to align WebSphere Connectivity with Industry solutions – something IBM’s Smarter Planet approach has been doing for our complete set of offerings.

At times it has been tough going trying to tell the story, but then things drop into place. Sometimes it doesn’t require much change to make everything work. And mostly it seems to come down to one common answer. If you are telling the right message, the right story, it should be clear and simple. Telling it, building it, explaining it should all work. And trying to change it, improve it, should be difficult. Just as A-level Maths had you work out proofs for formula, and it would all work out neatly, or you knew you had done it wrong. If we can’t tell a compelling story in marketing, then we probably need to change our approach if not what we are trying to say. If marketing is done right, it should be obvious and we shouldn’t feel the need to change it.To some extent I think that is why SOA has been successful. SOA is actually a simple idea. People had already been doing it for years. Just formalizing it, and calling it SOA allowed everyone to agree, and now of course it is accepted, and has won the argument to all intents and purposes. Also it was probably the reason WebSphere MQ was successful. It was a simple idea, simply executed, allowing for a simple message…2+2=4 if you like.

So am I there yet with my latest marketing…not quite…but I think I have the basis for the proof, now I just need to follow it through, and show my working in my neatest handwriting. Fingers crossed for a good grade!

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.

Something I have learnt so far as an industrial trainee, is that people’s time is gold. Ok sure, we all knew that. However, what I am learning further is that people will spend their time on what they think is most important or most pertinent at that time. Tell me something I don’t know please young Dino.  Someone said to me, “I am a fireman, it’s who shouts the loudest that gets my attention”. Wow.

So, it doesn’t really matter if what they are asking is less important, as long as it’s sort of “pretty important/urgent” and they shout loud enough, they’ll get your time. Therefore, it’s about what/who has the ability/stubbornness to grab your attention. So much for “its the quiet ones that you must watch out for”? It’s appears to be more like a jungle in this respect.

Ok, all in all, not rocket science I know, but it is really interesting non-the-less.

You book someone out for a meeting, for something that would’ve taken ten minutes say over instant messenger/email, and suddenly you have their attention for half an hour, an hour, sometimes more.

I guess people like focus, and meetings are a way of doing just that.

In response to Leif’s comment on my previous blog, during the requirements process for Smart SOA products like Websphere MQ and Websphere Message Broker, IBM does give back much more, in fact we’ll spend sometimes an hour just discussing one requirement. Let alone the time it takes to create it and put it into the next release.
That process can only be done in a meeting, a set time where the appropriate people get together. Could you get an hour of so many peoples undivided attention in any other context than a face-to-face meeting?

But why couldn’t we pick up the phone and discuss or email? – because cold calling is seen as rude? But isn’t ignoring say, an email, just as rude? Or is that accepted now, being that with email you can prioritize what’s important. You are not being rude you’re just being smart with your time.
Why doesn’t email actually guarantee a response?
Why couldn’t they talk over instant messaging?

There are good reasons for all this but I found in essence meetings allow people to plan ahead, and make sure they have done what is needed in order to focus their attention on the task at hand. It is also harder to say no and just dismiss your question in person. A meeting also acts as a set deadline, a chance where less distractions are prevelant.

There is so much to this subject – here is an exploration study of a web-based conference system. This looks at the difference in effectiveness between virtual teams, and those who have the luxury of having these face-to-face meetings I talk of. Something very prominent in such a massive organisation such as IBM.

That is why it is common knowledge that if you ever need attention and action from a colleague, nothing beats booking a face-to-face meeting.

So how do you tie them down to a meeting….? How does this tie into marketing….?well that’s a whole other blog..

A long time ago I worked for the MQ Performance team, my current role is still loosely linked to that team as I am working on the performance for WebSphere MQ FTE. Recently I was asked to help a customer improve the performance figures that they were seeing from a JMS application. The application in question was actually the JMS Performance Harness, which can be found on Alphaworks. Many of the suggestions we made can be found in the myriad of performance reports that MQ delivers as Performance SupportPacs. These are delivered as PDFs, and as far as I know are not indexed by Google, which means that searching for information on MQ performance will not always give you the help that you were looking for. So I decided to compile the following hints and tips that you should use to improve performance.

Disclaimer: This post not sanctioned by IBM, and I am not copying information from the Performance reports verbatim. The following hints and tips are designed to improve the performance of your applications, when making changes to your environment you should ensure that the changes do not have unwanted side effects. Myself, or IBM, are not responsible for loss of data etc etc when using this information.

1. Use non-persistent messages where possible. Using persistent messages will require MQ to write the data to disk, which can be a performance bottleneck.
2. If you need to use persistent messages, ensure that you have are either using a separate disk for your MQ log files, or in an optimal scenario are using battery backed cached disks, for example a SAN.
3. Even if you are using non-persistent messages, the per queue buffer size might mean that MQ writes the non-persistent messages to disk. To avoid this you should set the DefaultQBufferSize and DefaultPQBufferSize for your queue manager to larger values. The default is 256kb
4. If you are using Channels, you can set the BindType to be FASTPATH. This will effectively reduce the CPU usage on the server, but it does mean that custom UserExits that are poorly written will not only crash your channel, but your queue manager too
5. MQ Version 7.0 introduced a new channel property called sharecnv. This property defines how many threads can use a single socket (the default value is 10). Setting this value to 1 may improve performance by limiting a single thread per socket.
6. JVM heap size is also important. Ideally you want to limit the number of times that the Garbage Collector is called. MP07 recommends that optimal GC interval is around 1-2 seconds.

The above points are by no means exhaustive. They are meant to stimulate MQ users into thinking a little more about getting the most out of the Queue Managers, and their applications.

MQ put a lot of time into developing Performance Reports, and it would be remiss of me to not mention them in this post. For each performance report there is a section that discusses performance for the platform (with the exception of the JMS report that is platform agnostic). The above points should be used in conjunction with the relevant report. The following is a list of links to the most recent reports for MQ Version 7:

• MP07 – MQ Version 7 JMS Performance Report
• MP6N – MQ Version 7 AIX Performance Report
• MP6P – MQ Version 7 Solaris Performance Report
• MP7I – MQ Version 7 Windows Performance Report
• MP6O – MQ Version 7 HP-UX Performance Report
• MPL5 – MQ Version 7 Linux Performance Report
• MPL6 – MQ Version 7 Linux (zSeries) Performance Report

I recently posted about my first WebSphere SupportPac (FA01). The SupportPac basically allows your FTE network to be defined within WSRR using custom models. Although there is a pdf detailing install/setup contained in the download for FA01 I thought it would be useful to document here the steps required to install and configure the plugin. This information is for Version 1.0 of the plugin. Future versions may require different steps.

Software in use for this blog post
WSRR 6.3 using DB2 for its database
WMQ FTE 7.0.1

Installing the Plugin
All the following steps take place using the Configuration Perspective of the WSRR web application.

First install the plugin jar file, this is performed under the “Active Profile -> Plugin JARs” section. Click “Load JAR Plug-in”, browse your local filesystem to find the FA01 jar, call it anything you like – preferably something related to FA01, or WMQFTE. Now that we have loaded the JAR into WSRR’s classpath, we can now load the model and setup the ServiceDiscovery configuration.

In order to create the required objects in WSRR we need to pass in the OWL file which defines the objects in use by the plugin. The fte_model.owl can be found in the zip file under the folder called models. Navigate to “Active Profile -> Classification Systems”. Click “Load Classification System” and using Browse locate the fte_model.owl file. You should then see WebSphere MQ FTE Entities in the list of Classifications:

WSRR Classifications

WSRR now needs to now how to run the plugin. This is done using the “Active Profile -> Service Discovery”. Clicking on the ServiceDiscoveryConfiguration link will take you to an xml editor in which you can setup FA01. Look at this xml file (WordPress don’t allow txt files, so you have it as a .doc :S), you need to paste the contents of that doc into the xml editor, make sure you paste inside the tag at the bottom of the editor. You need to change the qmgr/host/port/channel values to reflect your coordination queue manager settings. Click OK to save this configuration.

Finally to enable regular running of the plugin we need to configure the scheduler. This can be found again using the menu option “Active profile -> Scheduler”. You should see the ServiceDiscoveryScheduler, which when clicked will again give you an editor with some xml. You need to add the xml from this Scheduler Config document. Change the intervalGranularity and interval values to suit your needs. Check the WSRR Infocenter for allowed values. Once you save this the Scheduler should run your plugin, and the FTE Concepts should start to appear in the relevant Perspective.

If you experience problems with the ServiceDiscovery Plugin, check your WSRR SystemOut and SystemErr logs, as the plugin will output information that will help to diagnose the problem