BPEL is set to be the dominant Web services choreography language. It may change over time as standards in the area mature, but given the fact that it is a second generation effort, it is more immune to change than the other first-generation contenders in this area.
Developing BPEL workflows by hand is difficult and error-prone. Tool support is essential, especially if control of mission-critical workflows is to be given to non-specialist programmers. Writing code in XML does not magically make it simple.
If you are modeling an existing process with a view to automation, approach development in three stages. First understand your algorithm (that is, the necessary activities and the control flow dependencies). Then decompose the relationships between your enterprise and your partners into BPEL-friendly interface code (partners, serviceLinks and so forth). Finally, progress to connecting your workflow to your partner's services.
If you are starting from a blank slate, it might be more useful to start from your partner interrelations and work "inward" toward your process script.
BPEL will be the "API" for business analysts developing and deploying workflows into enterprises.
