Spring and the ESB - A New Approach to Implementing Extensions

The term usability is typically used in connection with graphical user interfaces. However, it is just as important to consider usability when designing programming interfaces. Like all other ESBs we provide extension points allowing developers to extend the platform. This is typically achieved by implementing the appropriate Java interface for that extension point. Recently, I’ve been considering the usability of these kind of interfaces.

The extension APIs available on the various message processing platforms share a number of common characteristics. You typically find a representation of the message itself, the message context (including transport headers associated with the message) and some lifecycle methods to control the initialisation of the extension. These extension APIs need to allow for all eventualities, so the developer can be exposed to a lot of information.

One difficultly I see with these kind of interfaces is that they usually present the data using a different set of classes to the one the user actually needs. The user may be presented with a javax.activation.DataHandler when what they need is a javax.xml.transform.Source or an org.w3c.dom.Document. When it comes to addressing this issue, the state of the art appears to be to solve it through documentation, code samples, or utility conversion methods. To put it another way – the developer is exposed to the full complexity of the system and then given a set of instructions on how to scale this back to the simple scenario that is relevant to their use case.

The extensions developers create typically have a very specific purpose. It would be much better if the developer could have an extension API specifically designed for the use case they are dealing with. No one interface is going satisfy all use cases. So we need to reverse the way in which we think about these interfaces. Instead of the container having a generic API that the developer must implement, the developer should be able to define their own API that the container should then call.

For example, a message transformation processing step (such as a call to an XSLT processor) just needs access to the message content represented as a javax.xml.transform.Source . The message then needs to be updated with the transformed content. Wouldn’t it be a much better starting point if the ESB platform could call a user defined method such as this:

javax.xml.transform.Result
transformMessage(javax.xml.transform.Source input)

In another scenario, an extension point that makes a routing decision might just want access to the message headers and the ability to return an endpoint URL. If the developer could implement the following method it would allow them to concentrate solely on the task in hand.

java.net.URL selectEndpoint(java.util.HashMap messageHeaders)

Allowing the developer to dictate the API greatly simplifies the coding task. We just need a platform that can call a wide variety of methods.

I’ve implemented a prototype in order to try out these ideas using Cape Clear Assemblies. The prototype is available in the Assembly Gallery. Instead of implementing the CustomMediationStep interface, the developer can design their own method signature using a variety of different Java classes. The extension is then configured as a Spring bean. The name of the method to call is also configured within the Spring bean definition. The SimpleMediationStepInvoker class deals with the conversion utilities and has some reflection code in order to call the developer’s API. This is the kind of code that we plan to move into the ESB platform itself.

A convenient side effect of this approach is that it allows developers to write their code without introducing any dependencies on APIs provided by the container. This is a feature that we regularly get asked for and it is one aspect of Spring that I really like.

Hopefully this sample gives an idea of what is possible with this approach. There are many ways in which we could extend this such as adding support for more data types or applying the same principle to other extension points. Do let me know what you think of this approach to extending Cape Clear Assemblies.