Mendelova zemědělská a lesnická univerzita v Brně. Provozně ekonomická fakulta. Integrace informačních systémů v podnikové praxi.

Transkript

1 Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta Integrace informačních systémů v podnikové praxi Diplomová práce Vedoucí práce doc. Ing.Ivana Rábová, PhD. Zpracoval Bc. Josef Kotrba Brno 2009

2 2

3 3

4 Čestné prohlášení Prohlašuji, že jsem diplomovou práci vytvořil zcela samostatně pod vedením svého vedoucího diplomové práce a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem čerpal. V Brně dne 10. května

5 Poděkování Touto cestou bych rád poděkoval doc. Ing. Ivaně Rábové, Ph.D za její cenné rady, konzultace a odbornou pomoc při řešení problémů, které mi při práci vznikly. RNDr. Janě Kohoutkové, Ph.D. za možnost implementovat výsledky diplomové práce v praxi, za její rady a připomínky, které mi pomohly odstranit nedostatky a dokončit práci ve stanoveném termínu. 5

6 6

7 Abstrakt KOTRBA, J. Integrace informačních systémů v podnikové praxi Diplomová práce. Brno, Diplomová práce se zabývá metodami integrace informačních systémů. Zvláštní pozornost je věnována servisně orientované architektuře. Mapuje jazyky a nástroje pro podporu návrhu a vývoje aplikací na bázi webových služeb. Na jednoduchém praktickém příkladu představuje návrh modelu informačního systému pro správu nemovitostí tak, aby vyhovoval potřebám integrace s okolním systémy. Klíčová slova Analýza, informace, informační systém, správa nemovitostí, webová služba, SOA, BPEL, XML, UML. Abstract KOTRBA, J. Integration of information systems in business routine. Master thesis. Brno, This thesis analyses methods of information systems integration, mainly focusing on service oriented architecture. In the theoretical section, languages and tools used in design and development of web service based applications are described. The practical part presents a building management information system design, suitable for integration with surrounding systems. Keywords Analysis, information, information system, property management, web service, SOA, BPEL, XML, UML. 7

8 1 Obsah 1 Obsah Úvod Cíl práce Definice pojmů Informační systém Podnikové informační systémy Dělení podnikových informačních systémů Systémová integrace Životní cyklus projektu Metody vývoje informačních systémů Metoda tunel Metoda vodopád Integrace informací a systémů Integrační přístupy Enterprise Information Integration Enterprise Application Integration Servisně orientované přístupy Nástroje integrace dat a systémů Datové sklady Virtuální databáze Servisně orientovaná architektura Softwarové architektury Koncept servisně orientované architektury Rozhraní SOA služeb Základní pilíře architektury SOA Referenční model SOA Zhodnocení technologie SOA Webové služby Struktura webové služby SOAP WSDL UDDI Zhodnocení webových služeb Modelovací jazyky a technologie SOA UML BPEL BPMN BPML WS-BPEL Integrace aplikací pomocí BPEL DSL ebxml

9 6.5.9 XML Enterprise Service Bus Vývoj integračních řešení Analýza a návrh systému pro správu nemovitostí Požadavky na modelovaný systém: Výsledek původní analýzy Popis externích systémů Popis uživatelů Use Case model - model případů užití Textové specifikace případů užití Modely integrace IS s externími systémy Integrace pomocí webových služeb BPEL integrace Návrh fyzické implementace modelovaného systému Fyzická architektura Aplikační server Databázový server Další technologie Další požadavky Závěr Použitá literatura

10 2 Úvod V posledních několika letech dochází k ohromnému rozvoji informačních a komunikačních technologií. To přináší i změny v komunikaci mezi lidmi. Vzdálenosti mezi nimi se zkracují, komunikace je snadnější a v mnoha případech dostává zcela nové rozměry. Význam a potřeba informací se neustále zvyšuje. Informační technologie umožňují informace získávat rychleji, efektivněji, levněji. Jejich zpracování je možné v daleko větším objemu. Informace se stávají cenným aktivem a schopnost s nimi efektivně nakládat se stala nezbytnou. Informace je třeba mít bezpečně uložené a v případě potřeby rychle dostupné ve formě, která je právě potřebná. Základním nástrojem pro tuto činnost jsou informační systémy. Ty jsou dnes využívány ve všech moderních podnicích a organizacích k organizaci času, práce, vedení nejrůznějších agend. Poskytují potřebné informace všem úrovním řízení podniku, usnadňují práci zaměstnancům. Informační systém organizace má nemalý vliv na pracovní procesy a organizační strukturu. Kvalita informačního systému je jedním ze základních faktorů ovlivňujících úspěšnost organizace v konkurenčním boji [1]. Současné velmi dynamické prostředí vyžaduje neustálé zvyšování produktivity práce ruku v ruce se zvyšováním její kvality, a to při konstantních nebo dokonce nižších nákladech. Je třeba zajistit rychlou reakci na měnící se podmínky na trhu, a proto roste potřeba správných a přesných informací. Informační systém je tedy třeba považovat za nezbytnou součást každé ekonomicky fungující společnosti. Každý informační systém má svoji strukturu a poskytuje podporu pro konkrétní specifickou činnost organizace. Některé činnosti jsou v organizacích podobné, např. vedení ekonomických agend apod., a lze je podpořit nasazením již existujícího informačního systému či jeho modulu. Jsou však činnosti, které jsou pro danou organizaci natolik specifické, že je třeba pro jejich podporu vyvinout zcela nový informační systém nebo jeho část. Tato cesta se může zdát neefektivní, riskantní a samozřejmě nákladnější, než pořízení již existujícího systému. Přináší však jednu velmi velkou výhodu a tou je, že informační systém podporuje přesně ty procesy, které v organizace probíhají. Tyto jsou v mnoha případech právě tím, co přináší podniku konkurenční výhodu oproti ostatním subjektům na trhu. Podnik nepřizpůsobuje svou činnost funkcionalitě pořízeného informačního systému, ale naopak informační systém využije k podpoře již zaběhlých činností. Struktura informačního systému je dána prvky a vazbami mezi nimi. Vazby jsou reprezentovány informacemi a prvky jsou procesy, které transformují vstupní informace na výstupní [2]. Vzájemná interakce prvků, tj. předávání a zpracovávání informací, se nazývá chování informačního systému. Před implementací informačního systému je tedy třeba analyzovat procesy probíhající v organizaci a zmapovat toky informací. Aby bylo možné toto učinit, je třeba zmapovat prostředí organizace a zjistit, jaké jsou její požadavky, co jednotliví zaměstnanci od informačního systému očekávají. Na základě těchto poznatků je možné navrhnout celistvý model, který dává přehled jak o struktuře budoucího systému tak o jeho chování. Na základě takto navrženého modelu je možné přistoupit k implementaci informačního systému programovými prostředky[6]. 10

11 Stupeň informatizace podniků se neustále zvyšuje. Podniky informatizují stále větší množství agend. Na trhu neexistuje žádný informační systém, který by pokrýval komplexně všechny agendy podniků. Může být nasazen systém s mnoha moduly, který pokrývá velké množství oblastí, ale nikdy nebude pokrývat všechny. Podnik se může s tímto stavem spokojit, nebo se může rozhodnout nasadit další informační systémy. Podniky od určité velikosti vždy přistoupí k druhé možnosti, protože informační podpora jim v dané oblasti přináší větší efektivnost a s tím spojenou úsporu nákladů. Pokud se podnik rozhodne provozovat více informačních systémů, musí se také rozhodnout, zda bude shodná data používaná ve více systémech udržovat duplicitně, nebo přistoupí k integraci dat mezi těmito systémy. Duplicitní evidence je náchylná k zanášení chyb, ale především neefektivní. O možných způsobech integrace IS pojednává tato diplomová práce. 11

12 3 Cíl práce Cílem diplomové práce je zmapovat možnosti integrace informačních systémů. Práce se zaměřuje především na integraci informačních systémů pomocí technologie SOA a webových služeb. Mapuje možnosti servisně orientované architektury v praxi, popisuje jazyky a standardy které tento přístup podporují. Podrobněji se věnuje standardu BPEL, u kterého se snaží najít praktické uplatnění při analýze a návrhu systémů. Na základě popsaných technologií je v závěru práce zpracována analýza a návrh integrace jednoduchého modelového informačního systému. 12

13 4 Definice pojmů Pro správné pochopení problematiky integrace informačních systémů je vhodné vysvětlit základní pojmy, které se budou vyskytovat v dalších částech práce. 4.1 Informační systém Základním pojmem, který je třeba osvětlit je informační systém. Ten lze definovat následovně: Informační systém je uspořádaný systém prvků a činností spolu s jejich vlastnostmi a vztahy, který transformací dat vytváří informace pro uživatele. Informační systém představuje uspořádaný souhrn lidí, technických prostředků a metod zabezpečujících sběr, přenos, uchování a zpracování dat za účelem tvorby a prezentace informací pro potřeby uživatelů, činný v systémech řízení [4]. Informační systém je systém sběru, uchovávání, analýzy a prezentace dat určený pro poskytování informací uživatelům [3]. Informační systém je široký komplex lidí, informací, vlastního systému řízení, technických prostředků a systému organizace práce uživatele v příslušné oblasti. Účelem celého komplexu je sběr, přenos, aktualizace, uchování a další zpracování dat za účelem tvorby a prezentace informací, které by měly zlepšit výkonnost uživatelů. Informační systém je systém definovaný množinou prvků a vazeb mezi nimi a vymezuje určitou konkrétní část reality. Vazby mezi jednotlivými prvky systému a vazby s okolím (vstupy a výstupy systému) se realizují předáváním informací a dat. Vazby mezi prvky systému jsou reprezentovány informacemi a prvky jsou procesy, které transformují vstupní informace (podněty) na výstupní (reakce). Soubor pravidel transformace tvoří operátor transformace (algoritmus) [5]. Každý informační systém se skládá ze tří částí, kterými jsou: Lidé jedná se o osoby, které vyvíjejí aktivity spojené s informačním systémem či jeho zabezpečením. Data jedná se o data, která jsou předmětem zpracování v informačním systému. Technologické prostředky jedná se o soubor nástrojů, metod a znalostí, které slouží k činnostem, které informační systém plní. Jedná se především o sběr, přenos, prezentaci a uchovávání dat. Z pohledu informačních technologii se jedná např. o SŘBD, operační systém, aplikační servery apod. 13

14 Hlavním cílem informačního systému je poskytovat informace v potřebném rozsahu a patřičném čase především všem úrovním řízení organizace (operativní, taktické, vrcholové). Data potřebná k plnění tohoto úkolu jsou uchovávána jako jedinečná a zpracovávají se zpravidla na vyžádání dle zadaného hlediska. Informační systémy lze rozdělit do dvou skupin, a to na veřejné a interní. Interní informační systém slouží především k interním potřebám subjektu, jenž tento systém provozuje. Veřejný informační systém slouží potřebám i jiných subjektů [5]. 4.2 Podnikové informační systémy Podnikové informační systémy mají za úkol zajistit podporu vybraných procesů podniku. Většinou se snaží řešit problematiku řízení podniku a vedení nezbytných agend. Konkrétně se ve většině případů jedná o řízení výroby, obchodu, vedení účetnictví, správu dokumentů apod. Tyto činnosti nemusí být vždy nutně podporovány nebo řešeny softwarovými nástroji, avšak provoz běžných agend bez užití softwarových nástrojů je v současné době i v menších podnicích téměř nemožný. S tímto přístupem se lze setkat pouze u drobných podnikatelů a živnostníků. Podle toho jak velké procento agend je v podniku informatizováno, lze hovořit o stupni informatizace podniku. Velké a střední podniky jsou v dnešní době již na vysokém stupni informatizace. Pro tyto podniky je návratnost investovaných prostředků relativně krátká, hlubší informatizace jim umožňuje pracovat efektivněji a s nižšími náklady. U malých organizací se lze často setkat jen s částečnou integrací softwarových nástrojů do informačního systému podniku. To je většinou důsledkem obav budoucích uživatelů z nasazení nového IS nebo rozšíření stávajícího IS na novou skupinu uživatelů, popřípadě obav managementu o efektivnost vynaložených prostředků na realizaci informační podpory dalších podnikových procesů (BPR) Dělení podnikových informačních systémů Primárním cílem každého podniků je generovat zisk. Podle toho jak je podnik zaměřen toho může dosáhnout výrobou určitých produktů, které nabízí na trhu, popřípadě poskytováním určitých služeb. Zvýšení zisku lze dosáhnout také snížením nákladů k čemuž významně přispívá optimalizace podnikových procesů. Informační systémy mají za úkol zajistit podporu všech těchto procesů. Jednotlivé podnikové procesy lze zařadit do skupin podle typu činnosti, jejich informační podporu pak následně zajišťují následující primární (někdy též označované jako transakční) systémy. 14

15 Definuje tyto primární systémy [2]: Systémy na podporu vztahů se zákazníky - Customer Relationship Management (CRM), systém určený pro maximalizaci spokojenosti a zajištění loajality zákazníků ke společnosti. Systémy pro plánování podnikových zdrojů - Enterprise Ressource Planning (ERP), systém určený k podpoře řízení a koordinaci všech dostupných podnikových zdrojů a probíhajících aktivit mající za cíl zajištění potřeb trhu a primárních potřeb podniku. ERP systémy pokrývají všechny základní oblasti podnikového řízení: prodej, nákup, finanční účetnictví, controlling, sklady, majetek, mzdy, technickou přípravu výroby, plánování výroby a lidské zdroje. Zajišťují též podporu operativnímu řízení výroby v podniku. Systémy pro řízení dodavatelského řetězce (SCM), zajišťují podporu řízení všech procesů v rámci dodavatelského řetězce, což zahrnuje zajištění surovin, zhotovení produktu a jejich dodávku spotřebiteli. Tyto procesy se integrují na bázi informačních a komunikačních technologií a zahrnují činnosti uvnitř i vně podniku. Mezi další části podnikových systémů se řadí například systémy pro řízení podnikové dokumentace (DMS), systémy pro řízení managementu jakosti (QMS), systém enviromentálního managementu (EMS), ale i informační systémy odběratelů, dodavatelů státní správy a další. Pro potřeby efektivního řízení podniky často implementují také informační systémy pro podporu podnikového managementu. Úkolem těchto systémů je nabízet transformovaná data z několika samostatných informačních systémů nebo modulů IS a zajistit tak efektivní řízení společnosti. Umožňují provádět analýzy výroby, provozu, prodeje, připravovat podklady (sestavy) či objevovat na první pohled ne úplně zřejmé souvislosti. 4.3 Systémová integrace Je komplexní činnost, jenž má za cíl vytvořit informační systém organizace metodou integrace různých produktů a služeb [3]. Jednotlivé produkty pak tvoří komponenty komplexního informačního systému. V drtivé většině organizací je nasazeno několik systémů, které poskytují samostatně podporu v konkrétních oblastech. Některé činnosti v těchto systémech se mohou opakovat, cílem integrace je tyto duplicitní činnosti odhalit a následně eliminovat. Subjekt schopný poskytnout v této oblasti komplexní služby (analýzu, implementaci) nazýváme systémovým integrátorem. Míru provázanosti jednotlivých systémů nazýváme stupeň integrace. S tvorbou a provozem komplexních integrovaných informačních systémů je bohužel spojena i řada rizik. Patří mezi ně vyšší závislost podniku na dodavatelích jednotlivých komponent a služeb, vyšší složitost systému, stoupající nároky na uživatele, větší a rychlejší následky případných výpadků systému. 15

16 4.4 Životní cyklus projektu Tvorba informačního systému je komplexní soubor činností a úloh, které je třeba řešit postupně s určitou návazností. Nezřídka se lze setkat s názorem, že tvorbou informačního systému se rozumí pouze programování. Tato etapa je samozřejmě nezastupitelná, ale její přeceňování se může velmi negativně podepsat na kvalitě výsledného systému. Neméně důležitou etapou, která bývá často podceňována, je detailní analýza a návrh. Jejím výstupem bývá zpravidla pouze dokumentace, pro zadavatele obvykle ne příliš srozumitelná, která u něj nemusí vzbuzovat důvěru. Zadavatel směřuje veškerou svoji pozornost na samotnou implementaci a vše ostatní chápe pouze jako doplňkové činnosti. Součástí analýzy je také sběr a utřídění uživatelských požadavků, což lze považovat za stěžejní fázi. Zůstává totiž paradoxem, že velká skupina uživatelů vlastně přesně neví, co od systému očekává. V průběhu analýzy by se měly tyto nejasnosti ozřejmit, a představy zadavatele a řešitele by se měly dostat do maximální možné shody. Vhodné je zaměřit se na pracovní postupy, které má informační systém podporovat. Je nezbytně nutné konzultovat požadavky kladené na informační systém přímo s uživateli, ovšem je třeba se vyvarovat přístupu, kdy zadavatel od začátku nutí řešiteli své vlastní představy technického provedení. Otázky samotné realizace je vhodné nechat zprvu otevřené a soustředit svoji pozornost na definování požadované funkčnosti informačního systému. Je výhodné analýzu rozšířit směrem k BPR Business Process Reengineering, jehož cílem je zmapování pracovních postupů v organizaci, jejich analýza a přehodnocení za účelem zlepšení vybraných ukazatelů [1]. Lze tím předejít tomu, že nasazení nového informačního systému zakonzervuje nevhodné pracovní postupy, jejichž následná změna je již nákladná a často k ní není vůle. V některých organizacích, které nekladou důraz na správnou analýzu, dochází k nasazení více dílčích systémů, které se pak svoji funkčností překrývají, společně mají větší personální nároky a celkově jsou finančně nákladnější. Jednodušší, z počátku se jevící jako levnější řešení, se může v konečném výsledku výrazně prodražit. Lze předpokládat, že později bude organizace stejně přinucena ke změně podnikových procesů. Klíčovou roli při rozhodování o těchto otázkách hraje management. Výsledný systém ovlivňují dva, často těžko slučitelné, postoje. Zadavatel má co největší snahu snížit náklady a časovou náročnost realizace informačního systému, vyžaduje tedy co nejjednodušší řešení. Oproti tomu řešitel, který by si měl být vědom budoucích rizik, prosazuje důslednější a v konečném důsledku finančně náročnější řešení [3]. Obě strany se mohou chránit důsledně provedenou analýzou a vytvořením katalogu požadavků. Zadavatel tak může přesně kontrolovat plnění dílčích požadavků, zatímco řešitel má jistotu, že od něj nebude požadováno něco, co není v katalogu obsaženo. Obecně lze prohlásit, že kvalita výsledného informačního systému je přímo úměrná množství úsilí věnovaného zpracování uživatelských a systémových požadavků. Odhalení chyby v rané fázi analýzy je ve výsledku mnohonásobně levnější, než pozdější nezbytné úpravy. V dnešní době je zcela obvyklé, že analýza je prováděna jinou firmou než tou, která 16

17 realizuje implementaci. V takovém případě je třeba používat standardních technik a modelů. Po dokončení analýzy zpravidla následuje fáze designu. Na rozdíl od analýzy, kde se úmyslně abstrahuje od konkrétního řešení, je design zaměřen především na rozpracování výsledků analýzy do jednoho partikulárního řešení. Výsledky detailního návrhu mohou být chápány jako přímé podklady pro implementaci. Často používaným prostředkem při designu je prototypování. Jeho úkolem je vytvořit funkční aplikační prostředí, které slouží pro vyjasnění požadavků zadavatele [9]. 4.5 Metody vývoje informačních systémů Z hlediska analýzy vývoje informačních systémů lze vymezit konkrétní metody a přístupy k problematice vývoje informačních systémů z pohledu životního cyklu. Kromě zcela intuitivních metod rozeznáváme dvě poměrně přesně definované metody, které se vyznačují především svou koncepčností. Jelikož vývoj informačního systému je proces, který naplňuje všechny charakteristiky řešení určitého projektu, budu nadále používat tento pojem Metoda tunel Tato metoda vychází z předpokladu, že se spuštěním projektu postupujeme do úplného neznáma do tunelu. Projekt se řídí podle momentální situace, existuje silný tlak na realizaci projektu. Hlavním cílem této metody je identifikovat konec tunelu a projekt k němu zdárně dovést. Projekt tedy není řízen operativně, ale pouze koncepčně. Řešitelé projektu většinou zůstávají angažováni po celou dobu životního cyklu projektu. Z hlediska řízení je projekt řízen průřezově se zaměřením na jednotlivé oblasti úkolů [8]. Pokud chceme metodu hodnotit, dojdeme přibližně k těmto závěrům: zcela chybí koncepce při řešení projektu, není možné projekt opakovat, výsledky jsou velmi netransparentní, vývoj doprovází značný chaos, často vznikají nedodělky, výsledek projektu je často nízké kvality Metoda vodopád Tato metoda vychází z toho, že již samotným projektem je dáno rozdělení na určité části vývoje, které lze dobře definovat a následně řešit samostatně. Řešení těchto částí lze rozdělit do samostatných etap vývoje v konkrétních časových úsecích. Jednotlivé etapy lze vyhodnotit. Výsledky jednotlivých etap vznikají postupně v pořadí: analytické dokumenty, návrhové dokumenty a v poslední fázi vlastní kódování. Jelikož se dokumenty předávají z jedné fáze do druhé odshora dolů, je tato metoda nazývána vodopád [8]. 17

18 5 Integrace informací a systémů Téma integrace informací a informačních systémů lze považovat za další stupeň vývoje informačních systémů. Ve většině podniků se informatizovaly jednotlivé oblasti zcela samostatně a odděleně, většinou v různých obdobích. Představa, že všechny procesy podniku budou mít podporu v jednom informačním systému, se ukázala jako nereálná. Dodavatelé softwaru se specializují na jednotlivé specifické oblasti činnosti podniků. I přesto,že na trhu je několik velkých komplexních produktů, které se snaží nabídnout podporu veškerých činností podniku, není možné očekávat, že jejich produkty pokryjí potřeby všech potencionálních zákazníků. Vždy bude existovat množina procesů, kterou je nutné pokrýt samostatným informačním systémem. Integrace informací uložených v jednotlivých separovaných informačních systémech podniku je v současné době velmi významnou oblastí. Dle průzkumů společnosti Gartner Inc. vynakládají firmy až 40% z rozpočtu ICT na řešení související s integrací informací [11]. Tatáž společnost odhadla, že velikost trhu s nástroji pro integraci dat v roce 2010 bude 2,2 miliardy USD. V porovnání s rokem 2005 se jedná o nárůst trhu o 17,4 % [12]. Důvodů pro zvýšení poptávky po integračních řešeních je několik: vzrůstá počet veřejně přístupných datových zdrojů dostupných prostřednictvím internetu, jejichž informace je možné bezplatně využívat, podnikové systémy jsou budovány jako soustava několika vzájemně provázaných a komunikujících systémů, nikoliv jako jediný velký systém, který řeší veškeré potřeby podniku [13], globální společnosti působící v mnoha zemích světa vyžadují pracovat s informacemi z lokálních poboček [14]. 5.1 Integrační přístupy V oblasti integrace informací rozlišujeme dva základní integrační přístupy: Enterprise Information Integration (EII), Enterprise Application Integration (EAI) Enterprise Information Integration Integrační přístup EII zpřístupňuje uživateli jednotný pohled na informace, které byly získány z různých datových zdrojů. Hlavní myšlenkou EII je dostupnost aktuálních dat přímo v primárních systémech bez nutnosti data nejdříve přenášet do centrálního datového skladu. EII obsahuje nástroje určené k dotazování, nelze pomocí nich provádět žádné modifikace. EII přístup využívají zejména analytické nástroje. Úspěšně je tento 18

19 přístup používán u CRM (customer-relationship management) aplikací, jejichž cílem je zajistit v reálném čase dostupnost komplexních agregovaných informací o zákazníkovi z více dostupných datových zdrojů podniku. Integrační nástroj tak ve své podstatě tvoří prostředníka mezi uživatelem IS a množinou datových zdrojů Enterprise Application Integration Integrační přístup EAI zajišťuje vzájemně propojení již implementovaných aplikací. Tento přístup: 1. umožňuje aplikacím předávat si informace, 2. zpřístupňuje aplikacím datové zdroje, které nejsou přímo propojeny s danými aplikacemi, 3. umožňuje jiným programům vhled do programů či systémů, 4. umožňuje sdílet data mezi odděleními nebo společnostmi [11]. EAI se v širším měřítku používá od konce devadesátých let. Vychází z teoretických základů systémové integrace. Ke změně došlo při pohledu na způsob provázání aplikací. V původním konceptu, označovaném jako point-to-point, bylo nutné vzájemně provázat všechny komunikujících aplikace viz obrázek č. 1. Obrázek č. 1: Point-to-point integrace [15] 19

20 EAI přichází s novým konceptem hub-and-spoke, jež provázání aplikací centralizuje. Je zaveden takzvaný integrační broker, který zajišťuje centrální správu a řízení integračních procesů a zajišťuje také všechnu komunikaci mezi jednotlivými aplikacemi viz obrázek č. 2. Obrázek č. 2: Integrační broker [15] Aplikace s integračním brokerem komunikují prostřednictvím vlastních proprietárních protokolů založených na XML (extensible Mark-up Language) a WSI (Web Services Interoperability). Tím je zajištěna nezávislost na použité platformě. Integraci lze provádět na některé z těchto čtyřech vrstev: prezentační vrstva, business vrstva, funkcionální vrstva, datová vrstva [11]. Tyto vrstvy jsou vzájemně nezávislé a odpovídají jednotlivým vrstvám čtyřvrstvé architektury. Tato architektura vychází ze třívrstvé architektury (datová vrstva, vrstva aplikační logiky, prezentační vrstva), ale aplikační vrstva je rozdělena na vrstvu funkcionální a vrstvu business procesů. Funkcionální vrstva je aplikačně závislá, business vrstva je aplikačně nezávislá. Obecně lze integrovat na libovolné z těchto vrstev viz obrázek č

21 Obrázek č. 3: Schéma čtyřvrstvé architektury [16] Integrační přístup EAI pokrývá dvě nejnižší vrstvy. Datová vrstva je využita v případě výměny nebo synchronizace dat. Přímá komunikace mezi datovou a business vrstvou není možná, je třeba komunikovat prostřednictvím funkcionální vrstvy, která tvoří komunikační rozhranní. 5.2 Servisně orientované přístupy Aplikace lze velmi efektivně integrovat také za použití servisně orientované architektury (SOA). Ta vychází z distribuované architektury a je zaměřena především na znuvupoužitelnost již existujících aplikací. Servisně orientovaná architektura je koncept modulární organizace softwaru využívající služeb. Jednotkou tohoto konceptu je služba. Služba je softwarový celek poskytující jen přesně vymezenou funkcionalitu. Architektura SOA používá volně vázané (loosely coupled) služby k vyřizování požadavků uživatelů a obchodních procesů. Systém postavený na SOA využívá množinu autonomních služeb, kde každá služba pracuje prakticky jako samostatná aplikace. SOA je modulární architektura chápající služby jako moduly. Díky autonomitě služeb je možné za předpokladu, že je dodrženo rozhraní služby, jednoduše změnit implementaci služby bez zásahu do vlastního systému nebo jiných, již implementovaných služeb. Protože SOA není definice implementace, ale koncept, existují různé přístupy, jak implementovat koncept SOA konkrétně. Služba SOA může být reprezentována funkcionalitou, která se volá prostým voláním metody, nebo může být implementována jako služba vzdálená, která se volá přes síť. V současné době se stále více prosazuje implementace vzdálených služeb SOA jako tzv. webových služeb. Webová služba je služba komunikující přes počítačovou síť (například internet) pomocí definovaného protokolu. Výhodou dekompozice systému pomocí webových služeb je možnost běhu služeb na různých strojích, nezávislost na programovacím jazyku, systému a architektuře použitých strojů [17]. 21

22 6 Nástroje integrace dat a systémů 6.1 Datové sklady Datový sklad (Data Warehouse) je podnikový strukturovaný depozitář předmětově orientovaných, vzájemně provázaných, časově neměnných, historických dat používaný na získávání informací a podporu rozhodování [18]. V datovém skladu jsou uložena detailní i agregovaná data. Datový sklad tvoří v podniku jednotnou datovou základnu, kde jsou data udržována v konzistentní a homogenní formě. Datové sklady jsou základem systémů pro podporu manažerského rozhodování. Obrázek č. 4: Datový sklad [20] Základní charakteristiky datových skladů [19]: Orientace na subjekt. Důraz je v datových skladech kladen na jasné vnitřní oddělení funkčních celků; důsledkem této separace je vysoká redundance dat (zvýšené nároky na diskový prostor) Integrovanost informací. V datových skladech jsou uloženy informace z mnoha různých zdrojů a jsou seskupeny podle jejich logického významu. Nízká proměnlivost dat. Data jsou do datových skladů obvykle importována datovou pumpou ve větších dávkách v delších časových intervalech a následně již nejsou dále modifikována. 22

23 Historizace dat. Data jsou v datových skladech obvykle udržována v historické podobě, nikoliv pouze v aktuálním stavu, jak je tomu běžné u provozních IS. To je dáno nutností provádět analýzy zaměřené na vývoj v čase. Datové sklady jsou plněny daty z provozních informačních systémů prostřednictvím ETL nástrojů. Tyto nástroje, které jsou označovány také jako datové pumpy, vykonávají: extrakci dat z provozních informačních systémů, transformaci dat - spočívá v postupném vykonání operací, které extrahovaná data připraví pro vlastní načtení do datového skladu. Jedná se o operace čištění dat, odstraňování duplicitních záznamů, standardizace záznamů, a jiné. loading dat, neboli vlastní plnění fyzických struktur datového skladu transformovanými daty. Kvalita dat datového skladu odpovídá kvalitě ETL procesu. Uvádí se, že vytvoření kvalitní datové pumpy zabere až 70 % z celkového času potřebného na vytvoření datového skladu. Jelikož data jsou v datovém skladu reprezentována zcela odlišným způsobem, než v provozním systému, je transformace dat většinou značně náročnou operací. Data se transformují z entitně-relačního schématu do schématu multidimenzionálního (schéma hvězdy, schéma sněhové vločky). K analýze dat v datovém skladu lze využít OLAP nástroje dostupné ve většině současných SŘBD. 6.2 Virtuální databáze Virtuální databáze poskytují přístup k aktuálním datům z datových zdrojů, čímž odstraňují klíčovou nevýhodu datových skladů. Nepoužívají žádné vlastní interní struktury pro předzpracování dat. Virtuální databáze je ve své podstatě sofistikovaný nástroj, který dokáže rozložit dotazy na dílčí subdotazy, které nechá vyhodnotit jednotlivé datové zdroje. Data, která získá, dokáže složit a následně vrátit jako odpověď na původní dotaz. Aby bylo možné takovéto distribuované dotazy pokládat, musí virtuální databáze znát přesnou strukturu dílčích zdrojů tzn. musí existovat mapování schémat. Virtuální databáze využívá mapování schémat při rozložení dotazu a také při následném slučování získaných dílčích dat. Existují dva základní způsoby mapování schémat: GAV (Global-As-View) - každý element globálního schématu je vyjádřen kombinací elementů lokálních schémat. Tento přístup je výhodný při dotazování - lze jednoduše odvodit všechny potřebné subdotazy na dílčí datové zdroje. Přidání dalšího datového zdroje ale vyžaduje provést úpravu všech stávajících mapování. LAV (Local-As-View) - každý element lokálního schématu je popsán elementy globálního schématu. Přidání nového datového zdroje je v tomto přístupu jednoduché - stačí definovat mapování pro elementy nově přidaného zdroje. Vyhodnocení potřebných dotazů na lokální datové zdroje je složitější. Musí se analyzovat všechny elementy lokálních schémat. 23

24 Obrázek č 5: Virtuální databáze [21] Proces integrace informací využívající virtuální databáze popsat takto [22]: Základní vrstvou této architektury jsou datové zdroje. Komponenty, ze kterých je vybudována vyšší vrstva nad datovými zdroji, jsou nazývány wrappery; ty hrají roli konektoru mezi datovým zdrojem a komponentami virtuální databáze, které se zabývajíintegrací informací. Wrapper zajišťuje získání dat z datového zdroje a úpravu dat do požadované formy. Ke každému datovému zdroji je přiřazen právě jeden wrapper.vlastní integrace dat probíhá v hierarchicky propojených komponentách nazývaných mediátoři. 6.3 Servisně orientovaná architektura Softwarové architektury Softwarová architektura obecně popisuje strukturu jednotlivých softwarových komponent, způsob jejich propojení a vlastností. Postupem času, tak jak se měnil rozsah požadovaných funkcí informačních systémů, měnil se i význam pojmu komponenta. IS v prvních verzích nepřesahovaly hranice podniků a sloužily pouze jako podpora vnitřních procesů podniků. Postupně začalo docházet k pokrytí čím dal větší množiny procesů, došlo k nárůstu velikosti komponent. Za nultou generaci softwarových komponent lze považovat monolitické aplikace. Základním rysem této architektury je zakomponování uživatelského rozhraní, aplikační logiky i správy datových zdrojů do jednoho nedělitelného produktu. Komponentu tvořil 24

25 v podstatě celý systém. Tyto nedynamické systémy byly provozovány na sálových počítačích. Příchod osobních počítačů zapříčil nárůst poptávky po software. Ukázalo se, že softwarová architektura má oproti hardwarové velké rezervy. Rostoucí složitost programů vedla k zavedení dekompozičních přístupů. Monolitické systémy s absencí jakékoliv možnosti znovupoužitelnosti se staly nedostačujícími. Započal přechod použití strukturovaných metod návrhu IS. Za komponentu byl v tomto přístupu považován modul jakožto základní programová jednotka, která je samostatná a rozlišitelná při překladu, při kombinaci s ostatními jednotkami. Moduly si však nadále zachovaly monolitickou vnitřní strukturu. Zcela jiný pohled na komponenty přineslo objektově orientované programování. Modul nadále označovaný jako třída v sobě obsahuje aplikační logiku. Konkrétní instance třídy nazvaná objekt pak v sobě přidává data specifikující stav konkrétního modulu. Tím dochází k oddělení dat a procesní logiky a tedy celkovému odklonu od monolitické architektury. Klasické strukturované programy tvořily seznamy po sobě jdoucích příkazů, které měnily stav konkrétního výpočtu. Objektové programy jsou sadou objektů, tvořících samostatné moduly. Ty mezi sebou komunikují prostřednictvím zasílání zpráv a mění svůj stav v závislosti na této vzájemné komunikaci. Komponenty systému jsou tak mnohem více autonomní. Koncept autonomních komponent založených na posílání zpráv dále rozvíjí komponentové (nebo komponentově-orientované) programování. Komponenta se skládá z několik tříd, které společně poskytují požadovanou funkcionalitu. Důležitým faktorem je existence přesně definovaného komunikačního rozhraní, které umožňuje přístup k implementované funkci modulu i ostatním komponentám v systému. Použití objektové architektury umožňuje vývoj větších robustnějších, ale především znovupoužitelných aplikací. Do systému lze navíc s výhodou integrovat komponent třetích stran čímž lze významně urychlit vývoj systému. Za současný trend v oblasti architektury informačních systémů lze považovat servisně orientovanou architekturu (SOA). Pojem servisně orientovaná architektura je tedy důsledkem přirozené evoluce předchozích architektur, nikoli revolučním konceptem, jak bývá často nesprávně označován. Snaží se přirozeným způsobem zobrazit prvky reálného světa do prostředí informačních technologii. Vychází ze způsobu lidského myšlení, kdy je kombinována procesní logika s vlastními daty. Jedna komponenta zpravidla reprezentuje jednu reálnou entitu, je v ní zapouzdřeno větší množství kódu. Komponenty jsou následně výrazně lépe znovupoužitelné Koncept servisně orientované architektury SOA (Service Oriented Architecture) lze chápat jako abstraktní koncept, který určuje jak propojit a integrovat moduly, aplikace i celé systémy dohromady. Je postaven na technologiích implementovaných v XML a nejčastěji na webových službách. Rozdíl mezi SOA webovou službou je ten, že SOA nedefinuje konkrétní způsob komunikace spolupracujících služeb, ale pouze popisuje, jak se mohou vzájemně dorozumět. Webovéslužby (WS, Web Wervices) mají naopak přesně určená pravidla vzájemné 25

26 komunikace, např. jakým způsobem si mohou posílat zprávy (technologie SOAP).Dalo by se říci, že webové služby jsou podmnožinou SOA, respektive až pozdější implementací technologie SOA. SOA nemusí být implementována povinně pomocí Web Services, ale právě popularita Web services stojí i za současnou oblibou SOA. Největší výhodou WS je, že se jedná o otevřený standard, který mohou využít všichni vývojáři systémů bez omezení. Existují samozřejmě i jiné standardy jako například WS-Reliability, WS-Transaction, WS- Security (tyto technologie jsou odvozeny od klasických webových služeb a jsou souhrnně označovány jako WS-*), které lze využít s obdobným výsledkem [23]. Webové služby netvoří povinný základ implementace SOA a jsou pouze jedním z možných implementačních schémat.alternativou může být například technologie ESB (Enterprise Service Bus podniková sběrnice služeb). SOA lze tedy nazvat obecným modelem, který propojuje různé funkční jednotky aplikace nazývané služby (nejedná se však o webové služby). Propojení je realizováno přes jasně definované rozhranní. Službou může být objekt, sada objektů, proces složený z více objektů nebo skupina procesů mající jeden jediný výstup. Navenek se služba tváří jako jedna entita, ale uvnitř může být velice komplexní. Rozhraní služeb jsou definována zcela nezávislým a neutrálním způsobem. Rozhraní není závislé na konkrétní hardwarové platformě či operačním systému. Nezáleží na tom, ve kterém programovacím jazyce je služba napsána. Tím je zajištěna schopnost všestranné spolupráce služeb vytvořených různými dodavateli. Možnost univerzální definice rozhraní, které je nezávislé na konkrétní implementaci služby je rys, který je nazýván volná vazba služeb. Jeho největší výhodou je vysoká pružnost v reakci na změny a možnost přizpůsobit se případným změnám ve struktuře a implementaci služeb. Ani v tomto není technologie SOA žádnou novinkou. Velice podobný princip komunikace objektů přes jasně definovaná rozhraní byl navržen už v architektuře CORBA (CommonObject Request Broker Architecture) Rozhraní SOA služeb Rozhraní služby musí splňovat několik následujících kritérií: Nezávislost na platformě - služba neklade na klienta žádné nároky na způsob implementace, tím je dosaženo interoperability služby. Služba může být využita v rozdílných prostředích. Skrytá implementace - služba přísně dodržuje zapouzdření. To umožňuje změnit implementaci průběhu života služby bez dopadu na klienta. Zdokumentované rozhranní - dokumentace je jediným popisem služby, který má konzument k dispozici a podle něj se musí také striktně řídit. Rozhraní služeb v rámci SOA je zpravidla specifikováno prostřednictvím jazyka 26

27 WSDL (Web Services Definition Language). Ten je založen na XML formátu, což významně přispívá k jeho nezávislosti na programovacím jazyku. Popis rozhraní je jen jednou ze součástí SOA architektury. Mimo něj musí být znám popis funkčnosti aplikace tj. charakteristika workflow jednotlivých služeb, které aplikace využívá. Workflow dynamického procesu může obsahovat operace mezi jednotlivými aplikacemi v rámci jednoho informačního systému, ale i spolupráci s komponentami externích informačních systémů. Pro popis workflow mezi jednotlivými službami a procesy byl navržen speciální jazyk označovaný zkratkou BPEL ze slov Business Process Execution Language. V některých případech se lze setkat s označením BPEL4WS nebo WSBPEL, což jsou rozšíření,,čistého" BPEL [24] Základní pilíře architektury SOA Jak již bylo výše uvedeno, architektura SOA je pouhou evolucí předchozích distribuovaných architektur jako jsou CORBA nebo DCOM. SOA stojí dnes na následujících pilířích: služby jsou volně vázané (loosely coupled), služby mají hrubozrnné (coarse grained) aplikační programovací rozhraní API, komunikace mezi službami je typicky asynchronní (asynchronous communications), důsledně se využívají oborové standardy (standard based), služby jsou znovupoužitelné (service reuse) - na znuvupoužitelnost se nahlíží jako na žádoucí vedlejší efekt (nikoli cíl) potvrzující dobrou implementaci SOA principů, metadata služeb jsou uložena v úložišti (metadata repository) [25]. Obrázek č. 6: Základních pilíře SOA architektury [25] 27

28 Oborové standardy Architektura SOA v široké míře využívá především otevřených standardů (XML, SOAP, WSDL, HTTP). S rozmachem využití této architektury postupně přicházely nové specifické standardy, které zjednodušily využití webových služeb v praxi (např. WSReliableMessaging, WS-Addressing, WS-Security a atd.). Ty dále rozšiřují syntaxi původního WSDL. WS však naráží v podnikové praxi na určitá omezení dané informační infrastrukturou podniku. Využití základních prvku Web Services (SOAP, HTTP, WSDL) je bez potřebné infrastruktury omezené. Bez úložiště pro metadata webových služeb, bez nástrojů pro správu a monitorování, logování nebo archivaci nemohou WS dojít zamýšleného komplexního využití. WS jsou postaveny na zpracování požadavků typu klient/server se všemi jeho nevýhodami.vzhledem k tomu, že v současné době panuje značně chaotická situace okolo vývoje jednotlivých WS-* standardů, může implementace těchto specifikací trh SOA produktů v budoucnu ještě více rozdělit [25]. Obrázek č. 7: Přehled standardů využívaných technologií SOA [27] Úložiště metadat služeb Kvalitní úložiště metadat je nepostradatelná součást celého konceptu SOA. Veškeré služby, a to jak ve fázi vývoje, testování, tak především v následném ostrém provozu, musí být dokumentovány v konkrétním dostupném persistentním úložišti. 28

29 V úložišti jsou následně o službě dostupná tato metadata: formální popis, metadata rozhraní služeb, formální popis, křížové reference, příslušné verze služby, další informace potřebné pro vývoj, nasazení, správu a měření služeb. Pod pojmem úložiště se nemusí nutně skrývat sklad webových služeb (UDDI registry). Každý z poskytovatelů WS nebo ESB řeší úložiště metadat služeb ve vlastní režii, svým specifickým způsobem. Jejich funkcionalita se může značně lišit. Může se jednat pouze o adresářové struktury, vnořené relační, objektové či XML databáze nebo samotné UDDI registry, se kterými se funkcionalita úložiště může překrývat [25]. Znuvupoužitelnost Cílem dobře navrženého systému na architektuře SOA je minimalizace potřebných služeb. Efektivnost systému se zvyšuje s počtem dalších aplikací, které jeho služby využívají. Znuvupoužitelnost je výsledkem dobře navržené architektury systému, jde o principiální záležitost. Nelze jí docílit spoléháním se na skutečnost, že ve firmě bude postupně více aplikací využívajících funkčnost dané služby. Je třeba si však uvědomit, že i v dobře navržených SOA systémech lze obtížně docílit větší znuvupoužitelnosti než 30 až 40 %. Některé služby budou vždy patřit jen jedné aplikační doméně či aplikaci. [23]. Slabá vazba (loose coupling) aplikací Princip slabé vazby spočívá v tom, že pokud aplikace nabízí službu, mělo by druhé straně k jejímu využití stačit znát několik základních informací. Ty jsou dostupné v úložišti metadat. Výhodou je, že pokud dojde ke změně služby nebo rozhranní, přes které je využívána, není nutné na straně příjemce dělat žádné změny. Služby jsou volně vázané (loosely coupled). Pro vývoj služeb se využívá hrubozrnné (coarse grained) aplikační programovací rozhraní API. Služby mezi sebou komunikuji typicky asynchronně (asynchronous communications).důsledně využívají oborové standardy (standard based). Služby jsou implementovány tak, aby byly znovupoužitelné (service reuse). Na znuvupoužitelnost se nahlíží jako na žádoucí vedlejší efekt (nikoli cíl) potvrzující dobrou implementaci SOA principů. Metadata služeb jsou uložena v úložišti (metadata repository) [30]. 29

30 6.3.5 Referenční model SOA Najít obecný implementačně nezávislý referenční model architektury SOA je obtížné. Softwaroví dodavatelé příliš nedbají obecnost a nezávislost. Jedním z vhodných příkladů může být referenční model vytvořený nezávislou analytickou firmou CBDI Forum (viz obrázek 8.). Obrázek 8. Referenční model architektury SOA podle CBDI Forum [25] U takto zachycených modelů je nutné si uvědomit, že vrstvy služeb, aplikací a technologií představují oddělené fyzické vrstvy. Oproti tomu vrstva obchodních procesů představuje konceptuální vrstvu. V těchto schématech většinou chybí zachycení úložiště metadat a zobrazení celkového řízení této architektury. Po doplnění těchto faktorů by model mohl vypadat podobně jako na obrázku číslo 9. 30

31 Obrázek č. 9 :Referenční model architektury SOA se zdůrazněním úlohy úložiště metadat a úlohy řízení této architektury [26] Zhodnocení technologie SOA Systémy využívající technologii SOA mohou rychleji reagovat na změny reálného světa. Snadnou reorganizací jejich služeb lze získat novou funkcionalitu bez jakékoliv implementace tj. bez dodatečných nákladů. Již implementované komponenty lze jednoduše nahrazovat novými a to i za běhu systému. Za pomoci hrubých rozhraní a distribuce problému se lze efektivněji vypořádat s rozsahem velkých systémů. Kladně lze hodnotit také použití již existujících systémů při přechodu na SOA, respektive při vývoji nových aplikací. Vystavením existující aplikace jakožto služby je docíleno efektivní využití vložených investic, dochází k intenzivnějšímu využití aplikace. Výrazným důsledkem je i přínos SOA v oblasti přirozené integrace - mnoho existujících systémů díky navázání na další datové zdroje dosáhne lepších výsledků a delší životnosti. Lze konstatovat, že správnou implementací SOA je možné: snížit náklady jak na vývoj, tak na integraci aplikací, díky znuvupoužitelnosti služeb zefektivnit vývoj a integraci aplikací, rychle a snadno otevřít, zpřístupnit a zhodnotit původní (legacy) aplikace, zprůhlednit správu a řízení informačních systémů, rychle přijmat změny - změna je atributem architektury SOA, ne nečekanou výjimkou, při níž se typicky mění jen metadata, nikoli zdrojové kódy služeb, podnikat v reálném čase pokud je daná společnost na takový způsob práce informačního systému připravena [25]. 31

32 6.4 Webové služby V předchozích kapitolách byla představena servisně orientovaná architektura, jako poměrně abstraktní koncept. Aby bylo možno její využití v reálných systémech je třeba použít konkrétní technologii, která umožní přistupovat k informačním zdrojům jakožto službám za pomocí volání zpráv. Jako vhodné řešení se jeví použití webových služeb. Webové služby jsou dnes považovány za standard v oblasti využití SOA. Drtivá většina nových informačních systému na trhu webové služby podporuje. Nástroje pro vývoj WS dnes dodávají téměř všichni tvůrci nástrojů pro vývoj software v čele s firmami Sun, IBM, a Oracle. K největšímu rozvoji tohoto oboru došlo ale bezesporu po uvedení platformy.net společností Microsoft. Charakteristika webových služeb Webové služby poskytují přístup ke konkrétní funkcionalitě informačního systému standardními prostředky. Přístup je realizován přes web. Webovou službu lze tedy chápat jako samostatný systém komponent, které komunikuji v distribuovaném prostředí pomocí výměny zpráv.obsah zpráv je definován rozhraním mezi poskytovatelem služby a jejím konzumentem. Rozhranní předepisuje komunikační protokol, definuje množinu nabízených operací a jejich parametry. Popisuje také fyzické umístění webové služby. Architektura webových služeb kopíruje koncept naznačený při popisu obecných služeb v prostředí SOA. Základní aktivitou je tedy interakce mezi poskytovatelem služby a konzumentem, který se službou komunikuje výhradně na základě vystaveného rozhraní [16]. Definice rozhraní může konzumentem získat až v době běhu. To zajišťuje vysokou modularitu celého systému webových služeb. Transparentnost umístění Konkrétní umístění implementace webové služby je vždy definováno v rozhraní amůže se v průběhu životního cyklu služby měnit. Konzument tedy musí zohlednit získané data z rozhranní až bezprostředně před navázáním komunikace. Pro dynamičtější řešení je nutné vybudovat komplexnější směrovací infrastrukturu. Nezávislost na konkrétních protokolech Architektura webových služeb nepředepisuje žádné konkrétní protokoly pro přenos zpráv. Na první pohled by se mohlo zdát, že tato volnost přinese velké množství nestandardních řešení. Není tomu tak. Aby byla služba úspěšná, musí být dostupná maximálnímu počtu klientů., už proto se snaží všichni vývojáři používat standardní protokoly. Obvykle se využívá HTTP protokol, který je u serverů poskytujících webový obsah vždy dostupný. Není předepsán ani striktní obsah zpráv. Nejjednodušším požadavkem tak muže být prostý HTTP GET požadavek, který může být případně 32

33 obohacen o patřičné parametry. Standardně se však posílají zprávy ve formátu XML a protokol SOAP. Interoperabilita služeb je zajištěna odstíněním vlastního rozhraní služby od její konkrétní implementace. Fyzickou bránou služby je fasáda realizovaná prostředky příslušného transportního protokolu. Samotná služba je pak ve své podstatě černou skříňkou. Služba jako samostatný modul Modularita webových služeb je dána kombinací zapouzdření funkcionality do černé skříňky přístupné prostřednictvím rozhraní a především strojově zpracovatelným popisem rozhraní služby. Samotné rozhraní obsahuje veškeré potřebné informace pro interakci mezi příjemcem a poskytovatelem. Formálním nástrojem pro popis rozhraní webové služby je WSDL. Dynamické vazby Vazby mezi klientem služby a její konzumentem mohou být značně dynamické. Klient a konzument služby jsou vzájemně nezávislí. Konzument může vyhledat pro něj nejvhodnější službu v registru např. UDDI. Hrubá rozhraní Optimální granularitu rozhraní služeb může systému služeb zaručit pouze kvalitní návrh. Všechny výše popsané vlastnosti lze nalézt i v jiných technologických řešeních např. CORBA (Common Object Request Broker Architecture), RMI (Remote Method Invocation), nebo DCOM (Distributed Component Object Model). Žádné z nich však nepokrývá zmíněné rysy tak široce jako webové služby. Potenciál WS Využití webových služeb má velký přínos hlavně pro podnikovou sféru. Doposud bylo pro podniky velmi obtížné integrovat jednotlivé aplikace, které jsou provozovány v různých systémech a na různých platformách. Doposud používané metody integrace nefungují vždy zcela spolehlivě. Webové služby společně s otevřenými standardy komunikaci mezi aplikacemi značně usnadňují. 33

34 6.4.1 Struktura webové služby Webové služby jsou postaveny nad trojicí základních částí a jejich vzájemné interoperabilitě [31]: Poskytovatel služby (Service Provider) jedná se o softwarovou či hardwarovou platformu, která zajišťuje provoz vlastních webových služeb. Např. MS IIS pro služby vytvořené v technologii.net. Registr služby (Service Registry), jedná se o místo, kde jsou uloženy informace o různých webových službách a jejich poskytovatelích. Potencionální konzumenti v něm mohou vyhledávat různé poskytovatele ale především informace potřebné pro navázání komunikace. Klient (Service Requestor), alias konzument služby, je z obchodního hlediska ten, kdo požaduje funkci, kterou služba poskytuje. Jedná se tedy o aplikaci, která funkci volá. Obrázek č. 10: Struktura webové služby [31] 34

35 6.4.2 SOAP Veškerá komunikace mezi poskytovatelem služby a konzumentem probíhá pomocí XML zpráv. Také komunikace mezi poskytovatelem služeb a registrem služeb probíhá prostřednictvím protokolů postavených nad XML. Zpravidla se jedná o XML-RPC, SOAP a REST (XML-RPC lze považovat za předchůdce SOAP). SOAP je zkratkou pro Simple Object Access Protocol, v současnosti nejrozšířenější protokol pracující na principu vzdáleného volání procedur (RPC). Zprávy jsou formátovány v XML. Poskytovatel služby nabízí konzumentovi množinu funkcí nad zpřístupněnými daty. SOAP definuje základní strukturu XML obálky přenosového rámce a způsob mapování interních datových typů systému do obecné podoby v XML. Vzdálené volání webové služby (funkce) konzumentem pak probíhá jako přenos jednoduché XML zprávy. Ta se obvykle přenáší pomocí HTTP protokolu. Odpovědí na konzumentův požadavek je další XML zpráva obsahující požadovaná data získaná poskytovatelem z vlastních datových zdrojů. Vzhledem ke standardizaci je možné na specializovaných webových serverech najít několik různých knihoven pro snadnou implementaci jak klienta, tak i serveru [33]. Příklad SOAP požadavku [34]: POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockprice> <m:stockname>ibm</m:stockname> </m:getstockprice> </soap:body> </soap:envelope> Příklad SOAP odpovědi [34]: HTTP/ OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockpriceresponse> <m:price>34.5</m:price> 35

36 </m:getstockpriceresponse> </soap:body> </soap:envelope> WSDL Popis služby nám dává k dispozici potřebné informace o rozhraní služby. Jedná se o popis komunikace, formátu zpráv, názvů procedur, typů parametrů, vazeb protokolu a dalších. Dnes se k tomuto účelu většinou používá jazyk WSDL (Web Services Description Language), který SOAP využívá pro komunikaci. WSDL je jazykem postaveným nad XML, který slouží pro formální specifikaci webových služeb. Jeho výraznou vlastností, vítanou speciálně v prostředí SOA, je separace abstraktního popisu funkcionality služby od informace o fyzickém umístění konkrétní služby. Tento fakt se výrazně podepisuje na znovupoužitelnosti dokumentů WSDL. Tento jazyk převzala pod svou správu organizace W3C [35]. Příklad popisu služby v jazyku WSDL [36]: <definitions name="helloservice" targetnamespace=" xmlns=" xmlns:soap=" xmlns:tns=" xmlns:xsd=" <message name="sayhellorequest"> <part name="firstname" type="xsd:string"/> </message> <message name="sayhelloresponse"> <part name="greeting" type="xsd:string"/> </message> <porttype name="hello_porttype"> <operation name="sayhello"> <input message="tns:sayhellorequest"/> <output message="tns:sayhelloresponse"/> </operation> </porttype> <binding name="hello_binding" type="tns:hello_porttype"> <soap:binding style="rpc" transport=" <operation name="sayhello"> <soap:operation soapaction="sayhello"/> <input> <soap:body encodingstyle=" namespace="urn:examples:helloservice" use="encoded"/> 36

37 </input> <output> <soap:body encodingstyle=" namespace="urn:examples:helloservice" use="encoded"/> </output> </operation> </binding> <service name="hello_service"> <documentation>wsdl File for HelloService</documentation> <port binding="tns:hello_binding" name="hello_port"> <soap:address location=" </port> </service> </definitions> Popis služby je sestaven následovně [30]: 1. Základní jednotkou je zpráva reprezentovaná elementem message. Zpráva je dále rozdělena na části (part), jejichž struktura je detailně popsána formální gramatikou. Nejčastěji je pro tento účel použito XML Schema. 2. Základní jednotkou funkcionality služby je operace reprezentovaná elementem operation. Operace využívá definovaných zpráv ke specifikaci formátu svého vstupu, výstupu, případně chyby. To, v jakém pořadí a s jakou sémantikou jsou zprávy mezi klientem a službou posílány, definuje vzory výměny zpráv (Message Exchange Pattern, zkráceně MEP). Specifikace WSDL 2.0 obsahuje tři předdefinované: In-Only s právě jednou vstupní zprávou, Robust In-Only s jednou vstupní a volitelnou výstupní chybovou zprávou a In-Out s jednou vstupní a jednou výstupní zprávou, která může být korektním výstupem nebo chybovou zprávou. 3. Logicky související operace seskupuje rozhraní. Ve WSDL 1.1 je reprezentováno elementem porttype, ve verzi 2.0 elementem interface. 4. Vazba (element binding) přiřazuje dříve zadefinovaným rozhraním konkrétní komunikační protokol. Je zde tedy patrná znovupoužitelnost abstraktně definovaného rozhraní, které lze elegantně zpřístupnit prostřednictvím více konkrétních protokolů. Masově používanými jsou SOAP, HTTP a MIME. Brána (ve verzi 1.1 port, v 2.0 endpoint) asociuje příslušnou vazbu s konkrétní adresou, obvykle ve formě URL, jež službu zpřístupňuje UDDI Pro vyhledání konkrétní požadované služby se běžně používá registr webových služeb. Tam poskytovatel vloží její adresu a přesný popis ve formátu WSDL. Nejčastěji bývá implementováno pomocí UDDI (Universal Description, Discovery and Integration). 37

38 Jedná se o otevřený obchodní registr založený na XML. Nabízí seznam služeb a kontaktů, ve kterých je možno vyhledávat a podrobný popis dostupných webových služeb. UDDI tak poskytuje konzumentovi možnost automatického nalezení požadované služby - poskytovatele. Komunikace klienta s registrem služeb (UDDI) dává konzumentovi potřebné informace o jednotlivých poskytovatelích webových služeb, resp. samotných webových službách a jejich možném využití [35]. Obrázek č. 11: Struktura komunikace s UDDI adresářem [37] Zhodnocení webových služeb Pojem webová služba je velmi často zaměňován s pojmem webová aplikace.webová aplikace umožňuje interakci člověka se strojem. Jako příklad může posloužit třeba internetový zpravodajský server, na němž si čtenář může pročítat nejnovější zprávy ze světa. Webová služba umožňuje interakci stroje se strojem. Komunikují spolu dva stroje na základě standardizovaného protokolu. Jako příklad může posloužit , ten musí cestou k adresátovi projít přes řadu serverů, které spolu právě tímto způsobem komunikují [38]. Z objektivního hlediska je nutné také popsat omezení webových služeb, které se týkají především WSDL a UDDI. Mezi podstatná omezení WSDL specifikace patří: chybějící oddělení privátní a veřejné části rozhraní služby, chybějící podpora transakcí, chybějící podpora workflow (procesy), neřešené otázky zabezpečení a error handling [39]. 38

39 Mezi podstatná omezení UDDI specifikace patří: centralizovaný přístup, který nereflektuje distribuované prostředí internetu a který se vyznačuje všemi problémy, jenž má jakákoli centralizovaná správa (problém při poruše, odstavení,...), problematická důvěryhodnost centrálního registru a vyhledané služby, nemožnost automatického vyhledávání a vyhodnocování relevance a kvalityposkytovaných služeb softwarovými agenty [39]. Za nejzávažnější jsou považovány problémy spojené s centrální správou bezpečností a důvěryhodností. I přes tato úskalí je technologie webových služeb značně oblíbená a v široké míře využívaná. Bohužel často dochází k tomu, že vývojáři často obchází tyto problémy tím, že jimi implementované webové služby nevystaví jako veřejné v UDDI registru. Díky tomu sice vyřeší problémy s centrální správou webových služeb, ale již neposkytnou tyto služby veřejnosti, čímž popřou samotnou podstatu webových služeb. Před příchodem webových služeb a architektury SOA byla integracepodnikových aplikací velmi nákladnou záležitostí. Vždy bylo potřeba specifikovat podnikový standard, podle kterého se integrace řídila. Bylo třeba vybudovat společný datový slovník, definovat přenosové protokoly atd. Výsledkem pokusů o integraci aplikací bylo v mnoha případech vytvoření tzv. špagetového efektu, kdy se aplikace integrovaly vzájemně nepřímo a s velkým množstvím n:m propojení [40]. Obrázek č. 12: Špagetový efekt při nevhodné integraci aplikací [24] 39

40 Způsob takové integrace však přináší velké problémy pokaždé, když se jeden z integrovaných systémů změní. K tomu v praxi dochází velmi často, neboť svět není statický,neustále se mění a informační systémy na to musí reagovat. Architektura zaměřená na služby spolu s webovými službami přináší jednotný a standardizovaný komunikační protokol a popis aplikačního rozhraní. Díky webovým službám a jejich rozšíření je implementace integračního prostředí velmi rychlá a nabízí otevřenou architekturu založenou na standardech. Při integraci aplikací pomocí webových služeb vzniká společný datový model, do kterého všechny aplikace konvertují svá data. Při jakékoli změně jednoho systému se tak nyní nemusí měnit komunikace se všemi ostatními systémy, ale pouze změníme způsob komunikace u měněného systému [40]. Pokud tedy chceme jednotlivé systémy či aplikace integrovat pomocí webových služeb, je třeba striktně využívat standardní protokoly a mechanismy, zejména pak protokoly SOAP, WSDL a UDDI. Obrázek č. 13: Integrace aplikací pomocí SOA [24] Komerčních společnosti dnes zpravidla neintegrují aplikace a systémy čistě pomocí webových služeb jako celku ale například jen za pomoci nadefinování standardů SOAP a WSDL. To znamená, že vyvinuté služby nejsou následně zveřejněné v UDDI registru. Tento způsob integrace není přesně podle komplexní specifikace webových služeb, nicméně si zachovává všechny výhody a přínosy této technologie. Důvodem je především to, že podniky nechtějí zveřejňovat data, která mezi jednotlivými interními systémy proudí. 40

41 6.5 Modelovací jazyky a technologie SOA Jak již bylo v předchozím textu uvedeno, je správný návrh aplikace SOA základním předpokladem pro její efektivní využití. Existuje velké množství modelovacích jazyků, které nabízejí podporu pro analýzu a návrh aplikací využívajících webové služby. Některé z nich si představíme v této kapitole UML UML (Unified Modeling Language) je dnes zřejmě nejrozšířenější modelovací nástroj pro návrh informačních systémů. Byl vytvořen společností Rational Software a postupem času se z něj stal všeobecně přijímaný standard pro vizuální modelování. Nyní jej spravuje Object Management Group ( Jedná se o grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů, který podporuje objektově orientovaný přístup k analýze a návrhu. UML nabízí standardní způsob zápisu návrhů systému včetně konceptuálních prvků jako jsou business procesy a systémové funkce. Zahrnuje také podporu příkazů programovacích jazyků, databázová schémata různých SŘBD i znovupoužitelné programové komponenty. V praxi se používá mnoho metodik vycházejících z modelovacích možností UML. K těmto patří například metodika Select Perspective firmy Select Business Solution, kterou na českém trhu uplatňuje firma LBMS, s.r.o, nebo metodika Rational Unified Process (RUP), která byla vyvinuta společností Rational Software. V současné době je aktuální specifikace UML ve verzi 2. Jelikož je používání UML velmi rozšířené, existuje řada produktů, které podporují modelování založené na tomto standardu. Mezi nejznámější a nejrozšířenější patří: Rational Rose od firmy IBM Together Designer od firmy Borland Enterprise Architect od firmy Sparx Systems ARTiSAN Studio od firmy ARTiSAN Software Visual Paradigm for UML od firmy Visual paradigm a další např. Agro UML, Magic Draw UML. Na trhu jsou kromě komerčních produktů také volně dostupné (open source) produkty, které však ve většině případů poskytují jen omezenou funkčnost nebo omezené množství definovaných diagramů. 41

42 Většina komerčních produktů je dostupná i ve volně dostupné verzi, která poskytuje základní diagramy. Nejrozsáhlejší a tím většinou i nejdražší enterprise verze poskytují všechny typy diagramů a další užitečné funkce jako třeba možnost předgenerování kódu. Podporu UML lze nalézt i v podobě rozšíření (pluginů) pro některá vývojových prostředí jako například pro Visual Studio, Elipse nebo NetBeans. Jedná se ve většině případů o podporu základních funkcí, které pro jednoduché modelování dostačují. UML podporuje velice široké spektrum technik analýzy a návrhu, ale není prakticky možné, aby bylo plně dostačujícím standardem pokrývajícím modelování všech známých oblastí. Pro účely modelování specifických oblastí je tedy třeba standardní UML přizpůsobit. K tomuto účelu slouží UML profily, které představují rozšíření klasického UML. Tím zjednodušují návrh v dané oblasti. Existuje již celá řada profilů a předpokládá jejich další rozšiřování. Vzhledem k tomuto rozvoji je nezbytné, aby celý vývoj profilů byl koordinován centrální autoritou. Tou je v tomto případě Object Management Group ( Pro potřeby modelovaní aplikací s podporou SOA technologií byl vytvořen profil Enterprise Application Integration (EAI). Ten však nebyl vytvořen pouze za tímto účelem, nepodporuje pouze samotnou SOA technologii a z tohoto důvodu není ideálním řešením BPEL Častým tématem posledních let a výzvou pro mnoho firem se stala implementace procesního řízení. Business process management, Business process (re)engeneering, Business process improvement a s nimi spojená témata, jako jsou podnikové architektury, modelovací a exekutivní jazyky, grafické notace, softwarové nástroje, metodiky a mnoho dalších souvisejících oblastí se stále vyvíjejí a jsou předmětem zájmu a diskuzí jak komerčních společností, tak standardizačních institucí [24]. BPEL (Business Process Execution Language) je jazyk, který umožňuje organizovat existující služby do větších bloků. Jeho cílem je definovat itinerář toku zpráv těmito bloky. Tato činnost je někdy označována jako vytváření choreografie služeb. Nabízí prostředky pro sériové a paralelní provádění jednotlivých služeb, podporuje větvení závislé na obsahu zpráv. Proces jazyka BPEL je fyzicky zachycen prostřednictvím XML souboru, který je vykonavatelný v jednotce zvané BPEL engine. V modelu struktury SOA je BPEL implementací elementu business proces [42]. Popis BPEL Webové procesy mají za úkol popsat, jak jsou propojeny jednotlivé webové služby. Nezáleží přitom na tom, kde je daná služba umístěna a jak je implementována, tedy jestli jde o interní vnitropodnikovou nebo externí službu. Tyto vztahy je třeba modelovat vhodnými prostředky, které jsou z abstraktního hlediska BPEL nadřazeny.jejich použití je zpravidla základní podmínkou pro vytvoření použitelné a efektivní aplikace. BPEL definuje na úrovni exekutivního jazyka jak mají být webové služby kombinovány a uspořádány do rozsáhlejších business procesů. S jeho pomocí mohou analytici a 42

43 systémoví integrátoři modelovat jak proudí informace mezi jednotlivými webovými službami v rámci modelovaných webových procesů. BPEL byl předložen ke standardizaci skupinou firem v čele se společnostmi IBM a Microsoft. V současné době rozvoj tohoto standardu podléhá konsorciu OASIS. BPEL umožňuje definovat procesy na dvou úrovních abstrakce: abstraktní proces: popisuje proces bez zbytečných detailů, zabývá se především určením očekávaných protokolů a z vnějšku viditelného chování procesu, exekutivní proces: jedná se o plně detailizovanou a spustitelnou specifikaci procesu [24]. Definice abstraktních i exekutivních procesů obsahuje především: uspořádání aktivit procesu s důrazem na interakce webových služeb, specifikaci zasílaných zpráv a vazeb mezi instancemi procesů, ošetření výjimek a chybových stavů, definice vztahů, založených na webových službách, mezi účastníky procesu [42]. Jazyk BPEL je založen na formátu XML a vychází ze standardů jako je WSDL 1.1, XML Schema 1.0 a XPath 1.0. Nejtěsněji je svázán s jazykem WSDL. Procesní model vytvořený v jazyku BPEL funguje jako další vrstva nadřazena modelu služeb, který je definován standardem WSDL 1.1 Obrázek č. 13: Vrstvy webových služeb [43] Základem modelů v jazyce BPEL jsou webové služby specifikované pomocí WSDL. BPEL pak slouží k mapování a koordinaci interakcí mezi instancemi konkrétních webových služeb s dalšími službami. Popisuje jak mají být tyto služby sdruženy do business procesů. K tomu se v BPEL používá ustanovení message exchange protokolů mezi jednotlivými službami a dále pak určením chování a pozice dané služby v rámci 43

44 business procesu. Pro definici procesu se tedy využívá jedna nebo více WSDL služeb. BPEL poskytuje popis chování a interakcí instance daného procesu vůči dalším procesům a zdrojům pomocí rozhraní webových služeb. Velkou výhodou jazyka BPEL je, že samotný skript v něm napsaný může obsahovat volání několika webových služeb současně. Ty jsou následně pomocí BPEL zapouzdřeny a prezentovány jako jediná zcela nová služba, která může být implementací rozsáhlého procesu a mít vlastní rozhraní. K tomu mohou přistupovat další aplikace ať interní nebo externí.. Takto nově vytvořená služba může poté být samostatnou komponentou aplikace. Samotné workflow v rámci každého procesu je pak zajišťováno pomocí BPEL orchestration enginu [24]. Jedná se o engine, který interpretuje a vykonává BPEL kód. Engine koordinuje všechny aktivity procesu a zajišťuje ošetření případných výjimek. Definice procesu v jazyce BPEL se skládá z těchto základních částí: Hlavička procesu - obsahuje název procesu a jeho obecné vlastnosti. Sekce <partnerlinks> - definuje účastníky procesu (zákazník, fakturační odd., odbytové odd., atd.) a jejich role. Tyto informace identifikují funkcionalitu, která je zajišťována procesem a jeho účastníky. Sekce <variables> - definuje datové proměnné používané procesem. Těmi mohou být WSDL messages, XML typy, XML elementy. Proměnné umožňují procesům udržovat stavová data a historii procesu založenou na přijatých a odeslaných zprávách. Sekce <faulthandlers> - tato sekce obsahuje definici aktivit, které musí být provedeny při výskytu chyby v procesu. Nejedná se primárně o ošetření technických, syntaktických a podobných chyb, ale o ošetření stavů (vnitřních i plynoucích z průběhu určité služby), které jsou logickou součástí procesu a které brání jeho dokončení. Průběh procesu - samotná definice daného procesu. V případě vyřízení objednávky jsou obsaženy tři základní aktivity celého procesu, které jsou zpracovávány postupně (tag <sequence>). Zákazníkův požadavek je přijat (tag <receive>), zpracován (tag <flow>) a na závěr je odeslána faktura zpět zákazníkovi (tag <reply>)[24]. Nejčastěji používaným příkladem BPEL kompozice je cestovní kancelář, která pomocí webových služeb zpřístupní své obchodní procesy dalším systémům. Konkrétními procesy jsou pak například aplikace na rezervaci hotelů, letů nebo automobilů v půjčovnách. Tyto služby následně integruje do kompozitní aplikace společně se službami a obchodnímiprocesy svých zákazníků a partnerů. Použitím jazyka BPEL4WS a specifikací WSCoordination a WS-Transaction pro tuto kompozici tak zákazník cestovní kancelářezískává možnost zadat plán své cesty plně elektronicky zástupci cestovní kanceláře.systém pak podle požadavku zákazníka automaticky zajistí vhodný letecký spoj, 44

45 rezervaci hotelu či automobilu (systém postupuje podle nadefinovaných procesů). Jakmile je zpracování plánu cesty dokončeno, může systém potvrdit všechny rezervace zpátky zákazníkovi. Pokud by se jakoukoli činnost nepodařilo úspěšně provést, dokončené úlohy by se automaticky stornovaly a předaly k manuálnímu zpracování.v případě automatické rezervace všech zdrojů je tak patrná úspora a to jak časová, tak i nákladů na manuální vyřízení [30]. Obrázek č. 13: Příklad BPEL procesu [43] 45

46 6.5.3 BPMN Společně s BPEL se k modelování business procesů používá notace BPMN (Business Process Modeling Notation). Jedná se o soubor grafický nástrojů pro kreslení obchodních procesů. BPMN zajišťuje standard vizuálního zpracování procesů do jednotné grafické podoby. Tuto notaci podporují samozřejmě i existující vývojové nástroje, které pak dovolují zapisovat procesy v odpovídající formě. Konkrétně lze zmínit například Together Designer firmy Borland nebo Enterprise Architekt firmy Sparx Systéme. Obrázek č. 13: Příklad modelu diskusního systému v notaci BPMN procesu [45] 46

47 6.5.4 BPML Pokud hovoříme o standardu BPMN, je třeba zmínit také standard BPML (Business Process Modeling Language). Jedná se o meta-jazyk pro modelování obchodních procesů. Jednotlivé procesy jsou při modelování popisovány v jazyce XML. Popisem je vytvářena nezávislá specifikace zkoumaného workflow. Příklad specifikace vidíme na obrázku č. 14. Obrázek č. 14: Příklad procesu popsaného pomocí BPML[45] 47

48 6.5.5 WS-BPEL Postupem času se objevují i další jazyky, které jsou odvozeny od původního BPEL.Jedním z nich je například WS-BPEL, dříve označovaný jako BPEL4WS. Nové pojmenování bylo zvoleno z důvodu asociace s ostatními WS-* standardy. Jedná se v podstatě o rozšíření standardu UML. Toto rozšíření si klade za cíl definování standardu pro použití UML v oblasti webových služeb. Tento standard je stejně jako klasický BPEL spravován organizací OASIS. Příklad WS-BPEL procesu vidíme na obrázku 15. Obrázek č. 15: Příklad modelu procesu v jazyce WS-BEL [46] 48

49 6.5.6 Integrace aplikací pomocí BPEL V této kapitole si popíšeme možnosti jazyka BPEL k integraci různých aplikací. Za pomoci tohoto jazyka vytváříme tzv. kompozitní aplikace. Taková aplikace vznikne propojením několika existujících aplikací. Kompozice probíhá ve dvou fázích, kdy první spočívá ve vývoji samostatných aplikací a druhá v jejich vzájemné integraci. Možnost vývoje aplikací tohoto typu umožnila technologie SOA konkrétně speciálně webové služby. Propojením několika webových služeb vznikají zcela nové obchodní procesy. Ty jsou popsány právě jazykem BPEL. Oddělením vývoje aplikací a integrace se tak plně využívají výhody servisně orientované architektury. Lze dosáhnout minimální duplicity softwarových komponent a vysoké míry znuvupoužitelnosti. Minimální duplicita se odráží v nižších nákladech na samotný vývoj systému a vývoj jeho jednotlivých funkcionalit [11]. Popisu vývoje webových služeb jsme se věnovali v předcházejícím textu.nyní si popíšeme integraci jednotlivých služeb. Samotná kompozice, tedy koordinace volání jednotlivých webových služeb (tzv.ws Orchestration) se skládá z několika základních operací: synchronní nebo asynchronní volání služeb (funkcí), transformace XML dat, řízení běhu procesu (podmínky, cykly, výjimky), notifikační události. Kompozice tak dovoluje kombinovat jakékoli služby. Postupujeme dle přesně stanovených pravidel. Vzhledem k faktu, že všechny služby a funkce jsou ve formátu standardizovaných webových služeb, lze kombinovat funkce a služby z několika různých systémů. Nevadí ani to, že různé služby jsou implementovány na rozdílných platformách (závislost na platformě je odstraněna technologií webových služeb). Samotná integrace je tak rozšířena do roviny procesů, které mohou zahrnovat více aplikací a komplexní logiku průběhu vlastního procesu [30]. 49

50 Obrázek č. 16: BPEL Engine [47] Pomocí nástrojů integrační choreografie je možné do procesů zahrnout také manuální kroky. To vede ke komplexní podpoře business procesů, vyjadřovací síla diagramů se tak dostává na stejnou úroveň jako mají klasické workflow systémy. Na rozdíl od workflow systémů klade integrační choreografie mnohem větší důraz na automatizovanou integraci procesů mezi jednotlivými aplikacemi. S ohledem na požadavky jež jsou kladené na jednotlivé funkce a jejich podobu byl navržen jazyk WS- BPEL (BPEL4WS). Ten striktně definuje podobu jednotlivých integrovaných služeb. Výhodou jazyka WS-BPEL při procesní integraci je zejména rychlá reakce na změny a rychlost implementace. Procesor jazyka WS-BPEL obsahuje korelační a transformační mechanismy, které tak programátor nemusí implementovat sám. Choreografie služeb více externalizuje lokaci orchestrovaných služeb, což znamená, že jednotlivé služby mohou být velmi snadno nahraditelné [30]. 50

51 Obrázek č. 16: Ukázka BPEL modelu [48] Použitím jazyka BPEL (WS-BPEL) lze dosáhnout výrazně lepší integrace než v případě původní SOA architektury. Kompozitní aplikace si ponechávají všechny výhody SOA integrace a navíc poskytují výhody dané zautomatizováním celé integrace a vyšší granularitou jednotlivých služeb. I u webových služeb totiž v přeneseném slova smyslu 51

52 platí základní pravidlo operačních systému rodiny UNIX, že je lepší mít velké množství jednoduchých služeb, řešících dílčí úlohy, než malé množství složitých funkcí. Větší množství služeb zvýší režii při používání služeb, ale podstatně sníží výskyt duplicitních činností a především náročnost vývoje. Mezi leadery BPEL modelování se v současné době řadí firmy IBM a Oracle. Obě nabízejí v této oblasti vlastní řešení. V obou případech se v podstatě jedná o nativní implementace BPEL standardu s možností využívat grafický editor pro práci s BPEL procesy a škálovatelné, vysoce dostupné provozní prostředí. Toto prostředí navíc poskytuje funkce pro monitoring, auditing a debugging nasazených BPEL procesů [30] DSL DSL (Domain Specific Language) je jazyk, který se snaží odstranit někdy až přílišnou obecnost jazyka UML. Zastánci DSL tvrdí, že přílišná obecnost jazyka UML je spíše překážkou a pro oblasti jako je například oblast financí či řízení lidských zdrojů je lepší využívat speciální jazyk. To ale znamená, že pro každou eventuální oblast potřebujeme alespoň jeden specifický DSL jazyk [30]. Obrázek č. 17: Ukázka DSL modelu [49] Odpůrci tohoto přístupu oponují tím, že UML je více než dostatečný nástroj pro modelování a navíc, že podpora specifických oblastí je v UML zahrnuta také, a to od verze 2.0. Tvrdí, že vytvoření mnoha různých jazyků pro každou oblast zájmu pouze znepřehlední celý,,trh" a zbytečně oslabí pozici UML. Mezi zastánce DSL přístupu patří například společnost Microsoft, která již několik standardů dokázala samostatně prosadit. 52

53 6.5.8 ebxml Jazyk ebxml (Electronic Business using extensiblemarkup Language) někdy též označovaný jako e-businessxml, je dalším ze standardů pro popis business procesů a jejich modelování. Vývoj jazyka probíhá pod záštitou organizací OASIS a UN/CEFACT. Tento standard je založen na třech rozšířených standardech, jimiž jsou UML, XML a BMP. To mu dává značný potenciál pro prosazení mezi používané technologie.ebxml si klade za cíl vytvořit obecné a veřejné struktury, které budou popisovat obchodní procesy a aktivity. Ty je možné implementovat velice elegantně pomocí jednoduché XML syntaxe. Použití XML umožňuje vznik velmi levných a efektivních implementací nenáročných na provoz. Tím se otevírá prostor pro elektronickou komunikaci i v rámci malých firem. Příkladem může být předávání objednávek, faktur, informací o skladových zásobách apod. EebXML si tedy klade za cíl poskytovat otevřený, na XML založený standard, který dovoluje automatický přenos informací v obchodních stycích. Z tohoto pohledu je ebxml podobné výše popsané technologii SOA. Je ovšem nutné podotknout, že SOA nabízí mnohem komplexnější standard. EbXML slouží v podstatě jen pro sdílení informací a není možné postavit systém pouze na tomto standardu. Obrázek č. 18: Architektura ebxml [50] 53

54 6.5.9 XML Jazyk XML vynikl zjednodušením velmi komplexního jazyka SGML. Jazyk XML vznikl v rámci konsorcia W3C a je touto nezávislou organizací dále rozvíjen. Patří tedy, stejně tak jako napříkladhtml, do skupiny značkovacích jazyků. Oproti HTML vyniká svou flexibilitou, kdy autor XML dokumentu sám definuje značky, které bude v dokumentu používat. Autor dokumentu tak není omezen konkrétním počtem značek, sám definuje jejich vlastní množinu, kterou v dokumentu použije. Za pomoci XML lze data velice přesně značkovat. XML má velice jednoduchá syntaktická pravidla ovšem jejich splnění je velmi striktně vyžadováno To zjednodušuje vývoj prohlížečů jazyka, což umožňuje zobrazování dokumentů XML i na jednodušších zařízeních. Velmi jednoduše tak lze zpřístupnit webový obsah na mobilní zařízeních. Jde o jednoduchý, otevřený formát, který je nezávislý na operačním systému. XML je založen na textovém formátu (označkovaný text), kdy při značkování se používají pouze jednoduchá syntaktická pravidla. XML je zcela otevřený formát, veškeré specifikace jsou dostupné na stránkách konsorcia. W3C. To přináší řadu výhod oproti uzavřeným proprietárním produktům, které jsou většinou svázány s určitým typem hardware či software. Princip XML spočívá v tom, že značky obklopují v textovém XML dokumentu určité části textu, čímž označují jejich věcný význam. Značky které je možné v dokumentu použít, stanoví autor sám v Definici Typu Dokumentu - DTD (Document Type Definition) Pokud je dokument určen lidskému oku a nejedná se pouze o datový soubor využívající XML, může autor pomocí stylů XSL (extensible Stylesheet Language) určit jak se má dokument zobrazovat. To znamená, že značky neurčují způsob prezentace obsahu dokumentu, ale pouze jeho věcný význam. XML a webové služby Webové služby založené na XML jsou moderním nástrojem pro integraci webových aplikací. Existence různých webových služeb umožňuje programátorům a tvůrcům informačních systémů tvořit nové webové aplikace, které využívají tyto služby. Jestliže je pro přístup k webovým službám použit formát XML, je možné vytvářet aplikace nezávislé na platformě. Tím se webové služby a XML stávají užitečným integrujícím nástrojem pro budování rozsáhlých distribuovaných aplikací založených na výměně zpráv. Tvoří základní stavebními bloky webových aplikací a distribuovaného zpracování dat, jelikož jedna webová aplikace může současně využívat více webových služeb z více různých serverů. Uživatel aplikace přitom většinou vůbec neví, jaké webové služby a ze kterých serverů jeho aplikace využívá. Uživatel tak přímo komunikuje pouze s jedinou aplikací [38]. 54

55 Hodnocení XML XML nabízí oproti proprietárním formátům dat tyto výhody: samopopisný, na platformě nezávislý, otevřený textový formát, jednoduchá možnost validace a kontroly správnosti dat, možnost použití různých kódování češtiny, možnost přenosu i binárních dat, rozšiřitelnost s možností definovat vlastní značky a strukturu [38]. Samopopisnost a nezávistost na platformě je důležitá především pro tvůrce informačních systémů a programátory. Tím, že jsou XML dokumenty v textovém formátu, jsou velmi vhodné pro použití na internetu. Tomu napomáhá i možnost zvolit si různé kódování, ikdyž drtivá většina dokumentů v tomto formátu využívá kódování UTF8. Rozšiřitelnost a možnost definovat vlastní značky a tím i strukturu dokumentu znamená, že XML je vysoce flexibilní a univerzální nástroj pro ukládání a výměnu dat. Otevřenost formátu je zárukou toho, že informační systémy, služby a aplikace založené na formátu XML budou mít delší životnost a tím přispějí ke znatelnému snižení nákladů na jejich další budování a především údržbu [20]. Nevýhodou se může zdát větší velikost XML souborů, to však dnes lze velmi efektivně řešit za pomoci vhodných komprimačních technik. Integrace pomocí XML Integrací pomocí XML nazýváme použití XML pro vzájemnou výměnu dat mezi systémy bez použití dalších nástaveb jako je např. SOAP. Jedná se v podstatě o použití XML jako univerzálního výměnného formátu. Dříve se pro tyto účely běžně používaly soubory s oddělovačem. XML jako univerzální výměnný formát figuruje ve všech webových technologiích, jeho použití je však skryto v konkrétní technologii. Např. v SOAP engine. Pokud mluvíme o integraci pomocí web services je třeba znát alespoň základy XML. Při integraci pouze pomocí XML je třeba nejdříve nadefinovat podobu posílaných zpráv, tj. popsat strukturu XML souboru např. pomocí DTD nebo XML schémat. Následně musí obě strany komunikačního kanálu implementovat mechanizmy pro vytváření a příjem těchto zpráv. Implementace může být u poskytovatele úplně odlišná od konzumenta, důležité je pouze dodržení správné struktury posílaných XML dat. Pokud hovoříme o integraci pomocí XML je třeba poznamenat, že za pomoci předávání XML souborů, a to buď automatizovanou nebo v extrémním případě manuální cestou, lze propojit i systémy, jež nemají pro integraci na první pohled žádné předpoklady. Většina z nich totiž dokáže data uložená v interních strukturách na požádání vyexportovat právě do formátu XML. Takový soubor pak lze jednoduše načíst do cílového systému. Tento postup lze použít pouze tam, kde není jiná možnost integrace a kde není kladen důraz na pravidelnou aktualizaci dat v cílovém systému. Příkladem může být číselník telefonních poboček u telefonních ústředen firmy Avaya, který lze ručně načíst do tohoto zařízení právě ve formátu XML. 55

56 6.6 Enterprise Service Bus Webové služby jsou velmi vhodným prostředkem pro realizaci SOA. Jsou však jen základním kamenem celé konstrukce integrace informačních systémů. Aby celá integrace neskončila jen výměnou dat mezi systémy, je třeba služby rozšířit o další infrastrukturu. Teprve ta umožňuje výsledné aplikace společně s použitými službami monitorovat a efektivně spravovat. Celek pak poskytuje služby garantované kvality a bude schopen řešit komplexní úlohy vyplívající z aktuálních potřeb provozovatele. Infrastrukturní řešení na bázi SOA poskytuje takzvaná organizační sběrnice služeb - ESB (Enterprise Service Bus). Jedná se o logicko architektonický koncept, který poskytuje integrační infrastrukturu v distribuovaném prostředí. Obsahuje samozřejmě také potřebné nástroje pro vlastní správu. Obrázek č. 19: Schéma použití Enterprise Service Bus [50] 56

57 Základním principem ESB je centrální sběrnice představující logický komunikační kanál, k němuž jsou připojeny jednotlivé služby. Ty si vyměňují zprávy právě prostřednictvím této sběrnice. Jejím základním úkolem je směrování a předávání zpráv mezi službami. Komunikace po sběrnici probíhá v předem definované standardní formě. Jednotliví klienti se připojují prostřednictvím tzv. adaptérů, které přizpůsobují vstupně výstupní formát zpráv standardu sběrnice. Tato charakteristika posunuje ESB do oblasti integračních řešení vyšší úrovně. Obrázek č. 20: Schéma připojení služeb k ESB za pomoci adaptérů [50] Z předchozího popisu technologie SOA je patrné, že webové služby nedostatečně pokrývají oblast transparentnosti svého umístění a nezávislosti na komunikačním protokolu. Transparentnost umístění lze v prostředí webových služeb zajistit pomocí registru služeb. Ten však není schopen zajistit inteligentní směrování. To závisí na znalosti vzájemné závislosti jednotlivých služeb, na statické či dynamické směrovací informaci. Řešení tohoto problému přináší právě principy ESB. Nezávislost na komunikačním protokolu je v podstatě integračním problémem. ESB jej řeší pomocí přidané vrstvy adaptérů, které jsou schopné obousměrné transformace dat. Doplněním technologie webových služeb o ESB získáváme komplexní koncept servisně orientované architektury. 6.7 Vývoj integračních řešení ESB vychází z dlouhé řady více či méně úspěšných předchůdců. Snaží se respektovat jejich přednosti a potlačit odhalené nedostatky. Za nejvýraznější integrační koncept před příchodem ESB lze bezesporu považovat integrační brokery. Základem jejich funkcionality byl transformační a směrovací modul. Broker provedl transformaci příchozí zprávy do formátu srozumitelného pro příjemce a na základě směrovacích informací ji poslal dál. Nejmarkantnější vlastností brokeru je právě centralizovanost. Ta sice přináší jednoduchou správu, ale negativně ovlivňuje 57

58 škálovatelnost služeb. Všechny zprávy v takovém řešení musí totiž nutně procházet jedním středovým bodem, kterým je právě broker. To jej neúměrně zatěžuje. Při integraci různých systémů pak toto řešení není schopné zajistit potřebnou autonomii. Tato centralizovanost bývá označována termínem hub-and-spoke. Tento model nebyl z těchto důvodů dlouhodobě úspěšný. Vznikl jako první koncept pro řešení integrace, ale jeho koncepci nelze považovat za nadčasovou. I přesto byl v polovině devadesátých let implementován v řadě velkých organizací. Na zvyšující se poptávku po integračních řešeních následně zareagovaly velké softwarové společnosti jako jsou IBM, TIBCO, BEA. Uvedly na trh řadu produktů, které můžeme souhrnně označit Enterprise Application Integration (EAI, podniková aplikační integrace). EAI je v podstatě jiný název pro integrační brokery s architekturou hub-and-spoke, které zpravidla vedle základních transformačních a směrovacích funkcí nabízely i moduly pro správu business procesů (Business Process Management, BPM). To umožnilo částečné přesunutí integrační logiky z kódu aplikací do integrační mezivrstvy. Oproti předchozímu konceptu přibyla možnost deklarativně konfigurovat směrování a informace o směrování ukládat do nově zřízených depozitářů. Obrázek č. 21: Časová rozložení integračních řešení [42] S rozmachem i dnes stále populárnějšího jazyka Java a systémů v něm implementovaných se dočkal úspěchu jiný integrační koncept. Je označován jako Messageoriented middleware (middleware orientovaný na zprávy) ve zkratce MOM. V jeho případě základní myšlenka spočívá ve vytvoření komunikačního prostředí založeném na asynchronně doručovaných zprávách. Ty si lze představit jako analogii e- mailové komunikace. Zprávy od odesilatele přijímá doručovací systém, který je předává příjemci. Doručovací systém zajistí spolehlivou výměnu zpráv a je také vybaven vlastní směrovací logikou. MOM silně podporuje interoperabilitu připojených systémů, je distributivní a omezuje počet nežádoucích point-to-point spojení. Negativním rysem však je nutnost výrazně zasáhnout do aplikační logiky komunikujících komponent, u kterých má dojít k napojení na příslušné aplikační rozhraní. Za nejúspěšnější klasickou implementaci message-oriented middlewaru lze považovat Java Messaging Service (JMS) [42]. Integrace pomocí ESB je postavena na úspěšných rysech obou výše uvedených architektur. ESB využívá a dodržuje v maximální míře volně dostupné standardy čímž brání vzniku efektu informačního sila postaveného z uzavřených technologií. Druhotným efektem je pak méně výrazná závislost organizací na jednom konkrétním dodavateli softwaru. Za hlavní nedostatky integračních brokerů lze považovat použití centralizované architektury hub-and-spoke a s ní spojené nevýhody. 58

59 U ESB je kladen maximální důraz na distribuovanost vytvořené infrastruktury. Typickou ESB tvoří několik kontejnerů služeb, které jsou navzájem propojený přes společný komunikační kanál. Celek pak tvoří jednu transparentní sběrnici. Příslušné infrastrukturní komponenty jsou nasazeny pouze tam, kde jsou právě potřebné. Decentralizace směrování předchází nadměrnému zatížení centrálního routeru. Stejného efektu je možné dosáhnout také řízenou distribucí směrovacích informací do každého uzlů sběrnice. Kladným rysem ESB je možnost oddělit logickou a fyzickou část systému. ESB umožňuje koncipovat celý systém jako federaci autonomií - každá zájmová doména participující v systému disponuje vlastní logickou částí sběrnice, na které si organizuje vlastní zdroje, některé komponenty jsou potom sdílené a dostupné všem [42]. Takto navržený distributivní systém samozřejmě vyžaduje správu a konfiguraci. To se provádí přes jeden vstupní bod, příslušné nastavení se pak šíří mezi uzly po sběrnici. Aby bylo možno zajistit maximální znovupoužitelnost jednotlivých komponent systému, je třeba dodržovat určitá pravidla. V samotném kódu modulů se nesmí objevit žádné informace, které by jej svázaly s konkrétním transportním protokolem nebo adresou. ESB v tomto směru zajišťuje potřebnou infrastrukturu vlastními zdroji, umožňuje komponentám komunikovat úplně transparentně. Za komponentu při implementaci servisně orientované architektury považujeme službu. Pokud je konkrétní služba navržena podle principů SOA je možné ji současně zařadit do více komponovaných procesů. Systém se pak vlastně skládá z několika dalších vrstev, kdy skupiny existujících služeb tvoří nové funkční bloky. To, aby byla služba korektně navržena dle principů SOA nelze zajistit žádným formálním postupem. Tyto vlastnosti dokáže do služby promítnout pouze zkušený analytik. Jak integrační řešení postupem času vyzrávají, můžeme pozorovat jejich posun směrem od fyzické centralizace k distribuovanosti. Integrační logika se přesunuje z aplikací do univerzálních dedikovaných modulů, proprietární koncepty jsou nahrazovány standardy[50]. Tento trend je důsledkem zvyšujících se požadavků na integrační řešení s důrazem na ochranu investic vložených do vývoje těchto řešení. Typická současná implementace ESB nabízí funkcionalitu, jejíž rozsah výrazně překrývá výše uvedený přehled. Je ovšem dobré si uvědomit, že optimální řešení pro konkrétní problém není systém s maximálním počtem význačných rysů. Je jím ten, který poskytuje správné vlastnosti nezbytné k vyřešení konkrétních problémů [42]. 59

60 7 Analýza a návrh systému pro správu nemovitostí V této části práce se budu věnovat ukázce použití výše popsaných technologii při analýze systému pro správu nemovitostí v rozsáhlé organizaci a jeho integraci do dalších informačních systémů, které tato organizace využívá. Analýza bude obsahovat také návrh technického řešení informačního systému. Při analýze systému vyjdeme z již hotové analýzy, kterou jsem zpracoval jako bakalářskou práci viz [6], kde je možné najít kompletní funkční a datový model. Tento systém již byl uveden do ostrého provozu, způsob propojení s externími systémy však doposud nebyl uspokojivě realizován. Původní analýzu tedy doplním o podrobnější popis externích systémů a navrhnu způsob integrace modelovaného systému pomocí výše popsaných metod. 7.1 Požadavky na modelovaný systém: Cílem práce je navrhnout informační systém pro správu nemovitostí pro potřeby Masarykovy univerzity. Před rozhodnutím implementovat vlastní informační systém určený těmto potřebám byla odpovědnými osobami zvažována možnost zakoupit již existující produkt, který by tuto problematiku řešil. Po prozkoumání nabídek společností, které nabízejí odpovídající produkty, bylo rozhodnuto implementovat zcela nový systém v rámci již existující informační infrastruktury MU. To přinese několik podstatných výhod. Informační systém bude odpovídat přesně potřebám univerzity a v případě, že se potřeby v budoucnu změní, bude možné jej jednoduše modifikovat. Aplikace budou vytvořeny nad již provozovaným aplikačním serverem, využijí předpřipravené komponenty vyvinutého frameworku a jeho bezpečnostní model. Masarykova univerzita je velmi rozsáhlou organizací. Její pracoviště sídlí v osmdesáti budovách roztroušených po městě Brně a některé budovy vlastní i mimo město. Ke každé budově je třeba evidovat její umístění, v rámci města Brna je třeba zvolit jemnější členění, obdobně jako jsou rozloženy městské části. Některé budovy tvoří tzv. areály. Jedná se o skupiny geograficky blízkých budov s určitým specifickým společným jmenovatelem, např. vchodem přes společnou vrátnici apod. Budova může mít přiřazenu adresu, obecně jich však může mít přiřazeno více. Areál může mít taktéž přirazenu jednu či více adres, v tomto případě se pak jedná o společnou adresu všech budov v areálu. V případě, že budova nemá přiřazenu adresu, musí být součástí areálu s alespoň jednou přiřazenou adresou. U každé budovy se eviduje organizační složka univerzity, která za správu budovy odpovídá. Číselník organizačních složek je poskytován z personálního systému (modulu pro správu organizační struktury). Uspořádání organizačních složek tvoří hierarchickou stromovou strukturu. Spravovat budovu mohou jen vybrané organizační složky. Dále je k budovám třeba evidovat údaje minimálně v tomto rozsahu: název, zkratka, anglický název, typ vlastnictví, počet nadzemních a podzemních podlaží, typ budovy a poznámka. 60

61 Každá budova má přiřazen jednoznačný identifikátor v rámci lokality, tzv. polohový kód budovy. V rámci budovy se evidují jednotlivé místnosti. Místnost má přiřazen jednoznačný identifikátor v rámci budovy a podlaží. Ten tvoří společně s polohovým kódem budovy polohový kód místnosti. Dále se k místnosti evidují tyto údaje: podlaží, ve kterém se nachází, číslo, název česky a anglicky, účel užití (viz níže seznam účelů), poznámka, zda je místnost užívána pro výuku či zda je místnost označena jako tajná. Každou místnost užívá jedna nebo více organizačních složek, a je třeba evidovat procentní zastoupení jednotlivých uživatelů. Dále je k místnosti nutné evidovat, kterým organizačním složkám má být zahrnuta do rozpočtu (obecně se může jednat o jiné organizační složky, než které místnost užívají). Seznam účelů místností je dále členěn na skupiny účelů, kdy každý účel je přiřazen právě do jedné skupiny účelů, a obdobně skupiny účelů tvoří typy skupin účelů, kdy každá skupina účelů je zařazena do právě jednoho typu skupin účelů. Ke každé místností se eviduje stavební pasport. Ten se skládá z informací o ploše místnosti, obvodu místnosti, výšce stopu, počtu oken, dveří a světel v místnosti a údaje, zda je místnost vytápěna. Součástí stavebního pasportu je také informace o rozměrech povrchů v místnosti. Povrchy se rozlišují na povrchy stěn, podlahy a stropu. U každého povrchu se eviduje jeho plocha a typ. Obecně platí, že místnost může mít evidováno více povrchů podlahy (obdobně stěn a stropu), kdy součet ploch všech povrchů podlah nesmí překročit celkovou plochu místnosti. Systém musí být otevřený, v dohledné době se počítá s jeho rozšířením o technologický pasport, ve kterém budou zmapovány všechny technologie v jednotlivých místnostech. Součástí návrhu IS je podrobný návrh přístupových práv, kdy je v rámci informačního systému požadováno více úrovní přístupu k evidovaným údajům. Je třeba umožnit vybraným osobám přístup pouze pro čtení (a to jen vybraných údajů), modifikaci (pouze vybraných údajů). Vybrané osoby mají přístup pouze k budovám a místnostem v budovách, které užívá organizační složka (složky), za niž je jim právo přiděleno. Systém umožní osobě evidované jako celouniverzitní správce neomezený přístup k datům. Evidence osob je řešena samostatným personálním systémem, na který je nutné se navázat. Každá osoba má přiřazeno jednoznačné osobní číslo. Systém neeviduje historii, je však možno jej tak navrhnout. Systém eviduje u každé skupiny údajů, kdy a kým byly pořízeny či modifikovány. Informační systém umožní pohodlnou správu výše popsaných údajů s možností hromadného exportu a importu evidovaných dat (předpokládá se formát XML). Dále informační systém umožní vybraným uživatelům nahlížet do evidence a vytvářet předem definované sestavy, založené na výběru konkrétních skupin budov či místností s omezením na účel užití místnosti, typu ploch obsažených v místnosti a uživatelů místnosti. Typy sestav budou dopřesněny během implementace. Výstupní formát sestav je PDF. Na základě výše popsaných požadavků jsem provedl níže uvedenou analýzu. 61

62 Seznam požadavků na systém Z popisu systému odvodíme seznam požadavků na modelovaný systém. Pro potřebu našeho ukázkového přikladu stačí tato podmnožina: zobrazení karty místnosti zobrazení karty objektu (místnost, budova) generování parametrizované sestavy změna údajů o objektu změna přístupového práva 62

63 7.2 Výsledek původní analýzy Obrázek č. 22: Kontextový diagram [6] Výsledkem původní analýzy byl kromě jiného výše uvedený kontextový diagram (ERD diagram je uveden v příloze). Jak je z diagramu patrno, systém má návaznosti na čtyři externí systémy. Pouze externí systém CEPo je vytvořen v rámci jednoho aplikačního prostředí, ostatní tři jsou systémy od externích dodavatelů Popis externích systémů CEPo Pod zkratkou CEPo se skrývá informační systém pro evidenci telefonních poboček univerzity, který zahrnuje taktéž tarifikaci jednotlivých hovorů, umožňuje označování 63

64 soukromých hovorů zaměstnanců. Systém eviduje u každé telefonní pobočky její fyzické umístění, proto je nezbytná komunikace se systémem pro správu nemovitostí. Správci CEPo potřebují pro vykonávání svých povinností mít možnost nahlédnout na podrobnosti o nemovitostech evidovaných v modelovaném systému. Naopak pro modelovaný systém je vhodné vědět, v kterých místnostech se nacházejí které telefonní pobočky. Tuto informaci následně zobrazuje na kartě místnosti. GIS Zkratka GIS označuje geografický informační systém provozovaný univerzitou. Ten je s modelovaným systémem ve velmi silné vazbě. Modelovaný systém spravuje popisná data nemovitostí, zatímco GIS spravuje grafická data nemovitostí. Oba systémy proto musí úzce spolupracovat a být neustále v synchronním stavu. Za primární zdroj dat je určen modelovaný systém. GIS v pravidelných intervalech přebírá vybraná data. GIS poskytuje modelovanému systému grafický náhled plánů nemovitostí a hypertextový odkaz na interaktivní prohlížečku grafických podkladů. Ekonomicky informační systém Ekonomický informační systém eviduje mimo jiné veškerý hmotný majetek. Každý hmotný majetek má své umístění v konkrétní místnosti. Seznam místností a vybrané informace o nich přebírá ekonomický informační systém z modelovaného systému. V opačném směru jsou přebírána data o majetku evidovaném v konkrétních místnostech. Do modelovaného systému je dále přebírán seznam majetkových referentek konkrétních organizačních jednotek, které mají následně možnost prohlížet si vybrané informace na kartě místnosti. Personální informační systém Personální informační systém univerzity poskytuje modelovanému systému aktuální seznam zaměstnanců a číselník organizačních složek..vzhledem k zaměření této práce je v navrženém systému zakomponováno použití webových služeb. Navržený systém tak zahrnuje integraci s externím systémem CEPo a externím systémem GIS. Tyto systémy a samotná integrace budou specifikovány v následující samostatné kapitole, kde bude patrné oddělení standardní a SOA funkcionality navrhovaného systému. Abych mohl ukázat použití SOA integrace, začlenil jsem do základního návrhu následující webové služby: předání základních informací o místnosti do externího systému získání informací o telefonních pobočkách evidovaných v místnosti v systému CEPo získání informací o evidovaném majetku v ekonomickém IS předání seznamu místností v budově systému GIS 64

65 Výčet těchto služeb poskytovaných modelovaným systémem není kompletní. Všechny webové služby zde neuvádím, jelikož se jedná pouze o motivační příklad integrace IS. Je třeba mít na paměti, že pro vlastní návrh a implementaci modelovaného systému a jeho vnitřní logiky není nezbytně nutné vědět jak přesně bude systém vystupovat vůči ostatním spolupracujícím systémům. Stačí znát definici používaných rozhranní Popis uživatelů Pokud se na kontextový diagram podíváme očima UML analytika, je nám na první pohled zřejmé, že množina uživatelů je podmnožinou aktorů v notaci UML. Správce nemovitosti Správce nemovitosti je zaměstnanec univerzity, mezi jehož pracovní povinnosti patří udržovat vybranou množinu informací v informačním systému v aktuálním stavu. Správce nemovitosti vždy odpovídá za množinu nemovitostí, jež užívá či spravuje organizační jednotka, která ho správou pověřila. Správce může být pověřen správou více organizačních jednotek současně. Celouniverzitní správce spolupracuje s jednotlivými správci organizačních jednotek a koordinuje jejich činnost. Může upravovat informace u všech typů nemovitostí evidovaných v systému. Přiřazuje na základě požadavků organizační jednotky správcům potřebná oprávnění. Správce má možnost prohlížet detailní informace o těch nemovitostech v informačním systému, které spravuje nebo užívá jeho organizační jednotka. Organizační jednotku, která spravuje či užívá nemovitost, definuje celouniverzitní správce. Správce má možnost vygenerovat pomocí informačního systému sumární parametrizované sestavy, např. plochu všech podlah ve zvoleném patře, které mají jako povrchovou úpravu použitu dlažbu. Správce CEPo Správce CEPo je zaměstnanec univerzity pověřený správou telefonních poboček určité organizační jednotky. Seznam správců získává modelovaný systém od CEPo. Správce má právo prohlížet vybrané údaje o jednotlivých nemovitostech. Pověřená osoba Pověřená osoba je osoba s právem prohlížet vybrané údaje evidované v modelovaném systému. Osoba musí být zaevidována v univerzitním personálním systému. Příslušné právo pro pověřené osoby přiděluje celouniverzitní správce. 65

66 Majetková referentka / majetkový referent Majetková referentka / majetkový referent je zaměstnanec univerzity pověřený správnou evidencí umístění nehmotného majetku. Seznam majetkových referentů přebírá modelovaný systém z ekonomického informačního systému. Systém Systém je označení aktora, který spouští pravidelné operace. V podstatě se jednáo systémový spínač jednotlivých operací, který se spouští v pravidelných intervalech (jednou denně, jednou měsíčně) a provádí přepočty a aktualizace dat. 7.3 Use Case model - model případů užití Use Case model, je pro potřeby tohoto příkladu velmi zjednodušen. Nebudeme se zabývat UML modelováním, potřebujeme jen určitý základ modelu IS na kterém si ukážeme jeho integraci s externím systémem pomocí WS. Obrázek č. 32: Případ užití 66

67 7.4 Textové specifikace případů užití Use Case: Zobrazení karty místnosti Účastník: Správce CEPo Scénář: IS zobrazí formulář pro vložení polohového kódu místnosti Správce CEPo zadá polohový kód místnosti: IS zobrazí informace o místnosti Use Case: Zobrazení karty místnosti Účastník: Majetková referentka Scénář: IS zobrazí formulář pro vložení polohového kódu místnosti Majetková referentka zadá polohový kód místnosti IS zobrazí informace o místnosti Use Case: Zobrazení karty objektu Účastník: Správce nemovitosti Scénář: Správce nemovitosti zvolí operaci,,zobrazení karty místnosti". IS zobrazí formulář pro vložení polohového kódu místnosti Správce nemovitosti zadá polohový kód místnosti IS zobrazí informace o místnosti Alternativní scénář 1: Správce nemovitosti zvolí operaci,,zobrazení karty budovy". IS zobrazí formulář pro vložení polohového kódu budovy Správce nemovitosti zadá polohový kód budovy IS zobrazí informace o budově Use Case: Zobrazení karty objektu Účastník: Pověřená osoba Scénář: Pověřená osoba zvolí operaci,,zobrazení karty místnosti". IS zobrazí formulář pro vložení polohového kódu místnosti Pověřená osoba zadá polohový kód místnosti: IS zobrazí informace o místnosti Alternativní scénář 1: Pověřená osoba zvolí operaci,,zobrazení karty budovy". IS zobrazí formulář pro vložení polohového kódu budovy Pověřená osoba zadá polohový kód budovy IS se zobrazí informace o budově 67

68 Use Case: Změna objektu Účastník: Správce nemovitosti Scénář: Správce nemovitosti zvolí operaci,,změna údajů o místnosti ". IS zobrazí formulář pro vložení polohového kódu místnosti Pověřená osoba zadá polohový kód místnosti IS zobrazí formulář pro změnu údajů o místnosti Pověřená osoba změní vybrané údaje IS uloží zadané informace o místnosti Alternativní scénář 1: Správce nemovitosti zvolí operaci,,změna údajů o budově". IS zobrazí formulář pro vložení polohového kódu budovy Pověřená osoba zadá polohový kód budovy IS zobrazí formulář pro změnu údajů o budově Pověřená osoba změní vybrané údaje IS uloží zadané informace o budově 7.5 Modely integrace IS s externími systémy V této kapitole se zaměříme pouze na samotné rozhraní systému, tedy na operace vstupující do navrženého systému od externích systémů a na operace vystupujícíz navrženého systému směrem k externím systémům. Oprostíme se od vnitřních funkcí modelovaného systému. Možnosti integrace s externími systémy byly teoreticky popsány v předchozích kapitolách. Pokud vyjdeme z těchto znalostí a vyloučíme zastaralé techniky je jasné, že máme celkem tři možnosti integrace. První variantou je volba postupu, kdy rozšíříme systém svépomocí. V tomto případě známe jak model IS, tak i detailní specifikaci rozšiřujícího systému. Oba systémy lze tedy jednoduše spojit a celá integrace tak může být velmi pohodlná, efektivní a rychlá. Tato možnost je vhodná pro integraci se systémem CEPo, neboť je implementován na stejné platformě a ve stejném prostředí. Druhou variantu integrace použijeme, jestliže u externího systému alespoň částečně známe jeho specifikaci a máme možnost v něm nastavit (zpřístupnit) rozhraní pro vlastní integraci. Příkladem může být integrace s externím systémem GIS, který z tohoto pohledu relativně otevřený a umožňuje definovat webové služby, které zpřístupní určitá uložená data. Třetí variantou je integrace s systémem o jehož vnitřních funkcích nic nevíme. Známe pouze rozhranní pro výměnu dat. Příkladem takového systému může být ekonomický IS nebo personální IS, který je dodáván na klíč a o jehož vnitřní struktuře toho víme velmi málo. 68

69 Obrázek č. 42: Okolí IS Na obrázku č. 23 vidíme schematické znázornění okolí navrženého systému. Nejedná se o přesnou specifikaci systému, tak jak by měla při pečlivé analýze vypadat, ale pouze o ilustrační popis rozhraní systému. Obrázek abstrahuje od detailní znalosti integrovaných systémů, tj. nezachycuje, zda daný systém a jeho specifikaci známe či nikoli. Dále je třeba podotknout, že ve skutečnosti nevíme s kolika dalšími informačními systémy přesně bude náš IS umět spolupracovat. Tento předpoklad nás směruje k co nejobecnější metodě integrace např. k integraci pomocí webových služeb. Jedná se o kladnou vlastnost systému, protože pokud nelze přesně definovat počet a funkce externích systémů, je třeba systém navrhnout tak, aby byl schopný integrace prakticky s jakýmkoli externím systémem. Tomu pak odpovídá i volba použité technologie. 7.6 Integrace pomocí webových služeb V této kapitole si popíšeme vlastní integraci výše uvedeného systému s externími systémy prostřednictvím technologie webových služeb. Webové služby byly již popsány v několika dřívějších kapitolách. Integrace tedy pomocí technologie webových služeb. To také znamená, že bude třeba implementovat jednotlivé součásti webových služeb, kterými jsou SOAP, UDDI a WSDL. Je nutné mít na paměti, že ne všechny tyto standardy je naprosto nezbytné implementovat plně. Jako příklad může posloužit standard UDDI, který v podstatě pro správnou funkčnost řešení není nutné implementovat vůbec, nebo je možné využít pouze na lokální adresář. Tato možnost spočívá v tom, že si navrhneme a sestrojíme vlastní UDDI registr, do kterého budou mít přístup pouze naši vybraní partneři. Tím zveřejníme jenom ty služby, které vybereme. Částečně tím odstraníme i problematiku centralizace UDDI registru. Obdobně jako u UDDI registru se nemusíme držet přesné specifikace ani u SOAP a WSDL standardu. Je nutné si uvědomit, že některé systémy nebudou schopny komunikace prostřednictvím SOAP, ale například pouze prostřednictvím klasického XML. To se může stát u některých komerčních ekonomických systémů. V našem případě 69

70 u ekonomického informačního systému, který alespoň částečně zvládá komunikaci pomocí XML ale stále ještě nepodporuje SOAP. Pro dorozumívání s takovými systémy je třeba umět komunikovat pomocí XML zpráv a mít možnost přizpůsobit se většinou předem danému formátu zpráv. Z výše uvedených předpokladů, dostáváme následující návrh integrace. Integrace pomocí WS bude spočívat v implementaci lokálního UDDI registru, implementace rozhranní pro přenos SOAP zpráv a vytvoření odpovídající WSDL specifikace. K tomu připojíme implementaci komunikace prostřednictvím klasického XML. (Klasické XML sice není přímo součástí standardu WS ale nijak této technologii neodporuje. Navíc platí, že pro náš systém není takový rozdíl mezi komunikací prostřednictvím SOAP a XML.) Nyní naznačíme praktickou integrace aplikací. Uvedený příklad není jediným řešením v oblasti SOA integrace, ale pouze jednou z možností v této oblasti. Podpora SOA integrace je dnes na velmi vysoké úrovni i u programovacích jazyků. Integrace pomocí webových služeb se tak stává velmi snadnou. Pro integraci využijeme možnosti frameworku Apache Axis viz následující kapitola. Pomocí něj máme možnost jednoduše implementovat technologii webových služeb pomocí Java Web Services. Jedná se o technologii, u které lze za pomoci jistých interních mechanismů vystavit na aplikačním serveru Java kód jako webovou službu. K tomuto napomáhá framework Apache Axis, který poskytuje SOAP engine, tedy nástroj pro práci se SOAP zprávami a také nástroje WSDL2Java a Java2WSDL, které slouží pro vzájemné převádění mezi WSDL soubory a Java třídami. Pokud tedy například z WSDL specifikace vygenerujeme Java kód, můžeme s touto metodou (třídou) pracovat jako by byla lokální, což samozřejmě velmi ulehčí a zjednoduší práci programátora. Použitím tohoto frameworku tak máme možnost implementovat technologii webových služeb a tedy princip SOA. Tato implementace navíc není díky propracovanosti navržených nástrojů, technik a standardů nijak obtížná a nákladná. Samotná implementace webových služeb není pouze otázkou použití frameworku Apache Axis, ale lze k ní využít i spoustu jiných nástrojů a technik. Použití Apache Axis je pouze jedním z možných praktických příkladů integrace pomocí SOA technologie. Na tomto místě je třeba zmínit fakt, že součástí této práce není návrh specifikacevšech procesů v systému a ani definice konkrétní WSDL, SOAP nebo XML zprávy. Záměrem je zmapovat způsoby jednotlivých integrací. Hlavním důvodem je jednak rozsah a složitost případných specifikací a zejména pak zaměření práce, kdy praktická implementace informačního systému je nad rámec zadání. Pohybujeme se tedy v určité hypotetické rovině, kdy se pouze snažíme najít a popsat takové řešení, které bude prakticky použitelné. 7.7 BPEL integrace Pomocí standardu BPEL lze sestrojit kompozitní aplikaci, tj. aplikaci sestavenou z několika webových služeb. Ty nemusí být implementovány v jednom systému. Integrace pomocí BPEL je v podstatě další úrovní SOA integrace, která dovoluje naplno využít všech výhod SOA technologií a k nim přidává možnost jednoduché 70

71 orchestrace použitých služeb. Jedná o seskupení funkcí a služeb několika systémů ve výslednou funkci s přesně požadovanými vlastnostmi. Pro integraci pomocí BPEL, je nutné bezpodmínečně dodržet standard WS-BPEL (BPLE4WS) u všech integrovaných služeb. Z praktického hlediska dnes není problémem najít nástroj podporující BPEL integraci. Jako uživatelsky a implementačně nejpřívětivější se jeví použití některého z vývojových prostředí jako například NetBeans či Eclipse. Ta v sobě zahrnují BPEL architekt či designer, jenž slouží pro vizuální správu BPEL integrace. Prakticky tedy budeme postupovat tak, že v prostředí, ve kterém budeme implementovat náš systém, použijeme i BPEL designer a pomocí něj zorchestrujeme jednotlivé webové služby, přičemž náročnost práce a požadavky na znalosti programátora nejsou nijak extrémně zvýšeny. Obrázek č. 52: Model asynchronní komunikace v BPEL 71