In his post, Fred Cummins criticizes the fact that BPEL4PEOPLE doesn't fulfill expectations of business users. Fred says that BPEL (see here for version 2.0 from OASIS) is not a language for business people but for programmers. Well, I personally don't know of any programmer who writes BPEL code himself. BPEL is a language for machines, for executions engines. BPEL is destined to be generated not written. On the other hand, BPEL4PEOPLE should allow including and defining human interaction. I don't personally know if that means that the BPEL4PEOPLE execution engine allows defining tasks that are realized by humans (Humanoid services so to say, if considering the general notion of a service) or if it means that it allows BPEL to be defined by people. I do however think the first explanation is the right one.
Nevertheless, in the second part of the post, Fred Cummins talks about possible repercussions of BPDM. The use of BPMN 1.1 (see here) and BPDM together would allow definition of choreography and orchestration for services, both of which are critical concepts in SOA.
I would conclude that there is a wave of opinions directly linking BPM to SOA, so Joe McKendrick, in "BPM and SOA Need Each Other." I must say that I do not think that SOA should be directly linked to BPM. This would simply restrict any flexibility BPM implementation has and its independence from technology, which provides the stability business people like and need so much. The whole story is all about ROI. If you don't want to take a bet on SOA, then why should you? In the end, it is your processes that create value, not your soa architecture. This however, does not exclude that we work on technologies allowing us using the current standards to build a bridge between business process management and an SOA implementation, just because both worlds go so well along with another.
Marwane El Kharbili.
No comments:
Post a Comment