Jason Bloomberg, jeden ze zakladatelů analytické společnosti Zapthink zdůrazňuje ve svém článku ze dne 21.03.2007 klíčový aspekt SOA, který řadě zákazníkům i dodavatelům může unikat: "SOA je něco, co děláte, ne něco, co kupujete".
Je to jeden ze základních atributů SOA: architekturu zkrátka nelze koupit.
Tak a máme tu další SOA alianci: Karl-Heinz Streibich, CEO firmy Software AG, zamýšlí vytvořit alianci-síť evropských „niche“ poskytovatelů SOA řešení. Mělo by jít o jakousi protiváhu IBM, Oracle nebo SAPu. Bude zajímavé sledovat, kdo se stane členy tohoto SOA uskupení, neboť tím automaticky zařadí svoji organizaci mezi „niche“ poskytovatele SOA (sousto pro analytické společnosti). Pokud ale aliance prokáže akceschopnost, bude velmi zdravé, když budou velkým dodavatelům účinně šlapat na paty ti menší – a zařazení Progressu mezi „niche“ by mi pak vůbec nevadilo.
Přečetl jsem si tiskovou zprávu Amberpointu viz http://www.amberpoint.com/releases/pr_158.shtml, v které je oznámena užší spolupráce se
společností Microstoft. Ať se oběma společnostem a jejich zákazníkům daří, ale ať prosím Microsoft nevydává BizTalk za podnikovou sběrnici služeb (Enterprise Service Bus)!
Microstoft BizTalk Server 200x Engine byl, je a asi i zůstane centralizovaným aplikačním serverem, na kterém běží příslušná aplikační/integrační logika-služby. Pokud je distribuovanost základním stavebním kamenem SOA, jak jí tedy v podání BizTalku lehce docílit? Instalací BizTalku všude tam, kde služby potřebuji? Jako zákazník bych tento problém nechtěl řešit.
Optimální situace z hlediska SOA Governance je, pokud pro každou platformu, kde běží služby a procesy, existuje agent, který z XML komunikace mezi službami a procesy získává potřebné informace, které pak intervalově zasílá dohledového systému. Dohledový systém interpretuje tyto informace a naopak zpět agentům zasílá definice veškerých politik (SLA, KPI, ..), kterými jsou služby a procesy řízeny. Čím více takto specializovaných agentů máme, tím lépe dokážeme pokrýt rozmanitost a heterogenitu svého ICT prostředí. Současná nabídka od různých firem (Amberpoint, CAI, HP, IBM, Progress) se mi zdá nedostatečná, protože pokrývá zatím jen „SOA mainstream“ technologie: HTTP/SOAP messaging, JMS messaging, různé RMI, různé servletové J2EE technologie + EJB a AXIS. Co když jsou služby v SOI spíše datově orientované a pracují přes JDBC pouze s RDBMS bez aplikačního serveru? A co jiný než JMS messaging?
Pro řadu potenciálních uživatelů může být překvapivé, že SOI může být z krátkodobého hlediska jeden z nejdražších přístupů, které mohou zvolit. Budování SOA je ale běh na dlouhou trať, nekončícím procesem. Pokud se náklady rozloží do delšího období a porovnají se s ostatními možnými technologiemi, architekturami nebo přístupy, zjistí se, že SOI byla na počátku tohoto období drahý, ne-li nejdražší přístup. S přehledem však převálcuje všechny ostatní technologie v postimplementačních fázích – při údržbě a při realizaci změn. Nákladová křivka je zde velmi příznivá, protože změna se v SOI obvykle realizuje pouze změnou metadat - změnou kompozice služeb či redefinicí procesů. Po úpravě postačí reload, změna je implementovaná a proces běží dál podle nové definice. Výhodou tedy je, že změna zpravidla nemíří do zdrojových kódů, což je naopak typické pro ostatní přístupy. Viz graf.
Pokud na kteroukoli z následujících otázek odpovíte ANO, pak SOA pro vás NENÍ přínosem:
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:
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.
SOA se skládá ze tří písmen – A jsem se snažil vysvětlit zde, S jsem víceméně okomentoval zde. Zatím jsem neřekl, co je vlastně služba a co je komponenta. Existuje mnoho definic, dávám přednost těm co možná nejjednodušším:
„Služba = smluvní rozhraní do softwarové logiky.“
„Komponenta = softwarový artefakt vystavující příslušné rozhraní.“
Jak jsem napsal v předchozích postech, SOA není firma, produkt, technologie, natož nějaký standard. Pokud požádáte 10 softwarových dodavatelů o SOA definici, dostanete minimálně 12 odpovědí (osobní zkušenost).
Když byla v roce 2002 uvedena na trh sběrnice podnikových služeb, nikdo nevěděl, o co jde, a nikdo z velkých hráčů o ní nechtěl mluvit. Dnes se z ESB stal typický buzzword a nazývají se tak i věci, které evidentně ESB nejsou. Jak ale oddělit zrno od plev? Jak rozlišit, co je ESB a co ne?
WS-Addressing, WS-Agreement, WS-AtomicTransaction, WS-BaseFault, WS-BaseNotification, WS-BrokerNotification, WS-Context, WS-Coordination, WS-Coordination, WS-CoordinationFramework, WS-Discovery, WS-Enumaration, WS-Eventing, WS-Federation, WS-Choreography, WS-MessageDelivery, WS-MetadataExchange, WS-Notification, WS-Reliability, WS-ReliableMessaging, WS-Resources, WS-Security, WS-Topics, WS-Transaction, WS-TransactionManagement.....!
Znovupoužitelnost služeb je jeden z nejčastěji omílaných buzzwordů v SOA. Byl to termín, který se objevoval od samého počátku, ať o ní mluvil kdokoli. Právě znovupoužitelnost vyvolala nerealistická očekávání, jak vývoj kompozitních aplikací půjde hladce a jednoduše, když se služby budou budou vlastně jen znovupoužívat. Jsme však zpátky na zemi.
Důležité je vyjasnit si předem, v jaké oblasti se pohybujeme – jestli na poli vývoje kompozitních aplikací nebo na poli integrace aplikací. Nepovažuji se za experta na poli vývoje aplikací, proto bych ocitoval závěry firmy Gartner, která před 3 – 4 roky odhadovala znovupoužitelnost podnikových služeb na 30 – 40 % a v současnosti své odhady zkorigovala: tvrdí, že když někdo dosáhne na 15 – 20 %, je asi hodně dobrý.
U služeb, které fungují v oblasti integrace aplikací, je to úplně jiné. Je zřejmé, že znovupoužitelnost služby typu „Zjisti saldo klienta XY“ je velmi omezená – na rozdíl od integrační datové služby pro přenos souborů. Službu pro přenos souborů často používám jako příklad výborné znovupoužitelnosti. Je to služba, která nachází opakované uplatnění v každém jednotlivém integračním procesu, takže je možné docílit i její více 100% znovupoužitelnosti.
Poznámka: Podle mého názoru by znovupoužitelnost neměla být cílem SOA – SOA přece nebudujeme proto, abychom docílili např. 30% znovupoužitelnosti. Pokud se SOA implementuje dobře, pak by měla znovupoužitelnost být žádoucím, nicméně spíše vedlejším efektem. Není to tedy cíl, ale žádoucí vedlejší efekt.
Moc se mi líbí jeden jeden z bonmotů firmy Gartner: „Pro potřebu SOA governance zcela postačuje jedna služba. Jedna služba zcela postačuje na to, aby zničila váš byznys.“
Není překvapením, že nejčastější příčinou selhání SOA projektů jsou zásadní nedostatky ve fungování governance mechanismů bez ohledu na velikost projektu. Bonmot od Gartnerů jasně říká, že je jedno, jestli máme jednu nebo tisíc služeb – správné politiky v nich buď jsou, nebo nejsou vloženy. Pokud tam nejsou, budete mít problémy.
IT Governance není pojem neznámý a SOA Governance je jeho nedílnou součástí. V rámci SOA je každá jednotlivá služba, každý jednotlivý proces IT prostředkem, který by měl být pokryt svým vlastním procesem životního cyklu. Souhrn dat a metadat o dané službě nebo procesu pak tvoří jeho politiky. Každou takovou službu nebo proces je nutné řádně
Písmeno A ve zkratce SOA znamená „architektura“. Každá (softwarová) architektura by měla mít svoji referenční podobu – svůj referenční model. Ten by měl popisovat, jak architektura vypadá ve své generické podobě. SOA však není ani konkrétní technologie nebo produkt ani norma nebo standard, ale obecný přístup jak aplikace budovat nebo integrovat. Každá analytická nebo softwarová společnost si proto vytváří vlastní referenční model SOA. Znám řadu zákazníků, kteří pracují s referenčním modelem CBDi. Mně osobně se tento model SOA nelíbí, zdá se mi „chudý“.
Na přelomu 2005 – 2006 vznikla pod OASIS iniciativa vedená překvapivě Adobe, která měla snahu představit skutečně generický referenční model SOA. Současný návrh je ale tak čistý, že mně osobně nic neříká.
Vytvořil jsem proto vlastní referenční model SOA, který explicitně vypichuje dva hlavní pilíře architektury SOA. Těmi je jednak úložiště pro metadata a jednak zastřešující vrstva nazvaná SOA Governance, kam patří vizualizace, správa, řízení, reporting a zpětná vazba.
Zobrazený model SOA můžeme číst zleva doprava a odzdola nahoru: Architektura SOA stojí na centralizovaném úložišti pro metadata. Distribuované úložiště mi nedává smysl - distribuované jsou instance služeb-procesů, které se vytvářejí z úložiště a mohou se distribuovat tam, kde jsou potřeba. Pokud architektura nemá úložiště metadat, těžko se dá nazvat architekturou SOA.
Ve struktuře podnikového ICT existují různé vrstvy od technologické vrstvy po vrstvu podnikových procesů. Čím jdeme níže, tím více jsou služby datově orientované a jednodušší. Dobrý příkladem může být např. služba na přenos souborů. Je to typická datově orientovaná služba, jejímž vstupem je soubor z operačního systému, z něhož služba vyrobí XML zprávu a posílá ji do definovaného endpointu.
Takto jednoduché datově orientované služby najdou uplatnění opakovaně v rámci jakéhokoli projektu: jejich znovupoužitelnost může být i větší než 100 % (násobné využití jak v rámci jednoho projektu, tak násobné využití v každém dalším).
Čím v modelu postupujeme výše, tím jsou služby složitější a hrubozrnnější. V horní vrstvě modelu mají služby charakter v podstatě čistých metadat v podobě popisů podnikových procesů. Viděl jsem, že v některých referenčních modelech byla nad vrstvou podnikových procesů ještě prezentační vrstva, což je ne úplně přesné vyjádření. Prezentační vrstva SOA bývá nativní součástí aplikační vrstvy – aplikace jsou pro uživatele, proto nástroj, který vykresluje uživatelské rozhraní, musí být být nutně zde, nikoli nad vrstvou podnikových procesů.
Jednou z možností realizace služeb v architektuře SOA jsou webové služby (WS, Web Services). Webové služby nabízejí standardní popis svého rozhraní (WSDL), díky němuž je kterýkoli klient schopen službu využívat (konzumovat). Dávat do spojení SOA a webové služby je možné a správné, ale zůstat pouze u toho 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é rozhraní API. Této definici pochopitelně vyhoví každá webová služba, ale ne každá služba musí být nutně webová.
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-Notification, 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, SOAP a WSDL. Bez úložiště pro metadata webových služeb, bez garance doručení zpráv, bez nástrojů pro správu, monitorování, žurnálování, orchestraci nemohou WS doznat celopodnikového využití. V některých případech implementace integrační aplikační logiky jako webové služby může být buď technologicky či licenčně příliš složitá či náročná, nebo i 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.
