JBoss ESB 4: SOA beyond SOAP/HTTP

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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.

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.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.