Architektura orientovaná na služby šetří peníze

Architektura SOA umožňuje spojování aplikací napříč sítěmi prostřednictvím společného komunikačního protokolu....


Architektura SOA umožňuje spojování aplikací napříč sítěmi prostřednictvím
společného komunikačního protokolu. Teoreticky tak vývojáři mohou považovat
aplikace za síťové služby, které lze vložit do jediného řetězce, a rychleji
potom vytvářet systémy realizující složité obchodní procesy.

Jedním z příkladů architektury orientované na služby, tedy SOA (Service
Oriented Architecture), je CORBA (Common Object Request Broker Architecture).
Nověji pak organizace používají pro připojení k potřebným aplikacím technologie
webových služeb. Nejlepší vlastností SOA je možnost opakovaného použití kódu.
Vývojáři musejí dát dohromady pouze rozhraní pro existující aplikace a není
tedy třeba psát nové aplikace od začátku při každé změně obchodních pravidel.
"Naše orientace na společnou standardizovanou SOA nám poskytuje ohromné výhody
díky opakované použitelnosti kódu v rámci celé organizace," říká Rick Wiseman,
CTO společnosti Galileo, která poskytuje cestovatelské rezervační služby a
vytváří aplikace založené na konceptu SOA. "Když přijdou požadavky na nové
produkty, nemusíme již začínat vždy znovu na zelené louce. Můžeme složit
produkty z existujících komponent."

Alternativa k EAI
Koncept SOA začíná nabírat na obrátkách. Prosazuje se jako alternativa k
tradičnímu konceptu EAI (Enterprise Application Integration). SOA nabízí něco,
co tradiční EAI ne: flexibilitu, standardní formáty messagingu, větší potenciál
opakovaného použití kódu a nižší náklady na integraci. Namísto architektury
nezávislých aplikací, jež jsou vzájemně propojeny proprietárními systémy pro
předávání zpráv (message brokery), je SOA postavena na softwarových
komponentách obalených rozhraními, která využívají standardy například SAOP
(Simple Object Access Protocol), jež komponenty v případě potřeby volají. Za
SOA stojí teorie, že lze společně využívat nové i existující komponenty jako
například kontrolu finančního kreditu a poskytovat je jako služby bez toho, že
by byly napojeny na specifické uživatelské rozhraní. Komponenty je možné
sdílet, opakovaně používat a vytvářet z nich složené aplikace napříč jakoukoli
sítí. Nicméně jednoduchost konceptu je v rozporu s úsilím, jež je potřeba
vynaložit k tomu, aby staré systémy zapadaly do nové architektury. Organizace
musejí zdokonalit existující aplikace, vybudovat nové middlewarové vrstvy a
navrhnout i nové manažerské postupy a příslušné zabezpečení. Organizace
spadající do skupiny raných osvojitelů SOA se ale rozhodly, že úsilí spojené s
migrací na SOA rozhodně stojí za to a hodlají integrovat jeden projekt po
druhém.

V praxi
Například Hartford Financial Services Group (HFSG) využívala donedávna
monolitický aplikační kód z roku 1997 nazvaný SEMCI (Single Entry Multiple
Carrier Interface), který po jednom zadání dat dovoluje jejich rozeslání na
řadu míst, kde dochází k vyhledávání cen akcií. "Když jsme chtěli udělat nějaká
vylepšení, zjistili jsme, že bude třeba provést zásadní změny v celé aplikaci,"
říká Ben Moreland, manažer aplikační infrastruktury HFSG. Nakonec téměř tři
tucty programátorů aplikaci přepracovaly a vytvořily řadu webových služeb,
které následně napojily na existující back-endové systémy. V rámci této
činnosti skupina také vytvořila referenční architekturu, která by se mohla stát
základem pro elektronický systém firmy zpracovávající majetkové a úrazové
pojištění. "Do rozpočtu na SEMCI jsme zahrnuli platformu pro správu, kterou by
bylo možné použít v celém podniku," říká Moreland. Hned nato ji následoval
registr UDDI (Universal Description, Discovery and Integration) a systémy pro
publikování i předplácení dat. Tyto části položily základ SOA, kterou v HFSG
nadále rozvíjejí.

Modernizace
Dalším důvodem, proč by mohli uživatelé zvažovat SOA, je příležitost
modernizovat obchodní procesy. Společnost Naval Facilities Engineering Command
(NAVFAC) vedla k tomu, aby začala uvažovat o SOA, nutnost uvolnit zaměstnancům
ruce od opakovaného zadávání dat. NAVFAC navrhuje a staví námořní stavby na
celém světě. Její roční obrat v oblasti správy budov činí asi 8,5 miliardy
dolarů. Nejedná se ale o monopol vlastníci námořních nemovitostí si mohou
vybrat z konkurence, mezi kterou patří například General Service Administration
(GSA).
"V minulosti bylo zapotřebí zadávat spoustu dat ručně, aby bylo možné je sdílet
v různých aplikacích, které běžely na různorodých platformách," říká Scott
Smith, asistent CIO společnosti. Podle jeho slov se NAVFAC snažila zefektivnit
svoje procesy správy smluv automatizováním rozhraní mezi dvěma klíčovými
systémy: SPS (Standard Procurement System) ministerstva obrany, což je aplikace
pro Windows, kterou musí NAVFAC povinně používat, a na zakázku NAVFAC
vytvořeným mainframovým informačním systémem FIS (Facility Information System),
který mimo jiné zpracovává data pro finanční řízení a účetnictví projektů.
NAVFAC chce svázat tyto systémy do nových složených aplikací, označovaných
například eProjects a eContracts, které automatizují procesy řízení projektů a
smluv. Kdyby si NAVFAC ponechala konvenční EAI, musela by se pro sdílení
informací mezi aplikacemi spoléhat na message brokery, aplikační adaptéry a
translátory. "Trvalo by to dlouho a stálo by to hodně peněz," říká Smith. Místo
toho NAVFAC obalila současné systémy webovými službami, které z nich vytahují
potřebné informace bez nutnosti dalších změn ve zdrojových kódech aplikací.
"Prostředníka mezi původními systémy NAVFAC, aplikacemi pro Windows a novými
složenými aplikacemi dělá software Fusion od Jacada," vysvětluje Smith. "Nyní,
když hlavní obchodní aplikace NAVFAC podporují architekturu SOA, doufáme, že
nalezneme příležitosti k opakovanému využití komponent," říká Smith. "Opakované
využití jistě nebude stoprocentní, ale nástroje se zlepšují," dodává.

Datum dodání
Přáním společnosti Wall Street Access bylo zlepšit doručování informací
zákazníkům, partnerům a dodavatelům a to ji nakonec dovedlo k přechodu k SOA.
Tato brokerská firma provozuje obchodní aplikaci AccessPoint, v níž agreguje
informace z kapitálového trhu od asi dvaceti poskytovatelů dat, včetně
BusinessWire, CBS MarketWatch, Edgar Online, Pinnacore a Newyorské burzy. "Šlo
tedy o scénář velmi vhodný pro SOA," říká Peter Underwood, viceprezident a
ředitel softwarového vývoje ve Wall Street Access. Přechod na SOA firma začala
s plány hlavních rozhraní otevřených jednotlivým aplikacím, poté vybrala
vývojový jazyk Javu a rozhodla se pro platformu WebSphere od IBM.
Výsledkem je různorodá sada služeb, které tvoří společný rámec. "Jedna služba
například automatizuje datovou výměnu mezi Wall Street Access a externími
poskytovateli cenových nabídek. Další služba zpracovává řízení objednávek pro
řadu aplikací," říká Underwood. "Vše jsme naprogramovali jednou na vrstvě
služeb, přišli jsme s jedním rozhraním a pak jsme nechali všechny ostatní
aplikace toto rozhraní používat. Je skvělé napsat program jednou a používat jej
vícekrát," dodává Underwood.
Navzdory jednoduchosti konceptu ale podle Underwooda přináší budování firemní
SOA řadu technických a obchodních výzev. Jednou z nich je podle něj to, že
udržování SOA vyžaduje vývojářskou disciplínu. "Jednou z nevýhod je, že pokud
udělám změnu v jednom rozhraní, tato změna ovlivní všechny aplikace, které tuto
službu používají," vysvětluje Underwood. "Když jsme začínali, mysleli jsme, jak
nejsme disciplinovaní, ale zjistili jsme, že ve skutečnosti nejsme." Nedostatek
disciplíny je nejvíce cítit tehdy, je-li potřeba provést změny v rozhraní,
které se teprve vytváří. "Rovněž je nutné mít na paměti problematiku
výkonnosti," upozorňuje Underwood. XML je velmi upovídaný jazyk a komunikace
webových služeb vyžaduje serializaci a deserializaci informací. "Je to jako
hovořit přes dva tlumočníky," říká.

Práce v plném proudu
Současní uživatelé SOA se shodnou, že tuto architekturu není možné zavést přes
noc. Podle Morelanda HFSG používala v posledních dvaceti letech určitou formu
infrastruktury, které se dnes říká SOA. Reorganizace aplikace SEMCI jednoduše
tuto myšlenku formalizovala. Nyní HFSG používá svoje SOA na podporu ostatních
služeb, například pro zpracování dokumentů. Rovněž používá SOA k vytváření
služeb zajišťujících přístup do systémů. Původní myšlenkou bylo ověřovat
uživatele v existující profilové aplikaci a jejím prostřednictvím si pak
vyžádat potřebná data, ale šlo o těžkopádný způsob integrace, která by zabrala
několik měsíců vývoje. Namísto toho tedy nyní HFSG používá svou platformu SOA
pro ověřování identity agenta. "Byli jsme schopni to zvládnout na naší servisní
platformě za půl dne," pochvaluje si Moreland. Moreland tvrdí, že praxe
zdůrazňuje přínosy SOA implementované v jeho společnosti, a to včetně zkrácené
doby potřebné pro vývoj a nižších nákladů na údržbu softwaru. Není totiž třeba
mít několik verzí stejné technologie. "A o tom SOA je. Začnete abstrahovat od
technických detailů. Když máte znovu použít obchodní funkci, je to přesně
místo, kde díky SOA ušetříte," říká. Ačkoliv je obtížné kvantifikovat výši
úspor, Moreland tvrdí, že díky ušetřenému času mají nyní jeho zaměstnanci
dvojnásobek času na péči o IT společnosti. Dalším přínosem je podle něj možnost
nespoléhat se na jednoho dodavatele. "Čím jednodušší je dodavatele vyměnit, tím
jej máme raději," říká Moreland. "Chceme mít hodně volnosti, abychom mohli
přijmout nového dodavatele bez nutnosti významného přepracování aplikace po 18
měsících."











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