WebServices dot org

With the recent acquisition of Arjuna technologies’ transactions and Web services transactions technology and people, JBoss is making waves in the enterprise Web services space. WebServices.org spent some time with JBoss’ director of standards, Dr. Mark Little, to understand the JBoss strategy in Web services, WS-*, SCA, and the ESB market.

Q: JBoss has made its reputation by providing solid open-source solutions in the Java and J2EE space; there has been a tipping point recently where JBoss really became active further up the stack. Could you elaborate on that strategy?

Little: Although it's true that JBoss have been more visible in the JEE space (Sun dropped the 2 earlier this year), they have been supporting Web services applications for several years -- even before J2EE moved into Web services with the 1.4 platform. It's just that they haven't been as vocal about it as some others.

JBoss has supported Axis development, and recently have been working on a completely new architecture, JBossWS, that is more flexible and, hopefully, more SOA-oriented too.

Q: Is it fair to say the product offerings have been limited until now in terms of the breadth of standards supported? The Arjuna purchase seems to be the first big splash that JBoss really made in the area.

Little: If you mean Web services specification/standards offerings, yes, that's fair to say. However, if you think about where JBoss has been coming from (J2EE environment), then it does make some sense: as with any company, JBoss has been driven by customer demand and up until recently, most of our customers were not heavily into Web services or SOA. But that's changing now.

The Arjuna purchase was a pretty big move for JBoss in several ways: standards, Web services and transactions. It sent a message to customers (and prospective customers) that we’re looking more widely now than just JEE. The recent collaboration announcement with Microsoft also did that.

Q: Are there any other important WS-* moves we can expect in the near future -- in terms of product and support from JBoss in standards and so on?

Little: I think you'll find that JBoss is going to be much more visible in the WS-* space. We'll be more active in standards, such as WS-Addressing and WS-ReliableExchange, and we'll be supporting those standards in our products. We'll also be taking a much more aggressive stance with regard to WS-* standards - leading rather than following. And we'll be at as many interoperability fests as we can!

Q: By implication, does this mean JBoss will be creating new product streams?

Little: Definitely. JBoss is embracing Web services and SOA as broadly and deeply as it did JEE. We want to commoditize that arena too. "Drive innovation up the stack", is how I've heard it described.

Q: That’s an interesting proposition for JBoss. But thinking about going further up the stack, will JBoss be supporting SCA?

Little: We're still looking at SCA: there's a lot there to digest! So although we aren't moving to support it in product just yet, I wouldn't rule anything out. What we'd like to see is broader support from the likes of Microsoft, and for it to be put into an open standards body. As a model, it seems interesting and worth looking at. I think we would be foolish to dismiss it out of hand - after all, it does have some pretty big players associated with it already.

Q: Some of the players involved in SCA are also active in the ESB space. Could you explain to me the philosophy of the JBoss ESB?

Little: Philosophy? Well I've only been the development manager for JBossESB for a few weeks, so it's difficult to associate much philosophy with what we've done so far, but I'll give it a try!

I can tell you what it isn't: it won't be a restricted definition of ESB. This will not be JMS with some added bells –and whistles. We're looking at an SOA deployment infrastructure that will support Web services (of course), but also any type of SOA that you care to need. We'll be looking for flexibility and extensibility. This is where something like SCA may come into play and also JBI (Java Business Integration). At this stage, we're still just fleshing out requirements and basic architecture, but I'm pretty excited about the possibilities. I think one thing you can guarantee from the "philosophy" is that: the message is ‘king.’

Little: Not at all. Firstly the ESB will act as the glue between many of the other components and products that JBoss has currently, including our Web services stack. Secondly, although there has been debate about ESB versus WS-*, I don't think what we are aiming for falls into that debate. We are trying to embrace SOA from the start, and Web services are one aspect of that. If WS-* doesn't fit into our ESB strategy, then we've gone wrong somewhere. Think of the JBossESB as the deployment infrastructure for your WS-* services. It'll be more than that, but that should give you a basic idea of what it'll offer.

Q: So the JBossESB it's more a hosting environment than a transport?

Little: It'll do both, but it won't mandate transport. Of course you need transport in order to communicate, but it won't mandate any particular implementation. This comes back to what I said earlier. I think many people get confused about ESB because of its background -- JMS with some added features. Now whilst that's certainly something we can support, it's not the ultimate goal. I'd prefer to think of JBossESB as JBossSOA, where we will present a deployment, management and development infrastructure for SOA. Transports, such as JMS, SOAP, SMTP, raw TCP, will all be supported.

Q: Is SOAP considered a transport protocol in JBoss's plans?

Little: Sorry, I forgot who I was talking to! No, I used that as a short-hand, for "SOAP-over-XYZ".

Q: SOAP aside, these are all quite disparate architectural models. How does the ESB help here?

Little: It's a single architectural model that will be supported: SOA. How you "plug" into that will obviously depend upon how you are implementing your services and applications. There's only so much an infrastructure can provide or mandate without becoming too restrictive, which is something we don't want to be. So there'll be good practices that we will encourage too, to try to encourage "good SOA". It is too early to really say much more, but one thing that I do want to mention is that we'll be looking at models such as REST and MEST too. You never know, this may be the first major deployment of a MEST-based system

Q: Everyone has a different vision of SOA. For some it's defined by HTTP, for me personally by the SOAP processing model, for others by WSDL or SCA. What's the equivalent JBoss vision?

Little: I'm not sure we've got a collective vision at the moment. I can tell you my own vision: SOA isn't defined by HTTP, SOAP, WSDL or SCA. Those are ways in which you can implement SOA, but they're not the only way. I'd say that something that espouses loose coupling, message-oriented interactions is a basis for SOA, so I could use UDP if I wanted to. I do think that it's the message first and foremost (message as in payload) and then how you convey that message comes afterwards. I should be able to define an entire SOA system in terms of abstract messages and interaction patterns without reference to HTTP, SOAP or even WSDL.

Q: Do you need a concrete set of architectural constraints to get quality of service? In fact transactions are a great example here, for instance how does one have “SOA transactions?”

Little: Sure, but I can still do that at an abstract level and then map down to implementation specifics later. Of course, if you get the abstraction wrong. then you may find mapping to an implementation technology difficult or impossible. But I think that's just an example of getting the abstraction right in the first place. SOA existed before WSDL, HTTP, and SOAP. It should be able to exist after they've come and gone too. I've come across some very large SOA deployments that have been running for over 10 years and the people behind them didn't realise they were SOA until recently. And they used raw UDP.

Q: Will the JBoss ESB perform such mappings on behalf of the developer?

Little: Good question. I'd like to think so, or as much as possible. But it's very early stages at the moment and we need to walk before we can run. What I'd like to ensure is that we start with the ideal notion in our heads and try to stay as close to that as possible when making architectural and implementation decisions. It will be interesting to see how the real world affects us as we go on though.