JBoss released Riftsaw-2.0RC1. Riftsaw is a WS-BPEL 2.0 engine that is optimized for the JBoss Application Server container. Riftsaw supports short-lived and long-running process executions, process persistence and recovery, process versioning, JBoss deployment architecture enabling hot deployment of your BPEL processes and integration with JBossESB and UDDI using jUDDI. An Eclipse-based BPEL designer is bundled with JBossTools 3.1. Riftsaw is based on Apache Ode, and adds support to run on any JAX-WS compliant WebServices stack and it ships with a new GWT based Admin console. RiftSaw can be downloaded from here. Interim editor asks TSS community: What are your thoughts on BEPL, open source or other? Message was edited by: firstname.lastname@example.org
- Posted by: Kurt Stam
- Posted on: December 17 2009 12:10 EST
- Choosing between full blown BPEL and BPM by adam devoe on December 17 2009 14:01 EST
- RE: Choosing between full blown BPEL and BPM in news by Burr Sutter on December 17 2009 15:18 EST
- Forking/contributing by Renat Zubairov on December 20 2009 04:37 EST
Congrats on the release of Riftsaw We're trying to decide on a technical direction for our CRM product. Could anyone suggest criteria for deciding between going with full-blown BPEL vs a lighter weight BPM solution like jBPM? Thanks, Adam
Hello Adam, WS-BPEL 2.0 via Riftsaw or Ode is not necessarily a "heavyweight" solution. It is targeted specifically a Web Service orchestration - WSDL is a huge part of WS-BPEL-based development/design. The key benefits are specific syntax & capabilities around short-live or long-running web service-based processes with correlation, WSDL variable input/output mapping, support for XPath, XSLT, etc. jBPM's JPDL language is not focused on Web Services, it has no native understanding of WSDL. It is a generic workflow language and engine that is ideally suited to embedding in your custom .WAR or .EAR. It has specific syntax for human task management while the WS-BPEL standard does not (though that is being worked on by the spec committee). In my mind, the decision is really around how much WSDL-based web service factor into your architecture. Burr
Interesting announcement. After investing quite some time in the jBPM it seems JBoss dropped it.... I'm just curious about open source commitments of JBoss, for example the BPEL Editor project that was dead already, did they just forked it or took over the project leadership from IBM? Also ODE project originally contributed from Intalio, what are the differences between ODE in RiftSaw and ODE in commercial Intalio versions. IMHO JBoss obviously need a reliable enterprise-proof BPM product in it's portfolio, however concentrating on BPEL in my opinion dangerous decision, I would more likely go with jBPM for "technical BPM" and BPMN for "business/human-workflow BPM".
After investing quite some time in the jBPM it seems JBoss dropped it....jBPM is not dropped. On the contrary. jBPM focusses on jPDL and BPMN 2. A separate team focusses on BPEL. RiftSaw based on ODE was taken as the engine for that purpose. jBPM 4.3 will come out in the next few weeks and it includes BPMN 2.
However concentrating on BPEL in my opinion dangerous decision, I would more likely go with jBPM for "technical BPM" and BPMN for "business/human-workflow BPM".Depends on what you want. If you need to orchestrate services or build coarse grained WSDL services as a function of smaller grained WSDL services, then BPEL is the most obvious choice. But if you need to manage human tasks or make the bridge between development and non technical people, then jPDL and BPMN are better suited. regards, Tom Baeyens jBPM
The support of standards has grown more important, and as such standards like BPEL are now fully supported by JBoss. We chose the strategy of supporting an common open source BPEL engine (ODE), and providing deployment and integration support into the JBoss platforms and provide tooling support. We contribute back to the upstream projects. Forking hardly ever works, and we'd like to support the exising communities instead. Hopefully that clears things up. --Kurt