Použití case pro architekturu SOA

LS 2011
Týmový projekt v rámci předmětu 4IT450.
Zpracoval (a):
-
Jana Bartelová
Václav Formánek
Ivan Kutil
Jan Křenek
Petr Weida
Jan Mach
Petr Uhlíř
Peter Rusiňák
4IT450 - CASE – Computer Aided Systems Engineering
[ POUŽITÍ CASE PRO ŘÍZENÍ
ARCHITEKTURY SOA]
Obsah
1. Úvod .............................................................................................................................................. 1
1.1 Stručná historie ................................................................................................................................... 1
2. Teoretická nástavba SOA ................................................................................................................ 4
2.1 Business popis ..................................................................................................................................... 4
2.1.1 Úvod do SOA................................................................................................................................. 4
2.1.2 Co je to SLUŽBA? .......................................................................................................................... 5
2.1.3 ARCHITEKTURA SOA ..................................................................................................................... 6
2.1.4 Bezpečnost v SOA všeobecně ....................................................................................................... 6
2.1.5 Hlavní přínosy SOA v IS/ICT .......................................................................................................... 9
2.1.6 Nevýhody SOA .............................................................................................................................. 9
3. SOA a webové služby .................................................................................................................... 10
3.1. Vztah SOA a webová služba.............................................................................................................. 10
3.2. Základní prvky webových služeb ...................................................................................................... 10
3.2.1 XML-RPC ..................................................................................................................................... 10
3.2.2 REST ............................................................................................................................................ 11
3.2.3 SOAP ........................................................................................................................................... 11
3.2.4. WSDL ......................................................................................................................................... 12
3.2.5 UDDI ........................................................................................................................................... 13
3.3. Bezpečnost webových služeb a SOA ................................................................................................ 13
3.3.1 XML Denial of Service (xDOS) ..................................................................................................... 13
3.3.2 Neautorizovaný přístup ke službě .............................................................................................. 14
3.3.3 Útok na integritu a důvěrnost dat .............................................................................................. 14
3.3.4 Kompromitování celého systému............................................................................................... 14
3.3.5 Bezpečnostní opatření................................................................................................................ 14
4. SOA a další oblasti ........................................................................................................................ 16
4.1 SOA a EDA .......................................................................................................................................... 16
4.2 SOA Governance................................................................................................................................ 18
4.2.1 SOA Governance referenční model (SGRM)............................................................................... 19
4.2.2 SOA Governance Vitální metoda (SGVM)................................................................................... 20
5. Význam jazyka BPEL v SOA ........................................................................................................... 22
5.1 BPEL ................................................................................................................................................... 22
5.2. Role jazyka BPEL v SOA ..................................................................................................................... 23
5.3. Vybrané nástroje pro správu BPEL procesů ..................................................................................... 23
5.3.1. Oracle BPA Suite a SOA Suite .................................................................................................... 23
5.3.2. IBM WebSphere BPM Suite....................................................................................................... 24
5.3.3. jBoss Community – jBPM a RiftSaw .......................................................................................... 25
6. Spojení přístupu SOA a BPM ......................................................................................................... 27
6.1 Srovnání SOA a BPM .......................................................................................................................... 27
6.2 Překážky propojení ............................................................................................................................ 29
6.3 Přínosy propojení .............................................................................................................................. 30
6.4 SOA a BPM v IBM............................................................................................................................... 31
6.4.1 Tvorba robustní infrastruktury pro SOA a BPM ......................................................................... 31
6.4.2 BPM a SOA jsou přirozeně synergické ........................................................................................ 31
6.5 SOA a BPM trendem budoucnosti? ................................................................................................... 32
7. Analýza trhu s CASE nástroji pro řízení architektury SOA ................................................................ 34
8. Charakteristika vybraných nástrojů dle analýzy trhu ...................................................................... 38
8.1 Microsoft BizTalk ............................................................................................................................... 38
8.1.1 BizTalk technologie ..................................................................................................................... 40
8.1.2 BizTalk Server ............................................................................................................................. 40
8.1.3 Jádro BizTalk Serveru.................................................................................................................. 41
8.1.4 Posílání a příjem zpráv: Adaptéry ............................................................................................... 42
8.2 SAP ..................................................................................................................................................... 43
8.2.1 SAP NetWeaver .......................................................................................................................... 43
8.2.2 SAP NetWeaver Portal ................................................................................................................ 43
8.2.3 SAP NetWeaver Business Warehouse ........................................................................................ 45
8.2.4 SAP NetWeaver Business Process Management/Composition Environment ............................ 46
8.2.5 SAP NetWeaver Process Integration .......................................................................................... 52
8.2.6 SAP NetWeaver Mobile .............................................................................................................. 52
9. Budoucnost SOA: Cloud computing ............................................................................................... 53
9.1 Srovnání SOA a Cloud computingu.................................................................................................... 53
9.2 Výhody Cloud computingu ................................................................................................................ 53
9.3 Nevýhody Cloud computingu ............................................................................................................ 54
9.4 Budoucí vývoj .................................................................................................................................... 55
10. Závěr .......................................................................................................................................... 56
11. Seznam použitých zdrojů............................................................................................................. 57
1. Úvod
V naší práci se budeme snažit co nejobšírněji popsat celou problematiku SOA v oblasti CASE. Na
následujících stránkách se dozvíte o různých aspektech, které s sebou Service Oriented Architecture ve
zkratce SOA přináší. Některé kapitoly navazují na naše předchůdce a doplňují jejich práci o aktuální data
či porovnávají vývoj v SOA odvětví. Představme si nyní tedy strukturu celé práce.
V úvodu se čtenář dozví o historických souvislostech provázející samotný vznik architektury orientované
na služby. Dále bude následovat stručný popis vývoje SOA modelů. Oproti našim předchůdcům bude
oblast historie pokryta v mnohem širším měřítku. V následující kapitole budou představeny základní
teoretické principy fungování SOA. Čtenář bude mít šanci dozvědět se o základních pilířích SOA, na nichž
je technologie postavena. Kromě technických aspektů bude k dispozici i business náhled na tento typ
architektury. Tato kapitola obsahuje i nastínění problematiky využití. Kdo SOA využívá, či komu je hlavně
určena, zde bude naznačeno také. Dále se dozvíte o současné situaci na trhu. Informace obsažené v této
kapitole budou čerpat z analýzy provedené jednou z nejuznávanějších společností věnující se tomuto
odvětví. Kapitola bude pracovat s analýzami společností Gartner. Následující částí budeme navazovat na
práci našich předchůdců. Zde dojde k již zmíněnému porovnání a aktualizaci informací o CASE nástrojích
pro podporu SOA. Čtenáři zde budou mít šanci porovnat změny, které proběhly v některých případech za
uplynulý nebo za poslední 2 roky. Práce se zde bude věnovat popisu nástrojů od IBM, ORACLE, Software
AG a HP. Další kapitolu jsme se rozhodli pojmout ve formě popsání zatím nezpracovaného nástroje.
Čtenář zde bude mít příležitost nahlédnout do podrobné funkcionality produktu od společnosti Microsoft
a jejich řešení v podobě MS BizTalk. Poslední kapitola bude porovnávat 2 podobné modely, a to SOA vs.
Cloud Computing. Zde se mimo jiné dozvíte o předpokládaných trendech v obou oblastech a možných
scénářích budoucího vývoje.
1.1 Stručná historie
Service Oriented Architecture - česky architektura zaměřená na služby je jedním z vývojových stupňů, jež
provází historii vývoje SW. První etapou při návrhu aplikací bylo využití strukturovaného programování,
které pracuje s procedurami a funkcemi. Jedním z hlavních cílů byla i znovupoužitelnost kódu, jež však v
realitě nedosáhla očekávaných výsledků. V průběhu vývoje se začaly aplikovat další přístupy např. v
podobě objektového programování. To přináší zapouzdření, polymorfismus a dědičnost.
Znovupoužitelnost kódu při využívání těchto principů opět vzrostla. O aplikaci vytvořené v objektovém
jazyce můžeme tedy říci, že je složena z mnoha navzájem závislých objektů. Pro nás zásadním stupněm
ve vývoji návrhu aplikací je rozdělení jejich funkcionality do nezávislých komponent. [VSB, 2011]
O službě – Service nyní tedy můžeme říci, že jde o komponentu s přesně definovaným rozhraním, které
určuje její funkcionalitu. Podrobným teoretickým principům bude věnována jiná část práce. My si nyní
představíme některé zajímavé informace z historie vývoje architektury orientované na služby.
Jedním z obecně zažitých názorů je, že SOA byla vynalezena společnost Gartner v 90. letech. Toto tvrzení
je na první pohled absurdní. Mnohem přesnější je, že společnost Gartner pojmenovala již existující trend
a díky její popularitě došlo k rozšíření tohoto pojmu. Jeden z prvních průkopníků SOA Erik Townsend, z
1
jehož článku budeme v této kapitole mnohokrát čerpat, se k tomuto staví naprosto stejně. Pojem, který
propagoval on, stavěl na zcela totožných základech pouze pod jiným jménem. Service-Based Distributed
Systems bohužel nedosáhlo takové popularity jako pojem SOA pod křídly Gartner co. Proto nyní
nehovoříme o SBDS ale o SOA. Pro některé bude dalším zajímavým zjištěním, že princip SOA je mnohem
starší než pojem samotný. Princip dekompozice jednotlivých funkcí aplikace, které jsou dostupné jako
služby, je mnohem starší. Jak Erik Townsend uvádí, na tomto konceptu pracoval již od raných 80. let.
Tvrzení o stáří tohoto podporuje i soudní případ z r. 1997. Řešilo se zde patentování jednoho z principů
SOA. U soudu po prozkoumání všech faktů samozřejmě došlo k zamítnutí patentu „zcela nové“ koncepce,
ale přesto tento případ potvrdil domněnku o všeobecném názoru týkajícím se stáří SOA.
V následujících odstavcích si představme příběh Erika Townsenda a jedny z prvních snah o uvedení SOA
modelu do života. [Townsend, 2010]
Erik ve své práci uvádí, že jedním z důvodů, pro které začala být SOA ideálním řešením, byla práce na
tehdejším projektu v oblasti sjednocení automatizace tovární výroby. Situace vypadala tak, že bylo
přítomno mnoho separátně fungujících automatizovaných stanic. Cílem bylo sjednotit a provázat
jednotlivé stanice výrobních linek. V roce 1982 přišli s řešením Townsend a jeho tým. Pro společnost DEC
(Digital Equipment Corporation) začal vývoj systému INFINET (Integrated Factory Information NETwork).
Cílem tohoto systému bylo vytvoření architektury, jež by byla schopna rozložit jednotlivé prvky tovární
výroby na množství oddělených funkcí, jež by využívaly společný middleware jako druh síťového API.
Jinými slovy šlo o jednu z prvních aplikací SOA konceptu a reálnou snahu o její uvedení do života.
Na následujícím obrázku si můžete prohlédnout tehdejší model navrhovaného systému INFINET.
Obr. č. 1: Model systému Infinet [Townsend, 2010]
Service layer obsahovala základní výpočetní infrastrukturu jako HW a operační systém. Application layer
sloužila pro popis jednotlivých serverových funkcí, jež bychom dnes nazvali službami (Services). Support
layer zastupoval označení pro middleware. Jednou z hlavních překážek při vývoji byla jeho praktická
2
neexistence. Jednou z hlavních priorit bylo tedy vytvoření funkčního middleware. To se podařilo okolo
roku 1986. Došlo k vytvoření konceptu využívajícího Message Queuing. Jak Townsend uvádí, tehdy k
tomuto řešení došlo 17 týmů, pracujících nezávisle na sobě.
Z roku 1989 pocházejí první snahy o aplikaci objektově orientovaného přístupu na problematiku
middleware. Jeden z prvních produktů tohoto trendu bylo vytvoření Application Control Architecture
známou pod zkratkou ACA. Společnosti pracující s objektovým přístupem v oblasti middleware zatím
neměly žádné standardizované vodítko pro svoje snahy. V roce 1991 tak vešla na svět CORBA alias
Common Object Request Broker Architecture, jež se postupem času stala standardem uznávaným OMG.
Jeden z principů objektového přístupu obsažený již v názvu specifikace - Object Request Broker, se dá
považovat za předchůdce principu využívaného ve webových službách pro SOA.
Na počátku 90. let došlo k prvnímu komerčnímu nasazení SOA pro koncového zákazníka. O nasazení SOA
konceptu již byla řeč, ale až tento případ obsahuje klasický typ koncového zákazníka oproti zmiňované
společnosti DEC, jež byla hlavně technologicky zaměřena. V roce 1993 byla vypracována první SOA
případová studie pro společnost Wells Fargo. Vlastní implementace SOA proběhla v roce 1995 a Wells
Fargo se stala první internetovou bankou na světě. Celý projekt byl dokončen za velmi krátkou dobu.
Pouhých 60 dní stačilo k jeho naplnění.
V druhé polovině 90. let kdy došlo k masovému rozšíření Windows po celém světě, vešel do života další
model SOA. Byl jím DCOM od Microsoftu z roku 1996. *DCOM, 2008+ Distributed Component Object
Model byl rozšířením svého předchůdce COM. Byl navržen, aby již podporoval internetové protokoly jako
např. http. Podobně jako CORBA vychází ze specifikací definovanými Open Software Foundation, a to
RPC. S rostoucím rozšiřováním internetu a zvyšováním jeho funkcionality začalo docházet k využívání
webových služeb i v architektuře orientované na služby. Tento trend převládá do dnes a patří k jednomu
z nejrozšířenějších. Webové služby pracují na 3 hlavních pilířích. Jsou jimi SOAP, WSDL a UDDI. Pojďme si
nyní představit, kdy jednotlivé součásti vznikly. V roce 1998 je vytvořena první SOAP specifikace. *W3C,
1998]
O dva roky déle v roce 2000 je napsána první verze WSDL 1.0. Ve stejném roce přišla na svět i první
specifikace pro UDDI. [Wikipedia-1, 2011], [UDDI, 2008]
Jedním z posledních konceptů, o kterém se v této kapitole zmíníme je REST – Representational State
Transfer. Ten byl oficiálně představen Royem Fieldingem v jeho disertační práci pocházející opět z roku
2000. [Irvine, 2001] Až v roce 2001 naopak začaly první práce na DDS – Data Distribution Service.
[Wikipedia-2, 2011]
3
2. Teoretická nástavba SOA
Pro lepší pochopení vztahů mezi jednotlivými nástroji, je vhodné provést teoretický úvod, jakožto to
základní uvedení do problematiky SOA. Přiblíží tak pohled na sofistikovanost celého konceptu a na vazby
CASE nástrojů na tuto architekturu.
2.1 Business popis
2.1.1 Úvod do SOA
SOA (Service-oriented architecture), tedy architektura orientovaná na služby, jako taková přesnou
definici nemá, nejedná se ani o standard, technologii natož produkt. Není to něco, na co společnost
uzavírá smlouvu, podle které dodavatel implementuje části systému. Formulace definice SOA se často
autor od autora liší, ale obecně je popisována jako koncept, styl pro vytváření informačních systémů.
SOA je kolekce znovupoužitelných distribuovaných služeb, které jsou provázány mezi sebou. Jedná se
tedy o modulární strukturu, ve které lze snadno a efektivně vyměňovat jednotlivé moduly (části) podle
momentálních potřeb společnosti. Dochází tak k odstranění rozdílů a hranic mezi jednotlivými aplikacemi
(technologiemi). Samotná integrace SOA je realizována na základě procesního řízení, nikoliv klasického
propojení – integrace. „Tato skutečnost nás posouvá za hranice klasického IT – až k procesům podnikání“
*Lešina, 2007]
Petr Lešina ze společnosti WebSphere Technical Sales popisuje SOA následovně: „SOA představuje
architektonický koncept, který nám umožní překonat překážky, s nimiž se nyní pracovníci IT potýkají.
Jestliže dokážeme transformovat architekturu informačních technologií na servisně orientovanou,
získáme přesný přehled o funkcionalitě, kterou máme prostřednictvím služeb k dispozici. To představuje
značný potenciál pro další rozvoj, navíc založený na systémech, které již vlastníme a provozujeme. “
*Lešina, 2007]
Tím pádem také dochází ke zlepšení komunikace a transparentnosti samotného firemního IT.
Díky SOA mohou firmy provázat jednotlivé interní i externí procesy, které spojují firmu s dodavateli,
obchodními partnery, klienty atd. Stávají se tak mnohem pružnější a flexibilnější. „Výsledkem je pak
skutečnost, že se společnosti mohou flexibilně přizpůsobovat a výrazně tak zefektivnit svoji činnost či
zkrátit reakční doby na externí požadavky“. *Lešina, 2007]
Koncept SOA slibuje organizacím krátkodobou návratnost investic, zlepšení jejich činnosti, zvýšení
podnikové akceschopnosti, rychlejší reakce na změny trhu a snížení nákladů na provoz IT. Aby podniky
mohly tyto přínosy realizovat, potřebují vhodnou, integračně zaměřenou, infrastrukturu schopnou
podporovat vysoce proměnlivé prostředí a co nejširší nasazení služeb tak, aby bylo možné zavést SOA do
celého podniku. [IBM, 2008]
4
Obr. 2: Vztah poskytovatel – konzument. [Barry, 2007]
2.1.2 Co je to SLUŽBA?
Služba je definovaná funkce, která je soběstačná, není závislá na kontextu nebo stavu jiných služeb
[Barry-2, 2007] a je nabízena skrze standardy založených na XML, jako jsou např. WSDL1, SOAP 2a UDDI3.
Má definované rozhraní, pomocí kterého poskytuje informace o sobě samé a nabízí své připojení. Služba
je realizována pomocí webových služeb4. Služby jsou vykonávány na základě kontraktu mezi klientem a
službou samotnou.
To bylo na úvod ke službám, a nyní si probereme některé základní vlastnosti a důležité body podrobněji:
Služby jsou volně vázané (loosely coupled)
Generalizací rozhraní služeb je docíleno toho, že služby jsou na sobě nezávislé. Změna provedená v jedné
službě nevyvolá reakci na změnu v jiných službách, které mají na ní vazbu, nebo s ní jakkoliv spolupracují.
Kdybychom se podívali na službu ještě hlouběji do detailu, tak si ji můžeme představit jako zapouzdřený,
od okolí oddělený, celek. (viz jako objekty v Java, C a jiných OOP jazycích)
Služby mají hrubozrnné (coarse grained) aplikační programovací rozhraní (API)
Hrubozrnností rozumějme to, že služby poskytují širší úroveň funkcionality (např. objednávky, faktury,
oznámení o expedici …), naopak jemnozrnná služba poskytuje užší úroveň funkcionality (např. zjistit stav
expedice, zjistit nové ID …).
Komunikace mezi službami je typicky asynchronní (asynchronous communications)
Služby po odeslání zprávy pokračují v dalším zpracování dat a nečekají na odpověď jiné služby. To
znamená, že neblokují kanály pro zasílání dalších zpráv jiným službám (viz princip komunikace klientserver / HTTP).
Služby jsou univerzální (service reuse)
Slovem univerzální jsou myšleny takové služby, které znovupoužitelné (což je i jedním z principů
samotného SOA). Znovupoužitelné služby jsou takové, které je možno nesčetněkrát použít. Jako dobrý
příklad můžeme uvést „přenos souborů“, který nachází opakované využití.
1
WSDL (Web Services Description Language) - typicky popisuje samotné služby.
2
SOAP (Simple Object Access Protocol) - protokol pro přístup k objektům ve formátu XML.
3
UDDI (Universal Description Discovery and Integration) – specifikace, která definuje jak zveřejňovat a vyhledávat informace o
WS.
4
Webové služby (Web-services) – technologie, které dovolují vytvoření spojení (připojení služeb).
5
2.1.3 ARCHITEKTURA SOA
Pod architekturou si představme celkový pohled na koncepci. Musí být integračně zaměřená, aby byla
schopna rychle, spolehlivě a bezproblémově provázat heterogenní systémy (včetně původních aplikací),
propojit lidi, funkce a výpočetní prostředky napříč podnikem a často i za jeho hranice. [IBM, 2008]
Níže si ukážeme jeden z referenčních modelů, který popisuje dva hlavní pilíře architektury SOA. Těmi jsou
centralizované úložiště metadat a zastřešující vrstva celkového řízení architektury (SOA Governance), do
které patří správa, reporting, vizualizace, řízení a zpětná vazba. Technologická vrstva, aplikační vrstva a
služby představují oddělené fyzické vrstvy, zatímco vrstva podnikových procesů je vrstvou procesní. Čím
výše v modelu postupujeme, dostáváme se ke složitějším, hrubozrnným službám. V nejvyšší vrstvě jsou
služby ve formě čistých metadat, které slouží k popisům podnikových procesů. *Štumpf-2, 2006]
Obr. 3: Referenční model architektury SOA se zdůrazněním úlohy úložiště metadat a úlohy řízení této architektury
*Štumpf-2, 2006]
2.1.4 Bezpečnost v SOA všeobecně
Jednou z hlavních předností SOA je odstranění bariér a technologických rozdílností. Díky své otevřenosti
přináší SOA ale i bezpečnostní otázky. Tradiční zabezpečení zaměřené na prostředky již není plně
dostačující pro dynamická prostředí architektury SOA. K zabezpečení SOA je nutné přidat bezpečnostní
vrstvu, která je zaměřena na uživatele (trust management), přidat bezpečnostní vrstvou zaměřenou na
XML zprávy a také je nutné zajistit možnost podrobení auditu zbývajících prvků. [IBM, 2008]
Jindřich Štumpf ve svém článku poukazuje na velký problémem, který může nastat při zjišťování a správě
konzumentů služeb. „Organizace obvykle nemají žádnou možnost jak se dozvědět, kteří konzumenti
využívají které služby a jaké úrovně služeb dostávají, ani zda k určité službě nepřistupují neautorizovaní
uživatelé. Navíc pokud organizace nevědí, zda služba nebo konzument vůbec existují, těžko na něj mohou
aplikovat podnikové a bezpečnostní politiky.“ *Štumpf, 2006] Osobně další nefunkcionální problém vidím
v možné nedostupnosti služby způsobené například výpadkem internetové konektivity.
6
Obdobný problém je i se smlouvami SLA5, neexistuje způsob pro zjištění úrovně dodávaných služeb, které
si zákazníci sjednávají. IT oddělení má však možnost sledovat a „účtovat“ využívané služby pomocí
nástrojů pro runtime governance. *Štumpf, 2006]
Jak již bylo řečeno, SOA je technologicky spojena webovými službami což přináší celou řadu
bezpečnostních aspektů, které je nutné řešit. Nejúčinnější ochranou před riziky spojenými s webovými
službami a XML daty je využití „prostředníka“, který prosazuje nastavenou bezpečnostní politiku nad
probíhající komunikací. [SecurityWorld, 2009]
Nesmíme také opomenout protokol SOAP, který je přenášen nejen protokolem HTTP, ale i například
protokoly FTP nebo SMTP. Problémem je opět otevřenost textu protokolu SOAP, což může být nežádoucí
vlastnost, pokud přenášíme čísla účtů, rodná čísla apod.
„Přístup k řešení bezpečnostních aspektů SOA pomocí „prostředníka“ vyplývá ze základního požadavku na
bezpečnostní řešení – eliminovat veškerá rizika co nejdříve.“ [SecurityWorld, 2009]
2.1.4.1 Autorizace a Autentizace
Důležitou součástí zabezpečení jsou autorizace6 a autentizace7 - oprávnění klienta využít službu,
zabránění vydávat se za někoho jiného. Prvním krokem procesu autentizace, je získání identity ze zprávy
nebo metadat. S rostoucí schopností spolupráce řešení u služeb SOAP a nutností širší integrace
společností, roste i počet řešení, které využívají různé standardy obsahující informace o identitě:
[SecurityWorld, 2009]




WS-Security tokeny – (UserName, BinarySecurity, X. 509, SAML)
SAML Session Ticket
XML Document Credentials Collector (DCC)
XML Digital Signature
2.1.4.2 Validita požadavku a vyhodnocení
Do této oblasti spadá prioritně kontrola, zda je zpráva ve správném formátu (mapř. XML), zda se jedná o
služby využívající protokol SOAP a jiné. U formátu XML je vhodné ověřit validitu zpráv pomocí XML
schématu (XS, XSD), čímž se výrazně zvýší odolnost proti útokům SQL Injection nebo XPath Injection.
Odolnost proti těmto útokům je také možné zvýšit prohledáváním obsahu na základě vzorů (pattern
scan). Dalším vhodným typem validace zpráv, avšak velmi často opomíjeným, je antivirová kontrola.
[SecurityWorld, 2009]
5
SLA (Service Level Agreement) - dohoda o úrovni poskytovaných služeb dodavatelem.
6
SLA (Service Level Agreement) - dohoda o úrovni poskytovaných služeb dodavatelem.
7
Autorizace - přidělení oprávnění
7
2.1.4.3 Audit
Audit příchozích a odchozích zpráv je běžně zažitým vzorem a je podporován do jisté míry téměř všemi
produkty Enterprise Service Bus (ESB). Vzniká tak datový sklad obsahující auditní logy, které mohou být
zdrojem citlivých informací. Proto je vhodné zajistit integritu těchto dat pomocí digitálních podpisů či
využít šifrování citlivých údajů. [SecurityWorld, 2009]
2.1.4.4 Digitální podpisy
Použitím digitálních podpisů je zajištěno prokázání původu zprávy a zároveň je zaručena i její integrita.
Takto podepsaná zpráva je chráněna před možnými, při kterých dochází k modifikaci obsahu zprávy.
[SecurityWorld, 2009]
U webových služeb je možné použít k digitálnímu podpisu zprávy vlastní privátní klíč a poskytovateli
služby předložit certifikát obsahující informace o identitě a dále také veřejný klíč. Poskytovatel služby by
měl ověřit validitu digitálního podpisu zprávy s použitím veřejného klíče, a zároveň ověřit platnost
předloženého certifikátu u certifikační autority. Po tomto ověření je doporučené provést na základě
identity získané z certifikátu autorizaci, zda má uživatel přístup k dané službě a jejím datům. K validaci
digitálních podpisů také patří ověřování časových známek digitálního podpisu, které znesnadňují Reply
attack8. [SecurityWorld, 2009]
2.1.4.5 Šifrování a dešifrování zpráv
Užití šifrování je vhodné pro ochranu citlivých data ve zprávách. V praxi se často používají transportní
protokoly jako je HTTPS pro point-to-point zabezpečení. Šifrování zpráv však nabízí širší end-to-end
zabezpečení, které lze využít i u již zmiňovaného ukládání dat v auditním logu. Je-li poskytovatelem
služby zaslaná odpověď zašifrována pomocí veřejného klíče klienta služby, je nutné mít k jejímu
dešifrování privátní klíč klienta. [SecurityWorld, 2009]
2.1.4.6 Monitoring transakcí
Z hlediska řešení SOA představuje monitoring transakcí velmi důležitou součást, kterou sledujeme různé
anomálie např. atypicky velké zprávy a dlouhý čas odezvy, které mohou naznačovat možný únik dat v
důsledku např. SQL Injection. [SecurityWorld-2, 2009]
2.1.4.7 Skrytí interních zdrojů
Skrytí interních zdrojů je jednou z metod ochrany systémů. Jako příklad uvedeme maskování interních
zdrojů nebo potlačení HTTP hlaviček, které by mohly vypovídat o implementaci poskytovatele služby.
[SecurityWorld-2, 2009]
8
Reply attack – forma síťového útoku, při kterém je platný přenos dat opakován nebo zpožděn.
8
2.1.5 Hlavní přínosy SOA v IS/ICT
Shrnutím již dříve popsaný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 – flexibilita.

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. Využívání
jen těch služeb, které podnik momentálně potřebuje.

Znovupoužitelnost distribuovaných služeb.

Přesunutí některých nákladu na stranu dodavatele (HW, bezpečnost, zálohování …)
2.1.6 Nevýhody SOA
Sumarizace již dříve popsaných nevýhod.





Složitost vytvoření aplikace orientované na služby a SOA je podstatně náročnější, nežli integrovat
klasickou desktopovou aplikaci.
Nákladné uvedení do provozu v porovnání s provozními náklady a dalším rozvojem.
Obtížné sledování využití služeb, přesněji konzumentů, kteří dané služby využívají a v jakém
rozsahu …
Možné nefunkcionální problémy spojené s výpadkem internetové konektivity.
Možná bezpečnostní rizika.
9
3. SOA a webové služby
3.1. Vztah SOA a webová služba
Technologickým základem servisně orientované architektury (SOA) jsou webové služby. Ty vytvářejí
prostředí pro vzájemnou kooperaci jednotlivých komponent. Rozložení systému na komponenty přináší
větší flexibilitu, protože je možné tyto části dynamicky měnit v čase a přizpůsobovat konečnému řešení.
Ke komunikaci se využívá nejčastěji protokol HTTP (Hypertext Transfer Protocol) a formát XML (Extended
Markup Language) pro přenos obsahu.
Na pojem webová služeb mohou být rozdílné názory nebo pohledy. V našem kontextu se budeme držet
definice organizace W3C *W3C, 2001+: “Webová služba je softwarový systém identifikovaný URI, jehož
rozhraní a vazby jsou definované a popsané pomocí XML. Definice může být objevená jinými
softwarovými systémy. Tyto systémy mohou vzájemně působit s webovou službou způsobem
předepsaným v její definici a s použitím zpráv založených na XML a přepravovaných pomocí internetových
protokolů.”
3.2. Základní prvky webových služeb
Mezi nejznámější prvky webových služeb patří XML-RPC, REST a SOAP. První dvě si popíšeme hlavně pro
komplexnost a následné pochopení vztahů v SOAP, jakožto hlavním řešení pro SOA.
3.2.1 XML-RPC
Protokol XML-RPC vychází ze staršího protokolu Remote Procesure Call (RPC), vyvinutého Davidem
Wintrem ze společnosti UserLand v roce 1996. Cílem bylo vytvořit způsob komunikace aplikací po síti.
Aplikace A předala zprávu aplikaci B, která vzdálená procedura/funkce se má zavolat. Po zpracování na
vzdáleném zařízení obdržela odpověď. Nově tedy místo dvou aplikací na síti, mohou takto komunikovat
jakékoliv dvě zařízení přes internet - položením HTTP requestu s XML popisem.*CHOW, 2008].
Protokol již není dále vylepšován, stal se však předlohou pro SOAP. Více informací je možné najít na
oficiálních stránkách http://www.xmlrpc.com/
POST /server HTTP/1.0
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs-CZ; rv:1.9.0.11)
Host: xmlrpc.example.com
Content-Type: text/xml
Content-length: 314
<?xml version="1.0"?>
<methodCall>
<methodName>trida.jmenoMetody</methodName>
<params>
<param>
<value><int>250</int></value>
</param>
<param>
<value>oblast</value>
</param>
</params>
10
</methodCall>
Obr. 4: Příklad XML-RPC dotazu
3.2.2 REST
Representational State Transfer (REST) byl poprvé zmíněn Royem Fieldingem v rámci jeho disertační
práce *CHOW,2008+. Hlavní myšlenkou je využití možnosti HTTP protokolu - konkrétně 5 základních
metod (GET, PUT, POST, DELETE, HEAD) a vlastnosti URI jakožto jednoznačné identifikátoru zdrojů.
Oproti předcházející XML-RPC nebo dále zmiňované SOAP není orientován procedurálně, ale
datově.
V příkladu ačkoliv se jde o jednu stejnou URL adresu a vždy se používá jiná metoda a to v principu
znamená i vykonání jiné akce. Nejčastěji se GET používá pro získání položky, POST pro vložení hodnot,
PUT pro editaci a DELETE pro smazání.
POST http://server.cz/stranka/akce/zbozi?1024
GET http://server.cz/stranka/akce/zbozi?1024
DELETE http://server.cz/stranka/akce/zbozi?1024
Obr. 5: Příklady URL při REST dotazu
3.2.3 SOAP
Simple Object Acces Protocol (SOAP) je třetím způsobem jak využívat webové služby. Vznikl krátce po
příchodu XML-RPC a samotný pozdější vznik protokolu dal možnost poučit se z jeho předchozích chyb.
Mohl tak přidat uživatelské datové typy, zlepšit podporu znakových sad a základní zabezpečení. S touto
změnou souvisí i celková náročnost na pochopení fungování *CHOW,2008+.
Jako nejvhodnější definic lze použít od organizace W3, že SOAP (Simple Object Access Protocol)) je
nenáročný protokol určený k výměně informací v decentralizovaných a distribuovaném prostředí.
[W3C1,2011]. Ve stručnosti poskytuje jednoduchý způsob pro výměnu strukturovaných a typově
definovaných informací mezi koncovými zařízeními za pomocí XML.
K přenosu opět jako XML- RPC využívá XML, skládající se ze tří částí



obálky (popisuje strukturu co je ve zprávě a jak se má zpracovat)
souboru pravidel kódování,
konvence pro reprezentaci vzdáleného volání procedur a odpovědí.
*Hovorčák,2003+,*Juřek,2004]
11
Obr. 6: Struktura zprávy SOAP vložená do HTTP regestu *Oracle, 2010+
POST /mjurek.EAIdemo_Proxy/WSKontaktniUdaje.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: 183
SOAPAction:
"http://schemas.microsoft.cz/BrozuraBTS/2004/WSKontaktniUdaje/VyhledejKontaktniUdaje"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<rodneCislo
xmlns="http://schemas.microsoft.cz/BrozuraBTS/2004/WSKontaktniUdaje">7003222315</rodneCislo>
</soap:Body>
</soap:Envelope>
Obr. 7: Příklady SOAP dotazu *Juřek, 2004]
3.2.4. WSDL
Při definování tohoto pojmu budeme opět vycházet z definice organizace W3C. WSDL (Web Services
Description Language) popisuje jako XML formát pro popis sítových služeb jako množinu koncových bodů
pracující se zprávami obsahující dokumentově orientované nebo procedurálně orientované informace.
*W3C2,2011+. Jinými slovy jde o jazyk pro popis dostupných služeb, které obsahují informace, jaké
parametry se mají předat a jaké hodnoty budou vracet. V zjednodušeném případě lze na WSDL pohlížet
jako na dokumentaci zapsanou v XML.
12
3.2.5 UDDI
Pro doplnění přidáváme ještě popis poslední pojmu spojeného se SOA. UDDI (Universal Description,
Discovery, and Integration) jsou veřejně dostupné registry se strukturovanými informace o firmách a
jejich službách. Obsahuji informace o dané firmě, třídí webové služby do kategorií a popisují WSDL
3.3. Bezpečnost webových služeb a SOA
S rozšiřováním webových služeb se začíná oblast zájmu více zaměřovat na otázku bezpečnosti. Možná
rizika lze rozdělit do čtyř kategorií: [Melichna,2011]
1.
2.
3.
4.
XML Denial of Service (xDos)
neoprávněný přístup ke službě
narušení integrity a důvěrnosti dat
kompromitování systému jako celku
Jednotlivá rizika rozebereme a podíváme se na možné zabezpečení.
3.3.1 XML Denial of Service (xDOS)
Stejné jako při běžném DoS (Denial of Service) útoku, i zde se útočník snaží zpomalit nebo zastavit
zpracování požadavků webové služby. Servery zpracovávají tyto zprávy a jsou natolik vytíženy, že nestačí
zpracovávat jiné požadavky.
Podle typu útoku se dělí na Single nebo Multiple message xDost
Single message xDos





Jumbo payload - útočník posílá velkou zprávu, aby vyčerpal operační paměť a vytížil procesor
serveru, při nastavení limitu zpracovávané zprávy lze tento útok zamezit
Coercive parsing - útočník zasílá těžko parsovatelné XML soubory
Recursive elements - snahou útočníka je způsobit rekurzivní volání parseru, ochranou je
nastavení limitu rozvoje
MegaTags - útočník zasílá dlouhé názvy entit nebo atributů, ochranou je nastavení limitu délky
elementu nebo atributu
Public Key Dos - zneužití vysoké výpočetní náročnosti při asymetrické kryptografii s cílem vytížit
systém, obranou je vysoký výkon serverů
Multiple message xDos


XML flood - útočník zasílá velké množství zpráv za sekundu, ochranou je vynucení pravidel služby
(Service Level Management)
Resource hijack - útočník zasílá zprávy, až dojde k uzamčení zdrojů aplikačního serveru,
ochranou je implementace prostředníka pro řízení klientského
13
3.3.2 Neautorizovaný přístup ke službě
V tomto typu útoku se snaží útočník získat neautorizovaný přístup ke službám a jejím datům



Dictionary attack - útočník zasílá zprávy se snahou uhodnout správné přihlašovací údaje,
obranou je sledování počty neúspěšných pokusů
Falsified message - útočník zasílá pozměněnou zprávu se správnými přihlašovacími údaji, která
již byla dříve zachycena, základní ochranou je digitální podpis pro zajištění integrity dat
Reply attack -útočník zasílá stejnou zprávu, která byla již do systému odeslána nebo posílá její
části obsahující security token, ochranou je využití časových razítek a ohraničení doby platnosti
3.3.3 Útok na integritu a důvěrnost dat
Hlavním cílem útočníka je získání je získání citlivých údajů ze zpráv nebo z backendu systému.
Jde o tyto útoky



Message tampering/alternation – modifikace odchytnutých zpráv a zaslání na server
Data tampering – útočník hledá chyby při řízení přístupu ke službě, aby mohl získat přístup
Message snooping – útočník odposlouchává privátní data, ochranou je šifrování
3.3.4 Kompromitování celého systému
Do této kategorie patří útoky s velkým dosahem. Jedná se o útoky:

Malicious include – útočník zasílá speciální zprávy, která přinutí, vrátí i jiná data (např. soubor s
hesly), může se jednat např. vložení embed elementu odkazující na konkrétní soubor do XML
zprávy

Memory space breach – útok probíhá na operační paměť serveru přes přetečení zásobníku,
(vyčerpání bufferů nebo vyčerpání heap pamětí), pokud toto nastane útočník je schopen spustit
svůj kód

XML encapsulation – útok přes zapouzdření systémových příkazů v XML s využitím CDDATA

XML virus – útočník využívá přenos binárních dokumentů a společně se zprávou zasílá viry nebo
červy, ochranou je využití antivirového programu
3.3.5 Bezpečnostní opatření
Ačkoliv si to většina lidí neuvědomuje, problematika bezpečnosti SOA je důležitá, protože existují cesty
jak ohrozit systém. Aby se těmto útokům předcházelo, uvádíme níže možné cesty jak předejít možným
problémů.
Základní validace zpráv – každá přijatá zpráva musí být zkontrolována, zda obsahuje správnou velikost,
názvy elementů a atributů. Pokud nepracuje s přílohami je nutné je ihned odstranit
1. Základní validace zpráv – každá přijatá zpráva musí být zkontrolována, zda obsahuje správnou
velikost, názvy elementů a atributů. Pokud nepracuje s přílohami je nutné okamžité odstranění.
14
2.
3.
4.
5.
6.
Validace XML zpráv oproti XML schématu.
Používání digitálního podpisu pro ochranu datové integrity.
Použití šifrování pro ochranu soukromých dat.
Řízení přístupu ke službám – autentizace, autorizace a audit.
Monitorování transakcí a upozornění na nestandardní chování (dlouhá doba odezvy, počet
dotazů).
Obr. 8: Validace zpráv XML schématu pro zvýšení bezpečnosti webových služeb *MELICHNA, 2008]
15
4. SOA a další oblasti
V předchozích kapitolách jsme se dozvěděli o významu servisně orientované architektury a o technické
podstatě této architektury. Nyní se zaměříme na interakci SOA s dalšími architekturami, stručně
nastíníme problematiku řízení služby v SOA v průběhu jejího celého životního cyklu a na závěr se
zaměříme na vznik a vývoj servisně orientovaných architektur.
4.1 SOA a EDA
Většina dodavatelů servisně orientované architektury (SOA) poskytují své integrační softwary se sběrnicí
služeb neboli s ESB. Detailní popis jednotlivých typů sběrnice ESB a její účel je popsán v semestrální práci
ze LS 2009/2010.
Jednou z aplikací, která je tzv. "nasazena" na sběrnici ESB je aplikace zaměřená na zpracování událostí.
Dnešní business v celosvětovém měřítku potřebuje využívat aplikace a technologie, které pracují v
reálném čase, neboť procesy v daném podniku probíhají v reálném čase a je potřeba reagovat na
události také v reálném čase. Např. eBay provozuje celosvětové tržiště okamžitě dostupné pro kohokoli.
Ovšem samotná architektura SOA zpracovává data staticky, proto nelze získávat data a reakce na procesy
ve správném čase, ale s časovým zpožděním.
Okamžitost je právě výsadou Event drive architecture (dále jen EDA), která je jednou ze skládaček v SOA.
EDA umí realizovat podnikové operace v reálném čase a mění efektivnost SOA, neboť bez EDA by SOA
nedokázala poskytovat okamžité podnikové zpravodajství. Architektura řízená událostmi (ve zkratce EDA)
poskytuje reálné informace, které se praktikují v podniku k okamžité reakci na otázky a určitě situace.
Příklady využití EDA uvádí společnost Progress ve svém odborném článku:



„Kolik plazmových televizorů máme právě teď na skladě, kolik jich bylo objednáno, jaká je naše
míra prodeje a jak si právě teď vedeme ve srovnání s naší obchodní předpovědí?“
„Je v dráze tohoto letu během deseti minut hlášená předpověď špatného počasí? Pokud ano,
odkloňte letadlo, zjistěte, kteří pasažéři budou zpožděním dotčeni, překnihujte tyto pasažéry,
aktualizujte informace na našich přepážkách a u všech agentů na letištních bránách ve všech
lokalitách a v reálném čase aktualizujte náš poměr zisku a ztrátovosti.“
„Pokud se během posledních pěti sekund objevily transakce u této kreditní karty z různých
podniků v různých místech, odmítněte poslední žádost a vydejte upozornění o detekci možného
podvodu u daného účtu.“
„Takové situace nemohou vyřešit jen krásné oči odpovědné pracovnice. Efektivní EDA potřebuje solidní
novou formu výpočetního prostředí – výpočetní zpracování toků dat.“ [Palmer, 2007]
Aplikace pracující v reálném čase využívají dynamické zpracování dat, které se od statického modelu liší
především tím, že poskytuje okamžité a inteligentní rozhodnutí v reálném čase postavené na vzorcích
byznys operací. Tento rozdíl je zachycen v ilustračním obr. č. 9.
16
Obr. č. 9: Rozdíl mezi statickým a dynamickým zpracováním dat, Zdroj: [Palmer, 2007]
Existují 3 obecné styly zpracování událost, které jsou společně používány v architektuře řízené
událostmi. Jedná se o:



Jednoduché zpracování událostí. Tento jednoduchý styl se zabývá událostmi, které přímo souvisí
s konkrétní a měřitelnou změnou stavu. V tomto stylu se vyskytuje tzv. pozoruhodná událost,
která iniciuje následné akce. Tento styl zpracování události se typicky využívá jako prostředek pro
řízení pracovních toků v reálném čase a jeho výhodou je účinné snížení nákladů a prodlevy.
Stream – zpracování událostí. V tomto stylu dochází ke zpracování obyčejných i pozoruhodných
událostí.
Komplexní zpracování událostí. Tento komplexní styl zpracování událostí se zabývá vzory
obyčejných i jednoduchých událostí a má tendenci hodnotit toky akcí až do přijetí opatření.
Komplexní zpracování událostí vyžaduje zaměstnávání kvalifikovaných tlumočníků akce, akce
vzorů a definice, stejně jako korelační techniky. Komplexní zpracování událostí je typicky
využívány jako prostředek pro detekci a reakci na anomálie, hrozeb a příležitostí v
podnikatelském prostředí.
Obě architektury (SOA a EDA) se vzájemně doplňují. Nelze tedy tvrdit, že EDA je podmnožinou SOA, ale
tato kombinace architektur může dle názoru odborníků tvořit základ nových inteligentních systémů. Na
kombinaci SOA a EDA lze nahlížet ve dvou následujících interakcích:

Event-driven SOA. V této první interakci dochází k výskytu události, která může vyvolat jednu
nebo více služeb. Tyto služby mohou potom vykonávat jednoduché funkce nebo celé obchodní
procesy, proto se tato interakci mezi událostmi a službami označuje jako event-driven SOA.

Služby jako generátor události. V této druhé interakci může služba generovat událost nebo
případně může znamenat problém či hrozící problém, příležitost nebo odchylku. Po generování je
událost okamžitě předávána všem zainteresovaným stranám, které hodnotí události a případně
přijmou opatření. Tyto opatření většinou zahrnují vyvolání služby, spuštění obchodního procesu
17
nebo zveřejnění dalších informací. Služba je v této interakci pouze jedním z mnoha zdrojů
události.
V předchozím odstavci jsme kladli důraz na to, že obě architektury se vzájemně doplňují, nikoliv
nenahrazují. Nyní si stručně shrneme základní vlastnosti obou architektur, které nám utvrzují, že obě
architektury jsou odlišné. Přehled základních vlastností je zobrazen v tabulce č. 1.
EDA
SOA
Oddělené interakce
Volně spojené interakce
One-to-one "komunikace
Many-to-many komunikace
Publikování / Odebírat zprávy, kde jedna konkrétní
událost může mít vliv na mnoho předplatitelů.
Událost zahajuje komunikaci
Tok ovládání, které je určeno příjemcem, na základě
vyslaných události.
Asynchronní operace
Jedna konkrétní služba je použita pro jednoho
spotřebitele najednou. Komunikace jsou
obousměrné
Klient (spotřebitel) zahajuje komunikaci
Tok řízení je z podnětu klienta (služba spotřebitele).
Synchronní operace
Tabulka č. 1: Základní vlastnosti architektur
Základní rozdíl mezi těmito architekturami je především v tom, že architektura SOA je založená na
mechanismu dotaz/odpověď. Oproti tomu v architektuře EDA je komunikace zahájena určitou událostí.
[IBM, 2011]
Architektura SOA řízená události (tedy doplněná a rozšířená o EDA) je velmi důležitým krokem při rozvoji
SOA, neboť v rámci podnikových procesů se vyskytují různé události, které vyvolávají jednu nebo více
služeb, které mohou vykonávat jednoduché funkce nebo celopodnikové procesy. Jedním z dalších
důvodů tohoto rozšíření je potřeba reagovat na provozní procesy v reálném čase, potřeba dnešního
konkurenčního boje podniků mít vše ve „správný“ čas a dřív než konkurence.
Pokud chceme dostatečné komplexní integrační řešení, je vhodné implementovat a využívat obě
architektury. Některé komunikace budou probíhat SOA cestou a další komunikace bude realizována
způsobem EDA. Většina odborníků říká, že i když obě architektury jsou odlišné pojmy, které mají své
výhody i omezení, obě jsou kompatibilní a podnik potřebuje oba.
Problematika vztahu, propojení a rozdílnosti těchto dvou architektur by mohla být rozšířena v dalších
semestrálních pracích našich následníků.
4.2 SOA Governance
Pojem SOA Governance lze překládat jako metodika efektivního řízení a dozoru, která v sobě ukrývá
definované metody a procesy. Cíle řízení SOA Governance je plnohodnotné využití architektury SOA a
řešení vyskytnutých problémů, které by bránily realizaci a využívání architektury SOA.
18
Obsah SOA Governance definuje článek [Kasal, 2011] : „SOA Governance obsahuje postupy pro definici a
správu životního cyklu služeb. Obsahuje tzv. politiky či pravidla pro jejich technologická, bezpečnostní a
jiná omezení služeb a samozřejmě data o užití služeb (kdo je poskytovatel, kdo danou službu odebírá,
jaká jsou standardní pravidla o užití služby, v jakém životním cyklu se služby nachází, jak je řešeno
účtování, podpora, přechod na novou verzi a další).“
Tato kapitola navazuje na semestrální práci ze zimního semestru 2009 - celá práce je k dispozici na:
http://panrepa.org/CASE/zima2009/CASE_SOA_zima2009.pdf
Kolegové ve své práci definují význam a zařazení SOA Governance, popisují infrastrukturu řízení SOA a
stručně charakterizují nástroje této problematiky. Jejich teoretický úvod do oblasti SOA Governance
bychom chtěli v této kapitole rozšířit o standardy pro řízení a správu SOA.
Existují určitě standardy řízení SOA, které navrhly organizace COBIT a ITIL, avšak společnost Open Group
vytvořila na základě spolupráce s IBM tzv. SOA Governance framework, který definuje, jak by si
společnost měla zajistit správu SOA. Neboli správa SOA pomáhá organizaci, aby vytvořila správné služby,
správným způsobem, ve správný čas a řídila a vyžívala tyto služby efektivně. SOA Governance framework
se skládá z referenčního modelu (SGRM) a z vitální metody (SGVM).
a celý framework zahrnuje tři následující aspekty řízení SOA:

procesy (řídící procesy)

organizační strukturu (role a odpovědnosti)

technologie (nástroje a infrastrukturu)
4.2.1 SOA Governance referenční model (SGRM)
Referenční model je základní SOA Governance model k urychlení přizpůsobení organizačních procesů v
SOA Governance. Model se skládá z 6 následujících oblastí:

řídící procesy SOA Governance podniku

řídící principy SOA Governance podniku

řízené procesy SOA Governance podniku

artefakty SOA Governance

role a odpovědnosti SOA Governance

technologie SOA Governance
Cílem řídících procesů SOA Governance podniku je podpora při rozhodování návrhu, nasazení a
provozování SOA Governance z různých pohledů, tj. z pohledu procesů, technologií a z pohledu
zaměstnance a jeho přidělených rolí. Principy řízení SOA Governance nejsou vždy v podniku totožné,
neboť rozhodujícím faktorem při výběrů těchto principů jsou potřeby konkrétního podniku. *Karkošková,
2010].
19
Existují tři hlavní řídící procesy:
1. Řízení shody (compliance). Úkolem tohoto řídícího proces je zajištění shody mezi SOA procesem
a SOA politikou, pravidly a standardy. Řízení shody tak umožňuje nastavit vhodný mechanismus,
který umí utvrdit shodu nebo prokázat, neshodu v určité části SOA procesu.
2. Řízení výjimek (dispensation). Úkolem tohoto procesu je správné vyhodnocení jednotlivých
typů výjimek. Proces řízení výjimek v určitých případech umožňuje zpracovat detekovanou
výjimku*1+ a stanovuje omezenou dobu akceptování této výjimky, případně zamítnutí této
výjimky.
3. Řízení komunikace (communication). Úkolem tohoto procesu přestavení a školení relevantních
zaměstnanců s problematikou řídících procesů.
Úkolem řízených procesů SOA Governance je zachycení aktivit, které souvisejí s životním cyklem řešení
(neboli jednotlivé služby), ve fázi životního cyklu plánování, vývoje, testování a provozu. K
nejvyužívanějším řízeným procesům patří:

Správa portfolia SOA řešení. Tento proces zajišťuje, že vybrané SOA řešení podporuje potřeby
obchodního procesu. Zároveň tento proces musí umět najít a detekovat případy, kdy dané řešení
již není v souladu s danými potřebami obchodních procesů podniku.

Správa portfolia služeb. Úkolem tohoto procesu je zajištění optimálních služeb, které realizují
podporu jednotlivým potřebám podnikových obchodních procesů, tzn. mít správnou službu ve
správný čas.

Řízení životního cyklu SOA řešení. Cílem tohoto procesu je monitorování a řízení fáze vývoje,
testování provozu SOA řešení.

Řízení životního cyklu služeb. Tento proces je rozšířením řízení životního cyklu softwaru v
podniku o určité specifické aktivity pro služby. Zahrnuje např. proces definice služby, modelování
služby atd.
Artefatky SOA Governance obsahují dokumentaci systému řízení a jsou základem pro realizaci řídících
procesů v podnikové praxi. Nejvyšším dokumentem je určitá deklarace vedení podniku, které popisuje
odpovědi na otázky Proč zavést do podniku vybrané způsoby systému řízení? Proč podnik potřebuje SOA
pro další fungování a rozvoj podniku.
Role a odpovědnosti SOA Governance jsou v každém podniku odlišné, proto jejich podoba není
definována jednotným předpisem. Avšak definování jednotlivých rolí a odpovědností potřebných pro
SOA Governance by mělo být součástí modelu řízení SOA. [OpenGroup1,2011]
4.2.2 SOA Governance Vitální metoda (SGVM)
Vitální metoda je nepřetržitý proces, který používá Referenční model jako základ pro zdokonalování SOA
architektury podniku v rámci fází, které znázorňuje obr. č. 10. Každá fáze SGVM musí nahlížet na SOA
Governance jako na neustále se zlepšování smyčce a vnímat pokroky, opravy a aktualizace.
20
Obr. 10: Fáze Vitální metody SOA Governance, Zdroj: [OpenGroup2,2011]
1. Fáze PLÁNOVÁNÍ, která identifikuje a analyzuje hlavní oblasti pro zlepšení SOA Governance.
2. Fáze DEFINOVÁNÍ má za úkol definování plánů a kroků na postupný přechod na nový
změněný SOA Governance proces.
3. Fáze IMPLEMENTACE se stará o provedení plánů přechodů včetně zavádění procesů,
organizace a technologických aspektů SOA Governance modelu.
4. Fáze MONITOROVÁNÍ zahrnuje metody sběru dat o efektivnosti změněného procesu, a tím
poskytuje vstupní data pro další fázi plánování.
Řízení a správa SOA zahrnuje v sobě řadu pravidel i postupů aplikovaných na služby, proto lze tuto
problematiku dále rozšiřovat v některé následující týmové práci. [OpenGroup2,2011]
21
5. Význam jazyka BPEL v SOA
Servisně orientovaná architektura má řadu podmínek, které jsou popsány v kapitole č. 2 abychom tyto
podmínky naplnili je nutné skládat jednotlivé služby do business procesů. Tyto procesy jsou definovány
jako sada aktivit, přes které služba přechází. Oblastí business procesů se zabývá Business Process
Modeling (BPM), která je detailněji popsána v kapitole č. 6. V této kapitole si přiblížíme jeden z
nejrozšířenějších jazyků BPM, tedy jazyk BPEL a také vymezíme vztah tohoto jazyk k servisně orientované
architektuře. V poslední podkapitole budou charakterizovány vybrané nástroje pro správu BPEL procesů.
5.1 BPEL
Jazyk BPEL slouží pro zápis business procesů a je založený na XML a díky tomu využívá několik dalších
standardů (tj. WSDL, XML Schéma, XPath a XSLT). Pomocí tohoto jazyka můžeme definovat jednoduché i
velmi složité procesy, neboť obsahuje podobně jako tradiční programovací jazyky různé smyčky, větvení,
proměnné atd. Důležitou vlastností je spojení s tohoto jazyka s voláním webových služeb.
„Business Process Execution Language (BPEL) se stal v posledních dvou letech významným standardem,
vyzdvihujícím využití SOA z IT úrovně na business úroveň. Umožňuje organizacím spouštění a
automatizování jejich business procesů, prostřednictvím orchestrace služeb uvnitř i vně dané organizace.
Vyvinut firmami Microsoft a IBM, standardizován neprofitujícím konsorciem OASIS (Organization for the
Advancement of Structured Information Standards). Tento jazyk umožňuje specifikovat jak spustitelné,
tak abstraktní procesy.“ *Maršík, 2008]
Základní podoba jazyka BPEL je textová, avšak s grafickým vyjádřením se můžeme setkat u nástrojů pro
implementaci procesů pomocí tohoto jazyky. Je nutno podotknout, že jazyk BPEL souvisí se službami,
BPM a s architekturou orientovanou na služby. Pomocí jazyka BPEL můžeme *Zdroj+:

popisovat business procesy pomocí skládání služeb

skládat větší procesy ze služeb a již vytvořených procesů

pracovat se synchronními a asynchronními operacemi a přijímat tzv. callbacks

spouštět služby sekvenčně či paralelně

kompenzovat služby v případě chyby

přesměrovat příchozí zprávu patřičnému procesu

pracovat s událostmi

spouštět aktivity v určitém pořadí či za určitý čas

strukturovat business procesy
Proces v jazyce BPEL je složen z jednotlivých základních či složených aktivit. Komunikace v rámci procesu
probíhá tak, že BPEL proces obdrží požadavek, na základě tohoto požadavku spustí dané webové služby a
na závěr odešle odpověď původnímu volajícímu. [BPEL,2011]
22
5.2. Role jazyka BPEL v SOA
BPEL (Business Process Execution Language) se stala jednou z nejvýznamnějších technologií SOA (ServiceOriented Architecture) a umožňuje snadnou a flexibilní složení služeb do obchodních procesů. Využití
jazyka BPEL v SOA umožňuje rozvíjet procesy a rychle definovat pořadí služeb. Servisně orientovaný
přístup pro efektivní automatizaci podnikových procesů vyžaduje splnění všech tří následujících
požadavků:
1.
Standardizovaný způsob přístupu k funkčnosti aplikací jako služby
2.
Infrastruktura pro komunikaci a řízení služeb (včetně zpráv, směrování, transformace
atd.)
3.
Specializovaný jazyk pro složení funkcí aplikací do podnikových procesů
První požadavek je splněn současnou distribuovanou architekturou webové služby. Druhý požadavek je
splněn díky ESB, který zahrnuje podporu pro centralizované, deklarativní a koordinované řízení služeb a
jejich komunikace. Třetí požadavek je splněn jazykem BPEL.
Jazyk BPEL a orchestrace umožňují servisně orientované architektuře pružně reagovat na změny v
procesech.
Role jazyka v BPEL v SOA je taková, že tento jazyk umožňuje v SOA organizovat existující služby do
větších bloků a vytvářet choreografie služeb. Zároveň BPEL nabízí prostředky pro sériové a paralelní
provádění jednotlivých služeb, které podporuje větvení závislé na obsahu zpráv. [Šafář, 2007]
5.3. Vybrané nástroje pro správu BPEL procesů
5.3.1.
Oracle BPA Suite a SOA Suite
Nástroje společnosti Oracle pokrývají celý životní cyklus business procesů. Především díky spolupráci s
firmou IDS Scheer poskytuje Oracle komplexní sadu integrovaných produktu pro návrh, modelování,
simulaci a optimalizaci obchodních procesů s cílem dosažení maximální efektivity provozu. Sada Oracle
BPA Suite obsahuje modelovací nástroj Business Process Architect, který slouží pro modelování
podnikových procesů v notaci BPMN a garantuje také bezztrátový převod této notace do jazyka BPEL.
Dalším nástrojem, který je v sadě nabízen je portálové řešení Business Proces Publisher a Business Proces
Server, který umožňuje souběžný přístup k modelům a jejich artefaktům a slouží také pro ukládání
modelů. [Černý, 2010]
Nástroje pro modelování BPEL procesů jsou obsaženy v sadě SOA Suite. Tato sada však neobsahuje
pouze nástroj modelování, ale zahrnuje také kompilaci, spuštění a nástroje pro propojení BPEL procesů s
webovými službami. Konkrétním produktem sady SOA Suite, který se zabývá popsanou problematikou
BPEL procesů je produkt BPEL Process Manager. Mezi hlavní složky BPEL Process Managera patří (dle
obrázku č. 11) BPEL Server, BPEL Console, BPEL Designer (Eclipse nebo JDeveloper) sloužící ke grafickému
vyjádření a databáze.
23
Obr. č. 11: Architekturu Oracle BPEL Process Managera, Zdroj: [DC Design, 2010]
5.3.2. IBM WebSphere BPM Suite
Společnost IBM dle svých webových stránek „pomáhá organizacím optimalizovat výkonnost podniku díky
objevování, dokumentování, automatizování a neustálému zlepšování podnikových procesů pro zvýšení
efektivity a snížení nákladů.“
Obr. č. 12: BPM společnosti IBM, Zdroj: [IBM WebSphere, 2010]
24
Business proces management je jednou ze součástí jádra řešení WebSphere9. Toto řešení obsahuje
komplexní sadu funkcí pro podnikové procesy s názvem IBM BPM Suite. Komplexnost dané sady je dána
obsahující produkty, jejichž přehled je k dispozici v tabulce č. 2. Jedná se především o produkty k
modelaci, simulaci, realizaci, ke sledování a optimalizaci klíčových procesů. Klíčovým nástrojem dané
sady pro oblast BPEL je produkt WebSphere Business Modeler, který umožňuje modelovat návrh
business procesů v BPMN a realizuje přechod z BPMN do obchodního modelování v jazyce BPEL.
Název produktu
FileNet Active Content Edition
Stručný popis
Automatizuje a optimalizuje obchodní procesy správou sledu
prací v součinnosti osob a systémů
WebSphere Business Events
Komplexní systém BEP (Business Event Processing) pro
zpracování podnikových událostí. Pomáhá podnikům
rozpoznávat, vyhodnocovat a řešit podnikové události metodou
zjišťování typických struktur událostí, na které lze reagovat.
WebSphere Business Modeler
Pomáhá kompletně vizualizovat, zpřehledňovat a dokumentovat
podnikové procesy.
WebSphere Business Monitor
V reálném čase zajišťuje obchodní monitorování zahrnující
metriky, vizuální zobrazení a výstrah.
WebSphere Business Services
Fabric
Jedná se o platformu, která slouží k tvorbě a správě
modulárních, dynamicky sestavených a rozšiřitelných
podnikových procesů.
WebSphere Dynamic Process
Edition
Jde o komplexní základ pro implementaci dynamických
podnikových procesů v reakci na měnící se potřeby společnosti.
Umožňuje rychlou reakci na požadavky trhu změnami
podnikového procesu.
WebSphere Integration
Developer
Prostředí pro komplexní integraci v architektuře SOA.
WebSphere Process Server
Výkonný systém pro automatizaci obchodních procesů, který
pomáhá utvářet procesy, jež splní vaše obchodní cíle.
WebSphere Sensor Events
Zajišťuje middlewarovou infrastrukturu pro tvorbu a správu
senzorových řešení podnikové třídy.
Tabulka č. 2: Přehled produktů v rámci sady IBM BPM Suit, Zdroj: [IBM WebSphere, 2010]
5.3.3. jBoss Community – jBPM a RiftSaw
jBPM je jedno z řešení pro Business Process Management. Jádrem jBPM je workflow, které umožňuje
provádět obchodní procesy s využitím BPMN a spouštět je v prostředí Java. Nad jádrem jBPM je mnoho
dalších funkcí a nástrojů, které slouží k podpoře obchodní procesů po celou dobu jejího životního cyklu.
9
IBM WebSphere je software pro prostředí SOA, který umožňuje dynamické, vzájemně propojených podnikových
procesů, a poskytuje vysoce efektivní aplikační infrastruktury pro všechny obchodní situace
25
Patří tam např. konzole pro správu podpůrných procesů, Eclipse jako on-line editor pro podporu
grafického vyjádření vytvořených obchodních procesů. jBPM pokrývá komplexní obchodní logiku, kterou
lze modelovat jako kombinaci obchodních procesů s obchodními pravidly a komplexním zpracováním
událostí. [Černý, 2011]
JBoss jBPM je open source (LGPL licence) v rámci Java API, nástroje a definice jazyka, který může
fungovat jako webové aplikace nebo samostatná aplikace Java (případně jako plug-in do Eclipse). jBPM
se skládá z několika component, jejichž vztah znázorňuje obr. č. 13. Jádro jBPM včetně BMP funkčnosti je
celé zabalené v jedné knihově, která obsahuje i služby pro řízení a spuštění procesů v jPDL databází.
.
Obr. č. 13: Vztahy mezi komponentami v JBOSS jBPM, Zdroj: [Javaworld, 2006]
Modelování procesů v jazyce BPEL není v komponentách jBPM zastoupeno, a tak společnost JBoss
vyvinula projekt RiftSaw, který je implementací BPEL engine a doplňujících nástrojů. Projekt RiftSaw je
zaloţen na dalším open-source produktu od Apache Software Foundation – Apache ODE. Projekt
obsahuje následující moduly:



BPEL process deployer.
Eclipse plug-in jakou součást JBoss Tools.
Konzoli pro management a monitoring.
26
6. Spojení přístupu SOA a BPM
V této kapitole uvádíme, které znaky jsou pro přístupy SOA a BPM společné. Čtenář by se z této kapitoly
měl dozvědět, proč by se daly tyto přístupy spojit.
6.1 Srovnání SOA a BPM
BPM byl módě hlavně v 90. letech, uvažujme metodu BPR (Business Process Reingeneering). Celý přístup
BPM je převážně o objevování procesů ve firmě, zlepšování a automatizace procesů. BPM má za úkol
snížit chyby lidského faktoru a snížit náklady ve firmě. V BPM se používá jazyk BPEL, který slouží pro
popis business procesů. Existují zde i modely jako je například model Six Sigma, který pomáhá v
hodnocení vyspělosti procesů s cílem snížit procento chyb ve výrobním prostředí. Obchodní procesy jsou
součástí obchodní vrstvy v EA architektuře. Procesy jsou stále abstraktní v tom, že musí být ještě
prováděny lidmi nebo stroji. BPM nemá jednoznačnou definici, zahrnuje v sobě vše, co se snaží přispět ke
zlepšení podnikových procesů.
Na druhé straně máme SOA. Taktéž stejně jako BPM, používá jazyk BPEL. SOA je obchodní
architektonický styl, který pochází z objektově orientovaných technologií a webových služeb. Stejně jako
v BPM tu máme charakteristickou vlastnost, kterou je snížení nákladů na vývoj a integraci. Mezi další
prvky patří snadná rozšiřitelnost a udržovatelnost, znovu-použitelnost komponent/služeb, integrace
zastaralých aplikací, zjednodušení, zprávy a řízení informačních systémů a just-in-time řízení. SOA je o
poskytování dat a jejich zpracování, zapouzdřené a přístupné pouze prostřednictvím zveřejněného
rozhraní. Na rozdíl od OO se zabývá vývojem SW komunity. V architektuře SOA se obchodní pracovní
postupy skládají ze služeb SOA, které zapouzdřují jak proces, tak technologie provádění. SOA je
technologie, která se řadí typově mezi ESB (Enterprise Service Bus).
Obr. č. 14: ESB – EnterpriseServiceBus, Zdroj: [WSO2]
27
Servisně orientovaná architektura (SOA) tedy umožňuje sestavit z dostupných služeb optimální proces.
Tím celému BPM poskytuje potřebnou infrastrukturu pro flexibilní design procesů při maximálním
znovupoužití již existujících služeb.
Architektura orientovaná na služby (SOA) zprostředkovává přístup k určitým aplikacím. BPM ji pak
využívá k získávání informací z těchto aplikací. Ty posléze zahrnuje do vylepšeného procesu.
Představíme-li si SOA jako asfaltovou cestu k informacím, je BPM vozidlem, které dokáže naplno využít
jejích služeb, a zefektivnit tak celkovou infrastrukturu. Pokud se používá SOA jako integrační strategie pro
BPM, jsou obchodně kritické procesy závislé právě na jejich službách. A pokud tyto služby selžou, pak se
samozřejmě zhroutí i procesy na nich postavené spravované BPM. Proto existuje trend, který se snaží o
zajištění kontroly na kvalitě veškerých služeb.


SOA: Zprostředkovává přístup k určitým aplikacím BPM
BPM: BPM využívá přístup k získávání informací z aplikací
Když se budeme snažit shrnout podobnosti mezi BPM a SOA, dostaneme tyto body:





Podpora znovu-použitelnosti,
přizpůsobivost dynamickým změnám,
oba přístupy jsou opakující se proces,
podpora volně vázaných služeb,
oba se zabývají distribuovaným prostředím.
Na závěr této kapitoly můžeme říci, že SOA a BPM jsou dva rozdílné pohledy na stejnou věc. BPM je tzv.
pohledem shora, tento pohled vznikal hlavně mezi lidmi, kteří rozumí obchodu jako takovému. Mluvíme
tedy o manažerech, business analyticích a o odbornících, kteří modelují podnikové procesy. Je nutno
dodat, že tyto lidi nemají znalosti a schopnosti, které by jim umožňovali implementovat a spouštět
podnikové procesy nebo implementovat jednotlivé služby.
Naopak je tomu u SOA architektury. O SOA mluvíme jako o pohledu na podnikové procesy skrze
informační technologie nebo také o tzv. pohled zespodu. Tímto pohledem se již nezabývají manažeři, ale
IT odborníci, kteří jsou schopní definovat podnikové procesy (například v jazyce BPEL) a schopní
implementovat služby. Na druhou stranu, se ve většině případů nevyznají v modelovém businessu. [Basl,
2008]
Mezi pohledem zespod (SOA) a pohledem shora (BPM) vzniká problém propojení, tzv. business-IT
mezera (business - IT gap). Při převodu procesních modelů do spustitelné podoby se musí využít člověk,
který umí business model na model stejný, který je možné spustit i obráceně. Při automatizaci tohoto
převodu dochází k problémům. Něco k tomuto si řekneme v dalších kapitolách.
28
Obr. č. 15: Vazby mezi SOA a BPM, Zdroj: *BPM téma, 2007+
Obr. č. 16: Schéma propojení BPM a SOA, Zdroj: *BPM téma, 2007+
6.2 Překážky propojení
V předchozí kapitole jsme si řekli o srovnání přístupu SOA a BPM. V této kapitole budeme mluvit o
překážkách, které brání spojení BPM a SOA.
Největší výzvou propojení SOA a BPM je správné mapování služeb na business procesy. Jedná se tedy
spíše o rozeznání služeb tak, aby v budoucnu bylo možné jejich znovu-použití. Business proces je totiž 29
definovaný, po průchodu BPM cyklem, také zoptimalizovaný. Musíme tedy i podle toho navrhnout
služby, které by nekolidovaly s jednotlivými aktivitami business procesu.
29
„Z pohledu businessu nezáleží na tom, zda jsou to služby jednoduché či složené. Důležité je, že
reprezentují procesní aktivitu.“ [Kianička, 2008]
Když mluvíme o správné identifikaci v souvislosti se znovu-použitelností, bavíme se o tzv. granularitě
služeb. Obvykle se stává, že služby nejsou navrhnuty kvalitně z hlediska granularity a nejsou vhodné pro
jejich další zacházení s nimi. Musí se poté následně upravovat, což vyžaduje další náklady. V dnešní době
se všechny podniky snaží snižovat své náklady na minimum. Vždy, když se připravuje něco dlouhodobě
použitelného, je nezbytně nutné neodbít začátek a klást důraz na kvalitní zpracování samotného návrhu.
Řešením tohoto výše popisovaného problému je propojení SOA a BPM, od začátku a systematicky.
Samozřejmě už byly vymyšleny různé metodiky, jak navrhovat služby tak, aby byly navrženy dle
požadavku podnikových procesů. Nikdy však není u těchto metod garantována znovu-použitelnost.
Žádná takováto metoda zatím nebyla vytvořena. K integraci BPM a SOA musí být BPM systematicky
propojený se SOA, této integrace dosáhneme integrovanými metodami softwarového inženýrství.
Navzdory výše zmiňovaným problémům a rozdílům, je implementace BPM v SOA velmi účinným
nástrojem k vypořádání se s výzvami, které přináší měnící se podnikové prostředí a potřeba snižovat
náklady při současném zvyšování efektivity. SOA usnadňuje rozšíření BPM, pomáhá mu dosahovat
flexibility pomocí loose coupling infrastruktury. Potom mohou být procesy modelované BPM nástroji
snadno a rychle implementovány architekturou SOA. Na druhé straně BPM poskytuje SOA silné obchodní
případy a usnadňuje bližší spojení mezi podnikem a IT. Když kombinujeme tyto dva přístupy dohromady,
BPM a SOA požadují, aby podnik implementoval podnikové procesy jako služby a BPM nástroje jako
servisně orientované aplikace. Tyto BPM nástroje budou poskytovat výstupy v podobě servisně
orientovaných aplikací. [Kianička, 2008]
6.3 Přínosy propojení
Jeden z největších přínosů SOA je ten, že umožňuje nahrazení funkcí, které jsou nyní vykonávány interně
službami, které jsou vykonávány obchodními partnery. Jako jeden z dalších přínosů je často uváděné
samozřejmě snížení nákladů, jelikož to přináší obě metody i samostatně. Propojení SOA a BPM přináší
snížení provozních nákladů a nákladů na údržbu a vývoj. Jejich spojení může dále zvýšit rychlost vývoje a
optimalizaci podnikových procesů a celkovou efektivitu podniku. Dále by spojení mohlo přinášet
komplexnost, pokud se procesní model nedegraduje na základě kladení důrazu na znovu-použitelnost. V
neposlední řadě přináší součinnost BPM a SOA možnost podniku dynamicky reagovat na změny a být
flexibilní.
Přínosy, kterých můžeme dosáhnout, pokud implementujeme zároveň BPM a SOA jsou následující. Jako
první je samozřejmě snížení nákladů, jelikož to přináší obě metody i samostatně. Propojení SOA a BPM
přináší snížení provozních nákladů a nákladů na údržbu a vývoj. Jejich spojení může dále zvýšit rychlost
vývoje a optimalizaci podnikových procesů a celkovou efektivitu podniku. Dále by spojení mohlo přinášet
komplexnost, pokud se procesní model nedegraduje na základě kladení důrazu na znovu-použitelnost. V
neposlední řadě přináší součinnost BPM a SOA možnost podniku dynamicky reagovat na změny a být
flexibilní. Objevují se jisté tendence k prosazení spojení mezi SOA a BPM. Jsou jimi např.: různé snahy o
definování kompletní metodiky k přístupu řešení pomocí BPM a SOA dohromady nebo vznik nové
iniciativy pod záštitou skupiny BEI (Business Ecology Initiative). *Pršala, 2009]
30
6.4 SOA a BPM v IBM
Společnost IBM již pomohla mnoha tisícům klientů z celé řady průmyslových odvětví úspěšně zlepšovat
své cíle ve zlepšování procesů. IBM pomáhá zmapovat přesně procesy ve firmě, aniž by to nijak ohrozilo
rozpočet klientské firmy. IBM k tomuto využívá právě SOA a BPM.
6.4.1 Tvorba robustní infrastruktury pro SOA a BPM
Společnost IBM má mnohaleté zkušenosti s disciplínou BPM. IBM nabízí velké množství nástrojů, které
podporují celý proces vývoje řešení od analýzy až po implementace řešení.
Obchodní řešení jsou rozdělena na tři prvky:



Lidé,
Procesy,
informace.
Lidé se podílejí na řízení procesu, poskytování informací, provádění jednotlivých úkolů v rámci procesu
nebo využívají výsledků. Samotný proces je obecně definován jako popis posloupnosti činností, spolu s
klíčovými metrikami a obchodními předpoklady. Tyto činnosti mohou představovat jakékoliv množství
úkolů, automatizovaných postupů nebo dokonce funkcí, které plní jiné fyzické stroje. Použití techniky
SOA, ve snaze zajistit pružnost těchto systémů, pomáhá podniku rychle reagovat na změny na trhu,
využít obchodní příležitosti a zavádět nové produkty. Udržení robustnosti a celistvosti business procesů
nebylo nikdy důležitější, než je dnes. Vývojáři aplikací jsou, při použití BPM a SOA techniky, stále
zodpovědní za správné uplatnění obchodní logiky jejich procesů. BPM a SOA využívají middleware a
infrastruktury, které poskytují transakční sílu. Sada middlewarových produktů od IBM umožňuje šíření
moderních procesů automatizace. WebSphere Portal Server, Lotus Forms, Expeditor a související výrobky
můžou hostit interakce služeb našich aplikací. S pomocí WebSphere Process Serveru spravují procesní
toky, lidská správa úloh, pravidla a integrace požadavků obchodních procesů. InfoSphere Information
Server ™ a související Master Data Management zpracovávají informace, očišťují a transformují potřeby.
A WebSphere Enterprise Service Bus, WebSphere MessageBroker a WebSphere DataPower zařízení,
spolu s WebSphere Service Registry a Repository, WebSphereBusiness Events a Tivoli Composite
Application Manager, je určen pro správu připojení a zpracování událostí s požadavky na zajištění silného
soudržnost v kompozitních aplikacích. Je jasné, že „Service oriented architecture“ (SOA) a „Business
proces management (BPM) jsou synergické. BPM nám poskytuje nástroje a techniky pro pochopení
našich obchodních procesů, využití podnikových zdrojů, automatizace těchto procesů zvyšuje efektivitu.
Spojení BPM a SOA zvyšuje pružnost podnikání. Oddělení logiky procesů a logiky služeb zvyšuje
soudržnost a tolerance ke změnám na úrovni systému. *Adam, 2008]
6.4.2 BPM a SOA jsou přirozeně synergické
BPM je závislé na SOA. Toto tvrzení platí i naopak.
31
Obr. č. 17: Porovnání SOA a BPM, Zdroj: [Josuttis, 2007]
Z organizačního hlediska podniku se musí využít simulace a vizuální modely procesů a služeb, stejně jako
integraci BPM a SOA. Z technologického hlediska podniku musí zavést platformu, že bude stupnice s
úspěchem kombinovat BPM a SOA iniciativa, stejně jako neustále zajistit integritu a spolehlivost
podnikových procesů a služeb. Efektivně kombinuje BPM a SOA bude klíčovým rozlišujícím pro úspěšné
podniky v jejich snaze k obchodní pružnosti. A za tím účelem, IBM integrované metody, nástroje a
infrastruktura je dobrým výchozím bodem, který poskytuje solidní základ pro budoucnost. *Adam, 2008]
6.5 SOA a BPM trendem budoucnosti?
Ani jeden z přístupů nemá přesně definovaný postup. Z tohoto důvodu čelí organizace, které využili BPM
v SOA několika výzvám a případným potencionálním hrozbám (Mezi příklady největších hrozeb pro
aplikace BMP v SOA řadíme - nedostatečně výkonné procesy, nízká odezva podniku na změny, nákladné
chyby podniku, ztráta možnosti proniknout do podstaty věci atd.).
V některých elektronických zdrojích je zmiňováno o vývoji tzv. BPM další generace, které by mělo
poskytovat základ pro implementaci v rámci SOA. Z toho lze usuzovat, že trendem v budoucnosti bude
spíše vzájemné doplnění obou konceptů, což by mohlo organizacím pomoci k efektivitě a zvýšení
konkurenceschopnosti.
V roce 2010 došlo ke vzniku skupiny BPM/SOA Community of Practice (BPM/SOA CoP), kerá se zaměřuje
na optimalizaci podnikání a je složena z lidí zabývajících se praxí, poskytovatelů služeb a prodejců
technologií. Tato skupina spadá pod Business Ecology Initiative (BEI) a k jejich hlavním cílům patří *Černý,
2010]:







optimalizovat podnikání,
poskytovat vzdělání business analýzy,
designu procesů,
řízení (governance),
měření výkonnosti
implementace pro optimalizaci podnikání za pomoci kombinace BPM a SOA,
ukazovat přínosy realizace BPM a SOA dohromady,
32

pozvednout povědomí o BPM a SOA mezi IT odborníky a nakonec i poskytnou prostor pro
případové studie týkající se dohromady BPM a SOA řešení.
Vznik této skupiny bych viděl jako první signál k nové tendenci prosazování spojení mezi SOA a BPM. V
dnešní době lze charakterizovat využití Business Process Managementu v Service-Oriented Architecture
následovně: „Architektura orientovaná na služby zprostředkovává přístup k určitým aplikacím. BPM ji pak
využívá k získávání informací z těchto aplikací. Ty posléze zahrnuje do vylepšeného procesu.
Představíme-li si SOA jako asfaltovou cestu k informacím, je BPM vozidlem, které dokáže naplno využít
jejích služeb, a zefektivnit tak celkovou infrastrukturu.“ *BusinessWorld, 2008]
Sledování vývoje spojení Service Oriented Architecture a Business Process Managementu je zajímavým
tématem pro další týmy, které se budou zabývat oblastí SOA a podnikovými procesy.
33
7. Analýza trhu s CASE nástroji pro řízení
architektury SOA
V této kapitole se budeme věnovat hlavním poznatkům získaným z analýzy trhu, jež byla provedena
společností Gartner. Data, se kterými analýza pracuje, jsou aktuální k březnu roku 2009. Průzkum se
zaměřuje na dodavatele SOA governance technologií. O analyzovaném období, jímž byl uplynulý rok,
zpráva hovoří jako o bouřlivém a to z těchto důvodů. *CNET, 2011+ Došlo k mnoha akvizicím, spojením a
příchodu nových hráčů na trh. Následující obrázek zachycuje situaci na trhu znázorněnou ve známých 4
kvadrantovém rozložení.
Oproti stavu z minulého roku můžeme zpozorovat zajímavý jev. U většiny hráčů došlo k výraznému
posunu do samého středu pole. Tento jev signalizuje zlepšení kvality poskytovaných řešení a služeb a
ilustruje rostoucí vyspělost celkového trhu.
Obr. č. 19: Situace na trhu z března roku 2009. Zdroj: [CNET, 2011]
Hlavní zjištění uvedená ve zprávě hovoří o následujících jevech, vyskytujících se na trhu se SOA
governance nástroji.
Rostoucí procento zákazníků zahrnuje SOA governance technologie již do počátečních fází SOA projektů.
Zákazníci a dodavatelé SOA technologií začali klást mnohem větší důraz na validaci a monitoring. Dalším
34
trendem je zavádění jakostních center pro SOA samotnými zákazníky a mnohem silnější požadavky na
kompatibilitu dodávaných řešení s těmi stávajícími. Posledním důležitým zjištěním je zvýšená touha
zákazníků po aplikaci modelu Cloud.
Jak zpráva uvádí, tak toto období bylo velmi plodné na akvizice. Pro příklad uveďme největší z nich.
Jedním z nových hráčů, kteří se v přehledu oproti roku 2008 objevili, je společnost Oracle. Oracle
provedla akvizci BEA Systems a Clear App. Další provedené akvizice byly uskutečněny společností SOA
Software v podobě LogicLibrary a Progress Software s Mindreef . Tyto provedené akvizice reálně
demonstrují rostoucí si uvědomění a důraz, jež dodavatelé kladou na rostoucí potřebu pro monitoring,
validaci a management celého životního cyklu SOA governance.
Výsledky zprávy z předchozího roku hovořili o trhu se SOA governance nástroji jako o vyspělém avšak do
přehledu bylo zahrnuto mnoho dodavatelů s širokým polem nabízených nástrojů. Do současné analýzy
byli zahrnuti dodavatelé nabízející technologie s jasně danou kohezní architekturou. Druhou podmínkou
byl často skloňovaný pojem „Ease of use“ a zároveň kompatibilita s technologiemi jiných výrobců. Tento
pohled na trh respektive dodavatele nyní zahrnuje i podmínku, jíž je možnost správy SOA více osobami.
Do zobrazeného diagramu s magickými kvadranty byli v roce 2009 zahrnuti dodavatelé, kteří explicitně
dodávají SOA governance nástroje. Nejsou v něm zahrnuti ti, jež poskytují SOA testování a validaci, i když
jde o velmi podobná odvětví.
Oproti analýze z roku 2008 přibyli tito hráči: Alcatel-Lucent, Intel, MuleSorce, Oracle, Sonoa Systems.
Naopak kvadranty jsou chudší o tyto společnosti: BEA Systems, CA, Iona, LogicLibrary.
Nyní si představme hodnotící kritéria pro jednotlivé kvadranty a poté jejich vlastní definice. Gartner zde
oblast hodnotících kritérií rozděluje na 2 hlavní části. Schopnost realizace a Ucelenost vize. V první části
se setkáváme s kritérii: Produkt/Služba, Celková životaschopnost, Prodej/ Cenová kalkulace, Reakce na
změny na trhu, Marketing, Zákaznické zkušenosti, Provoz.
Druhá část uvádí tato kritéria: Schopnost porozumět trhu, Marketingová strategie, Prodejní strategie,
Strategie propagace produktu, Busines model, Obchodní strategie, Inovace, Strategie dle geografické
polohy.
Na základě ohodnocení těchto kritéríí jsou tedy jednotliví dodavatelé zařazení do následujících skupin.
Leaders – (Vůdci). Tato skupina obsahuje hráče, kterým se aktuálně na trhu daří nejlépe. Mají jasnou
představu o tom, kam trh směřuje a aktivně se snaží udržet ve výsadním postavení. Challengers –
(Vyzyvatelé). Do této skupiny jsou zařazeni dodavatelé, kterým se daří opět dobře, avšak nemají zcela
jasnou představu o budoucím směřování trhu. Můžeme zde zařadit hráče, kteří trh považují za zatím
nevyspělý či ne zcela jasně definovaný. K zásadním inovacím a proaktivnímu vývoji se mohou stavět
zdrženlivě. Visionaries – (Vizionáři) pomáhají stanovovat důležité trendy a směr jakým bude trh
směřovat. Není ale podmínkou, že jsou schopni nové trendy zcela nastolit a nové technologie či přístupy
dodat. Příkladem v nově se rozvíjejících trzích, jako je např. tento se SOA governance nástroji, mohou být
začínající společnosti menších velikostí. Niche Players (Okrajoví/Specializovaní hráči) Již podle názvu
vyplývá, že tato skupina reprezentuje všechny hráče specializující se na specifickou část trhu. Může jít o
zaměření na určitou funkcionalitu, velikost zákazníka či rozsáhlost dodávaného projektu. Jejich schopnost
realizace projektů bývá omezena na specializovanou oblast podobně jako schopnost inovací.
35
V následující tabulce jsou uvedeny nejdůležitější zjištění z provedené analýzy trhu pro každého
uvedeného dodavatele.
Dodavatel
Silné stránky
Nebezpečí
Alcatel-Lucent
Vysoké množství odborných znalostí
načerpaných z odvětví telekomunikací, jež
jsou aplikovány do prostředí SOA
Slabý marketing
AmberPoint
Ustálené tržby z přímého prodeje, vyspělé
validační a monitorovací technologie
Závislost na technologiích od
Oracle a Software AG
Fujitsu
Využití konkurenceschopné kombinace BPM
a CMDB řešení od CentraSite
Nižší popularita jména a dosažené
úspěchy než hlavní partner
CentraSite
HP
Solidní vize pro budoucí dodávané SOA
governance řešení
Slabý marketing týkající se SOA,
ovlivněný širokým spektrem
nabízených produktů a služeb
IBM
Kromě zavádění nabízí IBM se svými partnery
pomoc společnostem s kompletní IT
governance
Produkty WebSphere a WSRR
mohou fungovat pouze v IBM
prostředí
Intel
Kromě samotné technologie pro SOA
governance nabízí i zprostředkování služeb a
zabezpečení řešení
Intel se hlavně zaměřuje na
bezpečnostní politiku svých řešení
avšak opomíjí stejnou důležitost,
jíž je třeba pro marketing a
propagaci
Layer 7 Technologies
Aktivní prosazování standardů zaměřených
na interoperabilitu produktu s cizími
dodavateli
Konflikty cílů marketingové
strategie a prodejní strategií
Microsoft
Pevné vztahy s AmberPoint, SOA Software,
HP SOA Systinet
Špatná komunikace s trhem resp.
zákazníky
MuleSource
Pragmatický přístup k dodávaným SOA
technologiím, open source alternativa
Ostatní doavatelé začínají nabízet
podobné výhody jako
propagované open source řešení
Nastel
Dodávané řešení nabízí možnosti
monitoringu, sledování a řízení prováděných
transakcí pro lepší porozumění závislostí
systému
Nespecifická marketingová a
prodejní strategie pro SOA trh
Oracle
Integrace technologií od BEA Systems a
Flashline do produktového portfolia
Zatím nepříliš rozšířené povědomí
u zákazníků o spolehlivosti
nabízených produktů
Progress Software
Rozšíření a posílení aspektů validace a
diagnostiky u nabízeného řešení akvizicí
Mindreef
Nebezpečí ztráty postavení
jednoho z primárních dodavatelů
SOA governance
36
SAP
Portfolio nabízející produkty pro zajištění
celého životního cyklu SOA, snadná integrace
v SAP prostředí
Téměř mizivý marketing zabývající
se dodáváním produktů do jiného
než SAP prostředí
Sensedia
Pevné postavení na brazilském trhu, rychlá
expanze do Severní Ameriky
Nepříznivé ekonomické podmínky
na trhu pro začínající hráče
Software AG
Zkušený management a stálé příjmy ze
současných licencí
Reálné nebezpečí provedení
špatných akvizicí
Sonoa Systems
Zprostředkování požadavků na dodání
governance technologií od společností jejich
Cloud poskytovatelům
Dochází ke zmenšování místa na
trhu pro nezávislé dodavatele
(rostoucí počet větších nezávislých
dodavatelů)
SOA Software
Silná pozice na trhu, kompletní portfolio
ověřených řešení
V některých případech zbytečně
komplexní řešení nasazované i na
menší projekty
Sun Microsystems
Distributor řešení od Layer 7
Neexistující marketing v SOA
governance oblasti
Tibco Software
Posílení vlajkového produktu ActiveMatrix o
governance technologie
Zatím malý vliv v oblastech trhu s
novými technologiemi
Vordel
Dravý a agresivní přístup při budování
partnerské základny
Nedostatečný marketing při
prosazování myšlenky
interoperability nabízeného řešení
Web Layers
Kvalitní partnerská základna v podobě IBM,
Oracle a HP
Slabá marketingová image
Tabulka č. 3: Silné stránky a nebezpečí pro jednotlivé dodavatele SOA governance nástrojů [CNET, 2011]
37
8. Charakteristika vybraných nástrojů dle analýzy
trhu
Tato kapitola obsahuje charakteristiku vybraných nástrojů od dvou společností – Microsoft a Oracle.
Nástroje byly vybrány na základě analýzy trhu. Při tvorbě obsahu týmové práce byla navržena také
společnost Progress, avšak vzhledem k časově náročnému zpracování práce byl nástroj této společnosti,
ponechám jako podmět pro příští generace. Jednotlivé podkapitoly popisují využití vybraného nástroje.
8.1 Microsoft BizTalk
Microsoft BizTalk je systém elektronického obchodování. Je používán pro integraci aplikací a styk s
obchodními partnery a zákazníky prostřednictvím Internetu. Systém BizTalk je založen na jazyce XML
(Extensible Markup Language) a na průmyslových standardech umožňujících integraci ve všech odvětvích
a mezi obchodními systémy, a to nezávisle na platformě, operačním systému a použité technologii.
Možnost elektronického obchodování a integrace aplikací
Obchodování prostřednictvím Internetu bylo dosud pro podniky velmi obtížné, neboť postrádaly
jednotný technický slovník pro popis obchodních postupů. BizTalk nabízí systém, díky němuž se značně
urychlí rozvoj elektronického obchodování, neboť takovýto slovník softwaru nabízí na všech platformách
a technologiích.
Na základě sestavení technického slovníku pro popis společných obchodních postupů v elektronickém
obchodování a v konkrétních oborech mohou díky systému BizTalk informace překračovat hranice oborů,
a firmy tak mají možnost se smysluplně spojovat se svými zákazníky a obchodními partnery
prostřednictvím Internetu. Pro elektronické obchodování to znamená, že systém BizTalk definuje
obchodní schémata pro nákupy realizované firmami, katalogy výrobků, nabídky, reklamní kampaně a
další obchodní postupy.
Díky systému BizTalk je integrace softwaru do prostředí interní technologie snazší a nákladově
efektivnější. Jelikož BizTalk je systém použitelný na všech platformách, umožňuje softwaru komunikovat
s různými společnými objektovými modely, programovacími jazyky nebo sdílenými databázovými
systémy. BizTalk umožňuje integraci softwaru tak, aby firmy byly schopny okamžitě zvýšit výkonnost
svých interních obchodních systémů a využít možností elektronického obchodování při optimálním
využití svých investic do hardwaru a softwaru.
BizTalk Server je využíván dvěma způsoby:

EAI (enterprise application integration) - spočívá v propojování aplikací v rámci jedné organizace.

B2B (business-to-business) - propojuje aplikace ve více různých organizacích.
38
Obr. č. 20: Propojení aplikací v rámci jedné organizace - EAI, Zdroj: [CHAPPELL-02, 2011]
Obrázek č. 20 ukazuje propojování aplikací v rámci jedné organizace (EAI). Aplikace pro evidenci zásob,
zjistí, že zásoby určité položky jsou příliš nízké a odešle požadavek na objednávku dalších kusů.

BizTalk Server vydá požadavek na ERP aplikaci k vystavení objednávky.

ERP aplikace vrátí zpět požadovanou objednávku.

BizTalk Server pak informuje prováděcí aplikaci, že má požadovanou položku objednat.
V tomto příkladu používá každá aplikace jiný komunikační protokol. Infrastruktura BizTalk Serveru pro
předávání zpráv musí být schopná komunikace s každou aplikací v jejím vlastním způsobu komunikace.
Příklad integrace typu B2B ukazuje obrázek č. 21. V tomto příkladu nakupující organizace (v obrázku
nahoře) používá aplikaci BizTalk Server, která spolupracuje se dvěma dodavatelskými organizacemi.
39
Obr. č. 21: Integrace typu B2B, Zdroj: [CHAPPELL-03, 2011]
8.1.1 BizTalk technologie
BizTalk je postaven na technologiích:

XML (eXtensible Markup Language) - Základním výchozím formátem BizTalku je XML.

.NET - Alternativa Microsoftu pro Javu a související technologie. Aplikace v BizTalku jsou vlastně.
NET knihovnami (assembly), takže veškeré vlastnosti. NET aplikací platí i pro ně.

Visual Studio. NET -Visual Studio je již poměrně dlouho IDE nástrojem určeným pro vývoj
Windows aplikací. VS. NET je samozřejmě jeho vylepšená obdoba zaměřená na. NET aplikace. Lze
v něj vyvíjet i BizTalk aplikace pomocí vizuálních nástrojů.

Microsoft SQL Server - BizTalk jej využívá pro uložení informací o svých aplikacích, stavu
rozpracovaných transakcí a loguje do něj jejich průběh.
8.1.2 BizTalk Server
BizTalk Server zahrnuje:

BizTalk Server Orchestration Designer: Návrhový nástroj, který umožňuje obchodním
analytikům, vývojářům a IT profesionálům spolupracovat na společné platformě.

BizTalk Editor: Vytváření a editace dokumentů XML.
40

BizTalk Mapper: Transformace dokumentu XML do XML schéma (Schémata jsou různé způsoby,
jak XML dokument může být strukturován a předřipraven v zájmu zjednodušení výměny dat).

BizTalk Messaging Manager: Umožňuje výměnu informací a aplikací s minimem programování.

BizTalk Framework: Umožňuje směrování, sledování a analýzu přijatých a odeslaných dat.

BizTalk Administration Tools: Umožňuje snadné a uživatelsky přívětivě online zpracování
informací.

Pipeline Editor: Sledování zpracování dokumentů od začátku do konce.
8.1.3 Jádro BizTalk Serveru
BizTalk Server je užitečné rozdělit koncepčně do dvou částí:

jádro (engine)

služby vybudované nad jádrem
Microsoft BizTalk je stroj pro zpravování zpráv (messaging engine). Jedná se o produkt založený na
architektuře publisher/subscriber. Výkonná jednotka (engine) detekuje vstupní data na nastavených
vstupních portech.
Jak je z obrázku č. 22 patrné, zpráva je přijata prostřednictvím vstupního adaptéru (Recieve Adapter).
Zpráva je pak zpracována vstupním procesorem (Receive pipeline). Tento procesor může obsahovat
různé komponenty, které vykonávají činnosti jako např. převod zprávy z jejího nativního formátu na
dokument XML, ověření digitálního podpisu zprávy atd. Zpráva je potom předána do databáze nazývané
MessageBox, která je vytvořena pomocí SQL Serveru.
Administrativní proces je implementován jako jedna či více orchestrací (jsou to běžné programy). Tyto
programy však nejsou napsány v programovacím jazyku typu např. C#. Analytik nebo programátor je
vytvoří grafickým zorganizováním definované skupiny symbolů (obrazců), vyjadřujících podmínky, smyčky
a další chování a postupy v administrativním procesu. Administrativní procesy mohou využívat i tzv.
Business Rules Engine, poskytující jednodušší a snáze modifikovatelný způsob vyjadřování pravidel v
administrativním procesu.
41
Obr. č. 22: Hlavní komponenty jádra BizTalk Serveru, Zdroj: [Visionet Systems, 2011]
Každá orchestrace vytvoří předpisy, vyjadřující typy zpráv, které chce přijímat. Když taková zprva přijde
do MessageBoxu, je přeposlána do své cílové orchestrace, která vykoná tu kterou akci, požadovanou
administrativním procesem. Výsledkem takového zpracování je typicky další zpráva, generovaná
administrativním procesem a uložená v MessageBoxu. Tato zpráva je pak zpracována výstupním
procesorem (Send pipeline), který ji může např. zkonvertovat z interního formátu XML, používaného v
BizTalk Serveru, do formátu požadovaného cílovou aplikací, přidat digitální podpis atd. Zpráva je nakonec
odeslána výstupním adaptérem, který použije ke komunikaci s cílovou aplikací odpovídající
mechanismus.
8.1.4 Posílání a příjem zpráv: Adaptéry
BizTalk Server musí komunikovat se širokým spektrem dalšího softwaru, proto disponuje řadou adaptérů,
které to umožňují. Adaptér je implementace komunikačního mechanismu, např. určitého protokolu.
Adaptér je prvním prvkem systému, který Microsoft BizTalk zpřístupňuje k rozšíření (extensibility point).
Základní úlohou adaptéru je odstínění detailů komunikačních protokolů nutných k přenosu zpráv po síti.
Smyslem adaptéru je zapouzdření komunikačního protokolu pro danou přenosovou technologii.
8.1.4.1 BizTalk Server adaptéry
BizTalk Server adaptéry obsahují:
42

Web Services Adapter: umožňuje odesílání a příjem zpráv pomocí SOAP přes HTTP. K identifikaci
odesílacích i přijímacích systému se používají URL.

MSMQT Adapter: umožňuje odesílání a příjem zpráv pomocí BizTalk Message Queuing
(MSMQT). MSMQT je implementace protokolu MSMQ, který slouží k odesílání a příjmu zpráv
do/z MessageBoxu.

File Adapter: umožňuje čtení ze souboru a psaní do souboru v souborovém systému Windows.

HTTP Adapter: umožňuje odesilání a příjem informací prostřednictvím HTTP.

SMTP Adapter: umožňuje odesilání zpráv prostřednictvím SMTP. K identifikaci odesilatele slouží
standardní emailové adresy.

SQL Adapter: umožňuje čtení a zápis informací z/do databáze SQL Serveru.
Dále existuje velmi široká nabídka adaptérů třetích stran. Tyto adaptéry například umožňují přístup do
systému SAP či IBM WebSphere.
8.2 SAP
8.2.1 SAP NetWeaver
SAP NetWeaver (dále jen SN) je komplexní platforma sloužící k budování a řízení informačního systému
vytvářenému na principech SOA. V širším slova smyslu je tedy možné považovat SN, a technologie, které
poskytuje, za robustní CASE nástroj k řízení (a budování) architektury SOA. SN obsahuje pět hlavních
částí, které vždy pokrývají určitou část funkcionality platformy, jedná se o: [SAP-1, 2011]

SAP NetWeaver Portal

SAP NetWeaver Business Warehouse

SAP NetWeaver Business Process Management/Composition Environment

SAP NetWeaver Process Integration

SAP NetWeaver Mobile
Přestože jednotlivé části lze instalovat nezávisle na sobě, jsou vzájemně provázané a nahrazení jedné
části neSAPovským řešením by mohlo být značně komplikované. Z tohoto důvodu v následujících
kapitolách popíšeme přehledově funkcionalitu jednotlivých částí SAP NetWeaver raději než pouhého
malého fragmentu této platformy.
8.2.2 SAP NetWeaver Portal
SN Portal zajišťuje jednotný přístup k aplikacím, informacím a službám koncovým uživatelům – a to jak k
SAPovským, tak neSAPovským informačním zdrojům. Obsahuje nástroje pro řízení a analýzu přístupu a
obsahu – viz obrázek č. 23. [SAP-2, 2011]
43
Obr. č. 23: SN Portal, Zdroj: [Richter, 2006]
Obrázek č. 24 zobrazuje designové nástroje obsahu – je zde vidět provázanost s ostatními SN nástroji,
které nejsou zahrnuty do SN Portal, například SN Visual Composer (viz dále).
Obr. č. 24: SN Portal - content design tools, Zdroj: [Richter, 2006]
44
8.2.3 SAP NetWeaver Business Warehouse
SN Business Warehouse (dále jen BW) je SAPovské řešení data warehousingu. BW umožňuje integrovat
data warehouse na komplexní a škálovatelnou platformu. BW využívá databázi Teradata – kde dochází ke
konsolidaci dat na jednu databázovou platformu. BW integruje BusinessObjects datové nástroje a řízení
metadat – jak je z obrázku č. 25 patrné, jedná se o Business Inteligence nástroje (kde hraje klíčovou roli
BW Accelerator). [SAP-3, 2011][SAP-4, 2011]
Obr. č. 25: Role SN Business Warehouse v IS, Zdroj: [SAP-3, 2011]
Nedílnou částí poslední verze BW je nástroj pro grafické modelování datových toků. Jedná se o
modelování shora-dolů, které by mělo umožňovat rychlé vytváření strukturovaných modelů (viz obrázek
č. 26). Pro rychlejší modelování datových toků jsou zde předdefinovány šablony (k adaptaci dle
podnikových potřeb) vycházející z best practises. [SAP-5, 2011]
45
Obr. č. 26: Modelování datových toků [SAP-5, 2011]
8.2.4 SAP NetWeaver
Environment
Business
Process
Management/Composition
SN Composition Enviroment poskytuje sady nástrojů a provozní prostředí pro vývoj, běh a řízení
kompozitních aplikací postavených na principech SOA. Z pohledu CASE nástrojů je právě tato část SAP
NetWeaveru nejzajímavější, a proto se zde zaměříme na jednotlivé sady nástrojů, které tato část nabízí.
SAP NetWeaver Developer Studio
Vývojářské prostředí pro vytváření jednotlivých business aplikací (služeb). DS je postavené na platformě
Eclipse a vytváření aplikací je „model-driven“, čili nejdříve dochází k namodelování jednotlivých
komponent a poté k jejich naprogramování, jak je možné vidět na obrázku č. 27. [SAP-6, 2011]
46
Obr. č. 27: Developer studio – Přehled, Zdroj: [SAP-6, 2011]
Tento nástroj je možné rozšiřovat o plug-iny třetích stran, například i o implementaci notace UML, jak je
možné vidět s obrázku č. 28
Obr. č. 28: Developer studio – Komponenty, Zdroj: [SAP-6, 2011]
47
SAP NetWeaver Service Registry and repository
Enterprise Service Repository (dále jen ESR) a Registry (dále jen SR) slouží jako centrální úložiště pro
meta-data podnikových služeb, a také místo kde lze modelovat podnikové služby a jejich interface. ESR
poskytuje integrované modelovací prostředí pro definici podnikových služeb, datových typů a ostatních
objektů – viz obrázek č. 29 a SR vztahy mezi službami a jejich řízení (včetně informací předávaných mezi
těmito službami). [SAP-7, 2011]
Obr. č. 29: Enterprise Service Repository – Objekty, Zdroj: [SAP-7, 2011]
Z obrázku č. 30 je zřejmé, že ESR (se SR, které není sice na následujícím schématu vidět, ale je s ESR
provázáno) hraje klíčovou roli v infrastruktuře SAPu a SOA Governance (mimo jiné se ESR může také
využívat při modelování datových toků v „Process Integration“ – mapování).
48
Obr. č. 30: Enterprise Service Repository – Infrastruktura, Zdroj: [SAP-7, 2011]
SAP NetWeaver Business Process Management a Business Rules Management
SN Business Process Management (dále jen BPM) obsahuje nástroje sloužící k designu, modelování,
implementaci, běhu, monitorování, provozu a zlepšování business procesů celým jejich životním cyklem.
SN Business Rules Management (dále jen BRM) slouží k řízení business pravidel (např. které procesy se
automatizují). Obrázek č. 31 ukazuje přehled částí (nástrojů) v rámci BRM. [SAP-8, 2011] [Narayanan,
2011]
Obr. č. 31: Business Rules Management – Nástroje, Zdroj: [Narayanan, 2009]
49
Přestože BPM a BRM by měly jít použít zvlášť, vzájemně se doplňují – například nejdřív může dojít k
namodelování procesu v rámci BPM a po té jednotlivým krokům přiřadit pravidla, jak je možno vidět na
obrázku č. 32.
Obr. č. 32: SN Businness Proces Management a Business Rules Management – Příklad, Zdroj: [Narayanan, 2009]
SAP NetWeaver Visual Composer
Modelovací nástroj pro vytváření aplikací pro existující datové služby – viz obrázek 33. Datové služby
mohou být spojeny s transakčními (RFC, Web Service, Portal JDBC) nebo analytickými (SAP BI, JDBC, SAP
Query, XMLA, ODBO) backend systémy. [SAP-9, 2011]
50
Obr. č. 33: Visal Composer, Zdroj: [SAP-10, 2011]
SAP Composite Application Framework
Metodika a soubor nástrojů pro sestavování a řízení kompozitních aplikací. V rámci vytváření
kompozitních aplikací se zde rozlišují 4 procesy – přehled (viz obrázek č. 33). [SAP-11, 2011]
51
Obr. č. 34: Composite Aplication Framework – Procesy, Zdroj: [SAP-11, 2011]
8.2.5 SAP NetWeaver Process Integration
SN Process Integration je implementací SOA middleware. Jedná se o integraci založenou na zprávách
(mapování, směrování, využívání adaptérů, orchestrace služeb založená na integraci procesů). Integrací
procesů je zde myšlena choreografie výměny dat mezi procesními komponentami. Pro zjednodušení
vazeb mezi komponentami je zde využíván Integration Broker, přes který jsou předávány (a případně
upravovány) xml zprávy, viz obrázek č. 35. (Gutsche, 2009)
Obr. č. 35: Integration Broker, Zdroj: [Gutsche, 2009]
8.2.6 SAP NetWeaver Mobile
SN Mobile slouží k zajištění bezpečného přístupu k systému odkudkoliv (přes přenosný počítač nebo
mobil). [SAP-12, 2011]
52
9. Budoucnost SOA: Cloud computing
Kapitola je zaměřená na dnešní technologii Cloud computing v porovnání se SOA. V poslední podkapitole
se autor soustředil na charakteristiku budoucího vývoje využití SOA.
9.1 Srovnání SOA a Cloud computingu
Pojmy SOA a Cloud computing není vhodné srovnávat na základě toho, v čem je který lepší. Spíše je
vhodné se na Cloud computing dívat jako na nástupce SOA, který tuto architekturu posunuje dále.
Jestliže SOA poskytuje služby uvnitř podnikové sítě, pak Cloud computing jde za podnikový firewall.
Všechny zdroje jsou tak mimo kontrolu společnosti, která využívá pouze dané služby a nestará se a ani se
starat nemůže o technické pozadí.
Obr. č. 36: SOA vs. Cloud computing, Zdroj: [Qylafku, 2010]
Platí také, že není možné nasadit Cloud computing aniž by systém byl připraven na SOA. Podnik musí být
na práci pomocí služeb připraven. SOA musí být zavedené, Cloud computing pak už přináší „pouze“
možnost využívat tisíce služeb přes internet.
Cloud computing přináší v porovnání s využíváním služeb, u kterých má podnik kontrolu i nad zdroji
několik významných výhod, ale zároveň i nevýhod. Podíváme se na ně podrobněji.
9.2 Výhody Cloud computingu
První výhoda vyplývá z rozdílu mezi SOA a Cloud computingem – není třeba se nijak zabývat zdroji
nutnými pro provoz daných služeb. Odpadá tak velké množství nákladů:
53

analýza a výběr vhodného řešení

cena řešení (hardware + software)

lidé starající se o provoz

školení lidí

údržba systému a pravidelný upgrade
O vše potřebné se stará poskytovatel služby. Podnik pak používá služby za mírný poplatek či úplně
zdarma. U některých služeb není nutné platit za službu jako celek, ale pouze za využité zdroje. Například
u hostingu tak platí podnik pouze za nahraná a přenesená data a využitý výpočetní výkon. U webů
obsluhující špičky může dojít k výraznému snížení nákladů.
Druhá výhoda navazuje. Nasazení služby pomocí Cloud computingu je většinou otázka pár minut, což se
určitě nedá říct o standardním zavedení pomocí SOA.
Jelikož poskytovatel služby většinou operuje na globálním poli, kde mu konkuruje velké množství firem,
je nucen držet službu na vrcholu, co se týče možností, funkcí či bezpečnosti. Jeden případ nabourání do
systému může ohrozit pověst poskytovatele. Podnik tak získává za stejný poplatek stále se vyvíjející
službu, která drží krok s dobou.
Jedním z problémů SOA je práce se špičkami vytíženosti. Žádná služba není využívána kontinuálně, ale
během času dochází ke špičkám, které je nutné zvládat při zachování požadované kvality. Logicky pak
musí být zdroje naddimenzovány a většinu času se flákají, aby párkrát ročně fungovaly i při špičkách
(např. Vánoce). Služby v cloudu se s tímto problémem vyrovnávají výrazně lépe, protože obsluhují tisíce
uživatelů, kteří mají špičky vždy jindy (už jenom z logiky časových pásem) a zdroje jsou tak využity
výrazně lépe. Cloud computing tak i výrazně šetří životní prostředí, protože není nutné budovat desítky
výkonných systémů, ale postačí jenom jeden.
9.3 Nevýhody Cloud computingu
Nevýhody Cloud computingu plynou z absence kontroly nad zdroji nutnými pro provoz služeb. Jak tato
absence přinášela nezanedbatelné výhody, jak bylo vidět výše, tak bohužel má i svá omezení, na která se
podíváme podrobněji.
Klíčové pro všechny podniky bude při využití Cloud computingu ztráta kontroly nad daty. Data jsou
uložená mimo vnitřní systémy, nad kterými má podnik kontrolu, může nastavit potřebná zabezpečení a
pravidelné zálohování. V cloudu je podnik odkázán na poskytovatele, kterému svěřuje svá (mnohdy
citlivá) data a jejich zabezpečení. Data jsou ohrožena hned v několika fázích:

při každém přenosu putují, sice šifrovaná, ale pořád veřejně po internetu

hrozí napadení systému poskytovatele a zcizení dat

podnik je odkázán na zálohování poskytovatele, které, jak ukazují případy ztráty dat, není vždy
stoprocentní
54
Kromě problémů s bezpečností dat se ztráta kontroly nad daty projevuje při migraci mezi poskytovateli.
Poskytovatel nemusí nabízet export podnikových dat a podnik se pak stává uvězněn uvnitř. Možnost
přechodu mezi poskytovateli tak bude hrát velmi významnou roli při výběru poskytovatele.
Potíže bude dělat také integrace dat napříč systémy různých poskytovatelů. Cloud computing na něco
podobného není stavěn. Řešením pro podniky může být implementované API rozhraní k datům, které
takovou integraci umožňuje.
Standardem u Cloud computingu také není vždy použití smluv SLA. Garance dostupnosti nebývá
definována smluvně, ale spíše na základě značky, kdy je pro poskytovatele klíčové držet si dobrou pověst.
9.4 Budoucí vývoj
Jak ukazuje porovnání výhod a nevýhod Cloud computingu nenahradí všechny služby, ale pouze ty, kde
rizika ze ztráty kontroly nad daty převýší výhody. Cloud computing tak nebude nikdy vhodný pro práci s
klíčovými citlivými daty, které mají pro podnik takovou hodnotu, že je s nimi vždy nutné pracovat za
podnikovým firewallem. Naopak pro řadu podpůrných služeb je umístění v cloudu ideální řešení. Ušetří
se značné prostředky se správou potřebných zdrojů k běhu služby a čas nutný k implementaci.
Do budoucna se bude rozšiřovat užití služeb v cloudu, budou převažovat výhody nad ztrátou kontroly
nad daty, protože jednoduše podniky užívající služeb v cloudu budou mít výhodu nad těmi, které se musí
zabývat neklíčovými a podpůrnými zdroji pro běh služeb. Důvodem také je to, že problémům s
bezpečností dat a zálohováním se podnik nevyhne ani při vlastním řešení a naopak zkušený poskytovatel
má většinou vše výrazně lépe vyřešené.
55
10. Závěr
Jak bylo již v úvodu řečeno, naše práce se snažila o co nejobsáhlejší popsání SOA. Při naplňování tohoto
cíle jsme museli překonat několik překážek. Jednou z nich bylo mnoho prací vytvořených na toto téma v
minulých letech. Obsah celé práce byl proto koncipován, aby přinesl pokud možno co nejvíce zcela
nových pohledů na tuto problematiku či informací aktualizovaných do dnešních dnů. V souhrnu lze říci,
že naše práce obsahuje již zpracovanou oblast pouze v případě teoretického úvodu. Popis řešení od
konkrétního dodavatele se v předchozích pracích objevil také, ale v našem případě jde o popis zcela
jiného. Na čtenářích nyní leží úkol nejlehčí, a to odnést si z práce pouze informace které potřebují.
Počáteční část práce se věnuje problematice popisující historii vzniku samotného konceptu SOA a
čtenáře poprvé seznamuje s informacemi, s nimiž se v pracích našich předchůdců neměli možnost
seznámit. Jsou zde popsány první snahy o uvedení konceptu SOA do života jedním z prvních pionýru
propagujících tuto myšlenku a je zde vyvráceno několik obecně přijímaných mýtů o stáří SOA.
Na historický úvod navazuje obecné seznámení s teoretickou rovinou SOA. Kapitola čtenářům zásadní
pojmy nutné pro základní teoretickou orientaci v této oblasti. Jdou zde definovány pojmy jako služba,
architektura a je zde uveden k dispozici i základní úvod do bezpečnosti spolu s ukázkou referenčního
modelu.
V dalších částech konkrétně kapitole 3 jsou velmi zevrubně popsány webové služby jako jeden ze
základních kamenů současné SOA. Čtenáři se zde obeznámí s problematikou využití XML, REST, SOAP,
WSDL a UDDI. Kapitola 4 popisuje vzájemné vztahy mezi SOA a EDA, v jakých aspektech se obě
architektury prolínají a naopak v čem se liší. Je zde objasněn pojem SOA Governance, se kterým jste se
setkali i v kapitole 7.
Kapitola 5 se věnuje jazyku BPEL jako jedné z možností Business Process Modellingu. Jsou zde k dispozici
informace určující a vysvětlující vztahy k SOA. Můžete se zde dočíst o závislostech na XML a informacích
o produktech zajišťujících správu BPEL procesů. Kapitola 6 navazuje na předcházející rozšířením informací
o vztahu SOA k BPM a prohloubením popisu známých dodavatelů s touto problematikou.
Následující kapitola je zaměřena na praktickou oblast a reálné využívání jednotlivých řešení samotnými
zákazníky. Dočtete se zde o situaci na trhu se SOA Governance. Kapitola obsahuje informace o všech
hráčích resp. jejich silných stránkách a možných nebezpečích pro dané dodavatele. Tato kapitola je
doplněna velmi rozsáhlým popisem funkcionality produktů BizTalk a SAP NetWeaver, o kterých se
dočtete v kapitole 8.
Poslední kapitola se věnuje dnes velmi populárnímu modelu Cloud a nutnému srovnání se SOA. Je zde
popsáno mnoho aspektů pro obě koncepce a nastíněno srovnání obou technologií i s pravděpodobným
pohledem do budoucna.
56
11. Seznam použitých zdrojů
















[VSB, 2011]: VSB [online]. 2011 [cit. 2011-23-04+. Architektura orientovaná na služby. Dostupné z WWW:
<http://formular-ekf.vsb.cz/formulare/F01/tsw/getfile.php?prispevekid=877>.
[Townsend, 2010]: ErikTownsend [online]. 2010 [cit. 2011-23-04]. The 25 Year History of Service Oriented
Architecture. Dostupné z WWW: <http://www.eriktownsend.com/white-paperstechnology/doc_download/4-1-the-25-year-history-of-service-oriented-architecture.html>.ErikTownsend
[online]. 2010 [cit. 2011-23-04+. The 25 Year History of Service Oriented Architecture. Dostupné z WWW:
<http://www.eriktownsend.com/white-papers-technology/doc_download/4-1-the-25-year-history-ofservice-oriented-architecture.html>.
[DCOM, 2008]: Service Architecture [online]. 2011 [cit. 2011-20-04+. DCOM. Dostupné z WWW:
<http://www.service-architecture.com/web-services/articles/dcom.html>.
[W3C, 1998]: W3C [online]. 2011 [cit. 2011-22-04+. SOAP Version 1.2 Part 1. Dostupné z WWW:
<http://www.w3.org/TR/soap12-part1/#intro>.
[Wikipedia-1, 2011]: Web Services Description Language#History. In Wikipedia : the free encyclopedia
[online]. St. Petersburg (Florida) : Wikipedia Foundation, 27.10. 2002, last modified on 13.4.2011 [cit.
2011-04-23+. Dostupné z WWW:
http://en.wikipedia.org/wiki/Web_Services_Description_Language#History>.
[UDDI, 2011]: UDDI#History. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) :
Wikipedia Foundation, 16.12. 2002, last modified on 3.4. 2011 [cit. 2011-04-23+. Dostupné z WWW:
<http://en.wikipedia.org/wiki/UDDI#History>
[Irvine, 2001]: University of California, Irvine [online]. 2011 [cit. 2011-20-04]. Representational State
Transfer. Dostupné z WWW:<http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm>.
[Wikipedia-2, 2011]: Data Distribution Service#History. In Wikipedia : the free encyclopedia [online]. St.
Petersburg (Florida) : Wikipedia Foundation, 13.6. 2005, last modified on 6.4. 2011 [cit. 2011-04-23].
Dostupné z WWW: <http://en.wikipedia.org/wiki/Data_Distribution_Service#History>.
*Lešina, 2007]: LEŠINA, Petr. Co je Servisně Orientovaná Architektura? *online+. 2007 *cit. 2010-11-14].
Dostupné z WWW: http://bpm-ibm.blogspot.com/2007/11/co-je-servisn-orientovan-architektura.html
[Barry, 2011]: BARRY, Douglas K. Service-oriented architecture (SOA) definition [online]. 2007 [cit. 201011-14+. Dostupné z WWW: http://www.service-architecture.com/web-services/articles/serviceoriented_architecture_soa_definition.html
[Barry-2, 2011]: BARRY, Douglas K. Service [online]. 2007 [cit. 2010-11-17+. Dostupné z
WWW:http://www.service-architecture.com/web-services/articles/service.html
[IBM, 2008]: IBM. Správa a zabezpečení SOA *online+. 2008 *cit. 2010-11-29+. Dostupné z WWW:
http://www-01.ibm.com/software/cz/solutions/soa/mgmtsec/security.html
*Štumpf, 2006]: ŠTUMPF, Jindřich. Řízení SOA v provozním prostředí SOA *online+. 2006 *cit. 2010-11-29].
Dostupné z WWW: http://www.systemonline.cz/sprava-it/rizeni-soa-v-provoznim-prostredi.htm
*Štumpf-2, 2006]: ŠTUMPF, Jindřich. SOA: referenční model *online+. 2007 *cit. 2010-11-29+. Dostupné z
WWW: http://soablogjst.blogspot.com/2007/03/referenn-model-soa.html
[SecurityWorld, 2009]: SECURITYWORLD. Zabezpečujeme webové služby a SOA (1) *online+. 2009 *cit.
2010-11-29+. Dostupné z WWW: http://securityworld.cz/securityworld/bezpecne-soa-a-webove-sluzby-11930
[SecurityWorld-2, 2009]:SECURITYWORLD. Zabezpečujeme webové služby a SOA (2) *online+. 2009 *cit.
2010-11-29]. Dostupné z WWW: http://securityworld.cz/securityworld/zabezpecujeme-webove-sluzby-asoa-2-1931
57




















[W3C, 2001]: W3C Web Services Description Language 1.1, March 2001. Dostupné z WWW:
<http://www.w3.org/TR/2002/WD-ws-arch-20021114/>
[CHOW, 2008]: Chow Shu-Wai. Programujeme Mashup aplikace pro Web 2.0 v PHP. Computer Press. 2008
[W3C1, 2011]: W3C. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) [online]. 2007
Dostupné z WWW: <http://www.w3.org/TR/soap12-part1/>
*Hovorčák, 2003]: HOROVČÁK, Pavel. Webové služby - třetí generace internetu *online+. 2003 System
Online. Dostupné z WWW: <http://www.systemonline.cz/clanky/webove-sluzby-treti-generaceinternetu.htm>
*Juřek, 2004]: JUŘEK, Michael, Moderní integrace aplikací *online+. 2004 *cit. 2011-04-25+. Dostupné z
WWW: <http://download.microsoft.com/download/8/6/c/86c09926-affc-4e14-bec03c45cd989436/Moderni_integrace.pdf>
[W3C2, 2011]: W3C.Web Services Description Language (WSDL) 1.1*online+. 2001 Dostupné z WWW:
<http://www.w3.org/TR/wsdl#_service>
[Melichna, 2008]: MELICHNA, Jiří. Zabezpečujeme webové služby a SOA. SecurityWorld. 2008, 1, s. 20-24.
[Palmer, 2007]: PALMER, Mark; DŽMURÁŇ, Michal. Komplexní zpracování událostí a architektury
řízené událostmi. Progress Software [online]. 2007. [cit. 2011-04-07]. Dostupný z WWW:
<http://www.progress.com/progress_software/worldwide_sites/cz/docs/cep/071002a.pdf>.
[IBM, 2011]: MARÉCHAUX, Jean-Louis. Combining Service-Oriented Architecture and Event-Driven
Architecture using an Enterprise Service Bus. IBM developerWorks [online]. 23. 8. 2006. [cit. 2011-04-19].
Dostupný z WWW: <https://www.ibm.com/developerworks/library/ws-soa-eda-esb/>.
[Kasal, 2011]: KASAL, Jindřich. SOA Governance. SOA blog *online+. 29. 8. 2007. [cit. 2011-04-18].
Dostupný z WWW: <http://jindrichkasal.blogspot.com/2007/08/soa-governance.html>.
[Karkošková, 2010]: KARKOŠKOVÁ, Soňa. SOA Governance [online]. Praha: VŠE, 2010. 66 s. Bakalářská
práce. Vysoká škola ekonomická. Dostupné z WWW:
<http://library.vse.cz/F/6AQXBQAIMJ4CY6KKTBVBNDIQXEUDP234VAF667HHKEFCS9P2LM44847?func=full-set-set&set_number=165101&set_entry=000003&format=999>.
[OpenGroup1, 2011]: SOA Governance Technical Standard: SOA Governance Reference Model (SGRM).
The SOA Source Book [online]. [cit. 2011-04-12+. Dostupný z WWW:
<http://www.opengroup.org/soa/source-book/gov/sgrm.htm>.
[OpenGroup2, 2011]: SOA Governance Technical Standard: SOA Governance Vitality metoda (SGVM). The
SOA Source Book [online]. [cit. 2011-04-12+. Dostupný z WWW: <http://www.opengroup.org/soa/sourcebook/gov/sgvm.htm>.
*Maršík, 2008]: MARŠÍK V., PRAGER M. Analýza jazyků pro orchestraci, 2008. *cit. 2011-04-16]
[BPEL, 2011]: Wikipedia, The Free Encyclopedia. Business Process Execution Language [Online].[cit. 201104-16]. <http://en.wikipedia.org/wiki/Business_Process_Execution_Language>.
[DC Design, 2010]: DC Design [online]. 2010 [cit. 2011-04-20+. SOA & BPEL. Dostupné z WWW:
<http://www.dc-design.eu/?cat=4>.
[IBM WebSphere, 2010]: IBM [online]. 2010 [cit. 2011-04-20]. BPM - Business Process Management.
Dostupné z WWW: <http://www-01.ibm.com/software/cz/info/bpm/>.
[Javaworld, 2006]: Javaworld [online]. 2006 [cit. 2011-04-12]. Javaworld.com. Dostupné z WWW:
<http://www.javaworld.com/javaworld/jw-05-2006/images/jw-0522-jbpm1.gif>.
*Šafář, 2007]: ŠAFÁŘ, Pavel. Vyuţití BPEL v servisně-orientovaných architekturách *Online+. 2007. *cit.
2011-04-16]. <http://is.muni.cz/th/73395/fi_m/thesis.pdf>.
*Černý, 2010]: ČERNÝ, Ondřej. BPEL *online+. Praha: VŠE, 2010. 73 s. Diplomová práce. Vysoká škola
ekonomická v Praze. Dostupné z WWW: <https://www.vse.cz/vskp/public.php?evskp_id=24216>.
58

















[Rosen, 2011]: ROSEN, Mike. Where Does One End and the Other Begin? BPM and SOA [online]. 2006.
[cit. 2011-04-24+. Online. Dostupné z WWW: <http://www.bptrends.com>.
*Kianička, 2008]: KIANIČKA, Tomáš. Princip vývoje softwaru postavený nad průběžnou integrací na bázi
SOA *online+. Praha: ČVUT, 2008. 76 s. Bakalářská práce. České vysoké učení technické. Dostupné z WWW:
<https://dip.felk.cvut.cz/browse/pdfcache/kianit1_2008bach.pdf>.
[Adam, 2008]: ADAM, Sebastian; DOERR Joerg. How to better align BPM & SOA – Ideas on improving
the transition between process design and deployment [Online]. 2008. [cit. 2011-04-22+. Online. Dostupné
z WWW: <http://lams.epfl.ch/conference/bpmds08/program/paper6.pdf>.
[Basl, 2008]: BASL, Josef. Architektura podnikání *Online+. 1/2008. *cit. 2011-04-25+. Online. Dostupné z
WWW: <http://bpm-tema.blogspot.com/2008/01/architektura-podnikani.html>.
*Pršala, 2009]: PRŠALA, Ondřej Bc. SOA Governance: jako další vývojový stupeň zavádění SOA
architektury *online+. Praha: VŠE, 2009. 121 s. Diplomová práce. Vysoká škola ekonomická v Praze.
Dostupné z WWW: <https://vse-praha.info/vskp/public.php?evskp_id=9117>.
[Josuttis, 2007]: JOSUTTIS , Nicolai; ST. LAURENT, Simon. SOA in Practice: The Art of Distributed System
Design , O'Reilly Media, 2007. 324 s. ISBN 978-0-596-52955-0.
[WSO2, 2011]: WSO2 [online]. 2011 [cit. 2011-04-13+. WSO2. Dostupné z WWW:
<http://wso2.com/products/enterprise-service-bus/>.
*BPM téma, 2007+: BPM téma [online]. 2007 [cit. 2011-04-16+. Jak na BPM a SOA prakticky. Dostupné z
WWW: <http://bpm-tema.blogspot.com/2007_10_01_archive.html>.
[BusinessWorld, 2008]: Abeceda BPM, Businessworld.cz [Online]., 2008. [cit. 2011-04-25]. Online.
Dostupné z WWW: <http://www.businessworld.cz/bw.nsf/co-je-businessprocessmanagement/886E8B63E43620E7C1257485005BD194?OpenDocument&cast=1>.
[CNET, 2011]: CNET Direct Technology Market Experts [online]. 2011 [cit. 2011-23-04]. Magic Quadrant
for Integrated SOA Governance Technology Sets. Dostupné z WWW:
<http://www.cnetdirectintl.com/direct/fr/2009/progress/0907_centre_ressources/ressources/news/Magi
c_quadranCBS__Gartner_report_actional.pdf>.
[Gutsche, 2009] GUTSCHE, Peter. Process Integration Handbook. SAP Community Network. [Online] 30. 6
2009. [Citace: 19. 4 2011.]
<http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/8078cff3-e045-2c10-9baeabf0ca5040c5?QuickLink=index&overridelayout=true>.
[Narayanan, 2009] NARAYANAN, Rajagopalan. Business Rules Change All the Time, But Your Applications
Don’t Have To. SAPinsider. [Online] 6. 2009. [Citace: 12. 4 2011.]
<http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/a0a95c58-4512-2c10-0782e07af9347e2c?QuickLink=nw-rules-management&overridelayout=true>.
[Richter, 2006] RICHTER, Jana, HENSEL, Thomas a spol. Integrating Content into your Portal (Providing
Uniform Content Access). SAP Community Network. [Online] 2006. [Citace: 10. 4 2011.]
<http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d0ba013b-2048-2a10-0eb0ce91137b4e7e?QuickLink=index&overridelayout=true>.
[SAP-1, 2011] SAP NetWeaver 7.3. SAP Community Network. [Online] [Citace: 10. 4 2011.]
<http://www.sdn.sap.com/irj/sdn/nw-73>.
[SAP-2, 2011] SAP NetWeaver Portal and Collaboration. SAP Community Network. [Online] [Citace: 10. 4
2011.] <http://www.sdn.sap.com/irj/sdn/nw-portalandcollaboration>.
[SAP-3, 2011] SAP NetWeaver BW - What’s new with SAP NetWeaver BW 7.3. SAP Community Network.
[Online] 3 2011. [Citace: 10. 4 2011.]
<http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/304444f7-e02d-2d10-9c97d5e3ecf09882?QuickLink=index&overridelayout=true>.
[SAP-4, 2011] Enterprise Data Warehousing - with the SAP NetWeaver Business Warehouse (BW). SAP
Community Network. [Online] [Citace: 10. 4 2011.] <http://www.sdn.sap.com/irj/sdn/edw>.
59


















[SAP-5, 2011] SAP NetWeaverBW 7.3 Overview and Roadmap. SAP Community Network. [Online] 4 2011.
[Citace: 10. 4 2011.] <http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/300347b59bcf-2d10-efa9-8cc8d89ee72c?QuickLink=index&overridelayout=true>.
[SAP-6, 2011] SAP NetWeaver Developer Studio. SAP Community Network. [Online] 9 2007. [Citace: 12. 4
2011.] <http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/309c816e-7c51-2a10-05b69e0151d0ea2d?QuickLink=index&overridelayout=true>.
[SAP-7, 2011]. SAP NetWeaver Process Integration 7.1 - Deep Dive into the Enterprise Services Repository.
SAP Community Network. [Online] 12 2007. [Citace: 12. 4 2011.]
<http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c0f90f22-678c-2a10-91a0f1f1bf7ff191?QuickLink=index&overridelayout=true>.
[SAP-8, 2011] Business Process Management. SAP Community Network. [Online] [Citace: 12. 4 2011.]
<http://www.sdn.sap.com/irj/sdn/business-process-management>.
[SAP-9, 2011] What is Visual Composer? SAP Community Network. [Online] [Citace: 17. 4 2011.]
<http://wiki.sdn.sap.com/wiki/pages/viewpage.action?pageId=4411>.
[SAP-10, 2011] CREATE APPLICATIONS EASILY WITH VISUALCOMPOSER TOOL. SAP Community Network.
[Online] 2006. [Citace: 17. 4 2011.]
<http://www.sap.com/belux/platform/netweaver/pdf/BWP_SB_Creating_Applications_Easily_with_Visual
_Composer_Tool.pdf>.
[SAP-11, 2011] SAP NetWeaver Composite Application Framework - Overview. SAP Community Network.
[Online] 2008. [Citace: 17. 4 2011.]
<http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/003110b5-e1c9-2b10-3dba97ebfe1fd0b7?QuickLink=index&overridelayout=true>.
[SAP-12,2011] MOBILITY SOLUTIONS FROM SAP. SAP Community Network. [Online] [Citace: 19. 4 2011.]
<http://www.sdn.sap.com/irj/sdn/mobile?rid=/webcontent/uuid/80222bf7-42a2-2d10-ca80ecece5f7cae7>.
[SAP-12,2011] MOBILITY SOLUTIONS FROM SAP. SAP Community Network. [Online] [Citace: 19. 4 2011.]
<http://www.sdn.sap.com/irj/sdn/mobile?rid=/webcontent/uuid/80222bf7-42a2-2d10-ca80ecece5f7cae7>.
[Qylafku, 2010] QYLAFKU, Denis. Rozšíření SOA do platformy Cloud Computing. *s.l.+, 2010. 88 s.
Diplomová práce. VŠE.
[SAP-12,2011] INTEGRACE: SOA, ČI CLOUD?. Business World.cz. [Online] [Citace: 25. 4 2011.]
<http://businessworld.cz/podnikove-is/integrace-soa-ci-cloud-5832>.
*BŘÍZA 2011+ BŘÍZA, Petr. Microsoft BizTalk Server 2004 - princip technologie. [Online]
<http://interval.cz/clanky/microsoft-biztalk-server-2004-princip-technologie/>.
[CHAPPELL 2011] CHAPPELL, David, Chappell & Associates. Introducing BizTalk Server 2004. [Online]
<www.apollo.gr/dev/releases/UnderstandingBizTalkServer2004.doc>.
[Microsoft, 2011] Microsoft. BizTalk Server Adapters. [Online]
<http://www.microsoft.com/biztalk/en/us/adapters-included.aspx>.
[Microsoft-02, 2011] Microsoft. Microsoft BizTalk Server Product Overview. [Online]
<http://www.microsoft.com/biztalk/en/us/overview.aspx>.
[CHAPPELL-02, 2011] CHAPPELL, David, Chappell & Associates. Understanding BizTalk Server 2004. [Online]
<http://msdn.microsoft.com/en-us/library/ms942195%28v=bts.10%29.aspx>
[CHAPPELL-03, 2011] CHAPPELL, David, Chappell & Associates. Understanding BizTalk Server 2004. [Online]
<http://msdn.microsoft.com/en-us/library/ms942195%28v=bts.10%29.aspx>
[Visionet Systems, 2011] Visionet Systems. BizTalk Main Modules and Features. [Online]
<http://www.visionetsystems.com/microsoft-biztalk-server.html>
60