Webové služby a byznysové transakce

Představte si, že si s vámi váš obchodní partner domluvil schůzku ve druhé největší řecké metropoli Thessalonik...


Představte si, že si s vámi váš obchodní partner domluvil schůzku ve druhé
největší řecké metropoli Thessaloniki. Potřebujete se tam tedy letecky
dopravit a ubytovat. Co pravděpodobně uděláte? Požádáte svou asistentku, aby
vám tuto služební cestu "nějak zařídila", a pustíte tento problém z hlavy.
Asistentka začne hledat optimální letecké spojení (cca 30 různých možností) a
možnosti ubytování (stovky). Navíc jste ji požádal i o rezervaci auta
přistaveného přímo na letišti (cca 5 různých možností). Jak dlouho takový
výběr může trvat? Kolik budou stát případné telefonáty či faxy? Když se
nepodaří rezervovat vámi požadovaný hotel Hyatt v blízkosti letiště či auto
konkrétní značky, znamená to, že na tuto služební cestu nepojedete?
Samozřejmě, že ne, ale asistentka zde musí sehrát roli operativního
koordinátora této jen zdánlivě jednoduché transakce.

Klasika nestačí
Nyní si představme, že jste early-adopter tedy společnost implementující vše
nové a asistentku jste nahradili aplikací využívající webové služby. Pokud
budete rezervovat letenky, hotel a auto ve třech samostatných na sobě
nezávislých transakcích, žádný zvláštní software nebudete potřebovat. Zvládne
to jakákoli současná aplikace podporující standardy webových služeb (SOAP,
XML, WSDL, UDDI). Sdružíme-li ale naše tři rezervační požadavky do jedné
byznysové transakce, trivialita najednou mizí, neboť aplikace musí víceméně
kopírovat chování naší asistentky. Musí zde být také koordinátor, který je
schopen vznášet požadavky na rezervaci, monitorovat jejich stav, být schopen
zrušit požadavek na rezervaci (hotel je obsazen) a zadat nový požadavek
jinému vybranému subjektu (jiné webové službě). Navíc tato transakce nemusí
trvat jen několik minut či hodin, ale i několik dní.
Se stávajícími technologiemi, jako například synchronním protokolem XA,
bychom dokázali koordinovat jednotlivé transakce samostatně, ale naši
byznysovou transakci bychom koordinovat nedokázali, neboť zde platí pravidlo
"všechno, nebo nic" (full commit, full rollback).

Co je BTP
Webové služby by neměly šanci proniknout do sféry mezipodnikových vztahů,
kdyby neměly schopnost řídit dlouhodobé složité transakce ve volně svázaných
systémech, kterých se účastní řada různých stran (aplikací, komponent,
společností). Do nedávné doby to opravdu byl jejich nedostatek.
Situace se začala měnit zhruba přede dvěma roky, kdy novou dynamickou
společnost Arjuna koupila firma Bluestone Software, resp. Hewlett-Packard.
Jedním z důvodů akvizice byl bezesporu produkt WST (Web Services Transaction),
řešící novým přístupem výše uvedené dlouhodobé transakce. Tento produkt byl
posléze i základním stavebním kamenem specifikace Business Transaction
Protocol (BTP), která od loňského roku vzniká pod hlavičkou OASIS
(Organization for the Advancement of Structured Information Systems). Na
specifikaci se podílí řada velkých hráčů, mezi nimi např. BEA, HP, IBM, IONA,
Oracle či Sun Microsystems.
Business Transaction Protokol má následující vlastnosti:
Rozšiřuje definici dvoufázového commit.
Může, ale nemusí se chovat jako synchronní protokol (např. XA).
Lépe odráží reálné chování obchodních partnerů (resp. jejich aplikací) při
provádění byznysových transakcí.
Dokáže pracovat i s dlouhodobými transakcemi, trvajícími i několik dní/týdnů
(long running transactions).
Předpokládá, že každý partner provozuje odlišné autonomní aplikace, a
neočekává jejich vzájemnou znalost. lPřístup k těmto volně spojeným aplikacím
je prováděn výhradně pomocí rozhraní založeného na poskytování služeb typicky
pomocí XML messagingu využívajícího SOAP protokol.
Díky použitým otevřeným internetovým technologiím (HTTP, SOAP, XML) velmi
dobře proniká hradbou firewallů.
BTP je protokol ve smyslu způsobu komunikace. Není tedy součástí žádného
protokolového stacku. Jde spíše o podpůrný mechanismus, stejně jako jsou
podpůrnými mechanismy například směrování, bezpečnost, spolehlivost apod.
Kromě HP-WST není zatím dostupný žádný další komerční produkt, který by BTP
implementoval. Je ale velmi pravděpodobné, že spolutvůrci specifikace v brzké
době takový produkt uvedou buď samostatně, nebo v rámci rozšíření svých
aplikačních serverů.

Stručný popis
BTP definuje dvě základní jednotky práce:
Atomy nejjednodušší jednotka práce, která má transakční vlastnosti shodné se
stávajícím XA protokolem. Operace reprezentující funkcionalitu jedné webové
služby by měly tvořit jeden atom.
Koheze množina atomů s kterou může iniciátor BT manipulovat. V rámci této
množiny může iniciátor určovat, zda transakce jednotlivých atomů bude nebo
nebude potvrzena. Koheze je transakce, která funguje na základě příhlášení
účastníka k hlasování a průběhu vlastního hlasování. V tomto procesu má
iniciátor, resp. jeho rozhodčí, konečné slovo a on určuje, které hlasy přijme
a které odmítne. Iniciátor také určuje, kdo se hlasování vůbec může zúčastnit
a kdo bude z hlasování vyloučen.
Jak uvádí následující ilustrativní příklad, může být koheze relativně
jednoduše strukturována tak, aby se dala spouštět jako program:
void cohesion()
{
//Potřebujeme dodavatele s nejlepší cenou.
Atom supplier1 = new Atom();
Atom supplier2 = new Atom();
Atom supplier3 = new Atom();
//
// Zde by byla logika získávající ceny. Po jejich získání je nutné ověřit,
zda můžeme na jednotlivých zdrojích provést commit.
//
supplier1.prepare(); // Nedojde-li k výjimce tak commit.
supplier2.prepare(); // dtto
supplier3.prepare(); // dtto
//
// Zde aplikační logika vyhodnotí nejlepšího.
// Řekněme, že to bude supplier2.
//
// Koheze musí být ukončena tím, že každý ze zdrojů bude informován, jak se
iniciátor rozhodl.
supplier1.cancel();
supplier2.confirm();
supplier3.cancel();
}

Role v byznysové transakci
Rámec BT je určen rolemi a hráči (softwarové elementy, aplikacemi), kteří se
této transakce účastní, přičemž těžištěm BTP jsou dvojstranné vztahy, které
mezi sebou jednotlivé elementy transakce navazují. V dvojstranném vztahu je
vždy jedna komponenta nadřazená (superior) a druhá podřízená (inferior). Tyto
vztahy se pochopitelně mohou různě řetězit, takže jedna komponenta může hrát i
více rolí.
Příklad dalších rolí:
Iniciátor: Zahajuje BT.
Koordinátor: Vyhodnocuje výsledky jednotlivých atomů.
Účastník: Přijímá zprávy od iniciátora a provádí jeho příkazy.
Služba: Zpracovává aplikační zprávy. BT se účastní prostřednictvím účastníka.
Webové služby by neměly šanci proniknout do sféry mezipodnikových vztahů,
kdyby neměly schopnost řídit dlouhodobé komplexní transakce ve volně svázaných
systémech, kterých se účastní řada různých stran (aplikací, komponent,
společností). Business Transaction Protocol webovým službám tyto schopnosti
nabízí. Vzhledem ke společnostem podílejícím se na vzniku specifikace verze
1.0 můžeme v brzké době očekávat i komerčně dostupné produkty podporující
tento mechanismus (viz např. WASP TX společnosti Systinet či WST od HP).
Problematika webových služeb a transakcí byla jedním z aktuálních témat
letošní národní databázové konference Datakon, která se konala v uplynulém
týdnu v brněnském hotelu Santon. Computerworld byl mediálním partnerem
konference.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.