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

POUŽITÍ CASE PRO ARCHITEKTURY SOA SEMESTRÁLNÍ PRÁCE K PŘEDMĚTU 4IT450 - CASE ZS 2009/2010 Vedoucí týmu: Petr David ([email protected]) Členové: Tomáš Šolar ([email protected]) Martin Špírek ([email protected]) Jan Herout ([email protected]) Lukáš Vítek ([email protected])

ŘÍZENÍ

Obsah 1

Úvod ................................................................................................................................................................ 1

2

SOA (= Service Oriented Architecture)............................................................................................................ 3 2.1

Základní Pilíře SOA................................................................................................................................. 3

2.2

Hlavní přínosy SOA pro oblast podnikání .............................................................................................. 4

2.3

Hlavní přínosy SOA pro oblast IT ........................................................................................................... 4

2.4

Nevýhody SOA ....................................................................................................................................... 5

2.5

Mýty o SOA ............................................................................................................................................ 6

2.5.1

Životní cyklus SOA ............................................................................................................................. 6

2.5.2

Expose (=návrh)................................................................................................................................. 6

2.5.3

Compose (=kompozice)..................................................................................................................... 7

2.5.4

Konsume (=konzumace) .................................................................................................................... 7

2.6 2.6.1 3

4

Referenční rámec SOA........................................................................................................................... 7 Vybraný model zralosti SOA .............................................................................................................. 8

SOA Governance ........................................................................................................................................... 10 3.1

Definice a zařazení............................................................................................................................... 10

3.2

Infrastruktura SOA Governance........................................................................................................... 10

3.3

Nástroje SOA governance.................................................................................................................... 12

3.3.1

HP Software a SOA Governance...................................................................................................... 12

3.3.2

CA Unicenter a IBM Tivoli................................................................................................................ 13

3.3.3

Actional ........................................................................................................................................... 13

3.3.4

SOA software................................................................................................................................... 13

3.3.5

Amberpoint ..................................................................................................................................... 13

SOA od IBM ................................................................................................................................................... 15 4.1

Co je to Smart SOA?............................................................................................................................. 15

4.2

Smart SOA styly ................................................................................................................................... 15

4.3

IT hodnota architektury Smart SOA..................................................................................................... 16

4.4

Lidé ...................................................................................................................................................... 17

5

6

7

4.5

Procesy ................................................................................................................................................ 17

4.6

Informace ............................................................................................................................................ 18

4.7

Znovupoužitelnost ............................................................................................................................... 18

4.8

Konektivita........................................................................................................................................... 19

4.9

Integrita procesů ................................................................................................................................. 19

4.10

SOA a Web 2.0 technologie ................................................................................................................. 20

4.11

Obchodní hodnota architektury Smart SOA ........................................................................................ 20

4.12

Optimalizace a inovace podnikových procesů..................................................................................... 21

Služba ............................................................................................................................................................ 22 5.1

Několik pravd o Službě ........................................................................................................................ 23

5.2

Závislosti mezi službami....................................................................................................................... 23

5.3

Principy návrhu služby ......................................................................................................................... 24

5.4

Kontrakt služby .................................................................................................................................... 25

5.5

Typický obsah služby ........................................................................................................................... 26

5.6

Životní cyklus služby ............................................................................................................................ 27

Integrace a SOA............................................................................................................................................. 28 6.1

Jak integrovat ...................................................................................................................................... 28

6.2

Výhody integrace pomocí SOA ............................................................................................................ 29

Integrace CASE nástrojů do prostředí IBM Smart SOA.................................................................................. 30 7.1

IDS Scheer- ARIS SOA Architect ........................................................................................................... 30

7.2

Propojení Aris a IBM Websphere [IBMWebsphere] ............................................................................ 30

7.3

Ukázka jednotlivých rolí v procesu vývoje nové služby ....................................................................... 31

7.4

Ukázka jednotlivých rolí v procesu vývoje nové služby ....................................................................... 31

7.5

Postup vývoje procesu......................................................................................................................... 32

7.5.1

Model v Aris Business Architect ...................................................................................................... 32

7.5.2

Transforamce do Aris BPEL.............................................................................................................. 33

7.5.3

Čištění.............................................................................................................................................. 34

7.5.4

Export z Arisu a import do Websphere ........................................................................................... 35

7.5.5

Testování ......................................................................................................................................... 36

7.6

Několik poznámek k zamyšlení............................................................................................................ 37

7.7

IBM WebSphere Business Modeler ..................................................................................................... 37

8

7.7.1

WebSphere Business Modeler Basic ............................................................................................... 37

7.7.2

WebSphere Business Modeler Advanced ....................................................................................... 37

IBM WebSphere MQ ..................................................................................................................................... 38 8.1

9 10

Přínos pro WEB 2.0 .............................................................................................................................. 38

Závěr.............................................................................................................................................................. 41 Zdroje ....................................................................................................................................................... 42

Ú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

Úvod

2

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

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


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


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 procesů.

celkovou

obnovu

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.

podnikových

[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]

2.5.1

Ž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]

2.5.2

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


2.5.3

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ů.

2.5.4

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


2.6.1

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


Obrázek 3: Model zralosti SOA [Stumpf2006]

9

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

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

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].

3.3.1

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

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]

3.3.2

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]

3.3.3 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]

3.3.4

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.

3.3.5 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

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

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

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

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


IBM WebSphere Process Server

•

IBM WebSphere Integration Developer

•

IBM WebSphere Business Modeler

•

IBM WebSphere Business Monitor

17

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


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

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


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

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

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

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

Služba •

5.1

v celém svém životním cyklu je zvládnuta (viz SOA governance).

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

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

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. 2005. What Belongs in a Service Contract?“. Proces definice kontraktu služby se tedy skládá z:

25

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

Služba

5.6

ŽIVOTNÍ CYKLUS SLUŽBY

Obrázek 7: Životní cyklus služby [Gála2008]

27

Integrace a SOA

6 INTEGRACE A SOA Integrace je v současné době velmi moderním a ze všech stran omílaným tématem. Než se podíváme, jak takovou integraci systémů provádět, podíváme se proč to vlastně dělat. Integrovaný systém může podniku přinášet mnoho výhod. My si je rozdělíme nejdříve na dvě velké kategorie – výhody pro business pohled a výhody z hlediska IT. Z pohledu obchodu čekáme výhody hlavně v podobě rychlosti dodávky a nabídky zboží, dále též ve zvýšení počtu zákazníků, díky předchozím dvěma výhodám a v neposlední řadě též vyšší pružnost obchodních procesů. Z hlediska IT se jedná hlavně o snazší komunikaci a sdílení dat mezi jednotlivými částmi systému, snížení množství dat díky sjednocení a spojení datové základny pro dříve oddělené aplikace, zlepšení IT podpory obchodních procesů aplikacemi a v neposlední řadě též snížení výdajů na IT, ke kterému vede, zvláště v současné době krize, velký tlak ze strany managementu.

6.1

JAK INTEGROVAT

A jak tedy samotnou integraci provádět? Máme dvě základní možnosti integrace: •

Přímá integrace

•

Integrační platforma

Obrázek 8: Typy integrace [Horký2008]

28

Integrace a SOA

Výhody a nevýhody těchto dvou typů integrace jsou uvedeny v následující tabulce

Přímá integrace

(+)rychlý a levný začátek

Integrační platforma

(+) nízké náklady na integraci další aplikace

(–)při změně aplikace je nutné změnit všechna její (+) centrální správa a monitorování propojení

(–)počet propojení rychle roste s počtem aplikací

(+)rychlá reakce na změny (1 aplikace = 1 adaptér)

(–)nelze spravovat a monitorovat centrálně

(–)vyšší počáteční náklady

Integraci také rozlišujeme podle typu integrace, tedy podle toho, co vlastně integrujeme. Základními čtyřmi typy integrace jsou: •

Datová integrace (DI) – integrujeme různé formáty dat, či různé interpretace dat

•

Aplikační integrace (EAI) – dochází k výměně a sdílení dat mezi aplikacemi, případně ke vzájemnému sdílení funkcionality

•

Procesní integrace (BPM) – jedná se o řešení implementace obchodních procesů pomocí více informačních systémů

•

Integrace mezi firmami (B2B)

6.2

VÝHODY INTEGRACE POMOCÍ SOA

V celé práci se zaměřujeme na SOA architekturu, podíváme se tedy na konkrétní výhody plynoucí z integrace pomocí SOA architektury. Dle [Horký2008] můžeme tyto přínosy dělit do dvou hlavních kategorií, na přínosy technologické a přínosy obchodní.

Technologické přínosy

Obchodní přínosy

Volná vazba mezi klientem a službou

Opakované využití stávajících služeb a využití návrhových vzorů

Jednoduchá náhrada starého klienta novým

Snížení nákladů na integraci

Jednoduchá náhrada staré služby novou

Pružná reakce IT na požadavky obchodníků

Jedna služba může implementovat více rozhraní

Rychlé uvedení služeb / produktů na trh

29

Integrace CASE nástrojů do prostředí IBM Smart SOA

7 INTEGRACE CASE NÁSTROJŮ DO PROSTŘEDÍ IBM SMART SOA 7.1

IDS SCHEER- ARIS SOA ARCHITECT

Pomocí nástroje Service Browser v aplikaci ARIS SOA Architect je snadné identifikovat služby pro automatizaci podnikových činností. ARIS SOA Architect podporuje automatické generování BPEL procesů. Exportované BPEL procesy mohou být následně prováděny na platformách jako jsou IBM WebSphere, BEA WebLogic nebo SAP XI. [IDSScheer] IBM a IDS Scheer spolu integrovaly ARIS Business Process Modeling nástroje s IBM WebSphere platformou, tak aby umožnili firmám rozšířit výběr platforem pro procesní modely.

7.2

PROPOJENÍ ARIS A IBM WEBSPHERE [ IBMWEBSPHERE ]

Obrázek 9: IDS Scheer ARIS to IBM WebSphere: Integration introduction [IBMWebsphere]

Popis modelu integrace: 1.

Vytvoření modelu v Aris Business Architect. Model byl přizpůsoben pro implementační předpoklady.

2.

Transformace navrženého procesu(modelu). To zajišťuje BPEL rozšíření IBM pomocí EPC2BPL konvetoru.

3.

Upraví si dodatečná specifikace v Arisu

4.

Výstup z Arisu je hotov a vstupuje do produktu Webspehere Integration Developer. To provádí importovací a migrační nástorje Websphere.

5.

BPEL procesy se zlepšují ve Webspehere Integration Developer. Dělá se ještě dočištění, proces je nyní dokončen a může být otestován.

6.

Po dokončení procesu je vyvinuta označená služba.

7.

Nakonec se vyvinuto řešení

30


7.3

UKÁZKA JEDNOTLIVÝCH ROLÍ V PROCESU VÝVOJE NOVÉ SLUŽBY


7.4

UKÁZKA JEDNOTLIVÝCH ROLÍ V PROCESU VÝVOJE NOVÉ SLUŽBY


31


7.5 7.5.1

POSTUP VÝVOJE PROCESU MODEL V ARIS BUSINESS ARCHITECT


Tento model byl převzat z prezentace firmy IBM, která uváděla úvod integrace produktu ARIS do IBM Websphere. Nutno podotknout, že v obrázku je v horní pasáži procesu prohozeno označení „event“ a „function“. Doufejme, že IBM nepřistupuje takto k celému návrhu a jedná se pouze o záměnu popisů.

32


7.5.2

TRANSFORAMCE DO ARIS BPEL

Obrázek 13: IDS Scheer ARIS to IBM WebSphere: Integration introduction; transformace do Aris BPEL [IBMWebsphere]

33


7.5.3

ČIŠTĚNÍ

Obrázek 14: IDS Scheer ARIS to IBM WebSphere: Integration introduction; čištění [IBMWebsphere]

34


7.5.4

EXPORT Z ARISU A IMPORT DO WEBSPHERE

Obrázek 15: IDS Scheer ARIS to IBM WebSphere: Integration introduction; export [IBMWebsphere]

35


7.5.5

TESTOVÁNÍ

Obrázek 16: IDS Scheer ARIS to IBM WebSphere: Integration introduction; testování [IBMWebsphe]

36


7.6

NĚKOLIK POZNÁMEK K ZAMYŠLENÍ

•

ARIS, je na něj často pohlíženo jako na čistě dokumentační nástroj, už moc ne jako na nástroj, který by se měl využívat ke generování nějakých smysluplných kodů.

•

Současná transformace je pouze jednocestná. Je nutné vytvořit nástroj pro možnost opětovného načtení již naimportovaných změn zpět do Arisu.

•

ARIS2Websphere není v současnosti produkt. Je to pouze schopnost, založená na standartech, zajišťující Websphere BPEL rozšíření, podporováno jak IBM tak IDS Scheer.

•

ARIS2Websphere poskytuje alternativní implementaci životního cyklu BPM založeného na SOA.

7.7

IBM WEBSPHERE BUSINESS MODELER

Tento simulační nástroj pomáhá uživatelům odhadnout, jaký dopad může mít modelace procesů na jejich podnikání. Projekty obsahují nejrůznější konstrukce, prvky a potenciální metody, jak vytvářet SOA projekty zaměřené na zlepšení firemního výkonu. Z přednastavených vzorků zde uživatelé najdou aplikaci na hypotéky, pojistné nároky, na fakturaci pro maloobchod, DSL Provisioning pro telekomunikační služby nebo prognózu dodavatelských služeb pro výrobu. [IBMSOA] •

Umožňuje podnikovým uživatelům navrhování, modelování a dokumentaci důležitých podnikových procesů v zájmu průběžné optimalizace procesu.

•

Poskytuje vestavěnou knihovnu klíčových indikátorů výkonu produktu WebSphere Business Modeler, jež usnadňuje modelování podnikových procesů. Knihovna obsahuje více než 800 klíčových indikátorů výkonu (KPI) otevřených standardů založených na infrastruktuře APQC Process Classification Frameworks (PCF).

•

Odborníkům umožňuje sdílení modelů a spolupráci prostřednictvím webového prohlížeče použitím serveru WebSphere Business Modeler Publishing Server.

•

Podporuje import obsahu XML Microsoft Excel odvozeného ze šablon a souborových formátů včetně Visio a textových souborů s oddělovači.

•

Podnikovým uživatelům umožňuje modelování procesů s použitím vlastních obrázků a stylu BPMN v rámci přizpůsobitelného modelovacího prostředí.

•

Poskytuje integraci s nástroji pro vytváření sestav, například Crystal Reports a podporuje formáty Microsoft Word a PDF. [IMBModeler]

7.7.1

WEBSPHERE BUSINESS MODELER BASIC

Nízkonákladová edice poskytující základní modelování k zachycení dat. Využívá se zejména pro modelování, validaci a dokumentaci. Pracuje ve 3 módech: Basic, Intermediate, Advanced

7.7.2

WEBSPHERE BUSINESS MODELER ADVANCED

Využívá se dále pro pro provedení simulace a k vytvoření exportu vytvořeného kódu. Pracuje v 5 módech: Basic, Intermediate, Advanced, BPEL, FDL

37

IBM WebSphere MQ

8 IBM WEBSPHERE MQ Produkt IBM WebSphere MQ V7.0 poskytuje univerzální páteř systému pro předávání zpráv na distribuovaných platformách pro připojení téměř jakýchkoliv komerčních IT •

Snadnější používání systému pro předávání zpráv "publish-and-subscribe" a JMS (Java Message Service).

•

Podpora standardu Web 2.0 pomáhá při vytváření bohatších uživatelských rozhraní připojením aplikací HTTP pomocí Ajax a REST k páteři systému zpráv WebSphere MQ.

•

Podporované operační systémy: AIX, HP Unix, řada i, Linux, Sun Solaris, Sun Solaris, Windows, z/OS

•

Rozšířená použitelnost díky grafické konfiguraci systému pro předávání zpráv "publish-and-subscribe" a JMS prostřednictvím prohlížeče MQ Explorer využívajícím platformu Eclipse.

•

Rozšířený výkon služby JMS, více selektorů a vyšší propustnost listenerů se zkrácením doby odezvy.

WebSphere MQ propojuje aplikace - může propojit skoro cokoli s čímkoli - a tak umožní napřímit obchodní procesy a zajistit rychlou reakci na požadavky trhu. Přidružené produkty IBM a partnerských firem zprostředkovávají další úrovně integrace, doplňují obchodní funkčnosti a zjednodušují management systémů. WebSphere MQ představuje zásadní vrstvu v "IBM Application Framework for e-business" a je klíčovou technologií pro obchodní integraci.

Obrázek 17: WebsphereMQ, v7.0 [IBM WEBSPHERE]

8.1

PŘÍNOS PRO WEB 2.0

Websphere MQ umožnuje propojení mezi reálnými daty v zákaznických aplikacích, které běží na IBM platformách a novými aplikacemi Webu 2.0

38

IBM WebSphere MQ

Obrázek 18: Vytvoření HTTP mostu mezi aplikacemi a Web2.0 [IBM WEBSPHERE]

Zejména propojení aplikací pomocí AJAX do webu 2.0 umožňuje Websphere MQ získat ještě větší potenciál k integraci více produktů než tomu je doposud. WebSphere MQ (dříve MQ Series) je vedoucím produktem na trhu obchodní integrace s více než 65% podílem na trhu. Podle [IBM WEBSPHERE PLATFORM] bylo k roku 2008 zprovozněno více 550 tisíc serverů využívajících Websphere MQ s více než 10 tisíci zákazníky a 1500 partnery za dobu provozu, která postupem vývoje tohoto produktu začala již před 15 roky.

Obrázek 19: IBM WebSphere MQ Platform [IBM WEBSPHERE PLATFORM]

39

IBM WebSphere MQ

Platforma Websphere MQ v dnešní době poskytuje širokou škálu technilogií a směrů, takže zastřešuje kompletně celé prostředí pro předávání zpráv. To ocení zejména vývojáři, kteří již nemusí psát dlouhé kody pro komunikaci, ale jednoduše si vyvolají APIs (Application Programming Interfaces). IBM Websphere a SOA jsou zastoupeny celou rodinou produktů. Z nejvíce důležitých je vhodné připomenout produkt “IBM WebSphere MQ File Transfer Edition, V7.0.“, který se poprvé objevil v prosinci 2008, který se víceméně stará o datový přesun přes MQ síť. A dále produkt IBM WebSphere MQ Low- Latency Messaging, V2.1., který se stará o vysokorychlostní (méně než ms) přenosy dat, jež využívají finanční aplikace na frontofficech.

40

Závěr

9 ZÁVĚR Jelikož nám bylo doporučeno ať se naše práce zabývá spíše SOA, webovými službami a použitím CASE nástrojů pro řízení architektury SOA obecně, než konkrétním hodnocením a popisem jednotlivých nástrojů, které už beztak byly velmi dopodrobna zpracovány našimi kolegy, zpracovali jsme naši práci tak, aby byla popsána jak teoretická část této problematiky, tak i praktické možnosti použití CASE nástrojů pro řízení architektury SOA a další věci, které s tím úzce souvisí. První kapitola popisuje, co vše si lze pod pojmem SOA představit. Jsou zde uvedeny hlavní pilíře této architektury, její přínosy a důvody, proč je v poslední době stále více zmiňovaná. Součástí této kapitoly jsou ale i mýty a nevýhody této architektury. Je zde také popsán životní cyklus a referenční rámec SOA. Nechybí ani vybraný model zralosti SOA, z něhož lze vyvozovat, ve které fázi zavádění se organizace nachází. V další kapitole je popsán SOA Governance. Nechybí vysvětlení, proč se SOA Governance stává pro firmy, které se rozhodli budovat architekturu založenou na službách, stále častější problematikou. Jsou zde uvedeny a popsány nástroje určené pro SOA Governance od různých firem jako např. IBM, HP, Actional apod.. Je zde také popsáno, jak se mnoho velkých firem, zabývajících se řízením informatiky, snaží vlastními silami problematiku SOA Governance obsáhnout. Kapitola nazvaná „Služba“ si vzala za cíl popsat základních vlastností služby v servisně orientované architektuře. Je zde tudíž jak shrnutí o tom, co je služba, jaké má vlastnosti a co by měla obsahovat, ale také popis toho, jak se služba vytváří a jaký je její životní cyklus. Druhá část této kapitoly se zaměřuje na pojem integrace v rámci SOA, jak integrovat a jaké výhody nám tato integrace přináší. Kapitola „SOA od IBM“ si dala za cíl vysvětlit co je to Smart SOA, popsat 4 hlavní styly, nabízené společností IBM pro jeho integraci a vymezit úkoly pro IT hodnotu architektury Smart SOA. Závěrem pak bylo, že Smart SOA rozhodně není informačním systémem, který by se integroval do podniku a ihned přinášel užitky, ale jedná se o množinu činností, prostřednictvím kterých se musí změnit provoz a filozofie celého podniku, od zaměstnanců, byznys procesy až po znovupoužitelnost jednotlivých funkcí. V poslední kapitole, která se zabývá integrací nástrojů do prostředí IBM Smart SOA, je uvedeno, jak se některé společnosti snaží spolupracovat s IBM tím, že se snaží některé ze svých služeb propojit a maximálně využít jejich potenciál, což je považováno za vhodný tah jak se dostat do popředí, protože spojení se s nástroji od IBM znamená téměř jistý zisk, který se dá získat buď přímou spoluprácí na modelech a nebo následnou prací, kdy klient může IBM využívat a tato firma je schopna klientovi nabídnout doplňkové služby. Zejména se snaží přinejmenším podporovat stejné výstupní formáty, tak aby se snadno dalo pracovat s nástroji jejich vlastními, ale i nástroji od IBM. Zejména IDS Scheer spolupracuje na integraci svých nástrojů ARIS Business Process Modeling s IBM WebSphere platformou.

41

Zdroje

10 ZDROJE [Actional2008] Progress uvádí Progress Actional, Systemonline.cz, 2008, Dostupné http://www.systemonline.cz/sprava-it/progress-software-uvadi-progress-actional-z.htm [online].

z

www:

[Buchalcevova2006] Alena Buchalcevová, Libor Gála. Modely zralosti SOA [online]. Dostupné z http://si.vse.cz/archive/proceedings/2006/modely-zralosti-soa.pdf> [Přístup 12.11.2009] [CBDi2007] CBDi-SAETMSOA Reference Framework http://www.cbdiforum.com/secure/interact/2007-03/images/ACRF01.gif [Coupling] Service oriented.org, Coupling [Přístup 17. 12. 2008]

[online].

[online]

Dostupné

Dostupné

z

z:

[Cowley2005] Stacy Cowley, CA puts SOA at heart of Unicenter overhaul, IT world Canada, 2005, dostupné z WWW: http://www.itworldcanada.com/news/ca-puts-soa-at-the-heart-of-unicenter-overhaul/112936 [online]. [Gála2008] Gála, L., Servise Oriented Architecture; 4. Přednáška k předmětu 4IT410 – Integrace v informačních systémech; ZS 2008 [Horký2008] Horký, J., Integrace a SOA; Přednáška od firmy Ness Czech v rámci předmětu 4IT410 – Integrace v informačních systémech; ZS 2008 [IBMSOA] IBM SOA Executive Summit.[online], dostupné z [online]. [IBMModeler] IBM WebSphere Business Modeler. dostupné z [online]. [IBMWebsphere] IDS Scheer ARIS to IBM WebSphere®integration introduction, Dostupné z [online]. [IBM WEBSPHERE] IBM WebSphere MQ for z/OS, Version 7.0 29.12.2009] [IBM WEBSPHERE PLATFORM] [online ftp://ftp.software.ibm.com/software/websphere/pdf/WMQ_Application_Integration_2009_WP3rd_ed_FINAL.pdf [Přístup 29.12.2009]

[Přístup

]

[IDSScheer] Podnikové procesy jako základ pro Business-driven SOA, Dostupné z [online]. [IMBModeler] IBM WebSphere Business Modeler. dostupné z [online]. [Lestina2007/1] Petr Leština. Co je Servisně Orientovaná Architektura? [online]. Dostupné z < http://bpmibm.blogspot.com/2007/11/co-je-servisn-orientovan-architektura.html> [Přístup 12.11.2009] [Lestina2007/1] Petr Leština. SOA pomalu na obzoru [Publikováno 22.05.07] [online]. Dostupné z [Přístup 14.11.2009]

42

Zdroje

[Louda2008]Pavel Louda, Nástroje pro správu architektury SOA uvedla na náš trh firma HP, Computerworld, 2008, Dostupné z www: http://computerworld.cz/software/nastroje-pro-spravu-architektury-soa-uvedla-nanas-trh-firma-hp-371 [online]. [Mills2009] Steve Mills, Senior Vice President and Group Executive v IBM Software Group, interwiev [Přístup 14.11.2009] [Microsoft2006] Microsoft. Learn About Service Oriented Architecture (SOA) [Publikováno 1.12.2006] [online]. Dostupné z [Přístup 14.11.2009] [Oliver2007] Dave Oliver, What is SOA Governance, 2007, http://geekswithblogs.net/SabotsShell/archive/2007/02/04/105428.aspx [online].

Dostupné

z

www:

[Pittner2009] Kamil Pittner. Abeceda SOA [online]. Dostupné z < http://businessworld.cz/soa-a-eai/abecedasoa-2408> [Přístup 12.11.2009] [Progress2006] Řízení SOA v provozním prostředí, Progress Software, 2006, Dostupné z www: http://www.progress.com/progress_software/worldwide_sites/cz/docs/soa/070913m.pdf [online]. [Progress2008] Progress Software, Inc, Progress Software Corporation dokončila akvizici firmy Mindreef, Inc., 2008, Dostupné z www: http://www.progress.com/cz/o-nas/informace-protisk/pressitem/pressrelease_1143661/index.ssp [online]. [Řepa2003] Řepa, V., Služby a metriky jako nástroj [Přístup 22. 1. 2010] [Rydzi2007] Daniel Rydzi. SOA – východiska a www.cssi.cz/cssi/system/files/all/0rydz.pdf> [Přístup 18.1.2010]

řízení

výhled

IS/IT

[online]

[online].

Dostupné

Dostupné

z

z:

<

[Saugatuck2007] Saugatuck Technology, Inc.,SOA Governance: Necessary Protection for a Strategic Business Investment, 2007, s 7., Dostupné z WWW: http://www935.ibm.com/services/us/cio/flexible/saugatuck_ibm_soa_governance_jun07.pdf [online]. [SOAentryP1] Service Oriented Architecture (SOA) Entry Points, Oficiální webové stránky IBM ENG, Dostupný z WWW:http://www-01.ibm.com/software/solutions/soa/entrypoints/people.html? [SOAentryP2] Service Oriented Architecture (SOA) Entry Points, Oficiální webové stránky IBM ENG, Dostupný z WWW:http://www01.ibm.com/software/solutions/soa/entrypoints/process.html?S_TACT=107AG01W&S_CMP=campaign [SOAentryP3] Service Oriented Architecture (SOA) Entry Points, Oficiální webové stránky IBM ENG, Dostupný z WWW:http://www01.ibm.com/software/solutions/soa/entrypoints/information.html?S_TACT=107AG01W&S_CMP=campaign [SOAentryP4] Service Oriented Architecture (SOA) Entry Points, Oficiální webové stránky IBM ENG, Dostupný z WWW:http://www01.ibm.com/software/solutions/soa/entrypoints/reuse.html?S_TACT=107AG01W&S_CMP=campaign [SOAentryP5] Service Oriented Architecture (SOA) Entry Points, Oficiální webové stránky IBM ENG, Dostupný z WWW:http://www01.ibm.com/software/solutions/soa/entrypoints/connectivity.html?S_TACT=107AG01W&S_CMP=campaign [SOASoftware] SOA Software, Company http://www.soa.com/company/company_overview/ [online].

43

Overview,

Dostupné

z

www:

Zdroje

[Sova2008] Jiří Sova, Michal Gürtner, Marek Dušek, Petr Kovář. Integrační nástroje a jejich vazba ke CASE a modelování vůbec [online]. Dostupné z < www.cssi.cz/cssi/system/files/all/0rydz.pdf> [Přístup 18.1.2010] [SmartSOA] Smart SOA: od jednoduchého ke složitému, IBM, dostupné z www: http://www.itworldcanada.com/news/ca-puts-soa-at-the-heart-of-unicenter-overhaul/112936 [online]. [SmartSOA1] IBM - od jednoduché ke složitému, Oficiální webové stránky IBM, Dostupný z WWW: http://www01.ibm.com/software/cz/solutions/soa/smartsoa/index.html [SmartSOA2] The Smart SOA Approach: Reimagine more from your

business,

Dostupné

z:

[SmartSOA:IT] Smart SOA: IT hodnota, Oficiální webové stránky IBM CZ, Dostupný z WWW:http://www01.ibm.com/software/cz/solutions/soa/smartsoa/it_value.html [SmartSOA:business] IBM Smart SOA: Obchodní hodnota – Česká republika, Oficiální webové stránky IBM, Dostupný z WWW: http://www-01.ibm.com/software/cz/solutions/soa/smartsoa/business_value.html, [Přístup 28.1.2010] [Strumpf2006] Jindřich Štumpf. Proč SOA nemá alternativu [Publikováno 10.2006] [online]. Dostupné z < http://www.systemonline.cz/sprava-it/proc-soa-nema-alternativu.htm> [Přístup 14.11.2009] [Strumpf2007] Jindřich Štrumpf, SOA Koncepty a Technologie, Progress Software, s. r. o., 2007, Dostupné z www: http://si.vse.cz/archive/presentations/2007/soa-governance.pdf [online]. [Tofan2009] Lukáš Tofan, IT Governance a SOA: Co dřív a co později? Business World, 2009, Dostupné z www: http://businessworld.cz/business-rizeni-podniku/IT-Governance-a-SOA-Co-driv-co-pozdeji-4696 [online]. [Voříšek2008] Voříšek, J. a kolektiv, Principy a modely řízení podnikové informatiky. 1. vyd. Praha: Oeconomica, 2008. ISBN 978-80-245-1440-6 [Webservices2003] webservices.xml.com. What Is Service-Oriented Architecture [Publikováno 30.9.2003] [online]. Dostupné z < http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html> [Přístup 14.11.2009] [WebSphere MQ] WebSphere MQ 142.ibm.com/software/dre/ecatalog/Detail.wss?locale=cs_CZ&synkey=G106020C87422R91 29.12.2009]

[Přístup

[WiKi-Service] Wikipedia, the free encyklopedia, Service (systems architecture) [online] Dostupné z: [Přístup 22. 11. 2009] [WiKi-Coupling] Wikipedia, the free encyklopedia, Coupling (computer science) [online] Dostupné z: [Přístup 22. 11. 2009] [ZapThink] Linthicum, D. 2008. The "S" in "SOA" is Services. [online] ZapThink. Dostupné z [Přístup 22. 11. 2009]

44

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

Recommend Documents