Contribution by Mark Little, Director, Software Engineering
It’s taken us a while, but we’ve finally released the first version of our Service Oriented Architecture Platform, aka the SOA Platform 4.2. This is the culmination of many, many months of effort that actually dates back to the start of 2006 when we were still an independent JBoss entity. Just when we were on the edge of selling support contracts for JBossESB, we changed direction with Red Hat and went for the platform approach. So first there was the EAP and now there’s the SOA-P. This approach is actually better though, because we have spent a lot of the time and effort in making sure that the entire stack is stable, reliable, robust and performs.
We’ve been working on this initiative with some important partners, such as ActiveEndpoints and SOA Software, but the platform is primarily pure JBoss. There’s obviously the ESB that glues everything together, but also included is the great JMS implementation (JBoss Messaging) as our key transport, and JBossWS for those tricky Web Services interoperability requirements. JBossAS support comes out-of-the-box (though not mandatory), which allows us to tie in to some of those unique and cool capabilities such as Web Services Transactions, part of JBossTS. Ever thought about writing compensations for your services: much better than relying on traditional ACID transactions in long-running interactions. Now, many people may not be at that stage for their applications, but it’s there if and when it’s needed.
The Drools team has also been working overtime to get us some of their latest and greatest stuff. Currently, we use Drools on the SOA platform, as you might expect, but also “within” it for content-based routing support. This is a very powerful capability because it allows you to write arbitrarily complex rules to sort and route your messages on the fly, increasing the loose coupling of your applications in a dynamic way - no more having to tear down your infrastructures to take into account changes in business rules or deployment configurations, failures, etc. Now, you can write a new rule, upload it and away you go! The possibilities are almost endless, given the richness of the Drools language.
Last, but by no means least, is our support for orchestration of services. Obviously there’s BPEL support in the platform, but the combination of BPM and SOA is a very compelling one - for some users it’s much more compelling than Web Services. Luckily we have that combination in-house too, with jBPM. We’ve probably spent more time on closely integrating this than anything else because we see it as an important differentiator for our users. The end result is great because you can orchestrate your service invocations within the Java language and never have to deal with XML (or specifically WSDL), which is not necessarily one of the most natural fits for Java programmers!
The overall result is definitely more than the sum of the individual parts. This is just the start, too. Each of the individual projects has great technical directions to cover in the next few months, but the platform will pull these together to keep presenting a compelling solution for our customers. For instance, we’re doing some really cool things in the area of provably correct distributed applications as well as tooling and governance. The fact that we have all of these components within the JBoss brand clearly differentiates us from all of the other open source efforts, but also from some of our closed-source competitors. Not only does this mean it’s easier to get support, but the integration between the projects is much closer and seamless! Some observers have been pointing out that SOA and Open Source seem a very natural fit. Well the JBoss SOA Platform only helps to strengthen that argument. The wait is finally over: go grab the SOA Platform, and in the words of William Blake “Hold infinity in the palm of your hand” because the possibilities it offers have little boundaries.