Workday Announces Cape Clear Acquisition

Workday announced today that it is acquiring Cape Clear. We’ve already been working closely together over the last couple of years, so it is very exciting to become part of the Workday team. We will now be focusing on delivering Integration On Demand. This is a great opportunity to deliver the integration capabilities that we’ve developed over the last few years in new ways to workday customers.

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.

The New Cape Clear Assembly Editor

The release date for Cape Clear 7.5 is only a few days away. For those of you looking forward to getting your hands on the new Assembly Editor, here’s a quick demo of the Assembly Overview sample included in Studio.

Here's a high resolution version.

SOAP or REST, Have It Your Way!

While it would be premature to say that the SOAP versus REST debate is over, it does appear to have reached an uneasy truce. In practice we often encounter situations where both REST and SOAP style Web services need to be used together.
The Cape Clear ESB has always provided excellent support for SOAP based services, so one of our goals for 7.5 is to ensure that our support for REST style services is just as good.

This video shows how easy it now is invoke a REST style service from BPEL using Cape Clear 7.5. In it I show how using one of Yahoo’s services is simply a matter of copying and pasting a couple of URL’s from their web site into a new wizard in the BPEL editor. I think you’ll have to agree that we couldn’t have made it any easier and you’ll also learn where to get the best pizza in Palo Alto.

Here's a high resolution version.

ESB Driven On Demand Integration

I recently had the opportunity to talk to Michael Lippis of the Outlook Series about how SaaS providers are turning to ESBs to address their integration needs. The very fact that SaaS providers need integration solutions could be seen as a thorn in the side of their business models. Customers need their existing on-premise applications to exchange data with their SaaS solutions. However, they are reluctant to take on the overhead of solving this integration task.

Cape Clear’s ESB has been used many times in such situations and Michael and I discussed the JP Morgan use case. It’s a good example of how these issues can be addressed. Of course, using the ESB in this way changes the focus and introduces some new requirements, as I blogged recently.

You can hear the discussion here.

It's like a Press Release, but better.

I’ve recently has some small involvement in the creation of a few press releases. This really is a very formal process with many rules for how they should be created. Deviate from them at your peril. See for yourself with some of the articles that have been written on the subject. All these formal rules for such a short piece of text reminded me of how we used to dissect poetry in English literature classes at school. Each rhyming couplet would be analysed in detail until it seemed that the poem lay in pieces before us ready to be discarded in favour of the next victim of the dissection process.

Anyway - it seems to me that if we are going to put all this effort into crafting a short piece of text we could at least make it rhyme or even go so far as to produce a sonnet. Perhaps instead of marketing consultants, we should engage the services of a poet. The end result would be much more pleasant to read.

In the absence of an official Cape Clear poet – I’ve put pen to paper (with a lot of help from Trish) and rewritten our recent Cape Clear 7.5 press release. You’ll have to tolerate a Limerick, as a sonnet is well beyond my poetic capabilities, but I’m sure you will find all the essential information is included:

There’s a great new product I hear,
Whose release date is drawing quite near,
If you need mediation,
or on-demand integration,
The solution is here at Cape Clear.

ESBs on the Edge

Two distinct use cases are emerging for Enterprise Service Buses: firstly many organizations are using ESBs internally as the enabling infrastructure for their Service Oriented Architecture. The second use case places the ESB on the edge of the network in a role more traditionally occupied by B2B integration solutions.
This second use case is being used by organizations providing Web service interfaces to their business and in particular by pure play Software as a Service (Saas) providers who realise they need to take a proactive approach to their customers' integration issues. This may even involve hosting some portions of the integration solution on behave of the customers. An ESB deployed in a SaaS environment requires additional features over and above those of an ESB used internally. For example:

• Multi-tenanting support is fundamental to the SaaS model, but good support for it is not available in many ESBs. Hosting integrations on behalf of customers requires that data generated as a result of messages flowing through the ESB is segmented on a per customer basis. This applies to a whole variety of information stored in log files, activity reporting and data stored in databases. The segmentation of data in databases also applies to languages such as WS-BPEL which are heavily dependant on the persistence of data. The SaaS provider may need to make this data available to their customers in order to provide the same level of visibility into their integration solutions as they do for their core services.
• Scalability and Performance requirements for SaaS are typically more demanding than within the enterprise environment. The ability to deploy within a clustered environment is now a must.
• Productivity tools are vital. It must be possible to create integration solutions quickly for customers. Within the enterprise, an integration project might have been viewed as one off projects. For the SaaS provider they are now a normal part of providing access to their systems to each new customer.
• The software license model for the ESB needs to be consistent with the on-demand or per user billing model for the SaaS provider.
• The ability to deploy client side instances of the ESB is also important as the SaaS provider may not want to host all the integrations. For this scenario, ease of installation and maintenance is vital as is the need to work within a wide variety of IT environments.