Open-Source BPEL takes the form of 'RiftSaw'

Discussions

News: Open-Source BPEL takes the form of 'RiftSaw'

  1. Open-Source BPEL takes the form of 'RiftSaw' (5 messages)

    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: jvaughan@techtarget.com

    Threaded Messages (5)

  2. Choosing between full blown BPEL and BPM[ Go to top ]

    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
  3. 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
  4. Forking/contributing[ Go to top ]

    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".
  5. Re: Forking/contributing[ Go to top ]

    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
  6. Re: Forking/contributing[ Go to top ]

    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