I had a briefing with CapeClear a few weeks ago which got me thinking. For quite a while I had thought of an ESB as primarily being SOA message and interface management software. But actually, that is not where the origin of the ESB lies. ESBs developed out of the EAI products, which were the IT industry’s best attempt at application integration before SOA was even an acronym. ESB’s became part of the SOA picture because they could play a useful integration role. Most such products had useful sets of interfaces to legacy environments that couldn’t simply be wrapped up as web services.

CapeClear was floating the concept of “on-demand integration”. It’s marketing speak, naturally, but backed by the claim that its ESB’s caters for multiple channels on the client side and multiple tenants on the provider side – which it certainly appears to do in its latest incarnation. There’s some architectural thinking in this, so hold on to your hat.

What does Multi-Channel mean?

It means having multiple ways to access the same service (through an ESB). An access path to any specific service may involve transport, policy application, access to associated services (such as security), error handing and catering for different routes. It also involves considerations such as performance – there’s no point in making the call if there’s no answer within a second, say. A channel can clearly be complex, and it can be thought of as a “program” in its own right – or it would be if you couldn’t invoke it simply by describing it – which is what CapeClear is about. From this perspective an ESB looks like a mediation engine more than anything else.

What does Multi-Tenanted mean?

This is the other side of the equation, where the ESB attempts to deliver what a variety of different clients request. The complexity on this side of the line is that different clients need different service levels, so the serving component cannot necessarily be a one-size-fits-all instantiation. The two big considerations here are security and performance and it is easier, from an architectural perspective, for the ESB to deliver these things if it can, leaving the “server process” to do what it does.

So what is the ESB, in these circumstances?

This perspective puts the ESB in the position of mediator – with the client and server processes simply stating what they want (i.e. stating their requirements or policy imperatives) and the ESB looking after the details that neither client nor server is capable of doing – either by calling other services or providing its own. This allows both the client side and the server side to be “stateless” in respect of global policy.

What is important about this idea?
First of all, this view is what I like to think of as “SOA realistic”. The reality in complex SOA environments is that there really will be multiple clients and multiple providers and the characteristics of a specific service requested by different clients will not be identical. A simple example might be requesting an exchange rate for making a commodities trade in a fraction of a second and requesting an exchange rate for use on an invoice that will be sent by post at the end of the day. You may go to the same service for the data but the invoice can wait and the commodity trade is real-time – it cannot. So here the ESB becomes the instrument that implements the service level policy.

Secondly, putting SOA to the side, it is possible to think of the ESB as a vehicle for integrating mash-ups. For this, the key point is being able to achieve “on-demand” integration by describing the channel to the mash-up (which could be a service within or external to the network) in terms of transport, error handling, connectivity and any mediation steps. When mash-up components are external you cannot guarantee service levels, but you can monitor them and learn what they tend to be.

CapeClear provides a complete Eclipse-based development environment for assembly and mediation using its ESB, which caters for both Java and BPEL. The latest version, discussed above, has only just been released so it’s not yet clear how customers will use it, but it is worth noting that CapeClear has already been deployed in anger to integrate SalesForce.com applications with in-house applications, so some of the external integration capabilities have already been proven to some degree.

The idea occurs to me that the ESB – rather than a UDDI registry – will probably become the initial vehicle for mediation between different SOA environments. This means that mediation will be peer-to-peer before it becomes registry based. That’s the pragmatic route and pragmatism normally triumphs in our industry.