Využití technologie Oracle Fusion v integraci IS

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Využití technologie Oracle Fusion v integraci IS Diplomová práce

Autor:

Bc. Radek Vojtíšek Informační technologie a management, ITMK

Vedoucí práce:

Praha

Ing. Michal Valenta, Ph.D.

Duben, 2012

Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

............................... V Praze dne

Bc. Radek Vojtíšek

Poděkování

Děkuji tímto vedoucímu práce, panu Ing. Michalu Valentovi, Ph.D., za podnětné rady, připomínky a doporučení, které mi věnoval při metodickém vedení a které mi pomohly při zpracování této diplomové práce.

Anotace práce Tato práce je zaměřena na vyuţití technologie Oracle Fusion v integračním oddělení telekomunikační společnosti. V této práci se stěţejně věnuji produktům sady Oracle Fusion Middleware, které jsou hlavním zaměřením integračního oddělení. První část je zaměřena všeobecně na middleware jako pojem a podává přehled o jeho jednotlivých produktech Oracle Fusion Middleware. Dále pak porovnávám přínosy jednotlivých produktů. Druhá kapitola popisuje základní principy servisně orientované architektury SOA. Praktická část pak popisuje proces návrhu integrační vrstvy s podporou produktů Oracle Fusion Middleware. V závěru vyhodnotím dosaţení stanovených cílů této práce a naznačím moţné budoucí trendy. Klíčová slova BPM, B2B, ESB, JRockit, Oracle Fusion, Midlleware, SOA, weblogic

Annotation This thesis is focused on the use of Oracle Fusion in the integration department of telecommunications. In this work devoted to the flagship products of the Oracle Fusion Middleware, which are the main focuses of the integration department. The first part is sighted generally, on middleware as a concept, gives an overview of its various products, Oracle Fusion Middleware. Furthermore, it compares the benefits of product. In the second chapter there is described the general principles of service-oriented architecture SOA. The practical part describes the design process integration layer with the support of the products of Oracle Fusion Middleware. As a conclusion I made an evaluation of the established objective of this thesis and i hint at possible future trends.

Keywords BPM, B2B, ESB, JRockit, Oracle Fusion, Midlleware, SOA, weblogic

OBSAH: ÚVOD .......................................................................................................................................................... 7 ZVOLENÉ METODY ZPRACOVÁNÍ.................................................................................................... 9 1.

PRODUKTY ORACLE FUSION.................................................................................................. 11

1.1.

Middleware ....................................................................................................... 12

1.1.1. 1.2.

Komponenty Oracle Fusion Middleware ......................................................... 18

1.2.1.

Vývojové prostředí a frameworky .......................................................... 19

1.2.2.

Application Grid ..................................................................................... 19

1.2.3.

Data Integration ...................................................................................... 21

1.2.4.

Identity Management .............................................................................. 22

1.2.5.

Service Oriented Architecture................................................................. 26

1.2.5.1.

2.

Governance SOA................................................................................ 27

1.2.6.

Content Management .............................................................................. 28

1.2.7.

Business Intelligence (BI) ....................................................................... 30

1.2.8.

User interaction ....................................................................................... 32

PRINCIPY A ARCHITEKTURA PRO POUŽITÍ MIDDLEWARE ........................................ 34

2.1.

3.

Middleware v podání Oracle ................................................................... 16

Servisně orientovaná architektura .................................................................... 35

2.1.1.

Principy SOA .......................................................................................... 35

2.1.2.

Pravidla komunikace ............................................................................... 39

2.1.3.

Kompozice sluţeb ................................................................................... 41

2.1.4.

Enterprise Service Bus ............................................................................ 42

MODELOVÝ PŘÍKLAD - OBJEDNÁVKOVÝ PROCES ......................................................... 44

3.1.

Poţadavky a cíle ............................................................................................... 44

3.2.

Analýza poţadavků .......................................................................................... 44

3.3.

Architektura a komponenty .............................................................................. 45

3.3.1.

Klíčové systémy procesu ........................................................................ 45

3.3.2.

Návrh integrační infrastruktury............................................................... 47

3.3.3.

Konceptuální model integrační vrstvy .................................................... 51

3.4.

Implementace ................................................................................................... 55

3.4.1.

OSB - Oracle service bus ........................................................................ 55

3.4.1.1.

Vytvoření implementačních konvencí ............................................... 58

3.4.1.2.

Základní struktura proxy a business servis ........................................ 60

-5-

3.4.1.3.

Dodatková funkcionalita a artefakty .................................................. 63

3.4.2.

B2B brána ............................................................................................... 66

3.4.3.

Repository ............................................................................................... 67

3.4.4.

Zhodnocení a doporučení ........................................................................ 70

ZÁVĚR ...................................................................................................................................................... 73 SEZNAM POUŽITÉ LITERATURY A ZDROJŮ ............................................................................... 74 SEZNAM POUŽITÝCH ZKRATEK ..................................................................................................... 76 SEZNAM OBRÁZKŮ .............................................................................................................................. 78 SEZNAM TABULEK .............................................................................................................................. 79

-6-

Úvod V dnešním moderním světě jiţ prakticky neexistují společnosti, které by pro svoji výrobu či poskytování sluţeb nevyuţívaly nějakou výpočetní techniku. Rozvoj informačních technologií také svým uţivatelům přináší nové prostředky pro podporu výroby ať jiţ sníţením provozních nákladů, otevíráním nových příleţitostí pro společnost nebo i zkrácením času potřebného pro uvedení nového výrobku na trh téţ označované termínem TTM (time to market). Na trhu je nyní moţné sehnat aplikace pro všechny moţné odvětví s různorodou funkcionalitou. To však za cenu často velmi úzké specializace těchto aplikací, jejichţ povaha je spíše v poskytování autonomní funkcionality. Tímto procesem vzniká velice heterogenní prostředí. Nicméně v posledních letech pokročila poptávka od zadavatelů v podobě obchodních jednotek po více komplexní funkcionalitě, která odpovídá jejich business procesům a zde se jako velice nevýhodné ukazuje právě toto heterogenní prostředí. Priorita uţivatele jiţ není získávat jednotlivé informace z různých aplikací běţících na odlišných platformách a sám si je zpracovávat, ale potřebuje získat rychle komplexní důvěryhodnou informaci pro podporu při svých obchodních rozhodnutích a činnostech. Mnoho společností vsadilo na myšlenku v podobě „IT jako konkurenční výhoda“. Oddělení informačních technologií byla tedy postavena před otázku jak takové různorodé prostředky propojit, aby došlo ke sníţení redundance dat a funkcionalit tak, aby maximálně v moţné míře podpořila cíle společnosti. Tak aby nově vzniklý celek přinesl organizaci novou přidanou hodnotu v podobě sníţených provozních nákladů či vytvoření nových obchodních příleţitostí pro společnost. Z pohledu uţivatele je tedy cílovým stavem plně integrovaný systém, který naplňuje potřeby a cíle všech stupňů řízení organizace [5]. Zcela logicky se proto objevuje v řešeních integrační vrstva, která propojuje a spojuje různorodé zdroje podnikové informatiky do vyššího celku, přičemţ komponenty dohromady spolupracují a sdílejí data tak, ţe se taková kombinace komponent jeví uţivateli jako jednotný systém.

Nástroj, který

zabezpečuje tyto funkcionality, je označen jako “middleware”. Dalšímu urychlení ve světě integrace systémů přispěl příchod značkovacího jazyka XML a následně příchod webových sluţeb a servisně orientované architektury (SOA). Přínosem SOA je těsnější spolupráce IT oddělní s obchodními útvary v podobě provázanosti business procesů přímo na technologie IT.

-7-

Cílem mé práce je vyuţití komponent Oracle Fusion pro integraci podnikových aplikací, a proto jsem se dále v práci zaměřil především na sadu produktů a komponent Oracle Fusion Middleware. Oracle Fusion Middleware je vlastně takový motor při interakcích Oracle Fusion aplikací. V úvodní části práce se zaměřuji na vysvětlení pojmu middleware a rozborem jednotlivých komponent celé sady Oracle Fusion Middleware. Druhá kapitola je zaměřena na základní principy a vysvětlení pouţité architektury v rámci middleware. Není tajemstvím, ţe jádro komunikace middleware vyuţívá principy servisně orientované architektury (SOA), kterou také rozebírám v druhé kapitole. Následně na modelovém příkladu ověřuji základní principy a moţnosti vyuţití tohoto softwarového balíku v oddělení integrace informačních systémů telekomunikačního operátora. V závěrečné části práce jsem provedl zhodnocení přínosu tohoto balíku.

-8-

Zvolené metody zpracování V rámci diplomové práce a především v praktické části jsem pouţil modelování pomocí jazyka UML. Při návrhu řešení jsem vycházel z principů servisně orientované architektury, které byly vysvětleny v teoretické části práce. Pro rozpad obchodních poţadavků na jednotlivé systémy v integrační vrstvě bylo vyuţito principů dekompozice podle nabízených funkcionalit jednotlivých produktů sady Oracle Fusion Middleware. Při samotném identifikování a modelování sluţeb bylo pouţito agilní strategie. Obrázek č. 1: Kroky agilní strategie

Zdroj: ERL, T. Servisně orientovaná architektura SOA. Brno: Computer Press, 2009. 654s. ISBN 978-80-251-1886-3

Tato strategie vyuţívá lepší stránky ze strategie shora-dolů a zdola-nahoru. Je zde podporována neustálá analýza, ale přitom je moţné okamţité zavedení sluţeb. Přestoţe tato strategie splňuje krátkodobé i dlouhodobé potřeby je výsledkem zavedení této strategie zvýšené úsilí spojené se zavedením kaţdé sluţby. To, ţe sluţby mohou být revidovány a

-9-

následně znovu navrţeny a zavedeny do produkčního prostředí znamená úměrné mnoţství práce s údrţbou a zajištěním kompatibility všech podporovaných verzí sluţeb [4]. Jelikoţ v rámci mého praktického příkladu nezačínám úplně od začátku a je tedy nutné přihlédnou k jiţ existujícím systémům a jejich sluţbám.

- 10 -

1. Produkty Oracle Fusion Oracle Fusion nabízí prostředky a komponenty pro podporu celého spektra obchodních a podnikových aktivit současných společností. Tato sada poskytuje řadu podnikových komponent označovaných jako Oracle Fusion Applications, které zastřešují následující oblasti podnikových aktivit: Řízení vztahů se zákazníky - řízení vztahů se zákazníky také známe jako CRM (Customer relationship management) zavádí nový standard pro řízení výkonu prodeje [14]. Pro tuto aktivitu je stěţejní produkt Siebel CRM. Financování - poskytuje všechny základní funkce, které jsou očekávány od finančního systému. Jako jsou například řešení pohledávek, fakturace, platby, účty hlavní knihy a tak dále. Komponenta poskytující tyto činnosti se jmenuje Oracle Fusion Financials. Vedení, riziko a soulad s předpisy – tato oblast je zaměřena na správu rizik, zjednodušení souladu s předpisy a celkovou legislativu kolem této problematiky [14]. Komponenta zastřešující tyto aktivity se jmenuje Oracle Fusion Governance, Risk, and Compliance (GRC). Řízení lidských zdrojů – je zaměřeno na podporu procesů jednotek lidských zdrojů. Komponenta zastřešující tyto aktivity je Oracle Fusion Human Capital Management. Procurement – poskytuje podporu komplexních procesů pro činnosti nákupů a správu dodavatelů [14]. Produkt zastřešující tyto činnosti je Oracle Fusion Procurement. Řízení portfolia projektů (PPM) – poskytuje funkcionalitu pro řízení a správu projektů. Řízení zásobovacího řetězce (SCM) – tato oblast je zaměřena na správu dodavatelského řetězce coţ znamená například vyřizování objednávek, logistika, řízení skladu atd. Komponenta zajištující tyto aktivity se nazývá Oracle Fusion Supply Chain Management. Oracle Fusion Applications je velmi komplexní sada produktů, která pro svoje funkcionality vyuţívá robustní střední vrstvu (tzv. middleware) Oracle Fusion Middleware. Oracle Fusion Middleware je komplexní sada softwarových produktů střední vrstvy, vyuţívající principy architektury orientované na sluţby (SOA). Tato řada produktů střední vrstvy má pomoci společnostem dosahovat větší agilnosti, přijímat informovanější

- 11 -

podnikatelská rozhodnutí a snáz integrovat data a procesy napříč různými informačními systémy v heterogenních počítačových prostředích. Oracle Fusion Middleware se dále snaţí zaměřit na komplexní podporu celého ţivotního cyklu aplikací orientovaných na sluţby a snaţí se přinést interoperabilitu s existující heterogenní informační infrastrukturou podniků. Middleware je tvořen modulárními komponentami, které běţí na široké řadě oblíbených platforem a spolupracují s podnikovými aplikacemi i jiných výrobců softwaru např. Microsoft, SAP či IBM. Mnoţina spolupracujících aplikací není omezená pouze komerčními produkty, ale podpora je i open source technologií jako je Spring Framework, JUnit, CVS, Apache MyFaces a další. Je to dáno tím, ţe jádro midlleware je postaveno na otevřené technologii java (J2EE).

1.1. Middleware Dříve neţ se zaměřím na jednotlivé komponenty produktové řady Oracle Fusion Middleware, pokusím se objasnit, co se skrývá pod pojmem middleware. Zastavím se u základního rozdělení funkcionalit middlewaru a vysvětlím základní pojmy. Termín “middleware” je pro mnohé lidi nejednoznačný. Definic existuje velice mnoho, jako výstiţné jsem vybral tyto definice: “Middleware je programové vybavení, které je umístěno mezi operačním systémem a aplikacemi a které nabízí aplikacím všestranně použitelnou množinu služeb“[1]. A následující definice je podle společnosti Gartner: „Služby vytvářejí provozní systémové prostředí, které umožňuje procesům, programům a aplikacím vzájemnou interakci v distribuovaném systému prostřednictvím sítě“[12]. Middleware prostředky lze podle funkcionality rozdělit na základní middleware, integrační middleware a prostředky aplikační integrace. Kaţdý z prostředků vedle konkrétní funkcionality nabízí i sluţby bezpečnosti, vývoje a správy [5]. Názorné rozloţení je vidět z obrázku, který publikovala firma Gartner.

- 12 -

Obrázek č. 2: Taxonomie funkcionality Middleware

Zdroj: Lheureux, B., aj. Who's Who in Middleware, 1Q04 [online]. 2004 [cit. 2011-11-22], Dostupný z WWW:

Funkcionalita základního middleware Z obrázku je patrné rozdělení funkcionality základního middleware do následujících dalších kategorií: komunikační

middleware

(Communication

Middleware)

–

umoţňuje

vzájemnou komunikaci programů, ať se jedná o komunikaci mezi různými aplikacemi či v rámci jedné aplikace. Tato vrstva poskytuje protokol pro přenos dat a zpráv mezi programy a programovým rozhraním, jehoţ prostřednictvím program přistupuje ke komunikačním sluţbám. Je zaměřena na podporu asynchronní a synchronní komunikace [5]. Blíţe se komunikačními vzory zabývám v kapitole principy a architektura middleware.

Tato vrstva je

podporována různými technologiemi, zabezpečující jak synchronní, tak i asynchronní komunikaci. Jako příklady lze uvést pro synchronní komunikaci technologie: RPC (Remote Procedure Call), RMI, CORBA, DCOM a v současné době mohutně vyuţívají webové sluţby. Asynchronní komunikaci (neblokovaná komunikace – nečeká na odpověď) zde představují prostředky řízení fronty zpráv (MOM – message-oriented middleware) zaloţené například na protokolu JMS. prostředky řízení přístupu k datům (Data Management Middleware) – zajišťuje pomocnou funkcionalitu programům pro přístup k datům uloţených - 13 -

v různých datových zdrojích jako je např. čtení či zápis do vzdálených databází či souborů. Do této oblasti patří různé knihovny a API rozhraní jako je například knihovna ODBC (Open Database Connectivity) a nebo JDBC (Java Database Connectivity). platformový middleware (Platform middleware) - poskytuje vhodné provozní prostředí s mnoţinou obecně pouţitelných sluţeb. Zjednodušeně řečeno, poskytuje runtime prostředí (kontejner) a sluţby pro běh aplikací (např. správa paměti, operační systém, procesy a vlákna, načítání programů z disku dle potřeby, spuštění a zastavování programů, vyvaţování zátěţe (loadbalancing), odolnost proti chybám, zabezpečení přístupu, monitoring, distribuované zpracování transakcí atd.). Představitelé této vrstvy jsou aplikační servery (např. Oracle Weblogic Server). Funkcionalita integračního middleware Integrační middleware rozšiřuje funkcionalitu základního middleware. Nabízí funkcionalitu, která pomáhá sladit technické a aplikační odlišnosti v situacích, kdy spolu mají komunikovat či mají být vzájemně integrovány v zásadě nezávislé aplikační systémy [5]. Prostředky integračního middleware obvykle vyuţívají funkcionalitu základního middlewaru. Integrační middleware zajišťuje následující oblasti: adaptery – adaptér je kombinace návrhového nástroje a “běhového” prostředí umoţňující implementovat vhodné rozhraní pro komunikaci dvou prvků. Typicky zapouzdřuje původní rozhraní do nového, vyhovujícího rozhraní [5]. Adaptéry mají spíše charakter technických adapterů, kam se např. řadí: adaptery pro komunikaci do databáze, komunikační adaptery pro MOM (messageoriented middleware) a Web services platformy, ORBs adaptery pro CORBA komunikaci atd. De facto je orientovaný na zapouzdření a vytvoření rozhraní mezi systémovými komponentami. transformace – jedná se o prostředky, které zajišťují transformace, tj. poskytují syntaktickou a sémantickou konverzi dat (dokumenty, zprávy), které jsou přenášeny mezi aplikacemi. Syntaktická konverze představuje např. převod kódování, datových typů atd. Sémantická konverze vyţaduje jiţ detailnější znalost aplikací a procesů a přináší obohacení či redukce původního obsahu. - 14 -

inteligentní směrování – prostředky inteligentního směrování umoţňují směrování zpráv mezi aplikacemi na základě obsahu a při pouţití definovaných pravidel směrovat tok k vhodnému příjemci. řízení byznys procesů (BPM – Business Process Management) – Business Process Management nabízí prostředky pro řízení, optimalizaci, automatizaci a transparentnost firemních i zákaznických procesů. Lze říci, ţe pokrývá aktivity spojené s analýzou a definicí procesu, jeho vlastním prováděním, monitorováním a administrováním [5]. řízení procesů na základě pravidel (BRE – Business Rule Engine) – nabízí prostředky pro řízení podnikových prostředků v tom, ţe jsou schopny provést rekonfiguraci procesů (tj. změnit jeho chování) na základě definované mnoţiny pravidel a politik [5]. správu a dohled nad událostí (BEM - Business Event Management) – tato oblast poskytuje prostředky, které jsou zaměřené na monitorování aktivit podnikových procesů. Jedná se o prostředky zachytávající a shromaţďující informace o vzniklých událostech. V reálném světě jsou těmito představiteli agenti, kteří zachytávají a monitorují důleţité aktivity, které následně můţou být vyhodnoceny v BAM (business activity monitoring).

Funkcionalita middleware pro aplikační integraci Tuto poslední kategorii netvoří čistě middlewarové prostředky, ale prostředky vnitřně integrující middleware s aplikační logikou zaměřenou na podnikové procesy [5]. Jedná se především o tyto kategorie: aplikační adaptery - rozhraní aplikačních adapterů zabalují celé aplikační moduly např. Oracle Financials, SAP Procurement, RosettaNet, S.W.I.F.T. atd [12]. Jde o zapouzdření původního (nevyhovujícího) rozhraní aplikace nebo aplikačního balíku.

- 15 -

integrované “balíky” aplikací – tato oblast představuje specificky sestavované aplikační balíky, které zapouzdřují řešení nějakého konkrétního procesu, který vznikl na základě integrace více aplikací (PIP Packard Integrating Process). business activity monitoring (BAM) - mechanismus BAM umoţňuje snadno sledovat průběh obchodních procesů dle nasbíraných dat. Principiálně poskytuje v reálném čase přístup ke kritickým indikátorům výkonnosti byznys procesů, včetně moţností v reálném čase ovlivňovat technologie tak, aby bylo moţné zlepšit rychlost a efektivitu stěţejních obchodních operací [12]. Prostředky jsou často propojeny s business intelligence (BI) systémy.

1.1.1. Middleware v podání Oracle Na následujícím obrázku je naznačen princip z jakého vycházela společnost Oracle při tvorbě middlewaru. Obrázek č. 3: Architektura middleware

Zdroj: Oracle Fusion Middleware Concepts Guide [online]. 2010 [cit. 2011-10-11], Dostupný z WWW:

Na obrázku je vidět obecný přehled komponent Middleware. Na levé straně je naznačen přístup klientů na middleware přes vrstvu klientských rozhraní. Pod pojmem klient zde rozumíme osobní počítače, chytré telefony atd. V pravé části obrázku je zobrazen doménový

- 16 -

interface slouţící pro komunikaci s doménovými backend systémy, kde je moţné si představit např. SAP, CRM atd. Ve spodní části se nachází rozhraní sluţeb. Oracle Fusion Middleware se snaţí usnadnit vývoj aplikací, poskytnout všeobecnou programovou abstrakci, která by měla zakrýt různorodost aplikací, rozloţení hardwaru a operačních systémů tím, ţe zakrývá low-level programovací detaily. Vyznačuje se následujícími rysy: skrývá různorodost informačních systémů. skrývá distribuovanou povahu aplikace. poskytuje jednotné vysoko úrovňové rozhraní pro integrační/aplikační vývojáře tak, aby aplikace mohla vyuţívat funkcionalitu poskytující middleware. zabezpečuje mnoţinu sluţeb, které poskytují různorodou funkcionalitu, kde je snaha pomocí reuse patternu (znovu pouţití) poskytovat jiţ jednou naprogramovanou funkcionalitu. A dále usnadnit spolupráci mezi aplikacemi.

- 17 -

1.2. Komponenty Oracle Fusion Middleware Oracle Fusion Middleware nabízí řešení a podporu komplexních distribuovaných obchodních aplikací. Celé řešení je zaloţené na platformě Java Enterprise Edition a zahrnuje webové servery, aplikační servery, business inteligence, systémy pro správu obsahu, vývojářské nástroje. Jednoduše řečeno Oracle Fusion Middleware nabízí kompletní podporu pro vývoj, nasazení a správu. Celá sada se dá rozdělit na několik různých kategorii dle druhů řešených problémů. Na následujícím obrázku je zachyceno toto rozloţení. Obrázek č. 4: Produkty Fusion Middleware

Zdroj: KONDURI, G., LEE, S., SHAFFI, R. Oracle Fusion Middleware 11g Architecture and Management. Oracle Press 2011

- 18 -

1.2.1. Vývojové prostředí a frameworky Podpora moţnosti vývoje nových funkcionalit je velice důleţitá, proto i zde jsou dodávány vývojové nástroje. Základ tvoří dvě integrována vývojářské prostředí (IDE): Oracle JDeveloper a Oracle Enterprise Pack for Eclipse1 a dále pak Oracle Application Development Framework a Oracle TopLink. JDeveloper a Application Development Framework (ADF) - JDeveloper s technologií Oracle Application Development Framework (ADF) zjednodušuje vývoj aplikací vývojářům na všech odborných úrovních a umoţňuje vytvářet aplikace J2EE a webové sluţby optimalizované pro nasazení v podnikových výpočetních sítích. Technologie Oracle ADF dále optimalizuje vývojový proces tím, ţe poskytuje vývojářům zaujmout přístup architektury orientované na sluţby (SOA) a sestavovat účinnější aplikace ze sady sdílených obchodních sluţeb. Díky tomu se vývojáři mohou soustředit na definování vyšších úrovní obchodní logiky a na optimalizaci procesního toku, místo aby ručně psali základní aplikační kód [10]. Oracle Enterprise Pack for Eclipse (OEPE) - je sada zdarma certifikovaných modulů pro platformu Eclipse (IDE). Historie OEPE sahá k firmě BEA Systems, která byla v roce 2008 koupena firmou Oracle.2 OEPE poskytuje vývojářům Oracle Fusion Middleware velice podobnou funkcionalitu jako prostředí JDeveloper, nicméně velikou předností je obrovská komunita pouţívajících vývojářů a veliké mnoţství pluginů (zásuvných modulů) s obrovskou škálou funkcionality.

1.2.2. Application Grid Tato kategorie je také označována jako middlewarové infrastruktura, která zabezpečuje nízko úrovňovou funkcionalitu pro běh podnikových aplikaci. Pro náročné podnikové systémy tato kategorie poskytuje výhody sjednocení v rámci hardware a software do clusterů či gridů. Tyto principy zajišťují snadnou rozšiřitelnost, kdy stačí v případě nedostatečného výkonu přidat další server, čímţ získáme další prostředek pro rozloţení zátěţe. Zároveň je infrastruktura více odolná proti výpadkům, neboť v případě pádu jednoho ze serverů například příčinou špatné komponenty, převezmou jeho funkci ostatní servery clusteru. A koncový zákazník tudíţ nemusí o problému vůbec vědět, jelikoţ se mu v nejhorším případě zhorší odezvy od 1

Eclipse je open source vývojová platforma.

2

Firma BEA pouţívala vývojové prostředí Eclipse jako primární. Jelikoţ produkty společnosti BEA tvoří významnou roli v rámci Fusion Middleware musela zůstat zachována podpora nemalé skupiny vývojářů.

- 19 -

databáze z důvodu dotazování se vzdálenějšího a více vytíţeného serveru. Na následujícím obrázku jsou zobrazeny jednotlivé produkty této kategorie: Obrázek č. 5: Vrstvy Application Gridu

Zdroj: Oracle Fusion Middleware Components [online]. 2010 [cit. 2011-10-12], Dostupný z WWW:

JRockit/Hotspot – tyto dva produkty představují virtuální stroje Javy (JVM - Java Virtual Machine). JVM vytváří abstraktní (či virtuální) procesor zcela nezávislý na konkrétní architektuře počítače, v němţ jsou spouštěny instrukce uloţené v bajtkódu jednotlivých tříd Javy [22]. Produkt JRockit byl získán do portfolia Oracle produktů koupí společnosti BEA a produkt Hotspot zase koupí společnosti SUN. WebLogic Server – jedná se o robustní aplikační server, který poskytuje moţnosti pro vývoj, nasazení a provoz aplikací v jazyce Java (platforma Enterprise Edition, Java EE). Server implementuje všechny API popsaných standardem JEE, jako Java Message Service (JMS), Enterprise Java Beans EJB, Remote Method Invokation RMI, Java Database Connectivity (JDBC), Resource Adapters / JEE Connectors atd. Nad rámec JEE je moţné v aplikacích dále vyuţít mnoho dalších vlastností. Tuxedo - Tuxedo je strategickým produktem pro zpracování distribuovaných transakcí v rámci Oracle Fusion Middleware. Jedná se aplikační server, který je určen pro kritické aplikace v jazycích C/C++ a COBOL [21].

- 20 -

Coherence - umoţňuje významně zrychlit přístup k často pouţívaným datům a tím i celkovou odezvu aplikace. Jedná se o distribuovaný datový grid, kde jsou data uchovávána přímo v paměti jednotlivých serverů a jsou tak velice rychle dostupná ke zpracování. Datové objekty jsou automaticky a transparentně rozkládány mezi jednotlivé servery, čímţ je zajištěna vysoká dostupnost celého řešení. Vícenásobné uloţení jednotlivých objektů na různých serverech zajišťuje zachování dat i v případě výpadku serveru. Řešení s Oracle Coherence je lineárně škálovatelné, počty serverů v datovém gridu lze dynamicky měnit bez nutnosti zásahu do konfigurace. Coherence lze pouţít jako cache na střední vrstvě, ale také v některých případech i jako samostatný mechanismus pro správu dat. Distribuovaná architektura Coherence umoţňuje efektivně provádět analytické výpočty nad uloţenými daty [18]. Oracle Enterprise Manager - správa gridu se provádí pomocí uţivatelského rozhraní Oracle Enterprise Manager, které umoţňuje spravovat veškeré servery jako jeden celek a jednoduše přidávat a odebírat jednotlivá zařízení mezi která bude rozkládána zátěţ.

1.2.3. Data Integration Data Integration je otevřené a integrované řešení pro provozní a analytická prostředí. Spojuje všechny prvky integrace dat, jako jsou transformace dat, pohyb velkého mnoţství dat v reálném čase, kvalita dat, synchronizace dat, správa dat a datové sluţby tak, aby byla zajištěna včasnost, přesnost a konzistentnost informací v heterogenních systémech. Skládá se z následujících aplikací: Oracle Data Integrator - je platforma pro různorodé datové integrace v heterogenním prostředí, mezi které patří: migrace a replikace dat mezi databázemi či aplikacemi, datové pumpy pro Datové sklady, synchronizační přenosy pro Master Data Management řešení, Datová kvalita anebo Datové a Transformační sluţby v rámci Servisně Orientované Architektury. ODI je postaven na ELT Architektuře – Extrakt dat ze zdroje, Load (nahrání) do cíle a nakonec Transformace v cíli. Díky této architektuře ODI eliminuje zbytečné přenosy dat po síti a pro samotné zpracování dat nepotřebuje ţádný dedikovaný hardware, ale vyuţívá jedinečnou sílu samotných databázových systémů a jejich hardware [13]. Oracle GoldenGate - je jedno řešení, které lze pouţít pro různé scénáře nasazení s hlavními poţadavky na přenos transakcí v reálném čase s velmi nízkou latencí při neomezené vzdálenosti mezi zdrojem a cílem, minimálním zatíţením zdrojových systémů při extrakci dat, - 21 -

dodrţení transakční integrity při aplikování na cíl a odolnosti proti výpadku a poruchám systémů nebo sítě. Oracle Data Profiling & Oracle Data Quality – jedná se o dva produkty, které rozšiřují funkcionalitu Oracle Data Integrátorem a jsou s ním plně integrované. Oracle Data Profiling je nástroj na zkoumání dat a monitorování jejich kvality. Umoţňuje podnikovým uţivatelům hodnotit kvalitu svých dat prostřednictvím metriky, objevovat nebo odvozovat pravidla na základě těchto dat a monitorovat stanovené metriky o kvalitě údajů[20]. Oracle Data Quality for Data Integrator je špičkovou platformou pro kvalitu údajů, která pokrývá i ty nejsloţitější potřeby týkající se kvality údajů. Její výkonný mechanismus zaloţený na pravidlech a její robustní a škálovatelná architektura dělá z čištění dat jeden z hlavních prvků strategie integrace dat podniku [20].

1.2.4. Identity Management Fusion Middleware produkty v kategorii Identity Management poskytují komplexní sadu sluţeb, které umoţňují společnostem zavést a spravovat zabezpečení jejich podnikových aplikací. Jedná se o následující funkcionality: správa uţivatelských rolí, poskytování uţivatelských účtů, jednotného přihlášení SSO (Single Sign On), řízení přístupů k webovým aplikacím či webovým sluţbám, ověřování a administrace identit, detekce fraudů3, řízení bezpečnostních rizik a v neposlední řade provádění analýz, reportů a auditů. Oracle Identity Management se de facto stal bezpečnostní infrastrukturou Oracle Fusion Applications. Základním konceptem Oracle Identity Management je Service-Oriented Security (SOS) [17]. SOS poskytuje sadu bezpečnostních sluţeb pro komponenty Fusion Middleware, jak je ukázáno na následujícím obrázku:

3

Pojmem Fraud označujeme aktivity tykající se podvodů a různých druhů zneuţití.

- 22 -

Obrázek č. 6: Service Oriented Security v prostředí Oracle Fusion Middleware

Zdroj: Oracle Identity Management 11g- WHITE PAPER 2010 [online]. 2010 [cit. 2012-01-12], Dostupný z WWW:

Directory Services – tato kategorie poskytuje soubor produktů na vytváření flexibilní infrastruktury identit prostřednictvím LDAP adresářové sluţby, virtualizace a synchronizace. Následující obrázek ukazuje jednotlivé produkty: Obrázek č. 7: Oracle Directory Services

Zdroj: Oracle Identity Management 11g- WHITE PAPER 2010 [online]. 2010 [cit. 2012-01-12], Dostupný z WWW:

Na obrázku jsou zachyceny základní komponenty Oracle Directory Services (ODS), a to Oracle Internet Directory (OID) a Oracle Directory Server Enterprise Edition (ODSEE) a Oracle Virtual Directory (OVD).

- 23 -

Oracle Virtual Directory (ODV) - je virtuální adresářová sluţba, která provádí přístup a audit informací o identitách (např. kdo je uţivatel a jaké má přiřazeny role a oprávnění) přímo ze zdrojových systémů v reálném čase, namísto jejich uchovávání ve zvláštním depozitáři. Poskytuje jednotný způsob přístupu k informacím o identitách, které mohou být uloţeny ve více depozitářích bez potřeby synchronizace informací do centrálního úloţiště. Oracle Internet Directory(OID) - poskytuje soubor rozhraní a sluţeb, které umoţňují vyvíjet řešení ohledně synchronizace s jinými podnikovými adresáři, například Active Directory. Oracle Directory Server Enterprise Edition (ODSEE) – jedná se adresářový server, který řeší oproti OID více heterogenní prostředí, kde existuje více dodavatelských prostředí. OVD také poskytuje jednotný přístup k více ODSEE prostředím [17].

Access Management - jedná se o funkcionality centrální ověřovací sluţby, které umoţňují jednotné přihlášení SSO (Single Sign-On). Identity Federation - je kompletní řešení pro bezpečnou výměnu identifikačních informací mezi autorizovanými partnery. Společnosti můţou jednodušeji vystavovat funkcionalitu obchodních partnerů k chráněným aplikacím. Významně sniţuje potřebu vytvářet zbytečné identity a sniţuje náklady na integraci partnerů prostřednictvím podpory průmyslových standardů (SAML4, Liberty ID-FF, WS-Federation, Microsoft Windows CardSpace). Fraud Detection – poskytuje moţnost definice pokročilých algoritmů pro posílení mechanismu k ověřování a zjišťování potenciálně podvodných pokusů o přístup. Entitlement Services – poskytuje řešení pro externí centralizovanou správu pravomocí, které zjednodušuje autorizace a bezpečnost v distribuovaných heterogenních aplikacích. Zajišťuje bezpečný přístup ke zdrojům a softwarovým komponentám, ale i k obchodním objektům jako jsou zákaznické účty nebo záznamy o pacientech. Dynamicky ověřuje, kteří uţivatelé, 4

SAML je standard pro výměnu autentizačních a autorizačních dat mezi bezpečnostními doménami

- 24 -

skupiny nebo uţivatelské role mají přístup k aplikacím a k poskytnutým prostředkům. Díky unikátní flexibilní architektuře můţe také vyhodnocovat specializované atributy, aby se přesněji mohlo rozhodnout o pravomoci k přístupu. Samostatná administrační sluţba spravuje a rozděluje komplexní nároky na rozhodování o pravomocích a doručuje je na koncové body. Tyto body mohou být centralizované, ale i začleněné do samostatných aplikací a umoţňují tak flexibilně distribuovat výkon pro jednotlivé kritické aplikace [17]. Identity Administration – tato oblast je zaměřena na správu uţivatelských účtu a rolí a je tvořena dvěma stěţejními produkty: Oracle Identity Manager - jde o klíčovou technologii pro správu uţivatelských účtů a identit

zaloţených

na

úkolech

uţivatelů

(role-based).

Společnosti

mohou

automatizovat proces přidávání, aktualizací a odstraňování uţivatelských účtů a pravomocí v celém systému. Komplexní správa identit podporuje správu uţivatelů, zrychluje návratnost investice a zvyšuje produktivitu uţivatelů. Oracle Role Manager - je aplikace pro správu obchodních a organizačních vztahů, rolí a zdrojů. Jako nejkomplexnějšími produkt zprávy rolí na trhu a systém pro řízení ţivotního cyklu uţivatelské role také poskytuje nástroje pro organizační modelování a správu. Oracle Role Manager přináší integraci s Identity and Access Management (IAM) aplikacemi pro automatizaci poskytování rolí a řízení přístupu v rámci celé IT infrastruktury. Identity Analytics - poskytuje podnikům moţnost definovat a spravovat uţivatelské role a automatizaci ověřování identity. Jakmile jsou definovány, certifikované a přidělené role, nabízí škálovatelné a udrţitelné řízení identity a analytické řešení v celém ţivotním cyklu uţivatelova přístupu. Udrţuje centralizované identity a přístupy, inteligentně rozhoduje díky analýze rizik, zajišťuje monitorování uţivatelů a dodrţování předpisů, automatizuje proces certifikace a odstraňování neplatných přístupů a poskytuje kompletní sadu nástrojů pro řízení ţivotního cyklu rolí [17].

- 25 -

1.2.5. Service Oriented Architecture Oracle Fusion Middleware nabízí podporu pro vytváření podnikových aplikací zaloţených na platformě architektury orientované na sluţby (SOA). Pomocí niţ je umoţněno široké spektrum podnikových přístupů k SOA včetně integrace dat, modernizace aplikací, integrace podniků a kompozitních aplikací. Tato platforma poskytuje širší podnikovou flexibilitu integrováním aplikací a systémů pomocí moderních, otevřených standardů. Základním principům a moţnostem servisně orientované architektury se detailněji věnuji v kapitole 2 “Principy a Architektura pro pouţití middleware“. Produkt podporující architekturu orientovanou na sluţby se jmenuje Oracle SOA Suite a obsahují následující aplikace: Oracle BPEL Process Manager - BPEL (Business Process Execution Language) je standardem pro kompozici (orchestraci) sluţeb do celoplošných podnikových procesů a je klíčovou komponentou pro provádění strategie SOA. Oracle BPEL Process Manager obsahuje nativní podporu standardu BPEL a umoţňuje jednoduché napojení na heterogenní systémy pomocí adaptérů a webových sluţeb. Aplikace obsahuje následující části: vizuální BPEL modelér, škálovatelný BPEL Server, rozšiřitelný rámec pro propojování webových sluţeb a nástroje pro monitorování probíhajících podnikových procesů. Oracle Business Activity Monitoring (BAM)

- je kompletní řešení pro vytváření

interaktivních, manaţerských přehledů poskytujících informace v reálném čase a proaktivní výstrahy pro monitorování podnikových sluţeb a procesů. Oracle BAM poskytuje vedoucím pracovníkům a provozním manaţerům informace souvisejících s podnikovými procesy, které potřebují pro lepší rozhodnutí a operativní nápravná opatření při změně podnikatelského prostředí. Oracle Service Bus – je podniková sběrnice sluţeb určená na navazování, transformaci XML zpráv, zprostředkování a správu komunikace mezi heterogenními sluţbami, staršími aplikacemi a více instancemi ESB v rámci celopodnikové sítě sluţeb. Více se této problematice bude věnovat dále v kapitole věnuji v kapitole 2 “Principy a Architektura pro pouţití middleware“. Oracle Complex Event Processing - poskytuje společnostem kompletní řešení pro navrhování, definování, vývoj a realizaci komplexních aplikací pro zpracování událostí v reálném čase.

- 26 -

Oracle B2B Engine – jedná se o produkt podporující integraci sluţeb integraci mezi firmami (business-to-business - B2B). Podporuje standardní a přizpůsobené B2B protokoly a dokumenty, komplexní správu obchodních partnerů, snadnou integraci se stávajícími aplikacemi a úplný soubor sestav a bezpečnostních funkcí. Oracle Business Rules Engine - umoţňuje podnikovým analytikům snadno definovat a dynamicky měnit obchodní logiku za běhu programu bez nutnosti zapojení programátorů. Business pravidla jsou oddělena od aplikačního kódu. Oracle Integration Adapters (Technology) - poskytuje technologické adaptéry pro všechny komponenty Fusion Middleware. Oblasti pouţití adapterů jsou následující: práce se soubory, práce s databází, Oracle Advanced Queuing, PeopleSoft, SAP, Seibel, JDEdwards, webové sluţby, JMS, HTTP (s), SMTP a FTP [20].

1.2.5.1.

Governance SOA

Pod pojmem SOA governace se označují procesy a přístupy pouţívané pro kontrolu adaptace a implementace SOA v prostředí společnosti. Tato kategorie obsahuje nástroje pokrývající celý ţivotní cyklu sluţeb a jejich přehled uvádím níţe: Oracle Enterprise Repository - jedná se o produkt, který spravuje a uchovává metadata o ţivotním cyklu jednotlivých součástí SOA řešení a vazeb mezi nimi. Nabízí přehled o architektuře, snaţí se minimalizovat redundanci, optimalizuje opakované pouţití sluţeb, poskytuje kontrolu nad dodrţováním standardů. Analytické nástroje zaznamenávají a zobrazují celkový průběh a hodnotu SOA iniciativ. Intenzivní zaměření na automatizaci pomáhá překonat překáţky přijetí SOA a zefektivní řízení během celé doby ţivotnosti. Oracle Management Pack for SOA - pomocí tohoto nástroje mohou administrátoři snadno korelovat události a činnosti pro všechny komponenty v rámci prostředí SOA a umoţňuje jim rychleji řešit problémy výkonu a dostupnosti. S bohatým souborem dashboardů (manaţerských palubních desek/přehledů) na úrovni sluţeb a systému si mohou administrátoři zobrazovat úrovně sluţeb pro klíčové podnikové procesy a komponenty infrastruktury SOA [20].

- 27 -

Oracle Service Registry - zachycuje podrobný popis sluţeb SOA a informace o jejich vyuţívání do centrálně spravovaného, spolehlivého depozitáře, ve kterém lze vyhledávat [20]. Překlenuje mezeru mezi provozem a návrhem pomocí automatické synchronizace s Oracle Enterprise Repository, Oracle Service Bus a Oracle SOA Suite. Mezi hlavní výhody patří kompatibilita se standardem UDDI V3 pro UDDI registry, agilní udrţování aktuálních informací o změnách koncových bodů sluţeb. Oracle Web Services Policy Manager - poskytuje nástroje na vytváření bezpečnostních a provozních politik, které lze vrstvit na nové nebo existující aplikace a webové sluţby spolu s řídícími dashboardy na monitorování těchto politik v průběhu jejich realizace v zájmu zabezpečení úrovní sluţeb a vyhýbání se potenciálním problémům [20].

1.2.6. Content Management V této kategorii najdeme produkty na celopodnikovou správu heterogenního podnikového obsahu (content). Pod obsahem je moţné si představit například soubory s následujícím obsahem: tabulky, webové stránky, emaily, obrázky, video, prezentace atd.

Produkty

umoţňují uţivatelům podílet se na tvorbě dokumentu, přispívat či sdílet libovolný typ informace nezávisle na jejím formátu. Content Management obsahuje následující produkty: Oracle Enterprise Content Management Suite – pokrývá celý ţivotní cyklus dokumentu (zobrazený na obrázku) a díky flexibilitě je moţné řešení adaptovat na potřeby konkrétní uţivatele.

- 28 -

Obrázek č. 8: Ţivotní cyklus dokumentu

Zdroj: Enterprise Content Management with Oracle WebCenter [online]. 2011 [cit. 2011-12-01], Dostupný z WWW:

Tato komponenta se skládá ze souboru následujících částí: Oracle Content Conversion Server - poskytuje výkonné funkce konverze dokumentů na konverzi proprietárních formátů na univerzální formáty čitelné přes web. Oracle Imaging and Process Management - poskytuje funkce skenování obrazů a řízení podnikových procesů pro podnikové aplikace. Zahrnuje podporu pro PeopleSoft, JDEdwards a Oracle E-Business Suite. K dispozici jako součást Enterprise Content Management Suite. Oracle Information Rights Management - umoţňuje organizacím zajišťovat, monitorovat a kontrolovat přístup k informacím v rámci podniku i mimo něj. Uţivatelé mohou pracovat se zabezpečeným obsahem bez ohledu na to, zda jsou připojeni do sítě. Oracle Universal Content Management - je široký soubor nástrojů na správu obsahu včetně modulů Document, Web Content a Digital Asset Management v kompatibilní aplikaci, která obsah zpravidla prezentuje interním i externím uţivatelům.

- 29 -

Oracle Universal Records Management - poskytuje společnou správu záznamů, přičemţ umoţňuje správu záznamů a uchovávání v rámci více systémů správy obsahu po celém podniku, prostřednictvím centralizovaného mechanismu politik. Oracle Universal Records Management Adapters - jsou konektory pro externí depozitáře (například Microsoft SharePoint), které takto lze spravovat centrálně z nástroje Oracle Universal Records Management.

1.2.7. Business Intelligence (BI) Pod označením business intelligence je moţné si představit výkonné analytické a vykazovací nástroje, které umoţňují vyuţít firemní data nejen k analýze jiţ proběhlých jevů, ale také k predikcím budoucího vývoje. Oblast business inteligence je velice rozsáhlá a pro obchodní jednotky důleţitý zdroj pro rozhodování. Není tedy překvapením, ţe obsahuje mnoho komponent ve stěţejnějším produktu Oracle Business Intelligence Suite: Obrázek č. 9: Přehled komponent Business Intelligence

Zdroj: Oracle Fusion Middleware Concepts Guide [online]. 2010 [cit. 2011-10-11], Dostupný z WWW:

Oracle BI Publisher - poskytuje kompletní řešení pro generování a distribuci reportů. Pro návrh a tvorbu reportů umoţňuje vyuţívat soubor známých kancelářských nástrojů jako je Adobe Acrobat, Word a Excel.

- 30 -

Oracle BI Interactive Dashboard - poskytuje interaktivní panely slouţící pro publikování informací. Modul podporuje analytická workflow vedoucí k optimalizaci obchodních procesů. Oracle BI Server - je škálovatelný server BI, který poskytuje centralizovaný mechanismus přístupu k údajům, jejich agregace a výpočtů na získávání informací z různých podnikových datových zdrojů. Tento produkt je vytvořen tak, aby poskytoval vysokou škálovatelnost, spolehlivost a spravovatelnost a umoţňuje organizacím vytvořit si logický byznys model pro různé fyzické datové zdroje - včetně relačních, vícerozměrných, provozních, XML a dalších zdrojů. Poskytuje centrální přístupový bod k datům a kalkulacím pro všechny uţivatele [20]. Oracle BI Server Administrator - BI Server Administrator se pouţívá k definování logické vrstvy, která představuje byznys model, přičemţ koncové uţivatele uchrání před sloţitostí výchozích fyzických datových zdrojů, takţe nemusí vědět nic o klauzulích join, group by, having ani o jiných fyzických strukturách [20]. Oracle BI Answers - je nástroj pro ad-hoc dotazování, reportování a online analýzy s vyuţitím výstupů ve formě tabulek, kontingenčních tabulek a grafů. Uţivatelé pracují s logickým zobrazením informací a mohou snadno vytvářet grafy, sestavy, které jsou všechny plně interaktivní. Lze na nich pouţívat přechod na niţší úrovně dat a lze je sdílet, ukládat, modifikovat, formátovat nebo vkládat do nástroje Oracle BI Interactive Dashboard. Oracle BI Delivers - je proaktivní řešení BI, které poskytuje monitoring činnosti a rozesílání upozornění, které se mohou k uţivatelům dostat více kanály, například elektronickou poštou, přes manaţerské dashboardy nebo mobilní zařízení [20]. BI Disconnected Analytics – produkt poskytuje analytické a reportovací schopností nástrojů BI Interactive Dashboards a BI Answers i kdyţ jsou uţivatelé bez připojení k firemní síti. BI Interactive Dashboard - poskytuje interaktivní panely (dashboardy) slouţící pro publikování informací a také interaktivní přístup k informacím, na základě nichţ lze rozhodovat. BI Office Plug-In - umoţňuje uţivatelům rychlý a snadný přístup k informacím v aplikaci Microsoft Excel a jejich analýzu [20]. - 31 -

BI Reporting and Publishing - umoţňuje uţivatelům vytváření rozsáhlých sestav, jejich formátování (a to aţ do velkého grafického detailu) a distribuci. Oracle Application Adapters for Warehouse Builder - poskytují hotovou konektivitu na aplikace, jako jsou Oracle E-Business Suite, PeopleSoft, SAP a Siebel [20].

1.2.8. User interaction Jako poslední část nám zůstala vrstva pro interakci s uţivatelem, která nám nabízí kompletní a integrované kompozitní uţivatelské rozhraní pro vývoj internetových aplikací, podnikových portálů a sociálních sítí, čímţ transformuje způsob sdílení informací mezi lidmi pomocí internetu s vyuţitím technologie Enterprise 2.0 [20]. Tato vrstva je postavena na následujících produktech: Oracle WebCenter Services – poskytuje opakovaně pouţitelné komponenty, které umoţňují obohatit stávající portálové řešení souborem funkcí a funkcionalit zaloţených na principech koncepce Enterprise 2.05. Tento produkt je postaven na následujících komponentách: Oracle WebCenter Framework - poskytuje frameworkový rámec pro tvorbu a spouštění kontextově bohatých aplikací na bázi Java Server Faces (JSF). Oracle WebCenter Framework v zásadě integruje přímo do prostředí JSF funkce historicky obsaţené v portálových produktech a umoţňuje tvorbu a vkládání komponent na bázi technologie AJAXu6 a portletů. Oracle Ensemble - poskytuje mechanismus pro sestavování portálů na bázi REST. Jedná se o účinný systém pro správu webových prostředků jako jsou aplikace, komponenty, widgety atd. Tyto prostředky rovněţ dokáţe spojovat do nových i stávajících webových aplikací. Oracle Portal – poskytuje softwarové prostředí pro vytváření a nasazování podnikových portálů přímo z prostředí web prohlíţeče. Portálové rozhraní nabízí organizovaný,

5

Enterprise 2.0 je koncept, v jehoţ rámci integrujeme nástroje a technologie Web 2.0 do podnikových procesů, čímţ podporujeme spolupráci zaměstnanců, partnerů, dodavatelů a zákazníků a zapojujeme je do nově vzniklých sítí lidí s potřebou přístupu k obdobnému typu informací [9]. 6

Asynchronous JavaScript and XML – princip komunikace poskytující dynamickou změnu obsahu webových stránek bez nutnosti znovunačtení stránky (tzv. refresh).

- 32 -

personalizovaný pohled na podnikové informace, webový obsah a aplikace, které potřebuje kaţdý uţivatel [20]. Oracle WebCenter Adapters - poskytují propojení s aplikacemi třetích stran. Jedná se například o propojení Lotus Notes, MS Sharepoint, Documentum a MS Exchange. Oracle WebCenter Analytics – poskytuje přehled o činnosti portálu a webových aplikací. Nabízí ukazatele pro uţití stránek, obsahu, portletů, dokumentů, komunity Oracle WebCenter Interaction a nástroje Oracle WebCenter Collaboration. Zároveň jsou sledovány časy odezvy portletů a stránek a počet přihlášení uţivatelů. Nástroj disponuje schopností korelace výsledků pomocí jakéhokoli atributu metadat uţivatele, který danou akci provedl. Tímto způsobem lze efektivně vyhodnotit, jak se aplikace a informace v podniku pouţívají. Oracle WebCenter Interaction – poskytuje funkcionalitu k vytváření podnikových portálů, spolupracujících komunit a kompozitních aplikací. Poskytuje podporu pro více jazyků z různých platforem jako je Java či NET framework. Oracle WebLogic Portal - jedná se o portálové řešení, které má širokou podporu standardů (zejména technologie Web 2.0) a je vyvinuto pomocí technologie Java. Tento produkt byl získán při akvizici firmy BEA Systems a v současnosti je označen jako "non-strategic", nicméně je hodně pouţíván původními klienty BEA.

- 33 -

2. Principy a architektura pro použití Middleware Z předchozí kapitoly je patrné, ţe Oracle Fusion Middleware je velmi obsáhlý balík softwarových aplikací a komponent. Nicméně seskupení těchto produktů by principiálně nemělo velký význam. Poměrně významnou roli zde hraje princip integrace jednotlivých komponent mezi sebou a moţnost vyuţití vlastnosti nové moderní architektonické koncepce postavené na servisně orientované architektuře (SOA) v heterogenních počítačových prostředích. Principům této architektury se věnuji v následující podkapitole. Na následujícím obrázku je nastíněna architektura rozvrţení komponent pro typické prostředí Oracle Fusion Middleware. Jsou zde zobrazeny elementy vrchní webové vrstvy, jejíţ představitelé jsou Oracle Web Cache, Oracle HTTP Server. Dále pak střední vrstva (aplikace, Oracle SOA Suite a WebCenter a Oracle Identity Management) a Data vrstvy (LDAP a databáze). Klientská vrstva zahrnuje přístup pomocí Oracle Enterprise Manager Control Fusion Middleware a Oracle WebLogic Server Administration Console (WLST). Obrázek č. 10: High-level architektura Oracle Fusion Middleware

Zdroj: Oracle Fusion Middleware Components [online]. 2010 [cit. 2011-10-12], Dostupný z WWW:

- 34 -

2.1. Servisně orientovaná architektura 2.1.1. Principy SOA Pro SOA neexistuje zcela jednoznačná definice, jde spíše o volnější pojem, a proto se stalo jakousi tradicí, ţe kaţdý dodavatel z této oblasti má trošku jiný přístup v jeho poskytovaném SOA řešení. Uvádí se, ţe kořeny konceptu servisní orientace jsou zaloţeny na teorii oddělení zájmů (SoC - separation of concerns). Princip teorie je zaloţen na poznatku, ţe rozdělení velkého problému na sadu menších problémů se zdá být jednoznačně výhodnější [4]. Proto je moţné dívat se na servisně orientovanou architekturu jako na jiný způsob oddělení zájmů. Nicméně zde uvedu jednu z definic, kterou publikoval jeden z nejprodávanějších světových autorů o SOA Thomas Erl: “SOA je ve skutečnosti implementačně neutrální architektonický model a servisní orientace je implementačně neutrální paradigma“ [Erl, 2009, str . 442]. Jak je vidět z této definice, je velice těţké si představit o co se jedná. Lepší neţ hledání a pochopení definice SOA je proto představení jasných principů, které jsou spojené se SOA. Jedná se tyto principy: Služby jsou opětovně použitelné – takzvaná znovupouţitelnost. Logika je rozdělena do sluţeb za účelem podpory opětovného pouţití. Znovupouţitelnost je podporována například protokolem SOAP (Simple Object Access Protocol) při vyuţití webových sluţeb. Kontrakt služeb – sluţby zachovávají dohodu při komunikaci, jak je souhrnně definováno v jednom nebo více popisech sluţeb a souvisejících dokumentech [15]. Hlavním představitelem je zřejmě formát WSDL (Web Services Description Language), který popisuje rozhraní webové sluţby. Volná vazba – jedná se o základní kámen servisně orientované architektury, kde je snaha o minimalizaci závislostí mezi sluţbami tak, aby nevolala přímo jedna druhou. Jedná se o událostně řízenou komunikaci přes koncové tzv. vstupní/výstupní body (entry/exit endpoints). Výhodou volné vazby je pak moţnost lepší znovupouţitelnosti a také lepší kompozice sluţeb. Abstrakce logiky v pozadí – sluţba skrývá svoji logiku před okolním světem. Sluţba je popsána definicí rozhraní, z kterého není moţné poznat logiku, kterou sluţba provádí. Kompozice – spojování sluţeb ve volně vázaném kontextu do vyšších kompozitních celků.

- 35 -

Služby jsou autonomní – sluţby mají kontrolu nad logikou, kterou zapouzdřují [4]. Sluţby by měly ovládat pouze tu logiku, která je v nich zapouzdřená a tím eliminovat závislost na ostatních sluţbách. Bezstavovost – sluţby minimalizují mnoţství uchovávané informace, které jsou určené pro nějakou další aktivitu [4]. Zjistitelnost – sluţby jsou navrţeny tak, aby byly navenek samopopisné a přirozeně zjistitelné a tímto se staly dostupnější novým ţadatelům sluţeb. Pro vyhledávání sluţeb slouţí technologie UDDI (Universal Description, Discovery and Integration). Jedná se o standardní mechanismus umoţňující registraci a vyhledávání webových sluţeb. SOA tedy není ani konkrétní technologie, produkt či norma nebo standart, ale jde o obecný přístup jak aplikace budovat a hlavně integrovat. Proto pro podporu budování servisně orientovaných řešení vznikl implementačně nezávislý referenční model SOA, který popisuje vztahy mezi jednotlivými subjekty. Referenční model je zobrazen na následujícím obrázku.

- 36 -

Obrázek č. 11: Referenční model SOA

Zdroj: ERL, T. Servisně orientovaná architektura SOA. Brno: Computer Press, 2009. 654s. ISBN 978-80-251-1886-3

vrstva řídících procesů – jedná se o nejvyšší vrstvu, kde je řešena problematika spojování do větších celků, a to do procesů a je spíše konceptuálně zaměřená. vrstva rozhraní sluţeb – tato vrstva je sloţena z dalších vrstev. o vrstva sluţeb instrumentace – vrstva sluţeb instrumentace se skládá z jedné nebo více sluţeb procesu, které komponují sluţby a aplikace podle řídící logiky obsaţené v definicích procesu. V prostředí Oracle Fusion Middleware tuto vrstvu zastupuje Oracle BPEL Process Manager. o vrstva sluţeb řízení – servisní orientace rozděluje logiku na řídící a aplikační. Tato vrstva právě představuje kolekci sluţeb zaloţených na vzoru řízení. Řídící sluţby spojují sluţby aplikace, aby prováděly jejich řídící logiku [4]. V prostředí Oracle Fusion Middleware tuto vrstvu zastupuje například Oracle Service Bus.

- 37 -

o vrstva sluţeb aplikace – poskytuje znovupouţitelné sluţby aplikací, které nesouvisejí s řízením a reprezentují logiku specifické aplikace. V prostředí Oracle Fusion Middleware tuto vrstvu zastupuje také Oracle Service Bus a různé adaptery pro komunikace s jinými aplikacemi. aplikační vrstva – zastřešuje komponenty jednotlivých aplikací (např. CRM Siebel, billing atd.) a poskytuje jejich funkcionalitu vrstvě rozhraní sluţeb. Tato vrstva typicky implementuje funkčnost systému [4]. technologická vrstva - technologická vrstva je těsně provázaná s konkrétními technologiemi, které následně poskytují technologickou funkcionalitu aplikační vrstvě. Produkty jako například JRockit/Hotspot, Weblogic, Tuxedo atd. jsou představitelé této vrstvy. Tato vrstva obsahuje také dříve vyvinuté systémy poskytující data a funkcionalitu. SOA Governance – vrstva SOA governance je zaměřená na ţivotní cyklus sluţeb a dalších SOA artefaktů tak, aby byl zajištěn jejich business přínos. Tato vrstva poskytuje centralizované uloţiště metadat, vizualizaci sluţeb, řízení sluţeb, reporting atd. Dále pak monitoruje přenos zpráv, počet konzumentů sluţeb, vytíţenost jednotlivých sluţeb, jak je sluţba vyuţívána aţ po detekování nebezpečných sluţeb.

SOA Governance je

podmnoţinou mnoţiny IT Governance. Typickými představiteli jsou produkty Oracle Business Activity Monitoring (BAM), Oracle Enterprise Repository, Oracle Service Registry z. Security – úkolem této vrstvy je zajistit zabezpečení podnikových aplikací pro volání sluţeb v rámci servisně orientovaného řešení. Představiteli produktů

zajištující tuto

funkcionalitu v Oracle Fusion Middleware jsou aplikace z kategorie Identity Management Toto rozdělení do jednotlivých vrstev není v praxi vţdy striktně dodrţováno a můţe docházet ke kombinacím sluţeb řídících a aplikačních a takto vzniklé sluţby jsou označeny za hybridní. Budoucnost servisně orientované architektury podle Hype křivky od firmy Gartner směřuje do posledních dvou fází procesu coţ je směrem k nasazení v mainstreamových produktech, jak ukazuje následující obrázek. Obrázek č. 12: Hype křivka 2010 firmy Gartner

- 38 -

Zdroj: Hype Cycle for Business Process Management, 2011. [online]. 2011 [cit. 2012-03-12], Dostupný z WWW:

2.1.2. Pravidla komunikace V rámci principů SOA je stěţení a důleţitá komunikace mezi jednotlivými komponentami middlewaru. I platforma Oracle Fusion Middleware, která obsahuje velké mnoţství komponent a produktů, které jsou umístěné na všech vrstvách referenčního modelu, pouţívají základní komunikační vzory zajištující výměnu zpráv mezi sluţbami tzv. vzory výměny zpráv.

- 39 -

Obrázek č. 13: Komunikační vzory

Zdroj: GÁLA, L., POUR, J., ŠEDIVÁ, Z. Podniková informatika. 2.vyd. Praha: Grada, 2009. 496s. ISBN 978-80-247-2615-1

Vzor Request/Response - vzor pro synchronní komunikaci mezi klientem a poskytovatelem sluţby. Např. operace vratCenu a jako response je vrácena cena. Vzor One-Way - asynchronní komunikace, kde klient volá poskytovatele a nečeká na odpověď. Např. modifikace hodnot objektu, kde není vyţadováno znát, jak operace přímo dopadla nebo je potřebný delší čas na zpracování (výsledek akce pak můţe být oznámen následujícím principem notifikace). Vzor Notification – jedná se o asynchronní zprávu klientovi při oznámení změny. Vzor Solicit/Response – komunikaci inicializuje poskytovatel sluţeb a ţádá klienta o volání, kde klient později volá poskytovatele sluţby. Např. pro oznámení klientovi, aby si obnovil odebírání určité sluţby, kterou měl zaregistrovanou.

- 40 -

2.1.3. Kompozice služeb Jedním z principů je spojování sluţeb ve volně vázaném kontextu do vyšších kompozitních celků. Pod kompozitním celkem si můţeme představit sadu sluţeb, které spolu spolupracují za účelem vykonání určitého procesu, který definuje interakční workflow. [12] Orchestrace Princip orchestrace spočívá v centrálním řízení. Orchestrace zahrnuje pořadí vykonávání interakcí webových sluţeb, popisuje tok vykonatelného procesu a můţe zahrnovat jak interní, tak externí webové sluţby. Při orchestraci je proces vţdy řízen jednou stranou. Interakce při orchestraci nastávají na úrovni zpráv. Zahrnují byznys logiku, pořadí vykonávání úkolů a mohou pokrýt aplikace a organizování k definování dlouhotrvajícího, transakčního a vícestupňového procesního modelu [19]. Podpora orchestrace v rámci sady Oracle Fusion Middleware je v produktu Oracle BPEL Process Manager. Choreografie Choreografie popisuje interakce a výměnu zpráv, které mají mezi sebou navzájem dvě a více aplikací. Jedná se tedy především o komunikaci přesahující hranice organizace, a proto musí být logika, která vykonává choreografii distribuována poskytovatelem aplikačních sluţeb [10]. Porovnání orchestrace a choreografie Podstatným rozdílem orchestrace a choreografie je v řízení komunikace, kde orchestrace deleguje řízení procesu na nadřazenou sluţbou, zatímco choreografie rovnoměrně rozděluje řízení mezi účastníky komunikace. Z obou konceptů se zdá orchestrace jako více flexibilní, kde je moţné různě spojovat sluţby a v případě chyby spustit jiný scénář z procesu [4]. Názorně je rozdíl vidět z obrázku.

- 41 -

Obrázek č. 14: Porovnání orchestrace oproti choreografii

Zdroj: ERL, T. Servisně orientovaná architektura SOA. Brno: Computer Press, 2009. 654s. ISBN 978-80-251-1886-3

2.1.4. Enterprise Service Bus Jeden se stěţejních produktů, který naplňuje vizi servisně orientované architektury a je ideální platformou pro její realizaci se nazývá Enterprise Service Bus (ESB). Dokonce je ESB označeno jako obecný architektonický vzor, který poskytuje infrastrukturu nutnou pro rychlou a flexibilní integraci aplikací a informačních systémů na bázi sluţeb. Nicméně ESB nemusí být pouţito pouze v rámci SOA architektury. Základním principem je sníţení počtu propojení mezi jednolitými aplikacemi a potlačení negativního jevu v podobě integrace metodou špaget (těsně vázané systémy). Typický ESB je postaven na robustní messagingové platformě, která umoţňuje podporu synchronní i asynchronní komunikace, zaručeného doručení zpráv, publish & subscribe mechanismů apod. Velmi důleţitou roli zde hraje robustnost celého řešení a nativní podpora principů high-availibility, load-balancing, fail-over, disaster recovery. Dále pak transformaci XML zpráv, směrování (routování) procesního toku podle nastavených pravidel a auditovaní zpráv. Platforma také zajišťuje určitou kvalitu komunikace sluţeb (QoS - Quality of Service) pro různé konzumenty či pro různé sluţby například s cílem řízení objemu komunikace pro ochranu jednotlivých komponent před nadměrným přetíţením. Strukturu produktu Enterprise service bus je znázorněna na následujícím obrázku.

- 42 -

Obrázek č. 15: Struktura Enterprise Service Bus

Zdroj: ERL, T. Servisně orientovaná architektura SOA. Brno: Computer Press, 2009. 654s. ISBN 978-80-251-1886-3

I platforma Oracle Fusion Middleware nabízí produkt typu ESB, který se jmenuje Oracle Service Bus. Dále s ním budu detailněji pracovat v praktické části.

- 43 -

3. Modelový příklad - objednávkový proces V předchozích kapitolách jsem představil jednotlivé komponenty produktové řady Oracle Fusion Middleware a vysvětlil jsem základní principy servisně orientované komunikace, která je pouţita při interakcích mezi jednotlivými komponentami či aplikacemi. V této kapitole se zaměřím na pouţití některých komponent v reálném objednávkovém procesu telekomunikační firmy.

3.1. Požadavky a cíle Vznikl poţadavek obchodních jednotek na modernizaci (v informační terminologii se jedná o redesign) objednávkového procesu, který v současnosti není plně v souladu s firemním cílem, který stanovuje, aby bylo moţné co nejvíce poţadavků vyřídit okamţitě (online) v řádu sekund aţ minut. Tuto příleţitost na zásadní změnu procesu uvítalo i IT oddělení a snaţilo se o narovnání integrační vrstvy. Kde historickým vývojem vznikla změť různých nekontrolovatelných a nedokumentovatelných propojení jednotlivých aplikací (téţ známém pod termínem „špagety architektura"). Tento přístup způsoboval problémy, jak časové při vývoji nových funkcionalit obchodních procesů, tak i technologické při samotném vývoji. Proto vznikl poţadavek na zpřehlednění a sjednocení této komunikace, čímţ se očekává výsledný bonus ve zkvalitnění dodávky a zkrácení času (time to market ) na realizaci nových funkcionalit.

3.2. Analýza požadavků Z uvedených poţadavků lze odvodit zásadní změny pro současné integrační řešení. Jeden ze stěţejních přínosů lze očekávat v přechodu na servisně orientovanou architekturu. Tato architektura svými základními principy umoţnuje volnou vazbu funkcionalit, kompozici atomických celků do celků sloţitějších, abstrakci logiky jednotlivých funkcionalit a neméně důleţitou zvoupouţitelnost7 jednotlivých funkcionalit (více kapitola 2.1.1). Servisně orientovaná architektura s sebou také přináší mnoţství technologických standardů (SOAP, WS, WSDL, WS-Security, BPEL4WS atd.), které podporují jiţ zmiňované základní principy SOA.

7

V anglické terminologii označovaném termínem - reuse.

- 44 -

Pro splnění klíčového business poţadavku na co nejrychlejší zpracování objednávky bude právě vyuţito standardu webových sluţeb. Z historických důvodů jsou ve firmě pouţívány technologie a produkty firmy BEA Systéms, jenţ byla v minulosti koupena firmou Oracle, proto i zde padlo rozhodnutí na vyuţití produktů ze sady Oracle Fusion Middleware.

3.3. Architektura a komponenty 3.3.1. Klíčové systémy procesu V celém objednávkovém procesu dochází k mnoţství interakcí mezi jednotlivými systémy zastřešující jednotlivé funkcionality. Jenom náběrových kanálů objednávky je několik a přistupují zde uţivatelé z vnitřní sítě, kde není bezprostřední ohroţení napadnutí systému, tak existuje i moţnost přístupu externích agentur přímo prostřednictvím veřejného internetu, kde existuje moţnost napadnutí sytému. Pro tuto variantu je zde vybudována komunikační B2B (Business To Business) brána slouţící k zabezpečené komunikaci. Na následujícím obrázku jsem zachytil připojení klíčových systémů v rámci objednávkového procesu.

- 45 -

Obrázek č. 16: Diagram systémů objednávkového procesu

Zdroj: vlastní

Z obrázku je jasně patrné, ţe řešení přinese odstínění backend systémů od frontend systémů pomocí vrstvy integrace. Pod backend systémy jsou myšleny systémy, které přímo nekomunikují s uţivateli a do kterých mají přístup pouze provozovatelé či administrátoři. Přehled klíčových backend systémů: Systém billingu - zajištuje fakturační procesy a je zárukou správného, bezchybného a spolehlivého vyúčtování všech provozovaných sluţeb operátora koncovému zákazníkovi. Operátor vyuţívá dvě billingové platformy, a to pro zákazníky vyuţívající předplacené sluţby (tzv. prepaid) a tarifní zákazníky (tzv. postpaid). Systém provisioning – systém jenţ zajišťuje propagaci sluţeb či jiných poţadavků do fyzické telefonní sítě (např. aktivaci hlasového čísla, datových sluţeb atd.).

- 46 -

MNP (Mobile number portability) – systém zajišťuje funkcionalitu pro migraci čísel mezi telefonními operátory a vyměňuje si potřebná data pro fungování portačního procesu. Fraud systém – systém se souborem procesů pro detekci podezřelých či podvodných chování v objednávkových procesech. Skládá se z interní databáze dluţníků a neplatičů, dále je pak systém napojen i na registr dluţníků SOLUS. RMS (Resource Management System) – systém zajištující management zdrojů jako jsou SIM karty, telefonní čísla atd. Jiné systémy – pod tímto boxem jsou skryté menší aplikace podporující objednávkový proces. Přehled klíčových frontend systémů: Selfcare - jedná se o samoobsluţný portálový systém, který zákazníkům dává moţnost přidávat a měnit sluţby na svém telefonním účtě. IVR (Interactive Voice Response) – systém poskytující sluţby hlasového automatu. CRM (Customer relationship management) – stěţejním systémem pro práci operátorů jak ve značkových prodejnách, tak i operátorů zákaznické linky. Jedná se o CRM produkt z balíku Oracle Fusion Applications z kategorie řízení vztahů se zákazníky (viz. Kapitola 1) - Siebel CRM. SMS brána – systém podporující ovládání některých sluţeb přes SMS zprávy. Tyto aplikace jiţ existují a není potřeba je měnit. Stěţejní pro integrační oddělení je velký box uprostřed nazvaný integrace a také box B2B gateway. Takto navrţený model by měl zamezit nekontrolovanému propojení jednotlivých aplikací a měl by přispět k lepší moţnosti dokumentace, pokud propojení aplikací bude přes stejnou platformu.

3.3.2. Návrh integrační infrastruktury Pro budování robustní middlewarové vrstvy je nesmírně důleţité nepodcenit moţnosti poskytované infrastruktury. Jde o základní stavební kameny, které kdyţ nefungují, tak nefunguje celé řešení. Základem infrastruktury je samozřejmě pouţitý hardware, který sice není součástí balíku Oracle Fusion Middleware, ale správný výběr je důleţitý. Společnost Oracle získala akvizicí společnosti Sun široké portfolio hardwarových komponent a produktů,

- 47 -

mimo jiné i produktovou řadu serverů SPARC, které jsou vhodné pro běh podnikových aplikací. Dále pak i pro provoz databáze Oracle a dalších kritických systémů, pomocí kterých je moţná efektivní virtualizace a konsolidace datových center. Novinkou posledních let v oblasti provozu kritických a na výkon zvlášť náročných aplikací napsaných v jazyce Java je integrovaný hardwarový a softwarový systém Oracle Exalogic Elastic. Tento systém propojený přes proprietární vstupně/výstupní rozhraní InfiniBand s databázovým řešením Oracle Exadata, představuje dostatečně robustné řešení s vynikajícími parametry v oblasti výkonu, virtualizace, spolehlivosti a bezpečnosti. Nicméně se jedná o velice drahé a zatím málo rozšířené řešení, a tím pádem nemusí být zcela prověřěné a odladěné dlouhodobějším reálným provozem. Jeden z klíčových problému je ukryt v licenčním modelu firmy Oracle, který není zcela připraven na techniky virtualizace, coţ je jeden z hlavních přínosů řešení Exalogic. Objasním na krátkém příkladu, kdy například v období vánočních svátků při provádění marketingových akcí narůstá provoz na informačních systémech, a proto je ţádoucí přidat další node do clusteru nebo zvětšit paměti či přidat další procesor, ale pouze na omezenou dobu. V této chvíli nastává problém a licenční model, který nepočítá s tímto dočasným rozšířením. Jednoduše stanoví, máte-li X procesorů/jader na serveru a i kdyţ je nepouţíváte, tak je musíte zaplatit. Tímto se dostává toto řešení k závratným částkám placených za licence. Proto v následujícím řešení vyuţiji stávající hardware zaloţený na procesorech SPARC T3 s dostatkem RAM paměti (32 GB), která je nezbytná pro aplikace zaloţené na platformě Java. V oblasti operačních systémů je moţné vybrat ze dvou variant, a to v podobě linuxu Red Hat Enterprise čí Solaris. Z historických důvodů firma pouţívá 64 bitový systém Solaris, a proto bude vyuţit i zde. Produkty zatím zmíněné nejsou součástí Oracle Fusion Middleware, nicméně jsou hodně důleţité pro správnou funkčnost middleware vrstvy. Další produkty jiţ jsou obsahem Oracle Fusion Middleware, a to především kategorie Application Grid popsané v kapitole 1.2.2. Ta poskytuje ve svém portfoliu aplikační server Weblogic, který je nutný pro provoz aplikací vyuţitých v tomto řešení. Ve výběru aplikačního serveru není de facto jiná moţnost. Můţe se to zdát jako velice jednoduché, nicméně stěţejní aktiva zde směřuje spíše k návrhu řešení, které je hodně důleţité a můţe v budoucnu připravit nemilé překvapení. Jako jedna z prvních aktivit je výběr JVM, které pro svoji práci vyuţívá aplikační server. Výběr je ze dvou moţných variant, které Oracle v minulosti získal akvizicí firmy SUN, která vyvinula Hotspot

- 48 -

a akvizicí firma BEA Systems, která vyvinula JRockit. Jedná se zde o základní strategické rozhodnutí, které se následně těţkopádně mění. Uvádím zde několik základní otázek při výběru JVM: 32 nebo 64 bit platforma? jaká moţnost monitorování samotného JVM a ladění JVM? jaká verze JVM? Při návrhu řešení jsem vyuţil jiţ několikaleté zkušenosti s programování v Javě a vybral jsem méně známou JVM JRockit 64bit, která v určitých ohledech předčí Hotspot od SUNu. K tomuto výběru mě vedly následující aspekty. Integrační middleware by měl zpracovávat miliony zpráv denně s velikostmi řádově do 1 MB při synchronním volání a stovky kilobytu při asynchronním volání v podobě JMS zpráv. Z toho vychází, ţe JVM bude muset drţet data jak aplikačního serveru, tak i samotné aplikace (např. Oracle Service Bus) a ještě vykonávat transformace a různé procesy aplikačního flow. Z tohoto pohledu je 32 bitová architektura s maximální velikostí heapu 4GB silně omezují, a proto bude vyuţita 64 bitová architektura. Dalším bodem, který silně ovlivnil můj výběr jsou moţnosti samotného ladění JVM a monitorování, které nabízí JRockit lepší pro kritické serverové aplikace. Je to asi dáno i tím, ţe Weblogic server a JRockit byl vyvinut stejnou firmou BEA Systems. JRockit poskytuje lepší diagnostické nástroje v podobě Mission Control konsole, která umoţňuje mimo jiné i moţnost záznamů pohybů objektů v paměti JVM. Navíc umoţňuje dobrou podporu pro ladění běhu platformy pomocí podpory dynamických změn některých JVM parametrů za běhu serveru. JRockit také jiným způsobem pracuje s rozdělením paměti, coţ v určitých případech velkého zatíţení zvyšuje výkon. Samotná verze JVM je pak dána podle instalace verze samotného Weblogic Serveru. Jeden z dalších důleţitých poţadavků je zajištění spolehlivosti (failover), velké dostupnosti (high-availability) a rozšiřitelnosti (scalability) systému. Proto jsem v tomto řešení vyuţil nabízené moţnosti Weblogic serveru, který podporuje princip spojení více serverů do clusteru. Základní schéma návrhu clusteru popisuji na následujícím obrázku. Tento princip bude vyuţit pro kaţdou komponentu integrace (B2B, Service Bus, BPEL engine).

- 49 -

Obrázek č. 17: Návrh řešení clusteru

Zdroj: vlastní

Z obrázku je patrné, ţe cluster je sloţen ze dvou hardwarových serverů, kde první server obsahuje administrační server, který pomocí node manageru spravuje jednotlivé managed servery. Komunikaci mezi administračním serverem a jednotlivými managed servery je zaloţena na interní komunikaci přes proprietární protokol t3 na obrázku zobrazeném a označeném jako HeartBeat. Rozloţení zátěţe na jednotlivé servery je zajištěno pomocí předřazeného loadbalanceru, coţ je ve své podstatě server, který pomocí různých technik (např. Round robin) rozděluje zátěţ na jednotlivé managed servery clusteru. Load balancer je pouţit pro synchronní komunikaci zaloţenou na webových sluţbách. Zatímco asynchronní komunikace je zaloţena na principech JMS (Java Messaging Services). Pro tuto komunikaci se speciálně v clustrových řešeních vyuţívá distribuovaných JMS front, které jsou umístněné na všech managed server v clusteru. Jednou z hlavních otázek pro vytvoření a konfiguraci JMS komunikace je rozmyšlení jak budou uloţeny (persistovány) jednotlivé zprávy. Weblogic poskytuje uloţení v databázi anebo do souboru. Obě varianty mají klady a zápory, jak jsem se i v praxi přesvědčil. Výhoda ukládání do souboru spočívá v tom, ţe pokud dojde k problémům s DB nebo někde po cestě na síti, tak není omezen provoz JMS serverů. Nevýhody jsou v tom, ţe soubor se zprávami se pouze zvětšuje, i kdyţ obsahuje málo zpráv a tím způsobuje zpomalení startu serveru (řádově aţ minuty) a zprávy není moţné v souboru jednoduše přečíst. Kdeţto JDBC JMS server startuje velice rychle a zprávy je moţné si prohlédnout v tabulkách. Za to nevýhodou je, pokud nastane problém s DB či někde na síti. Pak dojde k problémům a server se musí restartovat.

- 50 -

B2B komunikace Všechny doposud popsané aplikace jsou interního charakteru coţ znamená, ţe jejich fyzické servery se provozují na vnitřní chráněné síti ve specifické demilitarizované zóně (DMZ Demilitarized Zone). Coţ v principu představuje jakousi samostatnou síť, kam není moţný běţný přístup z internetu a aplikace zde fungující jsou chráněny bezpečnostními prvky (typu firewall, paketové filtry atd.) před únikem informací či útokem hackerů. Nicméně z obchodního hlediska je potřeba komunikovat s nasmlouvanými externími partnery, kteří zabezpečují část obchodních aktivit pro telekomunikačního operátora. Z technického hlediska ale není moţné budovat pro tyto partnery odpovídající infrastrukturu a přístup do vnitřní sítě. Proto je pouţit pattern B2B gateway, coţ je v principu aplikace, která neřeší ţádné procesy či logiku, ale jejím hlavním úkolem je zprostředkovat a zabezpečit komunikaci přes vnější internet. V našem řešení se bude jednat o aplikační server, který bude v sobě ukrývat mnoţství certifikátu pro SSL/TLS8 komunikaci a moţnosti autentizace přistupujících partnerů.

3.3.3. Konceptuální model integrační vrstvy Neţ se detailněji zaměřím na konceptuální model, je potřeba ujasnit co všechno musí integrační vrstva splňovat: poskytnout synchronní komunikaci poskytnou moţnosti asynchronní komunikace technologické přizpůsobení okolním systémům moţnost procesního zpracování datová transformace ochránit procesní flow při odstávkách backend systémů moţnost ochránit backend systém před náhodným zahlcením (throttling9) zabezpečený přístup externím partnerů provoz s minimem výpadků (24x7) Následující model přináší konceptuální pohled na vnitřní rozloţení základních funkčních bloků integrační mezivrstvy. Cílem tohoto konceptuálního modelu je přiblíţit projekční bloky 8

Secure Sockets Layer - poskytuje zabezpečení komunikace šifrováním a autentizaci pro komunikaci třetích stran. 9

Throttling - volně přeloţeno jako přiškrcení procesního toku

- 51 -

navrţeného řešení a definovat jejich základní funkcionalitu. Funkcionalita je definována v podobě mnoha činností, které jednotlivé bloky budou zajišťovat nebo vlastnostmi, které jednotlivé bloky budou disponovat. Model vznikl v souladu s metodikou návrhu IS, a to dekompozicí poţadovaných funkcionalit do základních bloků. Obrázek č. 18: Konceptuální model jednotlivých systému integrace

Zdroj: vlastní

Stručnou charakteristiku jednotlivých bloků popisuje následující přehled: Podniková sběrnice (Enterprise Service bus ESB) – v tomto řešení je ESB pouţitá jako jedna z klíčových integračních komponent. V obecné rovině servisně orientované architektury je ESB označován za obecný architektonický vzor, který poskytuje infrastrukturu nutnou pro rychlou a flexibilní integraci aplikací a informačních systémů na bázi sluţeb. Díky ESB mohou mezi sebou v reálném čase komunikovat různorodé aplikace pouţívající rozdílné přenosové protokoly a datové formáty. Lze tedy velice elegantně a rychle integrovat moderní aplikace se staršími aplikacemi, které pouţívají historické komunikační prostředky. V tomto řešení je ESB pouţita jako vrstva řídících sluţeb a poskytovatel sluţeb vrstvy aplikačních. Pod aplikačními sluţbami je moţné si představit provolání sluţby spojené s určitý backendovým

systémem

např.

vytvoření

zákazníka

- 52 -

v billingu.

V podstatě

jde

o

přetransformování zprávy do srozumitelného formátu backendové aplikace za pouţití adapteru vyuţívajícího protokolu komunikace, které taktéţ rozumí backendová aplikace. Kdeţto vrstva řídících sluţeb vyuţívá spíše principů směrování (routing), který se podle specifických pravidel rozhoduje, jakou aplikační sluţbu zavolá. V této vrstvě jiţ mohou vznikat jednoduché sloţené kompozitní sluţby, coţ představuje určitou spolupráci několika sluţeb aplikačních. ESB také slouţí jako jediný vstupní bod pro systém BPM. Provozní poţadavek na ESB je zabezpečení provozu v reţimu 24/7, a proto bude pouţit princip zapojení serveru do clusteru. Při realizaci se bude dbát na maximální vyuţití webových sluţeb, aby odpověď byla v co nejkratším moţném čase. Realizace ESB je provedena produktem OSB (Oracle Service Bus) ze sady Oracle Fusion Middleware. B2B brána - B2B brána zabezpečuje čtyři základní klíčové aspekty: zabezpečení, komunikační standardy, management komunikace a integrace vůči internímu systému. Z ryze technického pohledu je B2B brána specifická integrační platforma umoţňující komunikaci mezi koncovými systémy na straně společnosti a externími partnery. Předmětem mezifiremní komunikace jsou velmi citlivé informace a je tedy nutné maximální zabezpečení komunikace. V našem případě je zabezpečení komunikace realizováno pomocí šifrovacích protokolů SSL/TLS10 s pouţitím bezpečnostních certifikátů. B2B brána musí také zabezpečovat provoz v reţimu 24/7. Proto bude pouţit principu zapojení serveru do clusteru. B2B brána je realizována pomocí další instance Oracle Service Bus, kde jsou vyuţity především schopnosti pro zabezpečenou komunikaci. V rámci komunikace s externími partnery není podporovanou JMS komunikace a tudíţ ji není nutné instalovat na aplikačních serverech Weblogic. Sluţby zde vystavené jsou jednoduché tzv. průtokové bez jakékoliv logiky. BPM – jedná se o systém, pomocí kterého lze navrhovat, provozovat, monitorovat a analyzovat procesy na bázi standardu pro oblast podnikových procesů. Ţivotní cyklus BPM sestává ze čtyř cyklicky opakovaných kroků – modelování, vykonávání, monitorování a vylepšování. BPM

systém je realizován prostřednictvím produktů Oracle BPEL Process Manager.

BPEL-PM je nativní implementací BPEL standardu, který nabízí grafický editor pro práci s BPEL procesy a škálovatelné, vysoce dostupné provozní prostředí. Prostředí umoţnuje také

10

SSL – Secure Sockets Layer, TLS – Transport Layer Security je následovníkem SSL.

- 53 -

ucelený monitoring jednotlivých spuštěných procesů, dále jejich vyhodnocování a následný debuging. Hlavním cílem, který tento systém v našem objednávkovém procesu plní je dekompozice objednávky zaslané frondent systémem na sadu seřazených úkolů (tasků). Formát objednávky je XML zpráva v předem definované struktuře. Sloţitost struktury objednávky je závislá podle toho, z jakého systému přijde. CRM systém umoţnuje všechny moţné operace s objednávkou, kdeţto ovládání účtu prostřednictvím SMS zprávy je minimální. Můţe zde tedy vzniknout jednoduchá sada tasků například při aktivaci roamingu aţ po sloţitou strukturu při změně tarifu spojenou se změnou vlastníka telefonního účtu.

Druhou a také velmi

důleţitou funkčností je orchestrace úkolů (tasků) vytvořených v dekompozici. V principu se pod provedením jednotlivých tasků na BPM serveru jedná o provolání sluţeb vystavených na service busu, který je následně přetransformuje do srozumitelného formátu backendu. Repository - jedná se o úloţiště metadat, které neustále udrţuje konzistenci jednotlivých vazeb operací a sluţeb. Veškeré sluţby, a to jak ve vývojovém, testovacím, tak i v provozním prostředí musí být dokumentovány v repository. Tato repository obsahuje metadata rozhraní sluţeb, formální popis, kříţové reference, příslušné verze a další uţitečné informace potřebné pro vývoj, nasazení a správu sluţeb. Provoz repository není z pohledu kritičnosti zcela zásadní, a proto postačuje reţim 8/5 (tedy dostupnost v pracovní dobu) a instalace bude provedena na jeden samostatný server (nebude vyuţit princip clusteru). Systém repository je realizován produktem Oracle Enterprise Repository z katergorie Governance SOA. Business monitorovací konsole – při budování řešení v rámci integrace IT systémů jsou kladeny vysoké nároky na moţnost monitorování jednotlivých části zpracování business procesů. V sadě produktů Oracle Fusion Middleware je k tomu určený produkt Oracle Business Activity Monitoring (BAM). Nicméně v současném řešení z důvodu finančních nákladu na BAM byla pouţita jiná technologie a doprogramována funkcionalita odpovídající přímo procesům telefonního operátora. Byl pouţit také produkt firmy Oracle v podobě aplikace Application Express (APEX), který není součástí balíku Oracle Fusion Middleware.

- 54 -

3.4. Implementace V rámci kapitol implementace jsem se zaměřil na části vyuţívající Oracle Service Bus, a to jak v podobě interní podnikové sběrnice, tak v podobě B2B brány. Při implementaci jsem vyuţil znalosti načerpané předchozí integrační vrstvou postavenou na principech Integračního Brokeru, jenţ byla vytvořena vlastními silami za pomocí technologie J2EE a vyuţívající pro svůj běh aplikačního serveru BEA Weblogic. Dále zde ukáţu vyuţití aplikace Oracle Enterprise Repository. Produkt Oracle BPEL Process Manager nebude v rámci implementace zmiňován ani vyuţit, neboť zatím nedošlo k realizaci a proces funguje s existující aplikací. Nebudu zde zmiňovat ani monitorovací konsoly, která sice byla vytvořena, ale nevyuţívá produkt ze sady Oracle Fusion Middleware.

3.4.1. OSB - Oracle service bus Koncept OSB zavádí nový způsob interakce mezi poskytovateli a konzumenty sluţeb. Aktéři spolu jiţ nekomunikují přímo, ale výhradně prostřednictvím sběrnice sluţeb. Nové sluţby jsou zapojeny do sběrnice a mohou být snadno integrovány s jiţ existujícími sluţbami bez nutnosti zásahu do programového kódu či logiky existujících aplikací. OSB sama přímo poskytuje nemalou mnoţinu adapterů (v terminologii OSB se jedná o transporty), jenţ právě zajištují komunikaci různých platforem. Přehled jednotlivých komponent OSB je zachycen na následujícím obrázku.

- 55 -

Obrázek č. 19: Architektura Oracle Service Bus

Zdroj: Introduction to the Oracle Service Bus Tutorials. [online]. 2010 [cit. 2012-03-12], Dostupný z WWW:

OSB pro svoje fungování potřebuje aplikační Weblogic server (aplikace Oracle Fusion Middleware z katerorie Application Grid), nad jehoţ principy jsem se zastavil v kapitole 3.3.2 Návrh integrační infrastruktury. Technická realizace sluţby v prostředí Oracle service bus je zaloţená na principu skládání jednotlivých funkčních bloků do výsledného procesního toku (flow). Na obrázku se jedná o část Message Brokeing. Pro modelování jednotlivých flow jsou k dispozici dva moţné nástroje ze sady Oracle Fusion Middleware, a to v podobě JDeveloperu, Enterprise Packu pro Eclipse. Další a nejjednoduší moţnost modelování flow, přímo prostřednictvím internetového prohlíţeče. Já jsem vyuţil moţnost prostředí eclipse a jednoduché změny jsem prováděl prostřednictvím prohlíţeče. Primárně pro své fungování je OSB zaloţena na vyuţití formátu XML, coţ je také primární nativní datový typ, nicméně lze pouţít pro zpracování i alternativní datové typy. Základní funkcionalita spočívá v poskytování inteligentního brokeru (zprostředkovatele) mezi business service (coţ je představitel backend sluţby) a proxy service (coţ je reprezentant klienta) za vyuţití dalších prostředků v podobě resources. Přehled jednotlivých resources je v následující tabulce. - 56 -

Tabulka č. 1: Přehled jednotlivých prostředků pro tvorbu sluţeb Typ prostředku Service Proxy Service Business Service Interface

Význam

WSDL

Soubor popisující rozhraní webové sluţby.

XML Schema

Soubor s definicí XML schématu.

WS-policy

Soubor s definicí pravidel pro chování sluţeb.

Transformation XQuery XSLT

Soubor s Xquery transformaci. Soubor s XSLT transformaci.

MFL File

Definice proxy sluţby. Definice business sluţby.

Soubor s formátem jazyka (MFL), který je BEA proprietární jazyk pro popis rozloţení binárních dat a definuje pravidla pro transformaci binárních dat v zadávaných údajích.

Security Service Account

Soubor obsahující account pro komunikaci s externím systémem.

Proxy Service Provider

Soubor obsahuje PKI pověření pro zabezpečenou komunikaci.

Utility JAR

JAR (Java ARchive) je ZIP soubor, který obsahuje sadu tříd Java, jenţ poskytují moţnost další funkčnosti.

Alert Destinations

Soubor obsahuje list s příjemcemi notifikaci.

MQ Connection

Soubor MQ Connection poskytuje parametry připojení potřebné pro připojení ke správci fronty MQ. Jinak samozřejmě funguje připojení na nativní JMS server. Zdroj: vlastní

Proxy service – v proxy service je nadefinováno chování logiky procesního toku zprávy. Tato logika zahrnuje takové činnosti jako transformace, validování, reporting, směrování toků podle definovaných pravidel. Toto vše je implementované v blokách nesoucí označení stage a poskládaných do sekvencí, které jsou označené názvem pipeline, rozdělené do Request

- 57 -

Pipeline a Response Pipeline. Přehled jednotlivých funkčních bloků je sepsán v příloze 3. Příloha 1 pak ukazuje příklad proxy service. Business service - definice business sluţby je podobná proxy sluţbě, jen bez definice flow. De facto se jedná o definici backend sluţby se kterou si chceme vyměňovat zprávy. Při konfiguraci business sluţby se zadává specifikace rozhraní, typ transportu pouţitého pro komunikaci, bezpečnostní poţadavky a další parametry pro specifikující zvláštnosti komunikace.

3.4.1.1. Vytvoření implementačních konvencí Service bus nepředpisuje striktně ţádné jmenné konvence ani hierarchii uspořádání souborů pro vytvořené sluţby, coţ dává značnou variabilitu. Sluţby vytvářené v objednávkovém procesu se skládají z proxy service, business service a také musejí obsahovat XSD a WSDL schémata, které slouţí k definici formátu zpráv a následné validaci správnosti zpráv. Nicméně po namodelování několika prvních sluţeb se ukázalo, ţe je nutné zavést jasná pravidla, aby s příchodem dalších nových sluţeb nemohlo dojít ke zhoršení orientace v souborech sluţeb. Proto byla navrţena jasná adresářová struktura a vzory (patterny) pro pojmenování, jak celých souborů zdrojů (resource), tak jednotlivých bloků namodelovaných v procesu proxy service. Na projektu se nám osvědčila následující navrţená stromová struktura. Obrázek č. 20: Navrţená adresářová struktura

Zdroj: vlastní

První úroveň pro proxy service označuje jméno sluţby. V další úrovni je identifikována verze sluţby. Z historických důvodů můţe existovat více verzí (jedná se o případy, kdy se starý systém nemůţe přepnout na novou verzi). V další úrovni jsou pak jiţ následují adresáře, které obsahují jednotlivé druhy různých zdrojů (Proxy service, WSDL, XSD, XQuery).

- 58 -

Pro business service je struktura podobná, ale před jménem v kořenovém adresáři je definován ještě systém (na obrázku se jedná o systém RMS) a zbytek je podobný jako v proxy service. Výhodou takovéhoto rozdělení je přehlednost a velká moţnost znovupouţitelnosti jednotlivých proxy a business service, neboť základní nejmenší jednotkou pro jednotlivé implementace a následný release je větev od kořene ke konci listu (z obrázku např. pouze vše co je pod úrovní RMS_UseResource). Jmenná konvence pro infrastrukturu: JMS queue: esb.2.queue. Databázový datasource: <systém> Jmenná konvence: Proxy service:

<systém>__

Business service:

bs_<systém>__

Parametry: zdrojový_systém – systém jenţ ukládá zprávy do JMS. cílový_systém – systém jenţ vyčítá zprávy. typ_poţadavku – typ poţadavku. Jsou dvě varianty a to request nebo response. systém – identifikace systému (v případě proxy je uveden pouze u technologické proxy která vyuţívá JMS komunikaci a tam přestavuje klientský systém. V případě business service představuje systém, který se bude volat). operace - jméno prováděné operace. technologie – pouţitá technologie. Přehled připon je uveden v tabulce. Přiklady: JMS queue: esb.esb2mnp.queue.request datasource: BSCS-BILLING proxy service: OrderingGatewayManagement_WS business service: bs_RMS_ChangeDealer_JMS

- 59 -

Tabulka č. 2: Návrh přehledu přípon Technologie

Přípona

Java Messaging Service

_JMS

Web Service E-Mail transport File transport Local transport WebSphere MQ

_WS _Mail _File _Local _MQ

IBWLI Transport (RMI)

_IBWLI

DB Transport

_DBT

Reverse DB Transport

_DBT

IBTUX Transport

_IBTUX Zdroj: vlastní

3.4.1.2. Základní struktura proxy a business servis Jelikoţ vyuţití OSB není pouze pro objednávkový proces, ale bude vystavovat sluţby pro široké spektrum oblastí (např. sluţby pro objednávkový proces, sluţby pro logistiku, sluţby pro procesy HR, sluţby pro trouble ticketing atd.) bylo zde nutné vymyslet základní strukturu a principy pro paralelní vývoj a hlavně bezproblémové instalování (release) jednotlivých funkcionalit do produkčních prostředí podle toho jak bylo poţadováno v jednotlivých příchozích poţadavcích na změnu (RFC -Request for Change). K tomuto rozdělení nedošlo hned při namodelování prvních sluţeb, ale bylo navrţeno aţ po nasbírání určitých zkušeností s modelováním sluţeb. Základní princip spočívá ve striktním oddělení technologických částí od procesních funkcionalit a je zachyceno na následujícím obrázku.

- 60 -

Obrázek č. 21: Návrh pouţití proxy a business service

Zdroj: vlastní

Technologická proxy service – účelem proxy sluţby v našem procesu je zajistit vystavení sluţby pro různé klienty, kteří pouţívají pro komunikaci rozdílných technologií. Sluţba tedy neposkytuje ţádnou speciální logiku pouze provede základní operace v podobě logování do Journalingu11, validování zprávy a ověření zda-li sluţbu volá odpovídající klient. Příkladem můţe být klient, který komunikuje pouze pomocí technologie webových sluţeb a druhý klient pouze pomocí technologie Java RMI, ale oba potřebují zavolat stejnou funkcionalitu. Samozřejmě je moţné vytvořit speciální sluţbu pro kaţdého klienta zvlášť, nicméně hned při první změně chování této sluţby budeme muset tuto logiku opravovat dvakrát coţ je pracné a přináší moţnost zanesení chyb. Proto byla maximální snaha oddělit logiku od technologie. Technologická proxy sluţba volá vţdy jenom jednu lokální proxy sluţbu. Základní vytvořená struktura pro objednávkový proces je sloţena z následujících navrţených bloků (v terminologii OSB pojmenovaných Stage): Init Variables - v bloku se definují proměnné pro daný proces Jornaling Start - v tomto bloku se zavolá naprogramovaný java kód, který zabezpečí uloţení zprávy do tabulky s dalšími zadanými parametry. Zde uloţené záznamy se následně skládají v aplikaci business monitoring konsole do sekvenčních diagramů zobrazující obchodní proces. Validation - blok ve kterém se validuje příchozí zpráva oproti XSD schématu. 11

Journaling – jedná se o funkcionalitu zabezpečují ukládání jednotlivých zpráv pro účel monitorovní. S těmito daty pracuje Business monitorovací konsole.

- 61 -

Error Handler – celý funkční blok je ohraničen blokem error handler. Pokud nastane chyba v procesu, tak je vyvolán právě tento chybový blok. Chybový blok je vyvolán i pokud nastane chyba v lokální proxy service. Dalším důleţitým úkolem je technologické přizpůsobení chybové odpovědi. Pro JMS technologii se vytvoří error zpráva, která se vloţí do response jms fronty, ale pro chybovou odpověď webové sluţby je technologická proxy transformována do typu SOAP Fault odpovědi. Příklad flow technologické proxy je zobrazena v příloze 1. Lokální proxy service – primárním cílem je zde vytvoření logiky sluţby a oddělení části závislých na technologii. Komunikace lokální a technologické proxy je zajištěna proprietárním lokálním protokolem, kde nevzniká ţádné zpomalení. Lokální proxy sluţba je tedy primárně zodpovědná za provedení logiky sluţby. Mezi hlavní činnosti se řadí různé transformace, cykly procházející XML zprávy, směrování a moţnost skládání do kompozitních sluţeb. Coţ znamená, ţe jedna lokální sluţba můţe volat neomezený počet dalších lokálních sluţeb anebo přímo volat zase neurčitý počet business sluţeb a z jejich výsledků následně poskládat výslednou odpověď. Init Variables - v bloku se definují proměnné pro daný proces RequestTransform – tento typ bloku se můţe několikrát opakovat podle toho kolik backend systémů se bude volat. A zabezpečuje transformaci vstupní zprávy na zprávu, které rozumí backend. Pro transformace se primárně pouţívají jazyky Xquery a XSLT. Call – v tomto typu bloku je provedeno synchronní volání business service. Volání je provedeno pomocí OSB funkce Service Callout to. Výhodou tohoto volání je, ţe jich můţe být v rámci proxy service provoláno několik po sobě oproti volání Route, ale nevýhoda je, ţe interně blokují thread, a proto při vysoké zátěţi můţou způsobit blokování interního java threadu. Coţ můţe způsobit v důsledku čekání nějakého jiného volání. Route – tento typ bloku slouţí pro volání business service a lze ji zavolat pouze jednou, a to na konci procesu. Funguje na principu request/response (popsáno v kapitole 2.1.2 Pravidla komunikace). Publish – tento blok slouţí podobně jako předchozí dva k zavolání business service vycházejícího z principu notifikace (popsáno v kapitole 2.1.2 Pravidla komunikace).

- 62 -

ResponseTransform – tento blok je pouţit při principu request/response a probíhá v něm transformace na response zprávu. Primárně se pouţívají jazyky Xquery a XSLT. Další bloky – jednotlivé procesy také potřebují specifickou funkcionalitu. Tyto bloky jsou specifické jednotlivým procesům. Error Handler – celý funkční blok je ohraničen blokem error handler. Pokud nastane chyba v procesu, tak je vyvolána právě tento chybový blok. V chybovém bloku se vytvoří předem definovaná chybová zpráva, která má pořád stejnou strukturu, akorát se mění obsah zprávy podle vyvolané chyby. Stejná struktura je velmi důleţitá, aby následně technologická proxy zprávě rozuměla a mohla transformovat zprávu do odpovědi klientovi. Příklad flow lokální proxy je zobrazena v příloze 1. Business service – nedefinuje ţádnou procesní logiku a v principu představuje rozhraní backendové sluţby. Konfigurují se zde komunikační parametry pro propojení s backend systémem, který sluţbu poskytuje. Mezi základní parametry se řadí např. adresa backend sluţby, protokol komunikace, zabezpečení, pokud nastane chyba komunikace tak nastavení opakování volání atd. V našem návrhu je pak business service moţné pouţít pro rozdílně procesní flow a tak je moţné dosáhnout znovupouţití (jeden za základních principů servisní architektury), coţ ve svém důsledku znamená ušetření práce, pokud například backend sytém bude přesunut na jinou IP adresu. Pak stačí změnit parametr konfigurace business service a není nutné vůbec zasahovat do logiky.

3.4.1.3. Dodatková funkcionalita a artefakty Během implementace vzniklo několik poţadavků, které přímo OSB nepodporuje anebo nejsou plně vyhovující pro naše řešení objednávkového systému. I přesto, ţe OSB nativně nepodporovala tyto poţadavky, tak na middleware patří. mapování zdrojových hodnot na cílové hodnoty – v podstatě jde o to, ţe některé systémy pouţívají jiné hodnoty, neţ jsou pouţívané v jiných systémech. K tomu došlo historickým vývojem systému. Například si lze pod tímto představit, ţe frontend CRM aplikace pouţívá pro nějaké produkty odlišné kódy neţ provisioning.

- 63 -

Proto vznikl malý java framework KMS (Key Mapping System), který provádí toto mapování. Základem je EJB komponenta se kterou komunikujeme z proxy service pomoci funkce javaCallout, která následně příkazem SELECT z databázových tabulek získá přemapovanou hodnotu. Pokud hodnota neexistuje, vrátí se chyba, která se zaloguje a podle typu komunikace se můţe upozornit klient sluţby. Komponenta KMS také umoţnuje přemapování více hodnot najednou. Schéma tabulek je na následujícím obrázku.

Obrázek č. 22: Relační model KMS

Zdroj: vlastní

MAPPING_INFO: tabulka slouţí pro mapování klíčového procesu nebo čísla zákazníka na jinou hodnotu 

MAPPINGID – primární klíč



KEYNAME – klíčové slovo, které můţe obsahovat identifikaci procesu nebo také referenční číslo zákazníka



SOURCESYSTEM – zdrojový systém



TARGETSYSTEM – cílový systém

MAPPING: tabulka pro mapování jednotlivých hodnot. Můţe existovat pro jeden systém a process/číslo zákazníka více mapovacích hodnot. 

MAPPINGID – klíč pro mapování na tabulku MAPPING_INFO



SOURCEVALUE – původní hodnota



TARGETVALUE – nová hodnota



VALID – flag zdali je mapování platné

- 64 -

Konfigurační cache – jelikoţ v OSB neexistuje jednoduchá moţnost jak pracovat s globálními proměnnými, které lze jednoduše dynamicky měnit, a zároveň jsou uloţené hodnoty přístupné všem procesům na všech nodech clusteru. Funguje zde podobný princip jako KMS komponentě. Data jsou uloţena v DB tabulce: Tabulka: ESB_CONFIGURATION 

ID – primární klíč



NAME – jméno hodnoty



VALUE – uloţená hodnota



DESCRIPTION – popis hodnoty



CREATED – vytvoření hodnoty



UPDATED – poslední změna hodnoty



VALID - flag zdali je hodnota platná

Konfigurační cache bude odhadem obsahovat počet hodnot v řádech desítek, coţ nezpůsobí problémy, aby data byla při startu serveru uloţena do datové struktury v paměti a nemusela kaţdou hodnotu vyhledávat v databázi, coţ by následně vše zpomalovalo.

- 65 -

Obrázek č. 23: Model komponent konfigurační cache

Zdroj: vlastní

3.4.2. B2B brána B2B brána je implementována také pomocí OSB, jak bylo rozhodnuto při tvorbě konceptuálního modelu. Nebude zde implementována ţádná zásadní logika ve sluţbách, ale půjde především o vyuţití nabízených moţností pro zabezpečenou komunikaci, jenţ OSB také nabízí ve velkém rozsahu. Zabezpečení komunikace je jak ve směru k externím partnerům tak i pro komunikaci do vnitřní sítě na podnikovou sběrnici (v našem případě se jedná také o OSB). Pro zabezpečenou komunikaci s externími partnery je nastavena two-way SSL - HTTPS komunikace. Pro nastavení zabezpečené komunikace je nutné provést konfigurační kroky jak na straně OSB tak i na straně aplikačního serveru Weblogic. Postup nastavení na straně Weblogic serveru: instalování klíče/certifikátu do keystore konfigurace keystoru na serveru weblogic (detailní obrazovky jsou vidět v příloze č. 2) Postup nastavení na straně OSB: - 66 -

vytvoření “service key providera”, který poskytuje informace o mapování java keystore se sluţbou. vytvoření zabezpečené proxy service Obrázek č. 24: Konfigurace proxy service pro SSL komunikaci

Zdroj: vlastní

vytvoření zabezpečené business service Obrázek č. 25: Konfigurace business service pro SSL komunikaci

Zdroj: vlastní

3.4.3. Repository Mezi často opomíjenou oblast při implementacích servisně orientované architektury je část SOA governance, která v zásadě znamená řízení sluţby v průběhu celého jejího ţivotního

- 67 -

cyklu. Počínaje návrhem a vývojem přes nasazení a provoz aţ po odstranění sluţby z pouţívání. Mezi základní úkoly SOA governance patří: Vývoj sluţby s maximálním důrazem na moţnost jejího znovupouţití (reuse) Kontrolované řízení změn vzhledem k tomu, ţe změna sluţby můţe mít zásadní dopady na mnoho klientů a navazující sluţby Zajištění kvality a výkonnosti sluţby (SLA) Implementace repository je zaloţena na produktu Oracle Enterprise Repository. Tento produkt poskytuje repository pro sdílení a výměnu metadat o sluţbách mezi spotřebiteli a poskytovateli sluţeb v celém ţivotním cyklu. Principy Oracle Enterprise Repository jsou zaloţeny na asset managementu, coţ zde představuje řízení a správu sluţeb. Struktura Oracle Enterprise Repository je organizována jako assety a zaloţena na principech podle specifikace OMG RAS12. Pro vyuţití v rámci integrační vrstvy se ukázalo jako nejvýhodnější toto rozvrţení assetů: solution – tento asset představuje samostatný řešený IT projekt nebo RFC aktivity, během něhoţ jsou vytvořeny architektura i implementace. service – asset obsahuje jednotlivé sluţby (např. createOrder). system – obsahuje informace o systému. Systém můţe být v roli poskytovatele či spotřebitele sluţby (např. CRM, billing, atd.). process – tento typ assetů poskytuje informace o vyšších kompozitních jako je proces. pattern – poskytuje moţnost přiloţení dokumentů s ověřenými principy a pouţitými vzory (patterny) pro specifická řešení (např. CRM Integration Patterns). project – představuje propojení assetu solution se sluţebnami a identifikaci kdo je poskytovatel a spotřebitel. Vazba mezi assetem solution a assetem project je 1:1. Plnění těchto obsahu assetů je zajištěno automaticky pomocí API rozhraní v programovacím jazyce Java. Rozhraní je automaticky voláno v jednotlivých fázích vývoje sluţby. Jednotlivé fáze jsou představeny těmito stavy: design, development, testing, production a po zrušení sluţby je stav decommissioning. Obrázek č. 26: Ukázka dokumentovaných sluţeb v repository

12

Detailní popis specifikace je adrese http://www.omg.org/technology/documents/formal/ras.htm

- 68 -

Zdroj: vlastní

Na obrázku je ukázaná hlavní obrazovka repository. V levé časti obrazovky je funkcionalita na vyhledávání jednotlivých sluţeb. Je zde moţné zadat filtr podle různých kritérií jako je: typ assetu, jméno sluţby, systém, RFC. Pravá vrchní část obrazovky pak obsahuje jednotlivé vyfiltrované záznamy a k nim jsou zobrazeny dodatečné informace (verze, typ assetu, status). Pravá spodní část obrazovky zobrazuje jiţ samotný detail sluţby s mnoţstvím informací, jako jsou: popis, jednotlivé operace sluţby, jednotlivé parametry operace, systém poskytující sluţbu, systém konzumující sluţbu, seznam RFC v kterých je sluţba pouţita, end point sluţby, technologie, statistika znovupouţití a v neposlední řadě také sada příloh ve formě RTF dokumentů. Další velice přínosnou funkcionalitou je generování interakce jednotlivých systémů v podobě obrázků.

- 69 -

Obrázek č. 27: Obrázek interakcí mezi systémy

Zdroj: vlastní

3.4.4. Zhodnocení a doporučení Hlavním cílem praktického příkladu bylo ukázání vyuţití produktů Oracle Fusion Middleware v reálné praxi za pomocí servisně orientované architektury. V příkladu jsem vyuţil pouze malou část aplikací z celkového počtu celé sady. Coţ je dáno tím, ţe i jednotlivé aplikace jsou natolik rozsáhlé, ţe vysvětlení principů a pouţití není jednoduché. V rámci modelového příkladu byly navrhnuty a realizovány poţadavky na novou integrační vrstvu za pouţití produktů JRockit, Weblogic Server, Oracle Service Bus, Oracle Enterprise Repository ze sady Oracle Fusion Middleware. Zbývající systémy v navrhnutém řešení buď jiţ v produkčním prostředí existují, anebo nebyly doposud realizovány. V úvodu bych chtěl také zmínit důleţitou poznámku, ţe jednotlivá hodnocení se netýkají ceny produktů, která není malá a v mnoha případech hraje klíčovou roli. Nyní bych zhodnotil jednotlivé pouţité systémy: Oracle Weblogic – jako výhodu bych zde uvedl stabilitu serveru a jednoduchost základního instalovaní Weblogic serveru. Je právem označen jako světová jednička v oblasti aplikačních serverů. I kdyţ se mi v praxi potvrdilo, ţe je velice důleţité nepodcenit fázi přípravy a rozhodnout si co od serveru očekáváme a v jakém reţimu chceme, aby pracoval. Server disponuje velkou škálou pokročilých nastavení, kde je moţné se velice rychle ztratit. Jeden z mála negativních dojmů je v oblasti JMS, kde dochází k problémům s perzistencí při velkém objemu zátěţe.

- 70 -

Oracle Service Bus – jako velkou přednost této aplikace bych uvedl jednoduchost a rychlost s jakou lze vytvářet a modifikovat sluţby. Pro připojení existují aplikace do procesu za pomocí OSB trvala v řádu hodin, coţ dříve bylo mnohem pomalejší a sloţitější. Samozřejmě zde existuje také spousta nedokonalostí a funkčností, které mi zde scházely a musely být doplněny externími moduly (KMS, Konfigurační cache). Jednoduchost vytváření sluţeb a celkově jednoduchá moţnost propojení jednotlivých systémů přinesla vzrůstající počet sluţeb na OSB. A to způsobilo zpomalení při instalaci nových sluţeb na produkční prostředí OSB (řadově desítek minut). Problém je způsoben mnoţstvím interních kontrol při deploymentu a násobí se sloţitostí clusteru (toto bylo stanovisko firmy Oracle). Nicméně pokud odhlédnu od těchto problémů, tak service bus přinesl velké zjednodušení v integrování aplikací a celkově sníţil čas dodávky nové funkcionality. V současné době na OSB běţí i jiné sluţby neţ pro objednávkový proces a přenesou kolem 4 mil. zpráv denně. Oracle Enterprise Repository – implementace repository spočívala v instalaci samotného produkce, kde nevznikl ţádný výrazný problém. Menším problémem bylo pouze napojení na firemní LDAP servery, coţ se nakonec úspěšně podařilo. Podstatnější práci znamenalo vymyšlení ukládání informací do assetu. Repository ve svém konečném důsledku přináší uţitek nejenom lidem z integrace, ale je vyuţívána i lidmi z ostatních systémů a také oddělením architektury. JRockit – pouţití JRockitu se nám velice osvědčilo ve stabilitě serveru a také při samotném ladění JVM oproti Hotspotu. S JVM Hotspot ve firmě máme veliké zkušenosti, neboť jsme ho pouţívali do současné chvíle z důvodu neexistence verze JRockitu pro systém Solaris. Ještě bych chtěl připomenout, ţe ladění Java Virtual Machine není triviální a odpovídá individuálním specifickým podmínkám. Z provedených testů na OSB nebylo moţné dostat JRockit do stavu, kdy by začal psát vyjímky OutOfMemoryError, coţ jsme i při stejném zatíţení HotSpotu dosáhli a server se musel následně restartovat. JRockit při tomto stavu zpomalil, ale nedošlo k nutnosti restartu, zpomalení pominulo při sníţení zátěţe. Parametry testu: (100 paralelních dotazů o velikosti od 100KB do 15 MB po dobu 2 hodin, v podobě webových sluţeb tak i jms komunikace v OSB, v kaţdém flow byli pouţité paměťově náročné operace v podobě validací a transformací). Dalším znatelným rozdílem bylo v moţnostech nastavování parametrů JVM. JRockit nabízí velkou moţnost dynamicky měnit parametry garbage collectoru

oproti

HotSpotu, který se musí po změně restartovat. (Příklad parametrů: InitialHeapSize, - 71 -

MaxHeapSize, GCTrigger, GCTimeRatio). Mezi nevýhody JRockitu, které jsem v rámci implementace našel, byla nemoţnost rotování GC logu a pak nutnost licence pro nahrávání (recording) paměti delší neţ 10 minut. Z výše provedené implementace a následně i provozem v produkčním prostředí se ukazuje, ţe pouţité aplikace přinášejí výhodu ve zkrácení času potřebného pro vývoj nových sluţeb. Realizované řešení pomocí zmiňovaných produktů jiţ teď neslouţí pouze objednávkovému procesu, ale rozšířilo se i pro další procesy jako je logistika, procesy pro měření ADSL/VDSL linek, SAP procesy a další procesy. Zde významnou měrou přispěla moţnost znovupouţití existujících sluţeb. Nyní evidujeme okolo 35% znovupouţitelnosti jiţ vytvořených sluţeb v dalších procesech, coţ v praxi znamená podstatné ušetření času a peněz na programování. Jako jeden z vedlejších efektů OSB se ukázala moţnost rychlého zásahu při nehodách na backend systémech, kde konfiguračním zásahem na OSB lze přesměrovat business flow na jiný fungující server anebo zpomalit proces a zamezit tak přetíţení backend systému, jenţ by brzy zkolaboval. Pomocí produktu Oracle Enterprise Repository se zamezilo rozšiřování existujícího chaosu v rámci dokumentování jednotlivých propojení systémů. Nespornou výhodu vidím také v tom, ţe systémy poskytuje stejná společnost, čímţ vzniklé problémy při propojování jednotlivých aplikací řešíme pouze v rámci jedné firmy. Drobné problémy, které jsem popsal u jednotlivých produktů nebyly nijak zásadní, nicméně si myslím, ţe stěţejním aspektem při rozhodování o pouţití produktů firmy Oracle bude aspekt finanční. Proto v konečném důsledku po produktech sáhnou spíše velké společnosti, kterým se investice vyplatí.

- 72 -

Závěr Hlavním cílem této diplomové práce bylo ukázání pouţití produktů Oracle Fusion Middleware v reálném světě integračního oddělení u telekomunikační společnosti. V teoretické části diplomové práce jsem se nejdříve zaměřil na vysvětlení základních pojmů problematiky middlewaru. Dále se pak práce zabývala základními principy Oracle Fusion Middlewaru a rozdělením produktů do jednotlivých funkčních kategorií. Následující kapitola je pak věnována jiţ samotným produktům z jednotlivých kategorií. Jedním ze základů pro moţné vyuţití produktů je servisně orientovaná architektura, jejímţ základním principům jsem se věnoval v celé druhé kapitole. Výsledkem praktické části je návrh vyuţití několika produktů ze sady Oracle Fusion Middleware v integrační vrstvě pro fungování objednávkového procesu. V úvodu praktické části byly definovány poţadavky a cíle co by měla splnit nová integrační vrstva. V návaznosti na poţadavcích byla navrţena architektura a propojení jednotlivých systémů integrační vrstvy. Dále pak byla navrhnuta vrstva infrastruktury i s návrhem clustrového řešení pro robustní fungování aplikačního serveru, coţ je jakýsi základní kámen dobrého fungování middlewaru. Následně došlo k vyspecifikování pravidel a doporučení pro vývoj sluţeb na service busu, které prošly mnoha změnami během samotné implementace sluţeb. Důleţité přínosy a problémy jednotlivých pouţitých aplikací jsem shrnul v poslední kapitole v rámci implementace. Implementované řešení je vybudováno jenom na několika málo produktech Oracle Fusion Middleware (JRockit, Weblogic Server, Oracle Service Bus, Oracle Enterprise Repository, JDeveloper) z tak obrovské nabídky sady produktů. Navrhnuté řešení je v podobě service busu a repository provozováno v reálném provozu. Jistě by se daly uplatnit i další produkty z nabídky Oracle Fusion Middleware jako jsou například produkty kategorie Identity Management a produkty pro monitorování procesů zaloţených na produktu BAM. Tato práce je proto vhodným dokumentem pro společnosti, kteřé teprve plánují zavedení servisně orientované architektury s podporou produktů od společnosti Oracle.

- 73 -

Seznam použité literatury a zdrojů 1. BERNSTEIN, P. Middleware a model for distributed systém services. Communications of the ACM. 1996 2. DAVIES, J., aj. The Definitive Guide to SOA Oracle Service Bus 2nd Edition. APRESS, 2008 3. Enterprise Content Management with Oracle WebCenter [online]. 2011 [cit. 2011-12-01], Dostupný

z

WWW:


1373495.pdf> 4. ERL, T. Servisně orientovaná architektura SOA. Brno: Computer Press, 2009. 654s. ISBN 978-80-251-1886-3 5. GÁLA, L., POUR, J., ŠEDIVÁ, Z. Podniková informatika. 2.vyd. Praha: Grada, 2009. 496s. ISBN 978-80-247-2615-1 6. Hype Cycle for Business Process Management 2011 [online]. 2011 [cit. 2012-03-12], Dostupný z WWW: 7. Introduction to the Oracle Service Bus Tutorials [online]. 2010 [cit. 2012-03-12], Dostupný z WWW: 8. KHUDHUR, P. Business intelligence: Je třeba přemýšlet [online]. 2007 [cit. 2012-01-12], Dostupný z WWW: 9. KHUDHUR, P., MILLER R. Abeceda Enterprise 2.0 [online]. 2008 [cit. 2012-02-12], Dostupný z WWW: 10. KNAP, P. Orchestrace a choreografie sluţeb [online]. 2007 [cit. 2011-11-12], Dostupný z WWW: <www.cssi.cz/cssi/system/files/all/00knap.pdf> 11. KONDURI, G., LEE, S., SHAFFI, R. Oracle Fusion Middleware 11g Architecture and Management. Oracle Press, 2011

- 74 -

12. Lheureux, B., aj. Who's Who in Middleware, 1Q04 [online]. 2004 [cit. 2011-11-22], Dostupný z WWW: 13. Oracle data integrátor. ORACLE, 2009 14. Oracle Fusion aplikace [online]. 2010 [cit. 2011-10-12], Dostupný z WWW: 15. Oracle Fusion Middleware Concepts Guide [online]. 2010 [cit. 2011-10-11], Dostupný z WWW: 16. Oracle Fusion Middleware Components [online]. 2010 [cit. 2011-10-12], Dostupný z WWW: 17. Oracle Identity Management 11g- WHITE PAPER 2010 [online] . 2010 [cit. 2012-01-12], Dostupný

z

WWW:


mgmt/overview/idm-tech-wp-11g-r1-128261.pdf> 18. PATOČKA, M. Oracle Coffee - Zvýšení výkonu aplikací s vyuţitím Oracle [online]. 2009 [cit. 2012-02-16], Dostupný z WWW: 19. PELTZ, Ch. "Web Services Orchestration and Choreography," Computer, srt. 46-52, October, 2003 20. Produktový katalog Oracle 2009. ORACLE, 2009 21. Produkty a technologie Oracle Application Grid [online]. 2010 [cit. 2012-02-16], Dostupný

z

WWW:
grid/index.html > 22. TIŠNOVSKÝ, P. Pohled pod kapotu JVM (popis virtuálního stroje Javy) [online] . 2012 [cit. 2012-03-16], Dostupný z WWW:

- 75 -

Seznam použitých zkratek B2B – Business-to-Business – obchodní vztahy, které se realizují mezi dvěma podniky . BAM (Business Activity Monitoring) – BAM zajišťuje sledování výkonnosti procesů v reálném čase. BPM (Business Process Management) – analýza a optimalizace procesního modelu. BPR (Business Process Reengineering) – reengineering podnikových procesů. CORBA (Commont Object Request Broker Architecture) – platformově nezávislá komponentová architektura. CRM (Customer Relationship Management) – řízení vztahů se zákazníky. ELT (Extract, Load and Transform) – proces extrakce dat ze zdrojových systémů. ESB (Enterprise Service Bus) – podniková sběrnice sluţeb, abstraktní vrstva provozovaná nad podnikovým messagingovým systémem slouţící k volnému propojení softwarových systémů. ICT (Information and Communication Technologies) – je označení pro informační a komunikační technologie. IS (Information System) – informační systém. IT (Information Technology) – informační technologie. ITG (IT Governance) – definovaná struktura vztahů a procesů, pomocí kterých lze řídit a kontrolovat organizaci. J2EE (Java 2nd Enterprise Edition) – platforma zaloţená na Javě pro aplikační servery.výměny zpráv mezi messagingovými klienty-aplikacemi. JMS (Java Message Service) – Java aplikační programové rozhraní pro systémy řízení výměny zpráv mezi messagingovými klienty-aplikacemi. MOM (Message Oriented Middleware) – systém řízení výměny zpráv, middleware pro komunikaci mezi messagingovými klienty/aplikacemi. RMI (Remote Method Invocation) – programové prostředky volání vzdálených procedur. SOA (Service Oriented Architecture) – Architektura orientovaná na sluţby. SOAP (Simple Object Access Protocol) – protokol pro výměnu XML zpráv, typickys vyuţitím HTTP/HTTPS a WSDL. SaaS (Software as a Service) – software jako sluţba. UDDI (Universal Description, Discovery and Integration) – platformově nezávislé úloţiště sluţeb a metadat slouţící pro jejich ukládání, popis a vyhledávání.

- 76 -

UML (Unified Modeling Language) – standardní jazyk pro vytváření modelů obchodních a technických systémů. WSDL (Web Services Description Language) – XML jazyk poskytující model pro popis webových sluţeb a jejich operací. WS-BPEL (Web Services Business Process Execution Language) – jazyk pro popis podnikových procesů zaloţených na WSDL sluţbách. WS-CDL (Web Services Choreography Description Language) – jazyk pro popis koncepce choreografie. WS-I (Web Services Interoperability Organization) – organizace pro interoperabilitu webových sluţeb. XML (Extensible Markup Language) – rozšířitelný značkovací jazyk pro všeobecné pouţití. XSD (XML Schema Definition) – jazyk pro definici XML schématu

- 77 -

Seznam obrázků Obrázek č. 1: Kroky agilní strategie .......................................................................................... 9 Obrázek č. 2: Taxonomie funkcionality Middleware .............................................................. 13 Obrázek č. 3: Architektura middleware ................................................................................... 16 Obrázek č. 4: Produkty Fusion Middleware ............................................................................ 18 Obrázek č. 5: Vrstvy Application Gridu .................................................................................. 20 Obrázek č. 6: Service Oriented Security v prostředí Oracle Fusion Middleware ................... 23 Obrázek č. 7: Oracle Directory Services ................................................................................. 23 Obrázek č. 8: Ţivotní cyklus dokumentu................................................................................. 29 Obrázek č. 9: Přehled komponent Business Intelligence ........................................................ 30 Obrázek č. 10: High-level architektura Oracle Fusion Middleware ........................................ 34 Obrázek č. 11: Referenční model SOA ................................................................................... 37 Obrázek č. 12: Hype křivka 2010 firmy Gartner ..................................................................... 38 Obrázek č. 13: Komunikační vzory ......................................................................................... 40 Obrázek č. 14: Porovnání orchestrace oproti choreografii ...................................................... 42 Obrázek č. 15: Struktura Enterprise Service Bus .................................................................... 43 Obrázek č. 16: Diagram systémů objednávkového procesu .................................................... 46 Obrázek č. 17: Návrh řešení clusteru....................................................................................... 50 Obrázek č. 18: Konceptuální model jednotlivých systému integrace ..................................... 52 Obrázek č. 19: Architektura Oracle Service Bus ..................................................................... 56 Obrázek č. 20: Navrţená adresářová struktura ........................................................................ 58 Obrázek č. 21: Návrh pouţití proxy a business service ........................................................... 61 Obrázek č. 22: Relační model KMS ........................................................................................ 64 Obrázek č. 23: Model komponent konfigurační cache ............................................................ 66

- 78 -

Obrázek č. 24: Konfigurace proxy service pro SSL komunikaci ............................................ 67 Obrázek č. 25: Konfigurace business service pro SSL komunikaci ........................................ 67 Obrázek č. 26: Ukázka dokumentovaných sluţeb v repository............................................... 68 Obrázek č. 27: Obrázek interakcí mezi systémy ..................................................................... 70

Seznam tabulek Tabulka č. 1: Přehled jednotlivých prostředků pro tvorbu sluţeb

57

Tabulka č. 2: Návrh přehledu přípon

60

- 79 -

Příloha č. 1 Struktura základních proxy service Technologická proxy service:

- 80 -

Lokální proxy service:

- 81 -

Příloha č. 2 Konfigurace zabezpečení v aplikačním serveru weblogic Nastavením keystoru na aplikačním serveru weblogic:

Nastavením SSL komunikace na aplikačním serveru weblogic:

- 82 -

Příloha č. 3 Funkční akce proxy service Akce pro řízení komunikace: Akce

Význam

Použití Pipeline stage, Error

Dynamic

Dynamické

publikování

publish

definované Xquery výrazem

zprávy

do

sluţby handler stage, Route node Pipeline stage, Error

Publish

Publikování zprávy do staticky definované sluţby

handler stage Pipeline stage, Error

Publish table Publikování zprávy do více sluţeb

handler stage

Nastavení některé vlastnosti odchozího volání Routing

(URI, Quality of Service, počet opakování, priorita

options

zprávy)

Pipeline stage

Service callout

Pipeline stage, Error Synchronní volání sluţby

handler stage

Transport headers

Pipeline stage, Error Nastavení hodnoty v hlavičce zprávy

handler stage

Akce na řizení toku: Akce

Význam

Použití Pipeline stage, Error

For each

Cyklus for each

handler stage Pipeline stage, Route

Podmíněný přikaz, na základě logického výsledku node, Error handler If... then...

výrazu v XQuery

stage

- 83 -

Vyvolání výjimky s definovaným kódem chyby a Pipeline stage, Error Raise error

popisem

handler stage Pipeline stage, Error

Reply

Přerušení flow a okamţitá odpověď klientovi

handler stage

Pokračovat ve flow po zpracované chybě v error Resume

handleru

Error handler stage

Ukončení probíhající akce ve stage a pokračování Pipeline stage, Error Skip

další funkcionalitou v následujícím stage

handler stage

Akce pro práci s obsahem: Akce

Význam

Použití

Přiřazení výsledku XQuery výrazu do kontextové Pipeline stage, Error Assign

proměnné

handler stage

Odstranění kontextové proměnné nebo sady uzlů Pipeline stage, Error Delete

specifikovaných Xpath výrazem

handler stage

Vloţení výsledku Xquery výrazu do nodu, který je Pipeline stage, Error Insert

vybraný Xpath výrazem

handler stage Pipeline stage, Error

Java callout

Vyvolání Java metody nebo EJB business service

handler stage

MFL

Transformace obsahu zprávy z XML na non-XML a Pipeline stage, Error

transform

naopak

handler stage

Přejmenování prvku nebo kontextu specifikované Pipeline stage, Error Rename

Xpath výrazem

handler stage

Nahrazení uzlu nebo části uzlu vybrané Xpath Pipeline stage, Error Replace

výrazem

handler stage

Validace elementu zprávy vybrané Xpath výrazem Pipeline stage, Error Validate oproti XSD schématu nebo WSDL

- 84 -

handler stage

Reportovací akce: Akce

Význam

Použití Pipeline stage, Error

Alert

Odeslání notifikační zprávy

handler stage Pipeline stage, Error

Log

Vytvoření zprávy pro logování

handler stage Pipeline stage, Error

Report

Povolení reportingu

handler stage

- 85 -