Orchestra 4 FAQ

What is BPEL?

BPEL is an Orchestration language, not a choreography language. The primary difference between orchestration and choreography is scope. An orchestration model provides a scope specifically focusing on the view of one participant (e.g. a peer to peer model). Instead, a choreography model encompasses all parties and their associated interactions giving a global view of the system. The orchestration and the choreography distinctions are based on analogies: orchestration describes central control of behavior as a conductor in an orchestra, while choreography is about distributed control of behavior where individual participants perform processing based on outside events, as in a choreographed dance where dancers react to behaviors of their peers.

BPEL's focus on modern business processes, plus the histories of WSFL and XLANG, led BPEL to adopt web services as its external communication mechanism. Thus BPEL's messaging facilities depend on the use of the Web Services Description Language (WSDL) 1.1 to describe outgoing and incoming messages.

In addition to providing facilities to enable sending and receiving messages, the BPEL programming language also supports:

A property-based message correlation mechanism
XML and WSDL typed variables
An extensible language plug-in model to allow writing expressions and queries in multiple languages: BPEL supports XPath 1.0 by default
Structured-programming constructs including if-then-elseif-else, while, sequence (to enable executing commands in order) and flow (to enable executing commands in parallel)
A scoping system to allow the encapsulation of logic with local variables, fault-handlers, compensation-handlers and event-handlers
Serialized scopes to control concurrent access to variables

BPEL's current public specification level is 2.0.

What is the Orchestra engine?

The Orchestra engine is an open source implementation of BPEL engine, written in Java. It reads BPEL process definitions and assiocated WSDL files and creates representations of BPEL processes. When an incoming message triggers a start activity, the Orchestra engine creates a new business process instance and starts running it. The engine takes care of persistence, queues, alarms, and many other execution details.

Why should I use the Orchestra engine?

Orchestra is the only real Open Source BPEL solution on the market. With no hidden "better" but expensive version. Everything is available as open source and to download on this site.

Furthermore, Orchestra 4 is a highly performant and robust solution that has been used in very intensive production environnement (tens of thousands of new process instances per day with 24/7 availability).

What kinds of SOA applications are most appropriate for BPEL and the Orchestra engine?

BPEL is designed specifically to manage process flows across Web service endpoints. Web service endpoints can be highly varied in terms of their granularity, transactionality, and availability. For example, one endpoint might provide query-level access to a database; another might provide access to an SAP function; another might provide access to a series of CICS transactions; and another might represent an interface to an entire business process within a customer or partner organization.

Regardless of their potential diversity, Web service endpoints share a common and essential characteristic - they present an external interface that is described by Web Services Definition Language (WSDL). Any Web service endpoint with a valid WSDL interface can be incorporated into a BPEL process. In a business context, therefore, one hypothetical BPEL process might automate purchase order management:

Receive and validate an electronic (e.g. XML based) purchase order
Access an SAP Accounts Receivable function to perform a customer credit check
Access an Oracle database to check on-hand inventory
Access a CICS Order Entry transaction
Send a purchase order confirmation/rejection

In the hypothetical scenario above, the SAP function, Oracle query, and CICS transaction each represent Web service endpoints with valid WSDL interfaces. BPEL, in general, and the Orchestra engine, specifically, are designed to support process compositions like the one described above.

BPEL can also be leveraged by the us of an ESB to provide more possibilities like using other protocols than SOAP with the Binding components offered by the ESB or like using other Service Engines provided by the Bus. Orchestra is natively integrated to the ESB Camel

What are the system requirements for the Orchestra engine?

Orchestra 4 is a lighweith Service Orchestration solution. A 1GHz processor is recommended, with a minimum of 512 Mb of RAM. Regarding software, Orchestra 4 requires Java Development Kit (JDK) 1.5 (also called JDK 5.0) or higher and Apache Ant 1.7.1 or higher.

How can I get started with the Orchestra engine?

Download the Orchestra engine, review the documentation and run the samples.

How do I get support for the Orchestra engine?

Free support is provided via the forums and mailing lists. Before posting questions, please make sure to read the documentation and search the forums and mailing list archives. If you need commercial support, check the support page.

What about tooling ?

Orchestra 4 aims at providing the same functionalities as Orchestra 3 but with much more advanced tools. For this purpose, it is already possible to use the Eclipse BPEL designer or the Netbeans BPEL designer with Orchestra 4. With Orchestra 4 is also delivered a Web 2.0 administration and monitoring console. And last but not least, we are currently developing a new Web 2.0 BPMN 2.0 compatible Designer. Follow the announcement on the mailing lists to know more.

Can I use Orchestra with an ESB ?

Yes ! The CXF packages of Orchestra 4 are delivered with the Camel ESB. Using those packages you can directly call or been called by Camel routes.