Vzhledem k tomu, jak se o jazyku BPEL (Business Process Execution Language) někdy hovoří i v odborném tisku a jak je potenciálními uživateli chápán, považuji za vhodné uvést následující komentář. BPEL je nyní zastřešován OASIS (původní myšlenka je z dílny IBM a Microsoft). Jeho hlavním posláním je poskytování notace pro specifikaci podnikových procesů založených na WS.
Již z této definice je zřejmé, že zaměřením pouze na WS se jazyku BPEL otevírá jen část SOA. Pomocí BPEL je velmi dobře možné realizovat dlouhé asynchronní byznys transakce včetně kompenzačních. Jazyk zvládá řízení toku dat (proměnné, korelace, cykly, větvení, spojení) i ošetření chyb a výjimek. Avšak již od prvních verzí si BPEL neumí poradit s:
- interakcemi s lokálními objekty Javy nebo C#,
- interakcemi s relačními databázemi,
- interakcemi s uživatelem (žádná explicitní abstrakce pro uživatele, skupiny, role),
- neexistujícím specifickým modelem pro měření, reporting nebo management,
- neexistující explicitní podporou transformací,
- neexistující explicitní podporou dalších protokolů a jiných služeb než WS.
Výše uvedené není kritikou, ale jen konstatováním faktu, že tato funkcionalita ani nebyla cílem autorů při tvorbě specifikace BPEL. Vzhledem k potřebám a požadavkům praxe však musela řada poskytovatelů BPEL později některé z těchto vlastností do svých produktů doplnit, čímž byl osud BPEL jako standardu zpečetěn.
Problém s přenositelností je pak stejný jako u jiných „standardů“ (SQL, JMS, JBI atd.) a oprávněná otázka zní: Jaký je rozdíl mezi takovým rozšířeným BPEL a proprietárním jazykem pro definici podnikových procesů od jakéhokoli softwarového dodavatele? V čem má pak takto rozšířený BPEL přidanou hodnotu pro zákazníka?
Navrch tak získává poskytovatel BPEL nástroje, který jedním hmatem chytne dvě mouchy: jednak může tvrdit, že dodržuje standardy (a svým způsobem má pravdu), jednak si ještě těsněji uváže daného zákazníka. Tato kombinace se pak stává nirvánou všech softwarových dodavatelů – a to nejenom u tohoto „standardu“.
Rozeberme ještě samotný akronym. „L“ je v BPEL zcela na místě – jedná se určitě o jazyk. „BP“ je také na místě – je zaměřen na automatizaci podnikových procesů. Právě „E“ je ale diskutabilní a může být i zavádějící. Může totiž vyvolávat dojem, že pomocí BPEL lze definovat samospustitelnou procesní logiku. Výsledkem definice BPEL procesu je ale „pouze“ dokument založený na XML, který musí být „nějakým způsobem“ transformován do proveditelné podoby.
Slova „nějakým způsobem“ znamenají, že každý z poskytovatelů BPEL nástrojů tuto cestu realizuje opět po svém. Někteří výrobci interpretují přímo XML definici, zatímco jiní tuto definici nejprve transformují do proprietárního formátu, kompilují a pak teprve provádějí. Teprve až po těchto krocích se tedy dostává ke slovu „E“, které je realizováno příslušným softwarovým strojem.
