« BPMN will kill BPEL. Will it kill BPM too? (cont’d) | Main | The future of BPM »

The two previous blog entries discussed the way in which BPMN, the emerging standard for graphical process notation, will effectively render the process language BPEL unnecessary – and lead eventually to BPEL vanishing from the scene.

Before BPEL goes, though, let’s look back at its history, since there are interesting lessons to be learned about where process execution may go in future. In particular, BPEL was originally called BPEL4WS – Business Process Execution Language for Web Services. As this suggests, the original purpose of the language was simply to execute Web services – these days, people in the field generally talk about Web service “orchestration”. What does this mean, exactly?

IT writers often make an analogy with musical orchestration here, which accomplishes little except to confuse matters. So let’s try and forget this, and talk just about Web services. Orchestration in this sense is the process of taking multiple Web services and combining them into a single Web service.

First BPEL did this, and now BPMN does this, by linking the component Web services together like subroutines in a procedural computer program - familiar control flow constructs such as if-then-else and while-do are used, together with more modern constructs for executing services in parallel and temporarily suspending program execution. In effect, process orchestration languages are the equivalent of old-fashioned BASIC or COBOL, extended to allow multiple “threads” of activity at one time. You invoked a BASIC or COBOL program via an operating system command to get something done – you invoke a BPEL/BPMN process via a Web service call to get something done.

This all sounds straightforward enough, though not particularly sophisticated. And indeed, more advanced techniques for combining Web services are emerging, which come under the heading of Web service “choreography”. Choreography is generally proposed as a complementary technique to orchestration, but as we shall see, their true relationship is rather closer.

Again, let’s try and forget the analogy with the arts, and keep it simple by sticking to Web services. Choreography, like orchestration, is concerned with combining Web services. However, it does so declaratively rather than imperatively – by describing what the overall process appears to do, without specifying how any of this is to be implemented.

Choreography is generally presented as applicable to situations where multiple parties are collaborating. Since each party has its own private concerns, and quite probably its own Web services it wishes to use, the only way for all parties to agree on a process is to talk about what will happen publicly, not how it will happen internally to each player: the "observable external behaviour" of a process, rather than how it actually works behind the scenes.

The idea is that choreography is like the specification of a business process, and orchestration like the corresponding implementation. Orchestration is supposed to follow on from choreography, and in multi-party collaboration, different pieces of the implementation are to be provided by each player.

However, if you look beyond the short-term, this principle does not hold up. In the next blog entry I will look at orchestration from the perspective of computer science history, in order to discover its true relationship with choreography, what the future holds for some closely-related process standards, and how this may impact enterprise process support faster than expected …

Posted by keithhb in Business Process Management • Service-Orientated Architecture |Digg This|Add to del.icio.us