The Apache ODE (Orchestration Director Engine) team has announced this month its 1.2 release that includes many new features, improvements and bug fixes. Apache ODE is a WS-BPEL compliant web services orchestration engine allowing to orchestrate web services execution following a process description written in the BPEL XML grammar.
WS-BPEL is a specifications initially developed by IBM and Microsoft and now maintained by OASIS Web Services Business Process Execution Language (WSBPEL) TC. The members of the working group include: IBM, BEA, Adobe, JBoss, SAP, Active.Endpoints, Tibco, WebMethods, Oracle, etc.
Highlights of this release include the following:
- External variables allowing business process variables to be visible and directly manipulated outside process instance. This mechanism can be used, for example, to externally configure process’s database access or service invocation address.
- Support for the WSDL HTTP binding along with extensions, allowing for the invocation of REST-style web services.
- Supports for two communication layers: one based on Axis2 (Web Services http transport) and another one based on the JBI standard (using ServiceMix).
- Advanced endpoint configuration which, in the case of Apache Axis2 communications, supports configuring WS-Security and WS-RM.
- A long list of small fixes and improvements for best-of-breed stability, performance and usability.
In addition to these new features, Apache ODE provides the following functionalities:
- Side-by-side support for both the WS-BPEL 2.0 OASIS standard and the legacy BPEL4WS 1.1 vendor specification.
- High level API to the engine that allows you to integrate the core with virtually any communication layer.
- Hot-deployment of your processes.
- Compiled approach to BPEL that provides detailed analysis and validation at the command line or at deployment.
- Management interface for processes, instances and messages.
InfoQ spoke with a Vice President for the Apache ODE project, member of the Apache Software Foundation and Intalio architect Matthieu Riou who also contributs to the Apache Tuscany project. On the the most important feature in ODE 1.2, Matthieu explained:
I think what we call external variables is very interesting. Traditionally, orchestration engines have been black boxes that interact extensively with the rest of your system but don't provide any way to access what's under the hood. Processes get executed, receive messages, manipulate them and send new ones but past your process definition, the execution is fairly opaque. It's most obvious with the data that processes manipulate. Especially in WS-BPEL where data is XML, it doesn't map very well to traditional data storage mechanisms
So this feature allows users to store process variables directly in a database table of their choice. We provide a simple mapping facility so that you can have a reasonable control over the table structure. Then every read or write on this mapped variable will be backed by the table. It's a fairly simple feature but it opens up a lot of possibilities toward reporting, Business Activity Monitoring or even live modification of process data.
We also plan to extend this feature to support the mapping of a process variable to a RESTful resource. As a result, a RESTful web service, could be directly accessed and manipulated from a process.
Matthieu told InfoQ about the significance of supporting Rest Web services in ODE:
One of our problems is that WS-BPEL is WSDL 1.1 only, at least for now (and I'm not aware of any effort to update it for WSDL 2.0). So we had to do with what WSDL 1.1 and its HTTP binding supports and honestly, there's not much.
So we've extended that a bit and added a few basic elements to the WSDL 1.1 HTTP binding. For example, we also accept verbs at the operation level and not only at the binding level. From there, WSDL port types can be mapped to a resource and operations to HTTP methods. Note that if your use case still falls under what the HTTP binding supports, no extensions are needed.
All of this probably sounds like heresy to both WS-* and REST purists but this still gets you a fairly clean way of invoking RESTful web services. We've been very careful to not abuse HTTP more than WSDL already does.
That being said, the longer term plan is to extend ODE's abilities to support RESTful architectures a bit more natively. We want to make processes RESTful, publish them by following the uniform interface and we have plans to extend WS-BPEL significantly. We already have our own specification for this, called RESTful BPEL, and I encourage everyone to have a look and provide feedback.
On SCA and BPEL integration:
Actually this is already underway as a collaboration between the ODE and the Apache Tuscany team. We have simple scenarios working, with interactions between a SCA composition and BPEL processes. The latest Tuscany SCA release (1.2.1) includes ODE with a sample demonstrating the use of a BPEL process.
Asked if they are planning to support WS-Addressing for request/reply implementation:
We already have some support for WS-Addressing. The value for us is in the ability to include, in the EPRs a process sends, additional information about the process instance identity. As a result, we don't need correlation for process to process interactions for example. Process instances just find each other using the EPR included in the WS-Addressing header of received messages.
Additionally if your services are implemented to use those headers as well and provide them to the process engine when you invoke it, correlation can be avoided entirely
Matthieu was asked if there are any plans to implement BPEL4People and WS-HumanTask, to which he replied:
The charter for ODE is larger than just WS-BPEL and includes both orchestration and human workflow. Historically we've been more focused on BPEL and orchestration but one of our committers (Assaf Arkin, whoe also wrote the RESTful BPEL specification mentioned previously) is currently working on a cool task manager called Singleshot. It's implemented on Rails and will complement our BPEL engine very well by giving it a human-friendly face.
In the meantime, Intalio also has an open source Workflow product called Tempo that implements the BPEL4People white paper.
Finally, we plan to support the WS-BPEL extensions included in BPEL4People, like peopleActivity. It's still a bit early right now for us but if others in the community are interested in making this happen earlier, we would definitely appreciate it.
One of the most important thing to remember about ODE is that it's an Apache project. And as such, we develop under a very business-friendly license and we welcome contributions of any kind: code but also simple feedback, documentation, tests or simply your enthusiasm.
With this new release Apache ODE is strengthening its position as a leading open source BPEL-based orchestration implementation. The work is also underway to extend ODE into a complete human workflow implementation.