Architektura SOA je všeobecně chápána a přijímána jako další fáze budování podnikového informačního systému. Soustřeďuje v sobě to nejlepší z předchozích kompozitních modelů návrhu, vývoje, provozu a integrace aplikací a pravděpodobně dnes nemá žádnou rozumnou alternativu. Proto je zajímavá pro softwarové dodavatele, vyzdvihovaná analytiky a žádaná zákazníky.


Uplynulý rok byl pro architekturu SOA zlomovým. Snad každý výrobce podnikového softwaru se k tomuto tématu vyjádřil – ať již rebrandingem stávajících produktů, nebo uvedením produktů zcela nových. Na trhu SOA produktů se etablovaly dvě dominantní technologie, které jsou zároveň považovány za konkrétní implementace této architektury: webové služby WS (Web Services) a podniková sběrnice služeb ESB (Enterprise Service Bus).
Zároveň během posledních měsíců došlo k bouřlivým změnám a krystalizaci celého trhu SOA produktů:

• Řada společností (BEA, Cape Clear, Fiorano, IBM, iWay Software, IONA, JBoss, Microsoft, SAP, Tibco a další) oznámila svoje vlastní implementace ESB.
• Sun Microsystems a IONA Technologies spojily své úsilí o zajištění větší kompatibility systému Artix (ESB od IONA) a Sun Java Enterprise System (Java ES). Artix je tak dostupný na všech podporovaných platformách Sun Microsystems.
• Byla dokončena specifikace JBI (Java Business Integration), na níž se podílelo více než 30 společností (mezi jinými např. Borland, Cap Gemini, JBoss, Nokia, Oracle, SAP, Sonic Software, Sun Microsystems, Tibco, Vignette a další). Všichni spoluautoři zároveň oznamují kompatibilitu svých produktů (ESB, aplikačních serverů, MOMů) s JBI v dalších verzích svých produktů. JBI má standardizovat koncept kontejnerů služeb známý již z J2EE.
• Sun Microsystems zakoupila firmu SeeBeyond, což bylo vnímáno jako posílení pozice Sunu na trhu ESB a RFID zejména vůči konkurenčním IBM a SAP. Pro řadu dalších IT společností to mohlo znamenat změnu pohledu na Sun: z partnera se stává konkurent. Označení „konkurent“ se tak opět více relativizuje.
• Byly dokončeny první z řady WS-* specifikací, což (konečně) přiblížilo webové služby skutečně celopodnikovému nasazení. Bohužel i nadále v oblasti WS-* specifikací panuje doslova džungle a některé z nich jsou dokonce duplicitní. Softwarové společnosti, které je zastřešují, tak jejich prostřednictvím vedou boj, který „standard“ bude standardnější. K lepšímu pochopení a zařazení přispěje zjištění, která skupina softwarových dodavatelů za danou specifikací stojí.
• Startup WS02 spustil projekt Synapse s cílem vytvořit open source ESB. Sběrnic ESB postavených na open source ESB však již existuje několik (např. od Sun nebo IONA), takže na úsudek o úspěšnosti Synapse bude nutné počkat.
• BEA zakoupila konkurenční společnost Plumtree Software. Tato akvizice přinesla do portfolia BEA portálovou multiplatformovou dimenzi (Java, .NET, konektivita i na jiné aplikační servery). Získáním konkurenta se ještě více upevnila pozice BEA na portálovém trhu.
• Oracle začala umožňovat začlenění Systinet UDDI registrů do svého aplikačního serveru. Systinet se tak stává jejím dalším certifikovaným partnerem. Začlenění má umožnit lepší kontrolu a správu životního cyklu celopodnikových (webových) služeb.
• Fujitsu Limited a Software AG úzce spolupracují na produktu CentraSite (SOA repository). Toto úložiště má sjednocovat metadata nejenom jejich produktů.
• Mercury zakoupila Systinet, což Systinetu otevírá globální prodejní kanály. Z technologického pohledu a zejména z pohledu společnosti Systinet vyvolala synergie této akvizice spíše otázky.
• Progress Software zakoupil Actional a oznámil začlenění Actional i do Sonic ESB. Actional přináší Progressu jak významná technologická partnerství, tak především doplňuje vyšší vrstvy Sonicu o další řešení např. v podobě BAM a jiných nástrojů pro správu celopodnikové SOA. Sonic si akvizicí upevňuje svoji přední pozici na trhu poskytovatelů SOA.
• Rad Hat zakoupil JBoss, čímž chce proniknout do segmentu nízkonákladových open source řešení architektury SOA.
• HP zakoupila Mercury (tedy i Systinet) a vrátila se tak zpět na špici dodavatelů SOA produktů.

SOA není ani konkrétním produktem, ani oborovým standardem. Marketing některých výrobců se sice toto zdání snaží vyvolat, ale tím bohužel ze SOA dělají jen další buzzword. SOA je tak volný pojem, že u každého dodavatele z této oblasti je možné najít jinou definici a trochu jiný přístup. Některé společnosti dokonce prezentují její implementace nejenom jako ESB se sběrnicovou topologií, ale např. i jako ESB s „hub&spoke“ topologií. Jedná se přinejmenším o nepřesný výklad, neboť „hub&spoke“ architektura se ve většině případů uvádí jako předchůdce distribuované podnikové sběrnice služeb.
SOA je široce akceptovaným přístupem pro analýzu, vývoj, provoz a integraci podnikových aplikací založeným na sdílených distribuovaných službách. To, na čem se všichni softwaroví dodavatelé vzácně shodují, je konstatování skutečnosti, že SOA je v dnešní době asi nejefektivnějším způsobem, jak tyto činnosti realizovat.
SOA a její směry, např. SOI (Service Oriented Integration), SODA (Service Oriented Development Architecture), SOAD (Service Oriented Analysis and Design), SOBA (Service Oriented Business Application), jsou mnoha softwarovými dodavateli, analytickými společnostmi i zákazníky považovány za další fázi budování podnikových informačních systémů.
Panuje také poměrně vzácná shoda o přínosech SOA. Vhodnou implementací SOA je možné:

• snížit náklady jak na vývoj, tak integraci aplikací,
• díky znuvupoužitelnosti služeb dále zefektivnit vývoj nebo integraci aplikací,
• relativně rychle a snadno otevřít a zhodnotit původní (legacy) aplikace,
• zprůhlednit a zjednodušit správu a řízení informačních systémů (nedělat věci složitější, než ve skutečnosti jsou),
• rychle adoptovat změny – změna je atributem architekturySOA, ne nečekanou výjimkou, při níž se typicky mění jen metadata, nikoli zdrojové kódy služeb,
• podnikat v reálném čase (otázkou je, zda daná společnost je na takové chování a reálnou odezvu informačního systému připravena).

Referenční model SOA

Najít obecný implementačně nezávislý referenční model architektury SOA je obtížné. Pokud s ním přichází jakýkoli softwarový dodavatel, lze jen stěží hovořit o dostatečné obecnosti a nezávislosti takového modelu. Typickým příkladem může být referenční model vytvořený nezávislou analytickou firmou CBDI Forum (obr. 1). Referenční modely představované jednotlivými softwarovými dodavateli se od něj příliš neliší.



Obr. 1: Referenční model architektury SOA podle CBDI Forum

Při pohledu na tyto referenční architektury je nutné si uvědomit, že vrstvy služeb, aplikací a technologií představují oddělené fyzické vrstvy, zatímco vrstva obchodních procesů představuje vrstvu konceptuální. Co na těchto schématech většinou chybí, je výslovné zdůraznění úlohy úložiště metadat a úlohy celkového řízení této architektury – ať již ve fázi produkční nebo předprodukční. Po takovém doplnění by model mohl vypadat podobně jako na obr. 2.



Obr. 2: Referenční model architektury SOA se zdůrazněním úlohy úložiště metadat a úlohy řízení této architektury

Pilíře SOA

Principy současné architektury SOA jsou evolucí předchozích distribuovaných architektur CORBA, DCOM a webových služeb. Současná SOA stojí na následující pilířích:

• Služby jsou volně vázané (loosely coupled).
• Služby mají hrubozrnné (coarse grained) aplikační programovací rozhraní API.
• Komunikace mezi službami je typicky asynchronní (asynchronous communications).
• Důsledně se využívají oborové „standardy“ (standard based).
• Služby jsou znovupoužitelné (service reuse). Na znuvupoužitelnost se nahlíží jako na žádoucí vedlejší efekt (nikoli cíl) potvrzující dobrou implementaci SOA principů.
• Metadata služeb jsou uložena v úložišti (metadata repository).

Vzhledem k inflačnímu množství textu na téma SOA není cílem tohoto příspěvku podrobně popsat SOA, ale spíše poukázat na méně známé či zajímavé skutečnosti – proto následují jen poznámky k vybraným pilířům a vybraným „standardům“.

SOA nerovná se WS

Dávat do spojení SOA a webové služby je možné a správné, ale zůstat pouze u tohoto by bylo nepřesné. Mezi SOA a WS není rovnítko. Písmeno S ve zkratce SOA může představovat jakoukoli integrační aplikační logiku využitelnou po síti přes hrubozrnné API. Této definici pochopitelně vyhoví každá webová služba, ale ne každá služba musí být nutně webová.
V některých případech implementace integrační aplikační logiky jako webové služby může být buď technicky, či licenčně příliš složitá či náročná, nebo rovnou neproveditelná (extraktovací, transformační a zaváděcí služby, souborové FTP/JMS služby apod.). V těchto situacích se ukazuje síla konceptu ESB, resp. odlehčených distribuovaných kontejnerů založených na JBI, které mohou hostit jakoukoli logiku reprezentovanou (Java) službou nebo procesem.

Znuvupoužitelnost

Dobře navržená a efektivně fungující SOA minimalizuje počet potřebných služeb se snahou o co největší počet aplikací, které danou službu využijí. Znuvupoužitelnosti nelze docílit samovývojem. Spoléhání se na skutečnost, že časem stejně bude ve firmě více aplikací, které budou využívat danou službu či služby, by svědčilo o tom, že proces adopce SOA není cíleně řízený, takže i výsledky (např. znuvupoužitelnost) jsou buď nejisté, nebo dílem náhody.
Znuvupoužitelnost je výsledkem dobře navržené architektury – jde tedy o principiální záležitost. Je nutné být zároveň realistou a uvědomit si, že i v dobře navržených SOA systémech je obtížné docílit větší znuvupoužitelnosti než 30 až 40 %. Některé služby zkrátka patří jen jedné aplikaci nebo aplikační doméně.

Úložiště metadat služeb

Na kvalitním úložišti pro metadata stojí a padá celý koncept SOA. Veškeré služby, a to jak ve vývojovém, testovacím, tak i provozním prostředí, musí být dokumentovány v nějakém persistentním úložišti. To obsahuje metadata rozhraní služeb, formální popis, křížové reference, příslušné verze a další užitečné informace potřebné pro vývoj, nasazení, správu a měření služeb.
Úložištěm zde nejsou nutně myšleny UDDI registry. Každý z poskytovatelů WS nebo ESB řeší úložiště metadat služeb po svém, takže se jejich funkcionalita může značně lišit. Může se jednat pouze o adresářové struktury, vnořené relační, objektové či XML databáze, nebo samotné UDDI registry, s kterými se funkcionalita úložiště může překrývat.

Webové služby

K již široce používaným standardům (XML, SOAP, WSDL, HTTP) přibyly konečně specifikace, které zreálnily využití webových služeb v praxi (např. WS-ReliableMessaging, WS-Addressing, WS-Security a další) a které dále rozšiřují syntaxi WSDL. Samotné WS však mají v podnikové praxi omezené využití. Reprezentují zpracování typu klient/server se všemi jeho nevýhodami. Termínem !samotné" je zde myšleno využití jen základních stavebních kamenů WS, tedy HTTP plus SOAP plus WSDL. Bez úložiště pro metadata webových služeb, bez nástrojů pro správu, monitorování, logování nebo orchestraci nemohou WS doznat celopodnikového využití.
Bude zajímavé sledovat, jakým způsobem a jak rychle dokáží jednotliví dodavatelé WS-* specifikace začlenit do svých produktů a jaká rozšíření k nim přidají. Vzhledem k tomu, jak chaotická je situace okolo WS-*, může implementace těchto specifikací trh SOA produktů ještě více rozdělit.

Demytizace jazyka BPEL

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žuje autor 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ástroj, 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.

Jak stanovit hodnotu SOA a plánovat její zavedení?

Řada softwarových dodavatelů (BEA, IBM, Sonic Software, Systinet a další) spolu s konzultačními a analytickými společnostmi (CBDI Forum, Zapthink apod.) přišla s různými modely zralosti SOA jako návodnými pomůckami pro plánování implementace SOA. Tyto modely zralosti zpravidla vycházejí z Integračního modelu zralosti (Capability Maturity Model Integration) definovaného v 90. letech institutem CMSEI (Carnegie Mellon Software Engineering Institute) a dále rozšiřují jeho pět úrovní.
Model hodnocení softwarových procesů je založen na myšlence, že kvalita procesu určuje kvalitu produktu, a proto popisuje postupy, které umožňují hodnotit úroveň zralosti těchto procesů. Úroveň zralosti (Maturity Level) je definována jako dobře definované prostředí pro evoluční dosahování zralých softwarových procesů. Každá úroveň představuje vrstvu pro kontinuální zlepšování procesů a zahrnuje sadu cílů, které stabilizují určitý prvek softwarového procesu.
Zralosti softwarového procesu (Software Process Maturity) je dosaženo tehdy, pokud je určitý proces explicitně definován, řízen, měřen, kontrolován a je efektivní. Zralost softwarových procesů vede ke zvýšení produktivity a kvality, přičemž se zvyšuje výkon procesu.
Když organizace dosáhne zralosti softwarových procesů, vede to k jejich institucionalizaci prostřednictvím politik, standardů a organizačních struktur. Hodnocení softwarového procesu (Software Process Assesment) rovná se hodnocení stavu softwarových procesů v organizaci.
Modely zralosti SOA vytvářejí formální rámec jak pro IT uživatele, tak i pro vrcholový management, který jeho prostřednictvím může správně vyhodnotit použitelnost a výhody SOA ve své organizaci.

Vybraný model zralosti SOA

Na závěr popíšeme Model zralosti architektury orientované na služby SOAMM (Service-Oriented Architecture Maturity Model), který je společným dílem společností AmberPoint, BearingPoint, Sonic Software a Systinet.
SOAMM definuje pro každou úroveň zralosti cíle, rozsah, vliv na podnikání, důležité oborové standardy, klíčové praktiky a kritické faktory úspěchu – a to jak technologické, tak organizační. SOAMM dále specifikuje, co je potřeba pro zavedení dané úrovně zralosti SOA – tedy jaké musí být k dispozici dovednosti, metody, technologie a infrastruktura. Jde zejména o tyto základní prvky:

• metodiky pro analýzu, návrh a implementaci SOA,
• modelovací a vývojové nástroje, které umožní specifikaci a vytváření služeb a jejich propojení na podnikové procesy,
• Sběrnice ESB poskytující spolehlivé, rozšiřitelné a distribuované komunikace a transformace dat mezi službami i napojení na původní systémy,
• úložiště metadat služeb, politik a procesů,
• nástroje pro provoz a řízení infrastruktury včetně monitorování využívání služeb a zjišťování metrik.

Obr. 3: Model zralosti SOA skupiny Amberpoint, BearingPoint, Sonic Software, Systinet (vpravo) a jeho namapování na Integrační model zralosti institutu Carnegie Mellon Software Engineering Institute (vlevo)

Jednotlivé úrovně zralosti pak definují fázi, v níž se organizace při zavádění SOA nachází.
Úroveň 1 – Počáteční služby (Initial Services): tato úroveň zralosti reprezentuje fázi učení a počáteční fáze zavádění SOA. Typické projekty v této fázi jsou zaměřeny na implementaci funkcionality pomocí nových technologií a testování SOA technologií v laboratorním prostředí. Zavedení SOA je iniciováno ze strany vývojářské organizace a SOA je zpravidla součástí projektu pro integraci aplikací. Na této úrovni zralosti se implementují základní standardy pro služby (XML, SOAP, WSDL), formují se nové dovednosti potřebné pro vývoj služeb a definují se základní metriky hodnocení.
Úroveň 2 – Služby zasazené do SOA architektury (Architected Services): na této úrovni zralosti jsou již zavedeny technologické standardy SOA a zavádění SOA je kontrolované a řízené oddělením podnikové SOA architektury. Klíčovým přínosem na této úrovni je snížení nákladů vývoje a zavádění díky využití SOA infrastruktury a komponent v porovnání s tradičními projekty.
Úroveň 3 – Obchodní služby a služby pro spolupráci: těžištěm zájmu je propojení podnikových procesů s IT. Úroveň 3 je definována ve dvou částech – obchodní služby (Business Services), které se zaměřují na zlepšení interních podnikových procesů, a služby pro spolupráci (Collaborative Services), které jsou zaměřeny na zlepšení spolupráce s obchodními partnery.
Úroveň 4 – Měřené obchodní služby (Measured Business Services): úroveň se zaměřuje na měření výkonnosti procesů zavedených na předchozí úrovni a jejich vlivu na podnikání. Součástí této úrovně je monitorování procesů, které umožňuje uživatelům měnit způsob reakce na podnikové události.
Úroveň 5 – Optimalizované podnikové služby (Optimized Business Services): tato úroveň přidává automatickou reakci na měření zavedené na předchozí úrovni. Tím se informační systém založený na SOA stává podnikovým nervovým systémem. Automatizované reakce na měření a výsledky přicházející z úrovně 4 umožňují přijmout okamžitá opatření, jakmile se objeví konkrétní podnět. Vzhledem k tomu, že většina společností se dnes chová reaktivně, však zůstává otázkou jejich připravenost na takové chování informačního systému.

Autor je Business Consultant společnosti Progress Software Corporation.