POUŽITÍ CASE PRO ŘÍZENÍ ARCHITEKTURY SOA

Transkript

1 POUŽITÍ CASE PRO ŘÍZENÍ ARCHITEKTURY SOA SEMESTRÁLNÍ PRÁCE K PŘEDMĚTU 4IT450 - CASE ZS 2009/2010 Vedoucí týmu: Petr David (xdavp08@vse.cz) Členové: Tomáš Šolar (xsolt02@vse.cz) Martin Špírek (xspim10@vse.cz) Jan Herout (xherj20@vse.cz) Lukáš Vítek (xvitl09@vse.cz)

2 Obsah 1 Úvod SOA (= Service Oriented Architecture) Základní Pilíře SOA Hlavní přínosy SOA pro oblast podnikání Hlavní přínosy SOA pro oblast IT Nevýhody SOA Mýty o SOA Životní cyklus SOA Expose (=návrh) Compose (=kompozice) Konsume (=konzumace) Referenční rámec SOA Vybraný model zralosti SOA SOA Governance Definice a zařazení Infrastruktura SOA Governance Nástroje SOA governance HP Software a SOA Governance CA Unicenter a IBM Tivoli Actional SOA software Amberpoint SOA od IBM Co je to Smart SOA? Smart SOA styly IT hodnota architektury Smart SOA Lidé...17

3 4.5 Procesy Informace Znovupoužitelnost Konektivita Integrita procesů SOA a Web 2.0 technologie Obchodní hodnota architektury Smart SOA Optimalizace a inovace podnikových procesů Služba Několik pravd o Službě Závislosti mezi službami Principy návrhu služby Kontrakt služby Typický obsah služby Životní cyklus služby Integrace a SOA Jak integrovat Výhody integrace pomocí SOA Integrace CASE nástrojů do prostředí IBM Smart SOA IDS Scheer- ARIS SOA Architect Propojení Aris a IBM Websphere [IBMWebsphere] Ukázka jednotlivých rolí v procesu vývoje nové služby Ukázka jednotlivých rolí v procesu vývoje nové služby Postup vývoje procesu Model v Aris Business Architect Transforamce do Aris BPEL Čištění Export z Arisu a import do Websphere Testování...36

4 7.6 Několik poznámek k zamyšlení IBM WebSphere Business Modeler WebSphere Business Modeler Basic WebSphere Business Modeler Advanced IBM WebSphere MQ Přínos pro WEB Závěr Zdroje...42

5 Úvod 1 ÚVOD Pro tuto práci jsme si zvolili téma Použití CASE pro řízení architektury SOA. Práci jsme se rozhodli zaměřit více na SOA a webové služby obecně, přesto jsou zde i kapitoly, které se zabývají integrací CASE nástrojů, obzvláště do prostředí IBM Smart SOA. Práci na tomto tématu jsme v zásadě rozdělili do dvou hlavních částí. První část se zabývá úvodem do problematiky SOA, historií, přínosy, výhodami a nevýhodami a dalšími obecnými charakteristikami servisně orientované architektury. Do první části jsme také zařadili popis webových služeb, jejich životní cyklus charakteristiku a jejich souvislost se SOA. V této části nechybí ani popis SOA Governance a slovník základních pojmů z této oblasti. Druhá část je převážně zaměřena na řešení SOA od IBM a na integraci CASE nástrojů do prostředí IBM Smart SOA. Nechybí základní popis této služby ani možnosti její integrace do podniku. V této části je také možné nalézt ukázku postupu vývoje procesu pomocí Aris a IBM Websphere. Cílem práce je tedy nejenom teoretické popsání SOA, webových služeb a SOA Governance, ale také popis integrace CASE nástrojů do prostředí vyvinutém přední firmou zabývající se touto problematikou (IBM) a možnostmi jejich využití při řízení architektury SOA. 1

6 2 Úvod

7 SOA (= Service Oriented Architecture) 2 SOA (= SERVICE ORIENTED ARCHITECTURE) SOA nebo-li servisně orientovaná architektura je přístup k organizování IT zdrojů pomocí jednotného řešení, které má za cíl maximální zvýšení flexibility managementu v podniku. Architektura SOA pomáhá vzájemně provázat jednotlivé interní a externí procesy. [Lestina2007/2] Toto provázání je možné i napříč organizacemi, tudíž lze propojit společnost s externími partnery, dodavateli, zákazníky apod.. Toto s sebou přináší velkou pružnost a možnost přizpůsobení se a zefektivnění činností. [Pittner2009] Díky takovémuto propojení pak lze velmi rychle reagovat na nové požadavky. SOA je také schopna snížit procesní náročnost fungování infrastruktury ve společnosti. Další velkou výhodu, kterou s sebou SOA přináší je její modulární infrastruktura, ve které lze měnit jednotlivé komponenty dle aktuálních požadavků. Součástí je také používání otevřených standardů. Integrace z pohledu SOA neprobíhá pomocí klasického propojení, ale na bázi procesního řízení. Jelikož SOA ve velkém podporuje možnost znovupoužitelnosti, přináší velmi efektivní využívání již naprogramovaných aplikací. [Webservices2003] SOA také přináší standardizaci stávající infrastruktury a zjednodušení prostředí čímž pomáhá zvýšit kontrolu managementu nad firemními procesy. Implementaci architektury SOA lze chápat jako životní cyklus, tzn. po jednotlivých fázích. [Lestina2007/1] [Buchalcevova2006] Standardizace SOA probíhá např. pomocí webových služeb popisujících funkce aplikací, nebo pomocí Business Process Execution Languae, popisující jednotlivé procesy. [Lestina2007/1] [Lestina2007/2] Lze také říci, že SOA je nástrojem pro integraci různorodých systémů a aplikací. Každý IT prostředek, systém, aplikace nebo obchodní partner může vystupovat jako služba. [Stumpf2006] SOA je v podstatě souborem služeb, které vzájemně komunikují a ke komunikaci používají standardizované protokoly a předem dohodnutá rozhraní. Díky těmto rozhraním lze měnit implementaci služeb, aniž by byla ovlivněna schopnost systému tyto služby používat. [Microsoft2006][Webservices2003] SOA vnímá IT infrastrukturu VÝHRADNĚ v kontextu procesů podnikání a proto je základním úkolem IT zajistit provozní prostředí pro podnikové procesy a poskytnout řídícím pracovníkům informace nezbytné pro řízení společnosti. IT tak není pouze nákladovou položkou, ale aktivní nástroj podílející se na realizaci klíčových cílů podniku. Přes nesporné technologické výhody je jádro SOA v efektivnosti podnikání a pružností reakce na tržní změny. [Lestina2007/1] 2.1 ZÁKLADNÍ PILÍŘE SOA - výčet pilířů v této kapitole je převzat z [Stumpf2006], další informace jsou čerpány z [Rydzi2007] a [Sova2008] Principy současné architektury SOA jsou evolucí předchozích distribuovaných architektur CORBA, DCOM a webových služeb. Současná SOA architektura stojí podle [Stumpf2006] na následující pilířích: Služby jsou volně vázané (loosely coupled) - pomocí generalizovaného rozhraní je docíleno toho, že jednotlivé služby jsou na sobě ve velké míře nezávislé, což znamená, že pokud provedeme změnu v jedné službě není nutné provádět změnu i v ostatních službách, které na ní navazují nebo s ní jinak spolupracují; lze také říci, že jednotlivé služby jsou tzv. zapouzdřeny jejich zdrojový kód není přímo propojen se zdrojovým kódem jiných služeb (podobně jako objekty v C++, Java, atd.) Služby mají hrubozrnné (coarse grained) aplikační programovací rozhraní (API) - hrubozrnné aplikační programovací rozhraní znamená, že služby poskytují mnohem vyšší úroveň funkcionality několik služeb odpovídá skupině podnikových funkcí, naopak jemnozrnná služba by odpovídala pouze jednomu byznys procesu (což je např. jednoduchý dotaz do databáze) 3

8 SOA (= Service Oriented Architecture) Komunikace mezi službami je typicky asynchronní (asynchronous communications) - služby fungují tak, že po odeslání zprávy pokračují v dalším zpracování dat a nečekají na to, až jim druhá služba odpoví; neblokují tedy kanály pro zasílání dalších zpráv jiným službám (podobné jako komunikace serveru a klienta pomocí HTTP) Důsledně se využívají oborové standardy (standard based) - striktně se dodržují standardy typu XML, HTTP, SOAP, WSDL, apod., což např. pomáhá lepší znovupoužitelnosti služby, porozumění funkcionalitě, Služby jsou znovupoužitelné (service reuse) - na znovupoužitelnost se nahlíží jako na žádoucí vedlejší efekt (nikoli cíl) potvrzující dobrou implementaci SOA principů - teprve tehdy, když jsou služby využívány opakovaně, se projeví síla konceptu SOA; jde o to, aby co nejvíce aplikací využívalo co nejméně služeb, což s sebou mimo jiné přináší nižší náklady na tvorbu aplikací Metadata služeb jsou uložena v úložišti (metadata repository) - úložiště by mělo obsahovat nejen dokumentaci pro provoz, vývoj a testování služeb, ale i verze služeb, jejich rozhraní a další důležité informace, které je možné využít při správě, vývoji a nasazení služeb 2.2 HLAVNÍ PŘÍNOSY SOA PRO OBLAST PODNIKÁNÍ Následující kapitola čerpá z [Lestina2007/1], [Microsoft2006], [Webservices2003], [Stumpf2006] Lepší propojení s dodavateli, zákazníky a s businessem celkově - dynamické aplikace jsou k dispozici jak zákazníkům, tak dodavatelům a umožňují jim lepší vzájemnou komunikaci a spolupráci SOA pomáhá podnikové procesy zbavovat závislosti na konkrétní implementaci podpůrných systémů a tím umožňuje lepší reakce procesů na potřeby organizace; s tím souvisí i flexibilní propojení aplikací a řízení procesů skrze tyto aplikace viz jeden z pilířů SOA (loosely coupled) Zlepšená schopnost rozhodování - pomocí distribuce informací mezi kompozitními aplikacemi mají vedoucí pracovníci k dispozici více dat s vyšší přesností; současně lze tato data získávat a zobrazovat dle aktuální potřeby ve velkém množství různých forem (náhledů) Možnost znovupoužití stávajících aplikací pro další rozvoj - viz jeden z pilířů SOA (service reuse) Možnost kontrolovat procesy a monitorovat je v průběhu jejich celého životního cyklu - viz jeden z pilířů SOA (metadata repository) 2.3 HLAVNÍ PŘÍNOSY SOA PRO OBLAST IT Následující kapitola čerpá z [Lestina2007/1] a [Lestina2007/2] 4

9 SOA (= Service Oriented Architecture) Hlavní přínosy SOA vychází především ze základních pilířů SOA, které jsou popsány v předchozí části. Proto je tato kapitola pouze shrnutím dříve již vysvětlených skutečností. Nezávislost na platformě, aplikaci či programovacím jazyku (služby nejsou propojené přímo, ale pomocí rozhraní) Důsledné využívání otevřených oborových standardů Aplikace jsou schopné mezi sebou sami lépe komunikovat Při změně aplikace zůstávají procesy a ostatní integrační rozhraní zachovány (zapouzdření) Flexibilita při přidání nové aplikace (služby) a možnost kombinace s existujícími službami Možnost pružně měnit procesní zpracování v závislosti na podnikatelských potřebách (není potřeba měnit celé systémy ale mnohdy postačí vyměnit jednu službu (proces) za jinou) Opětovná použitelnost aplikací (i když se jedná spíše o vedlejší produkt než o hlavní cíl architektury) 2.4 NEVÝHODY SOA Následující kapitola čerpá z [Lestina2007/1] a [Pittner2009] Je mnohem složitější naprogramovat aplikaci orientovanou na služby, než provést standardní integraci aplikací - aplikace orientované na služby musí být nezávislé na platformě, aplikaci či programovacím jazyku, přesto spolu musí být schopné komunikovat; počítá se s jejich dalším využitím v jiné aplikaci -> toto vše a mnoho dalšího s sebou přináší podstatně větší nároky na naprogramování než standardní integrace aplikací SOA jako metodologie sama o sobě žádný reálný přínos nemá - přínosem, jsou až dopady, jaké má na složitou a redundantní firemní infrastrukturu Celý postup zavádění SOA je potřeba podrobně sledovat a kontrolovat - je to z toho důvodu, aby nedošlo k neefektivnímu řešení, které by danou situaci zkomplikovalo místo toho aby ji zjednodušovalo, je třeba neustále sledovat výkon, poruchovost a především bezpečnost jednotlivých služeb V první fázi vyžaduje mnohem více nákladů na uvedení do provozu - toto úzce souvisí s první popsanou nevýhodou > jelikož celý koncept SOA musí být postaven na jednotlivých samostatných službách, které jsou propojeny pomocí určitého rozhraní, přináší to sebou podstatně vyšší komplikace a tudíž i náklady na zprovoznění takového modelu; naopak následná investice při výměně jedné služby za jinou bývá obvykle nižší než v případě nutnosti přepsat část zdrojového kódu v aplikaci; tento rozdíl v nákladech pak ještě více narůstá, pokud danou službu použijeme znovu v dalších aplikacích 5

10 SOA (= Service Oriented Architecture) 2.5 MÝTY O SOA Mýtusus Jedná se o kompletní produkt, který si je možné zakoupit. Cílem organizace je vybudování SOA. SOA požaduje celkovou obnovu podnikových procesů. Pravda SOA je pouze filozofie, která radí jak dané řešení budovat. SOA není cíl, jedná se pouze o prostředek k jeho dosažení. Řešení pomocí SOA by měla být přírůstková a postupná, využívající stávající systémy. [Microsoft2006], [Webservices2003], [Stumpf2006] Aplikace se skládají z nezávislých bloků (služeb). Služba je komponenta, která má přesně definované rozhraní, a toto rozhraní určuje funkcionalitu, kterou poskytuje. Nejčastějším transportním kanálem pro webové služby bývá standard HTTP nebo HTTPS. Řada společností záměrně nespojuje architekturu zaměřenou na služby (SOA) s webovými službami. Webové služby nejlépe naplňují podstatu architektury orientované na služby, nicméně nepředstavují jediný prostředek k její realizaci. Komunikačním protokolem tedy nemusí být pouze SOAP a transportním protokolem nemusí být jen HTTP či HTTPS. [Lestina2007] ŽIVOTNÍ CYKLUS SOA Tato kapitola vychází z anglického článku [Microsoft2006]. IT prostředky každé organizace zahrnují data, provozované systémy, různé druhy specializovaných aplikací a informace o obchodních partnerech. Všechny tyto zdroje vystupují jako služby produkující celou škálu výstupních dat. Servisní architektura seskupuje tyto odlišné zdroje informací společně s operačními systémy, technologiemi a komunikačními protokoly. Toto seskupování probíhá iterativně ve třech krocích: nejprve jsou vytvořeny nové služby (vytvoření), poté jsou tyto služby zakomponovány do větších aplikací (kompozice) a nakonec jsou výstupy služeb předány ke zpracování koncovým uživatelům (konzumace). Obrázek 1: Životní cyklus SOA [Microsoft2006] EXPOSE (=NÁVRH) V prví fázi je třeba navrhnout, jaké služby je třeba vytvořit nad stávajícími aplikacemi a daty. Návrh těchto služeb může být jak jemnozrnný (1 služba = 1 business proces) a nebo hrubozrnný (více služeb odpovídá určité skupině podnikových funkcí). V této fázi je třeba také zvážit jejich implementaci buď přímo pomocí webových aplikací a nebo nepřímo pomocí nějakého rozhraní. 6

11 SOA (= Service Oriented Architecture) COMPOSE (=KOMPOZICE) Po vytvoření jednotlivých služeb je lze zkombinovat do větších celků. Díky tomu že jsou tyto služby na sobě i na platformě nezávislé, lze je navzájem kombinovat a znovu-používat s maximální flexibilitou. Současně při dalším vývoji business aplikací je lze snadno upravovat bez omezeních, vyplývajících ze stávajících aplikací a systémů KONSUME (=KONZUMACE) Jakmile jsou nové aplikace nebo business procesy vytvořeny, jejich funkcionalita musí být poskytnuta pro jiné IT systémy a koncové uživatele. Cílem tohoto procesu je dodat nové dynamické aplikace, které umožní zvýšení produktivity a lepší možnost nahlížet do fungování a výkonnosti businessu. Uživatelé mohou tyto služby využívat mnoha způsoby včetně webových portálů, kancelářských aplikací, mobilních zařízeních apod. Z pohledu IBM se jedná o hledání cest, jak za pomoci nejmodernějších technologií zajistit uspokojování nových potřeb a požadavků neustále se měnícího trhu. [Steve2009] Termíny SOA a webové služby bývají často zaměňovány. Ale přestože s pomocí webových služeb se implementace SOA stává jednodušší, tyto termíny nelze volně zaměňovat. SOA je způsob navrhování systémů, zatímco webové služby jsou implementační technologie, které používají specifické standardy a protokoly k dosažení řešení založeného na principech SOA. [Webservices2003], [Stumpf2006] 2.6 REFERENČNÍ RÁMEC SOA Obrázek 2: Referenční rámec SOA [CBDi2007] 7

12 SOA (= Service Oriented Architecture) VYBRANÝ MODEL ZRALOSTI SOA - převzato z [Stumpf2006] 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. 8

13 SOA (= Service Oriented Architecture) Obrázek 3: Model zralosti SOA [Stumpf2006] 9

14 SOA Governance 3 SOA GOVERNANCE 3.1 DEFINICE A ZAŘAZENÍ Na úvod je vhodné SOA Governance zařadit jako takovou. SOA Governance se dá definovat mnoha způsoby. Jindřich Štrumpf ze Společnosti Progress například definuje SOA Governance jako "souhrn nástrojů, politik, procesů a SOA modelu pro správu, řízení, reporting a virtualizaci volně spojených IT prostředků" [Strumpf2007]. Jednodušeji řečeno je SOA governance řízení a správa architektury SOA. Tedy způsob jakým aplikovat architekturu SOA do firmy. V současné době se o záležitostech týkající se SOA velmi mnoho hovoří. Tento trend je pochopitelný už dle zařazení SOA Governance. Dá se říci, že SOA Governance je podmnožinou IT Governance. Vzhledem k tomu, že v současné době je zde silná snaha ze strany firem propojit business a informatiku, je potom jasné, že SOA Governance má v této oblasti nemalý význam. Toto tvrzení je možné podložit i citací z odborných článků, které ukazují důležitost vztahů mezi těmito pojmy. "Jednou z nejčastějších příčin selhání již započatých projektů SOA jsou nedostatky ve fungování governance mechanismů. Ve chvíli, kdy se množství implementovaných služeb rozroste, není možná jejich správa bez metodického a procesního ukotvení v podobě SOA governance. Ta ovšem musí vycházet z vyšších principů nastavených v IT governance, jinak skončíme s potenciálně velice výkonným nástrojem, který ale sám o sobě žádný pozitivní obchodní efekt nepřináší." [Tofan2009] Dle dalších zdrojů je možné vztah mezi IT Governance a SOA Governance doložit jako "SOA Governance je aplikací IT Governance specificky zaměřenou na životní cyklus služby, metadata a aplikace v organizační SOA architektuře" [Saugatuck2007] Na základě historického vývoje je zřejmé, že dříve když nebylo SOA tolik zaváděné, nebylo nutné klást na SOA Governance takový důraz. V současné době se však situace mění a kvalitní řízení budování architektury SOA se stává nutností. Na základě toho jsou stanoveny určité požadavky, které by moderní řešení SOA Governance mělo poskytovat. Jedná se především o možnost: "automatického zjišťování a poskytování konzumentů služeb, nabízet rozhraní pro integraci s registry/úložišti metadat, mapování toků zpráv a sledování vzájemných vazeb mezi službami, detekci a eliminaci nebezpečných služeb, oddělení politik a služeb, virtualizaci reálných procesů pro různé typy uživatelů, proaktivní nasazování politik (bezpečnost, shoda s předpisy/zákony), změna politik nezávisle na změnách služeb." [Progress2006] 3.2 INFRASTRUKTURA SOA GOVERNANCE Celkovou oblast SOA Governance je obsáhnout řadou dalších pojmů, mezi tyto pojmy lze zařadit. Run Time Design Time Repository 10

15 SOA Governance Registry Policies Change-time První z těchto skupin, je run time governance neboli řízení v provozním prostředí. Na tuto oblast je patřičné dbát velký důraz, neboť je v řízení SOA oblastí kritickou. Žádná firma nepovažuje za žádoucí selhání jednotlivých služeb a tím i prodlevy v provozu. Další části je Design Time, který je považován za klíčovou část SOA Governance a obecně se má za to, že na této oblasti závisí úspěch SOA Governance a ve většině případů zde také končí. Je to zřejmé, neboť architektura, která nebude správně nadesignována a nebude dostatečně dbát na specifické požadavky firmy a prostředí, nemůže dosáhnout úspěchu. Důležité jsou také samozřejmě dobře nastavené politiky a to jak v oblasti designu architektury SOA, tak její nasazení a běhu. Kromě toho je v předchozím výčtu uveden change- time a s tím související management. V tomto případě se jedná o zvládnutí změn v architektuře SOA takovým způsobem, aby to nenarušilo celkovou komplexnost architektury. Pojmy Repositry a registry v souvislosti se SOA jsou vysvětleny na konci této části práce, ve slovníčku pojmů. Jak spolu předchozí pojmy souvisejí, také dobře dokládá následující obrázek: 11

16 SOA Governance Obrázek 4: From Design Time to Run Time [Oliver2007] 3.3 NÁSTROJE SOA GOVERNANCE Co se týče nástrojů pro SOA governance, je nutné si uvědomit, že nabídka není příliš široká. Na jedné straně zde existují nástroje od firem jako jsou Actional, Amberpoint, SOA Software, na druhé straně se objevují rozšíření již existujících řešení typu HP Software, CA unicenter či IBM Tivoli. Podstatné také je uvědomit si, že je možné koupit pouze některé nástroje, celkovou SOA architekturu je možné pouze vybudovat [Strumpf2007] HP SOFTWARE A SOA GOVERNANCE Jak bylo uvedeno v předchozí kapitole i produkt HP Software se snaží rozšiřovat svoje řešení pomocí nových funkcionalit tak, aby splňovalo požadavky kladené na budování SOA architektury. Konkrétně se jedná o nástroje "HP Business Availability Center for SOA, HP Diagnostics for SOA a HP SOA Policy Enforcer pro správu 12

17 SOA Governance architektury SOA, které umožňují lépe monitorovat produkční služby, odstraňovat provozní problémy a řešit změny služeb." [Louda2008] Kromě toho jsou kladeny požadavky i na zvýšení kvality při budování SOA architektury, proto HP Software uvedlo na trh i dva produkty, které se přímo zaměřují na zajištění kvality a správy při nasazování architektur. "Jedná se o produkty pro testování architektury SOA, HP Service Test a HP Service Test Management." [Louda2008] CA UNICENTER A IBM TIVOLI Vedle firmy HP Software se na trhu vyskytují i další velcí hráči, kteří se zabývají architekturou SOA, jedná se o CA Unicenter a IBM Tivoli. Co se týče CA Unicenter, tak to již v počátku trendu SOA řešilo tuto problematiku. [Cowley2005] V otázce IBM Tivoli se poté jedná o tzv. "Smart SOA". O této problematice bude podrobněji pojednáno v dalších částech této práce. Ve stručnosti se pouze jedná o zajištění agilního přístupu k SOA, tedy schopnosti rychle a efektivně reagovat na změny, příležitosti a hrozby. [SmartSOA] ACTIONAL Produkt Actional od již výše citované firmy Progress patří k záležitostem, které se primárně zaměřují právě na SOA Governance. Jak firma sama tvrdí, společně s produktem SOAPscope "pokrývá celý životní cyklus SOA s nejlepšími nástroji pro zajištění kvality a validace SOA v jejich třídě a vedoucími nástroji pro řízení provozu SOA v celém oboru a zajišťuje tak úspěšná nasazení architektury SOA." [Progress2008] Samozřejmě Progress Actional disponuje řadou funkcí. Lze k nim přiřadit "funkce pro vizibilitu, zabezpečení a řízení na bázi politik pro služby, middleware a podnikové procesy. Kompletní SOA governance vyžaduje, aby procesy, služby a politiky bylo možné řídit ve vzájemném kontextu a nikoli jako oddělená sila. Actional odpovídá tomuto požadavku a umožňuje uživatelům monitorovat, analyzovat a provazovat aktivity probíhající v rámci i mimo rámec existujících BPM procesů." [Actional2008] SOA SOFTWARE Firma SOA software existuje od roku 2001 a byla založena v U. S. A. Firma sama se považuje za jedinou, která v oblasti SOA poskytuje komplexní řešení. To samozřejmě už dle předchozích dvou kapitol není pravda. Je však nutné brát v úvahu, že je to již pěkná řádka let, kdy tyto texty byly na webových stránkách firmy uveřejněny [SOASoftware]. Od té doby se situace jistě změnila. Firma poskytuje následující produkty: Portfolio Management - pomáhá propojit investice do IT na základě stretegických rozhodnutí Repository Management - umožňuje firmě rozpoznat jaké služby jsou pro ní žádoucí a jak zapadají do celkové architektury Policy Management - nástroj pro správu politik Service Manager - jedná se o produkt zprostředkovávající zajištění bezpečnosti, monitorování a obsluhy pro SOA a webové služby. SOLA - řeší kritické problémy, vytváří aplikace a části SOA efektivně s co nejvyššími úsporami AMBERPOINT Amberpoint poskytuje SOA Governance ve formě kontroly, která zprostředkovává visibilitu, prosazuje politiky, zajišťuje spolehlivost, reporty a zprávy, a upozorňuje uživatele na akce, které mohou narušit celkovou koncepci 13

18 SOA Governance architektury. [Oliver2007] Tento produkt v sobě obsahuje podstatné části jako je SOA Policy Management a integrování s Repository a Registy. SOA Policy Management - nástroj pro správu politik integrace s Repository a Registry - zjednodušuje komunikaci mezi celkovým prostředím a repository a registry díky jejich integraci. 14

19 SOA od IBM 4 SOA OD IBM Že je společnost IBM na trhu informačních technologií velkým hráčem není nutné zdůrazňovat. Ačkoli již nemá tak významné postavení jako kdysi a její místo v současné době zaujímají společnosti Microsofot nebo Google, má svým zákazníkům stále co nabídnout. V současné době se IBM více zaměřuje na uspokojování potřeb společností než jednotlivých osob. Právě architektura Smart SOA je jednou ze služeb, která by měla společnostem zajistit větší výkonnost v dnešním turbulentním prostředí. 4.1 CO JE TO SMART SOA? Jedná se o architekturu společnosti IBM založenou, jak už samotný název napovídá, na službách. Jejím cílem je implementovat tuto architekturu do podniku, vytvořit z něj globálně integrovaný podnik a získat pro něj výhodu oproti konkurenci. IBM samozřejmě není jediným podnikem zabývajícím se integrací SOA. Podobné služby nabízí Microsoft (Microsoft SOA & Business Process), Progress Software a spousta jiných IT společností. IBM však se svými více než 5700 zákazníky na tomto poli dominuje. Smart SOA je postavena na stylech. Každá firma, která má o tuto architekturu zájem, si může zvolit z jednoho z daných stylů, které znamenají různou úroveň integrace SOA do podniku a taktéž různý přínos pro podnik. [SmartSOA1] 4.2 SMART SOA STYLY IBM ve své architektuře nabízí celkem čtyři styly, přičemž každý ze stylů se liší svoji složitostí a robustností. Obrázek 5: Styly Smart SOA [SmartSOA1] Základní styl Větší agilita v konkrétních oblastech daného oddělení Styl komplexního rozšíření Optimalizace a inovace napříč komplexními podnikovými procesy Styl transformace 15

20 SOA od IBM Implementace inovací podnikového modelu pro podporu globálně integrovaného podniku Styl dynamické adaptace Automatické sledování a reagování na síly trhu bez lidského zásahu (který je v současné době nezbytný) Smart SOA přináší každému podniku dva typy přidané hodnoty. Prvním typem je hodnota obchodní, druhým typem hodnota IT. Obrázek 6: Styly v Smart SOA v detailu [SmartSOA2] 4.3 IT HODNOTA ARCHITEKTURY SMART SOA Technologie je hlavním katalyzátorem vývoje podniku. Kromě toho, že architektura Smart SOA předvídá změny, zpřístupňuje také pokrokovou strategii růstu pro IT. Zajištění agility vyžaduje schopnost rychle a účinně reagovat na změny, příležitosti a hrozby. Architektura Smart SOA je navržena se zřetelem k zajištění agility. IMB definuje celkem 5 základních vstupních bodů, na které se Smart SOA zaměřuje a které v závislosti na vybraném stylu rozšiřuje. Pro každý z těchto bodů pak nabízí i konkrétní software, který má pomoci tuto architekturu do podniku integrovat. Základními vstupními body jsou lidé, procesy, informace, znovupoužitelnost a konektivita. [SmartSOA:IT] 16

21 SOA od IBM 4.4 LIDÉ Cílem je dosáhnout pokud možno co nejefektivnější spolupráce mezi zaměstnanci, zákazníky a partnery. Zaměření Smart SOA na lidský faktor je kritické pro celkovou úspěšnost této architektury, neboť jsou to právě lidé, co řídí interakci mezi službami SOA, které jsou pak důležité pro výsledky celého podniku. Mezi důležité vlastnosti patří: Zrychlení produktivity Redukce nákladů pro přístup k multi-aplikačním a informačním zdrojům Redukce času na rozmístění nových služeb Zvýšení přístupu k procesní flexibilitě Umožnění spolupráce uvnitř a mimo podnik Software podporující tento vstupní bod: IBM WebSphere Portal IBM WebSphere Portlet Factory IBM Lotus Forms IBM Lotus Expeditor [SOAentryP1] 4.5 PROCESY Jedná se o vstupní bod, který poskytuje specifické nástroje a služby, jenž pomáhají usměrnit a zlepšit veškeré procesy napříč celým podnikem. Prostřednictvím tohoto vstupního bodu lze vybudovat základy pro business process management a zlepšit tak efektivnost, flexibilitu a kontrolu nad klíčovými byznys procesy v podniku. Mezi hlavní vlastnosti tohoto vstupního bodu patři: Zlepšení produktivity zaměstnanců Zvýšení spolupráce Implementace nových procesů v kratším čase Maximalizace návratnosti investic Rychlá reakce na obchodní výzvy Software podporující tento vstupní bod: IBM WebSphere Process Server IBM WebSphere Integration Developer IBM WebSphere Business Modeler IBM WebSphere Business Monitor 17

22 SOA od IBM [SOAentryP2] 4.6 INFORMACE Informaci v kontextu Smart SOA je třeba chápat způsobem informace jako služba (information as a service). Taková informace nabízí přístup ke komplexním, heterogenním datovým zdrojům uvnitř společnosti jako ke znovupoužitelným službám. Tyto informace mohou být pak opakovaně využívány napříč procesy k tomu, aby umožnily větší flexibilitu podniku a pozvedly produktivitu IT zdrojů. Vstupní bod Informace pomáhá k: Snížení nákladů a rizik Zvýšení agility organizace Shromáždění, očištění a zpřístupnění dat [SOAentryP3] 4.7 ZNOVUPOUŽITELNOST Znovupoužitelnost zvyšuje efektivitu, snižuje riziko a náklady. Existující aplikace jsou tak pro společnost daleko hodnotnější. Aplikace v celém podniku podporují klíčové byznys procesy a udržují většinu zákazníků, produktů, dodavatelských řetězců a informačních kanálů. Znovupoužitelností běžných funkcí podpoří opakovatelné obchodní chování, sníží možnosti chyb, zlepší obchodní flexibilitu a postará se o lepší návratnost investic. Úspěšné znovupoužívání IT aktiv je velice důležité pro efektivní a cenově dostupnou SOA. Vstupní bod Znovupoužitelnost pomáhá k: Redukci množství nového kódu, který musí být vytvořen pro obchodní iniciativy Snížení nákladů prostřednictvím eliminace redundantních systémů Identifikaci již existujících funkcí jako přístup CRM v existujících aplikacích a procesech Urychlení uvolňování nových obchodních funkcí tvorbou sdílitelných služeb Software podporující tento vstupní bod: Rational Application Developer Rational Business Developer WebSphere Application Server CICS Transaction Server Rational Asset Analyzer Rational Transformation Workbench IBM WebSphere MQ IBM WebSpere Message Broker [SOAentryP4] 18

23 SOA od IBM 4.8 KONEKTIVITA Konektivita služeb je dnes klíčovou částí každé IT strategie. Pomáhá zjednodušit IT prostředí bezpečnějším, spolehlivějším a škálovatelnějším přístupem, aby docházelo k lepšímu spojení s objekty uvnitř a mimo byznys. Spojení lidí, procesů a informací v byznysu s bezproblémovým tokem zpráv odkudkoli a kdykoli to je ta pravá konektivita. Vstupní bod Konektivita pomáhá: Zajistit bezproblémový tok zpráv kdykoli a odkudkoli Budovat důvěryhodné vztahy s existujícími a novými partnery Dělat byznys více dynamický a flexibilní Doručovat konzistentní uživatelské zkušenosti bez ohledu na kanál nebo zařízení Zvýšit přístup k existujícím funkcím aniž by bylo potřeba měnit aplikace Zjednodušit existující aplikace zaměřením na logiku byznysu místo na konektivitu Software podporující tento vstupní bod: IBM WebSphere MQ IBM WebSphere Message Broker IBM WebSphere Enterprise Service Bus IBM WebSphere DataPower SOA Appliances WebSphere Services Registry and Repository Tivoli Federated Identity Manager Tivoli Composite Application Manager for SOA WebSphere Adapters WebSphere Partner Gateway WebSphere Transformation Extender WebSphere Business Events [SOAentryP5] 4.9 INTEGRITA PROCESŮ Integrita procesů přináší do architektury Smart SOA větší agilitu a diferenciaci a posouvá ji tak na další úroveň. Integrita procesů se skládá ze tří klíčových částí: Integrita transakcí: nepřetržité provádění transakcí s možností obnovy dle potřeby WebSphere Process Server, WebSphere Message Broker 19

24 SOA od IBM WebSphere ESB WebSphere DataPower Integration Appliance XI50 WebSphere MQ Integrita interakcí: poskytuje uživatelům aktuální a zabezpečený přístup k informacím a obsahu WebSphere Portal Lotus Forms Integrita informací: zajištění spolehlivých, kompletních a spravovatelných informací IBM Information Server IBM IMS [SmartSOA:IT] 4.10 SOA A WEB 2.0 TECHNOLOGIE Prostřednictvím webu 2.0 lze rozšířit architekturu SOA způsobem, který umožňuje tvorbu uživatelem vytvářených aplikací, zpřístupňuje uživatelské zkušenosti a poskytuje informační služby, včetně snadného přístupu k nim. Mezi software, který toto rozšíření podporuje, patří: WebSphere MQ WebSphere Portal WebSphere Commerce WebSphere Application Server WebSphere DataPower SOA Appliances [SmartSOA:IT] 4.11 OBCHODNÍ HODNOTA ARCHITEKTURY SMART SOA Prostřednictvím obchodní hodnoty Smart SOA nabízí IBM svým zákazníkům stát se globálně integrovaným podnikem. Přeměna v takovýto subjekt se má dít v následujících krocích: Definice a implementace inovativní strategie Optimalizace a zdokonalení podnikových procesů Monitorování klíčových metrik odvětví Využití SOA k průběžnému propojování IT a obchodních činností Ve spojení s globálně integrovaným podnikem IBM často zmiňuje slovo agilita. Neboli pokud má být podnik úspěšný a konkurence schopný, musí vyvíjet nové byznys modely, kterými se odliší od konkurence. K určení, v jaké pozici se podnik bude nacházet, slouží takzvané KAI (key agility indicators). Jedná se o kombinaci metrik 20

25 SOA od IBM ověřených standardů a podnikové ovladače, které společně poskytují mechanizmus pro vyhodnocování agility a mohou pomoci i při odhadování provozních nákladů, efektivity a ukazatelů kvality. [IBM:business] 4.12 OPTIMALIZACE A INOVACE PODNIKOVÝCH PROCESŮ Správa podnikových procesů BPM (Business process management), kterou zpřístupňuje architektura Smart SOA, optimalizuje a inovuje procesy rychleji, a tím pomáhá zlepšovat procesy poskytující organizaci konkurenční výhody. Správné využití, to znamená nikoli pouze modelování procesů, ale také simulace výsledků a spekulativních scénářů s použitím podnikových pravidel k řízení průběhu procesů. Dále pak monitorování klíčových podnikových ukazatelů pro upřesnění procesů. BPM zpřístupněné architekturou SOA pomůže nejen vylepšit procesy, ale také lépe rozhodovat o těchto vylepšeních a investicích. K optimalizaci a inovaci podnikových procesů slouží následující software: IBM WebSphere Business Modeler Modelování, analyzování a simulování podnikových procesů IBM WebSphere Business Service Fabric Urychlení vstupu do architektury SOA s nejlepšími postupy daného odvětví IBM WebSphere Business Monitor Porovnávání výsledků změn ve změně v podnikových procesech kvůli nepřetržité optimalizaci a vylepšování [IBM:business] 21

26 Služba 5 SLUŽBA Pohybujeme-li se ve světě SOA, je Služba základním stavebním kamenem naší architektury. Z toho je patrné, že vytvoření kvalitních služeb je podmínkou pro tvorbu kvalitní SOA, řečeno jinak, kvalita jednotlivých služeb, které SOA tvoří, se odrazí v kvalitě samotné SOA. Pojem Služba lze definovat několika způsoby. Zde bych uvedl například definici organizace OASIS, převzatou z [WiKi-Service] : Service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. V článku [Řepa2003] je služba definována: Služba informatiky je ucelenou skupinou činností, zajišťovanou informatikou organizace, která může být jako celek uživateli IS/ICT poskytnuta nebo odejmuta. Poslední definicí, kterou uvedu, je definice uvedená v [Voříšek2008]: ICT služba jsou koherentní aktivity a/nebo informace dodávané poskytovatelem ICT služby příjemci služby. ICT služba je vytvářena ICT procesy, které při svém průběhu konzumují ICT zdroje (hardware, software, data, lidé). Služba se realizuje na základě dohodnutých obchodních a technických podmínek. Jednou z důležitých součástí služby je její popis. Ten označujeme spojením kontrakt služby. Kontrakt je vyjádřením viditelných aspektů chování služby. Každý kontrakt zahrnuje: popis funkčních charakteristik - charakterizuje jakou hodnotu konzument získá použitím služby specifikace nefunkcionálních charakteristik - charakterizují zodpovědnost poskytovatele za poskytování služby (a dat) včetně odpovědnosti za dostupnost, bezpečnost a další kvalitativní charakteristiky služby politiky - charakterizují pravidla jednání poskytovatele a konzumenta, kterými se určuje, kdo může službu užívat, jaké bezpečnostní procedury musí participující strany realizovat a další pravidla aplikovaná na vzájemnou komunikaci. Dalším pohledem na službu by měla být její funkcionalita. Funkcionalita služby je vždy skryta za rozhraním služby. Každá služba vlastně realizuje nějaký proces, respektive pracovní tok popřípadě jeho část. Rozsah funkcionality Služby je charakterizován granularitou služby. Podle granularity (zrnitosti) služby rozlišujeme: jemnozrnné služby (fine-grained) hrubozrnné služby (coarse-grained) Jemnozrnné služby se vyznačují vysokou znovupoužitelností, představují nějakou základní, atomickou operaci. V případě potřeby modifikace jemnozrnné služby je však třeba přímého zásahu do programového kódu. Hrubozrnná služba je, dá se říci, opakem jemnozrnné služby. Její znovupoužitelnost je tedy nižší, zato modifikovatelnost mnohem snazší. Hrubozrnné služby obvykle reprezentují nějakou významnou činnost, subproces, nebo dokonce celý proces. Celkově je každá služba charakterizována v SOA následujícími vlastnostmi: volná vazba, standardizace, abstrakce, skládatelnost (composable) a modularita, objevitelnost a 22

27 Služba v celém svém životním cyklu je zvládnuta (viz SOA governance). 5.1 NĚKOLIK PRAVD O SLUŽBĚ Ačkoli si mnoho lidí myslí, že Služba je vlastně webová služba, není tomu tak. Pod pojmem služba se skrývají i jiné služby než webové. Dle [ZapThink] může být SOA dokonce postavena i bez webových služeb, volbou tradičnějších přístupů jako jsou distributed objects, či custom software systems. Přestože služby, nebo přesněji rozhraní služeb, jsou velmi podobné webovým službám, obsahují ve svých kontraktech mnohem více informací. Druhou vlastností služeb, zmíněnou v [ZapThink] je, že kromě dat produkují služby též chování. Mnoho lidí z těch, kteří služby tvoří či navrhují, si je představují pouze jako zdroje dat, jak tomu je ve většině případů. Ačkoli je tedy mnoho služeb datově orientováno, služby jsou schopny stejně dobře produkovat chování, a dokonce i třeba poskytovat výstupy v podobě chování bez jakýchkoli dat. Třetí zmínitelnou, často opomíjenou skutečností je, že služby nejsou aplikace a tedy by jako aplikace neměly být vytvářeny. Jak bude ukázáno níže, služby mají vlastní specifický styl tvorby, který se velmi liší od tradičního přístupu používaného při tvorbě aplikací. Služba je mnohem menším systémem existujícím v mnoha různých systémech a při její tvorbě tedy musí být brán zřetel na její granularitu, interoperabilitu, její hlavní smysl a na přístup k testování. Služby nejsou kompletní aplikací či dokonce systémem. Jou to vlastně malé části různých aplikací. Nelze je považovat ani za subsystémy. Na konec je třeba zmínit, že každá funkce má svůj specifický účel, a nemůže tedy být komplexní, či přirozeně závislá na jiné službě. Lze je tedy volně připojovat k různým aplikacím a dávat tak aplikacím funkcionalitu dané konkrétní služby. 5.2 ZÁVISLOSTI MEZI SLUŽBAMI Při tvorbě SOA se setkáme též s vazbami mezi jednotlivými službami. Tento vztah je v odborné literatuře označován slovem coupling. Pojem coupling tedy vyjadřuje vnitřní soudržnost a vnitřní závislosti mezi dvěma nebo více službami či komponentami informačního systému. Vazba může být slabá (loose couple), nebo silná (tight couple). Nejjednodušším způsobem, jak rozlišit o jaký typ vazby se jedná je následující úvaha: Jak jednoduché je změnit libovolnou část služby A tak, abychom nemusely měnit službu B? Vyžaduje-li změna v A nějaké změny v B, jedná se o silnou vazbu. Pokud lze snadno změnit A bez zásahu do B, jedná se o slabou vazbu. Architektury se silnou vazbou je mnohem těžší udržovat a též je obtížné jejich znovupoužití. Z toho plyne, že v SOA je hlavním cílem dosáhnout co nejslabších vazeb. Vazby mezi aplikacemi, komponentami či službami lze dosáhnout mnoha způsoby: [Coupling] Nejčastější formou spojení je závislost na specifickém společném rozhraní mezi poskytovatelem a uživatelem služby. Lze tomu předejít použitím WSDL, nebo jiného jazyka pro popis rozhraní. Další forma vazby je vytvořena tehdy, když uživatel služby očekává od dodavatele její konkrétní umístění. Předejít této vazbě lze použitím UDDI. Dvě či více komponent / služeb může být propojeno též potřebou společného jazyka či společné platformy. Pro předejití této vazbě používají webové služby SOAP, nebo jiný typ komunikačního protokolu nezávislého na platformě. 23

28 Služba Nejostřejším typem vazby je sémantická vazba. K té dochází, pokud službu A nelze použít bez služby B. Na obranu proti tomuto typu vazby neexistuje jednoznačná odpověď. Z pohledu [WiKi-Coupling] je pojem slabá vazba (loose-coupled) definovaná jako vztah, ve kterém jeden modul (služba) ovlivňuje jiný modul (službu) v ustáleném rozhraní tak, aniž by se musel starat o ostatní implementace tohoto modulu (služby). Slabá vazba je podle [WiKi-Coupling] obvykle signálem dobře strukturovaného sytému. Dále lze, podle [WiKi-Coupling], říci, že systémy, které nejsou postaveny na principu slabé vazby, mohou mít některý, popřípadě i více, z následujících problémů: Změna jednoho modulu vyvolá potřebu množství změn v dalších modulech Jednotlivé moduly jsou samostatně těžko pochopitelné Jednotlivé moduly je obtížné testovat, nebo znovupoužít bez připojení ostatních závislých modulů Koncept silné a slabé vazby je dle [WiKi-Coupling] v nepřímé závislosti spolu s konceptem soudržnosti (cohesion) slabá vazba napomáhá vysoké soudržnosti a opačně. Vzájemná vazba mezi dvěma prvky A a B poroste tehdy, když například (příklad je uváděný z pohledu tříd, nikoli služeb): A obsahuje atributy odkazující na B (jsou typu B) A využívá metodu, která patří modulu B A obsahuje metodu, která pracuje s B (jako návratovým typem) A je podtřídou třídy B Na druhé straně slabá vazba může redukovat výkonnost, a tak systém, postavený na principu silné vazby, může někdy být žádaným z důvodu dosažení co největší efektivity. I přes tuto skutečnost je v mnoha moderních informačních systémech snížení výkonu často považována za vhodnou kompenzaci za výhody, které přinese postavení systému na principu slabé vazby. 5.3 PRINCIPY NÁVRHU SLUŽBY Když už jsme si řekli, co to služba je a jaké má vlastnosti, podíváme se nyní na způsoby, jak takovou službu tvořit. Při vytváření služby je dle [ZapThink] třeba postupovat podle několika základních principů. Pokud uplatňování těchto principů nezajistí úspěch při tvorbě služeb, přinejmenším vás zavede na správnou cestu. Prvním a nejdůležitějším pravidlem je, že služby by většinou měly být tvořeny s možností znovupoužití. Služby se stávají součástmi mnoha různých aplikací, a proto musí být vytvářeny s cílem poskytovat chování či informace, ale neměly by být specifické pro jednu konkrétní aplikaci. Tento přístup je pro mnoho vývojářů velmi obtížný, neboť celoživotní prací většiny z nich byla právě tvorba rozličných softwarů na jedno použití. Nyní je ale třeba, aby byly jednotlivé modely (služby) použitelné ve více než jedné aplikaci, v jedné doméně. Z toho plyne, že Služby musí být znovupoužitelné, jinak bude celá práce zbytečná. I přesto nemusí / nemohou být všechny Služby znovupoužitelné, neboť kritéria pro znovupoužitelnost mohou být různá. Dalším důležitým principem je, že při návrhu služby je třeba počítat s heterogenitou prostředí. Služby je třeba vytvářet tak, aby se neodvolávaly do žádného domácího rozhraní, či na domácí platformu. Jinak řečeno, služba, která bude vyvinuta v prostředí například Linuxu, by měla být stejně dobře využitelná i v aplikacích běžících v prostředí například MS Windows, či na MAC OS. Kdokoli, kdo vámi vytvořenou službu bude používat, 24

29 Služba musí mít možnost tak činit bez potřeby zkoumání, jak byla služba vytvořena, bez závislosti na jakékoli platformě. Důležitou vlastností služeb je též abstraktnost. Abstrakce umožňuje přístup ke službě z mnoha různých, simultánních procesů, od mnoha simultánních uživatelů. Využití abstrakce je vyžadováno k obejití mnoha protokolů, datových vrstev či bezpečnostních mechanismů, které by mohli být v cestě. V době vytváření Služby musíme též počítat s agregací služeb. Mnoho Služeb se časem stane součástí jiných služeb. Tak se stanou komplexní službou, která je využita nějakou aplikací a právě s tímto je třeba počítat již při tvorbě jednotlivých služeb. Agregací služeb tedy vytváříme příslušné řešení problému (kompozice). Služby nejsou aplikace ani kompletní řešení. S tím by mělo být při jejich tvorbě taktéž počítáno a na základě toho by měl být rozsah jejich funkcionality patřičně omezený. Řečeno jinak, služby slouží k dělání jednoduchých věcí. Potřebujete-li něco komplexnějšího, prostě si vytvořte více služeb a agregujte je dohromady, místo přetěžování jedné prosté Služby velkým rozsahem funkcí. Služby s příliš velkým rozsahem funkcionality jsou považovány za těžkopádné, a jejich znovupoužitelnost (viz výše) je nízká. Navíc je zbytečné tvořit Službu, z níž nakonec není využito více než 10% z rozsahu jejích funkcionalit. Nyní, když rozumíme základním principům návrhu služby, podíváme se na základní otázky, které je třeba si před samotnou tvorbou zodpovědět. Jedná se o: Jak budu vytvářet službu? Jaké k tomu mám dostupné nástroje? Existuje několik základních kroků, které mohou vývojáři využít. Zde nabízím, podle [ZapThink], několik doporučení pro návrh služby: Definujte si účel služby. Konkrétněji řečeno, co bude služba dělat a kdo bude jejím uživatelem. Formulujte si informace, které budou svázány se službou, jako datová schémata, metadata aj. Definujte chování služby pomocí definování jednotlivých funkcí (metod) služby. Definujte si veškerá rozhraní služby, to znamená definovat, jakým způsobem bude služba reagovat na volající aplikace a též jakým způsobem bude služba volána Nesmí být opomenuto definování procedury, která určí, jak bude služba testována. Testování je důležitým, avšak často opomíjeným krokem vývoje služeb. Jak plyne z výše uvedeného, nejdůležitější pro úspěch SOA je jasný přístup k tvorbě Služeb, jejich návrh a testování. V konečném pohledu jde tedy vlastně o staré dobré disciplíny a ne žádné nové technologie, nové nástroje či nové programovací triky. Není to zrovna to, co by lidé chtěli slyšet, ale taková je realita. 5.4 KONTRAKT SLUŽBY Součástí vytváření každé služby je též tvorba kontraktu služby (viz výše). Kontrakt patří v SOA k významným metadatům. Pro popsání kontraktu služby jsem si dovolil převzít shrnutí z [Gála2008], které je konkrétně vytvořeno ze Schmelzer, R What Belongs in a Service Contract?. Proces definice kontraktu služby se tedy skládá z: 25

30 Služba Definice služby Identifikace hodnoty, která bude nabízena Popis funkcionality služby Návrh kvalitativních charakteristik služby a omezujících pravidel použití Definice, jak bude služba fungovat Definice zpráv služby a sémantického formátu požadavků Identifikace podmínek pro dílčí výsledky a chování služby Definice procesního toku, aktivit a kroků, které vedou k vytvoření požadovaných výsledků Definice, jak se službou komunikovat Definice způsobu jak bude konzument služby se službou komunikovat Popis přípustných komunikačních protokolů Rozhodnutí o vhodném stylu vyvolání služby (dotaz/odpověď, oznámení, událostí řízená) Nastavení dalších latentních předpokladů [Gála2008] 5.5 TYPICKÝ OBSAH SLUŽBY Kontrolér služby typ interního routeru, manažera zatížení, anebo dispečera, který zná jak distribuovat požadavky na interní a externí prvky služby. Komponenty služby prvky, které zahrnují kód, který odpovídá byznys logice nebo byznys procesu Interní adaptéry spojovací prvky nebo mechanismus rozhraní, které zajišťují komunikaci a přenos informací mezi prvky služby Komponenty bezpečnosti a ochrany Agenti specifické typy komponent (listener), které slouží k prosazení SLA, monitorování, zachycení informací pro audit a trasování Kompozitní služby Manažer interního workflow zajišťuje interní governance a asistuje při koordinaci úloh, které realizují prvky a komponenty služby, stanovení priority zpracování. Manažer interních pravidel zajišťuje řízení interních pravidel služby, jejich nastavení, apod. 26

31 Služba 5.6 ŽIVOTNÍ CYKLUS SLUŽBY Obrázek 7: Životní cyklus služby [Gála2008] 27