WebSphere Message Broker and WebSphere ESB

People are sometimes confused about the differences between WebSphere ESB (built on top of WebSphere Application Server, and using the inbuilt WebSphere Platform Messaging JMS provider) and WebSphere Message Broker (which uses WebSphere MQ as a messaging engine). IBM sometimes describes the latter as ‘Advanced ESB’, but Message Broker is not a superset of the functionality in ESB. There is a good FAQ on the IBM website which clears up some of the confusion.

In general, Message Broker is designed for working primarily with WebSphere MQ, as well as having a larger set of nodes (or mediation primitives, in WebSphere ESB-speak). WebSphere ESB has a richer set of functionality with respect to SOAP and Web Services (Message Broker treats SOAP as plain XML). ESB is also built on SCA, which allows it work more easily with products such as WebSphere Process Server.

ESB and Message Broker can work together: using the MQLink functionality in WebSphere Platform Messaging, ESB can simulate an MQ server and exchange messages with MQ accordingly. They can be complementary and both form part of an SOA solution.

Five Easy Pieces

I’m 50:50 about this film, really. I wanted to like it. It does contain plenty of classic Americana, some nice shots, and some very competent acting from Nicholson and others. The central scene of the film, where Nicholson is trying to order in a diner, is also him at his sarcastic best: work we’ve also seen in later films like As Good As It Gets.

But fundamentally, the film is actually quite boring. The premise has potential: concert pianist turned oil rigger returns to his roots. But the execution is so dry, so tedious, that it really just didn’t hold my interest. The film ends without any conclusion, and is ultimately unsatisfying.

What's in a name? (or: Who exactly are we selling to?)

There’s a tradition in the technology industry of a ‘user’. This, apparently, is the poor sod who’s going to ultimately use whatever you’re creating (software, steering wheels, microwaves, and so on). We’re not sure exactly who he is, but he must exist, right? Many of the more theoretical parts of software engineering use this term, for example: user-centered design, user interfaces, user error (a most horrifically arrogant expression), etc.

As a work for a commercial company, I resolved to give up using this word a few years ago, and call these entities ‘customers’ instead. I figured this would encourage me to be more customer-centric (duh). I’ve been relatively successful at giving up my addiction to ‘user’, and use of ‘customer’ reminds me that a feature / bug / product that isn’t important to one of our customers, although it might be important to a ‘user’, isn’t important to me either. After all, we’re here to make money, right?

But a recent article of Don Norman’s has convinced me that this approach, too, is damaging. Not as harmful as ‘user’, but still wrong. ‘Customer’ works fine for the business. But customers don’t want to be customers. They want to be people, and they want you to care about them and their needs. Thinking of them as people is a reminder that they have human values and failings, and should be recognised in a human way rather than as entities who exchange money for goods and services. Of course you want that exchange, but you don’t want them to feel like that’s the sole purpose of your relationship - otherwise you exclude yet another way for you to differentiate yourself from your competitors (others of which include producing good quality products, cheap products, faster-to-market products, and all the others we know and love).

As such, I plan to try and wean myself off ‘customer’, and onto ‘people’. Please let me know if I lapse.

Would you like some process with that project, sir?

I work in software development, where process is a hotly-debated topic (some think there should be little, some a lot, some think it should be of this type, some of that). Some people can’t even spot a process when it’s staring them in the face, and, to be fair, the definition of processes is not exactly cast in stone.

Scott Berkun understands processes well. He makes an accurate analogy between a good process and the white lines separating lanes on a highway: they restrict the (intended) movement of vehicles, but help everyone to travel faster and more safely. They don’t intrude, they help. Perhaps a slightly more tenuous extension of this analogy to bad processes would be where the lines are constantly shifting about or the lane schemes being re-arranged, in an attempt to improve matters, but actually confusing everyone and slowing them down.

So the important thing to understand is that more process is not necessarily bad, more bad processes are bad (for example, in software products of any significant size, some level of source control is a good thing - but awkward source control will annoy people and encourage them to find ways round it). Over lunch I was listening to some colleagues talking about process, and I came to an important conclusion:

  • People whose sole job is to invent and maintain processes will almost certainly come up with bad ones.

This is because they have no motivation to help, only a motivation to keep their job going, and that means more process (and probably ill-thought-through process). Processes should, with some minor exceptions, be invented with participation from those they affect, as they have a motivation to get it right. If there isn’t a strong enough motivation for them to help come up with a process, they obviously aren’t being bothered enough by the status quo and the process probably isn’t necessary.

Near-human Tasks

This morning I was writing a test plan document. It contained lots of technical nitty-gritty and detail, but a lot of it was the same stuff repeated over and over again. It was very tedious to write (and hence undoubtedly error-prone), but necessary. I kept thinking how useful it would be if I could automate the process. I knew it was just a little too complex, and contained a few too many exceptions, though, that writing a program to do it would be more trouble than it would be worth.

This led me to thinking about ‘near-human’ tasks. Perhaps we can classify tasks into three board areas:

  • Automatable. These are tasks that can easily be programmed, and where it makes sense to do so once you have a computer. For example, figuring out the prime numbers between 1 and 1 million is far faster on computer than by hand (including the time to write the program).

  • Non-automatable. These are tasks that almost certainly cannot be programmed, even with the current state of AI, and are often open questions: ‘How do I prevent wars?’, ‘Is global warming real?’, ‘Which way should I design my new product?’, ‘What’s the best colour for a car?’, etc.

  • Near-human, or semi-automatable. These are tasks (such as mine above), that feel like they should be automatable, but anyone who has any software engineering experience knows that they will spend more time writing the program to do it than doing the task (although only by a factor of up to 10, say).

It wouldn’t surprise me to discover that near-human tasks are an already-understood concept, probably in the field of AI or some other computer science theoretical field (possibly something I should already know!), and that I’m reinventing terms here. But maybe they an area that we can focus on more in order to overcome some frustration with the menial tasks that annoy us?

One possible example, although more automatable than my original one, is that of detecting spam. Relatively good spam filters now exist for email, with ~1% false negative rate and next-to-no false positives. These spam filters have been probably been technically possible for some time (although they still eat a fair amount of compute resources), but have only risen to prominence in the past few years because the rising tide of spam has made them necessary. They are still not perfect, which in my mind is what keeps them out of the fully-automatable category (the writers are always one step behind the spammers, and would have to do more work than is worthwhile, or maybe even possible, to get a 0% false negative rate), but they are getting closer.

What other examples of near-human tasks exist? What should the bright software engineers of tomorrow be working on to make our lives easier?

subscribe via RSS