, , , , , ,

One of the problems I often face when encountering some new enterprise product, ‘solution’ or technology is having to dig through a word salad of marketing speak to get a vague idea of what a vendor’s product actually does. This is especially true when it comes to learning how I’d be developing APIs and getting applications to work with an ‘Enterprise Service Bus’ in my new job.
The best literature on the Enterprise Service Bus relates to Apache Synapse. Almost all the other material on this is provided by vendors – the three main ‘solutions’ I’ve been looking at were JCAPS, Fiorano and InterSystems Ensemble, which are all heavily used for integrating clinical/medical applications here in the UK.

It’s easy to get a logical representation of what an ESB is roughly supposed to be. This example is from Fiorano’s documentation:

(Fiorano, 2015)

(Fiorano, 2015)

Obviously this is a logical representation of multiple services using a common channel to communicate, and the channel isn’t limited to any single message type. The applications themselves are coded in different programming languages.
But what exactly is being sent and received on the bus, and how are those messages formatted accordingly without heavily modifying API code? Is the ‘bus’ a cable, a server box, or what? What the hell is an ‘integration pattern’? What we do know is that an ESB is a) software-based, b) provides a common interface for independent services to communicate, and c) has something to do with APIs.

Let’s look at Apache Synapse as an example:

(Apache Synapse, 2012)

(Apache Synapse, 2012)

To the left of the diagram there is a ‘Transport’ component, which appears to have interfaces listening for the various message types, and might have something that determines what to extract from each message prior to it reaching the Message Builder or Message Formatter. The Builder and Formatter, I’m guessing, reformats the data extracted from the original messages. The QoS component handles the routing and prioritisation, based on the TCP headers of the message.
Finally, in the Mediation Engine, which appears to perform the bulk of the message processing. Within the Mediation Engine, there are ‘Mediators’, each of which is described in the Synapse user guide as a ‘processing unit’ that performs a specific action on a message. Examples of what a Mediator could do include:
* Drop message
* Log message
* Send message to endpoint
* Rule-based filtering
* Modify URLs within message

Mediators can be chained to perform a sequence of these operations.

The important point about Synapse, and perhaps all the other ESB ‘solutions’ is that it runs on a physical machine, as a server on the network that listens for incoming messages, relays the messages to another process and sends the result back out to whichever service. Logically we have a message bus, but physically it’s pretty much a proxy server.

Thing is, I’m not sure why an enterprise network would require an ESB in the first place, or why it would be appropriate to have one. If we have several applications that need to communicate, why not simply do that through API or stored procedure calls? Adding yet another layer to this seems pretty redundant.