Skip to content.

Manageability

Sections
Personal tools
You are here: Home » blog » archive » Discordant Web Service Orchestration

Discordant Web Service Orchestration

20030423065831

Web services Orchestration in particular BPEL4WS  is in a sense an attempt to do "Programming In The Large".  The main criticism of it however are that (1) Its developed by two vendors to serve their own interests. (2) It's based on two overlapping process models that just happen to be based on above vendors existing products. (3) It assumes programming in XML to be better than programming in a normal language.

If we apply the criteria for language design mentioned on my previous blog.  That is, simplicity, correctness, consistency and completness, it fails to make the grade. 

Simplicity, the standard assumes that adopting XML automagically makes it simple.  I've done XSLT and TagLibs, both with control flow expressed in XML, not only ugly but pretty confusing.  I guess its the same warped reasoning that gave rise to the "S" in SOAP.

Consistency, BPELWS has essentially sacrificed consistency over the need to satisfy its promoters agendas. 

Completeness, maybe combining two different models give better coverage.  Unfortunately, based on a recent analysis on workflow patterns, it simply doesn't, it's the same patterns expressed in two different ways.

Correctness, a more difficult criteria to discern, this really hinges on a compatibility test suite.  Something that will verify semantics such that it conforms to the specification.  In the absence of it, expect to see bifurcation of the standard, and an opportunity to "embrace" and "extend".

The question does remain, "Is it better to be railroaded into standards by vendors or by academics?".  Both sides are just as guilty of introducing overly complex standards, the vendors have given us Web Services and EJB and the academics have given us XML Schema and XSLT.

The alternative may be more towards standards that supports community.  Linux for example is a standard, however not defined by standardized bodies, rather its software that is architected in a way as to allow contributions by the community.  Eclipse is another project that supports community.  If we could get something similar for orchestration, then that would be a move in the right direction.

Created by admin
Last modified 2003-07-30 04:14 PM
visitors
reading
 
 

Powered by Plone

This site conforms to the following standards: