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 <methodCall> <methodName>trida.jmenoMetody <params> <param>
250 <param>
oblast
10
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" <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>
7003222315
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:
. [Townsend, 2010]: ErikTownsend [online]. 2010 [cit. 2011-23-04]. The 25 Year History of Service Oriented Architecture. Dostupné z WWW: .ErikTownsend [online]. 2010 [cit. 2011-23-04+. The 25 Year History of Service Oriented Architecture. Dostupné z WWW: . [DCOM, 2008]: Service Architecture [online]. 2011 [cit. 2011-20-04+. DCOM. Dostupné z WWW: . [W3C, 1998]: W3C [online]. 2011 [cit. 2011-22-04+. SOAP Version 1.2 Part 1. Dostupné z WWW: . [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: [Irvine, 2001]: University of California, Irvine [online]. 2011 [cit. 2011-20-04]. Representational State Transfer. Dostupné z WWW:. [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: . *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: [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: *Hovorčák, 2003]: HOROVČÁK, Pavel. Webové služby - třetí generace internetu *online+. 2003 System Online. Dostupné z WWW: *Juřek, 2004]: JUŘEK, Michael, Moderní integrace aplikací *online+. 2004 *cit. 2011-04-25+. Dostupné z WWW: [W3C2, 2011]: W3C.Web Services Description Language (WSDL) 1.1*online+. 2001 Dostupné z WWW: [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: . [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: . [Kasal, 2011]: KASAL, Jindřich. SOA Governance. SOA blog *online+. 29. 8. 2007. [cit. 2011-04-18]. Dostupný z WWW: . [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: . [OpenGroup1, 2011]: SOA Governance Technical Standard: SOA Governance Reference Model (SGRM). The SOA Source Book [online]. [cit. 2011-04-12+. Dostupný z WWW: . [OpenGroup2, 2011]: SOA Governance Technical Standard: SOA Governance Vitality metoda (SGVM). The SOA Source Book [online]. [cit. 2011-04-12+. Dostupný z WWW: . *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]. . [DC Design, 2010]: DC Design [online]. 2010 [cit. 2011-04-20+. SOA & BPEL. Dostupné z WWW: . [IBM WebSphere, 2010]: IBM [online]. 2010 [cit. 2011-04-20]. BPM - Business Process Management. Dostupné z WWW: . [Javaworld, 2006]: Javaworld [online]. 2006 [cit. 2011-04-12]. Javaworld.com. Dostupné z WWW: . *Šafář, 2007]: ŠAFÁŘ, Pavel. Vyuţití BPEL v servisně-orientovaných architekturách *Online+. 2007. *cit. 2011-04-16]. . *Černý, 2010]: ČERNÝ, Ondřej. BPEL *online+. Praha: VŠE, 2010. 73 s. Diplomová práce. Vysoká škola ekonomická v Praze. Dostupné z WWW: .
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: . *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: . [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: . [Basl, 2008]: BASL, Josef. Architektura podnikání *Online+. 1/2008. *cit. 2011-04-25+. Online. Dostupné z WWW: . *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: . [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: . *BPM téma, 2007+: BPM téma [online]. 2007 [cit. 2011-04-16+. Jak na BPM a SOA prakticky. Dostupné z WWW: . [BusinessWorld, 2008]: Abeceda BPM, Businessworld.cz [Online]., 2008. [cit. 2011-04-25]. Online. Dostupné z WWW: . [CNET, 2011]: CNET Direct Technology Market Experts [online]. 2011 [cit. 2011-23-04]. Magic Quadrant for Integrated SOA Governance Technology Sets. Dostupné z WWW: . [Gutsche, 2009] GUTSCHE, Peter. Process Integration Handbook. SAP Community Network. [Online] 30. 6 2009. [Citace: 19. 4 2011.] . [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.] . [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.] . [SAP-1, 2011] SAP NetWeaver 7.3. SAP Community Network. [Online] [Citace: 10. 4 2011.] . [SAP-2, 2011] SAP NetWeaver Portal and Collaboration. SAP Community Network. [Online] [Citace: 10. 4 2011.] . [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.] . [SAP-4, 2011] Enterprise Data Warehousing - with the SAP NetWeaver Business Warehouse (BW). SAP Community Network. [Online] [Citace: 10. 4 2011.] .
59
[SAP-5, 2011] SAP NetWeaverBW 7.3 Overview and Roadmap. SAP Community Network. [Online] 4 2011. [Citace: 10. 4 2011.] . [SAP-6, 2011] SAP NetWeaver Developer Studio. SAP Community Network. [Online] 9 2007. [Citace: 12. 4 2011.] . [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.] . [SAP-8, 2011] Business Process Management. SAP Community Network. [Online] [Citace: 12. 4 2011.] . [SAP-9, 2011] What is Visual Composer? SAP Community Network. [Online] [Citace: 17. 4 2011.] . [SAP-10, 2011] CREATE APPLICATIONS EASILY WITH VISUALCOMPOSER TOOL. SAP Community Network. [Online] 2006. [Citace: 17. 4 2011.] . [SAP-11, 2011] SAP NetWeaver Composite Application Framework - Overview. SAP Community Network. [Online] 2008. [Citace: 17. 4 2011.] . [SAP-12,2011] MOBILITY SOLUTIONS FROM SAP. SAP Community Network. [Online] [Citace: 19. 4 2011.] . [SAP-12,2011] MOBILITY SOLUTIONS FROM SAP. SAP Community Network. [Online] [Citace: 19. 4 2011.] . [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.] . *BŘÍZA 2011+ BŘÍZA, Petr. Microsoft BizTalk Server 2004 - princip technologie. [Online] . [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] . [Microsoft-02, 2011] Microsoft. Microsoft BizTalk Server Product Overview. [Online] . [CHAPPELL-02, 2011] CHAPPELL, David, Chappell & Associates. Understanding BizTalk Server 2004. [Online] [CHAPPELL-03, 2011] CHAPPELL, David, Chappell & Associates. Understanding BizTalk Server 2004. [Online] [Visionet Systems, 2011] Visionet Systems. BizTalk Main Modules and Features. [Online]
60
