 Monday, October 31, 2005
|
|
|
|
Our pal David Chappell has a sober and realistic view of BPEL, the Business Process Execution Language.
Using BPEL to define business protocols makes good sense. The requirements for achieving portability are relatively low, since no system-specific behaviors need to be defined, and the benefits of interoperability are considerable. I expect BPEL to become an important technology in this area.
Most of the excitement around BPEL isn't about solving this important but relatively narrow problem, however. Instead, it's about BPEL's potential to become the standard language for defining all kinds of business processes in a portable way. Despite the hype, despite the enthusiasm, and despite the unbridled optimism of some vendors, I don't believe this is likely to happen.
I think David's right on. BPEL has its uses but is hobbled by a number of factors: its inability to fully specify an executable process, despite its name; and its lack of flexibility to support dynamic processes, for example, delegating or reassigning tasks at runtime (to support human-centric processes).
UPDATE: More on the delay of BPEL 2.0 here.
|
|
|
|
October 2005 |
Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
1 |
2 |
|
|
|
6 |
7 |
8 |
|
|
|
12 |
13 |
|
15 |
16 |
|
|
|
|
|
22 |
23 |
|
|
|
|
|
29 |
|
31 |
|
Sep Nov
|
