JBoss ESB 4: SOA beyond SOAP/HTTP

Posted by Stefan Tilkov on Feb 05, 2007

Community

SOA

Topics

ESB

Tags

JBossESB ,

JBoss

6 months after acquiring the Rosetta ESB from a Canadian insurance provider, JBoss has released a GA version of JBossESB 4.0, its open source ESB product. According to JBoss the ESB supports SOA concepts independently of Web services.

According to the announcement, JBossESB features include

• support for general notification framework. Transports supported include JMS (JBossMQ, JBoss Messaging and MQSeries), email, database or file system.
• trailblazer example.
• support for data transformations using Smooks or XSLT.
• listeners and action model to support loose-coupling of interaction steps.
• content based routing using JBoss Rules or XPath.
• support for registries, using JAX-R and jUDDI out-of-the-box.
• durable object repository.
• high performance and reliability

InfoQ sat down with Mark Little, JBoss Director of Standards and JBossESB development manager, to find out more about the product. (As an aside, Mark is also an InfoQ editor for the SOA community). As an obvious first question, we asked about the improvements have been made to the original code base since the acquisition:

Rosetta was a 3 year old ESB and the notion of what comprised an ESB back in 2002 is different to what people expect today. The fact Rosetta has been in active deployment for 3 years continuously is obviously a good thing for us, since none of the other open source ESBs can say that. However, ESBs and SOA have rolled forward and that means we have some catch-up to do from a functionality perspective. Therefore we've been trying to make sure that the core of the system has remained stable (the architecture was very forward-thinking for 2002) and add in new services and capabilities, such as Contend Based Routing and transformation.

Mark confirmed that many concepts and APIs of JBossESB are similar, but not equal to standard WS APIs and/or wire formats:

The ESB project actually started before the Rosetta acquisition. From the start we decided that Web Services are important but they're not the only way in which we want to support SOA development for our customers. JMS, HTTP, TCP/UDP are just as valid. So we wanted an architecture that supported Web Services, but didn't preclude other infrastructures. However, I've been involved with Web Services for a very long time and have seen how they've been evolving from XML RPC to asynchronous message passing and that approach is one we wanted to project within the product. Plus, there's almost a full architecture now for Web Services that addresses many of the enterprise requirements. Again, that's something we want support for within JBossESB. Therefore, rather than re-inventing the wheel, we decided to try to leverage some of the approaches and APIs that are being used (or still being worked on) in Web Services. The only caveat is that we don't want to mandate SOAP/HTTP.

When asked about plans to support e.g. JAX-WS, the final WS-Addressing specification, or WS-Reliable Messaging, Mark pointed out that while these are not available yet, they are scheduled for 2007:

We'll be supporting JBossWS, which is implementing JAX-WS. However, as with our entire architectural philosophy, we'll also support other Web Services stacks. JBossESB (and SOA) is all about leveraging existing infrastructural investments, so fro the outset we decided that we would always try to work with whatever customers currently have. Therefore, if you don't have a Web Services stack we'd obviously recommend our own, but if you've already made a choice then you can just plug that in instead.

Reliable message exchange is also something that will be coming in 2007, according to Mark. While JBossESB will support WS-RM for those who are using a Web Services deployment, equivalent capabilities will be provided if they're running over e.g. JMS or TCP, Mark pointed out.

With regards to WS-Addressing, Mark said:

As for WS-A, well we already support the initial submission to W3C (WS-Addressing 2004). We have an implementation of the Candidate Release, which we have been testing with the likes of IBM and Microsoft at various interoperability workshops. I'd expect to see us using that within the ESB in 2007 too.

JBossESB used jUDDI and Scout to provide a registry service. When asked about the registry service's importance for JBossESB, Mark said the it is meant to be a stand-alone component that can have multiple different backend implementations:

The API that we've settled for is JAX-R, but the out-of-the-box implementation is UDDI based. If people want to replace that then they can do at runtime with anything that provides similar capabilities. At the moment we're using the registry to store information about services (their addresses, or endpoint references, and some minimal contract information). In 2007 we're going to be extending out use of the registry quite a bit.

The ESB concept means different things to different people (as evidenced by the heated discussions on the topic here at InfoQ; see part 1 and part 2), so we asked Mark to summarize JBossESB's functionality in two or three sentences. Here is his reply:

In so much as SOA can be supported by software, then JBossESB is a SOA infrastructure: the model presented to users is based on services communicating via messages and the contracts between client and service maintained, as much as possible, in the message and basic service interface. JBossESB provides the capability for users to develop business components that are not tied to any specific underlying messaging infrastructure; in fact you can have the same service listening on multiple different buses (communication channels) simultaneously. Finally, the ESB also supports on-the-fly message transformation and routing, based on message content. This latter capability is simple yet incredibly powerful and I can see us expanding on that in the coming year.

JBossESB 4.0 is licensed under LGPL and available for download at the JBoss website.

• Older >