Přečetl jsem si
Vytvářet nejdříve WSDL nebo Java rozhraní od
Petra Jůzy a rozhodl jsem se, že také připojím pár svých zkušeností.
Na otázku, zda začít nejdřív s WSDL nebo nejdřív implementovat a potom generovat WSDL neexistuje jednoznačná odpověď. A navíc je třeba podle Cimrmana vzít v potaz i roli kohouta, ale nepředbíhejme :-)
Bavme se tedy v prvé řadě o WebServise, u které tato otázka má smysl, tedy o RPC.
Nedá se říct, že by varianty měly své pro a proti. Prostě jsou každá na něco jiného.
Hodláte-li napsat WebServisu na zelené louce, máte na začátku dva výchozí předpoklady: a)bude to WebServisa někomu zveřejněná a která b)bude něco dělat. Pravděpodobně začnete s nějakou analýzou problému. Z analýzy vypadne struktura dat, která by měla kolovat tam a zase zpátky. Struktura se lépe popíše XML schematem než pomocí tříd. Nad ukázkovým XMLčkem se pak lépe přemýšlí jiným lidem, je to názornější. Proto je tedy v takovém případě nejlepší začít s XML schematem, přidat operace a máte WSDL. Z něj pak generovat kód.
Máte-li už napsaný kus kódu a chcete lokální volání roztrhnout SOAPem, není jednodušší cesty než označit nějakou fasádu jako WebServisu a nechat k ní vygenerovat WSDL. Nejčastější a nejhezčí je ale vypublikovat ji pomocí Endpoint.publish().
Já ale tvrdím, že tato otázka je ve své podstatě nesmyslná. Kde je jádro pudla, nebo lépe řečeno kohouta? V pohledu na věc.
Ať už jde o Integrační, B2B, Intranetový Infrastrukturní či Separační scénář, vždy je na počátku všeho zadání. Jak už nás učili na základní škole, zadání problému se klasicky popisuje trojicí množina vstupních hodnot, množina výstupních hodnot a přechodová funkce, popřípadě jejich množina. A to se dá říct jak o nově vznikající aplikaci či WebServise, také o fasádě nad legacy systémem. Ač se to nezdá, totéž platí i při roztrhávání, protože se může ukázat, že bude daleko čistější vygenerovat novou fasádu. V případě složitějšího problému komunikace mezi více participanty pak také víte (nebo aspoň tušíte), co si ti dva tam budou posílat. Každý z participantů má přece svoji roli a k roli patří zase vstupní i výstupní data a popis, co má dělat.
Proto je nejjednodušším postupem rozdělit si vstupy a výstupy na samostatné celky (= zprávy), ty ozobákovat, pojmenovat si jednotlivé funkce (=operace) a spárovat zprávy k operacím. Výsledkem je pak kostra WSDL. Pro lenochy je pak možné vygenerovat kód z oné kostry, vypublikovat WebServisu čistě jako třídu bez WSDL a do kostry doplnit zbývající části WSDL, které za nás vygeneroval publisher.
Tento přístup má hned několik kladů:
* tvůrce se musí nejdříve zamyslet nad strukturou dat, což nebývá tak úplně zvykem
* to zabrání nutnosti neustále měnit rozhraní (a tím i WSDL) při změně datového modelu
* tvůrce uvažuje v intencích dokumentů a operací nad nimi, což mu umožní přehoupnout se přes onen RPC XORBA zlozvyk
* WSDL je čitelné a "hezké" a interoperabilní (pokud je navrženo jako document-wrapped (.NET nic jiného neumí))
* celý návrh systému je pak mnohem lépe udržovatelný, modularizovatelný, rozšiřitelný, znovupoužitelný, lépe odladitelný
na závěr se s vámi podělím o jednu velice podstatnou metodickou pomůcku. Z jednoho neúspěšného projektu Systinetu jsem si odnesl následující systém návrhu SOA aplikací:
1)Vyjmenuj si všechny role participantů, kteří se na aplikaci (procesu) podílejí.
2)Namaluj si síťový graf procesu podle jednotlivých rolí.
3)Rozděl proces na ucelené podprocesy.
4)Vytvoř XML dle struktury procesů, a to tak, že root elementem bude název procesu a v něm na stejné úrovni jako elementy názvy podprocesů. Při vzájemném zanoření podprocesů zanoř element podřízeného podprocesu do elementu nadřazeného.
5)Ke každému participantovi se pokus navrhnout kostru struktury dat (XML, stačí root element a jednu úroveň elementů v něm), které mohou od nich ostatní požadovat.
6)Tato XMLčka sluč do jednoho dokumentu, a to tak, že je podle pořadí v síťovém grafu poskládáš pod sebe do elementu procesu či podprocesu, ve kterém se role vyskytuje.
7)Ke každé roli označ data, která potřebuje pro svoji práci.
8)Z těchto dat poskládej ke každé roli zprávu, kterou bude participant akceptovat na svém vstupu.
9)Data, která participant produkuje, označ jako odchozí zprávu.
10)Dopodrobna rozpracuj XML schema jednotlivých zpráv
Každá role pak odpovídá jedné operaci WebServisy. Pokud hraje jeden participant více rolí, má jeho WSDL více operací. Každý proces i podproces má ještě dvě fáze, které je také nutno zmínit: iniciační (musí vyletět první zpráva) a ukončovací (poslední zpráva musí někam doputovat).
A co se týká implementace celého systému, máme minimálně principiálně čtyři možnosti.
První a nejlepší možností by bylo použít principy z onoho neúspěšného (když vymyslíte něco, co předběhne dobu o deset let, a stane se to díky tomu nezproduktovatelné, naštve to) produktu. V dubnu 2010 mi vyprší klauzule o mlčenlivosti, tak si počkejte na podrobnosti :-) Nemohu Vás bohužel ani odkázat na nějaký veřejný zdroj, protože bylo všechno staženo včetně blogspotů :-(
Další možností je pouštět data do messagingového systému, kde budou zprávy z jedné instance procesu korelovány. Ale to jsme u TIBCO Randezvous a to Vám fakt nemohu doporučit ;-) .
Třetí možností je dát do každé zprávy tranzitivní obal všech zpráv požadovaných mými následovníky. Tento Message Decorator pattern se používá v ESB, má jak své výhody, tak nevýhody. Některé věci v něm nejde bez Cimrmanova úkroku stranou dělat vůbec.
Čtvrtá možnost je ta nejčastější. Každý proces či subproces je implementován jednou fasádní WebServisou. Pro jednoduché věci je BPEL, složitější logiku je lépe kódovat. Iniciační fázi odpovídá příjem zprávy a finalizační pak odeslání výstupní zprávy. Pro jednoduchost je možno implementovat několik rolí v procesu přímo ve fasádě, ale je dobré si tam minimálně nechat čisté rozhraní pro případné oddělení.
PS: Kdyby to pomohlo alespoň jednomu z vás, nepsal jsem to zbytečně. A vyjmenovat výhody takovéto metodologie návrhu nechám na Vás jako domácí cvičení do komentářů
Příspěvky
