Bílá místa v mozaice SOA

Je díky architektuře SOA konvenční integrace podnikových aplikací historií? Zatím ne. Příslib univerzální integrac...


Je díky architektuře SOA konvenční integrace podnikových aplikací historií?
Zatím ne. Příslib univerzální integrace aplikací, s nímž SOA přichází, je v
řadě ohledů přinejmenším vágní a dokáže zamotat hlavu nejednomu zájemci o tuto
technologii. Zevrubnější zkoumání odkryje velké mezery týkající se
spolehlivosti, bezpečnosti, orchestrace, podpory starších technologií a
sémantiky. Přinášíme zprávu o tom, jak podnikoví zákazníci překonávají těchto
pět největších obtíží, s nimiž se koncept SOA při svém užití zatím potýká.
Kouzelné slůvko SOA (Service-Oriented Architecture), tedy architektura
orientovaná na služby, se stále častěji objevuje v souvislosti s integrací a
konsolidací podnikových informačních systémů. Jedná se o architekturu zaměřenou
na sdílení a opakované používání kódu, jejímž základem je vzájemná komunikace
aplikací prostřednictvím standardně definovaných webových služeb. V rámci SOA
jsou aplikace budovány nebo zpřístupňovány pomocí standardních rozhraní
nejčastěji založených na XML a jeho derivátech, k nimž patří protokol SOAP
(Simple Object Access Protocol) a jazyk WSDL (Web Services Description
Language). SOA také definuje, jak jsou jednotlivé služby lokalizovány,
prováděny, spravovány, monitorovány a zabezpečovány.
Peter Underwood, viceprezident softwarového vývoje v makléřské firmě Wall
Street Access, říká, že dříve, než začal jeho tým plánovat využití architektury
SOA, musel udělat pár vážných úvah.
"Začněte s myšlenkou, že SOA je takový větší chlebník. Jinými slovy, že je to
jen rámec," radí Underwood. Ačkoli SOA začala žít vlastním životem díky webovým
službám založeným na současných standardech, Underwood věří, že mezi jejich
nynějšími schopnostmi a jejich budoucím potenciálem stále existuje propastný
rozdíl. Řadoví úředníci jsou nepochybně rádi, že mohou využívat webové služby k
jednoduchým úkonům, jako je dodávání informací do webových portálů. Avšak
komplexní úkoly s kritickou důležitostí jsou o něčem jiném a mohou vyžadovat
standardy webových služeb, které jsou teprve ve vývoji.
Kdy tedy lze architekturu webových služeb SOA doporučit a kdy lépe poslouží
stará dobrá integrace podnikových aplikací EAI (Enterprise Application
Integration)? Odpověď závisí na tom, o co se snažíte a na jaké mezery ve
schopnostech webových služeb přitom narazíte.

Spolehlivost
Potřeba vysoce spolehlivého, asynchronního zpracování zpráv může být největším
problémem, přinejmenším krátkodobě. Podle Aiaze Kaziho, generálního manažera
pro podnikovou integraci u společnosti Tibco a skalního příznivce řešení EAI,
je tento druh zpracování zpráv kritický vzhledem k integraci na podnikové
úrovni.
Sam Boonin, viceprezident marketingu u dodavatele infrastruktury webových
služeb, společnosti Blue Titan Software, soudí, že architektura SOA není zatím
zcela připravena na nejvyšší úroveň transakční spolehlivosti, která musí
zaručit nepopiratelnost a jedinečnost doručení všech zpráv a současně v každém
okamžiku také bezpečnou možnost návratu do předchozího stavu. Je však jen
otázkou času, kdy standardy a jejich implementace dospějí do požadovaného stavu.
Ve skutečnosti již existuje několik návrhů specifikací webových služeb, které
řeší problémy v případě kritických a dlouhodobě běžících procesů. Například
specifikace WS-ReliableMessaging je navržena tak, aby zaručila doručení zprávy
do místa určení prostřednictvím protokolu SOAP. Jiné navrhované specifikace,
jako WS-AtomicTransaction, WS-Eventing a několik dalších, by měly definovat
způsoby zpracování komplexních, stavových a dlouhodobě běžících podnikových
transakcí. Avšak na rozdíl od mnohých protokolů vztahujících se k bezpečnosti
je široké využití standardů pro zajištění spolehlivosti, jako jsou tyto, teprve
otázkou budoucnosti.
"Do té doby bude pro webové služby spolehlivé zpracování zpráv skutečným
oříškem," říká Chris Crowhurst, viceprezident pro podnikovou architekturu ve
společnosti Thomson Prometric, která poskytuje služby v oblasti počítačového
testování a vyhodnocování. Aplikace však na spolehlivé komunikaci potřebují
stavět již dnes, aby dokázaly zúročit interoperabilitu, kterou webové služby
poskytují.
Pro tuto chvíli to představuje nutnost psát aplikace tak, aby předjímaly
chybové stavy a dokázaly se s nimi vyrovnat. Znamená to rovněž podpořit
point-to-point interakce protokolu SOAP prostředníkem jakýmsi správcem webových
služeb který sehraje roli standardizované mezivrstvy. Takovéto utility jsou k
dostání od nezávislých firem jako Actional, AmberPoint a Blue Titan.
Jak ale poznamenává Dan Foody, CTO společnosti Actional, která je dodavatelem
nástrojů pro správu webových služeb, ne všechny problémy vyžaduje stejnou
spolehlivost. Nejvyšší míru zabezpečení potřebují asynchronní, dlouhodobé
transakce s mnoha vzájemnými závislostmi příkladem jsou komplexní finanční
transakce. Pro méně náročné úkoly však docela spolehlivě poslouží protokol SOAP
na platformě HTTP zejména v případě jednoduchých synchronních interakcí.
Rajan Jena, podnikový architekt firmy Oncology Therapeutics Network, využívá v
integrační infrastruktuře své společnosti jak tradiční middleware zaměřený na
zpracování zpráv, tak i webové služby. Říká, že řešení na zpracování zpráv jsou
vhodná při velkých objemech transakcí, které jsou přenášeny v dávkách. Na druhé
straně webové služby jsou nejlepší volbou, je-li transakcí málo, ale musejí-li
probíhat zcela v reálném čase.

Bezpečnost
Autorizace, ověřování a šifrování představují vážný podnět k zamyšlení pro IT
manažery, kteří uvažují o integraci založené na webových službách. Řízení
přístupu je tradičně záležitostí vyžadující přihlašování a ověřování. Avšak ve
světě distribuovaných webových služeb, kde by složky jedné aplikace mohly
snadno zmizet a navázat kontakt se složkami existujícími v jiných doménách, je
udržování bezpečnosti různorodých propojených systémů daleko složitější.
Tak jako v případě spolehlivého zpracování zpráv je i u interakcí ve stylu
webových služeb navržena řada standardů. Dva z nich jsou obzvlášť důležité a
široce implementované: WS-Security a SAML (Security Assertion Markup Language).
První popisuje rozšiřitelný rámec pro specifikaci různých položek zabezpečení
systému, zatímco druhý definuje standardní proces přenosu informací v rámci
jednotného přihlašovacího modulu SSO (Single Sign-On). Pro podnikové
architektury SOA volí analytik Phil Wainewright třetí, i když zatím ještě
nevyzrálý návrh vycházející ze specifikace WS-Policy. Ta by měla různým
systémům poskytnout prostředek ke sdělení informací o tom, jaké druhy
bezpečnostních mechanismů vyžadují pro akceptaci spojení.
Ačkoli žádný z navržených standardů sám o sobě neřeší problém zabezpečení
webových služeb, společně poskytují základ, na němž lze postavit další
strategii. Standardizační skupina WS-I (Web Services Interoperability)
sdružující dodavatele a uživatele tak před nedávnem schválila části specifikace
WS-Security pro svůj takzvaný základní bezpečnostní profil (Basic Security
Profile), což je soubor nejlepších metod pro zajištění vzájemné spolupráce.
Předpokládá se, že v blízké budoucnosti k tomu přibude rovněž podpora pro SAML
a další standardy.
V krátkodobém horizontu je relativně výhodnou cestou k zabezpečení webových
služeb využití technik, které slouží pro ochranu standardních webových aplikací
to znamená přenosových mechanismů jako SSL. Doplňkovou možnost pro posílení
ochrany síťového provozu webových služeb představuje nasazení běžně rozšířených
XML firewallů například od společností DataPower Technology, Forum Systems,
Reactivity a Westbridge Technology spolu s digitálními XML podpisy.

Orchestrace
Koordinace distribuovaných softwarových součástí za účelem vytváření
smysluplných podnikových procesů je současně nejsložitější a nejsmysluplnější
formou integrace orientované na služby. Důvod je jasný: Řečeno co
nejjednodušeji, aplikace postavené na architekturách SOA jsou navrženy tak, aby
od sebe mohly být odtrženy a v okamžiku potřeby opět složeny k sobě. Jako páteř
současných řešení správy podnikových procesů BPM (Business Process Management)
umožňuje orchestrace IT manažerům vytvářet nové meta-aplikace pospojováním z
funkcionalit aplikačních balíčků nebo jiných již používaných aplikací.
Na první pohled se zdá, že poskládání těchto kousků tak, aby řídily průběh
podnikové transakce, je jednoduchý úkol. Největší problém však nepředstavuje
vytvoření nových modulárních aplikací, nýbrž změna způsobu, jakým tyto systémy
reprezentují zpracovávaná data.
Existuje několik standardů pro orchestraci a správu podnikových procesů. Jedním
z nich je BPEL (Business Process Execution Language), který se těší široké
podpoře, a objevuje se dokonce v řadě BPM produktů ačkoli všichni přiznávají,
že robustní verze BPEL 2.0 je asi 18 měsíců před dokončením. Doplňující
standardy BPEL WS-AtomicTransaction a WS-CAF (Composite Application Framework)
jsou navrženy tak, aby usnadnily komplexní transakce generované dlouhodobými a
stavovými podnikovými procesy.

Podpora starších řešení
Tak jako správná redukce umožní americkému návštěvníkovi Řecka připojit
napájecí kabel notebooku do místní elektrické sítě, specializovaný adaptér
aplikace dovolí jednomu systému natáhnout data ze systému jiného. Stejně jako
mají jednotlivé země svůj vlastní standard elektrických zásuvek, vyžaduje každý
starší systém svůj vlastní adaptér. Po léta byla šíře nabízeného portfolia
adaptérů pro starší aplikace z pohledu zákazníka klíčovým faktorem při výběru
dodavatele pro integraci podnikových aplikací.
Náklady na tuto činnost naštěstí s rozvojem standardů typu webových služeb
postupně klesají, konkurence roste a dodavatelé specializovaní na tuto oblast,
jako například Attunity a iWay, ohromně rozšířily rozsah v současnosti
dostupných možností propojení.
Občas opomíjenou výhodou adaptérů pro starší aplikace je, že mnohdy zakrývají
složitost a hloupost vlastních aplikačních programových rozhraní. Role dobrého
adaptéru se neliší od role dobře sestavené webové služby: Vytváří oddělovací
vrstvu, která izoluje zbytek infrastruktury aplikace od jakéhokoli nepořádku.
Někteří dodavatelé, jako firma Software AG, se proto specializují na
sémantickou integraci starších aplikací do integračních páteří založených na
XML.
Aplikační balíčky od společností typu Oracle a SAP již poskytují určitý stupeň
podpory propojení založeného na standardech, typicky přidáním vlastního API,
jako je Business API společnosti SAP s rozhraním SOAP. Přesto však budou drahé
vlastní aplikační adaptéry nadále jedinou možností připojení mnohých opravdu
archaických systémů do společného integračního rámce.

Sémantika
Vymezení obchodního významu jednotlivých transakcí a dat je nejúpornějším
problémem, kterému musejí IT manažeři čelit, a žádná technologie ani softwarový
produkt jej nemůže doopravdy vyřešit. Podnikoví IT manažeři musejí nakonec vzít
na svá bedra těžkou práci spojenou s vymezením a implementací funkcí a datových
modelů pro procesy specifické pro dané odvětví.
Společnosti si stále více uvědomují hodnotu standardů založených na XML pro svá
vlastní odvětví. Například odvětví finančních služeb vyvinulo protokol FIXML
(Financial Information Exchange Markup Language) pro bankovní transakce a
odvětví účetnictví navrhlo protokol XBRL (Extensible Business Reporting
Language) pro popis a kontrolu záznamů ve stylu hlavní knihy.
Mnoho uživatelů tvrdí, že dynamika odvětví, v němž společnost působí, může být
jednou z nejdůležitějších hnacích sil při přechodu na architekturu SOA. Bob
Sutor, ředitel pro infrastrukturu WebSphere ve společnosti IBM, poznamenává, že
odvětví jako finanční služby jsou mimořádně aktivní, pokud jde o zavádění
architektury SOA. Kromě technologických katalyzátorů, kterými jsou standardy v
rámci vertikálního odvětví, poukazuje Sutor rovněž na vysoký počet fúzí a
akvizic jako jednu z hlavních příčin tohoto trendu. Spíše než pomalé třídění a
kopírování informací z jednoho systému společnosti do druhého by podle něj měly
v případě fúze přijít ke slovu malé chytré adaptéry ve stylu SOA, které dokáží
začlenila jednotlivá podniková oddělení do komplexní sítě rychleji než jiné
technologie.
Navzdory všem obtížím se většina IT manažerů shoduje v názoru, že přijetí
integrační infrastruktury orientované na služby je spíše otázkou "kdy" než
"zda". I zde však do značné míry platí staré pořekadlo "dvakrát měř, jednou
řež".
"Obchodní potřeby firmy a používané IT technologie musejí být ve vzájemném
souladu. Nepouštějte se do služeb jen proto, že jde o senzační technologii.
Řiďte se požadavky podniku a kritérií návratnosti investic," radí Sprott.
Crowhurst k tomu dodává, že je rozhodující naučit se správně reprezentovat
základní obchodní procesy jako služby. "Změnit způsob, jakým probíhá vývoj,
vyžaduje určitý kulturní posun," říká Crowhurst. "V porovnání s tím jsou
technické otázky pouhým intelektuálním cvičením."

A jak je to s výkonem?
Pět problémů zachycených v tomto článku odráží kompromisy, které s sebou
přináší distribuovaná architektura SOA založená na webových službách. Skeptici
však často vyzdvihují ještě jeden problém, kterým je výkon. Tato kritika má
obecně dva cíle: distribuovanou povahu architektury SOA a zátěž plynoucí z
protokolů webových služeb.
Jakýkoli distribuovaný systém funguje pomaleji než systém soběstačný, jednoduše
proto, že síť se stává omezujícím faktorem. A některé aplikace samozřejmě
nedokáží tolerovat prodlevy způsobené sítí. Tento axiom však neplatí jen pro
webové služby či architekturu SOA. Výhody flexibility a snadného přístupu
získané tím, že systémy ponecháme v bezprostřední blízkosti reálných procesů,
které zastupují, dokáží nicméně výrazně převýšit nevýhodu nižšího výkonu, která
je důsledkem síťové režie.
Podstatnější námitkou je relativní náročnost XML transakcí v porovnání s
transakcemi binárními. Odhaduje se, že zatížení aplikačního Java serveru
potřebné pro zpracování relací v protokolu SOAP je 10krát vyšší, než úsilí
vynaložené na odpovídající nativní přístupy, například prostřednictvím
technologie Remote Method Invocation. To zní logicky, dokud nevezmeme v úvahu
zkušenosti získané z webu. Stejně jako HTML má i XML velmi rozvláčný přístup k
popisu informací. Přesto je to právě ona čitelnost a rozšiřitelnost, která
úbytek výkonu vyváží. A Moorův zákon spolu se specializovanými zařízeními, jako
jsou XML akcelerátory usilovně přispívá k dalšímu snižování významu výkonu v
průběhu času.
Jednoznačná pravda nakonec není ani na straně zastánců ani na straně kritiků
webových služeb. Jde o to použít správný nástroj ke správnému účelu. Pro
velkoobjemové transakce budou po určitou dobu nadále používána vlastní binární
middlewarová řešení. Naproti tomu aplikace využívající méně četné, avšak daleko
flexibilnější interakce budou stále častěji obsluhovány webovými službami.

Tipy pro návrh architektury SOA
Realita termínů, odbornosti týmu a napnutých rozpočtů většiny projektů znamená,
že rozhodujícím impulzem pro vybudování architektury SOA není ani tak
technologické hledisko, jako spíše požadavek maximální návratnosti investic do
softwaru. Proto zde uvádíme několik klíčových zásad pro vytvoření návrhu
řešení, které si klade ambice na dosažení rychlé návratnosti.

Začněte v malém
Abyste získali zkušenosti a brzy dosáhli hmatatelného přínosu, začněte tím, že
stávající rozhraní zabalíte do protokolu SOAP a jazyka WSDL, čímž dosáhnete
jednosměrné point-to-point integrace. Tyto první webové služby by měly imitovat
současná API zaměřená na data. Vhodnými kandidáty jsou základní stabilní
aplikace běžící na starších systémech či zavedené správně definované aplikace
obchodních pratnerů.

Postupujte podle plánu
Trojfázový plán k dosažení vyzrálého produktu obnáší:
1. Služby imitující dosavadní API, určené pouze ke čtení a zaměřené na data.
2. Obousměrné transakční modely, jež využívají vznikající standardy a
schopnosti původního produktu.
3. Asynchronní na dokumenty zacílené modely, které odrážejí zaměření
podnikových procesů na návrh orientovaný na služby.

Nechte se vést procesy
V každé fázi zralosti pohlížejte na SOA z hlediska podnikových procesů. Každou
webovou službu nejprve navrhněte jako samostatný modul z hlediska vstupů a
výstupů ještě před specifikováním typu dat či API. Její rozhraní a popis
prostřednictvím WSDL by měly odrážet tento přístup zaměřený na proces a nikoli
podrobnosti, které dokáže mnoho programovacích nástrojů vygenerovat automaticky.

Zaměřte se na náklady
Vyhledejte manuální procesy skryté v distribuovaných funkcích, jako je prodej v
terénu či zákaznická podpora. Aplikace s vysokými náklady na integraci a správu
jsou vhodnými kandidáty pro investování do projektu orientovaného na služby.

Zvolte vhodnou platformu
Většina společností začne s tím, co už dříve vytvořily na platformě J2EE nebo
.Net. Některé však budou možná chtít zvolit jinou základní platformu pro webové
služby. Například společnost SAP postupně integruje standardy webových služeb
do svého BAPI (Business API); firmy, které do značné míry spoléhají na software
SAP, mohou tedy zabalit aplikace BAPI do protokolu SOAP a jazyka WSDL a
využívat definice společných dokumentů vytvořené SAPem.

Budujte infrastrukturu
Architektura orientovaná na služby, která sestává z heterogenních systémů, musí
čerpat ze své vlastní speciální sady služeb, aby bylo zajištěno, že vše bude
spolehlivě fungovat, vše bude možné spravovat a vše bude bezpečné. Produkty pro
správu webových služeb poskytují funkce, jako je řízení verzí a kvality služeb
(QoS). Další základní potřeby, jako je ověřování, budou pravděpodobně zajištěny
dosavadní infrastrukturou. Základní utility typu přihlašování a transformace
dat jsou rovněž vhodnými kandidáty na sdílené služby.
A nakonec mějte na paměti, že dokonalost je nepřítelem úspěchu. Příliš mnoho
projektů v oblasti IT nakonec neuspěje, neboť manažeři odmítnou praktické
kompromisy anebo se řídí zbožným přesvědčením o té či oné architektonické vizi.
Pragmatismus mnoha způsoby definuje filozofický základ architektury SOA.
Standardy webových služeb a softwarová řešení budou dále zrát, avšak využití
kýžených výhod plynoucích z orientace na služby je možné již dnes.









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