Opinari

Subscribe

More on The Case Against BPEL  
# Wednesday, November 16, 2005
 
The division of opinion in the BPEL community is certainly interesting. Some people agree with my perspective that BPEL executable processes are likely to be of limited use, while others feel that the portability problems I’m worried about aren’t really that significant.

It’s also been interesting to see that this division of opinion doesn’t fall cleanly along vendor lines, nor does it echo the traditional .NET/Java split. Some Microsoft bloggers agree with me, for example, while others don’t. An Oracle VP disagreed strongly, in comments I responded to here. At least one BEA observer seems to agree, although I'm willing to bet some of his co-workers have a different perspective. I’m told that even the OASIS BPEL Technical Committee is divided on the issue.

One thing I think we'd all agree on is that every BPEL product vendor wants to do at least two things: sell its products to customers, then make sure customers can use those products to solve real problems. Promoting BPEL’s portability helps significantly in the first of these goals, since customers like the idea of not being locked in to a single vendor. But actually making customers successful has typically required extending BPEL in proprietary ways, which works against the language’s promised portability. While BPEL purists might argue that all of these extensions should be provided via programming language-neutral web services interfaces, this isn’t what’s actually happening in the products. And in any case, vendors still want to lock users in (which isn't evil—it's just good business). Adding proprietary extensions is an effective way to do this.

Whether or not my perspective turns out to be right—and I wouldn’t be unhappy to be proven wrong—this issue needs to be more visible. Being too sanguine about BPEL’s portability is not in any customer's best interest.

0 comments :: Post a Comment

 

<< Home