Vysoká škola ekonomická v Praze. Fakulta informatiky a statistiky. Katedra informačních technologií

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie Diplomant: Bc. František Simetinger Vedoucí diplomové práce: Ing. Libor Gála Oponent diplomové práce: Ing. Martin Samek VYUŽITÍ SYSTÉMU SAP V KOMPOZICI BUSINESS SLUŽEB školní rok 2011/2012

2 Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem čerpal. V Praze dne podpis

3 Poděkování: Děkuji panu Ing. Liboru Gálovi za vedení této práce, jeho rady, poznámky a průběžné konzultace.

4 ABSTRAKT Tato práce se zabývá službami v rámci podnikového IT a jejich kompozicí. Tato oblast s sebou přináší celou řadu otázek v celé řadě perspektiv a tato práce má ambici tyto otázky v těchto různých perspektivách nalézt. Cílem práce je prověření možnosti aplikace zásad a principů servisně orientované architektury a dalších standardních metodik při kompozici vnitřně procesně řízené složité business služby, která komponuje služby informačního systému SAP a vyžívá prostředků IBM WebSphere Process Server a IBM WebSphere ESB Server. Pro dosažení cíle je základním předpokladem správně identifikovat a definovat službu. Dalším důležitým pojmem je kompozice, tedy jaké mají mezi sebou služby zejména logické vazby. Na základě identifikace služby a možností její kompozice bude upřesněno, jaký je význam a definice služeb a její kompozice v rámci podnikových informačních technologií. Po vymezení služeb v kontextu informatiky, bude kladen důraz zejména na kompozitní business služby. Kompozitní business služby budou analyzovány ze tří pohledů: Engineering, Management a Governance. Přínosem práce bude zodpovězení otázky, zdali je možné v určitém prostředí a za určitých podmínek komponovat business služby, které budou respektovat kriteria pohledů Engineering, Management a Governance. Jestli kompozice těchto business služeb bude respektovat obecně respektované standardy a doporučení v definovaném prostředí. Práce svojí strukturou přechází z obecných poznatků o službách k poznatkům o službách v rámci podnikového IT. Tyto poznatky vycházejí z analýzy a doporučení metodik, které se zabývají řízením podnikového IT z pohledu služeb a stávají se základem pro definování tří pohledů. Zásady a principy definované ve třech pohledech jsou pak následně experimentálně ověřeny. Klíčová slova: servisně orientovaná architektura, kompozitní aplikace, business služba, kompozice služeb, kompozitní služba

5 ABSTRACT This thesis is focused on service in frame of enterprise computing and composition of these services. This brings a number of issues in large spectra of perspectives and this thesis has the ambition these issues resolve. The goal of this thesis is considering the principles application of service oriented architecure and standard methodologies in composition of internally managed by process complex business service, which composes services in SAP information system and which use resources of IBM WebSphere Process Server and IBM WebSphere ESB Server. The basic presumption to goal achieve is precise identification and definition of service. Also important is the notion of composition. So what are especially logical links between services. Based on this service identification it is going to be clarified the options of its composition and it is going to be specified the importance of service definition and composition in enterprise computing area. After defining the services in computing context the thesis is going to be focused on composite business services. Composite business services are going to be analyzed from three perspectives: Engineering, Management and Governance. The benefit of thesis is answer to question if it is possible in specific environment with specific conditions to compose business services, which respect the criterions of three perspectives: Engineering, Management and Governance. If the composition of those business services will respect generally respected standards and recommendations in a defined environment. Thesis in its structure passes from general knowledge about services to knowledge about services in frame of enterprise computing. This knowledge is based on analysis and recommendations of methodologies which are focused on service oriented IT management. Knowledge of this analysis are became basis for definition of three perspectives. Principles defined in three perspectives are going to be verified in real experiment. Key words: service oriented architecture, composite application, business service, services composition, composite service

6 OBSAH Abstrakt... 4 Abstract... 5 Obsah Úvod Vymezení tématu Cíl práce Způsoby dosažení cíle práce Struktura práce Předpokládaný přínos práce Aktuální stav poznání v oblasti Služby a jejich kompozice Obecný pohled na služby a jejich vlastnosti Základní kritéria pro členění služeb Kompozice služeb Služby a jejich kompozice v rámci podnikového ICT Shrnutí poznatků o službách a jejich kompozici Standardy a principy pro kompozici služeb SOA jako obecný standard pro kompozitní business služby Služby v rámci SOA Typy služeb v rámci SOA ESA a kompozitní business služby Služby v rámci ESA Konstrukce kompozitních business služeb v rámci ESA TOGAF a kompozitní business služby Služby v rámci TOGAF Kompozice služeb v rámci TOGAF... 39

7 4.4 ITIL a kompozitní služby Typy služeb v rámci ITIL Kompozice služeb v rámci ITIL COBIT Ostatní přístupy ke kompozitním službám Princip kontroleru dle Erla Portál jako kompozitní služeba v rámci ESA Shrnutí poznatků o kompozitních business službách Pohledy na kompozitní business služby Pohled Engineering Standardy pro tvorbu komponent mimo koncept service oriented Standardy pro tvorbu služeb v konceptu service oriented Standardy pro komunikaci mezi službami Pohled Management a Governance Řízení a dohled na životní cyklus služeb v rámci ESA Řízení a dohled na životní cyklus služeb v rámci TOGAF Řízení a dohled na životní cyklus služeb v rámci ITIL Řízení a dohled na životní cyklus služeb v rámci SOA Řízení a dohled na životní cyklus služeb v rámci COBIT Shrnutí poznatků o pohledech Management a Governance Shrnutí poznatků o pohledech na kompozitní business služby Implementace kompozitní business služby Předpoklady a omezení prostředí experimentu Popis prostředí Omezení prostředí Popis experimentu Popis business case... 76

8 6.2.2 Požadavky kladené na jednotlivé kompozitní business služby Provedení experimentu Analytický popis kompozitní business služby Implementační popis kompozitní business služby Fyzická podoba kompozitní business služby Zhodnocení naplnění předpokladů implementovanými kompozitními business službami Závěr Terminologický slovník Přehled použitých zkratek Přehled literatury a použitých zdrojů Seznam obrázků Seznam tabulek Přílohy Kanonický model Datový slovník Business Objekty Rozhraní, business objekty a reprezentační diagramy služeb GetClientCardsOverview GetClient GetClientCard GetCard GetCode SAPGetClient SAPGetAccount a SAPGetClientAccount SAPGetCard SAPGetCode

9 13.3 Služby na platformě SAP NetWeaver Datový model na platformě SAP NetWeaver Služba Z_GET_CLIENT Služba Z_GET_CARD Služba Z_GET_ACCOUNT Služba Z_GET_CODE

10 1 ÚVOD Diplomová práce: Využití systému SAP v kompozici business služeb 1.1 VYMEZENÍ TÉMATU Pojem služba je v moderním komerčním prostředí poměrně rozšířený a používá se na celou řadu pojmů, objektů i činností. Jedná se o termín, který nemá jednoznačný význam a je možné si pod ním představit naprosto odlišné věci bez obsáhlého kontextu. Tato práce se zabývá službami v rámci IT a jejich kompozicí, přičemž je nezbytné nalézt definici služby a také způsoby, jakými je možné je komponovat. To s sebou přináší celou řadu otázek v celé řadě perspektiv a tato práce má ambici tyto otázky v těchto různých perspektivách nalézt, odpovědět na ně a podložit tyto odpovědi relevantními argumenty. 1.2 CÍL PRÁCE Cílem práce je prověření možnosti aplikace zásad a principů servisně orientované architektury a dalších standardních metodik při kompozici vnitřně procesně řízené složité business služby, která komponuje služby informačního systému SAP a vyžívá prostředků IBM WebSphere Process Server a IBM WebSphere ESB Server. 1.3 ZPŮSOBY DOSAŽENÍ CÍLE PRÁCE Pro dosažení cíle je základním předpokladem správně identifikovat a definovat službu. Proto se vychází ze sumarizace, co to vlastně služba je, co můžeme v obecném měřítku za službu považovat. Dalším důležitým pojmem je kompozice, tedy jaké mají mezi sebou služby zejména logické vazby. Na základě identifikace služby a možností její kompozice bude upřesněno, jaký je význam a definice služeb a jejich kompozice v rámci podnikových informačních technologií. Po vymezení služeb v kontextu informatiky bude kladen důraz zejména na kompozitní business služby, které jsou těžištěm této práce. Kompozitní business služby budou analyzovány ze tří pohledů: Engineering Management Governance 10

11 Pohled Engineering se na kompozitní služby dívá z technologicky-implementačního hlediska, tedy jaké standardy a doporučení existují pro definování kompozitních business služeb a jak tyto služby vymezují. Zjednodušeně je možné pohled Engineering chápat jako konstrukci služeb. Pohled Management se na kompozitní služby dívá z pohledu životního cyklu služby. Tedy jakým způsobem služby řídit z pohledu toho, co mají poskytovat a jak dlouho. Případně, jak se mají chovat v případě transformace požadavků na to, co mají poskytovat. Pohled Governance má za úkol dohlížet na pohled Management, aby jeho řízení životního cyklu respektovalo architektonické principy a politiky definované pro chod, provoz a vlastnosti služeb. Pro definování služeb z těchto tří pohledů a jejich kompozice bude využita odborná literatura a rešerše dostupných vysokoškolských kvalifikačních prací. Výstupem této na rešerši založené analýzy bude výčet vlastností, které by měly kompozitní aplikace a její součásti splňovat, aby ji bylo možné nazývat SOA-ready a service-ready business kompozitní službu. Předpokládá se, že možností, jak dosáhnout standardizované kompozitní služby, bude více. Pro další část práce, experiment, bude zvolena varianta, která bude nejlépe vyhovovat kritériím definovaných ve standardech a doporučeních. Výstupy této analýzy se následně stanou výstupem pro experimentální ověření těchto závěrů. Tento experiment bude mít jasně definované prostředí, předpoklady a omezení. Experiment bude spočívat v designu a implementaci konkrétní kompozitní business služby, která bude popsána business casem a která bude zároveň respektovat předpoklady získané analýzou. Výstupem experimentu bude kompozice business služby v daném prostředí, která bude respektovat dané předpoklady analýzy. 1.4 STRUKTURA PRÁCE Úvod Aktuální stav poznání v oblasti rešerše literatury Služby a jejich kompozice o Služby a jejich kompozice v obecném pohledu o Služby a jejich kompozice v rámci podnikových informačních technologií Standardy a principy pro kompozici služeb 11

12 Pohledy na kompozitní business služby Sumarizace výstupů pro kompozici standardizovaných business služeb Implementace kompozitní business služby o Předpoklady a omezení prostředí experimentu o Popis experimentu Popis business case Požadavky kladené na jednotlivé kompozitní business služby o Provedení experimentu Analytický popis kompozitních business služeb Implementační popis kompozitních business služeb Fyzická podoba kompozitních business služeb o Zhodnocení naplnění předpokladů implementovanými kompozitními business službami Závěr Detailnější struktura práce je dostupná v obsahu práce. 1.5 PŘEDPOKLÁDANÝ PŘÍNOS PRÁCE Přínosem práce bude zodpovězení otázky, zdali je možné v určitém prostředí a za určitých podmínek komponovat business služby, které budou respektovat kriteria pohledů Engineering, Management a Governance. Jestli tedy kompozice těchto business služeb bude respektovat obecně respektované standardy a doporučení v definovaném prostředí. 12

13 2 AKTUÁLNÍ STAV POZNÁNÍ V OBLASTI Pro tuto práci jsou klíčová následující slova a slovní spojení: service oriented architecture, kompozitní aplikace, business služba, kompozice služeb a kompozitní služba. Pro nalezení relevantních odkazů a nejvíce citovaných zdrojů byly využity citační rejstříky Web of Knowledge a SCOPUS a dále fulltextové vyhledávače Google Scholar a EBSCO. Pro zajištění aktuálnosti nalezených hesel a citací byly výsledky omezeny na ty, které byly publikovány od roku Pomocí klíčových slov pak také byly vyhledávány diplomové a disertační kvalifikační práce, a to jak v databázi Vysoké školy ekonomické v Praze, tak i v dalších vzdělávacích institucích. Výsledky vyhledávání shrnuje Tab. 1. Tab. 1: Výsledky citační analýzy (Autor) Google Scholar Web of Knowledge SCOPUS EBSCO Kvalifikační práce Service Oriented Architecture Kompozitní aplikace Business služba Kompozice služeb Kompozitní služba (Erl, 2005) (Coffey, a (Erl, 2005) (Rao, a další, (Rao, a další, (>2200) další, 2011) (>2200) 2005) (>580) 2005) (>580) (>10) (Gu, a další, - (Papazoglou, (Gu, a další, (Benatallah, 2005) (>160) a další, 2007) 2005) (>160) a další, 2005) (>130) (>40) (Papazoglou, - (Papazoglou, (Yu, a další, (Yu, a další, a další, 2007) a další, 2007) 2007) (>240) 2007) (>240) (>340) (>340) (Ionita, a - (Ionita, a (Ionita, a (Ionita, a další, 2009) další, 2009) další, 2009) další, 2009) Počty citací byly zaokrouhleny na relevantní řád, protože v čase stoupají (zaokrouhlení k datu ). V případě vyhledávače EBSCO je zmíněn první nejrelevantnější autor, tedy publikace týkající se cílové oblasti. Z pohledu přítomnosti v citačních rejstřících jsou na předních místech podstatné publikace a články, s výjimkou klíčového slova kompozitní 13

14 aplikace, které je spojováno zejména s technologií materiálů a chemickými odvětvími. Přesto je možné říci, že oblast je významná a k jejím klíčovým slovům jsou dostupné významné a uznávané informační zdroje. Jak ukazuje Tab. 1, nejčastěji citovaným autorem je Erl, který problematiku rozebírá v publikacích (Erl, 2005) a (Erl, 2007). Pohled a přístupy k řešení servisně orientované architektury, služeb a kompozitních aplikací, proto (tedy) budou podrobně popsány v následujícím textu. Ve zkratce je však možné říci, že principy, které Erl v (Erl, 2005) a v (Erl, 2007) popisuje, jsou použitelné obecně, nicméně při konstrukci kompozitních business služeb se předpokládá použití standardu webových služeb. Často citovaný autor je také Rao, který se ve svém referátu (Rao, a další, 2005) zabývá implementačními problémy při zavádění servisně orientované architektury. V zásadě popisuje, jak je možné pomocí standardu webových služeb komponovat kompozitní business služby. Je možné říci, že podporuje Erlova technologická doporučení. Dalším často citovaným autorem je Papazoglou a jeho článek (Papazoglou, a další, 2007), který se zabývá servisně orientovaným pohledem na podnikovou informatiku (service oriented comuputing). Vychází podobně jako Erl z toho, že sestavování aplikačních komponent z nezávislých služeb vede k flexibilním podnikovým procesům a pružným aplikacím. Často se však Papazoglou shoduje s Erlem, a to jak v principech, tak v doporučovaných způsobech implementace. Vysokou preferenci principů v rámci servisně orientované architektury, jaké deklaruje Erl, potvrzuje i Yu ve svém článku (Yu, a další, 2007), kde se opět ke kompozici využívá standardu webových služeb a jemu přidružených prostředků. Na základě rešerše dostupných odborných zdrojů a názorů je možné v základních principech pro servisně orientovanou architekturu inklinovat k principům a doporučením, které popisuje Thomas Erl a vycházet z jeho publikací a článků. Problematikou se však také zabývají diplomové kvalifikační práce. Kvalifikační práce vycházejí z různých předpokladů pro konstrukci servisně orientovaných infrastruktur, služeb a jejich kompozici. (Kočí, 2007) Vychází z principů, které pro servisně orientovanou architekturu vymezuje (Krafzig, a další, 2005). Pro kompozici služeb pak zmiňuje technologii Java Enterprise Service Bus Suite. (Vančura, 2008) se zabývá možnostmi 14

15 automatizace workflow, a ačkoliv praktickou část demonstruje na platformě MS Windows Workflow Foundation, v souvislosti s problematikou kompozitních aplikací zmiňuje také technologii xapps od společnosti SAP. (Kmínek, 2009) vychází pro definování servisně orientované architektury z (ZapThink, 200x). Pro kompozici služeb pak využívá standardů webových služeb a jazyka BPEL a demonstruje jejich možnosti na platformě MS BizTalk Server. Vývojem kompozitních aplikací se ve své práci zabývá (Malik, 2008). Ten s využitím servisně orientované architektury a kompozitních aplikací postavených na technologii xapps od společnosti SAP a principech definovaných v rámci ESA čerpal informace z (Arsanjani, 2005). (Koten, 2010) popisuje služby, které byly implementovány v rámci bankovní společnosti a které jsou založeny na principech servisně orientované architektury. Pro jejich zásady čerpal z (Erl, 2007) a pro jejich kompozici z (IBM, 2009). (Randová, 2010) se ve své práci zabývá využitím servisně orientované architektury v rámci podnikové aplikační infrastruktury a pro její definici a vymezení služeb vychází z (Sprott, a další, 2004), (Erl, ), (Gála, a další, 2009) a (Voříšek, 2008). (Burian, 2010) se také zaměřuje na možnosti servisně orientované architektury v podnikové infrastruktuře, zejména pak kompozitními službami a jejich přínosy pro podnikové procesy. Pro jejich vymezení pak využívá možností standardu webových služeb, tak jak je popisuje konsorcium W3C. (Michalička, 2008) se zabývá dopadem servisně orientované architektury na informační systémy od společnosti SAP. Vychází z informací, které společnost SAP poskytuje k rámci ESA, a k definici kompozitních služeb postavených na technologii xapps. (Sova, 2009) se ve své práci zabývá standardizací a orchestrací služeb v rámci kompozitních služeb. Pro jejich vymezení a definovaní využívá (Erl, 2009). (Fischer, 2009) se ve své práci zabývá tvorbou kompozitních služeb pomocí standardu webových služeb. Využívá však pro jejich konstrukce platformy WCF (Windows Communication Foundation) a pro její použití vychází z (Bechynský, 200x). Rešerše kvalifikačních prací potvrdily závěry vycházející z analýzy citačních rejstříků a fulltextových vyhledávačů. Pro konstrukci kompozitních business služeb se nejčastěji upřednostňuje standard webových služeb a pro jejich návrh se častěji používají názory Thomase Erla. Nicméně tyto závěry obohatily o další poznatky, jako je existence derivátu servisně orientované architektury, který je často používán v souvislosti s platformou SAP, jenž se nazývá ESA, nebo existenci alternativní platformy pro konstrukci kompozitních business služeb WCF. 15

16 3 SLUŽBY A JEJICH KOMPOZICE 3.1 OBECNÝ POHLED NA SLUŽBY A JEJICH VLASTNOSTI Problematika služeb je nesmírně rozsáhlá, zejména v současnosti, kdy terciární sektor ekonomiky roste rychleji než zbylé tři a služby jsou oblíbeným způsobem podniků, jak zvýšit svoji konkurenceschopnost na trhu. Podniky mohou v zásadě nabízet buď produkty, nebo služby. Často jsou nabízeny v kombinaci. Je poměrně jednoduché rozeznat, co je výrobek a co je služba. Co už však není snadné, je jak služby samy o sobě definovat, jak služby vymezit a jak služby rozdělovat. Těmito otázkami se podrobně zabývá publikace (Ramachandra, a další, 2010), kde je u služeb posuzována vazba na produkty a formy, v jakých je možné služby rozeznávat. Služby jsou popsány pomocí základních charakteristik, které jsou dle (Ramachandra, a další, 2010) následující: 1. Služby jsou nedotknutelné 2. Služby jsou nerozlučné 3. Služby jsou proměnlivé 4. Služby mají krátkou dobu trvanlivosti 5. Služby není možné vlastnit Jednotlivé rysy služeb, jak je popisuje (Ramachandra, a další, 2010), jsou popsány v následujícím textu pomocí srovnání s fyzickým zbožím, jako jsou například výrobky. Nedotknutelností služeb se rozumí skutečnost, že služba není fyzicky hmatatelná, jedná se o abstrakci, jež nemůže být realizovaná dříve, než je zakoupena. Také se nedotknutelností rozumí fakt, že není možné si ověřit kvalitu služby před nákupem, například na rozdíl od zboží, které je možné prohlédnout. Nerozlučností služeb se rozumí nerozlučnost výroby a spotřeby. Zboží jako takové je vyrobeno a následně transportováno na místo, kde jej zákazník obvykle koupí. Tento systém také umožňuje centrální kontrolu kvality apod. Toto ovšem u služeb není možné. Služba je totiž de facto produkována během její spotřeby. Poskytovatel služby (její výrobce) a spotřebitel (zákazník) musí být obvykle v přímém kontaktu během spotřeby služby, a tedy i její produkce, aby zákazník získal předpokládané přínosy služby. 16

17 Proměnlivostí služeb se rozumí zejména rozdíly ve výstupech služby. Vzhledem ke skutečnostem, že služby pokrývají požadavky a potřeby jejich konzumentů a že tyto požadavky a potřeby se liší u každého konzumenta a také že konzument je součástí výrobního procesu služby, je velmi pravděpodobné, že výstupy jedné služby pro různé konzumenty budou naprosto stejné. Krátkodobost služeb souvisí s nemožností služby skladovat. Na rozdíl od zboží a výrobků, které jsou fyzické a hmatatelné a je možné je hromadit. Je to výsledkem skutečnosti, že produkce služeb je vázána na požadavky konzumentů a jejich požadované výstupy nemají fyzický charakter. Nemožnost vlastnit služby vychází z jejich nedotknutelnosti a krátkodobosti. Služba je provedena jejím poskytovatelem a nedochází k přesunu vlastnických práv z prodejce na nakupujícího jako například při nákupu zboží. 3.2 ZÁKLADNÍ KRITÉRIA PRO ČLENĚNÍ SLUŽEB Kromě obecných vlastností služeb, (Ramachandra, a další, 2010) také definuje základní kriteria pro jejich klasifikaci. Opět často dochází k analogii s prodejem výrobků a zboží, případně k posuzování služeb na základě jejich vazby vůči fyzickým výrobkům. Posuzuje se: 1. roveň nedotknutelnosti služeb; 2. rozdíl mezi producentem a konzumentem služeb; 3. status služeb v rámci celkové produktové nabídky; 4. míra nerozlučnosti; 5. model dodávky služeb; 6. míra orientace na člověka; 7. význam služeb pro prodejce; 8. prodejnost a neprodejnost služeb. Úroveň nedotknutelnosti služeb souvisí především se způsobem a podmínkami, za kterých jsou služby dodávány. Úzce souvisí s marketingovým mixem pro služby. Ten má za úkol identifikovat, jak velká rizika u služeb vnímá potencionální konzument služeb, a podle toho definovat způsob propagace, dodávky a podmínky poskytování služeb. Konzumentem služby se rozumí jednotlivec, který poskytovanou službu používá pro vlastní potřeby a spotřebovávání služby nevede k ekonomickému zisku. Na rozdíl od producenta 17

18 služby, který je často najatý podnikatelským subjektem, který od něj služby nakupuje, má producent z poskytování služby ekonomický zisk. Statutem služeb v rámci celkové produktové nabídky se rozumí skutečnost, že služby jako takové jsou často spjaty s produktem a tvoří jakousi přidanou hodnotu, která zvyšuje konkurenceschopnost výrobku. Nebo naopak mohou být prodávány odděleně jako nadstandardní možnost k výrobku. Případně mohou být samostatným objektem prodeje. Mírou nerozlučnosti se u služeb posuzuje potřeba přítomnosti konzumenta služby při její produkci. Zdali je nezbytná přítomnost konzumenta u producenta, do jaké míry je možné oddělit konzumaci služby a produkci služby apod. Modelem dodávky služeb se rozlišuje spojitost produkce a konzumace služby. Jestli je služba poskytována a konzumována nepřetržitě nebo zdali je konzumace služby nárazová, a tedy podmíněna pouze aktuální potřebou. Mírou orientace služeb na člověka se rozumí potřeba lidské síly na dodávku služby. Opět souvisí, jestli konzument musí při konzumaci služby být v přímé interakci například se zaměstnanci producenta nebo zdali je možné celou dodávku zautomatizovat. Významem služeb pro producenta se rozumí frekvence a objem služeb, jaký je konzumován. Obvykle platí, že služby, které jsou konzumovány v krátkých pravidelných intervalech, jsou levnější, konzumují se rychle a jejich nákupu nepředchází nijak zvlášť komplexní rozhodovací proces. Na druhé straně pak stojí služby, které se konzumují nepravidelně, jedná se o služby, které jsou náročnější na lidský kapitál, dodávají komplexnější výstupy a jejich nákupu předchází také náročnější rozhodovací proces. Členěním služeb na prodejné a neprodejné rozděluje služby na ty, které jsou poskytovány veřejnosti například vládou a jejich dodávání je financováno z daní, tedy veřejné služby, a pak na ty ostatní. Mezi neprodejné služby jsou zařazeny často služby, které jsou poskytovány plošně a u kterých je nemožné nebo náročné omezit přístup těm, kteří by nebyli ochotni se podílet na jejich financování. 3.3 KOMPOZICE SLUŽEB Kompozicí služeb se v obecném měřítku myslí vzájemná integrace heterogenních služeb, které pak tvoří celky s přidanou hodnotou pro konzumenty a lepší ekonomické podmínky pro producenty služeb. 18

19 Na příkladu finančních a pojišťovacích služeb tento trend ukazuje (Daňhel, a další, 2006). Pojišťovny se integrují a slučují s bankovními a dalšími finančními institucemi a tvoří tzv. bankopojišťovny. Tyto instituce využívají příbuzného oboru podnikaní, podobné kapitálové struktury a výhod, které jejich spojování přináší. Dle (Daňhel, a další, 2006) se jedná o následující efekty: pojišťovny využívají bankovních systémů pro inkaso pojistného a výplatě pojistných plnění; banky využívají produktů pojišťoven pro snížení vlastního rizika; využívání vlastních prodejních kanálů a sítí pro nabídku partnerských společností; integrace bankovních a pojistných produktů a služeb do bankopojišťovacích celků. Právě integrace bankovních a pojistných produktů je kompozice služeb. V rámci kompozice se dle (Daňhel, a další, 2006) nejčastěji objevují následující služby: běžný účet a platební styk; spořící a investiční instrumenty; různé typy půjček a úvěrů; všechny typy životního a neživotního pojištění; nástroje řízení rizika; právní a poradenské služby. Jako příklad kompozice služeb je možné uvést pravděpodobně nejznámější bankopojišťovací produkt, kterým je životní investiční pojištění. V tomto produktu se kloubí krytí rizik, jako jsou úrazy, ztráta zaměstnání, pracovní neschopnost apod. pomocí pojištění, s bankovními produkty, jako jsou podílové fondy. Dalším příkladem může být běžný bankovní účet, ke kterému je poskytnuta platební karta, která má na sebe navázané pojištění zneužití karty, úrazové nebo cestovní pojištění a další pojistné produkty za poplatek, případně v rámci poplatku za vedení účtu. Nabídka těchto subjektů pak dostane nový rozměr variability a atraktivnosti. Zejména výše zmíněné investiční životní pojištění může kombinovat celou řadu doprovodných parametrizovatelných služeb, které v očích zákazníka mohou výrazně zvýšit atraktivitu takovéhoto produktu. 19

20 Mimo finanční sektor je možné se s kompozicí služeb setkat například u mobilních operátorů, kdy na základě kombinace více jejich služeb je možné získat zajímavější cenu nebo získat produkty jako mobilní telefony nebo jiné bonusy a dárky. Mobilní operátoři tyto kombinace často nazývají balíčky služeb. Takovéto balíčky jsou pak příkladem kompozice obecných služeb. S kompozicemi služeb je potom možné se setkat prakticky v každém, ať už maloobchodním, nebo velkoobchodním, odvětví. 3.4 SLUŽBY A JEJICH KOMPOZICE V RÁMCI PODNIKOVÉHO ICT Služby v kontextu podnikové informatiky se nazývají ICT služby. Definice ICT služby jsou různé. Pro jejich vymezení je však možné použít následující definice, které ICT služby popisují relativně konkrétně. Dle (Voříšek, 2004) jsou ICT služby aktivity a/nebo informace, dodávané poskytovatelem ICT služby příjemci (odběrateli, zákazníkovi) služby. Dle (Gála, 2006) je služba informatiky (je) abstrakcí nějaké entity informatiky, kterou reprezentujeme schopnost entity realizovat úlohu, mající z pohledu poskytovatele i příjemce služby koherentní funkcionalitu. Aby mohla být služba informatiky použita, musí být realizována nějakým konkrétním zdrojem poskytovatele a akceptována vhodným receptorem příjemce.. Podobnou definici pak uvádí ve svém pozdější práci i (Voříšek, 2008), konkrétně že ICT služby jsou koherentní aktivity a/nebo informace dodávané poskytovatelem ICT služby příjemci služby. ICT služba je vytvářena ICT procesy, které při svém průběhu konzumují ICT zdroje (hardware, software, data, lidé). Služba realizuje na základě dohodnutých obchodních a technických podmínek.. S definicí uvedenou v (Voříšek, 2008) je v rozporu (Hrabě, 2010), který tvrdí, že informace sama o sobě nemůže být službou, nýbrž v kontextu svého článku informací rozumí dílčí část metamodelu architektury. V definici, co je to služba v rámci ICT, se potom opírá o (O'Sullivan, a další, 2002), (Schekkerman, 2008) a (The, 2009). Na základě těchto zdrojů pak (Hrabě, 2010) vyslovuje definici služby, která říká, že služba je nehmotná aktivita (funkce) přinášející přidanou hodnotu, vykonává poskytovatelem pro příjemce na základě jeho požadavku a v souladu se vzájemnou dohodou (smlouvou) o parametrech služby. 20

21 Jednotlivé definice ICT služeb také ukazují, že se svým charakterem a vlastnostmi blíží službám, které popisuje (Ramachandra, a další, 2010). ICT služby jako takové jsou (tedy) samostatnou podmnožinou služeb obecných a základními vlastnostmi a principy si vzájemně odpovídají. Z uvedených definic vyplývá, že v moderním chápání služby jsou služby v naprosté většině případů chápány jako výsledek podnikového procesu. V případě ICT služeb se jedná o výstupy ICT procesů, které skrze vyprodukované ICT služby podporují konkrétní business procesy, jak to ilustruje Obr. 1. Ten znázorňuje, jak jsou zdroje informatiky propojeny s business procesy. Obr. 1: Propojení zdrojů podnikové informatiky a business procesů pomocí ICT služeb (Voříšek, 2008) Členěním ICT služeb se podrobně zabývá (Voříšek, 2008). Jedná se o následující definované kategorie a typy ICT služeb: 1. Dle předmětu služby o Služby informační o Služby aplikační o Služby infrastrukturní o Služby vývojové o Služby podpůrné o Služby smíšené 2. Dle způsobu spotřeby služby o Služby s jednorázovou spotřebou 21

22 o Služby s kontinuální spotřebou (nebo také disponibilitou) o Služby s diskrétní spotřebou (nebo také nárazovou nebo nespojitou spotřebou) 3. Dle příjemce služby o Služby x2c (služby pro zákazníky) o Služby x2b (služby pro podniky) o Služby x2a (služby vůči státní správě a administrativě) o Služby kombinovaného typu 4. Dle typu poskytovatele služby o Interní útvar ICT o Externí poskytovatel 5. Kategorizace podle potřebných zdrojů a znalostí poskytovatele služby o Instalace a dimenzování ICT struktury o Vývoj a instalace, customizace a integrace software o Provoz a správa hardware a software o Zpracování, publikování a poskytování dat o Poradenství v oblasti ICT První tři kategorie pro členění ICT služeb částečně kopírují kriteria pro členění služeb v obecném pohledu dle (Ramachandra, a další, 2010). Čtvrtá a pátá kategorie je potom specifická pro ICT služby a tato kriteria rozšiřuje. Výčet kriterií pak ilustruje komplexnost celé problematiky. Nicméně (Hrabě, 2010) se rozchází s (Voříšek, 2008) i v oblasti kategorizace služeb dle předmětu služby, když tvrdí, že vývojové a podpůrné služby jsou vlastně procesy, které vytváří výstupy podnikového ICT, případně externího dodavatele, ve formě odpovídající komerčním službám, které podniky nabízí za úplatu svým klientům. Tudíž zpochybňuje jejich zařazení mezi ICT služby, protože se dle něj jedná o služby obecného charakteru. Rozpor je také u zařazení informačních služeb mezi ICT služby. Jak bylo popsáno výše, dle (Hrabě, 2010) by informace jako taková neměla být předmětem služby. (Hrabě, 2010) pak potvrzuje shodu mezi (Voříšek, 2008) a prameny v jeho práci při členění ICT služeb na aplikační a infrastrukturní, někdy nazývané jako platformou služby. Přístupů, které berou v potaz existenci služeb a začleňují je do svých pohledů jak na business, tak na informatiku, existuje celá řada. Takové přístupy pak lze nazývat service oriented neboli zaměřené na služby. Tyto přístupy pak vidí služby a zejména pak ICT služby jako jeden ze 22

23 svých klíčových faktorů. Jeden z takových přístupů, který se při řešení podnikové informatiky zakládá na službách a ne pouze na ICT službách, je servisně orientovaná architektura a další, které jsou popisovány v dalším textu. Velmi obecnou definici pro přízvisko service oriented poskytuje (Schekkerman, 2011), který orientaci a služby přirovnává k pohledu, kdy jsou zdroje členěny na definované, jasně ohraničené a neprovázané služby. Mnohem konkrétněji tento termín vysvětluje (Erl, 2007), který vymezuje termín service orientation neboli orientaci na služby, a to jako návrhové paradigma, které zahrnuje specifickou množinu návrhových principů, které vedou řešení pomocí služeb, kdy službou se rozumí fyzicky nezávislá část software, která podporuje konkrétní cíl v rámci service oriented computing (přeneseně lze přeložit jako model provozování informatiky zaměřený na služby). Se service oriented computing pak (Erl, 2007) chápe jako novou generaci distribuovaných modelů pro řízení informatiky, který definuje nová návrhová paradigmata a návrhové principy, architektonické modely, představy, technologie a frameworky zaměřených na služby. Není však cílem teď striktně vymezit, co je to service oriented a co je to service oriented computing. Klíčovým faktem je, že v těžišti těchto dvou termínů jsou služby, které splňují určité vlastnosti, kterými se zabývá tato práce. Kompozice ICT služeb lze na základě předchozích definic chápat jako prostředek pro optimální podporu podnikových procesů. Ovšem samotná kompozice služeb probíhá i na dalších úrovních. Například pokud se bude i k ICT zdrojům přistupovat jako ke službám, je možné říci, že ICT služba založená na těchto zdrojích, je již komponovaná služba. Ke kompozici služeb a ne pouze ICT služeb, je možné přistupovat jako k implementaci logiky pro řešení rozsáhlého problému, jak je ukazuje (Erl, 2007). Tento přístup je možné vidět na Obr. 2. Tento obrázek ukazuje, jak pomocí kompozice služeb je možné vyřešit rozsáhlý problém, kdy po identifikaci rozsáhlého problému jej dekomponujeme na dílčí problémy, které je možné řešit již dostupnými nebo dosažitelnými prostředky (službami) a jejich správnou kompozicí získat komponovanou službu, která dokáže takovýto rozsáhlý problém vyřešit. 23

24 Obr. 2: Obecný pohled na kompozici služeb pro řešení rozsáhlého problému (Erl, 2007) 3.5 SHRNUTÍ POZNATKŮ O SLUŽBÁCH A JEJICH KOMPOZICI Při obecném pohledu na problematiku služeb je možné vycházet z analogie se zbožím. Jsou-li srovnávány služby a zboží, je možné identifikovat řadu společných znaků a také řadu specificky rozdílů. Na základě těchto odlišností je potom možné identifikovat specifické 24

25 vlastnosti služeb, na jejichž základě je možné služby klasifikovat. Také je nutné ke službám přistupovat specifickým způsobem, ať už z pohledu producenta služeb, nebo jejich konzumenta. U služeb se potom posuzuje zejména jejich vazba na celkové produktové portfolio producenta služby, respektive výrobce zboží apod. Také způsob propagace, dodávky a prodeje služeb a náročnost na infrastrukturu případně lidský kapitál. Důležitým parametrem je také to, do jaké míry služby vyžadují zapojení konzumentů do produkce služeb. Například je z tohoto pohledu rozdíl poskytovat kosmetické služby koncovým zákazníkům, anebo poskytovat službu jako rádiová stanice. Oba typy služeb vyžadují diametrálně odlišnou míru zapojení konzumenta do produkce služby. Kompozice služeb je pak nedílnou součástí dnešního podnikatelského života. Nové kompozitní produkty, které se skládají z různých typů produktů a různých typů služeb, mají přidanou hodnotu a jsou v očích zákazníků velmi atraktivní. Protože jsou služby jako takové obvykle parametrizovatelné, jsou tyto produkty velmi flexibilní jak z pohledu prodejní strategie, tak z pohledu vývoje poptávky. Ne jinak na tom (ne)jsou služby v rámci podnikového ICT neboli ICT služby. ICT služby jako takové mají s obecnými službami společnou celou řadu znaků a také vlastní specifické znaky. Je tedy možné říci, že ICT služby jsou podmnožinou služeb obecných a jedná se o specifický druh služeb, který má vlastní vlastnosti a členění. A stejně tak jako u obecných služeb je možné ICT služby komponovat, a to buď s jinými službami, nebo fyzickým zbožím. Kompozicí ICT služeb se však zabývá následující text. 25

26 4 STANDARDY A PRINCIPY PRO KOMPOZICI SLUŽEB Standardizace služeb a jejich kompozice je zásadní problematikou v moderním pojetí podnikového IT, které je orientované na služby, protože vysoká standardizace služeb vede k nákladově efektivnějšímu řízení, ale je také často spojeno s vyššími počátečními investicemi. ICT službami se z pohledu standardizace zabývá i Mezinárodní standardizační organizace (ISO, International Organization for Standardization), která vymezuje celou řadu ISO standardů, které upravují řízení (management) a dohled (governance) v rámci podnikového ICT. Z pohledu řízení a dohledu nad servisně orientovanými prostředími podnikového ICT jsou nejrelevantnější standardy ISO 8 420, ISO , ISO/IEC , ISO/IEC , ISO/IEC a ISO/IEC Na těchto standardech jsou pak postaveny nejrozšířenější standardy pro řešení řízení a dohledu podnikového ICT založeného na službách, kterými jsou ITIL (Information Technology Infrastructure Library), COBIT (Control Objectives for Information and relater Technology) a TOGAF (The Open Group Architecture Framework), na který ve své práci v souvislosti s řízením služeb odkazuje (Hrabě, 2010), a které proto budou v této práci analyzovány. Celkový pohled na vazby mezi těmito standardy, ISO standardy a metodikami pro budování služeb zobrazuje Obr. 3. Obr. 3: Vazba mezi ISO standardy, standardy pro řízení ICT a podnikovými metodikami pro budování služeb (Autor) 26

27 Obr. 3 zobrazuje, jak jsou de jure ISO standardy uplatňovány pomocí de facto standardů, které se v podnicích a organizacích používají a které své principy aplikují v rámci podnikových metodik na způsob konstrukce a podoby ICT služeb. Základním standardem je v tomto případe standard ISO/EIC , který přímo vymezuje zásady pro řízení služeb (Service Management) a je metodickým základem pro standard ITIL, TOGAF i COBIT (Office, 2007), (The, 2009) a (IT, 2007). Dále mají tyto tři de facto standardy společné využití standardů ISO/IEC a ISO/IEC , které jsou úzce provázané a definují zásady pro proces nepřetržitého zlepšování služeb (continual service improvement) a základních principů bezpečnosti služeb (Office, 2007), (The, 2009) a (IT, 2007). Standard TOGAF dále zmiňuje standard ISO , který definuje, jakým způsobem mají být informace o produktech vyměňovány. (The, 2009) V souvislosti se službami je důležitý také standard ISO 8 420, který standardizuje způsob, jakým specifikovat kvalitu služeb (QoS) a který v sobě obsahuje samotná servisně orientovaná architektura. (Wahli, 2007) Pro samotný dohled na podnikovým IT (IT Governance) je pak klíčový standard ISO/IEC , který se dohledem přímo zabývá. (ISO/EIC, 2008) Vazba je však, jak je znázorněno na Obr. 3, vzájemná. Dochází tedy k úpravám de jure standardů na základě podmětů ze strany standardů de facto, podobným způsobem jsou standardy de facto ovlivňovány ze strany podnikových metodik. Také je znázorněno, na jaký pohled je de facto standard primárně určen. Kdy standard ITIL se orientuje zejména na pohled Management a standard COBIT společně se standardem TOGAF zejména na Governance. Je také zřejmé, že samotnou servisně orientovanou architekturu je rozumné považovat za určitý obecný standard, který přináší určité zásady, z něhož pak vycházejí určité konkrétní podnikové metodiky a prostředky, které umožňují servisně orientovanou aplikační infrastrukturu budovat. Zbývající části práce se zabývají standardy, doporučeními a způsoby kompozice služeb, které mají za úkol dodávat aplikační funkcionalitu neboli služby, které (Voříšek, 2008) a (Hrabě, 2010) nazývají službami aplikačními. Z hlediska terminologie je důležité zmínit, že se jedná o komponované služby, které mají přímou vazbu na business, a proto jsou v dalších částech práce nazývané kompozitní business služby. Cílem následující části práce je sumarizovat a definovat vlastnosti kompozitních business služeb/kompozitních aplikací, jejichž návrh a kompozice jsou výsledkem přístupů orientovaných na služby (service oriented). 27

28 4.1 SOA JAKO OBECNÝ STANDARD PRO KOMPOZITNÍ BUSINESS SLUŽBY Servisně orientovaná architektura, také označovaná zkratkou SOA, není samostatným metodickým rámcem, který by se systémovou integrací přímo zabýval. Jedná se spíše o souhrn doporučení a principů, jak organizovat prostředky ICT v rámci organizace. Přičemž pojmy ICT (Gála, 2006) definuje jako soubor technických (hardwarových) prostředků, programového (softwarových) vybavení a prostředků pro vzájemnou komunikaci programového a aplikačního vybavení rozmístěného v rámci infrastruktury naprosto transparentně. Zjednodušeně lze říci, že servisně orientovaná architektura staví na předpokladu, že funkcionalita podnikových informačních systémů nebo podnikových aplikací je reprezentována službami, které by měly být uspořádány na základě podnikových procesů a ne naopak SLUŽBY V RÁMCI SOA Samotný pojem služba je v kontextu servisně orientované architektury chápán různými způsoby. Protože jsou služby a celé paradigma služeb těžištěm celé servisně orientované architektury, jsou v následujícím textu uvedeny některé definice služeb, které se servisně orientovanou architekturou korespondují. Dle (Feuerlicht, 2008) mezi hlavní znaky servisně orientované architektury patří: Služby jsou abstraktní služby jsou logický pohled na aplikace, databáze, podnikové procesy apod., který je zobrazuje tak, aby s nimi bylo možné provádět operace na business úrovni. Orientace na komunikaci pomocí zpráv služby jsou definované na základě zpráv, které si vyměňují poskytující agenti s konzumujícími agenty, přičemž vnitřní struktura agentů je skrytá. Popis služeb služby jsou popsány pomocí metadat, které je možné zpracovávat automaticky; zároveň platí, že jsou v popisu služby obsaženy pouze takové informace, které jsou důležité k jejímu provozování a definování funkcionality, kterou poskytuje. Granularita služby poskytují a provádějí pouze malé množství operací, ale komunikují mezi sebou pomocí relativně složitých a objemných zpráv. Použití služeb převážně přes počítačovou síť zprávy jsou doručovány zejména pomocí počítačové sítě. 28

29 Nezávislost na platformě zprávy jsou platformě neutrální, vysoce standardizované a doručovány na základě rozhraní; zpravidla jsou posílány ve formě XML dokumentu. Publikace (Feuerlicht, 2008) odkazuje na (Heffner, 2007), kde je definice servisně orientované architektury konkrétnější: Aplikace jsou organizovány do business služeb (které jsou vyžívány, jednotlivými podnikovými pracovními celky), které jsou obvykle dostupné přes počítačovou síť. Definice rozhraní služby musí mít stejně kvalitní návrh jako například databáze nebo aplikace. Každá služba má jasně definované charakteristiky, které vymezují kvalitu služby (QoS), mezi které patří: bezpečnost, transakce, výkon, způsob interakce mezi jinými službami, apod. Softwarová infrastruktura je aktivně zodpovědná za řízení přístupu ke službám, jejich provádění a udržování jejich kvality (QoS). Služby a jejich metadata jsou katalogizovány v service repository, kde jsou dosažitelné pomocí nástrojů pro jejich vývoj a správu. Protokoly a struktury v rámci infrastruktury jsou realizovány zejména pomocí obecně přijatých standardů. Tyto základní rysy a vlastnosti služeb v rámci servisně orientované architektury potvrzuje (Erl, 2007), který je nadále rozšiřuje o další a sumarizuje následovně (jedná se o zestručněné definice): Standardizovaný kontrakt služby který spojuje informace o rozhraní a definici kvality služby, které byly vymezeny zvlášť v předchozích vlastnostech dle (Heffner, 2007). Nízká provázanost služeb je založena na faktu, že služba je navržena takovým způsobem, aby mohla být nahrazena jinou bez ovlivnění funkcionality jiných služeb. Abstrakce služeb - je založena na faktu, že služba se snaží skrývat veškeré detaily a informace o ní samotné kromě informací obsažených ve vlastním kontraktu. Znovupoužitelnost služeb je založena na faktu, že návrh služeb a procesů je proveden takovým způsobem, aby službu bylo možné používat v různých kontextech podnikových potřeb a nedocházelo k nadbytečným duplicitám ve službách. 29

30 Autonomnost služeb je založena na faktu, že služby musí být schopny provádět svoje úlohy samy o sobě bez ohledu přítomnosti jiných služeb, které přímo nevyužívá. Bezestavovost služeb je založena na faktu, že služba sama o sobě si nepamatuje operace, které pomocí ní byly provedeny dříve, ale tyto informace jsou dostupné mimo tuto služby v rámci jejího prostředí. Dosažitelnost služeb je založena na faktu, že služba je lehce popsatelná, znovupoužitelná, zařaditelná a dokáže charakterizovat sama sebe. Komponovatelnost služeb je založena na faktu, že služby jsou navržené takovým způsobem, aby spolu mohly dynamicky spolupracovat takovým způsobem, aby pokryly aktuální potřeby businessu. Na základě těchto rysů, lze identifikovat základní vlastnosti služeb v rámci servisně orientované architektury: Služby mohou ve své funkcionalitě využívat jiných služeb a samy pak mohou být použity v rámci jiné služby neboli je možné je vzájemně komponovat. Služby mají definované rozhraní/kontrakt, které specifikuje, jaké informace služba vyžaduje a jaký bude výstup této služby. Služby mají ve svém rozhraní/kontraktu popsány své kvalitativní parametry. Služby mohou být vystaveny, aniž by musely samy řešit, jak budou přístupné nebo jak se bude řídit jejich kvalita. Služby jsou zařazeny do nativního servisního úložiště služeb. Služby respektují standardy v rámci podnikové informatiky TYPY SLUŽEB V RÁMCI SOA Vlastnosti služeb definované v předchozím textu jsou přijatelné v obecné rovině. Jednou z klíčových vlastností služeb v rámci servisně orientované architektury je jejich komponovatelnost, která je také těžištěm této práce. Komponovatelnost služeb je založena na abstraktním rozdělení služeb do typů a vrstev, což přináší flexibilitu, optimální podporu podnikovým procesům a oddělení business a aplikační logiky. Přehledný a srozumitelný model, který vysvětluje vrstvy, do kterých se služby rozdělují, a komponovatelnost služeb ukazuje (Erl, 2007) na Obr

31 Služby jsou zde rozděleny do tří základních vrstev, které odpovídají třem základním typům, které (Erl, 2007) v rámci servisně orientované architektury rozlišuje. Jsou to následující typy služeb: Task Service jedná se o business službu, která má svoji funkcionalitu spojenou přímo s určitou podnikovou funkcí nebo procesem. Tyto služby jsou obvykle méně znovupoužitelné, často jsou v pozici kontrolního prvku a komponují v sobě jiné služby s méně komplexní funkcionalitou. Jako příklad dává (Erl, 2007) službu, která se jmenuje Analýza zisku, má funkci Podat a zapouzdřuje v sobě celý business proces analýzy. Entity Service reprezentuje business službu, která má svoji funkcionalitu a kontextem svázaný s určitou business entitou nebo business objektem. Příkladem takové business entity nebo objektu může být zákazník, zaměstnanec, faktura apod. Business objekt nebo business entitu také definuje (Gavin, a další, 2005) jako datovou šablonu, která reprezentuje a popisuje určitou entitu nebo objekt, se kterou pak je možné pracovat jako se samostatným celkem. Jedná se o službu s vysokou mírou znovupoužití, protože se používá napříč podnikovými procesy. Utility Service jsou služby, které nejsou přímo svázány s business logikou nebo podnikovými procesy. Jedná se o vysoce znovupoužitelné služby, které jsou spjaty s podnikovými aplikacemi a zastřešují jejich funkcionalitu, která není důležitá pro business logiku a podnikové procesy. Jedná se například o logování, notifikace nebo zpracování výjimek a chyb. Obr. 4: Typy služeb v jednotlivých vrstvách (Erl, 2007) Názorně pak příklad kompozice v rámci jednodušší task služby ukazuje Obr

32 Task služba v sobě zapouzdřuje dvě entity služby a jednu utility službu. Mohlo by například jít o příklad podnikového procesu, ve kterém jsou použité business entity zákazník a ve kterém může být například komponenta pro logování transakce do databáze. Task služba je pak dle (Erl, 2007) chápána jako kompozitní business služba. Kompozitní business službu nebo také kompozitní aplikaci definuje (Erl, 2007) jako kompozici služeb, která obsahuje jiné služby, aby automatizovaly podnikový proces. Obr. 5: Příklad kompozice služeb (Erl, 2007) 4.2 ESA A KOMPOZITNÍ BUSINESS SLUŽBY V rámci této práce je ESA (Enterprise Service Architecture) důležitá zejména z toho důvodu, že v experimentu je využitý informační systém společnosti SAP, pro který je, jak je zřejmé na základě rešerše odborných informačních zdrojů a kvalifikačních prací, ESA optimalizovaná. A ačkoliv je ESA v celkovém pohledu na vazby mezi standardy de jure, de facto a metodikami pro konstrukci služeb zařazena mezi metodiky kromě technických prostředků pro kompozici služeb, popisuje i zásady a principy, které je možné při kompozici služeb používat a řídit se jimi. Z těchto důvodu je důležité tuto metodiku při definovaní standardů pro kompozici služeb popsat a prozkoumat její pohled na konstrukci kompozitních business služeb. ESA je metodika vytvořená softwarovou společností SAP, která vychází ze servisně orientované architektury. ESA není samostatný produkt, který by bylo možné zakoupit, ale (Woods, a další, 2006) jej spíše přirovnává k blueprintu. Blueprint je dle (Wikipedia, 2009) 32

33 definovaný jako technický nákres, architektonická dokumentace nebo inženýrský návrh, který je možné použít jako detailní plán. ESA doporučený framework pro vývoj aplikací a budování integračních řešení na platformě SAP NetWeaver. ESA není technologicky závislá na tomto produktu, nicméně je pro tento produkt optimalizovaná a předpokládá použití modelovacích a vývojových nástrojů přímo dodávaných s platformou SAP NetWeaver nebo doporučených společností SAP. Jedná se o nástroje jako ABAP Workbench, NetWeaver Visual Composer, modelovací nástroj ARIS a další (Woods, a další, 2006). ESA tedy oproti samotné servisně orientované architektuře přináší mnohem konkrétnější doporučení a postupy, jak kompozitní business služby vytvářet SLUŽBY V RÁMCI ESA Jak bylo poznamenáno výše, ESA přímo vychází ze servisně orientované architektury. Má tedy i podobné členění služeb. (Woods, a další, 2006) zmiňuje následující typy služeb, které se v rámci ESA rozlišují: Process Service jedná se o službu, která spouští podnikový proces a řídí jeho konzistentní provedení. Component Service jedná se o službu, která udržuje kontext v podobě vztahů, dat a externích informací, které jsou důležité pro určitou business funkci. Obvykle se jedná o sady pravidel, která se aplikují na operace ostatních služeb. Například když jedna služba spustí operaci nákup, tak druhá služba může na základě definovaných pravidel rozhodnout, jak bude tato operace správně provedena. Entity/Engine Service je služba, která poskytuje přístup k business objektům nebo diskrétní části funkcionality, jako jsou například funkce platebního systému, a také řídí další nezbytné události a činnosti spuštěné službou. V souvislosti s business objektem má ESA vlastní definici, co to je business objekt. Business objekt je dle (Woods, a další, 2006) v rámci ESA definován jako kolekce dat a metod, který by měl být v maximální možné míře znovupoužitelný. Utility Service je služba, která poskytuje ostatním službám sdílenou funkcionalitu. Jako příklad je uvedena služba, která umí poskytovat hodnotu (třeba i defaultní) do určitého pole. Tyto služby jsou pak součástí kompozitních business služeb, respektive kompozitních aplikací. 33

34 Problematika kompozitních aplikací, respektive kompozitních business služeb, je pro ESA klíčová. Za kompozitní aplikace ESA dle (Woods, a další, 2006) považuje aplikaci, která využívá služeb jako stavebních bloků. Předpokládá se totiž, že vývoj bude rychlejší, pokud se používají již hotové a standardizované služby, ze kterých se sestavuje kompozitní aplikace. ESA dokonce nepovažuje budování kompozitních aplikací za vývoj, ale za sestavování. Dále ESA jako taková dle (Woods, a další, 2006) klade důraz na znuvupoužitelnost a flexibilitu takovýchto kompozitních business služeb. V rámci ESA by měly být služby, které nemají vysokou míru znuvupoužitelnosti, spíše výjimkou. To, jak jsou kompozitní business služby v rámci ESA budovány, popisuje následující text KONSTRUKCE KOMPOZITNÍCH BUSINESS SLUŽEB V RÁMCI ESA Kompozitní aplikace, vytvořené dle specifikace ESA, se dle (Woods, et al., 2006) nazývají enterprise services a reprezentují business transakci, například zrušení objednávky. Preferovaným standardem je dle (Woods, a další, 2006) v tomto případě standard webových služeb, který bude blíže popsán v další části práce. Samotná kompozitní aplikace však může být přístupná přes různá další rozhraní, které vyžaduje konkrétní business případ. Příklad rozhraní v kompozitní aplikaci je vidět na Obr. 6, kdy samotná kompozitní aplikace, složená ze služeb stávajících podnikových systémů, může být dostupná přes portálovou technologii specializovaným zařízením přes standard RFID nebo aplikace MS Office. Přičemž integrace s MS Office je na velmi vysoké úrovni přes standardy VBA a OLE a je dostupná i v samotném informačním systému SAP, ne pouze pomocí SAP NetWeaver (Gadatsch, a další, 2007). Obr. 6: Rozhraní business služeb dle ESA (Woods, a další, 2006) 34

35 Na standard webových služeb jsou pak navázány další standardy, které ESA preferuje. (Woods, a další, 2006) zmiňuje standardy jako SOAP, HTTP (Hypertext Transfer Protocol), WSDL (Web Service Description Language), UDDI (Universal Description, Discovery, and Integration) apod. Politika pro podporu standardů v rámci ESA je dle (Woods, a další, 2006) určena dvěma kritérii: interoperabilita a rozšířenost. ESA si neklade za cíl podporovat každý standard, ale reaguje na požadavky zákazníků a implementuje pouze takové standardy, které se používají často a jsou obecně akceptované. Také je snaha implementovat takové standardy, které jsou nezávislé na platformě (například HTTP pracuje na platformě MS Windows i UNIX nebo Linux). Pro podporu komponovatelnosti enterprise služeb (Woods, a další, 2006) zmiňuje také doporučování standardu SCA (Service Component Architecture). Tento standard, podobně jako standardy navázané na standard webových služeb, však bude podrobněji popsán dále v textu. Kromě technologických standardů doporučuje ESA také definici podnikových standardů, které nazývá sémantické standardy a přenositelné standardy. Jejich vazbu ilustruje Obr. 7. Obr. 7: Standardy v rámci kompozitních aplikací (Woods, a další, 2006) Přenositelnými standardy se rozumí standardy jako například ODBC, FTP apod. Jedná se o standardy, které jsou obvykle nativní součástí operačních systémů nebo middleware. V případě informačního systému od společnosti SAP se jedná o standard BAPI (Business 35

36 Application Programming Interface), který je dle (Woods, a další, 2006) standardním rozhraním, které systému společnosti SAP vystavují funkcionalitu a služby vnějšímu světu. V rámci kompozice služeb jsou však také důležité sémantické standardy. Sémantickými standardy se dle (Woods, a další, 2006) rozumí takové standardy založené na podnikových standardech, podle nichž se modelují datové objekty, které jsou pak předávány mezi jednotlivými IT systémy. Sémantické standardy by měly minimalizovat nedorozumění a podporovat hodnotu a konzistenci dat. V základním principu se jedná o definování kanonického datového modelu. Kanonický model je dle (Hophe, a další, 2003) takový datový model, který je nyní závislý na žádné konkrétní podnikové aplikaci nebo systému. Ovšem v kontextu ESA je důležité zmínit, že je doporučováno použít datový slovník typu RossetaNet, než se pouštět do vývoje vlastního slovníku. Dle (Feuerlicht, 2008) je RossetaNet datový slovník, který obsahuje definici businessových a technických datových objektů. Jedná se o definice, které upřesňují datovou syntaxi, strukturu a sémantiku a řeší tak interoperabilitu napříč odvětvími pomocí definice předávaných podnikových dokumentů a procesů pro předávání mezi obchodními partnery. S datovými typy také souvisí již výše zmíněný termín business objekt. Business objekt je v ESA dle (Woods, a další, 2006) definován jako kompozitní objekty, které v sobě zapouzdřují sdílenou a znovupoužívanou funkcionalitu a jsou důležitou součástí služeb, protože reprezentují to, co poskytuje. Komplexnost celého frameworku ESA ilustruje Obr. 8. Ten ukazuje celkový pohled na framework ESA na vyšší úrovni abstrakce. Ukazuje, jak jsou na sobě jednotlivé prvky v rámci ESA závislé a jak se podporují. Jsou základní dvě skupiny objektů: poskytovatelé služeb a kompozitní aplikace. Mezi poskytovatele služeb patří podnikové informační systémy a služby, které nabízejí. Na těchto službách pak stojí kompozitní aplikace, které je komponují a definují ve větší celky a jejich funkcionalitu vystavují pomocí business objektů. Tyto služby jsou pak využívány v procesních službách na základě akcí, které jsou přiřazeny jednotlivým rolím v rámci organizační struktury. 36

37 Obr. 8: Přehled architektury ESA (Woods, a další, 2006) 4.3 TOGAF A KOMPOZITNÍ BUSINESS SLUŽBY TOGAF je de facto standard ve formě metodického rámce pro řešení enterprise architektury (EA, Enterprise Architecture), který je zastřešen organizační skupinou The Open Group. Architektura je dle (Minoli, 2008) v rámci TOGAF chápána jako zevrubná organizace systému, který se skládá z komponent, vztahů mezi komponentami, vztahů komponent vůči vnějšímu okolí a principů pro jejich návrh a vývoj. Dle (Minoli, 2008) je základními principy TOGAF založen na standardu ANSI/IEEE Std a některé prvky jsou z tohoto standardu převzaté. Kromě tohoto, jak bylo uvedeno výše, tak TOGAF také vychází ze standardu ISO/EIC podobně jako standard ITIL. 37

38 4.3.1 SLUŽBY V RÁMCI TOGAF Architektonický rámec TOGAF je také přístup, který je orientovaný na služby a v některých svých principech se servisně orientovanou architekturou překrývá nebo koresponduje. Ačkoliv oblast zájmu, kterou TOGAF definuje, výrazně přesahuje tu, kterou má servisně orientovaná architektura, tak i TOGAF má v popředí zájmu služby a jejich kompozici. V rámci TOGAFu je dle (The, 2009) služba definovaná jako logická reprezentace opakovatelné business aktivity, která má specifikovaný výstup. Služba je soběstačná, může být komponovaná z ostatních služeb a vůči svým konzumentům se reprezentuje jako černá skříňka. Architektonický rámec je podobně jako metodika ESA inspirován konceptem servisně orientované architektury a její principy i z velké části implementuje a je s ní provázán. Není sice natolik konkrétní jako ESA, protože pracuje na vyšší úrovni abstrakce, ovšem samotnou servisně orientovanou architekturu v některých oblastech rozšiřuje a doporučuje konkrétnější doporučení. Například v oblasti řízení služeb, což však bude konkrétněji popsáno v následujícím textu. V otázce rozlišování typů služeb, je však TOGAF poněkud složitější než předcházející metodiky. Dle (The, 2009) TOGAF nahlíží na služby ze dvou pohledů, a to konkrétně z pohledu business a z pohledu vývoje. Z pohledu business TOGAF definuje tzv. business service (business služba), která je dle (The, 2009) jednotkou podnikové funkce, která je podpořena kombinací lidské síly, procesů a technologie a může mít následující vlastnosti: Může být prováděna manuálním procesem nebo může být plně automatizována. Může být prováděna organizací nebo může být outsourcovaná partnerem. Je vystavena svým konzumentům, kteří mohou být tvořeni kombinací zaměstnanců, zákazníků, partnerů nebo dodavatelů. Je vykonávána na místě potřeby, na úrovni divize nebo v rámci korporátního kompetenčního centra. Z pohledu vývoje TOGAF definuje tzv. information system service (služba informačního systému), která je dle (The, 2009) jednotkou aplikačního kódu, který poskytuje otevřené rozhraní, jenž představuje abstrakci od implementace. Tyto služby jsou pak v rámci TOGAFu dle (The, 2009) rozděleny na následující typy: 38

39 Process Service zapouzdřuje podnikový proces a aplikační kompozici. Application Service zapouzdřuje aplikační funkci. Data Service řídí přístup k datům a jejich uchovávání. Infrastructure Service reprezentuje sdílené služby jako například monitorování, řízení bezpečnosti atd. Tyto služby definované pohledem vývoj se pak komponují v rámci kompozitních aplikací. Kompozitní aplikace má v v rámci TOGAFu relativně jednoduchou definici. Dle (The, 2009) je kompozitní aplikace taková aplikace, která je tvořena kompozicí jiných atomických nebo kompozitních aplikací. Kompozitní aplikace jsou pak konzumentům reprezentovány v rámci služeb, které definuje pohled business. Blíže je však problematika kompozitních aplikací v rámci TOGAF popsána v následující části práce KOMPOZICE SLUŽEB V RÁMCI TOGAF Vztah mezi pohledy vývoj a business a mezi službami, které tyto dva pohledy vymezují, blíže přibližuje Obr. 9. Obr. 9: Koncept služeb v rámci TOGAF (The, 2009) Je vidět, že pohled business (business-led) řeší otázky spojené s portfoliem služeb, jejich řízením, dohledem a prováděním a vykonáváním. Naopak pohled vývoje (developer-led) řeší otázky spojené s návrhem, budováním a provozováním služeb. Také je možné vidět, jakým způsobem jsou služby komponovány a jaké mají mezi sebou vztahy. Business service v sobě může komponovat jednu nebo více information system service. Také je možné vidět, jak se 39

40 vzájemně služby pohledu vývoj podporují. Základem jsou služby typu Infrastructure Service, na kterých jsou postavené další typy. Na typu Data Service jsou pak postavené služby typu Application Service a nad nimi pak služby typu Process Service. Navíc TOGAF nevylučuje, aby jedna služba typu Process Service byla komponována v rámci jiné služby typu Process Service. Podle definice, kterou používá TOGAF pro kompozitní aplikace, jsou kompozitními aplikacemi kromě Business Service a Process Service také služby typu Data Service a typu Application Service. Dále v této práci budou za kompozitní business službu považovány typy Business Service a Process Service, protože podobně jako v předchozích přístupech tyto služby tvoří rozhraní mezi businessem a podnikovým ICT. 4.4 ITIL A KOMPOZITNÍ SLUŽBY ITIL je de facto standard ve formě metodického rámce pro procesní řízení podnikového ICT, který je primárně založen na standardu ISO/EIC (Office, 2007). Není jej však možné vzít a aplikovat přímo, je nutné jej přizpůsobit konkrétní organizaci. Například (Lukáč, 2011) ITIL popisuje jako rámec postavený na tzv. best practices neboli na nejlepších známých praktikách. ITIL poskytuje návody a rady, jak IT řídit, ale není možné jej přebrat jako hotovou věc. Také (Lukáč, 2011) podotýká jednu pro tuto práci důležitou skutečnost, a to, že ITIL ve verzi 3 přistupuje k řízení IT striktně z pohledu služeb. ITIL ve verzi 3 je pak rozdělen na části podle fází životního cyklu služeb, které jsou dle (Lukáč, 2011) následující: Service Strategy (Strategie služeb); Service Design (Návrh služeb); Service Transition (Nasazování služeb do provozu); Service Operation (Provozování služeb); Continual Service Improvement (Nepřetržité zlepšování služeb). Protože je ITIL především procesním rámcem, tak v každé této fázi jsou definované procesy, které by v nich měly být prováděny. Celá problematika ITILu přesahuje rámec této práce TYPY SLUŽEB V RÁMCI ITIL V rámci ITIL je dle (Office, 2007) služba definovaná jako dodávka hodnoty zákazníkům, která je reprezentována usnadněním dosažení jejich cílů bez nutnosti, aby vlastnili specifické náklady a rizika. 40

41 ITIL sám o sobě také nemá široké členění služeb. ITIL v zásadně rozlišuje dva typy služeb, které obsahují konkrétní zdroje, které v sobě komponují. Dle (Office, 2007) to jsou následující typy: Business Service je služba definovaná businessem na úrovni procesní vrstvy a je zaměřená na abstrakci podnikových aktivit. Tato služba může reprezentovat podnikový proces nebo kolekci jiných služeb typu Business Service a může být konstruována jako kompozitní aplikace nebo diskrétní funkce aplikace. IT Service je služba poskytovaná podnikovým ICT, která nemá z pohledu businessu kontext nebo sémantiku pro podnikatelskou činnost. Nicméně i v rámci ITILu se dle (Office, 2007) říká, že hranice mezi službami typu Business Service a IT Service je v praxi často dost nejasná. Rozdíl nebo spíše podobnost ilustruje Obr. 10. Obr. 10: Srovnání business service a IT Service (Office, 2007) Je zřejmé, že architektura obou typů služeb se liší pouze v jádru, kdy u Business Service je jádrem služby workflow podnikového procesu a u IT Service logika obsažená v podnikové 41

42 aplikaci. Jinak jsou služby stejné, protože oba typy podléhají řízení, jsou definovány zdroji, které používají apod. Nicméně, jak bylo poznamenáno výše, i ITIL řeší kompozici služeb a kompozitní služby, které jsou popsány v následujícím textu KOMPOZICE SLUŽEB V RÁMCI ITIL Dle (Office, 2007) chápe ITIL kompozitní aplikace jako poslední evoluční formu, jak je funkcionalita podnikových aplikací dodána těm, kteří tyto aplikace využívají. Jak bylo zmíněno výše, kompozitní aplikace v podstatě odpovídá službě typu Business Service. V rámci Business Service jsou zapouzdřeny podnikové procesy, které využívají jednotlivých služeb typu IT Service. Názorně řešení kompozice služeb v rámci metodiky ITIL ukazuje (Office, 2007). Během kompozice služeb, se do jejich návrhu v rámci ITILu promítá všech pět aspektů, které mají na konečnou podobu služby vliv. Dle (Office, 2007) začíná fáze Service Design životního cyklu služby definicí nových nebo změněných business požadavků a končí vývojem služby nebo služeb, které naplňují tyto požadavky. Služba pak přechází do fáze Service Transition. Na samotný návrh služby pak má vliv pět aspektů: Service Strategy; Service Improvement; Service Transition; Service Operation; Service Management Systém. Dle (Office, 2007) je možné ve zkratce říci, že nově zavedené služby nebo upravená služby jsou v souladu se stávajícím portfoliem služeb, respektují technologické architektury a jsou schopné být provozovány ve stávající i plánované budoucí infrastruktuře, respektují procesní logiku organizace, role a zodpovědnosti v rámci organizační struktury organizace a existují metriky, podle kterých je možné samotnou službu měřit a hodnotit. ITIL tedy přistupuje k definování a návrhu služeb relativně obsáhle. Na druhou stranu lze předpokládat, že služby typu IT Service definované dle pěti aspektů budou podnikové procesy 42

43 v rámci služeb typu Business Service optimálně podporovat a bude u nich možné monitorovat měřitelné metriky, jako je například jejich kvalita. Obr. 11: Kompozice služeb v rámci ITIL (Office, 2007) ITIL však sám řeší kompozici všech služeb. V rámci této práce je v těžišti zájmu zejména kompozice aplikačních služeb a v této oblasti sám ITIL dle (Office, 2007) doporučuje využít principů servisně orientované architektury pro kompozici služeb dle pěti aspektů do kompozitních business služeb, které odpovídají službám typu Business Service. 4.5 COBIT COBIT není de facto standard, který by se přímo zabývala kompozitními aplikacemi a podrobným rozlišováním služeb, ale orientuje se spíše na IT Governance a audit podnikového ICT a informačních systémů. Proto bude tento standard rozebrán podrobněji v části práce, která se zabývá pohledy Management a Governance na ICT služby. 4.6 OSTATNÍ PŘÍSTUPY KE KOMPOZITNÍM SLUŽBÁM Následující část této práce sumarizuje další přístupy ke kompozici služeb, které byly zmíněny autory publikací jako alternativní nebo byly zmíněny v rámci metodik, které byly již popsány. 43

44 Jednotlivé zkratky, termíny a standardy jsou vysvětleny v samotném textu práce, terminologickém slovníku nebo seznamu zkratek PRINCIP KONTROLERU DLE ERLA V předchozím textu byl velice často ke kompozici kompozitních business služeb použit standard webových služeb. Kompozitní business služby také často reprezentovaly podnikové procesy. Tyto dva předpoklady pak často vedou k použití jazyka BPEL (Business Process Execution Language), který se postupně stává součástí standardu webových služeb (například specifikace WS-BPEL) v rámci kompozitní business služby. Tuto skutečnost potvrzuje například (Erl, 2005), (Erl, 2007) nebo (Feuerlicht, 2008). Definice a použití jazyka BPEL pak bude uvedeno v dalších částech práce. Nicméně ne vždy je při kompozici business služby použit jazyk BPEL. Jsou kompozitní business služby, které (Erl, 2007) nazývá kontrolery. Tyto služby nemají svoji vnitřní logiku reprezentovanou procesem v notaci BPEL, ale mají ji v sobě napevno naprogramovanou. Sám (Erl, 2007) však takovéto služby nepovažuje za zcela slučitelné s principy servisně orientované architektury a nedoporučuje se uchylovat k takovéto konstrukci kompozitních business služeb PORTÁL JAKO KOMPOZITNÍ SLUŽEBA V RÁMCI ESA Jak bylo poznamenáno v části, která byla vyčleněna pro kompozici služeb v rámci ESA, tato metodika staví kompozitní business služby do středu zájmu. Jak vyplývá z definice, kterou dle (Woods, a další, 2006) ESA pro kompozitní business službu používá, tak kompozitní business služba je jakákoliv aplikace, která se skládá ze služeb. (Woods, a další, 2006) také zmiňuje, že je v rámci kompozice zapouzdřen podnikový proces a je preferován standard webových služeb. Z toho de facto vyplývá použití jazyka BPEL. Nicméně v rámci ESA jsou jako příklady kompozitních aplikací, a tedy i kompozitních business služeb, uvedeny i portály (Woods, a další, 2006). Jakmile jsou jednotlivé prvky na portálu považovány za služby, tak celá portálová stránka je dle definice ESA kompozitní aplikace. 4.7 SHRNUTÍ POZNATKŮ O KOMPOZITNÍCH BUSINESS SLUŽBÁCH Jak bylo identifikováno v části práce, kde byla provedena rešerše odborné literatury a absolventských prací, byla zjištěna skutečnost, že při kompozici kompozitních business služeb byly nejčastěji používané,nebo doporučované principy architektury orientované na služby. Tyto principy jsou používány jak přímo, tedy využívání servisně orientované architektury v její čisté koncepční podobě, stejně tak i v její upřesněné a obohacené formě, 44

45 například v rámci ESA, nebo zaobalené do širšího spektra doporučení, principů a procesů jako například v rámcích TOGAF a ITIL. Na základě tohoto zjištění, bude v následujících částech práce upřednostňován přístup ke kompozici kompozitních business služeb definovaný v rámci servisně orientované architektury a na platformě nezávislých zásad definovaných v rámci ESA, jako například použití sémantického standardu, definici kanonického modelu, využívání SCA nebo BAPI pro přístup k funkcím systému společnosti SAP, což se nijak nevymyká zásadám, které servisně orientovaná architektura předpokládá. Toto rozhodnutí s sebou přináší několik výhod pro analýzu pohledů na definování, vývoj a řízení služeb (Engineering, Management, Governance), protože kompozitní služby budou nezávislé na technologii, bude možné pro design a vývoj komponovaných služeb zvolit nejvhodnější standard a pro řízení jejich životního cyklu a dohled nad ním zvolit relevantní aspekty z rámců, které se řízením zabývají a samy použití servisně orientované architektury doporučují. 45

46 5 POHLEDY NA KOMPOZITNÍ BUSINESS SLUŽBY Následující část práce se zabývá propojením moderních způsobů řízení podnikové informatiky a podobou kompozitních business služeb. Na počátku práce byly vymezeny tři perspektivy, kterými je možné na kompozitní business služby nahlížet: Engineering Management Governance Řízení podnikové informatiky v rámci těchto tří perspektiv přináší do problematiky kompozice služeb další principy a zásady, ale také vymezuje způsoby, jak kompozice kompozitních business služeb dosáhnout. Tedy jakými prostředky, jakými metodami a procesy a podle jakých pravidel (tedy Engineering, Management a Governance). Vztah těchto tří perspektiv ilustruje Obr. 12. Obr. 12: Vztah pohledů Engineering, Management a Governance (Autor) Je evidentní, že tyto tři perspektivy jsou provázané. Jednotlivé perspektivy budou konkrétněji rozebrané v následujícím textu. Pro přehled je však možné jednotlivé perspektivy charakterizovat následovně: Engineering zabývá se konstrukcí služeb a technologicko-implementačními aspekty, tedy jaké podnikové metodiky (standardy a postupy) při konstrukci služeb použít. Management řeší životní cyklus služeb, co konkrétní služby poskytují, jak dlouho jsou konkrétní služby v provozu a jak se mají služby chovat v případě, kdy se na ně mění požadavky. Governance dohlíží na pohled Management, aby způsob, jakým řídí životní cyklus služeb, respektoval architektonické principy a politiky definované pro chod, provoz a vlastnosti služeb. 46

47 Východiskem pro analýzu kompozitních služeb z těchto tří perspektiv je předchozí část práce, ve které byly sumarizovány základní poznatky, převážně obecné, jak kompozitní business služby komponovat. Kromě obecných principů, rešerše odborné literatury, absolventských prací a dokumentace, poskytla předchozí část práce také indicie, jakým směrem se v rámci jednotlivých perspektiv ubírat. 5.1 POHLED ENGINEERING Jak bylo poznamenáno výše, pohled Engineering má za úkol definovat, podle jakých podnikových metodik, tedy pomocí jakých standardů, metod a postupů, služby konstruovat. Možností je celá řada. Často vznikaly historickým vývojem informačních technologií, které procházely evolučním vývojem na základě nových požadavků, které na ně byly kladeny. Důležitým kritériem pro volbu technologií a standardů, které jsou v tomto přehledu uvedeny, byla vedle výsledků analýzy rešerše odborné literatury a kvalifikačních prací, podnikových metodik a standardů uvedených v citované odborné literatuře také jejich podpora a doporučení na straně platformy IBM WebSphere ESB Server a IBM WebSphere Process Server. Jedná se zejména o preferované standardy, jako jsou Java Enterprise Edition, webové služby, BPEL a SCA. Další technologie a prostředky jsou uvedeny zejména informativně a jako ukázka, že je možné služby budovat a komponovat i dalšími způsoby. Takovýmto příkladem je uvedení platformy WCF, kterou ve své práci zmiňuje (Fischer, 2009). Také je důležité hledisko, jak jsou standardy logicky zařazeny, neboť následující části práce rozlišují, zdali jsou standardy dimenzovány pro koncept service-oriented nebo zdali jsou mimo tento koncept. Zpravidla důvodem, proč je standard zařazen mimo koncept service-orented, je jeho historický vznik před tímto konceptem. Nicméně často z těchto historicky starších standardů koncept service-oriented vychází STANDARDY PRO TVORBU KOMPONENT MIMO KONCEPT SERVICE ORIENTED Modularitou a členěním podnikových aplikací a informačních systémů na komponenty jako cestou, která vede k zjednodušení jejich vývoje, se informační technologie zabývaly již dlouhou dobu před tím, než adoptovaly pojem služba. Jednalo se o různé komponentové architektury nebo objektově orientovaný přístup k budování softwaru. Přestože však nativně s pojmem služba nepracují, i dnes mají v informačních technologiích své zasloužené místo a celá řada principů, které sebou přinesly, se staly základem pro samotnou servisně orientovanou architekturu a je možné je použít v rámci kompozice kompozitních služeb, aniž 47

48 by se principům servisně orientované architektury vymykaly, protože servisně orientovaná architektura není programovací jazyk, ani konkrétní technologie, a je více cest, jak ji budovat. Několik těchto standardů uvedl ve své práci (Kočí, 2007). Jednalo se RPC (Remote Procedure Call) a MOM (Message Oriented Middleware), které jsou vlastně jedněmi ze základních předchůdců, na kterých pak stojí servisně orientovaná architektura. Tyto a několik dalších standardů zmiňuje i (Feuerlicht, 2008). Ten kromě RPC a MOM dále zmiňuje, CORBA (Common Object Request Broker Architecture) a Microsoft COM (Component Object Model) Remote Procedure Call RPC je, jak název napovídá, volání metody nebo procedury, která se nachází na vzdáleném systému. (Feuerlicht, 2008) tento princip vysvětluje na příkladu, kdy klient volá proceduru, která je uchována v databázi na vzdáleném serveru. Také říká, že tento princip je používaný při využívání programových knihoven. V praxi RPC funguje tak, že klient zavolá metodu a ta mu odpoví výsledkem, jako kdyby byla součástí samotného klienta. Metoda však za sebou skrývá proceduru, která se provede na vzdáleném stroji a která klientovi pošle výsledek. (Feuerlicht, 2008) u RPC vyzdvihuje celou řadu výhod, jako jsou efektivnější komunikace, uchovávání předkompilovaného kódu a implementační logiky procedury na straně serveru a další Message Oriented Middleware MOM je poměrně revoluční přístup, který zavedl komunikaci mezi komponentami systému pomocí zpráv. (Feuerlicht, 2008) tento přístup charakterizuje jako přístup, který umožňuje vyšší autonomnost a nižší provázanost komponent mezi sebou. Také říká, že jsou-li zprávy dostatečně obecné, například textový soubor, mohou pak spolu komunikovat vysoce heterogenní komponenty postavené na odlišných technologiích. (Feuerlicht, 2008) také v souvislosti s MOMem zmiňuje messagingové systémy, které do komunikace mezi komponentami přináší vysoký nárůst spolehlivosti komunikace. Messagingové systémy však budou blíže popsány dále v textu. I MOM je však důležitým pilířem moderních servisně orientovaných přístupů, které mají v definici komunikaci pomocí zpráv CORBA a Microsoft COM CORBA a Microsoft COM jsou dle (Feuerlicht, 2008) dva paralelní a ekvivalentní přístupy k podpoře interoperability informačních systémů. (Feuerlicht, 2008) tvrdí, že pro tyto přístupy 48

49 byl katalyzátorem rozmach objektově orientovaného návrhu aplikací, který však byl vyňat z vnitřní struktury aplikací a použit na aplikační infrastrukturu. Dle (Feuerlicht, 2008) je možné pomocí CORBA vytvářet znovupoužitelné komponenty s definovaným rozhraním v jazycích, jako jsou C++, Java, Smalltalk, COBOL apod. (Feuerlicht, 2008) však také zmiňuje, že CORBA nebyla příliš úspěšná a spíše se prosadil standard COM, který se pak stal součástí platformy.net společnosti Microsoft. Nicméně princip standardu CORBA, kdy jsou dostupné znovupoužitelné komponenty s definovaným rozhraním, je dnes přítomný prakticky všude, zejména v servisně orientované architektuře Shrnutí poznatků o standardech pro tvorbu komponent Je tedy evidentní, že principy, které servisně orientovaná architektura prosazuje a zavádí, jsou známé již poměrně dlouhou dobu. Nicméně v dnešní době již existují efektivnější technologie a standardy, které vlastnosti a zásady těchto starších standardů obsahují a které jsou dnes v servisně orientovaných prostředích používané a které jsou popsané v následujícím textu STANDARDY PRO TVORBU SLUŽEB V KONCEPTU SERVICE ORIENTED Jak vyplývá z předchozí části, moderní standardy implementují principy standardů, které vzniknuly mnohem dříve než samotný koncept služeb v rámci podnikového ICT. Nicméně moderní principy přináší minimálně jednu výhodu, a to v podpoře v moderních informačních systémech, podnikových aplikacích, integračních platformách a v celé řadě dalších produktů určených do podnikové IT infrastruktury. Standardy, které jsou v následující části práce uvedeny, si však neodpovídají svojí úrovní. Například jsou v ní vedle sebe uvedeny standardy jako Java Platform Enterprise Edition, webové služby a SCA, přičemž webové služby a SCA jsou používány v rámci Java Platform Enterprise Edition, ale i na dalších platformách jako například.net nebo SAP NetWeaver (viz část práce zabývající se kompozicí služeb v rámci ESA) a dalších. Standardy jsou uvedeny tímto způsobem, protože mají přímou vazbu na budování služeb na principu service oriented. Pro názornost jsou uváděné standardy zobrazeny ve své správné úrovni na Obr. 13. Ten ukazuje, jak mezi sebou uváděné standardy souvisí. Základem jsou platformy pro provoz služeb, které mohou nabízet technologie pro budování a komunikaci služeb, a také prostředky pro komponentový vývoj a následnou kompozici služeb. 49

50 Obr. 13: Standardy pro tvorbu služeb v konceptu Service-Oriented (Autor) Java Platform Enterprise Edition Jedním z nejkomplexnějších standardů pro budování služeb a podnikových aplikací ve všeobecném měřítku je standard Java Platform Enterprise Edition. Jedná se o platformu, která prošla rozsáhlým vývojem a v dnešní době nabízí ucelené spektrum prostředků pro tvorbu distribuovaných aplikací. (Feuerlicht, 2008) definuje Java Platform Enterprise Edition jako rámec standardizovaných specifikací pro tvorbu distribuovaných aplikací. Celá architektura této platformy je postavená na komponentové architektuře EJB (Enterprise Java Beans) a dostupných API (Application Programming Interface). API je dle (Feuerlicht, 2008) programovací koncept, který umožňuje definovat propojení mezi dvěma softwarovými komponentami. Komponentová architektura EJB je dle (Feuerlicht, 2008) založená na principu tvorby komponent na serverové části aplikace, které v sobě zapouzdřují znovupoužitelnou business logiku. Jednotlivé API umožňují, aby platforma bylo schopná implementovat nejenom požadovanou aplikační logiku, ale aby také byla schopná spolupracovat s dalšími systémy a technologiemi, které nejsou technologicky postavené na Javě. (Feuerlicht, 2008) zmiňuje API pro připojování do databáze, řízení transakcí, vyhledávání pojmenovaných prostředků, řízení a posílání zpráv mezi komponentami a další. V neposlední řadě je také důležitá podpora standardu webových služeb. 50

51 Webové služby Jedním z nejklíčovějších standardů, který je v rámci kompozice služeb používaný, je standard webových služeb. Servisně orientovaná architektura nevyžaduje konkrétní technologii pro své budování, ale (Feuerlicht, 2008) považuje použití standardu webových služeb za nejpraktičtější a (Erl, 2005), ačkoliv se snaží být ve svých doporučeních technologicky neutrální, použití standardu webových služeb předpokládá. Dle (Feuerlicht, 2008) je standard webových služeb založený na následujících standardech: XML, SOAP, WSDL a UDDI. Základní vztahy mezi standardy umožňují, aby poskytovatel služeb do servisního úložiště publikoval popis rozhraní služby pomocí WSDL. Konzument služby si tento popis najde v úložišti pomocí standardu UDDI, na základě WSDL identifikuje, kde se služba nachází a pomocí jakých zpráv (v tomto případě ve formátu XML) s ní má komunikovat a pak prostřednictvím standardu SOAP mezi sebou konzument a poskytovatel komunikují. Takovouto architekturu pak (Erl, 2005) nazývá první generací webových služeb. Tyto čtyři standardy jsou pak dle (Feuerlicht, 2008) rozšířeny dalšími doprovodnými standardy pro řízení bezpečnosti (WS-Security), spolehlivosti doručování zpráv (WS-ReliableMessaging), řízení transakcí (WS-Transaction), aplikaci politik (WS-Policy) a dalšími, (Erl, 2005) pak z těchto doprovodných standardů vyzdvihuje specifikaci WS-BPEL pro implementaci podnikových procesů, která bude přiblížena v následujícím textu. Standard WSDL, jak bylo poznamenáno výše, slouží ke komplexnímu popisu služeb. (Weerawarana, a další, 2005) popisuje WSDL na základě dvou scénářů. Prvním z nich je situace, kdy WSDL popisuje službu svým klientům pomocí deklarace zpráv, operací, které služba nabízí, kde se služba nachází, a mechanismus, jak se službou interagovat. V tomto scénáři je úkolem WSDL zajistit co nejefektivnější komunikace konzumenta služby se službou. Ve druhém scénáři slouží WSDL jako standardní popis služby pro implementátory. (Ramachandra, a další, 2010) tento scénář popisuje příkladem, kdy si v rámci jedné tržní vertikály, například výrobci pneumatik si se svými odběrateli odsouhlasí podobu služby pro nákup pneumatik. Výsledkem je pak standardizovaná služba, která je jednoznačně popsaná pro celé odvětví. (Weerawarana, a další, 2005) také uvádí důležitou vlastnost WSDL, která se týká interakce se službou. Použití standardu webových služeb sice nativně předpokládá použití protokolu SOAP, nicméně je možné použít i další protokoly, které se definují v rámci tzv. bindingu. Binding definuje komunikační protokol. Problematika komunikačních protokolů je však dále v textu. 51

52 Standard UDDI slouží k vyhledávání služeb. (Weerawarana, a další, 2005) vymezuje UDDI jako prostředek, který v rámci servisně orientované architektury umožňuje dynamický binding (viz popis standardu WSDL) ke službám, což je jeden z klíčových atributů servisně orientované architektury. Použití UDDI je však vhodné i během návrhu a vývoje služeb. Jak říká (Weerawarana, a další, 2005), UDDI je prostředek, jak nalézat služby a tím zajistit jejich znovupoužívání například pomoci hledání výskytů a použití business objektů a business entit ve službách Business Process Execution Language Standard BPEL, respektive jeho varianta WS-BPEL, je standard, který slouží v servisně orientovaných aplikacích k implementaci business procesů. Procesy v notaci BPEL jsou při vizualizaci velmi podobné procesům, které jsou modelovány pomocí notace BPMN (Business Process Modeling Notation). Notace BPMN (Havey, 2005) zařazuje do standardu BPM (Business Process Modeling). Dle (Havey, 2005) lze BPM vymezit jako disciplínu, která se zabývá návrhem, popisem a v základní míře i provozem podnikových procesů. Podnikový proces je v kontextu BPM chápán jako algoritmus definovaný krok po kroku tak, aby dosáhl podnikových cílů. Mezi BPEL a BPMN jsou ovšem dva základní rozdíly. Prvním z nich je skutečnost, že BPEL proces je definován pomocí souboru XML a jeho vizualizace formou procesu se provádí až druhotně na základě tohoto zdrojového souboru. Druhým rozdílem je ten, že procesy v BPMN slouží k vizualizaci a znázornění procesů, zatímco procesy v BPEL jsou určeny k provozu v rámci aplikační infrastruktury pomocí speciálního běhového prostředí pro jazyk BPEL (tzv. BPEL engine). V rámci servisně orientované architektury se jedná o nezbytnou součást kompozitních business služeb, protože reprezentují procesní logiku prováděnou těmito business službami. Podobnost je také podpořena skutečností, že procesy v BPMN a v BPEL mají většinu použitých prvků a objektů společných nebo velmi podobných. To také umožňuje pomocí specializovaných nástrojů export z procesu v BPMN do BPEL Representional State Transfer Standard REST (Representational State Transfer) byl vytvořen jako alternativa ke složitějšímu a výkonnostně náročnějšímu standardu webových služeb. Dle (Josuttis, 2007) standard REST využívá HTTP metod GET, PUT, POST a DELETE k bezestavovému čtení, 52

53 zápisu, tvorbě, spouštění a mazání zdrojů, které jsou identifikovány pomocí URL. (Josuttis, 2007) vyzdvihuje u tohoto standardu především jeho jednoduchost a výkonnost a zároveň schopnost s jeho pomocí vytvářet sofistikované procesní služby, kompozice a další operace se službami v rámci servisně orientované architektury. Zároveň ale také upozorňuje, že standard REST není vhodný pro distribuované podnikové procesy, protože není natolik robustní jako standard webových služeb, což potvrzuje i (Weerawarana, a další, 2005) a (Feuerlicht, 2008) Service Component Architecture Standard SCA je jeden z nejpokročilejších přístupů pro tvorbu komponent a na nich založených služeb, který je v současné době v rámci servisně orientovaných přístupů dostupný. Jak bylo zmíněno výše, je například uveden v rámci ESA. Dle (Mario, a další, 2009) je možné SCA charakterizovat jako základ pro budování distribuovaných systémů, které splňují průmyslové standardy, zapadají do moderních podnikových architektur a jsou připravené pro standard webových služeb a Java Platform Enterprise Edition. (Mario, a další, 2009) také uvádí klíčové výhody SCA. SCA přináší zjednodušený programovací model, přináší efektivnější a flexibilnější znovupoužívání služeb, přináší lepší podporu řízení distribuovaných systémů a zjednodušuje konfiguraci politik a jejich prosazování napříč aplikacemi. Na základě poznatků, které uvádí (Mario, a další, 2009), je možné v širším kontextu SCA charakterizovat jako přístup, který je připravený na tvorbu komponent pro servisně orientované prostředí, které mají definované specifikace pro platformy.net a Java Platform Enterprise Edition. Tyto specifikace definují vysoce standardizované komponenty, které mají své rozhraní popsané pomocí WSDL. SCA v sobě kloubí hlavní výhody všech předchozích přístupů a standardů, zejména pak standardu webových služeb včetně všech rozšíření (například výše zmíněné politiky). Mají vysokou variabilitu v komunikačních protokolech (jsou de facto omezené pouze možnostmi bindingu ve WSDL) a komunikačních vzorech (synchronní a asynchronní komunikace, viz dále v textu) a mají nativní podporu kompozice jiných SCA komponent. Samozřejmostí je pak podpora transakcí (rozšíření v rámci standardu webových služeb), perzistence (například skrze API v rámci Java Platform Enterprise Edition) nebo již zmíněných politik. SCA je také přímo podporováno pro komponenty služeb na moderních integračních platformách od společností, jako jsou SAP, IBM nebo Oracle. Vlastní variantu SCA pak má i společnost Microsoft. 53

54 Windows Communication Foundation WCF je platforma, kterou společnost Microsoft dle (Liberty, a další, 2008) vydala jako součást platformy.net Framework 3.0. WCF je svoji koncepcí a pozicí, v produktovém portfoliu společnosti Microsoft určeného pro podnikové prostředí, podobné rámci ESA. (Patrick, 2008) WCF charakterizuje jako jednotný celek, který v sobě obsahuje dříve samostatné prostředky dostupných v rámci frameworku.net. Konkrétně tedy messagingový systém pro zprávy MSMQ (messagingové systémy viz dále v textu), podporu standardu webových služeb, podporu distribuovaných transakcí v rámci MSDTC a.net Remoting, což je dle (Liberty, a další, 2008) technologie pro volání vzdálených metod vybudovaných na platformách.net. (Liberty, a další, 2008) o WCF tvrdí, že to je nový způsob, jak na platformě společnosti Microsoft budovat služby. Kromě samotného standardu webových služeb a protokolu SOAP a http dle (Liberty, a další, 2008) se neomezuje pouze na tyto robustní standardy, ale také na méně komplexní jako REST. Předně je ale WCF určeno pro rozsáhlejší implementace, protože jak zmiňuje (Liberty, a další, 2008), WCF je vlastně zastřešující balík technologií, která vývojářům webových aplikací na platformě společnosti Microsoft přináší plnou podporu standardu webových včetně všech doprovodných rozšiřujících standardů, který výrazně zvyšují interoperabilitu takovýchto řešení Shrnutí poznatků o standardech pro tvorbu služeb Standardy pro tvorbu služeb jsou založené na podobných principech a v praxi se často kombinují. Zejména standardy SCA a webové služby jsou úzce propojené se standardem Java Platform Enterprise Edition. Standard SCA je navíc nástroj, který webové služby a Java Platform Edition kloubí takovým způsobem, že vývoj služeb je jednodušší a je možné lépe na něj aplikovat principy servisně orientované architektury v rámci podnikového ICT STANDARDY PRO KOMUNIKACI MEZI SLUŽBAMI Budování služeb a komponent je pouze část celé problematiky. Nejenom pro kompozici služeb, ale vůbec pro funkčnost infrastruktury je nezbytné vyřešit problematiku komunikace mezi službami. Způsob komunikace mezi službami je dle (Mario, a další, 2009) a (Hophe, a další, 2003) nazýván komunikační kanál. 54

55 HTTP a SOAP V souvislosti se standardem webových služeb, který je se servisně orientovanou architekturou spojován nejčastěji, se jako komunikační kanál nejčastěji používá kombinace protokolů HTTP a SOAP 1, kdy HTTP slouží jako transportní protokol pro zprávu definovanou standardem SOAP. Kromě protokolu HTTP se dle (Weerawarana, a další, 2005) (se) také pro transport zpráv používají protokoly jako TCP, SMTP nebo protokoly používané v rámci messagingových systémů. SOAP je dle (Weerawarana, a další, 2005) definován jako základní framework pro realizaci komunikace založené na zprávách v rámci standardu webových služeb, který umožňuje přistupovat k webovým službám v rámci neprovázané infrastruktury. (Weerawarana, a další, 2005) také vymezuje čtyři hlavní vlastnosti standardu SOAP: Standardizovaná struktura zprávy založená na standardu XML Model zpracování, který popisuje, jak má služba zprávu zpracovat Mechanismus, který umožňuje SOAP navázat (binding) na různé transportní protokoly Možnost připojit ke zprávě informace, které nejsou definovány pomocí XML SOAP vlastně definuje XML obálku pro samotnou přenášenou zprávu. Tato obálka definuje hlavičku, která obsahuje například binding, politiky a další informace, často obsahuje informace k rozšiřujícím standardům standardu webových služeb, a tělo, které obsahuje zprávu. (Weerawarana, a další, 2005) také uvádí, že standard SOAP může pracovat ve dvou režimech, první je režim document literal a druhý je režim RPC. Pokud SOAP pracuje v režimu dokument literal, tak v těle SOAP obálky je umístěný dokument, například objednávka, faktura, apod. Po zpracování dokumentu, služba v těle SOAP obálky odpoví jiným dokumentem, v případě objednávky například potvrzením. Ve druhém režimu, je v těle SOAP obálky umístěn název procedury, která se má volat, a její argumenty. V těle SOAP obálky odpovědi je pak výsledek procedury. Mezi nevýhody standardů SOAP a HTTP patří zejména skutečnost, že se jedná o principielně synchronní způsoby komunikace. Synchronní komunikace je dle (Weerawarana, a další, 2005) takový způsob komunikace, kdy je řízený proces dotazu a odpovědi a odpověď dorazí v určitém definovaném čase. Asynchronní komunikace, která dle (Weerawarana, a další, 1 Dříve byl SOAP zkratka pro Simple Objects Access Protocol, ovšem od verze 1.2 se již používá pouze SOAP. V kontextu této práce se předpokládá verze 1.2 a z tohoto důvodu není SOAP zkratkou. 55

56 2005) není řízená a není zaručeno, že odpověď na dotaz dorazí v určitém čase, je pomocí kombinace standardu webových služeb a SOAPu možná, ale vyžaduje to rozšiřující standard a komunikace se tím výrazně zkomplikuje, což potvrzuje (Weerawarana, a další, 2005) a (Mario, a další, 2009) HTTP Samotný protokol HTTP je nejčastěji používaný v souvislosti se standardem REST, který si vystačí s možnostmi, které HTTP nabízí. Kromě standardu REST je možné HTTP jako komunikační kanál používat například u služeb vytvořených v Java Platform Enterprise Edition, pokud by byly vystaveny pomocí servletů. Lze však předpokládat, že takovýto model je výjimkou, která nastává ve specifických případech Messagingové systémy Messagingové systémy neboli systémy založené na komunikaci pomocí zpráv stojí na počátku komunikace založené na zprávách. Tyto systémy jsou dle (Hophe, a další, 2003) takové systémy, které jako komunikační a transportní kanál pro zprávy používají frontu nebo také nazývaný kanál, což je objekt, ve kterém se zprávy řadí a čekají na své zpracování. Tento koncept má celou řadu implementací. Základní specifikací byla dle (Hophe, a další, 2003) specifikace JMS (Java Messaging System), které je součástí standardu Java Platfrom Enterprise Edition. S většími nebo menšími úpravami pak s messagingovými systémy přišly i další velké společnosti jako IBM, Microsoft nebo TIBCO. Jako příklady produktů (Hophe, a další, 2003) uvádí IBM WebSphere MQ, MSMQ nebo TIBCO MessageBroker. Jako hlavní přednosti konceptu front uvádí (Hophe, a další, 2003) zejména spolehlivost doručování zpráv, nízkou režii během zpracování zpráv a nesmírnou zásobu návrhových integračních vzorů, které je možné v rámci messagingových systémů využívat. Jak popisuje (Hophe, a další, 2003), spolehlivost doručování zpráv je založena na faktu, že pokud je zpráva vložena do fronty, tak se obvykle ukládá například do databáze, ze které je odstraněna až ve chvíli, kdy je doručena do svého cíle. Zpráva tedy přečká například pád messagingového systému. Také pokud je cílová destinace z libovolného důvodu nedostupná, nic nebrání tomu, aby zůstala ve frontě, dokud není cílová destinace opět dostupná. Nízká režie, a tedy vysoký výkon, je nejčastěji vyzdvihován v souvislosti se standardem webových služeb. Webové služby, zejména v kombinaci s protokolem SOAP, musí ke zprávám přidávat SOAP obálku, která je pak zaobalena do HTTP obálky, odeslána a na straně příjemce probíhá 56

57 opačný proces včetně několika násobného parsování zprávy na obou stranách. Messagingové systémy nejsou těmito kroky zatíženy, protože se zprávou se během přenosu neprovádí náročné operace jako například ono parsování. Návrhové integrační vzory pro messagingové systémy podrobně rozebírá (Hophe, a další, 2003) a přesahují rozsah této práce. Nicméně s pomocí messagingových systémů je možné vytvořit velmi sofistikovanou komunikační infrastrukturu, která umožňuje realizaci spolehlivé synchronní i asynchronní komunikace. Mezi další výhody messagingových systémů patří schopnost přenášet různé typy zpráv. (Hophe, a další, 2003) uvádí, že v současnosti se nejčastěji v messagingových systémech posílají zprávy ve formátu XML, ovšem dále dodává, že dnešní messagingové systémy jsou schopné přenášet zprávy v libovolném formátu, textové soubory, COBOLovské soubory, a dokonce binární zprávy. Jak také uvádí (Weerawarana, a další, 2005) a (Mario, a další, 2009), nic nebrání tomu, aby po messagingových systémech byly přenášeny zprávy ve standardu SOAP nebo aby WSDL soubor měl v rámci bindingu definované fronty. Je tedy možné vybudovat infrastrukturu postavenou na webových službách, které budou mít rozhraní popsané pomocí WSDL, ale komunikovat budou obyčejnými XML zprávami, které budou transportovány pomocí front. Takové řešení je například mnohem spolehlivější a efektivnější, protože mechanismy, které u standardní implementace webových služeb zajistí spolehlivost doručování zpráv, je poměrně komplikovaný a vyžaduje doprovodné standardy (Weerawarana, a další, 2005). Pomocí frontových systémů je také výrazně snazší komunikovat asynchronně, protože princip zpracování zpráv pomocí front asynchronně pracuje. (Weerawarana, a další, 2005) Shrnutí poznatků o standardech pro komunikaci mezi službami Moderní prostředky, které zajišťují komunikaci se službami i mezi službami a komponentami, jsou dnes vysoce standardizované. Ačkoliv existují de facto dvě koncepce, nabízejí alternativy, které odpovídají svými vlastnostmi konkrétním požadavkům na výkon, spolehlivost i složitost implementace. Standard HTTP je svými vlastnostmi vhodný pro jednoduchou komunikaci mezi službami, standard SOAP je určený pro komunikaci se službami se standardizovaným rozhraním, která vyžaduje synchronní zpracování požadavků, ve které se přenáší složitější datové objekty. Messagingové systémy pak zajišťují komunikaci, u které se klade důraz na vysokou spolehlivost doručování zpráv bez výrazného poklesu výkonu. 57

58 5.2 POHLED MANAGEMENT A GOVERNANCE Jak bylo poznamenáno v úvodu. Pohled Management se zabývá zejména otázkami, jakou funkcionalitu mají služby poskytovat, jak dlouho ji mají poskytovat a jak služby mají reagovat na požadavky na změnu ve funkcionalitě, kterou poskytují. Pohled Governance dohlíží na pohled Management a zajišťuje, že řídí životní cyklus služeb v souladu s principy architektury a politikami definovanými pro chod, provoz a vlastnosti služeb. Obecně platí, že pohled Governance je součástí disciplíny IT Governance, které dohlíží na podnikové ICT celkově ŘÍZENÍ A DOHLED NA ŽIVOTNÍ CYKLUS SLUŽEB V RÁMCI ESA V souvislosti s řízením životního cyklu služeb je dle (Woods, a další, 2006) klíčovou otázkou zajištění nepřetržité dostupnosti funkcionality, která je skrze služby dostupná. Tedy jak služby a komponenty vylepšovat nebo nahrazovat bez dopadu na běžící podnikové procesy. ESA to dle (Woods, a další, 2006) řeší oddělením business logiky od podnikových procesů. Toho se dosáhne pomocí pečlivého plánování změny směrování požadavků na služby. Jestliže je nasazovaná nová verze služby nebo komponenty, je nasazena vedle stávající komponenty a jakmile je připravená pro zpracování požadavků, požadavky jsou na ni přesměrovávány. Předpokladem pro takovouto operaci je samozřejmě standardizované rozhraní služeb a komponent, jak uvádí (Woods, a další, 2006). Životní cyklus služeb je vyobrazen na Obr. 14. Obr. 14: Životní cyklus Služeb v rámci ESA (Woods, a další, 2006) 58

59 Jednotlivé fáze jsou dle (Woods, a další, 2006) definovány následovně: 1. Implementace v této fázi probíhá návrh, testování a nastavení business logiky a systémů. Je zaměřená zejména softwarovou logistiku, tedy jak nasadit novou verzi služby, aniž by to mělo zásadní dopady na klíčové podnikové procesy. 2. Provoz v této fázi je snaha udržet aplikace a služby v nepřetržitém provozu. Služby, komponenty a systémy se neustále monitorují, aby nedošlo k jejich přehlcení a následnému pádu. Optimálně by měl být nepřetržitý monitoring zajištěn automatizovaně a měl by informovat tým maintenance v případě problémů nebo podezření na problémy. 3. Neustálé zlepšování a řízení změn služeb v této fázi probíhá rekonfigurace, opravy chyb a nasazování nových verzí služeb a služeb. Tato fáze se považuje za nejvíce kritickou v rámci životního cyklu služeb. Dle (Woods, a další, 2006) je v rámci životního cyklu služeb a komponent nejvyšší důraz kladen na monitoring. Softwarová platforma od společnosti SAP, která je pro ESA navržena, poskytuje všechny nástroje, které kvalitní monitoring umožňují. Pohled Governance je dle (Woods, a další, 2006) kontextu ESA primárně zaměřen na dosahování podnikových cílů a splňování finančních regulatorních předpisů jako například předpisů definovaných v rámci Sarbes-Oxley. (Woods, a další, 2006) také zmiňuje, že ESA si klade za cíl, aby Governance definovala framework, který vymezuje, jakým způsobem dělat v rámci podnikového ICT rozhodnutí, aby výsledné efekty byly v souladu s celkovou podnikovou strategií. Tento soulad pak Governance zajišťuje na základě udáváním instrukcí, zaváděním standardů a principů a řízením investicí pomocí priorit. (Woods, a další, 2006) však také uvádí, že v rámci ESA je snaha potřebu Governance snižovat zejména skrze vysokou standardizaci služeb, které jsou umístěny v inventáři služeb. Tyto služby jsou potom dostupné business analytikům ke konzumaci a kompozici nových aplikací, kdy tyto služby tvoří stavební kostky. Tyto principy pak dle ESA vedou k minimalizaci potřeby udržovat soulad s celkovou podnikovou strategií skrze Governance. Přesto existuje oblast, kde bude Governance v rámci ESA stále důležitá. (Woods, a další, 2006) popisuje Governance v rámci ESA jako instituci, která rozhoduje a rozhoduje zejména o nových business službách, aby se předcházelo duplikaci služeb. 59

60 5.2.2 ŘÍZENÍ A DOHLED NA ŽIVOTNÍ CYKLUS SLUŽEB V RÁMCI TOGAF Pohled Goveranance na kompozitní business služby zapadá v rámci TOGAF do komplexní perspektivy, která řeší celkové Governance napříč celou podnikovou architekturou. Ačkoliv je ve standardu TOGAF této perspektivě nad celou architekturou věnován velký prostor, pohledu Management je naopak věnován prostor minimální. TOGAF se v rámci pohledu Management dle (The, 2009) otevřeně odkazuje na metodiku ITIL a samotný rámec TOGAF v pohledu Management zajímá zejména definice Service Level Agreement (SLA) u jednotlivých služeb. SLA je dle (Office, 2007) dokument, který u služeb kodifikuje dohodu s jejich konzumentem o úrovni, rozsahu a kvalitě služeb, které konzumuje. V rámci SLA se definují metriky jako dostupnost, garantovaný počet transakcí připojených konzumentů, bezpečnost a další kvantitativní a kvalitativní metriky. TOGAF tedy v případě pohledu Management spoléhá na jiné, více specializované metodiky, které pak začlení do svých principů zejména do pohledu Governance. TOGAF dle (The, 2009) pohled Governance nad službami zavádí zejména z toho důvodu, že v rámci podnikové architektury existuje mnoho nezávislých a soběstačných pohybujících se komponent, které jsou sdílené napříč organizací a závisí na nich kritické podnikové procesy. Governance nad těmito komponentami je tedy nezbytností. V souvislosti s tímto pohledem na problematiku Governance, definuje TOGAF otázky, které je nezbytné zodpovědět nebo na ně hledat odpověď. Dle (The, 2009) to jsou následující: Co se stane, když se služba změní? Kdo je vlastníkem služby? Jak je dohlíženo na SLA služeb? Kdo potřebuje testovat službu předtím, než je nasazená do produkčního prostředí? Jak je možné zajistit, že služby, které jsou konzumovány, jsou vysoké kvality? Jak je možné zajistit, že nové služby jsou v souladu s podnikovým ICT, obchodním modelem a regulatorními předpisy? Jak je možné zajistit předvídatelnou dobu životnosti služeb? Hlavním posláním pohledu Governance v rámci TOGAF je dle (The, 2009) zajištění a řízení kvality, konzistence, předvídatelnosti, změn a vnitřních závislostí služeb. 60

61 (The, 2009) také uvádí rizika absence pohledu Governance nad službami, kdy jsou služby málo znovu používané, narušují a nepodporují podnikové procesy, zvyšují náklady za údržbu a nesplňují bezpečnostní a regulatorní politiky a nařízení. Kromě zodpovězení výše zmíněných otázek dle (The, 2009) vyžaduje komplexní strategii, která v sobě obsahuje kontrakty, politiky, metadata a pravidla pro řízení životního cyklu služeb. Tyto aspekty jsou pak dle (The, 2009) vymezeny následovně: Kontrakt služby je klíčový nástroj v architektuře služeb, který pomáhá komunikovat a prosazovat politiky. Kontrakt služby je přirovnán k obchodnímu kontraktu, kdy zajišťuje zdravý vztah mezi poskytovatelem a konzumentem služby, podporuje dohodu o užívání služby a podporuje důvěru mezi oběma stranami. Politiky služby vychází z faktu, že podnikové, technické a regulatorní politiky mají zásadní dopad na komponenty v rámci servisně orientované architektury. Především je důležité zajistit, aby politiky nebyly naprogramované ve službách napevno, ale aby bylo možné je ke službám libovolně přidávat a odebírat. V servisně orientované architektuře se to často nazývá podnikovými pravidly. Metadata služby metadata neboli popisující a definující informace o službě musí být dostupná mimo službu, což umožňuje její klasifikaci a dohled nad ní. Řízení metadat by mělo být v rámci Governance zajištěno nad celou architekturou. Pravidla pro řízení životního cyklu služby životní cyklus musí zajistit kvalitu, výkon a použitelnost publikované služby. Pokud je služba publikována, znamená to, že její konzument ji může nalézt a použít. V rámci životního cyklu se vyhodnocuje dopad nové služby na další konzumenty v rámci infrastruktury. Rozlišuje se životní cyklus individuálních služeb, které jsou navrženy, sestaveny a nasazeny a sdílených služeb, které mají vysoký dopad na infrastrukturu a jejich publikace vyžaduje vyšší pozornost ŘÍZENÍ A DOHLED NA ŽIVOTNÍ CYKLUS SLUŽEB V RÁMCI ITIL Řízení životního cyklu služeb je v rámci ITIL řešena zejména v části Service Strategy. Řízení životního cyklu služeb, je v rámci třetí verze metodiky ITIL klíčovou problematikou. (Office, 2007) dokonce označuje životní cyklus za jádro celé metodiky. Jak ukazuje Obr. 15, tak všechny části rámce ITIL prolínají. Základem je strategie služeb, která služby definuje. Tyto služby pak prochází individuálním životním cyklem služby, který se skládá z fází návrh, přechod a provoz. A nad službami pak 61

62 probíhá cyklus neustálého zlepšování služeb, který v souladu se strategií služeb definuje zlepšování služeb. Obr. 15: Životní cyklus služeb v rámci ITIL (Office, 2007) (Office, 2007) pak toto schéma životního cyklu popisuje způsobem, kde strategie služeb je osa, kolem které se životní cyklus točí, v životním cyklu jsou tři fáze, návrh, přechod a provoz, které strategii implementují a cyklus neustálého zlepšování služeb prioritizuje zlepšovací programy a projekty, které jsou postavené na strategických cílech. Aby tak mohl životní cyklus pracovat, musí procesy, které v něm probíhají, splňovat určité vlastnosti. Dle (Office, 2007) to jsou následující: Procesy jsou měřitelné a jsou měřitelné relevantním měřítkem, jako jsou například náklady nebo kvalita. Procesy mají určité výsledky nebo výstupy, protože důvod, proč procesy jsou, je ten, aby dodávaly konkrétní výsledky nebo výstupy. A tyto výsledky nebo výstupy musí být identifikovatelné a spočitatelné. Procesy mají konkrétního zákazníka, tedy že proces dodává své výsledky nebo výstupy svému zákazníkovi nebo stakeholderovi a měl by naplňovat jejich očekávání. 62

63 Procesy odpovídají na konkrétní událost, což znamená, že u každého běžícího procesu by mělo být dohledatelné, co přesně jej spustilo. Pohled Governance je dle (Office, 2007) v metodice ITIL chápán jako cesta ke snižování transakčních nákladů. Transakční náklady jsou v (Office, 2007) definovány jako náklady spojené se specifikací zdrojů pro služby a specifikací požadavků zákazníků, uživatelských preferencí, kvalitativních kritérií a rozhodnutí o platebních podmínkách. Mezi další funkce Governance v rámci ITIL dle (Office, 2007) patří kontrola rozhodnutí, aby byly v souladu se strategiemi a provozními zásadami, řízení a dohled nad portfoliem služeb a projektů a také řízení vztahů s externími dodavateli služeb. Pohled Governance je pak dle (Office, 2007) zajištění, že politiky a strategie, které jsou implementované a požadované procesy, jsou správně naplňovány a respektovány. Governance také definuje role, zodpovědnosti, měřítka a způsob reportováni a přebírá zodpovědnost za řešení identifikovaných problémů ŘÍZENÍ A DOHLED NA ŽIVOTNÍ CYKLUS SLUŽEB V RÁMCI SOA Životní cyklus, který zavádí servisně orientovaná architektura, komplexně pokrývá problematiku služeb. (Wahli, 2007) zmiňuje dva důvody, proč zavádět životní cyklus služeb. První je, že životní cyklus služeb by měl být v rámci každého projektu, který implementuje servisně orientovanou architekturu. Za druhé, životní cyklus služeb umožňuje efektivnější růst zralosti celé architektury. O jeho kvalitách svědčí také fakt, že jej pro svá řešení používá společnost IBM. Proces má čtyři fáze a je znázorněn na Obr. 16. Dle (Wahli, 2007) jsou fáze životního cyklu služeb vymezeny následujícím způsobem: 1. Model v této fázi probíhá návrh služeb tak, aby dokázala pokrýt požadavky cíle podniku, které jsou definovány v podnikových procesech. Do návrhu jsou také zahrnuty tzv. KPIs (key performance indicators). 2. Assemble v této fázi probíhá sestavení služby tak, aby implementovaly návrh služby a služba dokázala provádět to, co se od ní očekává. Během této fáze se také vymezují potřebné prostředky, kontrola integrity, bezpečnostní mechanismy a prostředky pro řízení služby na základě politik obsažených v provozním prostředí. 3. Deploy v této fázi probíhá nasazení služby do provozního prostředí, aby mohla být využívána ke svému účelu. Také se v této fázi připravuje stávající infrastruktura pro 63

64 přijetí nové služby. Zdali jsou opravdu přítomné zdroje, které nová služba potřebuje a jaký má dopad na stávající aplikace a služby. 4. Manage v této fázi probíhá řízení, monitoring a hodnocení této služby pomocí specializovaných technologií, nástrojů a činností. Tato fáze má za úkol ověřit, že přínosy této služby jsou takové, pro jaké byla navržena a je také primárním zdrojem pro inovaci této služby, která její životní cyklus posouvá opět do fáze model. V neposlední řadě se také v této fázi ověřuje, že služba je neustále v souladu s obchodním modelem organizace. Obr. 16: Životní cyklus služeb dle SOA Foundation (Wahli, 2007) Referenční životní cyklus pro servisně orientovanou architekturu tedy prosazuje dvě klíčové oblasti. První je měřitelnost služeb, životní cyklus začíná definováním metrik a končí ověřením, zdali hodnoty dosahují požadované úrovně. Druhou oblastí je řešení implementačních a technologických požadavků infrastruktury, které služby vyžadují. SOA Governance je podobně jako životní cyklus služby proces. Ten však nemá za úkol pouze řídit a kontrolovat životní cyklus služeb, ale také spravovat služby, poskytovat informace o službách, které jsou již k dispozici, jejich monitorování a hodnocení jejich výkonnosti. SOA Governance vznikl na základě názoru, který vyslovil (Plummer, 2006) a je obecně přijímán IT architekty a dalšími profesemi, které se servisně orientovanou architekturou zabývají, a to konkrétně tento: Stačí jedna služba, aby nám zničila podnik, proto je zavedení i jediné služby, důvodem pro zavedení SOA Governance, která ji bude řídit a kontrolovat.. 64

65 SOA Governance úzce souvisí s životním cyklem služeb. Vazbu mezi fázemi životního cyklu a fázemi cyklu SOA Governance znázorňuje Obr. 17. Obr. 17: Vazba mezi fázemi životního cyklu služeb a fázemi SOA Governance dle SOA Foundation (Wahli, 2007) Dle (Wahli, 2007) jsou fáze SOA Governance vymezeny následujícím způsobem: 1. Plan v této fázi probíhá dokumentace požadavků a potřeb podniku. Také se analyzuje vyspělost stávajícího IT Governance v podniku (řízení celé informatiky). Na základě této analýzy se určí vize a cíle, které budou sloužit jako metriky k měření účinnosti a efektivnosti SOA Governance. 2. Define v této fázi je vytvořen detailní plán pro SOA Governance. Vymezí se procesy, které mají být řízeny, jejich priority, rozhodovací pravidla, politiky a metriky. Na konci této fáze je nadefinován detailní plán nasazování služeb. 3. Enable v této fázi je provedeno nasazení služeb do infrastruktury, jsou přiřazeny role, je vyškolen personál a jsou automatizována rozhodovací pravidla pomocí nástrojů pro podporu workflow. Také jsou zavedeny nástroje pro podporu reportingu. 4. Measure v této fázi je systém služeb provozován, monitorován a vyhodnocují se sledované metriky. Výsledky jsou pak podkladem pro úpravy služeb, aby lépe vyhověly požadavkům. SOA Governance je z hlediska organizační struktury součástí IT Governance. Rozšiřuje řízení podnikové informatiky o otázky týkajících se služeb, jejich komponent a podnikových procesů. SOA Governance je dle (Wahli, 2007) kritický faktor úspěšného dokončení 65

66 libovolného projektu, který souvisí se servisně orientovanou architekturou. SOA Governance má dle (Wahli, 2007) za úkol vypořádat se zejména s následujícími oblastmi: Stanovování rozhodovacích pravomocí určuje tedy, kdo může používat službu a jak má být používaná, kdo službu vlastní, jak jsou financovány sdílené služby, a kontroluje, zdali jsou jasně definované kvalitativní metriky služeb. Definuje hodnotu služeb, které jsou v souladu s obchodními cíli (jsou tzv. businessaligned) odpovídá na otázky, zdali podnikové ICT rozumí hodnotě služby jako odraz hodnoty pro organizaci a jaké jsou faktory úspěchu služby. Řídí životní cyklus majetku (včetně služeb) odpovídá na otázky, jaký dopad by měl pád určité služby, jak jsou oznamovány změny služeb a kdo schvaluje tyto změny. Měří efektivitu služeb odpovídá na otázky, jak zajistit, aby služby poskytovaly hodnotu organizaci jako celku a zároveň naplňovaly nesourodé požadavky jednotlivých oddělení a celků v rámci organizace, jaké jsou výkonnostní cíle služeb, jaké jsou dohodnuté potřebné úrovně služeb (SLA) a jak konsolidovat výkonnostní metriky. Jako hlavní přínosy správně řešeného Governance (Wahli, 2007) uvádí zvýšení ceny akcií, protože investoři jsou ochotni investovat do organizace se dobře definovanou Governance, zvýšení zisku, protože zavádění služeb je levnější a lépe podporují obchodní model organizace, a zvyšování hodnoty na trhu, které souvisí s předchozími dvěma přínosy, zvyšuje se hodnota akcií a roste ziskovost organizace ŘÍZENÍ A DOHLED NA ŽIVOTNÍ CYKLUS SLUŽEB V RÁMCI COBIT COBIT je de facto standard, který sám o sobě neřeší životní cyklus služeb, ale spíše se snaží v rámci pohledu Management definovat nefunkcionální vlastnosti služeb a v rámci pohledu Governance zavádí procesy, které by se měly v řízení podnikového ICT provozovat, a také vymezuje, jak provázat podnikové cíle s cíli, které podnikové ICT má. Oblasti, na které se COBIT v rámci IT Governance soustřeďuje, znázorňuje Obr. 18. Obrázek ukazuje oblasti zájmu, které jsou v rámci IT Governance dle COBITu definované. Jedná se dle (IT, 2007) o následující oblasti: Strategic Alignment se soustřeďuje na zajištění propojení podnikových plánů s těmi, které má podnikové ICT. Definuje, udržuje a ověřuje hodnotu přislíbenou 66

67 podnikovým ICT a také harmonizace činností a operací v rámci ICT s těmi, které jsou provozovány v rámci podniku. Value Delivery se zabývá samotným dodáváním přislíbené hodnoty skrze dodávkový cyklus, zajišťuje dodání přislíbených přínosů pro podnikovou strategii, optimalizaci nákladů a prokazuje vlastní hodnotu podnikového ICT. Resource Management se zabývá optimalizací investic do podnikového ICT a vlastním managementem kritických zdrojů podnikového ICT, jako jsou aplikace, informace, infrastruktura a lidé. Propojuje klíčové otázky k optimalizaci znalostí a infrastruktury. Risk Management vyžaduje od seniorních manažerů, aby si byli vědomi rizik a míry averze podniku vůči rizikům, aby rozuměli schvalovacím požadavkům, transparentně hodnotili rizika a začleňovali řízení rizik v rámci organizace. Perforance Measurement sleduje a monitoruje implementaci strategie, dokončování projektů, využívání zdrojů, výkonnost procesů a dodávku služeb a také definuje metodiky, jak výkonnost sledovat a měrit. Obr. 18: Oblasti zájmu v rámci IT Governance dle metodiky COBIT (IT, 2007) Vedle oblastí COBIT také zavádí procesy, které jsou rozděleny do čtyř domén, které jsou dle (IT, 2007) následující: Plan and Organise (Plánování a organizace) Acquire and Implement (Osvojení a implementace) Deliver and Support (Dodání a podpora) Monitor and Implement (Monitorování a ověřování) 67

68 Mezi tyto domény je rozděleno 34 procesů, které podrobně popisuje (IT, 2007) a které by měly být v rámci podnikového ICT provozovány. V kontextu této práce jich je však důležitých pouze několik, které souvisí s návrhem kompozitních business služeb a řízením jejich životního cyklu: Identify automated solutions (skupina Acquire and Implement) Acquire and maintain application software (skupina Acquire and Implement) Acquire and maintain technology infrastrucuture (skupina Acquire and Implement) Define and manage service levels (skupina Deliver and Support) Manage third-party services (skupina Deliver and Support) Tyto procesy mají svými výstupy dopad na to, jak by měly vypadat kompozitní business služby, pokud by pohled Governance byl realizován skrze de facto standard COBIT. Proces Identify automated solutions má dle (IT, 2007) za úkol hledat a definovat činnosti, které je možné automatizovat, a definuje požadavky na ně, přičemž musí nalézt vhodné a nákladově efektivní řešení. V případě této práce se vlastně jedná o identifikaci samotných kompozitních business služeb. Proces Acquire and maintain application software má dle (IT, 2007) za úkol řídit portfolio podnikových aplikací a upravovat je tak, aby dostupné podnikové aplikace optimálně podporovaly podnikové požadavky na ICT, přičemž musí zajišťovat časově a nákladově efektivní vývojový proces. V případě této práce se vlastně jedná o identifikace služeb různé úrovně, ze kterých se pak kompozitní business služby komponují. Proces Acquire and maintain technology infrastrucuture má dle (IT, 2007) za úkol udržovat funkční, integrovanou a standardizovanou technologickou infrastrukturu, přičemž musí zajistit, aby se skládala z vhodných platforem pro provoz podnikových aplikací a aby tato infrastruktura měla definované architektonické a technologické standardy. V případě této práce se vlastně jedná o technologické a podnikové standardy, které se v rámci kompozice business služeb používají. Proces Define and manage service levels má dle (IT, 2007) za úkol zajišťovat správnou podporu podnikové strategie ze strany klíčových ICT služeb, přičemž tyto služby musí splňovat požadovanou kvalitu. V případě této práce se vlastně jedná o správné definovaní SLA a QoS pro klíčové kompozitní business služby. 68

69 Proces Manage third-party services má dle (IT, 2007) za úkol z pohledu přínosů, nákladů a rizik poskytovat služby třetích stran, přičemž musí být definovány vztahy a zodpovědnosti v souvislosti se třetími stranami, a kvalitativní vlastnosti dodávaných služeb. V případě této práce se jedná o sestavování služeb, které jsou komponovány do interní infrastruktury služeb a definování jejich SLA a QoS. Je tedy evidentní, že COBIT z pohledu kompozitních business služeb vymezuje zásady a procesy, podle kterých je sestavováno portfolio služeb, definovány standardy, pomocí kterých jsou služby budovány a jak definovat jejich kvalitu. Ve srovnání s ostatními de facto standardy tedy COBIT definuje pouze pohled Governance, ale poskytuje kvalitní výstupy pro pohled Management. Je tedy možné říci, že COBIT je vhodný doplněk pro de facto standard ITIL, který by ve svých procesech, které se orientují na pohled Management, mohl vycházet z výstupů procesů v rámci COBITu SHRNUTÍ POZNATKŮ O POHLEDECH MANAGEMENT A GOVERNANCE Pojetí pohledů Management a Governance ve všech rámcích, které byly analyzovány, disponují podobnými zásadami. Životní cyklus služeb, který řídí pohled Management, by obvykle měl začínat definicí požadavků na funkcionalitu, výkon a kvalitu služby a měla by být definována měřitelná kritéria, podle kterých by mělo být naplnění požadavků posouzeno. Tyto požadavky pak přechází do dalšího kroku/kroků, ve kterých jsou služby modelovány, vyvinuty, nasazeny a je řízen jejich provoz. Nad tím vším pak probíhá cyklus, který služby monitoruje, vyhodnocuje jejich metriky a definuje zlepšovací kroky a projekty, které služby a jejich portfolio rozvijí, který se obvykle nazývá proces neustálého zlepšování služeb. Pohled Governance je pak na životní cyklus napojen zejména přes jeho počáteční fáze a proces neustálého zlepšování služeb. Na počátku zajišťuje, že se do tvorby a vývoje služeb dostanou jen takové služby, které podpoří strategii organizace regulatorními předpisy, a také definuje standardy a metriky, které musí služby splňovat. V procesu neustálého zlepšování služeb pak dohlíží na naplňování funkcionálních a kvalitativních metrik a na to, aby změnové a rozvojové projekty byly stále v souladu se strategií organizace a regulatorními opatřeními. 5.3 SHRNUTÍ POZNATKŮ O POHLEDECH NA KOMPOZITNÍ BUSINESS SLUŽBY V části práce, která se zabývala analýzou pohledů Engineering, Management a Governance, byly analyzovány metodiky a standardy, které je více či méně zapouzdřují. Všechny tři pohledy na sebe navazují, kdy v rámci pohledu Governance je řešeno, jaké služby a s jakými 69

70 vlastnostmi. Tyto služby pak přechází pod pohled Management, kde je řízen jejich vývojový a životní cyklus tak, aby služby splňovaly požadavky definované v rámci pohledu Governance. Úkolem pohledu Engineering je pak využít adekvátní technologické postupy, prostředky a technologie, pomocí kterých se takovéto služby vytvoří. Na základě těchto poznatků je možné upravit původní vztah pohledů. Upravené vztahy a vazby jsou znázorněny na Obr. 19. Obr. 19: Upravený vztah pohledů Engineering, Management a Governance (Autor) Z hlediska vztahů mezi těmito třemi pohledy je možné identifikovat úzkou vazbu mezi pohledy Governance a Management. Příkladem je možné uvést de facto standardy TOGAF a ITIL, kdy TOGAF předpokládá a doporučuje aplikaci metodiky ITIL. TOGAF v tomto případě společně s principy definovanými v rámci ITIL vydefinuje požadavky na služby v pohledu Governance. Tyto požadavky se pak aplikují na životní cyklus služby, kde vstupují do prvních fází. Stejným způsobem je pak možné kombinovat i de facto standardy COBIT a ITIL. Podobný přístup by bylo možné použít dále, kdy se více obecný životní cyklus služby v rámci ITIL nahradí životním cyklem definovaným v rámci servisně orientované architektury SOA pro kompozitní business služby. Takový to proces agregace je z logiky překrývajících se zásad, doporučení a principů možný, dokonce vhodný, protože ani TOGAF i ITIL, případně COBIT, jsou orientované na širší problematickou oblast a kompozitní business služby jsou pouze dílčí částí, které tyto de facto standardy pokrývají. Protože je pohled Governance vlastně na počátku vzniku služby, který definuje požadavky na služby a který velice často definuje politiky, pravidla a další nefunkcionální vlastnosti služeb, 70

71 lze vysvětlit časté použití standardu webových služeb v pohledu Engineering. Jak bylo poznamenáno v předchozím textu, standard webových služeb, disponuje celou řadou doprovodných rozšiřujících standardů, které jsou určené pro nastavování politik a pravidel (WS-Policy) a díky standardu WSDL mohou být pak tyto vlastnosti přímo součástí rozhraní služby. Na základě závěrů, které vyplynuly z analýzy části práce, která se zabývala kompozicí kompozitních business služeb, a závěrů, které vyplynuly z části práce, která se zabývala pohledy na kompozitní business služby, je možné říci, že vzhledem k požadavkům, které klade na kompozitní business služby pohled Governance, principům, které zavádí pohled Management, a možnostem, které nabízí pohled Engineering, je nejefektivnějším, nejvhodnějším a nejuniverzálnějšími standardy pro tvorbu kompozitních business služeb standard webových služeb ve spojení se standardy SCA a BPEL, které jsou doplněny vhodnými přenositelnými standardy (například rozhraní BAPI pro informační systémy společnosti SAP). Tyto standardy je možné aplikovat v různorodých podnikových infrastrukturách, s různorodými komunikačními kanály a zároveň respektovat principy servisně orientované architektury a všech tří pohledů. Jak bylo poznamenáno výše, tyto standardy jsou také doporučované pro použití na platformách WebSphere ESB Server a WebSphere Process Server, které jsou použity v rámci experimentu. Na základě těchto závěrů a důvodů budou pro experimentální kompozici služeb použity tyto standardy. 71

72 6 IMPLEMENTACE KOMPOZITNÍ BUSINESS SLUŽBY Následující část práce se zabývá experimentálním ověřením, které ověřuje, že je možné aplikovat na kompozitní business služby předpoklady a principy, které byly identifikovány v předchozích částech této práce. Pro tento experiment je zvoleno konkrétní návrhové a implementační prostředí, které má definované vlastnosti a omezení, na základě kterých je definováno, jaké vlastnosti můžeme u služeb ověřovat, jaké můžeme předpokládat a které ověřit nelze. Samotná experimentální kompozitní business služba je vyjmuta z většího celku, tzv. business case, který ji dodává určitý kontext. Následující části práce tedy popisují experimentální prostředí, business case, jaké požadavky jsou na kompozitní business službu kladeny, analytický, implementační a fyzický popis kompozitní business služby, a na závěr zhodnocení naplnění definovaných předpokladů a principů. 6.1 PŘEDPOKLADY A OMEZENÍ PROSTŘEDÍ EXPERIMENTU Jak bylo několikrát poznamenáno v předchozím textu, základem experimentu je platforma IBM WebSphere, konkrétně platformy IBM WebSphere ESB Server a IBM WebSphere Process Server, a aplikační a integrační platforma pro informační systém SAP, konkrétně SAP NetWeaver POPIS PROSTŘEDÍ Prostředí je provozováno na osobním laptopu Lenovo X61, jehož hardwarová konfigurace pro experiment klíčových komponent a operační systém jsou následující: Intel Core 2 Duo T7100 1,8 Ghz 4096 MB RAM Windows Vista Business 64-bit Aby platformy IBM WebSphere a SAP NetWeaver byly odděleny logicky i fyzicky, stejně jako v případě reálného prostředí, nejsou nainstalovány přímo na laptopu v prostředí Windows Vista Business, ale využívají se virtuální počítače provozované ve virtualizačním prostředí VMware Workstation Konfigurace virtuálního počítače s platformou SAP NetWeaver: 72

73 Hardwarová konfigurace o 1 virtuální procesor, každý procesor 1 jádro o 768 MB RAM o 35 GB HDD Softwarová konfigurace o Kompatibilita hardware pro VMware Workstation x o Windows Server 2003 Enterprise Edition SP2 32-bit o VMware Tools o SAP NetWeaver 7.01 ABAP o SAP GUI 7.10 o SAP NetWeaver Developer Studio 7.1 o SAP MMC SnapIn o MaxDB 7.7 o SQL Studio 7.6 o Database Manager 7.6 Konfigurace virtuálního počítače s platformou IBM WebSphere: Hardwarová konfigurace o 2 virtuální procesory, každý procesor 1 jádro o 1280 MB RAM o 30 GB HDD Softwarová konfigurace o Kompatibilita hardwaru pro VMware Workstation 6.0 a vyšší o Windows XP Professional SP3 32-bit o VMware Tools o IBM WebSphere Integration Developer 7.0 o IBM WebSphere ESB Server 7.0 o IBM WebSphere Process Server 7.0 o IBM DB2 Database 9 o IBM WebSphere MQ Server 7.0 o IBM WebSphere Message Broker 7.0 o IBM WebSphere Message Broker Toolkit

74 Pro lepší rozložení zátěže je virtuální počítač s platformou SAP NetWeaver provozován na externím disku, který je k laptopu Lenovo X61 připojen přes rozhraní USB 2.0, a virtuální počítač s platformou IBM WebSphere je provozován lokálně. Virtuální počítače jsou také nastaveny tak, aby mezi sebou a fyzickým počítačem mohly komunikovat skrze virtuální LAN, kterou poskytuje vizualizační prostředí VMware Workstation. Pro lepší názornost celou situaci znázorňuje Obr. 20. Ten ukazuje, jakým způsobem jsou organizovány virtuální počítače a prostředí pro provoz aplikací a služeb, které jsou součástí experimentu. Virtuální počítače jsou tedy propojeny skrze VMware Virtual LAN a z pohledu virtuálních počítačů se jedná o transparentní propojení skrze síťový switch, přes který mohou komunikovat mezi sebou a hostujícím fyzickým počítačem. Obr. 20: Fyzická podoba experimentálního provozního prostředí služeb (Autor) Na virtuálním počítači s operačním systémem Windows Server 2003 Enterprise Edition je provozována platforma SAP NetWeaver, která obsahuje databázový systém MaxDB a funkcionální moduly, které zapouzdřují business logiku implementovanou v informačním systému společnosti SAP nebo na platformě SAP NetWeaver. Na virtuálním počítači s operačním systémem Windows XP Professional je provozována platforma IBM WebSphere. Jejím základem je aplikační server IBM WebSphere Application Server (WAS), který je rozšířen o komponenty IBM WebSphere ESB Server (WESB) a IBM WebSphere Process Server (WPS). Na WESB jsou dostupné jednotlivé typy služeb (viz níže), které jsou komponovány do kompozitních business služeb, jež jsou dostupné na WPS. 74

75 Samotný vývoj služeb pak probíhá na virtuálním počítači s operačním systémem Windows XP Professional ve vývojovém prostředí IBM WebSphere Integration Developer OMEZENÍ PROSTŘEDÍ Omezení, kterými experimentální prostředí trpí, jsou způsobena zejména výkonnostními omezeními, které má laptop Lenovo X61, a také dostupnosti a licenčním omezením, které mají použité prostředí pro provoz aplikací a služeb. Výkonnostní omezení zapříčiňují skutečnost, že nebylo možné ověřovat principy na rozsáhlejším portfoliu služeb, které by vyžadovalo výrazně vyšší alokaci operační paměti pro virtuální počítač s platformou IBM WebSphere. Kompozitní business služba je tedy proto komponována pouze z jednodušších služeb, které využívají nepříliš komplikovaný kanonický model, aby operace nebyly příliš náročné. Také z výkonnostních důvodů nebyla řešena bezpečnost služeb. Licenční omezení souvisí především s absencí repositáře služeb. Pro platformu IBM WebSphere by byl vhodný repozitář IBM WebSphere Service Registry and Repository (WSRR), který je ve vývojových nástrojích pro vývoj služeb určených pro platformy WESB a WPS předpokládaný. Kvůli absenci WSRR pak není možné demonstrovat služby s doprovodnými standardy pro standard webových služeb jako například prosazování politik pomocí standardu WS-Policy nebo standardizované metadata o službách, která se také do repositáře služeb obvykle ukládají. Nejedná se však o kritická omezení. Absence složitější kompozice služeb a kanonického modelu nezabraňuje ověření principů, protože jejich podoba nemá zásadní vliv na možnosti kompozice služeb na platformách IBM WebSphere nebo SAP NetWeaver. Také absence repozitáře služeb nebrání ověřování principů, které souvisí s doprovodnými standardy ke standardu webových služeb, protože se jedná o obecně funkční a doplnitelnou funkcionalitu, která je na platformě IBM WebSphere podporovaná. 6.2 POPIS EXPERIMENTU V rámci části, která se zabývá popisem experimentu, bude popsán business case, ze kterého je kompozitní business služba vyjmuta, a také sumarizace požadavků, které musí tato služba splňovat, aby naplnila očekávané předpoklady a principy. 75

76 6.2.1 POPIS BUSINESS CASE Kompozitní business služba, která je v rámci experimentu navržena a implementována, logicky zapadá do aplikace typu internetového bankovnictví, ke kterému je možné přistupovat například pomocí webového prohlížeče. Jedná se o typické internetové bankovnictví, které umožňuje zobrazit provedené transakce, zadávat platební příkazy a pracovat s různými typy debetních a kreditních karet. Navržená a implementovaná kompozitní business služba je vyňata z funkcionality, která se zabývá operacemi s kartami. Konkrétně vrací na dotaz, který obsahuje jeden z možných identifikátorů klienta (viz dále v textu), seznam jeho debetních a kreditních karet POŽADAVKY KLADENÉ NA JEDNOTLIVÉ KOMPOZITNÍ BUSINESS SLUŽBY Jednotlivé požadavky na služby, aby odpovídaly požadavkům všech tří pohledů, byly postupně vymezovány v předchozích částech práce. Základním kritériem byly definované tři pohledy. V rámci pohledu Engineering byly definovány zásady, které jsou založené na obecném standardu servisně orientované architektury a podnikové metodice ESA. Vzhledem k omezení, která vyplývají z omezení experimentálního prostředí, jsou tyto zásady následující: Služby mohou ve své funkcionalitě využívat jiných služeb a samy pak mohou být použity v rámci jiné služby neboli je možné je vzájemně komponovat. Služby mají definované rozhraní/kontrakt, které specifikuje, jaké informace služba vyžaduje a jaký bude výstup této služby. Služby mají ve svém rozhraní/kontraktu popsány své kvalitativní parametry (v rámci experimentu není využito, ale možné to je). Služby mohou být vystaveny, aniž by musely samy řešit, jak budou přístupné nebo jak se bude řídit jejich kvalita. Služby respektují standardy v rámci podnikové informatiky, v případě tohoto experimentu se jedná o standardy: webové služby, SCA, BPEL a BAPI. Služby jsou trojího typu: task service, entity service a utility service; přičemž kompozitní business služba je také typu task service s rozdílem, že je reprezentovaná výhradně pomocí jazyka BPEL. Služby mají definovaný společný kanonický model. 76

77 Z hlediska zásad pro pohledy Management a Governance se vychází z předpokladu, že pro tyto pohledy mají preferovaný standard servisně orientovaná architektura a podniková metodika ESA definované procesy a principy. A v případě, kdy jsou v pohledu Engineering respektovány zásady, které standard servisně orientovaná architektura společně s metodikou ESA definují, se předpokládá, že v případě odstranění omezení tohoto experimentu by bylo možné principy pohledů Management a Governance aplikovat. Jedná se například o výše zmíněnou absenci repositáře služeb, který kromě aplikace politik umožňuje řídit zdroje služeb, vlastnická práva a odpovědnosti nebo definice SLA apod. To jsou oblasti, které nemají v rámci experimentu až tak velký význam, protože ačkoliv je definovaný business case, není definovaný v rámci konkrétní organizační struktury a v případě, kdy by byly organizační struktura nebo kvalitativní požadavky definovány, jednalo by se pouze o formální doplnění, které výsledky experimentu nijak neovlivní. Přestože jsou však zásady definované v pohledech Management a Governance v rámci experimentu omezené vlastnostmi business case, některé zásady jsou aplikovatelné a jsou v rámci experimentu dodrženy. Jedná se o dodržení návrhových a implementačních zásad definovaných v prvních dvou fázích životního cyklu služby dle obecného standardu servisně orientované architektury. Tedy fází Model a Assemble: 1. Model a. Vychází se z předpokladu požadavku na konkrétní funkcionalitu pokrývají se tedy konkrétní požadavky podniku. b. Realizace probíhá pomocí task služby, která je implementována pomocí BPEL (kompozitní business služba) naplňují se požadavky, které jsou definovány pomocí podnikových procesů. 2. Assemble a. Služba dokáže provádět svoji funkcionalitu sestavení služby tak, aby byla funkční při dodržení svého návrhu a při použití podnikových standardů. b. V rámci pohledu Engineering jsou použité jednotné definované podnikové standardy, jako jsou webové služby, SCA, BPEL a BAPI respektují se politiky provozního prostředí. 77

78 6.3 PROVEDENÍ EXPERIMENTU Jak bylo popsáno v předchozím textu, experiment je proveden v rámci prvních dvou fázích životního cyklu služby, který je definován v obecném standardu servisně orientované architektury. Konkrétně tedy fáze Model a Assemble. Fáze Model je popsána pomocí analytického popisu kompozitní business služby a fáze Assemble pomocí implementačního popisu a pomocí popisu fyzické podoby kompozitní business služby ANALYTICKÝ POPIS KOMPOZITNÍ BUSINESS SLUŽBY Jak bylo popsáno výše, základním vstupem pro první fázi Model životního cyklu služby jsou funkcionální požadavky služby. Základem těchto požadavků je podnikový proces, který reprezentuje operaci, kterou má navrhovaná kompozitní business služba implementovat. Implementovaný podnikový proces je zobrazen na Obr. 21. Obr. 21: Implementovaný podnikový proces (Autor) Tento podnikový proces se nazývá GetClientCardsOverview a vrací detailní seznam debetních a kreditních karet klienta. V rámci tohoto procesu jsou prováděny dvě operace: dotázání se na klienta a následně dotázání se na jeho debetní a kreditní karty. Vstupními hodnotami do procesu je jeden ze tří možných identifikátorů klienta: klientské číslo, rodné číslo nebo IČO. Výstupem pak je detailní seznam kreditních a debetních karet. V rámci procesu, který je reprezentován kompozitní business službou GetClientCardsOverview. V této kompozitní business službě jsou pak komponovány dvě další služby: GetClient a GetClientCard. Tyto tři služby vystavují svá rozhraní, reprezentovaná WSDL soubory, která obsahují vstupní a výstupní business objekty reprezentované pomocí XSD (XML Schema Definition), které jsou založeny na kanonickém modelu. Všechna rozhraní, definice business objektů a kanonický model jsou dostupné 78

79 v příloze této práce přílohy 13.1 a Business objekty, které jsou na vstupech a výstupech služeb, jsou zobrazeny na Obr. 22, Obr. 23, Obr. 24, Obr. 25, Obr. 26 a Obr. 27. Obr. 22: Vstupní business objekt pro službu GetClientCardsOverview (Autor) Obr. 23: Výstupní business objekt pro službu GetClientCardsOverview (Autor) Obr. 22 zobrazuje vstupní business objekt pro službu GetClientCardsOverview a Obr. 23 zobrazuje výstupní business objekt služby GetClientCardsOverview. Vstupní business objekt umožňuje vložit buď klientské číslo, rodné číslo, nebo IČO. Ve výstupním business objektu je pak podrobný seznam debetních a platebních karet klienta. 79

80 Obr. 24: Vstupní business objekt pro službu GetClient (Autor) Obr. 25: Výstupní business objekt pro službu GetClient (Autor) Obr. 24 zobrazuje vstupní business objekt pro službu GetClient a Obr. 25 zobrazuje výstupní business objekt služby GetClient. Vstupní business objekt umožňuje vložit buď klientské číslo, rodné číslo, nebo IČO. Ve výstupním business objektu jsou pak informace o klientovi. 80

81 Obr. 26: Vstupní business objekt pro službu GetClientCard (Autor) Obr. 27: Výstupní business objekt pro službu GetClientCard (Autor) Obr. 26 zobrazuje vstupní business objekt pro službu GetClientCard a Obr. 27 zobrazuje výstupní business objekt služby GetClientCard. Vstupní business objekt umožňuje vložit klientské číslo a volitelně číslo bankovního účtu. Ve výstupním business objektu je pak podrobný seznam debetních a platebních karet klienta. Pokud je vyplněno volitelné pole a číslo bankovního účtu ve vstupním business objektu, vrátí služba ve výstupním business objektu pouze karty, které jsou k zadanému účtu. 81

82 6.3.2 IMPLEMENTAČNÍ POPIS KOMPOZITNÍ BUSINESS SLUŽBY Pro implementaci služeb, jak bylo uvedeno v předchozích částech práce, jsou použity standardy webové služby, SCA, BPEL a BAPI. V rámci experimentálního prostředí jsou přítomny tři různá prostředí pro provoz aplikací a služeb. Zmíněné použité standardy jsou zvoleny takovým způsobem, aby byly pro tato prostředí v maximální možné míře přirozená. Samotné služby, které jsou přítomny na platformě IBM WebSphere, využívají standardy webové služby, SCA a BPEL. Standard BAPI je použitý pro komunikaci mezi platformou IBM WebSphere a platformou SAP NetWeaver. Globální referenční architektura, která znázorňuje jak a kde jsou jednotlivé standardy použity, je vyobrazena na Obr. 28. Standard webové služby je použitý pro přístup ke službám z vnějšku. Jedná se o přístup konzumenta služeb nebo o komunikaci a kompozici služeb mezi různými prostředími pro provoz aplikací a služeb, v případě experimentu mezi IBM WebSphere Process Server a IBM WebSphere ESB Server. Standard SCA je použitý pro komunikaci a kompozici v rámci stejného prostředí. V případě experimentu se jedná o komunikaci a kompozici služeb na platformě IBM WebSphere ESB Server. V rámci globální referenční architektury jsou také znázorněny, jak jsou komponovány jednotlivé typy služeb, kdy sdílené služby typu Utility Service jsou využívány napříč službami typů Entity Service a Task Service, nebo i jiné službě typu Utility Service. Služby typu Entity Service a Utility Service pak v sobě zapouzdřují specifické služby, které obsahují adaptér, pomocí kterého jsou schopny zpřístupňovat skrze standard BAPI funkcionální moduly na platformě SAP NetWeaver. Technicky je možné říci, že tyto specifické služby jsou také služby Typu Utility Service, nicméně nejsou sdílené v takové míře mezi ostatními službami. 82

83 Obr. 28: Globální referenční architektura experimentu (Autor) 83

84 6.3.3 FYZICKÁ PODOBA KOMPOZITNÍ BUSINESS SLUŽBY Jak bylo uvedeno v předchozích částech práce, kompozitní business služba reprezentuje business proces pomocí jazyka BPEL. Podoba podnikového procesu na Obr. 21 v jazyce BPEL je vyobrazen na Obr. 30. Jedná se o technicky komplikovanější, ale velice podobný diagram, které oproti samotnému business procesu obsahuje i ošetření chyb, které mohou služby během dotazů vrátit. Ve vývojovém nástroji IBM WebSphere Integration Developer je takováto kompozitní business služba reprezentována diagramem, který je vyobrazen na Obr. 29. Obr. 29: Diagram reprezentující kompozitní business službu a vazby na komponované služby (Autor) Základem tohoto diagramu je modul se samotnou prosení logikou reprezentovanou jazykem BPEL, který je na Obr. 30. Modul je SCA komponenta, která je definována rozhraním a umožňuje definovat tzv. exporty a importy. Export (je nalevo od komponenty) definuje binding, skrze který služba vystavuje své rozhraní svému okolí ať už uvnitř své platformy, nebo prostředí vně platformy. Import definuje binding a rozhraní komponovaných služeb. V obou případech se jedná o binding pomocí standardu webové služby, protože kompozitní business služba je volána z vnějšího prostředí platformy a také volá komponované služby, které jsou provozovány mimo platformu (binding napovídají písmena WS v názvech importů). Služby GetClient a GetClientCard jsou zástupci dvou různých typů služeb. GetClient je služba typu Entity Service a služba GetClientCard je typu Task Service. Ve vývojovém nástroji IBM WebSphere Integration Developer jsou tyto služby reprezentovány diagramy, které jsou vyobrazeny na Obr. 31 a Obr. 32. Služba GetClient je typu Entity Service a jedná se o SCA komponentu, která své rozhraní vystavuje pomocí exportů, které definují binding pomocí standardu SCA pro kompozici v rámci platformy a binding pomocí standardu webové služby pro přístup z vnějšku platformy. Importy pak zpřístupňují skrze standard SCA dvě služby. První služba 84

85 SAPGetClient je s adaptérem pro platformu SAP NetWeaver a druhá služba GetCode, jejíž import je popsán GetFailureCodeSCA, je služba typu Utility Service, která poskytuje číselníkové překlady a která bude popsána dále v textu. Obr. 30: Reprezentace podnikového procesu pomocí jazyka BPEL (Autor) 85

86 Obr. 31: Diagram reprezentující službu GetClient typu Entity Service a vazby na komponované služby (Autor) Obr. 32: Diagram reprezentující službu GetClient Card typu Task Service a Vazby na kompono vané služby (Autor) Služba GetClientCard je typu Task Service a jedná se o dvě SCA komponenty, z nichž komponenta nazvaná GetClientCard také své rozhraní vystavuje pomocí standardů SCA a webové služby stejně jako služba GetClient, která je popsána výše. Druhá komponenta PairCard slouží k doplnění číselníkových hodnot pomocí iterace v seznamu karet, kdy se pro každou položku seznamu, v tomto případě záznamu karty, provede sada operací a po zpracování celého seznamu se mezivýsledky zpět spojí do původního seznamu. Rozdíl oproti služba GetClient je zejména v komplexnější logice, kterou služba GetClientCard oproti službě GetClient zapouzdřuje, a v počtu služeb, které pomocí importů přes standard SCA komponuje. Tato služba v sobě komponuje tři služby, službu GetCode typu Utility Service, jejíž import je popsán GetFailureCodeSCA, službu GetCard typu Entity Service, která je volána ve dvou krocích, a službu SAPGetAccount s adaptérem pro platformu SAP NetWeaver, která je zpřístupněna skrze importy popsané SAPGetClientAccountSCA a SAPGetAccountSCA a která bude popsána dále v textu. Dvojí odlišné volání služby SAPGetAccount souvisí s možností zadat volitelnou hodnotu čísla účtu, jak bylo popsáno 86

87 v předchozím textu. Oba typy dotazů se totiž uvnitř služby GetClientCard zpracovávají odlišným způsobem. Pro úplnost výčtu zbývají poslední dva typy služeb, a to služba typu Utility Service a služba obsahující adaptér pro platformu SAP NetWeaver. V rámci kompozitní business služby GetClientCardsOverview je využívána služba GetCode, jejíž reprezentující diagram ilustruje Obr. 33. Obr. 33: Diagram reprezentující službu GetCode typu Utility Service (Autor) Služba GetCode je typu Utility Service s jedná se o tři SCA komponenty, které vystavují svá rozhraní pomocí standardu SCA pouze pro komponování v rámci platformy, a importují službu SAPGetCode s adaptérem pro platformu SAP NetWeaver pomocí standardu SCA. Jak bylo několikrát zmíněno výše, služba GetCode slouží k číselníkovým překladům. Aby bylo možné každou komponentu importovat do ostatních komponent pomocí stejného rozhraní, každá z komponent upravuje příchozí dotaz tak, aby v rámci služby provozované na platformě SAP NetWeaver byla hodnota překládána pomocí správného číselníku. Jedná se o číselníky chyb, které služby vrací, kódů bank a organizací pro doplnění čísel účtů a kódů produktů, kde jsou doplňující popisy pro typy účtů a typu debetních a kreditních karet. Posledním typem jsou služby, které obsahují adaptér pro platformu SAP NetWeaver. V předchozím textu byla zmíněna služba SAPGetAccount, jejíž reprezentační diagram ukazuje Obr. 34. Služba SAPGetAcccount, která obsahuje adaptér pro platformu SAP NetWeaver, vystavuje dvě různá rozhraní, kdy, jak bylo poznamenáno výše, jedno je použité pro obecný dotaz skrze klientské číslo (SAPGetClientAccount) a druhé na dotaz skrze kolekci čísel účtů (SAPGetAccount). Služba se skládá ze dvou SCA komponent, z nichž první, pojmenovaná 87

88 SAPGetAccount, zapouzdřuje samotný adaptér pro službu na platformě SAP NetWeaver. Popis služeb a logiky implementované na platformě SAP NetWeaver je dotupná v příloze této práce příloha Druhá komponenta nazvaná PairAccount plní podobnou funkci jako komponent PairCard ve službě GetClientCard, tedy doplnění číselníkových hodnot. Výstupem této služby je seznam účtů s podrobnými informacemi včetně informací o debetních a kreditních kartách, který odpovídá seznamu čísel účtů na vstupu nebo seznamu účtů, které má klient s klientským číslem na vstupu evidované. Pro lepší představu o tom, jak vypadají vstupní a výstupní business objekty, jsou všechna rozhraní, definice business objektů a kanonický model jsou dostupné v příloze této práce přílohy 13.1 a 13.2, jak bylo zmíněno už v předchozím textu. Celkový pohled na konkrétní kompozici služeb v rámci celého řešení ilustruje Obr. 35, který koresponduje s referenční architekturou vyobrazenou na Obr. 28. Obr. 34: Diagram reprezentující službu SAPGetAccount, která zapouzdřuje adaptém pro platformu SAP NetWeaver (Autor) Konkrétní kompozice služeb ukazuje, jak jsou v reálné kompozici použité principy vymezené v rámci referenční architektury. Zejména využití a sdílení služby GetCode napříč všemi službami a použití standardů pro komunikaci a kompozici služeb v rámci a mimo rámec platformy. Jediný rozdíl oproti referenční architektuře je ten, že služba GetClientCard komponuje přímo službu SAPGetAccount a neexistuje mezi nimi mezičlánek v podobě nějaké služby typu Entity Service. Základní důvody pro tento krok jsou tři. Prvním důvodem je skutečnost, že služba SAPGetAccount již poskytuje potřebný vstup pro službu GetClientCard, druhým důvodem je skutečnost, že služba SAPGetAccount v sobě zapouzdřuje dvojí zpracování dotazů a pohledu referenční architektury by měla být vystavena skrze dvě rozdílné služby typu Entity Service, což by mohlo způsobit problémy z pohledu výkonnostních omezení experimentálního prostředí. Třetím důvodem je skutečnost, že služba 88

89 typu Task Service nemusí být komponována výlučně ze služeb typu Entity Service, a za předpokladu, že služba obsahující adaptér pro platformu SAP NetWeaver je považována službu typu Utility Service, je možné říci, že služba GetClientCard z architektonického pohledu plní funkci určité vystavující služby pro službu SAPGetAccount stejně jako u ostatních služeb jejich služby typu Entity Service. 89

90 Obr. 35: Pohled na konkrétní kompozice služeb korespondující s referenční architekturou (Autor) 90

91 6.4 ZHODNOCENÍ NAPLNĚNÍ PŘEDPOKLADŮ IMPLEMENTOVANÝMI KOMPOZITNÍMI BUSINESS SLUŽBAMI Předpokladů, které byly v rámci experimentu ověřovány, bylo v rámci pohledu Engineering definováno šest a v rámci pohledů Management a Governance byly ověřovány předpoklady čtyři. V pohledu Engineering to byly následující předpoklady, které byly ověřovány: 1. Služby mohou ve své funkcionalitě využívat jiných služeb a samy pak mohou být použity v rámci jiné služby neboli je možné je vzájemně komponovat. 2. Služby mají definované rozhraní/kontrakt, které specifikuje, jaké informace služba vyžaduje a jaký bude výstup této služby. 3. Služby mohou být vystaveny, aniž by musely samy řešit, jak budou přístupné nebo jak se bude řídit jejich kvalita. 4. Služby respektují standardy v rámci podnikové informatiky, v případě tohoto experimentu se jedná o standardy: webové služby, SCA, BPEL a BAPI. 5. Služby jsou trojího typu: task service, entity service a utility service; přičemž kompozitní business služba je také typu task service s rozdílem, že je reprezentovaná výhradně pomocí jazyka BPEL. 6. Služby mají definovaný společný kanonický model. První předpoklad naplněn je, služby jsou vzájemně komponovatelné a je možné, aby mezi sebou sdílely svoji funkcionalitu. Druhý předpoklad naplněn je, každá SCA komponenta, která službu reprezentuje, definuje vstupní a výstupní business objekty, které určují rozhraní/kontrakt služby. Třetí předpoklad je splněn, implementace samotné SCA komponenty je nezávislá na exportech, které určují, jakým způsobem jsou následně přístupné. Čtvrtý předpoklad je splněn, v rámci řešení jsou použity vyjmenované standardy, které určují podnikové standardy a politiky provozního prostředí. Pátý předpoklad je splněn, v rámci řešení jsou definovány, popsány a používány vyjmenované typy služeb. Šestý předpoklad je splněn, business objekty používané v rámci řešení používají sdílený kanonický model. V pohledech Management a Governance to byly následující předpoklady, které byly ověřovány: 91

92 1. Vychází se z předpokladu požadavku na konkrétní funkcionalitu pokrývají se tedy konkrétní požadavky podniku. 2. Realizace probíhá pomocí task služby, která je implementována pomocí BPEL (kompozitní business služba) naplňují se požadavky, které jsou definovány pomocí podnikových procesů. 3. Služba dokáže provádět svoji funkcionalitu sestavení služby tak, aby byla funkční při dodržení svého návrhu a při použití podnikových standardů. 4. V rámci pohledu Engineering jsou použité jednotné definované podnikové standardy, jako jsou webové služby, SCA, BPEL a BAPI respektují se politiky provozního prostředí. První předpoklad je splněn, kompozitní business služba je navržena a implementována na základě konkrétního požadavku. Druhý předpoklad je splněn, kompozitní business služba je realizována pomocí jazyka BPEL, který odpovídá podnikovému procesu. Třetí předpoklad je splněn, služba funguje při dodržení návrhu a při použití podnikových standardů. Čtvrtý předpoklad je splněn, služba respektuje vyjmenované podnikové standardy a politiky provozního prostředí. Výsledek experimentu je tedy takový, že (je možné) služby, které využívají služeb informačního systému SAP, je možné dle definovaných zásad na konkrétním prostředí platforem IBM WebSphere ESB Server a IBM WebSphere Process Server navrhnout a implementovat takovým způsobem, aby respektovaly pohledy Engineering, Managemant a Governance. 92

93 7 ZÁVĚR Diplomová práce: Využití systému SAP v kompozici business služeb Tato práce byla zaměřena na problematiku služeb v rámci podnikového ICT. Cílem práce bylo prověření možnosti aplikace zásad a principů servisně orientované architektury a dalších standardních metodik při kompozici vnitřně procesně řízené složité business služby, která komponuje služby informačního systému SAP. Současně byla samotná kompozice realizována s využitím konkrétních technických prostředků, kterými byly IBM WebSphere Process Server, IBM WebSphere ESB Server a informační systém SAP. Významná část práce analyzovala problematiku služeb, jak je členit a klasifikovat, přičemž samotná analýza nevycházela z pojetí služeb v rámci podnikového ICT, ale vycházelo se z obecného pojetí služeb, kdy jsou služby nepostradatelnou součástí produktových portfolií společností všech velikostí po celém světě. Služby v rámci podnikového ICT pak byly analyzovány v korespondenci s poznatky, které byly získány v souvislosti s analýzou služeb v obecném pojetí, na základě rešerše stávajících kvalifikačních prací a publikovaných článků a v neposlední řadě na poznatcích získaných z odborné literatury. Detailní klasifikace, vlastnosti a zásady pro kompozici kompozitních business služeb byly vymezeny na základě standardů de jure a de facto, které vyplynuly z analýzy služeb v rámci podnikového ICT. Detailní klasifikace, vlastnosti a zásady pak byly interpretovány skrze pohledy Engineering, Management a Governance. Tyto pohledy společně ovlivňují životní cyklus kompozitních business služeb, kdy pohled Governance definuje funkcionální požadavky, politiky pro jejich provoz a další nefunkcionální požadavky na služby a dohlíží na pohled Management, aby tyto požadavky a politiky dodržoval. Pohled Management pak řídí samotný životní cyklus, který začíná přijetím požadavků na službu a končí dodáním služby, která požadavkům odpovídá. Pohled Engineering pak využívá adekvátních metodických a technologických prostředků, aby byl tyto služby schopen zkonstruovat. Pro ověření, že je možné kompozitní business službu, který tyto tři pohledy respektuje, zkonstruovat, byl proveden experiment na výše zmíněných technických prostředcích od společností IBM a SAP. V rámci experimentu byly vymezeny zásady, které bylo možné vhledem k omezením provozního prostředí ověřit, a byla navržena a implementována kompozitní business služba, která tyto zásady splňovala. Vzhledem ke skutečnosti, že se podařilo všechny zásady splnit, je možné říci, že cíl a předpokládaný přínos práce byl splněn a že je možné celou práci hodnotit jako úspěšnou. 93

94 Předpokládaný přínos práce spočíval v zodpovězení otázky, zdali je možné navrhnout a vyvinout kompozitní business službu, která respektuje zásady tří pohledů, které vycházejí z používaných standardů pro řízení podnikového ICT. Práce má i další přínosy. Jedním z nich je ukázka vývoje aplikačních služeb, které respektují zásady servisně orientované architektury, a ukázka toho, jak takové aplikační služby vypadají. Dalším přínosem jsou samotné zásady tří pohledů, které vznikly syntézou principů, které zavádí standardy pro řízení podnikového ICT. Přínosem je také poznatek, jakým způsobem probíhá propojení businessu a podnikového ICT a na jakých úrovních řízení probíhají konkrétní rozhodnutí o obsahu a podobě portfolia ICT služeb. Diplomovou práci je možné využít v praxi i pro další navazující témata. V rámci praxe je možné tuto práci použít v prostředích, kde jsou využívány zejména výše zmíněné prostředky od společnosti IBM, a aplikovat v rámci životního cyklu kompozitních business služeb zásady, které jsou definované ve třech pohledech. Z pohledu navazujících témat se nabízí několik oblastí, které by bylo možné v navazujícím tématu obsáhnout. Jedná se například o téma, které by se zabývalo implementací doprovodných a rozšiřujících standardů, jako jsou prostředky pro bezpečnost služeb, vynucování politik a dalších do stávajícího řešení. Dalším tématem je dopad na stávající kanonický model, pokud by kompozitní business služby nevyužívaly pouze prostředků informačního systému SAP, ale i dalších aplikačních platforem, například aplikace Oracle e-business Suite apod. Další možností, jak na toto téma navázat, je analýza možností, jak definované tři pohledy a stávající řešení aplikovat na platformu IBM DataPower nebo případně rozšířit použité technické prostředky společnosti IBM o platformu IBM WebSphere MQ a IBM WebSphere Message Broker a provést analýzu přínosů pro stávající řešení. V neposlední řadě je možné zásady tří pohledů ověřovat na jiných technických prostředcích. 94

95 8 TERMINOLOGICKÝ SLOVNÍK Tab. 2: Terminologický slovník (Autor) Termín Zkratka Definice Aplikační služba Služba, které má za úkol dodávat aplikační funkcionalitu. (Voříšek, 2008), (Hrabě, 2010) Blueprint Technický nákres, architektonická dokumentace nebo inženýrský návrh, který je možné použít jako detailní plán. (Wikipedia, 2009) Business viz Business Objekt Entita Business Objekt Business objekt je datová šablona, která reprezentuje a popisuje určitou entitu nebo objekt, se kterou pak je možné pracovat jako se samostatným celkem. (Gavin, a další, 2005) Business Služba Aplikace, které jsou vyžívány, jednotlivými podnikovými pracovními celky a které jsou obvykle dostupné přes počítačovou síť. (Heffner, 2007) Enterprise Kompozitní aplikace, vytvořené dle specifikace ESA. (Woods, a další, 2006) Service Kompozitni Business Služba Komponované služby, které mají přímou vazbu na business. (Autor) Service Level Agreement Service Orientation Service Oriented Service Oriented Computing SLA SOC Dokument, který u služeb kodifikuje dohodu s jejich konzumentem o úrovni, rozsahu a kvalitě služeb, které konzumuje. (Office, 2007) Orientace na služby, a to jako návrhové paradigma, které zahrnuje specifickou množinu návrhových principů, které vedou řešení pomocí služeb, kdy službou se rozumí fyzicky nezávislá část software, která podporuje konkrétní cíl v rámci service oriented computing. (Erl, 2007) Pohled, kdy jsou zdroje členěny na definované, jasně ohraničené a neprovázané služby. (Schekkerman, 2011) Nová generace distribuovaných modelů pro řízení informatiky, který definuje nová návrhová paradigmata a návrhové principy, architektonické modely, představy, technologie a frameworky, zaměřených na služby. (Erl, 2007) 95

96 9 PŘEHLED POUŽITÝCH ZKRATEK Tab. 3: Přehled použitých zkratek (Autor) Zkratka Význam API Application Programming Interface BAPI Business Application Programming Interface BPEL Business Process Execution Language BPMN Business Process Modeling Notation COBIT Control Objectives for Information and relater Technology COM Component Object Model CORBA Common Object Request Broker Architecture EA Enterprise Architecture EJB Enterprise Java Beans ESA Enterprise Service Architecture FTP File Transfer Protocol HDD Hard Disk Drive HTTP Hypertext Markup Language ICT Information and Communication Technology ISO International Organization for Standardization ITIL Information Technology Infrastructure Library JMS Java Messaging Systém KPI Key Performance Indicator MOM Message Oriented Middleware ODBC Open Database Connectivity OLE Object Linking and Embedding QoS Quality of Service RAM Random Access Memory REST Representational State Transfer RPC Remote Procedure Call SCA Service Component Architecture SLA Service Level Agreement SOA Service Oriented Architecture SOAP Simple Object Access Protocol (do verze 1.2) SOC Service Oriented Computing TOGAF The Open Group Architecture Framwork UDDI Universal Description Discovery and Integration VBA Visual Basic for Applications WCF Windows Communication Foundation WS-BPEL viz BPEL WSDL Web Service Description Language xapps Kompozitní aplikace na platformě SAP NetWeaver XML Extensible Markup Language 96

97 10 PŘEHLED LITERATURY A POUŽITÝCH ZDROJŮ Arsanjani, A How to Identify, Specify and Realize Services for your SOA (Part II and III). [Online] Bechynský, Štěpán. 200x. Úvod do Windows Communication Foundation. Microsoft Developer Network. [Online] Microsoft Corporation, 200x. [Citace: ] Benatallah, B., Dumas, M. a Sheng, Q. Z Facilitating the rapid development and scalable orchestration of composite Web services. Distributed and parallel databases. 2005, Sv. 17, 1. Burian, Tomáš Problematika ESB jako součást SOA řešení. Praha : Vysoká škola ekonomická v Praze, Coffey, John, a další Locating Software Features in a SOA Composite Application. : Security and Software Research Center, S2ERC-TR-304. Daňhel, Jaroslav, a další Pojistná teorie. Praha : Professional Publishing, str ISBN Erl, Thomas Service-Oriented Architecture Concepts, Technology and Design. Upper Saddle River : Prentice Hall, str ISBN SOA Principles: An Introduction to the Service-Orientation Paradigm. SOA Principles. [Online] SOA Systems Inc., [Citace: ] SOA Servisně orientoavná architektura: Kompletní průvodce. Brno : Computer Press, str ISBN SOA: Principles of Service Design. Boston : Prentice Hall, str ISBN Feuerlicht, George Enterprise Computing. Praha : Oeconomica, str ISBN

98 Fischer, Roman Podpora webových služeb v prostředí.net framework. Praha : Vysoká škola ekonomická v Praze, Gadatsch, Andreas, a další SAP R/3 Kompletní průvodce. Brno : Computer Press, str ISBN Gála, L., Pour, J. a Šedivá, Z Podniková informatika. Praha : Grada Publishing, str ISBN Gála, L., Pour, J. Toman, P Podniková informatika. Praha : Grada Publishing, str ISBN Gavin, Lee, a další WebSphere Business Integration Adapters: An Adapter Development and WebSphere Business Integration Solution. New York : IBM International Technical Support Organization, ISBN Gu, T., Pung, H. K. a Zhang, S. Q A service-oriented midleware for building context-aware services. Journal of network and computer applications. 2005, Sv. 28, 1. Havey, Michael Essential Business Process Modeling. Sebastopol : O'Reilly Media, Inc., str ISBN Heffner, Randy Your Strategic SOA Platform Vision by Randy Heffner. Your Strategic SOA Platform Vision by Randy Heffner. [Online] [Citace: 6. Duben 2010.] Hophe, Gregor a Woolf, Bobby Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions. Boston : Addison-Wesley Professional, str ISBN Hrabě, Pavel Úloha služeb v rámci podnikové architektury (Enterprise Architecture). Systémová integrace. 2010, Sv. 17, 1. IBM IBM Advantage for Service maturity Model Standards. DeveloperWorks. [Online] [Citace: ] 98

99 Ionita, Anca Daniela, Florea, Monica a Jelea, Lucian Correspondence between Multiple Views in a SOA Trans-National Business System. London : Proceedings of the World Congress on Engineering, ISBN ISO/EIC Corporate governance of information technology. Geneva : ISO copyright office, IT Governance Institute COBIT 4.1. Rolling Meadows : IT Governance Institute, str ISBN Josuttis, Nicolai SOA in Practice. Sebastopol : O'Reilly Media, str ISBN Kmínek, Jiří Porovnání nástrojů pro integraci aplikací. Praha : Vysoká škola ekonomická v Praze, Kočí, Vladimír Integrácia aplikacií pomocou podnikovej zbernice služeb. Bratislava : Univerzia Komenského v Bratislave, str. 80. Koten, Jiří Problémy on-line integrace v bankovním prostředí při aplikaci SOA principů. Praha : Vysoká škola ekonomická v Praze, str. 80. Krafzig, D., Banke, K. a Slama, D Enterprise SOA. Boston : Prentice Hall, ISBN Liberty, Jessie, Maharry, Dan a Hurwitz, Dan Programming ASP.NET 3.5, Fourth Edition. Sebastopol : O'Reilly Media, Inc., str ISBN Lukáč, L'ubomír IT Management. Brno : Computer Press, a. s., ISBN Malik, Filip Podniková servisně orientovaná architektura. Brno : Masarykova Univerzita, str. 63. Mario, Jim a Rowley, Michael Understanig SCA (Service Component Architecture). Boston : Addison Wesley, str ISBN Michalička, Jan Vliv SOA na podnikové informační systémy společnosti SAP. Praha : Vysoká škola ekonomická v Praze,

100 Minoli, Daniel Enterprise Architecture A to Z: Frameworks, Business Process Modeling, SOA, and Infrastructure Technology. Boca Raton : CRC Press, str ISBN Office of Goverment Commerce ITIL 3 Official Introduction. Norwich : The Stationery Office, str ISBN ITIL 3 Service Design. Norwich : The Stationery Office, str ISBN ITIL 3 Service Strategy. Norwich : The Stationery Office, str ISBN O'Sullivan, Justin, Edmond, David a ter Hofstede a Arthur, H. M Service Description: A survey of the general nature of services. Brisbane : Centre for Information Technology Innovation, Queensland University of Technology, Papazoglou, M. P., a další Service-oriented computing: State of the art and research challenges. Computer. 2007, Sv. 40, 11. Patrick, Tim Programming Visual Basic Sebastopol : O'Reilly Media, Inc., str ISBN Plummer, Daryl SOA governance key at Gartner. SearchSOA.com. [Online] Gartner Inc., [Citace: 6. Duben 2010.] Ramachandra, K., Chandrashekara, B. a Shivakumar, S Services Management (Including Skill Development). Mumbai : Global Media, str ISBN Randová, Libuše Integrace aplikací SaaS do podnikového informačního systému. Praha : Vysoká škola ekonomická v Praze, Rao, Jinghai a Su, Xiaomeng A Survey of Automated Web Service Composition Methods. Trondheim : Norwegian Unversity of Science and Technology, N Schekkerman, Jaap All you need to know about Services Orientation!! Amstelveen : IFEAD & Logica management consulting,

101 EA & Services Oriented Enterprise (SOE) / Service Oriented Architecture (SOA) and Service Oriented Computing (SOC). Institute For Enterprise Architecture Developments. [Online] Institute For Enterprise Architecture Developments, [Citace: ] Sova, Jiří Standardizace orchestrace v prostředí služeb. Praha : Vysoká škola ekonomická, Sprott, D. a Wilkes, L Understanding Service-Oriented Architecture. Microsoft Developer Network. [Online] CBDI Forum, [Citace: ] The Open Group TOGAF Version 9. Reading : The Open Group, str ISBN Vančura, Tomáš Nástroje pro automatizace workflow. Brno : Vysoké učení technické v Brně, str. 62. Voříšek, J. a kolektiv Principy a modely řízení podnikové informatiky. Praha : Oeconomica, str ISBN Voříšek, J., Pavelka, J., Vít, M Aplikační služby IS/ICT formou ASP - Proč a jak pronajímat informační služby. Praha : Grada Publishing, str ISBN Wahli, Ueli, Ackerman, Lee, Di Bari, Alessandro, Hodgkinson, Gregory, Kesterton, Anthony, Olson, Laura, Portier, Bertrand Building SOA Solutions Using the Rational SDP. New York : IBM International Technical Support Organization, str ISBN Weerawarana, Sanjiva, a další Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More. Upper Saddle River : Prentice Hall, str ISBN Wikipedia Wikipedia. Blueprint. [Online] [Citace: ] Woods, Dan a Mattern, Thomas Enterprise SOA: Designing IT for Business Inovation. Sebastopol : O'Reilly Media, str ISBN

102 Yu, T., Zhang, Y. a Lin, K.-J Efficitent algorithms for Web services selection with end-to-end QoS constraints. ACM Transactions on the Web. 2007, Sv. 1, 1. ZapThink. 200x. Service-Oriented Architecture Expertise, Advisory, and Influence. [Online] ZapThink, 200x. [Citace: ] 102

103 11 SEZNAM OBRÁZKŮ Obr. 1: Propojení zdrojů podnikové informatiky a business procesů pomocí ICT služeb (Voříšek, 2008) Obr. 2: Obecný pohled na kompozici služeb pro řešení rozsáhlého problému (Erl, 2007) Obr. 3: Vazba mezi ISO standardy, standardy pro řízení ICT a podnikovými metodikami pro budování služeb (Autor) Obr. 4: Typy služeb v jednotlivých vrstvách (Erl, 2007) Obr. 5: Příklad kompozice služeb (Erl, 2007) Obr. 6: Rozhraní business služeb dle ESA (Woods, a další, 2006) Obr. 7: Standardy v rámci kompozitních aplikací (Woods, a další, 2006) Obr. 8: Přehled architektury ESA (Woods, a další, 2006) Obr. 9: Koncept služeb v rámci TOGAF (The, 2009) Obr. 10: Srovnání business service a IT Service (Office, 2007) Obr. 11: Kompozice služeb v rámci ITIL (Office, 2007) Obr. 12: Vztah pohledů Engineering, Management a Governance (Autor) Obr. 13: Standardy pro tvorbu služeb v konceptu Service-Oriented (Autor) Obr. 14: Životní cyklus Služeb v rámci ESA (Woods, a další, 2006) Obr. 15: Životní cyklus služeb v rámci ITIL (Office, 2007) Obr. 16: Životní cyklus služeb dle SOA Foundation (Wahli, 2007) Obr. 17: Vazba mezi fázemi životního cyklu služeb a fázemi SOA Governance dle SOA Foundation (Wahli, 2007) Obr. 18: Oblasti zájmu v rámci IT Governance dle metodiky COBIT (IT, 2007) Obr. 19: Upravený vztah pohledů Engineering, Management a Governance (Autor) Obr. 20: Fyzická podoba experimentálního provozního prostředí služeb (Autor) Obr. 21: Implementovaný podnikový proces (Autor) Obr. 22: Vstupní business objekt pro službu GetClientCardsOverview (Autor) Obr. 23: Výstupní business objekt pro službu GetClientCardsOverview (Autor) Obr. 24: Vstupní business objekt pro službu GetClient (Autor) Obr. 25: Výstupní business objekt pro službu GetClient (Autor) Obr. 26: Vstupní business objekt pro službu GetClientCard (Autor) Obr. 27: Výstupní business objekt pro službu GetClientCard (Autor) Obr. 28: Globální referenční architektura experimentu (Autor)

104 Obr. 29: Diagram reprezentující kompozitní business službu a vazby na komponované služby (Autor) Obr. 30: Reprezentace podnikového procesu pomocí jazyka BPEL (Autor) Obr. 31: Diagram reprezentující službu GetClient typu Entity Service a vazby na komponované služby (Autor) Obr. 32: Diagram reprezentující službu GetClient Card typu Task Service a Vazby na komponované služby (Autor) Obr. 33: Diagram reprezentující službu GetCode typu Utility Service (Autor) Obr. 34: Diagram reprezentující službu SAPGetAccount, která zapouzdřuje adaptém pro platformu SAP NetWeaver (Autor) Obr. 35: Pohled na konkrétní kompozice služeb korespondující s referenční architekturou (Autor) Obr. 36: Datový slovník pro doménu Infrastructure (Autor) Obr. 37: Datový slovník pro doménu Product (Autor) Obr. 38: Datový slovník pro doménu Client (Autor) Obr. 39: Business objekty domény Product (Autor) Obr. 40: Business objekty domény Infrastructure (Autor) Obr. 41: Business objekty domény Client (Autor) Obr. 42: Rozhraní služby GetClientCardsOverview (Autor) Obr. 43: Vstupní business objekt služby GetClientCardsOverview (Autor) Obr. 44: Výstupní business objekt služby GetClientCardsOverview (Autor) Obr. 45: Diagram reprezentující službu GetClientCardsOverview (Autor) Obr. 46: Rozhraní služby GetClient (Autor) Obr. 47: Vstupní business objekt služby GetClient (Autor) Obr. 48: Výstupní business objekt služby GetClient (Autor) Obr. 49: Diagram reprezentující službu GetClient (Autor) Obr. 50: Rozhraní služby GetClientCard (Autor) Obr. 51: Vstupní business objekt služby GetClientCard (Autor) Obr. 52: Výstupní business objekt služby GetClientCard (Autor) Obr. 53: Diagram reprezentující službu GetClientCard (Autor) Obr. 54: Rozhraní služby GetCard (Autor) Obr. 55: Vstupní business objekt služby GetCard (Autor) Obr. 56: Výstupní business objekt služby GetCard (Autor)

105 Obr. 57: Diagram reprezentující službu GetCard (Autor) Obr. 58: Rozhraní služby GetCode (Autor) Obr. 59: Vstupní business objekt služby GetCode (Autor) Obr. 60: Výstupní business objekt služby GetCode (Autor) Obr. 61: Diagram reprezentující službu GetCode (Autor) Obr. 62: Rozhraní služby SAPGetClient (Autor) Obr. 63: Vstupní business objekt služby SAPGetClient (Autor) Obr. 64: Výstupní business objekt služby SAPGetClient (Autor) Obr. 65: Diagram reprezentující službu SAPGetClient (Autor) Obr. 66: Rozhraní služby SAPGetAccount (Autor) Obr. 67: Rozhraní služby SAPGetClientAccount (Autor) Obr. 68: Vstupní business objekt služby SAPGetAccount (Autor) Obr. 69: Výstupní business objekt služby SAPGetAccount (Autor) Obr. 70: Vstupní business objekt služby SAPGetClientAccount (Autor) Obr. 71: Výstupní business objekt služby SAPGetClientAccount (Autor) Obr. 72: Diagram reprezentující službu SAPGetAccount (Autor) Obr. 73: Rozhraní služby SAPGetCard (Autor) Obr. 74: Vstupní business objekt služby SAPGetCard (Autor) Obr. 75: Výstupní business objekt služby SAPGetCard (Autor) Obr. 76: Diagram reprezentující službu SAPGetCard (Autor) Obr. 77: Rozhraní služby SAPGetCode (Autor) Obr. 78: Vstupní business objekt služby SAPGetCode (Autor) Obr. 79: Výstupní business objekt služby SAPGetCode (Autor) Obr. 80: Diagram reprezentující službu SAPGetCode (Autor) Obr. 81: Datový model na platformě SAP NetWeaver (Autor)

106 12 SEZNAM TABULEK Tab. 1: Výsledky citační analýzy (Autor) Tab. 2: Terminologický slovník (Autor) Tab. 3: Přehled použitých zkratek (Autor)

107 13 PŘÍLOHY Diplomová práce: Využití systému SAP v kompozici business služeb Kanonický model Rozhraní, business objekty a reprezentační diagramy služeb Služby na platformě SAP NetWeaver 107

108 13.1 KANONICKÝ MODEL Tato příloha obsahuje kanonický datový model, který je využívaný službami na platformách IBM WebSphere Process Server a IBM WebSphere ESB Server. V rámci popisu kanonického datového modelu jsou výstupy aplikace Oxygen, které znázorňují definované datové elementy, a definice business objektů, které jsou v rámci služeb používány DATOVÝ SLOVNÍK Tato příloha obsahuje definici datových elementů používaných v rámci business objektů. Obr. 36: Datový slovník pro doménu Infrastructure (Autor) 108

109 Obr. 37: Datový slovník pro doménu Product (Autor) 109

110 Obr. 38: Datový slovník pro doménu Client (Autor) 110

111 BUSINESS OBJEKTY Tato příloha obsahuje definici business objektů používaných v rámci služeb na platformách IBM WebSphere Process Server a IBM WebSphere ESB Server. Obr. 39: Business objekty domény Product (Autor) 111

112 Obr. 40: Business objekty domény Infrastructure (Autor) 112

113 Obr. 41: Business objekty domény Client (Autor) 113

114 13.2 ROZHRANÍ, BUSINESS OBJEKTY A REPREZENTAČNÍ DIAGRAMY SLUŽEB Tato příloha obsahuje popisy služeb, které jsou provozovány na platformách IBM WebSphere Process Server a IBM WebSphere ESB Server. Součástmi popisů jsou výstupy aplikací IBM WebSphere Integration Developer a Oxygen, které znázroňují rozhraní služeb, vstupní a výstupní business objekty a diagramy s kompozicí služeb GETCLIENTCARDSOVERVIEW Tato příloha obsahuje popis služby GetClientCardsOverview, její rozhraní, vstupní a výstupní business objekty a diagram, který znázorňuje kompozici služby. Obr. 42: Rozhraní služby GetClientCardsOverview (Autor) Obr. 43: Vstupní business objekt služby GetClientCardsOverview (Autor) 114

115 Obr. 44: Výstupní business objekt služby GetClientCardsOverview (Autor) Obr. 45: Diagram reprezentující službu GetClientCardsOverview (Autor) GETCLIENT Tato příloha obsahuje popis služby GetClient, její rozhraní, vstupní a výstupní business objekty a diagram, který znázorňuje kompozici služby. Obr. 46: Rozhraní služby GetClient (Autor) 115

116 Obr. 47: Vstupní business objekt služby GetClient (Autor) Obr. 48: Výstupní business objekt služby GetClient (Autor) 116

117 Obr. 49: Diagram reprezentující službu GetClient (Autor) GETCLIENTCARD Tato příloha obsahuje popis služby GetClientCard, její rozhraní, vstupní a výstupní business objekty a diagram, který znázorňuje kompozici služby. Obr. 50: Rozhraní služby GetClientCard (Autor) 117

118 Obr. 51: Vstupní business objekt služby GetClientCard (Autor) Obr. 52: Výstupní business objekt služby GetClientCard (Autor) 118

119 Obr. 53: Diagram reprezentující službu GetClientCard (Autor) GETCARD Tato příloha obsahuje popis služby GetCard, její rozhraní, vstupní a výstupní business objekty a diagram, který znázorňuje kompozici služby. Obr. 54: Rozhraní služby GetCard (Autor) Obr. 55: Vstupní business objekt služby GetCard (Autor) 119

120 Obr. 56: Výstupní business objekt služby GetCard (Autor) Obr. 57: Diagram reprezentující službu GetCard (Autor) GETCODE Tato příloha obsahuje popis služby GetCode, její rozhraní, vstupní a výstupní business objekty a diagram, který znázorňuje kompozici služby. Obr. 58: Rozhraní služby GetCode (Autor) 120

121 Obr. 59: Vstupní business objekt služby GetCode (Autor) Obr. 60: Výstupní business objekt služby GetCode (Autor) Obr. 61: Diagram reprezentující službu GetCode (Autor) 121

122 SAPGETCLIENT Tato příloha obsahuje popis služby SAPGetClient, její rozhraní, vstupní a výstupní business objekty a diagram, který znázorňuje kompozici služby. Obr. 62: Rozhraní služby SAPGetClient (Autor) Obr. 63: Vstupní business objekt služby SAPGetClient (Autor) 122

123 Obr. 64: Výstupní business objekt služby SAPGetClient (Autor) Obr. 65: Diagram reprezentující službu SAPGetClient (Autor) SAPGETACCOUNT A SAPGETCLIENTACCOUNT Tato příloha obsahuje popis služeb SAPGetAccount a SAPGetClientAccount, jejich rozhraní, vstupní a výstupní business objekty a diagram, který znázorňuje kompozici služby. Obr. 66: Rozhraní služby SAPGetAccount (Autor) 123

124 Obr. 67: Rozhraní služby SAPGetClientAccount (Autor) Obr. 68: Vstupní business objekt služby SAPGetAccount (Autor) Obr. 69: Výstupní business objekt služby SAPGetAccount (Autor) 124

125 Obr. 70: Vstupní business objekt služby SAPGetClientAccount (Autor) Obr. 71: Výstupní business objekt služby SAPGetClientAccount (Autor) Obr. 72: Diagram reprezentující službu SAPGetAccount (Autor) 125

126 SAPGETCARD Tato příloha obsahuje popis služby SAPGetCard, její rozhraní, vstupní a výstupní business objekty a diagram, který znázorňuje kompozici služby. Obr. 73: Rozhraní služby SAPGetCard (Autor) Obr. 74: Vstupní business objekt služby SAPGetCard (Autor) Obr. 75: Výstupní business objekt služby SAPGetCard (Autor) 126

127 Obr. 76: Diagram reprezentující službu SAPGetCard (Autor) SAPGETCODE Tato příloha obsahuje popis služby SAPGetCode, její rozhraní, vstupní a výstupní business objekty a diagram, který znázorňuje kompozici služby. Obr. 77: Rozhraní služby SAPGetCode (Autor) Obr. 78: Vstupní business objekt služby SAPGetCode (Autor) 127

128 Obr. 79: Výstupní business objekt služby SAPGetCode (Autor) Obr. 80: Diagram reprezentující službu SAPGetCode (Autor) 128

129 13.3 SLUŽBY NA PLATFORMĚ SAP NETWEAVER Tato příloha obsahuje výstup aplikace MS Visio, která znázorňuje datový model využívaný službami na platformě SAP NetWeaver, a popis funkcionality jednotlivých služeb, které platforma SAP NetWeaver poskytuje DATOVÝ MODEL NA PLATFORMĚ SAP NETWEAVER Obr. 81: Datový model na platformě SAP NetWeaver (Autor) SLUŽBA Z_GET_CLIENT Služba Z_GET_CLIENT přijímá na vstupu jednu ze tří možných hodnot, klientské číslo, rodné číslo nebo IČO. Služba pro hledání využívá tabulky: ZCLIENT, ZCOMPAN, ZENTREP a ZPERSON a eviduje tři různé typy klientů: fyzická osoba, podnikatel, společnost. Podle kombinace vstupních hodnot se pak služba dotáže buď přímo do tabulky určené pro konkrétní typ osoby (například rodné číslo znamená fyzickou osobu a tabulku ZPERSON), nebo se na typ osoby dotáže přímo do tabulky ZCLIENT, nebo postupně prohledá tabulky ZENTREP a ZCOMPAN. Služba pak vrací, pokud to typ osoby dovoluje, typ osoby, jméno, příjmení, DIČ, klientské číslo, rodné číslo a IČO SLUŽBA Z_GET_CARD Služba Z_GET_CARD přijímá seznam čísel platebních karet. Služba pro hledání využívá tabulku ZCARD, kde eviduje všechny aktivní i neaktivní karty. Podle čísel platebních karet 129