Využití technologie Oracle Fusion v integraci IS

Rozměr: px
Začít zobrazení ze stránky:

Download "Využití technologie Oracle Fusion v integraci IS"

Transkript

1 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: Ing. Michal Valenta, Ph.D. Praha Duben, 2012

2 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

3 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.

4 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

5 OBSAH: ÚVOD... 7 ZVOLENÉ METODY ZPRACOVÁNÍ PRODUKTY ORACLE FUSION Middleware Middleware v podání Oracle Komponenty Oracle Fusion Middleware Vývojové prostředí a frameworky Application Grid Data Integration Identity Management Service Oriented Architecture Governance SOA Content Management Business Intelligence (BI) User interaction PRINCIPY A ARCHITEKTURA PRO POUŽITÍ MIDDLEWARE Servisně orientovaná architektura Principy SOA Pravidla komunikace Kompozice sluţeb Enterprise Service Bus MODELOVÝ PŘÍKLAD - OBJEDNÁVKOVÝ PROCES Poţadavky a cíle Analýza poţadavků Architektura a komponenty Klíčové systémy procesu Návrh integrační infrastruktury Konceptuální model integrační vrstvy Implementace OSB - Oracle service bus Vytvoření implementačních konvencí Základní struktura proxy a business servis

6 Dodatková funkcionalita a artefakty B2B brána Repository Zhodnocení a doporučení ZÁVĚR SEZNAM POUŽITÉ LITERATURY A ZDROJŮ SEZNAM POUŽITÝCH ZKRATEK SEZNAM OBRÁZKŮ SEZNAM TABULEK

7 Ú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

8 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

9 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, s. ISBN 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 -

10 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

11 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ší

12 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) 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

13 Obrázek č. 2: Taxonomie funkcionality Middleware Zdroj: Lheureux, B., aj. Who's Who in Middleware, 1Q04 [online] [cit ], Dostupný z WWW: < 01.ibm.com/software/info/websphere/partners4/articles/gartner/garwho.html#fig2> 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

14 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

15 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

16 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 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] [cit ], 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ý

17 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

18 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

19 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 Eclipse 1 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 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 2 Eclipse je open source vývojová platforma. 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ářů

20 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] [cit ], 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]

21 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ěţ 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,

22 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] 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í

23 Obrázek č. 6: Service Oriented Security v prostředí Oracle Fusion Middleware Zdroj: Oracle Identity Management 11g- WHITE PAPER 2010 [online] [cit ], 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] [cit ], 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)

24 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ů (SAML 4, 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

25 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]

26 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

27 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] 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]

28 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] 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, y, 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

29 Obrázek č. 8: Ţivotní cyklus dokumentu Zdroj: Enterprise Content Management with Oracle WebCenter [online] [cit ], 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

30 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 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] [cit ], 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

31 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]

32 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] 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 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 AJAXu 6 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)

33 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

34 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] [cit ], Dostupný z WWW: <

35 2.1. Servisně orientovaná architektura 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ů

36 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

37 Obrázek č. 11: Referenční model SOA Zdroj: ERL, T. Servisně orientovaná architektura SOA. Brno: Computer Press, s. ISBN 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

38 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

39 Zdroj: Hype Cycle for Business Process Management, [online] [cit ], Dostupný z WWW: < > 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

40 Obrázek č. 13: Komunikační vzory Zdroj: GÁLA, L., POUR, J., ŠEDIVÁ, Z. Podniková informatika. 2.vyd. Praha: Grada, s. ISBN 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

41 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

42 Obrázek č. 14: Porovnání orchestrace oproti choreografii Zdroj: ERL, T. Servisně orientovaná architektura SOA. Brno: Computer Press, s. ISBN 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

43 Obrázek č. 15: Struktura Enterprise Service Bus Zdroj: ERL, T. Servisně orientovaná architektura SOA. Brno: Computer Press, s. ISBN 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

44 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 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 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ţitelnost 7 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

45 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 Architektura a komponenty 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

46 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.)

47 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 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ů,

48 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 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

49 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)

50 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

51 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/TLS 8 komunikaci a moţnosti autentizace přistupujících partnerů 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 (throttling 9 ) 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

52 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 v billingu. V podstatě jde o

53 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/TLS 10 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

54 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

55 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 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

56 Obrázek č. 19: Architektura Oracle Service Bus Zdroj: Introduction to the Oracle Service Bus Tutorials. [online] [cit ], 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 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

57 Tabulka č. 1: Přehled jednotlivých prostředků pro tvorbu sluţeb Typ prostředku Service Proxy Service Business Service Interface WSDL XML Schema WS-policy Transformation XQuery XSLT MFL File Security Service Account Proxy Service Provider Utility JAR Alert Destinations MQ Connection Význam Definice proxy sluţby. Definice business sluţby. Soubor popisující rozhraní webové sluţby. Soubor s definicí XML schématu. Soubor s definicí pravidel pro chování sluţeb. Soubor s Xquery transformaci. Soubor s XSLT transformaci. 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. Soubor obsahující account pro komunikaci s externím systémem. Soubor obsahuje PKI pověření pro zabezpečenou komunikaci. JAR (Java ARchive) je ZIP soubor, který obsahuje sadu tříd Java, jenţ poskytují moţnost další funkčnosti. Soubor obsahuje list s příjemcemi notifikaci. 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

58 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 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)

59 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.<zdrojový_systém>2<cílový_systém>.queue.<typ_poţadavku> Databázový datasource: <systém> Jmenná konvence: Proxy service: <systém>_<operace>_<technologie> Business service: bs_<systém>_<operace>_<technologie> 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

60 Tabulka č. 2: Návrh přehledu přípon Technologie Java Messaging Service Web Service transport File transport Local transport WebSphere MQ IBWLI Transport (RMI) DB Transport Reverse DB Transport IBTUX Transport Přípona _JMS _WS _Mail _File _Local _MQ _IBWLI _DBT _DBT _IBTUX Zdroj: vlastní 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

61 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 Journalingu 11, 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

62 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 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 Pravidla komunikace)

63 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 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

64 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é

65 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

66 Obrázek č. 23: Model komponent konfigurační cache Zdroj: vlastní 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:

67 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í 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

68 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 RAS 12. 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

69 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ů

70 Obrázek č. 27: Obrázek interakcí mezi systémy Zdroj: vlastní 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

71 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,

72 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í

73 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

74 Seznam použité literatury a zdrojů 1. BERNSTEIN, P. Middleware a model for distributed systém services. Communications of the ACM DAVIES, J., aj. The Definitive Guide to SOA Oracle Service Bus 2nd Edition. APRESS, Enterprise Content Management with Oracle WebCenter [online] [cit ], Dostupný z WWW: < pdf> 4. ERL, T. Servisně orientovaná architektura SOA. Brno: Computer Press, s. ISBN GÁLA, L., POUR, J., ŠEDIVÁ, Z. Podniková informatika. 2.vyd. Praha: Grada, s. ISBN Hype Cycle for Business Process Management 2011 [online] [cit ], Dostupný z WWW: < > 7. Introduction to the Oracle Service Bus Tutorials [online] [cit ], Dostupný z WWW: < > 8. KHUDHUR, P. Business intelligence: Je třeba přemýšlet [online] [cit ], Dostupný z WWW:< 9. KHUDHUR, P., MILLER R. Abeceda Enterprise 2.0 [online] [cit ], Dostupný z WWW:< 10. KNAP, P. Orchestrace a choreografie sluţeb [online] [cit ], Dostupný z WWW: < 11. KONDURI, G., LEE, S., SHAFFI, R. Oracle Fusion Middleware 11g Architecture and Management. Oracle Press,

75 12. Lheureux, B., aj. Who's Who in Middleware, 1Q04 [online] [cit ], Dostupný z WWW: < 01.ibm.com/software/info/websphere/partners4/articles/gartner/garwho.html#fig2> 13. Oracle data integrátor. ORACLE, Oracle Fusion aplikace [online] [cit ], Dostupný z WWW: < > 15. Oracle Fusion Middleware Concepts Guide [online] [cit ], Dostupný z WWW: < 16. Oracle Fusion Middleware Components [online] [cit ], Dostupný z WWW: < 17. Oracle Identity Management 11g- WHITE PAPER 2010 [online] [cit ], Dostupný z WWW: < 18. PATOČKA, M. Oracle Coffee - Zvýšení výkonu aplikací s vyuţitím Oracle [online] [cit ], Dostupný z WWW: < _BACKPAGE:661,9 > 19. PELTZ, Ch. "Web Services Orchestration and Choreography," Computer, srt , October, Produktový katalog Oracle ORACLE, Produkty a technologie Oracle Application Grid [online] [cit ], Dostupný z WWW:< > 22. TIŠNOVSKÝ, P. Pohled pod kapotu JVM (popis virtuálního stroje Javy) [online] [cit ], Dostupný z WWW: <

76 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 2 nd 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í

77 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

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

79 Obrázek č. 24: Konfigurace proxy service pro SSL komunikaci Obrázek č. 25: Konfigurace business service pro SSL komunikaci Obrázek č. 26: Ukázka dokumentovaných sluţeb v repository Obrázek č. 27: Obrázek interakcí mezi systémy Seznam tabulek Tabulka č. 1: Přehled jednotlivých prostředků pro tvorbu sluţeb 57 Tabulka č. 2: Návrh přehledu přípon

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

81 Lokální proxy service:

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

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

Více

SOAP & REST služby. Rozdíly, architektury, použití

SOAP & REST služby. Rozdíly, architektury, použití SOAP & REST služby Rozdíly, architektury, použití Obsah Srovnání SOAP a REST služeb Service Oriented Architecture Microservice Architecture Příklady použití Nástroje pro vývoj SOAP a REST služeb (v Java)

Více

Elektronické dokumenty - jak efektivně na jejich správu a bezpečnost?

Elektronické dokumenty - jak efektivně na jejich správu a bezpečnost? 2008 aplis.cz, a.s. All rights reserved. 6.11.2007 Elektronické dokumenty - jak efektivně na jejich správu a bezpečnost? Ing. Jiří Bříza, CSc. 9.4.2008 str. 2 Informace pro úřad Informace a jejich zhmotnění

Více

1. Webové služby. K čemu slouží? 2. RPC Web Service. 3. SOA Web Service. 4. RESTful Web services

1. Webové služby. K čemu slouží? 2. RPC Web Service. 3. SOA Web Service. 4. RESTful Web services 13. Webové služby. K čemu slouží? Popis a vyhledávání služeb. Co je a k čemu slouží orchestrace a choreografie služeb. Technologie pro implementaci služeb 1. Webové služby. K čemu slouží? Definice WS -

Více

1. Integrační koncept

1. Integrační koncept Příloha č. 2: Technický popis integrace 1. Integrační koncept Z hlediska koncepčního budování Smart Administration na Magistrátu města Mostu je možno hovořit o potřebě integrace tří úrovní systémové architektury

Více

Správa a sledování SOA systémů v Oracle SOA Suite

Správa a sledování SOA systémů v Oracle SOA Suite Správa a sledování SOA systémů v Oracle SOA Suite Marek Rychlý Vysoké učení technické v Brně Fakulta informačních technologií Ústav informačních systémů Přednáška pro IOA 7. října 2014 Marek Rychlý Správa

Více

X33EJA Web Services. Martin Ptáček, KOMIX s.r.o.

X33EJA Web Services. Martin Ptáček, KOMIX s.r.o. X33EJA Web Services Martin Ptáček, KOMIX s.r.o. ptacek@komix.cz Copyright 2007 KOMIX Copyright s.r.o. 2007 KOMIX s.r.o. 1. Obsah Historie Co jsou Web Services? Co je to SOA? JAX-WS (Java API for XML Web

Více

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Aplikace IS, outsourcing, systémová integrace Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Kontext Dodavatelé Strategická Zákazníci ERP Taktická Operativní Kategorie ERP - zaměřeno na

Více

Vnořený Ensemble nové integrované aplikace. Martin Zubek, Account manager

Vnořený Ensemble nové integrované aplikace. Martin Zubek, Account manager Vnořený Ensemble nové integrované aplikace Martin Zubek, Account manager Nové užití známých technologií Vnořená integrace? Vnořená integrace a její typy Příklady Jak na to obchodně? Kdy použít? Spolupráce

Více

Vytvoření procesně integrační nástavby KUBIKI pro ERP systém MAX+

Vytvoření procesně integrační nástavby KUBIKI pro ERP systém MAX+ Vytvoření procesně integrační nástavby KUBIKI pro ERP systém MAX+ O společnosti IBA CZ Společnost IBA CZ je vývojovým centrem nadnárodní korporace IBA Group, které se specializuje na zakázkový vývoj software

Více

PODNIKOVÁ INFORMATIKA

PODNIKOVÁ INFORMATIKA GÁLA Libor POUR Jan TOMAN Prokop PODNIKOVÁ INFORMATIKA Obsah O autorech... 11 Na úvod jak chápat tuto knihu... 13 Část I: Principy podnikové informatiky... 17 1. Informatika, aplikovaná informatika, podniková

Více

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Aplikace IS, outsourcing, systémová integrace Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Kontext Dodavatelé Strategická Zákazníci ERP Taktická Operativní Kategorie ERP - zaměřeno na

Více

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

Koncept centrálního monitoringu a IP správy sítě

Koncept centrálního monitoringu a IP správy sítě Koncept centrálního monitoringu a IP správy sítě Implementace prostředí MoNet a AddNet Jindřich Šavel 31/5/2013 NOVICOM s.r.o. 2012 2013 Novicom All rights s.r.o. reserved. All rights reserved www.novicom.cz,

Více

Zvýšení kvality IA s využitím nových technologií: Představení řešení IDEA - SymSure pro CCM

Zvýšení kvality IA s využitím nových technologií: Představení řešení IDEA - SymSure pro CCM Jaromír Jiroudek Lukáš Mikeska J + Consult Ernst & Young Zvýšení kvality IA s využitím nových technologií: Představení řešení IDEA - SymSure pro CCM Náplň setkání 1. Rychlý úvod do CCM/CPM 2. Představení

Více

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka

Více

Architektury Informačních systémů. Jaroslav Žáček

Architektury Informačních systémů. Jaroslav Žáček Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

Centrální přístupový bod k informačním zdrojům resortu Ministerstva zemědělství Portál MZe a Portál eagri

Centrální přístupový bod k informačním zdrojům resortu Ministerstva zemědělství Portál MZe a Portál eagri Centrální přístupový bod k informačním zdrojům resortu Ministerstva zemědělství Portál MZe a Portál eagri Ing. Aleš Kopecký Ing. Martina Tomešová Telefónica O2 Czech Republic Agenda 1. Postup centralizace

Více

Požadavky pro výběrová řízení TerraBus ESB/G2x

Požadavky pro výběrová řízení TerraBus ESB/G2x Dokument: Převod dat TerraBus ESB/G2x Požadavky pro výběrová řízení TerraBus ESB/G2x Obsah 1. Účel dokumentu... 2 2. Použité termíny a zkratky... 2 3. Požadavky... 3 Účel dokumentu Účelem tohoto dokumentu

Více

Úvod do Web Services

Úvod do Web Services Úvod do Web Services Základy webových služeb a jejich implementace na platformě OS/2 Jarda Kačer jarda@kacer.biz Český Warpstock 2008 Brno, 20.-21.9.2008 Co je to webová služba? Část business logiky přístupná

Více

Komponentový návrh SW

Komponentový návrh SW Komponentový návrh SW Komponentový návrh SW Komponenty jsou kompletně specifikované pomocí interface Jejich funkčnost je nezávislá na programovacím jazyku a mohou být integrované do toho samého systému

Více

Zaměření Webové inženýrství doc. Ing. Tomáš Vitvar, Ph.D. Katedra softwarového inženýrství Fakulta informačních technologií České vysovké učení technické v Praze Den otevřených dveří 20.2.2014 http://www.fit.cvut.cz

Více

Architektura orientovaná na služby Návrh orientovaný na služby. Ing. Petr Weiss. VUT v Brně,, FIT, UIFS

Architektura orientovaná na služby Návrh orientovaný na služby. Ing. Petr Weiss. VUT v Brně,, FIT, UIFS Architektura orientovaná na služby Návrh orientovaný na služby Webové služby Ing. Petr Weiss VUT v Brně,, FIT, UIFS 3. 12. 2007 Obsah Architektura orientovaná na služby Základní pojmy Koncepce architektury

Více

Obsah Úvod 11 Jak být úspěšný Základy IT

Obsah Úvod 11 Jak být úspěšný Základy IT Obsah Úvod 11 Jak být úspěšný 13 Krok 0: Než začneme 13 Krok 1: Vybrat si dobře placenou oblast 14 Krok 2: Vytvořit si plán osobního rozvoje 15 Krok 3: Naplnit osobní rozvoj 16 Krok 4: Osvojit si důležité

Více

SOA a Cloud Computing

SOA a Cloud Computing 9.11.2011 Marriott hotel Praha SOA a Cloud Computing Jaroslav Novotný IT Architekt 1 Copyright 2011, Oracle and/or its affiliates. All rights SOA a Cloud Computing 2 Copyright 2011, Oracle and/or its affiliates.

Více

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS

Více

KIV/SI. Rozílová témata. Jan Valdman, Ph.D. jvaldman@dns.cz

KIV/SI. Rozílová témata. Jan Valdman, Ph.D. jvaldman@dns.cz KIV/SI Rozílová témata Jan Valdman, Ph.D. jvaldman@dns.cz 13.6.2011 Integrace Datová vrsta Přesouvání informací mezi DB Databová pumpa, SQL procedura... Problém: pouze relační integrita, záruka za aplikaci

Více

Chytrá systémová architektura jako základ Smart Administration

Chytrá systémová architektura jako základ Smart Administration Chytrá systémová architektura jako základ Smart Administration Ing. Petr Škvařil, Pardubický kraj Dipl. Ing.Zdeněk Havelka PhD. A-21 s.r.o. 1 Nepříjemné dotazy Jsme efektivní v provozování veřejné správy?

Více

Novell Identity Management. Jaromír Látal Datron, a.s.

Novell Identity Management. Jaromír Látal Datron, a.s. Novell Identity Management Jaromír Látal Datron, a.s. 19.4.2012 1 Identity management základní vlastnosti Jednoduché a rychlé poskytování uživatelských účtů Samoobslužné funkce pro uživatele Snadný návrh

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

Servisně orientovaná architektura Základ budování NGII

Servisně orientovaná architektura Základ budování NGII Servisně orientovaná architektura Základ budování NGII Jan Růžička Institute of geoinformatics VSB-TU Ostrava 17.listopadu, 70833 Ostrava-Poruba Poruba, jan.ruzicka@vsb.cz NGII NGII složitý propletenec,

Více

Úvod. Klíčové vlastnosti. Jednoduchá obsluha

Úvod. Klíčové vlastnosti. Jednoduchá obsluha REQUESTOR DATASHEET Úvod Requestor Service Desk poskytuje kompletní řešení pro správu interních i externích požadavků, které přicházejí do organizace libovolnou cestou. Produkt je zaměřen na vytvoření

Více

<Insert Picture Here> Jak garantovat bezpečnost systémů ve státní správě

<Insert Picture Here> Jak garantovat bezpečnost systémů ve státní správě 1 Jak garantovat bezpečnost systémů ve státní správě Tomáš Dvořáček Oracle Consulting Kvíz na začátek Čím se proslavil tento muž: Jménem Herve Falciani Autor bezpečnostního SW pro

Více

Snadný a efektivní přístup k informacím

Snadný a efektivní přístup k informacím Snadný a efektivní přístup k informacím 12. 4. 2010 Hradec Králové Petr Mlejnský Siemens Protection IT Solutions and Services, notice s.r.o.2010. / Copyright All rights notice reserved. Agenda Přístup

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

2012 (červen) Microsoft Sharepoint Portal Server. Microsoft Live Communications Server 2003 Řešení pro online komunikaci. Microsoft Exchange

2012 (červen) Microsoft Sharepoint Portal Server. Microsoft Live Communications Server 2003 Řešení pro online komunikaci. Microsoft Exchange 1989 1996 2001 2003 Microsoft Office Kancelářský balík Microsoft Exchange Emailové a groupwarové řešení Microsoft Sharepoint Portal Server Webová platforma pro spolupráci a správu obsahu Microsoft Live

Více

Využití identity managementu v prostředí veřejné správy

Využití identity managementu v prostředí veřejné správy Využití identity managementu v prostředí veřejné správy Tomáš Král Account Technology Strategist, Public Sector Microsoft ČR Realita dneška: Rostoucí počet provozovaných či používaných, často heterogenních

Více

Softwarové komponenty a Internet

Softwarové komponenty a Internet Softwarové komponenty a Internet Doc. Dr. Ing. Miroslav Beneš Katedra informatiky FEI VŠB-TU Ostrava Miroslav.Benes@vsb.cz Obsah přednášky Motivace Vývoj přístupů k tvorbě programů Definice komponenty

Více

Projektové řízení jako základ řízení organizace

Projektové řízení jako základ řízení organizace Projektové řízení jako základ řízení organizace Aleš Chudý, ředitel divize IW ales.chudy@microsoft.com Technický seminář Bratislava 6.10.2008 Obsah Potřeby byznysu a IT Řešení EPM Microsoft EPM Optimalizační

Více

Komponentní technologie

Komponentní technologie Komponentní technologie doc. Ing. Miroslav Beneš, Ph.D. katedra informatiky FEI VŠB-TUO A-1007 / 597 324 213 http://www.cs.vsb.cz/benes Miroslav.Benes@vsb.cz Obsah Motivace Aplikace v IT Vývoj přístupů

Více

Korporátní identita - nejcennější aktivum

Korporátní identita - nejcennější aktivum Korporátní identita - nejcennější aktivum Luděk Šafář Services Team Leader lsafar@novell.cz 03/13/2006 Standardní prostředí IT prostředí je diverzifikované a komplexní Administrativní činnosti jsou manuální

Více

ECM. Enterprise Content Management. čt 9:15 Petr Bouška (xboup00) Zbyněk Hostaš Lukáš Maršíček Martin Nikl (xnikm00)

ECM. Enterprise Content Management. čt 9:15 Petr Bouška (xboup00) Zbyněk Hostaš Lukáš Maršíček Martin Nikl (xnikm00) ECM Enterprise Content Management čt 9:15 Petr Bouška (xboup00) Zbyněk Hostaš Lukáš Maršíček Martin Nikl (xnikm00) Co nás čeká... Definice ECM Problém podnikového obsahu Historie vzniku ECM Architektura

Více

IBM Content Manager Collaboration Edition ECM služby pro IBM Lotus Quickr

IBM Content Manager Collaboration Edition ECM služby pro IBM Lotus Quickr IBM Content Manager Collaboration Edition ECM služby pro IBM Lotus Quickr 5/2010 IBM Content Manager Collaboration Edition O produktu IBM Content Manager Collaboration Edition IBM Content Manager Collaboration

Více

SAP PROCUREMENT DAY 2013. SAP CLM (Contract Lifecycle Management) Správa životního cyklu kontraktů. smooth business flow

SAP PROCUREMENT DAY 2013. SAP CLM (Contract Lifecycle Management) Správa životního cyklu kontraktů. smooth business flow smooth business flow SAP CLM (Contract Lifecycle Management) Správa životního cyklu kontraktů con4pas, s.r.o. Novodvorská 1010/14A, 140 00 Praha 4 tel.: +420 261 393 211, fax: +420 261 393 212 www.con4pas.cz

Více

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem

Více

Infor Performance management. Jakub Urbášek

Infor Performance management. Jakub Urbášek Infor Performance management Jakub Urbášek Agenda prezentace Stručně o produktu Infor PM 10 Komponenty Infor PM - PM OLAP a PM Office Plus Reporting Analýza Plánování / operativní plánování Infor Performance

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale je serverová aplikace určená pro efektivní zpracování velkého objemu sdílených nestrukturovaných dat. Umožňuje automaticky indexovat data z různých informačních zdrojů, intuitivně vyhledávat informace,

Více

Manažerský informační systém na MPSV. Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV

Manažerský informační systém na MPSV. Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV Manažerský informační systém na MPSV Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV Konference ISSS-2009 Hradec Králové Aldis 6. dubna 2009 MIS na MPSV časové údaje projektu Vytvoření MIS MPSV

Více

Procesní dokumentace Process Management. Pavel Čejka

Procesní dokumentace Process Management. Pavel Čejka Procesní dokumentace Process Management Pavel Čejka SAP Solution Manager 7.2 SAP Solution Manager 7.2 nabízí dramatické zlepšení možností dokumentace Solution dokumentace Jednotné webové prostředí Integrovaný

Více

Architektury informačních systémů

Architektury informačních systémů Architektury informačních systémů doc. Ing. Miroslav Beneš, Ph.D. katedra informatiky FEI VŠB-TUO A-1007 / 597 324 213 http://www.cs.vsb.cz/benes/vyuka/tis Miroslav.Benes@vsb.cz Obsah přednášky Co je to

Více

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček Aplikace IS, outsourcing, systémová integrace Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Kontext Dodavatelé Strategická Zákazníci Taktická Operativní Kategorie ERP - zaměřeno na řízení

Více

ČD Telematika a.s. Efektivní správa infrastruktury. 11. května 2010. Konference FÓRUM e-time, Kongresové centrum Praha. Ing.

ČD Telematika a.s. Efektivní správa infrastruktury. 11. května 2010. Konference FÓRUM e-time, Kongresové centrum Praha. Ing. ČD Telematika a.s. Efektivní správa infrastruktury 11. května 2010 Konference FÓRUM e-time, Kongresové centrum Praha Ing. František Nedvěd Agenda O společnosti ČD Telematika a.s. Efektivní správa konfigurací

Více

Wonderware Information Server 4.0 Co je nového

Wonderware Information Server 4.0 Co je nového Wonderware Information Server 4.0 Co je nového Pavel Průša Pantek (CS) s.r.o. Strana 2 Úvod Wonderware Information Server je výrobní analytický a reportní informační portál pro publikaci výrobních dat

Více

Architektury informačních systémů

Architektury informačních systémů Architektury informačních systémů doc. Ing. Miroslav Beneš, Ph.D. katedra informatiky FEI VŠB-TUO A-1007 / 597 324 213 http://www.cs.vsb.cz/benes/vyuka/tis Miroslav.Benes@vsb.cz Obsah přednášky Co je to

Více

Vzdálená správa v cloudu až pro 250 počítačů

Vzdálená správa v cloudu až pro 250 počítačů Vzdálená správa v cloudu až pro 250 počítačů S pomocí ESET Cloud Administratoru můžete řídit zabezpečení vaší podnikové sítě bez nutnosti nákupu, instalace nebo údržby dalšího hardwaru. Řešení je poskytováno

Více

Znalostní systém nad ontologií ve formátu Topic Maps

Znalostní systém nad ontologií ve formátu Topic Maps Znalostní systém nad ontologií ve formátu Topic Maps Ladislav Buřita, Petr Do ladislav.burita@unob.cz; petr.do@unob.cz Univerzita obrany, Fakulta vojenských technologií Kounicova 65, 662 10 Brno Abstrakt:

Více

Outsourcing v podmínkách Statutárního města Ostravy

Outsourcing v podmínkách Statutárního města Ostravy Outsourcing v podmínkách Statutárního města Ostravy Říjen 2009 Ing. Stanislav Richtar Ředitel společnosti 1 OBSAH PREZENTACE 1. Outsourcing - obecně 2. Výchozí stav projektu 3. Model poskytovaných služeb

Více

České Budějovice. 2. dubna 2014

České Budějovice. 2. dubna 2014 České Budějovice 2. dubna 2014 1 IBM regionální zástupci - Jihočeský kraj Michal Duba phone: +420 737 264 058 e-mail: michal_duba@cz.ibm.com Zdeněk Barlok phone: +420 731 435 534 e-mail: zdenek_barlok@cz.ibm.com

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1 Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové

Více

Vývoj informačních systémů. Přehled témat a úkolů

Vývoj informačních systémů. Přehled témat a úkolů Vývoj informačních systémů Přehled témat a úkolů Organizace výuky doc. Mgr. Miloš Kudělka, Ph.D. EA 439, +420 597 325 877 homel.vsb.cz/~kud007 milos.kudelka@vsb.cz Přednáška Teorie Praxe Cvičení Diskuze

Více

PRODUKTY Tovek Server 6

PRODUKTY Tovek Server 6 Tovek Server je serverová aplikace určená pro efektivní zpracování velkého objemu sdílených strukturovaných i nestrukturovaných dat. Umožňuje automaticky indexovat data z různých informačních zdrojů, intuitivně

Více

Obsah: Základní pojmy, definice Informační systémy IT architektura Typické aplikační komponenty Implementace aplikací

Obsah: Základní pojmy, definice Informační systémy IT architektura Typické aplikační komponenty Implementace aplikací Monitorovací indikátor: 06.43.10 Počet nově vytvořených/inovovaných produktů Akce: Přednáška, KA 5 Číslo přednášky: 30 Téma: INFORMAČNÍ SYSTÉMY A ARCHITEKTURA IT V PODNIKU Lektor: Ing. Michal Beránek Třída/y:

Více

Obsah. Zpracoval:

Obsah. Zpracoval: Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč

Více

BIG DATA. Nové úlohy pro nástroje v oblasti BI. 27. listopadu 2012

BIG DATA. Nové úlohy pro nástroje v oblasti BI. 27. listopadu 2012 BIG DATA Nové úlohy pro nástroje v oblasti BI 27. listopadu 2012 AGENDA 1. Úvod 2. Jaké jsou potřeby? 3. Možné řešení 2 Jaké jsou potřeby? Dopady Analýza dat potřeba nového přístupu Jak na nestrukturovaná

Více

Semináˇr Java X J2EE Semináˇr Java X p.1/23

Semináˇr Java X J2EE Semináˇr Java X p.1/23 Seminář Java X J2EE Seminář Java X p.1/23 J2EE Složitost obchodních aplikací robusní, distribuované, spolehlivé aplikace s transakcemi na straně serveru, klientské aplikace co nejjednodušší Snaha : Návrh,

Více

Možnosti propojení Lotus Notes/Domino a jiných systémů. Ondřej Fuxa Your System spol. s r.o.

Možnosti propojení Lotus Notes/Domino a jiných systémů. Ondřej Fuxa Your System spol. s r.o. Možnosti propojení Lotus Notes/Domino a jiných systémů Ondřej Fuxa Your System spol. s r.o. Lotus Symposium 2010 Agenda Integrace proč o ní uvažujeme? Možnosti integrace Lotus Notes/Domino a jiných systémů

Více

Moderní metody automatizace a hodnocení marketingových kampaní

Moderní metody automatizace a hodnocení marketingových kampaní Moderní metody automatizace a hodnocení marketingových kampaní SAS CI Roadshow 2014 24/09/2014 Vít Stinka Agenda Představení společnosti Unicorn Systems Aliance Unicorn Systems a SAS Celkový koncept Customer

Více

Jádrem systému je modul GSFrameWork, který je poskytovatelem zejména těchto služeb:

Jádrem systému je modul GSFrameWork, který je poskytovatelem zejména těchto služeb: Technologie Marushka Základním konceptem technologie Marushka je použití jádra, které poskytuje přístup a jednotnou grafickou prezentaci geografických dat. Jádro je vyvíjeno na komponentním objektovém

Více

ENTERPRISE INFORMATION PORTALS

ENTERPRISE INFORMATION PORTALS ENTERPRISE INFORMATION PORTALS Jan Kotek Sybase ČR s.r.o., Tychonova 2, 160 00 Praha 6, ČR Abstrakt Příspěvek pojednává o novém směru vývoje informačních systémů zaměřených na elektronickou komerci tzv.

Více

DOCUMENT MANAGEMENT TOOLKIT

DOCUMENT MANAGEMENT TOOLKIT DOCUMENT MANAGEMENT TOOLKIT SPRÁVA DOKUMENTŮ V MODERNÍM PODNIKOVÉM PROSTŘEDÍ Zpracování dokumentů prochází v dnešním firemním světě významnými změnami. Firmy jsou nuceny řešit řadu problémů, které s sebou

Více

PORTÁL STÁTNÍ ROSTLINOLÉKAŘSKÉ SPRÁVY VE SLUŽBÁCH

PORTÁL STÁTNÍ ROSTLINOLÉKAŘSKÉ SPRÁVY VE SLUŽBÁCH PORTÁL STÁTNÍ ROSTLINOLÉKAŘSKÉ SPRÁVY VE SLUŽBÁCH VEŘEJNOSTI I ZAMĚSTNANCŮ O zákazníkovi Státní rostlinolékařská správa (SRS) je úředním orgánem rostlinolékařské péče České republiky. Činnost Státní rostlinolékařské

Více

Návrh softwarových systémů - architektura softwarových systémů

Návrh softwarových systémů - architektura softwarových systémů Návrh softwarových systémů - architektura softwarových systémů Martin Tomášek, Jiří Šebek Návrh softwarových systémů (B6B36NSS) Převzato z přednášky X36AAS M. Molhanec Co je to architektura Využívá se

Více

SAP PROCUREMENT DAY 2013

SAP PROCUREMENT DAY 2013 SAP PROCUREMENT DAY 2013 Portfolio řešení SAP pro oblast nákupu Vladimír Heřt, SAP ČR Agenda Stručný úvod Portfolio řešení SAP Řešení SAP pro oblast nákupu On Premise & On Demand Nadstavbová řešení SAP

Více

ARIS Platform softwarová podpora řízení procesů Procesní ARIS laboratoř základ moderní výuky. www.ids-scheer.cz

ARIS Platform softwarová podpora řízení procesů Procesní ARIS laboratoř základ moderní výuky. www.ids-scheer.cz ARIS Platform softwarová podpora řízení procesů Procesní ARIS laboratoř základ moderní výuky www.ids-scheer.cz Agenda Představení IDS Scheer ARIS Platform Scénáře možné spolupráce Vybudování komplexní

Více

Nová dimenze rozhodovacího procesu

Nová dimenze rozhodovacího procesu Nová dimenze rozhodovacího procesu Marek Matoušek Pavel Mašek Data, nebo INFORMACE Využití dostupných firemních dat Několik systémů, mnoho různých dat Různé divize, různé potřeby Potřeba integrace dat

Více

Od klasického reportingu k SAP BO Design studio na BW power by HANA Pavel Strnad

Od klasického reportingu k SAP BO Design studio na BW power by HANA Pavel Strnad Od klasického reportingu k SAP BO Design studio na BW power by HANA Pavel Strnad CIO PIA5 NSC Prague Obsah Představení firmy Migrace BW to HANA BI architektura ve Wincor Nixdorf Migrační varianty z BW

Více

Optimalizaci aplikací. Ing. Martin Pavlica

Optimalizaci aplikací. Ing. Martin Pavlica Optimalizaci aplikací Ing. Martin Pavlica Vize: Aplikace v dnešním světě IT Ze všech částí IT jsou aplikace nejblíže businessu V elektronizovaném světě významným způsobem podporují business, ten se na

Více

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material,

Více

ADMINISTRACE POČÍTAČOVÝCH SÍTÍ. OPC Server

ADMINISTRACE POČÍTAČOVÝCH SÍTÍ. OPC Server ADMINISTRACE POČÍTAČOVÝCH SÍTÍ OPC Server Funkce a využití v průmyslové automatizaci Jiří NOSEK 2011 Co je OPC Server? OPC = Open Process Control (původně OLE for Process Control) sada specifikací průmyslového

Více

Obsah. Kapitola 1. Kapitola 2. Kapitola 3. Úvod 9

Obsah. Kapitola 1. Kapitola 2. Kapitola 3. Úvod 9 Obsah Úvod 9 Kapitola 1 Business Intelligence, datové sklady 11 Přechod od transakčních databází k analytickým..................... 13 Kvalita údajů pro analýzy................................................

Více

Reportingová platforma v České spořitelně

Reportingová platforma v České spořitelně Reportingová platforma v České spořitelně Agenda Implementované prostředí Cognos 8 v ČS Marek Varga, Česká spořitelna, a.s. Využití platformy Cognos z pohledu businessu Petr Kozák, Česká spořitelna, a.s.

Více

EXTRAKT z technické normy CEN ISO

EXTRAKT z technické normy CEN ISO EXTRAKT z technické normy CEN ISO Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě. Inteligentní dopravní systémy Kooperativní ITS Zařízení stanice ITS pro přenos

Více

Benefity při práci se systémem konsolidovaných pacientských dat. Ing. Ladislav Pálka, MBA C SYSTEM CZ a.s.

Benefity při práci se systémem konsolidovaných pacientských dat. Ing. Ladislav Pálka, MBA C SYSTEM CZ a.s. Benefity při práci se systémem konsolidovaných pacientských dat. Ing. Ladislav Pálka, MBA C SYSTEM CZ a.s. C SYSTEM CZ Společnost C SYSTEM CZ se zabývá komplexním řešením potřeb zákazníků v oblasti informačních

Více

Koncept. Centrálního monitoringu a IP správy sítě

Koncept. Centrálního monitoringu a IP správy sítě Koncept Centrálního monitoringu a IP správy sítě Koncept Centrálního monitoringu a IP správy sítě Společnost Novicom, společně se svým partnerem, společností INVEA-TECH, nabízí unikátní koncept Centralizovaného

Více

Role BI v e-business řešeních pohled do budoucnosti

Role BI v e-business řešeních pohled do budoucnosti Ing. Ota Novotný, Ph.D. katedra informačních technologií Vysoká škola ekonomická v Praze novotnyo@vse.cz katedra informačních technologií VŠE Praha jsme uznávanou autoritou v oblasti aplikované informatiky

Více

Servisně orientovaná architektura a její aplikace v systémech sledování a řízení výroby

Servisně orientovaná architektura a její aplikace v systémech sledování a řízení výroby Servisně orientovaná architektura a její aplikace v systémech sledování a řízení výroby Marek Rychlý Vysoké učení technické v Brně Fakulta informačních technologií Ústav informačních systémů VII. ročník

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Architektura v organizaci

Architektura v organizaci Architektura v organizaci Radek Vácha Seminář CSSI, 23.3.2007 Accenture, its logo, and Accenture High Performance Delivered are trademarks of Accenture. Obsah Můj profil Architektura odraz světa Jiné pohledy

Více

Unified Communications. Customer Contact. Cisco Unified Contact Center Enterprise. Hlavní výhody. Způsoby nasazení

Unified Communications. Customer Contact. Cisco Unified Contact Center Enterprise. Hlavní výhody. Způsoby nasazení Unified Communications Customer Contact Cisco Unified Contact Center Enterprise Cisco Unified Contact Center Enterprise přináší ucelené řešení poskytující inteligentní směrování a obsloužení hovorů. Jedná

Více

ARBES Technologies, s.r.o. Enterprise Content Management Konference ISSS 2013

ARBES Technologies, s.r.o. Enterprise Content Management Konference ISSS 2013 ARBES Technologies, s.r.o. Enterprise Content Management Konference ISSS 2013 Agenda Představení ARBES a divize Proč potřebujeme DMS ve státní správě Práce s dokumenty od A do Z Zabezpečení obsahu pro

Více

Nasazení jednotné správy identit a řízení přístupu na Masarykově univerzitě s využitím systému Perun. Slávek Licehammer

Nasazení jednotné správy identit a řízení přístupu na Masarykově univerzitě s využitím systému Perun. Slávek Licehammer Nasazení jednotné správy identit a řízení přístupu na Masarykově univerzitě s využitím systému Perun Slávek Licehammer 16. 5. 2016 IdM na MU Na MU právě vzniká nová koncepce správy identit a řízení přístupu

Více

Telelogic Focal Point využití pro řízení a optimalizaci projektového portfolia Verze 1.0

Telelogic Focal Point využití pro řízení a optimalizaci projektového portfolia Verze 1.0 DISTRIBUTOR White Paper Verze 1.0 Ing. Jiří Gryc 26.4.2007 Tento dokument ve stručnosti představuje možnost využití špičkového Telelogic Focal Point pro řízení a optimalizaci projektového portfolia. Další

Více

ARBES ECM MODERNÍ SYSTÉM. určený k digitalizaci, tvorbě, správě, sdílení a archivaci dokumentů a obsahu. www.arbes.com

ARBES ECM MODERNÍ SYSTÉM. určený k digitalizaci, tvorbě, správě, sdílení a archivaci dokumentů a obsahu. www.arbes.com ARBES ECM MODERNÍ SYSTÉM určený k digitalizaci, tvorbě, správě, sdílení a archivaci dokumentů a obsahu. www.arbes.com ARBES ECM ENTERPRISE CONTENT MANAGEMENT Poskytujeme služby v oblasti zavádění a rozvoje

Více

Sjednocení dohledových systémů a CMDB

Sjednocení dohledových systémů a CMDB Řízení dodávky IT služeb v enterprise společnosti Sjednocení dohledových systémů a CMDB Václav Souček, ČEZ ICT Services, a.s. Jaroslav Jičínský, AutoCont CZ, a.s. 26. Ledna 2012 Agenda Úvod Výchozí stav

Více

VZOROVÝ STIPENDIJNÍ TEST Z INFORMAČNÍCH TECHNOLOGIÍ

VZOROVÝ STIPENDIJNÍ TEST Z INFORMAČNÍCH TECHNOLOGIÍ VZOROVÝ STIPENDIJNÍ TEST Z INFORMAČNÍCH TECHNOLOGIÍ 1. Dědičnost v OOP umožňuje: a) dědit vlastnosti od jiných tříd a dále je rozšiřovat b) dědit vlastnosti od jiných tříd, rozšiřovat lze jen atributy

Více

CA Identity Lifecycle Management. Jak na to...

CA Identity Lifecycle Management. Jak na to... CA Identity Lifecycle Management Jak na to... June 2012 Agenda > Úvod Co je Identity Lifecycle Management (ILM) Proč zavádět ILM v organizaci Výhody po zavedení ILM > Identity Lifecycle Management ILM

Více

Strategické řízení IS Strategické řízení Základní pojmy

Strategické řízení IS Strategické řízení Základní pojmy Strategické řízení IS Základní pojmy Informatika Informatika je multidisciplinární obor, jehoţ předmětem je tvorba a uţití informačních systémů v podnicích a společenstvích a to na bázi informačních a

Více

Business Intelligence nástroje a plánování

Business Intelligence nástroje a plánování Business Intelligence nástroje a plánování pro snadné reportování a vizualizaci Petr Mlejnský Business Intelligence pro reporting, analýzy a vizualizaci Business Intelligence eporting Dashboardy a vizualizace

Více