YAWL
YAWL 開発の動機は、ほとんど全てのワークフローパターンをサポートし、形式的意味を与えるワークフロー言語を定義することであった。ペトリネットがほとんどのワークフローパターンをほぼ描けると思われたため、YAWL の設計者らはペトリネットを出発点とし、これに形式的な拡張として、OR-合流(or-join)、取り消し集合(cancellation sets)、複数インスタンス活動(multi-instance activities)という三つの構成要素を加えた。これらの拡張によって、ペトリネットでは直接描けなかった5種類のワークフローパターン(synchronizing merge, discriminator, N-out-of-M join, multiple instance with no a priori runtime knowledge, cancel case)が描けるようになった。
さらに YAWL ではペトリネットの構文的要素も拡張して他のワークフローパターンも直観的に描けるようにした。simple choice (xor-split)、simple merge (xor-join)、multiple choice (or-split) である。言語の設計において、ペトリネットへの拡張の一部は難解であったり、通常のペトリネットに戻せないものであることが判明した。結果として、YAWL の形式意味論は単なるペトリネットではなく、一種のラベル付き状態遷移系の定義となっている。YAWL が形式意味論に基づいているという事実により、YAWL プロセスの解析技法を実装可能となった。特に YAWL システムには静的解析ツール WofYAWL がある。
YAWL は BPEL の代替とされることもある。BPEL の最大の利点は、それがIT業界の標準化委員会で策定されたものであるという点である。そのため BPEL をサポートするツールは多数存在する一方、YAWL は1つの実装しか(今のところ)存在しない。また、BPEL のサブセットの形式的意味論によって、ペトリネット、プロセス代数、有限オートマトンといった各種形式定義が描けることが示されている。これにより、BPEL にも YAWL システムと同様の機能を持つ静的解析ツールが開発できることが示された。
一方、標準の BPEL は人間の行う作業をサポートできないと指摘されている。BPEL エンジンにはそのようなタスクも描けるよう拡張されたものが既に存在するが、そのような拡張はまだ標準化されていない。対照的に、YAWL はWebサービス標準に基づいたワークリストサービスのための統合されたインタフェースを提供する。このインタフェースによって開発者は、必要に応じて人間のタスクもサポートするワークリストサービスを構築できる。さらに、YAWL にはデフォルトで数種類の人間のタスクの割り当てと制御をサポートするワークリストサービスが含まれている。
YAWL のもう1つの利点はワークフローパターンのサポートだが、BPEL 2.0 で新たに追加される構成要素により、その差は小さくなると予想される。