What Clients Do I Get with WebSphere ESB?

So it’s Christmas morning, and you’ve unwrapped the shiny paper, and you see that Santa has left you a copy of WebSphere ESB 6.0.1. You’re keen to get going on developing your first SOA solution, but you’re a little bemused by the ‘Message Service Clients’ inside the jiffy bag, on CD2. Well, here’s what they are:

  • IBM Message Service Client for C/C++ (aka C/C++ XMS) - this is available for Windows and Linux.

  • IBM Message Service Client for .Net (aka .Net XMS) - this is available for Windows only.

  • IBM Web Services Client for C++ (aka WSCC, CWSS) - this is available for Windows and Linux.

These packages allow you to build client code that can be used against a WebSphere ESB system (as well as other messaging systems).

The XMS clients are essentially re-implementations of the JMS API in their respective programming environments: C/C++, and .Net. They are designed to match the JMS API as closely as possible, and are thus useful for client developers who are already familiar with JMS. The clients can work with three different JMS provider families:

These families use different wire protocols for the JMS messages, so the family being used has to be specified in the client application. Otherwise, though, the API is identical.

The WSCC client is slightly different: it allows one to write a web services client in C++ from an existing WSDL web service specification (such as one produced by ESB when one uses a Web Services Export in a mediation module, for example). Typically this is done using the supplied WSDL2Ws tool to create stubs that can be used to create the client.

The clients are also available as IBM SupportPacs for download, although you’ll want to check the licensing conditions for your support status when using these.

(Note: the ‘Application Client for WebSphere Applications Server’ is also shipped with WebSphere ESB, although, as the name implies, this isn’t specific to ESB - it’s the same client available with WAS). For more information, see:

  • The excellent article on IBM Developerworks - Introducing XMS.

  • The comprehensive documentation for the WSCC client - the file wscc.pdf in the docs/ directory where the client is installed.

What is WebSphere?

I still meet a lot of people who are confused by the term ‘WebSphere’. Let’s clarify, as it has two oft-used meanings. The first, which IBM encourages, refers to the WebSphere brand of software. This comprises many products (probably over 100 once all variations are taken into account), most of which are somehow related to middleware or integration. Included in this brand is the product WebSphere Application Server (WAS), upon which several of the other products are based. The second meaning of the word is as a synonym for WAS, and is popularly used outside IBM (and sometimes inside, when IBMers are feeling lazy). If someone asks ‘do you know WebSphere?’, they are almost certainly using the word to refer to WAS specifically.

For more information, see the Wikipedia entry for WebSphere.

OpenOBEX and Nokia 6630 (progress)

After getting a 1GB MMCmini card for my new Nokia 6630, I decided to have another go at getting OpenOBEX working with it. After applying a patch from the forums, I’ve now got ObexFS working over USB; I can mount the phone’s filesystem locally. The only problem seems to be that I can’t create directories, which makes syncing MP3s cumbersome. Argh! I’ve signed up for the mailing list so hopefully will get some help there.

Why Local Papers are Normally Useless

There was a front-page story in my local paper the other day - NewsEXTRA, the freebie cousin of the Hampshire Chronicle - about a knife amnesty. Apparently Hampshire police have been running one and are clapping themselves on the back because they’ve recieved so many (3000 in Hampshire, almost 100 in Winchester).

There are two problems with this:

  • The police are sending an inconsistent moral and practical message. Is owning knives wrong? One can assume it must be - after all, people have been handing in ‘peeling knives’ - and otherwise, the police would reject those, right? But in which case, er, how am I supposed to peel my carrots? Oh, maybe knives over a certain size are wrong? So are museums supposed to turn in their collection? The police should get their principles straight before they try to make people feel bad for owning knives per se. Disclaimer: I only own kitchen knives.

  • The headline was ‘Amnesty Success’. How do you know? If no-one was going to be injured by those knives (we’ll never know), you’ve just deprived several hundred members of the public of their knives by making them feel bad for … er, owning property. This would be less than a success. Instead of jumping to conclusions, one would hope that the paper would employ at least some inquisitiveness and dig a little deeper. But what else would you expect from a local freebie, I suppose?

Maybe all of this sloppy journalism explains why such papers normally go from my mailbox to the bin without stopping.

What is an ESB?

I recently had a comment attached to one of my posts regarding ESB suggesting that it needed to be translated into English - so that’s what I’m going to attempt to do here. An ESB is a fairly new and complex concept, and the definition is far from fixed, so don’t be surprised if you see some disagreement. As with many things, though, it’s also a generalisation and aggregation of some other concepts that already exist, so be aware of that too.

An ESB is a fairly abstract architectural idea, but I’d best describe it as ‘a place where messages are stored, routed, modified, created, and destroyed’. It’s probably easiest to describe this with some history (so apologies if you know some of this already), and I’m going to use IBM’s products as examples, simply because they are what I know best.

Enterprise messaging has been around for some time. IBM’s classic product in this area is WebSphere MQ (formerly MQSeries). MQ runs as one or more servers, which contain queues. Messages can be placed on queues by applications (originally using MQ’s own MQI API, now using industry-standard JMS). Other applications can retrieve messages from the queues using the same APIs. This allows data to be easily moved asychronously between platforms, systems, etc. One of the key points about products such as MQ is the way that the messages are treated - typically with ACID properties similar to the way databases treat data. This means you can be confident that once a message has been sent, it will eventually reach its intended destination (or somewhere that it will be noticed). This provides a reliable base for integrating different applications (the original attraction of messaging systems like this). Originally, messages were typically in a proprietary format, but they are often now in XML with an associated Schema.

It was shortly realised that it would be useful to add some form of brokering. IBM’s product in this area is called WebSphere Message Broker. Typically, it is used to build on the capabilities of MQ. It allows you to develop (normally without programming) ‘flows’ that pick messages off queues, transform them, route them, etc., then place them back on other queues. Message Broker also allows one to work with adapters, meaning that flows can input from, or output to, things that aren’t queues. In this respect, Message Broker is essentially a generalised MQ application.

Later on, IBM released a new messaging engine, similar in some respects to MQ, as part of WebSphere Application Server (WAS). It is formally called WebSphere Platform Messaging and is part of the J2EE standard which WAS conforms to. Many other application servers also exist, with their own JMS engines, some open-source.

In recent years, web services have started to come to prominence, particularly as part of creating a Services-Oriented Architecture (SOA) for an organisation. They utilise a slightly-different, but related, model for integrating applications from that of enterprise messaging. Typically, an application makes a synchronous request over HTTP, using a message format called SOAP, to a back-end service, which does some work for it. Many services send back responses. These services typically run on application servers.

WebSphere ESB brings together many of these concepts. It contains all the functionality of WAS (including the messaging engine), but also provides ‘mediation flows’. These are similar to flows in Message Broker in that they allow one to pick up messages from JMS queues and modify them, audit them, etc., before passing them on. However, it also allows mediation of Web Services: for example, one could invoke a web service provided by ESB, which invokes another web service, and ESB then does some processing on the result before returning it to the original invoker.

So now we are in a position to define an ‘ESB’ in the generalised sense - in all these interacting systems, it comprises the messaging engines and the brokering and mediation capabilities. The applications that send and recieve messages, provide and invoke services, are those that sit outside the bus. As such, one doesn’t need any particular product to have an ESB (including WebSphere ESB). ESB is often seen as a pattern rather than a product: just a statement that the bus and the applications are distinct. You could build one with MQ and Message Broker (or even MQ alone if you didn’t want brokering capabilities). WebSphere ESB simply provides extra mediation capabilities, including the ability to mediate web services, without doing a lot of leg-work.

It’s worth clarifying that an ESB doesn’t necessarily have to have anything to do with multicast (although some ESB systems do include the notion of splitting and aggregating messages, which has some similiarities).

This is a large and complex topic, so it’s hard to do it justice in a blog post, and I’ve simplified vastly on some topics above. In particular, I haven’t really discussed any business process management. But I hope I’ve cleared some things up. If you’re interested in learning more, the following might help:

Alternatively, as always, please post a comment and I’ll do my best to answer it.

subscribe via RSS