The topic of the Christmas Lunch (we had the choice between "The best Worscht in Town" (Worscht is Hessian Slang for sausage) and "Positive Eating" and we did the right thing) was his observation that there is good news and bad news when it comes to the topic of (services) orchestration: the (from my point of view) good news is that more and more companies start to use orchestration concepts to introduce a cleaner separation of concern to their (service-oriented) architectures. The bad news is that a lot of customers seem to be confused what orchestration is (e.g. "orchestration is BEPL") and how to use/implement it.
Before we start we should probably introduce a couple of standards, abbreviations and concepts:
*EIP - Enterprise Integration Patterns - A set of design patterns to design, build and deploy messaging solutions for distributed systems. Based on the book by Gregor Hophe and Bobby Woolf.
*DSL - Domain Specific Language - A DSL is a programming language dedicated to a specific problem domain. There are solutions available to describe EIPs with DSLs.
*(WS-)BPEL - Business Process Execution Language - A language to describe the orchestration of (web-)services.
*BPML - Business Process Modeling Language - A superset of BPEL. More suitable to describe workflows.
*BPMN - Business Process Management Notation - BPEL does not define a/the way to describe the business processes in a graphical way. This is addressed by BPMN. You can generate BPEL from BPMN.
There are also a couple of good discussions available on orchestration vs. cheography.
My suggestion is to structure the discussion by introducing different levels of orchestration:
*Component-Level/Microflow Orchestration - within a service
*Services-Level/Business-Process Orchestration - between services, but no interactions with humans and no long-running processes/transactions
*Workflows - between services, including interactions with humans (e.g. approvals, etc.)
The big question is, if BPEL is the silver bullet for all of these and the answer for me is clearly no. Using BPEL to do component-level orchestration is clearly overkill. EIPs (using a java-based DSL) are much better suited to get this job done. BPEL has also its limitations when it comes to the description of workflows. Using BPML to implement/describe your workflows might be a better choice.
But BPEL is clearly the language of choice when it comes to the orchestration of services in a SOA. At the same time, even this decision should not be taken lightly. One of the cited main advantages of using BPEL (and the tools that need to come with it) is the ability to design, change and maintain business processes in a graphical way (including the claim that this can be done by your business domain experts). My question is: do you really need this? How often do your business processes or more specifically the orchestration of the processes change? Once a week? Once a month? Once a year? If it is the later, you might want to reconsider the decision to introduce BPEL (and all of the overhead that comes with it) to your project/company, since it might be easier to just write two pages of JAVA code and you are done.
Executive Summary: I can recommend to have lunch in the Cha Cha. Good fresh food. Not to heavy. On the topic of orchestration I recommend a practical approach: start buttom up. Use DSL-based EIP as much as possible, before you use BEPL-based services-orchestration and/or BPML-based workflows.