Skip navigation
2009

Mark Little's Blog

July 2009 Previous month Next month

 

Today we're announcing RiftSaw, our return to the WS-BPEL space. Ever since I helped write the initial WS-T work and BPEL4WS, I've believed that BPEL is an important part of WS-* and subsequently SOA. Is it perfect? Of course not. In fact since it's initial release I think some of what we did in the OASIS technical committee made it less useable and less interoperable. But the same could be leveled at a lot of other standards efforts then and now.

 

A few years back we had our own BPEL engine, based on jBPM. Because we needed to focus on making jBPM the best embedded workflow engine around, we decided to not pursue this as a product, though it's still part of our community offerings. Meanwhile we released our own ESB and then SOA Platform, both of which use jBPM for workflow/task-flow, but both of which have a need for BPEL as well. However, it made no sense whatsoever for us to try to do this alone, for exactly the same reasons as were behind our decision to adopt Apache CXF. So where did that leave us? Apache ODE, with its long history going back to PXE from FiveSight was the best open source candidate, allowing us to participate in a thriving community as peers. (The added bonus was that I'd worked with the FiveSight guys back in my Arjuna days.)

 

We've been working on integrating ODE with our projects and platforms for a little while. This announcement is really to make it official. This is a really important step for us as the combination of Riftsaw, jBPM and Drools will help us to create a world-class offering in this space. I have high expectations for the months and years ahead, both for RiftSaw as a community project and for how we'll extend it and use it within our platforms. If you're interested in SOA, workflow, or just plain BPEL, now is the time to get involved!

 

Note we're doing a couple of webinars on RiftSaw. They should be available for those who couldn't attend in a few days.

 

Over the past few years we have made a conscious choice to separate community projects from commercial platforms. Why is this the case? What differentiates between our community and commercial software? Probably the most obvious difference is that we sell support (24x7) on commercial platforms whereas projects are given a best-effort support through public forums. But really there are benefits and trade-offs associated with either option.

Project

 

With this option the projects are always at the cutting edge. They release frequently (usually every 8 to 10 weeks) and they drive a lot of our innovation. We have many community contributors, in the form of code donations, use cases, feature requests etc. Technical direction is set by a combination of the project lead and the community. Interfaces and capabilities may change frequently as the developers and users of the project learn and shape their requirements based on experiences gained. As mentioned above, the support given to project code is best effort, with help from the community and Red Hat employees where possible. But you should not rely on it being available all of the time. However, this is definitely the place to be if you want to be on the bleeding edge and influence next generation technology and direction.

Platform

 

The projects try hard to ensure that where there are cross-project dependencies they work well together. However, because they release frequently, this is not always possible. Furthermore, the amount of testing across different operating systems, databases (and their drivers) and VMs that the projects can/should do is limited. As well as the 24x7 support they offer, this is where the platforms come in to their own. A platform is a point-cut of specific projects and is typically many months behind those projects when it is released. The reason for this is the amount of testing and qualification that goes into driving a project to become part of a platform. This can often be between 3 and 9 months of effort. As well as giving this significant testing regime, platforms also provide a very strict evolution path: interfaces and capabilities cannot simply change from one release to another, and not everything that is within a project may be within a platform, e.g., something that was beta quality when the project was accepted within the platform effort will typically be removed by the platform process. If long term stability and support are what you are after then this is the place to be.

Filter Blog

By date:
By tag: