Fakulta informatiky a statistiky
Katedra informačních technologií
Student : Jakub Karlec
Vedoucí bakalářské práce : Doc. Ing. Jan Pour, CSc.
Recenzent bakalářské práce : Ing. Roman Kopecký
TÉMA BAKALÁŘSKÉ PRÁCE
Oracle Fusion Middleware
Prohlášení
Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem čerpal.
V Praze dne 16. srpna 2007 ... ...
podpis
Pod ě kování
Úvodem bych chtěl poděkovat panu Doc. Ing. Janu Pourovi, CSc., za to, že se zhostil úlohy vedoucího mé práce a poskytoval mi cenné rady, připomínky a odborné vedení.
Abstrakt
Předmětem této práce je zhodnocení a analýza využití produktu Oracle Fusion Middleware v rámci podnikového informačního systému. Práce dále představuje a zkoumá možnosti, jež přináší Service Oriented Architecture (SOA).
SOA je architektonickým přístupem, který je moderním trendem v oblasti vývoje a správy podnikových informačních systémů. Na principech SOA je postavena middleware vrstva Oracle Fusion Middleware, která slouží jako platforma pro integraci, vývoj, nasazení, provoz a správu aplikací podnikového informačního systému.
Cílem práce je poukázat na přínosy, nedostatky a rizika, které Service Oriented Architecture a na něm založený softwarový balík Oracle Fusion Middleware přináší. Záměrem je analyzovat jak efekty, kterých lze dosáhnout v oblasti IT/ICT, tak efekty, jež se při využití těchto technologií projeví v podnikání.
Abstract
Subject of this bachelor study is evaluation and analysis of usage of the product Oracle Fusion Middleware in the context of enterprise information system. Next, the study introduces and examines possibilities brought by the Service Oriented Architecture (SOA).
SOA is an architectural approach, a modern trend in the area of development and administration of enterprise information systems. On the principles of SOA, the middleware layer Oracle Fusion Middleware is built. It serves as a platform for integration, development, running and administration of enterprise information system applications.
The aim of this study is to point out the benefits, negatives and risks of the Service Oriented Architecture and of Oracle Fusion Middleware package which is built using SOA principles. The purpose is to analyze both: the effects that can be achieved in the IT/ICT area and the business impacts of these technologies.
Obsah
1 ÚVOD... 7
2 SERVICE ORIENTED ARCHITECTURE... 9
2.1 PŘECHOD NA SOA– TREND VOBLASTI PODNIKOVÝCH IS... 9
2.2 ÚVOD DO SOA... 10
2.3 VYUŽITÍ SOA... 11
2.3.1 Integrace aplikací a informačních systémů... 12
2.3.2 Vývoj kompozitních aplikací... 13
2.3.3 Modernizace systémových platforem a stávajících aplikací... 13
2.4 VÝVOJOVÝ CYKLUS V RÁMCI SOA... 14
2.5 WEB SERVICES A BUSINESS PROCESS EXECUTION LANGUAGE... 15
2.6 VÝHODY A NEVÝHODY SOA... 16
2.6.1 Technologické výhody... 16
2.6.2 Výhody a efekty SOA pro podnikání... 17
2.6.3 Nevýhody... 18
2.7 ANALÝZA KRITICKÝCH MÍST PŘECHODU NA SOA... 19
2.8 SHRNUTÍ... 21
3 ORACLE FUSION MIDDLEWARE... 22
3.1 MODERNÍ ZÁKLADNA PRO INFORMAČNÍ SYSTÉMY... 22
3.2 ORACLE FUSION... 23
3.3 OBLASTI VYUŽITÍ ORACLE FUSION MIDDLEWARE... 24
3.3.1 Vývoj aplikací a komponent IS... 24
3.3.2 Integrace... 26
3.3.3 Orchestrace... 27
3.3.4 Provoz... 28
3.3.5 Analýza... 29
3.3.6 Přístup a prezentační logika... 29
3.4 ARCHITEKTURA ORACLE FUSION MIDDLEWARE... 30
4 ANALÝZA VYUŽITÍ ORACLE FUSION MIDDLEWARE... 32
4.1 ÚVOD... 32
4.2 VOLBA KONCEPTU INFORMAČNÍHO SYSTÉMU... 32
4.2.1 All-in-one integrovaný informační systém... 33
4.2.2 Kombinace best-of-breed software... 33
4.2.3 Vývoj na trhu ERP systémů... 34
4.2.4 Přínosy Oracle Fusion Middleware při volbě konceptu informačního systému... 35
4.3 PLATFORMA ORACLE FUSION MIDDLEWARE A VÝHODY SOA... 36
4.4 PODNIKATELSKÁ VOLBA MIDDLEWARE... 37
5 PŘEHLED KONKURENCE A TRHU MIDDLEWARE... 39
5.1 DEFINICE TRHU... 39
5.2 SROVNÁNÍ PRODUKTŮ... 39
5.3 RIZIKA SPOJENÁ SVÝBĚREM ORACLE FUSION MIDDLEWARE... 41
6 ZÁVĚR... 42
7 SEZNAM POUŽITÉ LITERATURY... 43
8 TERMINOLOGICKÝ SLOVNÍK... 45
1 Úvod
V současnosti narůstá význam middleware vrstvy nejen jako integrační platformy pro jednotlivé součásti informačních systémů, ale taktéž jako platformy pro vývoj a správu kompozitních aplikací.
Nejnovějším trendem je přitom přechod na Service Oriented Architecture (SOA), neboli architekturu orientovanou na služby1. Volba middleware vrstvy ovlivňuje směr, kterým se ubírá podniková informatika a proto je důležité věnovat této oblasti pozornost.
Oracle Fusion Middleware je integrovaný a na standardech založený balík nástrojů, komponent a aplikací, který umožňuje tvorbu, integraci a správu informačních systémů a jejich součástí. Základem Oracle Fusion Middleware je SOA.
Běžně byl middleware chápán jako sada technologií sloužících jako střední vrstva mezi daty a aplikacemi IS. Prakticky se jedná o integrační platformu, která umožňuje jednotlivým aplikacím podnikového IS sdílet data a pracovat s nimi. V současné době dochází ke změně pojetí middleware a to směrem k rozšiřování této vrstvy o funkcionalitu, která doplňuje a rozšiřuje integrační služby (viz [1]). Oracle Fusion Middleware je koncipován v duchu tohoto vývoje.
Platforma pro sdílení dat je pouze jedna část tohoto balíku. Oracle Fusion Middleware je spíše platforma pro komplexní modelování, vývoj, implementaci, integraci, správu a další rozvoj aplikací v rámci podnikového informačního systému. Nástroje Fusion Middleware pokrývají svou funkcionalitou celý životní cyklus informačního systému. Oracle Fusion Middleware je tedy komplexní technologickou a aplikační podkladovou infrastrukturou pro informační systém.
Vzhledem k tomu, že koncept SOA je klíčovou složkou Oracle Fusion Middleware a nejnovějším trendem ve vývoji informačních systémů, bude mu tato práce věnovat značnou pozornost. SOA bude dopodrobna prozkoumána v první části této práce, která slouží jako východisko pro analýzu využití a přínosů Oracle Fusion Middleware. Obsahem prvního oddílu bude princip SOA, její využití v rámci podnikových IS a zejména přínosy, které tato architektura přináší.
V další části přijde na řadu hodnocení samotného Oracle Fusion Middleware. Nejprve budou prozkoumány možnosti jeho využití a následně přijde část analyzující přínosy a případné nedostatky tohoto balíku.
Poslední oddíl práce udává přehled trhu a stručně analyzuje Oracle Fusion Middleware společně s konkurenčními produkty.
1 Některé zdroje překládají SOA jako servisně orientovaná architektura, nicméně tento překlad je na první pohled nepřesný, protože slovo service, jak je patrné z principu fungování SOA, značí službu, nikoli servis. Proč je pro tuto architekturu stěžejní právě slovo služba, je vysvětleno v textu
Cílem této seminární práce je ukázat možnosti, které podnikům poskytuje Service Oriented Architecture a na ní postavená řešení, v tomto případě konkrétně Oracle Fusion Middleware.
Snahou je přitom pokrýt jak obchodní tak i technickou problematiku SOA a konceptu middleware.
Zároveň se pokusím poukázat na úskalí, která s sebou nasazení SOA přináší a jak se jim vyvarovat.
Dalším cílem práce je představit funkcionalitu Oracle Fusion Middleware a analyzovat její přínosy.
Účelem zkoumání je taktéž zjistit nakolik Oracle Fusion Middleware umožní podnikům těžit z předností SOA.
2 Service Oriented Architecture
2.1 P ř echod na SOA – trend v oblasti podnikových IS
V oblasti IS/ICT, která v posledních letech prochází živelným rozvojem, se již delší dobu projevuje tendence sbližovat technologie s podnikáním (core-businessem) a podnikovou strategií. Hlavním úkolem je co nejlépe sladit podnikové procesy s IS/ICT, které jsou do podniku implementovány pro podporu těchto procesů. Vzájemné důsledné přizpůsobení obou oblastí je klíčové pro dosažení maximální efektivity investic do IT/ICT.
Nejmodernějším přístupem k tvorbě a implementaci podnikových informačních systémů je Service Oriented Architecture (SOA), jejíž hlavním úkolem je zjednodušit integraci aplikací IS a usnadnit vývoj nových komponent. Jako vedlejší (ale důležitý) efekt je právě lepší propojení IT s podnikovými procesy.
Cíl SOA definuje Hao He (viz [2]) následovně: „SOA je architektura, jejímž cílem je zajistit volné propojení mezi spolupracujícími aplikacemi.“ Díky tomuto volnému propojení a systému služeb, které mohou aplikace IS využívat, se zvyšuje flexibilita informačního systému a je snadnější ho integrovat s klíčovými oblastmi podnikání.
Proč SOA? Pokud chtějí společnosti uspět v moderním vysoce konkurenčním prostředí, musí co nejrychleji reagovat a přizpůsobovat své produkty a služby požadavkům zákazníků i krokům konkurence. IT/ICT hraje v tomto procesu velmi významnou roli. Bohužel nedostatky má dnes většina současných IS. K situaci stávajících informačních systémů Hao He (viz [2]) poznamenává: „Některé jsou příliš jednoduché, aby plnily úlohy, které mají. Jiné jsou příliš složité a náklady na jejich vývoj a správu enormně vzrostly, nemluvě o téměř nemožném úkolu, jakým je jejich vzájemná integrace.“ Z toho vyplývá i náročnost a komplikované změnové řízení ve složitých systémech. Mnoho společností dnes většinu rozpočtu pro IT/ICT věnuje na správu a údržbu stávajícího systému a minimum prostředků pak zbývá na další rozvoj. Tento problém by svou flexibilitou a tudíž nižšími časovými a finančními nároky na změny měla právě SOA řešit.
Problémem v této oblasti je v současné době zejména velká marketingová pozornost, kterou firmy SOA věnují. Díky tomu bývá SOA označována jen jako další „buzzword“, tedy pojem, o kterém se hodně mluví, ale ve skutečnosti přináší málo nového užitku. Jednotlivé společnosti, které produkty spojené se SOA zařadily do svého portfolia, skutečně velmi tlačí na propagaci této technologie a vytváří tak vysoká očekávání zákazníků. Tato situace je však dána velkou konkurenčností současného trhu IS/ICT a velkého tlaku na dodavatele, kteří se snaží neustále zvyšovat svůj podíl na trhu. Pokud však odhlédneme od marketingové stránky věci, je zajímavé, jak velká shoda na přínosech SOA panuje mezi technicky zaměřenou veřejností.
Rozruch, který kolem SOA vyvolává marketingová propagace, by v podnicích, které chtějí
provádět nové investice do IS/ICT, neměl vést k přílišnému nadšení, avšak ani k přílišné skeptičnosti vůči tomuto přístupu.
2.2 Úvod do SOA
V této části se podrobněji podíváme na technologickou stránku SOA. Definic existuje celá řada, ale pro lepší pochopení toho, co SOA vlastně znamená, si rozšíříme definici z kapitoly 1 Přechod na SOA – trend v oblasti podnikových IS: SOA je architektonický přístup k tvorbě informačních systémů, který využívá množství na sobě nezávislých služeb, které poskytují konkrétní jednoduchou funkcionalitu aplikacím podnikového informačního systému. Nejběžnějším základem této architektury jsou webové služby a jejich technologie. Tyto služby jsou uspořádány v rámci určité vrstvy, v našem případě Oracle Fusion Middleware, která se stará o jejich správu a umožňuje aplikacím IS se službami pracovat. Služba je vlastně jakýsi uzavřený kontejner, který na základě přesně definovaného vstupu vrací přesně dokumentovaný výstup. Aplikace pak služby využívají tak, že službě předají určité vstupní parametry, služba je zpracuje a aplikaci vrátí výstupní data, se kterými pak aplikace dále pracuje.
Pro lepší pochopení klíčových pojmů týkajících se SOA uvádím následující obrázek, který popisuje SOA tak, jak jí definuje společnost IBM.
Obrázek 1: Definice SOA a jejích hlavních součástí, zdroj: [3]
Častým omylem je zaměňování pojmů SOA a webových služeb. Nejedná se o různé názvy pro stejnou věc. Webové služby jsou pouze hlavní technologií, kterou je možné při budování SOA
ve společnosti využít. SOA totiž nedefinuje konkrétní formu služeb, které mají být v této architektuře využívány a ačkoli jsou webové služby tou nejčastější formou služeb, jejich postavení mohou zaujmout i rozhraní aplikací v jazyce Java, C# apod.
Další vrstvou v modelu SOA je vrstva procesů. SOA totiž přináší možnost propojit podnikové procesy na jednotlivé webové služby a díky tomu sblížit podnikání s IS/ICT. Propojení podnikových procesů a služeb je patrné z referenčního modelu SOA, který je zobrazen na obrázku 2.
K tomu, aby mohly aplikace, respektive podnikové procesy jednotlivé služby využívat, musí k nim mít nejprve přístup. To zajišťuje Enterprise Service Bus (ESB), který tvoří jakýsi adresář služeb.
Obrázek 2: Referenční model SOA zobrazuje propojení vrstvy podnikových procesů a služeb, zdroj: [4]
2.3 Využití SOA
Tři hlavní oblasti využití, u kterých se SOA zdá být výhodným architektonickým přístupem, jsou (viz [5]):
- integrace aplikací a IS, - vývoj kompozitních aplikací,
- modernizace systémových platforem a stávajících aplikací.
Přechod na SOA podporují zejména tyto faktory:
- neustálé změny podnikání, - konsolidace,
- customizace informačních systémů, - vícekanálové aplikace,
- B2B sítě služeb.
2.3.1 Integrace aplikací a informa č ních systém ů
Na rozdíl od stávajícího způsobu integrace aplikací, tedy tradiční EAI (Enterprise Application Integration) nebo specifických individuálních propojení, SOA nabízí propojení na bázi standardů jako je XML, WSDL nebo BPEL. Jakákoli standardizace s sebou samozřejmě přináší výhody. Ty vychází zejména z neproprietárnosti řešení, snadné správy a rozšiřitelnosti.
Nevýhody jednotlivých přístupů oproti integraci na bázi SOA a některá další srovnávací kritéria zobrazuje následující tabulka (viz [5]).
Individuální propojení (Point-to-Point)
Tradiční EAI Integrace na bázi SOA
Zásahy do jednotlivých aplikací
Proprietární řešení, nestandardní
Standardy (XML, WSDL, BPEL)
Neflexibilní Uzavřené, nízká flexibilita Flexibilita a rozšiřitelnost (volné propojení)
Nejsou k dispozici nástroje pro správu a monitoring propojení
Nákladné Vyšší počáteční investice do frameworku
Velké množství propojovacích bodů
Chybí konceptuální pohled na integraci (nedostatečná abstrakce)
Globální konceptuální pohled v rámci SOA architektury
Žádná znovupoužitelnost Minimální znovupoužitelnost Znovupoužitelnost je základem řešení
Tabulka 1: Přístupy k integraci aplikací
2.3.2 Vývoj kompozitních aplikací
Většina individuálních aplikací a software jsou tvořeny, aniž by bylo myšleno na komplexní a flexibilní integraci, která může být v budoucnu při dalším vývoji informačního systému potřeba.
Aplikace jsou napsané pro určité konkrétní specifické propojení se systémem a v případě změn je potřeba aplikaci upravit a přeprogramovat. Jakékoli úpravy aplikace jsou samozřejmě nepříjemné, navíc se jedná o časově náročné úkoly a právě tím vzniká mezera mezi IT a podnikáním.
SOA díky podpoře standardů a tvorbě aplikací založených na množství nezávislých služeb přináší nový přístup, který umožňuje aplikace snadno vytvářet z existujících služeb, aniž by bylo potřeba aplikaci znovu psát od začátku. Znovupoužitelnost jednotlivých služeb je klíčovým konceptem SOA. Není třeba pro každou aplikaci znovu nově programovat určitou funkcionalitu.
Funkcionalita je naprogramována jako služba, je dána k dispozici do Enterprise Service Bus a ten jí pak zpřístupní dalším aplikacím. ESB je součástí Oracle Application Serveru a jeho účelem je organizovat služby a zpřístupňovat je ostatním aplikacím. ESB tvoří hlavní integrační bod SOA.
Kompozitní aplikace jsou aplikace, které ke svému běhu využívají různých datových a programových zdrojů z různých částí informačního systému.
Pro doložení toho, že SOA je skutečně ideálním přístupem pro tvorbu kompozitních aplikací, můžeme uvést jednu z dalších definic SOA, podle společnosti Gartner (viz [26]):
„Architektura orientovaná na služby je typ vícevrstvého informačního uspořádání, které pomáhá organizacím sdílet logiku a data mezi více aplikacemi.“
Důležitý je správný výběr funkcionality, která bude poskytována v rámci služeb. Aby byla splněna podmínka pro co nejtěsnější propojení IS na podnikové procesy, je z podnikatelského pohledu ideální, aby (viz [6]): „portfolio služeb SOA obsahovalo zejména služby, které se přímo váží na podstatu podnikání“. Z pohledu technického je pak důležité, aby veškerá funkcionalita, která se opakovaně využívá napříč informačním systémem, byla poskytována jako služby.
Pro vývoj kompozitních aplikací a jednotlivých součástí IS se využívá Business Process Execution Language (BPEL), který umožňuje skládání služeb do funkčních aplikací. BPEL bude oblastí našeho zájmu v kapitole 2.5 Web services a Business Process Execution Language.
2.3.3 Modernizace systémových platforem a stávajících aplikací
SOA ve své podstatě umožňuje a podporuje inkrementální vývoj software. Toho se dá využít nejen při tvorbě nového IS a postupném budování jeho funkcionality, ale také při rozšiřování nebo úpravách stávajícího IS. Budování IS na bázi SOA tedy neznamená, že je potřeba kompletně změnit stávající IS/ICT infrastrukturu, ale lze stavět na stávajícím IS. Díky SOA tak lze využít předchozích investic do IS.
Princip, jakým lze stávající aplikace využít v novém prostředí IS je poměrně jednoduchý.
Je třeba funkcionalitu stávajících aplikací zprovoznit jako webové služby (popřípadě Java služby apod.). Většina aplikací to umožňuje, popřípadě je nutné do aplikace zasáhnout programově. Poté, co je funkcionalita zpřístupněna v podobě služeb, je možné tyto služby dát normálním způsobem k dispozici v ESB.
V případě, že podnik potřebuje přejít ze stávajících zastaralých aplikací na nový systém, nabízí SOA možnost přecházet postupným budováním funkcionality, která průběžně nahrazuje stávající systém. Toto postupné nahrazování starého systému namísto jednoho velkého projektu, který by systém nahradil, snižuje riziko neúspěchu, které je s velkými projekty spojeno.
2.4 Vývojový cyklus v rámci SOA
Jak již bylo řečeno, základem SOA jsou jednotlivé služby. K tomu, aby mohly být služby naprogramovány a poskytnuty jejich uživatelům, musí být nejprve rozhodnuto, jaké služby budou vytvořeny. Pro výběr těch správných služeb existuje několik přístupů. Oracle doporučuje iterativní top-down přístup, který vychází z firemní strategie a základů podnikání a přechází dolů do detailních business procesů, na kterých jsou pak založeny webové služby. Tento přístup však bývá mnohdy poměrně složitý. Proto vznikly také jiné přístupy k analýze, jako je bottom-up nebo
„middle-out“ od Microsoftu (viz [13]). Pří výběru správného přístupu je třeba, aby si společnost dala pozor na dvě základní věci. Analyzovaný systém by měl být co nejtěsněji propojen na firemní vize a strategii a měl by tak podporovat top-management, ale zároveň je potřeba, aby systém splňoval požadavky podnikání i na té nejnižší úrovni. Při analýze je třeba dbát na to, aby nedošlo k orientaci jen na jednu z těchto složek.
Následně přichází na řadu samotné programování služeb. V případě, že podnik již má naimplementován IS a využívá stávající aplikace, je možné, že tyto aplikace webové, či jiné služby podporují. Pak stačí pouze poskytnout funkcionalitu stávajících aplikací jako služby v rámci SOA.
Ve chvíli, kdy jsou v ESB k dispozici naprogramované webové služby, můžeme s nimi začít pracovat. Služby je možné skládat do komplexnějších služeb a aplikací propojených na podnikové procesy. K organizaci služeb do rozsáhlejších celků slouží BPEL.
Posledním krokem je poskytnutí služeb uživatelům a aplikacím IS. Uživatelé pak mohou ke službám a aplikacím přistupovat přes řadu uživatelských rozhraní. Například přes webové portály, tlusté klienty apod.
2.5 Web services a Business Process Execution Language
Business Process Execution Language je dalším základním stavebním kamenem Service Oriented Architecture a umožňuje tvorbu komponent informačního systému na základě propojení firemních procesů s webovými službami. Jan Matlis (viz [7]) popsal cíl BPEL takto: „Byl navržen, aby integroval množství aplikací, které jsou spouštěny k dosažení konkrétního podnikového cíle.“
V praxi se jedná o jazyk postavený na XML, který umožňuje namodelovat podnikové procesy a tyto procesy pak přímo ve vývojovém prostředí BPEL propojit se službami (viz. obrázek 3), které vykonávají funkcionalitu jednotlivých kroků podnikového procesu. Výstupem je přitom XML dokument, který je později interpretován serverem a tím je služba vykonána (spotřebována).
Obrázek 3: Propojení podnikových procesů a webových služeb
Problémem standardu BPEL je, že vznikl jako jazyk pro definování podnikových procesů postavených nad webovými službami. Současná verze BPEL standardu se proto jmenuje WS- BPEL 2.0 (Web Services BPEL). To však plně nepostačuje pro SOA, protože služby v rámci SOA nemusí být pouze webové, ale může se jednat o služby Java, .NET, nebo například o komunikaci s databází, apod. Bohužel, protože společnosti, které BPEL nabízejí, potřebují rozšíření tohoto jazyka, které by pokrylo ostatní technologické oblasti, vzniká řada specifických rozšíření jazyka BPEL, která se však již nedají považovat za standardizovaná. Standardizace je tedy do jisté míry omezena rozšiřujícími zásahy jednotlivých dodavatelů. Z toho následně vyplývá i problém interpretace BPEL dokumentů a potíže s kompatibilitou.
Hlavní výhoda BPEL spočívá v tom, že odděluje vrstvu podnikových procesů od programového kódu a tudíž zvyšuje flexibilitu informačního systému. Firemní procesy jsou nezávislé na změnách podkladových aplikací a tudíž při změně těchto aplikací není nutné
upravovat firemní procesy. Výstupem interpretace BPEL dokumentu je orchestrace webových služeb v rámci firemních procesů.
2.6 Výhody a nevýhody SOA
2.6.1 Technologické výhody
V této podkapitole jsou shrnuty všechny technologické výhody, které SOA přináší a které mohou být přínosem pro podnik, který se rozhodne informační systém na bázi Service Oriented Architecture budovat. Jednotlivé výhody této architektury v ohledu na IT/ICT byly postupně uváděny v předchozím textu, proto jsou zde již jen krátce sumarizovány. Základní pilíře SOA shrnuje Ronald Schmelzer (viz [8]) následovně: „SOA přináší výhody ve čtyřech základních kategoriích: snižuje náklady na integraci, zvyšuje znovupoužitelnost, zvyšuje flexibilitu a snižuje investiční riziko.“ Těchto výhod je dosaženo především změnou přístupu k architektuře IT/ICT řešení a aplikací, jak je zachyceno na následujícím obrázku.
Obrázek 4: Rozdíly mezi architektonickými přístupy, zdroj: [9]
První výhodou SOA je integrační hledisko. Díky možnosti volně provázat jednotlivé, dříve na sobě nezávislé aplikace pomocí standardizovaných nástrojů a technologií, lze získávat vyšší flexibilitu informačního systému. Díky tomu může dojít k úspoře nákladů nejen na integraci, ale i na následnou správu a změnu informačního systému, vyvolanou změnami požadavků podnikových procesů.
Integrační výhoda je tedy spojená s větší flexibilitou systému z hlediska jeho propojení na další systémy a rozšíření o další aplikace. SOA však zvyšuje i flexibilitu v rámci samotného systému a požadavků na jeho změny. To je dáno možností snadno přizpůsobovat informační systém novým a měnícím se požadavkům. Měnící se potřeby totiž vyvolávají nutné změny
v informačním systému na od sebe oddělených úrovních podnikových procesů a aplikační logiky.
Díky využití BPEL je možné měnit funkcionalitu IS pomocí přemapování podnikových procesů na podkladové služby, aniž by bylo nutné provádět větší programové úpravy v samotných aplikacích.
Znovupoužitelnost, ačkoli je jedním ze základních principů SOA, nemusí být u všech projektů významná, ale to bude zmíněno později. Nyní zůstaňme u faktu, že SOA napomáhá znovu využít již naprogramované služby a aplikace v rámci různých podnikových procesů a tím šetří čas programátorů i správců systému. Díky tomu opět může docházet ke zvýšení flexibility systému a ke snižování nákladů na jeho implementaci a provoz.
Z podnikatelského hlediska je nejdůležitějším přínosem architektonického přístupu SOA snížení investičního rizika. Díky možnosti postupné implementace systému či jeho částí dochází k rozdělení implementačního projektu na menší celky a tudíž i menší investice. Menší projekty se lépe řídí, proto je menší riziko jejich neúspěchu, který se u informačních systémů projevuje především špatným pokrytím podnikových potřeb, málo flexibilním řešením, zvýšenými náklady a prodlouženou implementační dobou.
2.6.2 Výhody a efekty SOA pro podnikání
Efekty, které SOA přináší podnikání jsou samozřejmě propojené s efekty, které přináší v IT/ICT.
Primární výhodou je zmiňované užší propojení podnikání na IT/ICT, které je dané orientací na podnikové procesy a jejich propojení na služby.
Základní přínosy SOA pro podnikání jsou vysvětleny v následující tabulce.
Přínos pro podnikání Odpovídající vlastnosti SOA
Snížení nákladů a zlepšení přehledu o investicích do IT/ICT
Možnost rozložení investic do menších projektů, postupné budování IS
Flexibilita a snadnější přizpůsobení IS změnám podnikatelských požadavků
Volné provázání jednotlivých částí IS
Zvýšení produktivity zaměstnanců, zkrácení podnikových procesů a snížení chybovosti
Automatizace činností, tvorba kompozitních aplikací a orchestrace nad různými
komponentami IS
Snazší navazování podnikových partnerství Využití standardů a služeb pro mezipodnikovou komunikaci
Tabulka 2: Přehled efektů SOA pro podnikání
2.6.3 Nevýhody
Nyní probereme některé nevýhody SOA a situace za kterých je pravděpodobné, že se s nimi podnik bude muset potýkat.
Jedním ze základních problémů při současném stupni vývoje, je počáteční nákladnost řešení na bázi SOA. Společnost BEA Systems (viz [10]) k tomu uvádí: „Využití SOA vyžaduje dodatečný návrh, vývojové úsilí a infrastrukturu, což se promítne do dodatečných nákladů. Proto nemusí být SOA vhodná architektura pro všechny případy.“ Je patrné, že pro některé aplikace je vhodnější SOA nevyužívat. Jedná se zejména o takové aplikace, které jsou nezávislé a nepotřebují být integrovány s ostatními aplikacemi, respektive jejich datovými zdroji. Informační systém na bázi SOA navíc vyžaduje vyšší počáteční investice do infrastruktury. Ačkoliv je problematika vyššího počátečního úsilí (finančního a potencionálně i časového) při implementaci u SOA poměrně často diskutována, nedá se k ní přistupovat zcela jednoznačně. Při implementaci informačního systému, jehož komponenty SOA využívají a které v sobě již mají zabudovanou funkcionalitu v podobě dostupných služeb, nemusí být implementace o nic složitější než v případě klasického informačního systému. Klíčovou roli v tomto případě bude hrát možnost snadné implementace pomocí BPEL.
Druhá nevýhoda je výkonnost systému, neboli performance. Je patrné, že performance aplikací na bázi SOA bude nižší, než u napevno naprogramovaných a úzce propojených aplikací.
Množství služeb, které spolu musí neustále komunikovat, řada volání těchto služeb a přenos dat a metadat přes síť, musí zákonitě zpomalovat chod a odezvu systému. „[…] robustnost a rozšiřitelnost má svou cenu. Ano, možná jste to uhodli. Je to výkonnost systému. Jakákoli architektura s volně propojenými částmi nemůže, přese všechnu optimalizaci, nikdy dosáhnout takové výkonnosti jako architektury s pevně propojenými prvky.“ Uvádí Kareemullah Quadri (viz [11]).Tento fakt je kompenzován tím, že hardware a síťové prvky neustále zvyšují svou rychlost, kapacitu a propustnost, čímž umožňují dosahování stále lepšího výkonu i u aplikací a IS postavených na SOA.
Mezi nevýhody SOA si zaslouží zařadit také marketingový informační rozruch, který se kolem tohoto architektonického přístupu v poslední době rozpoutal. Řada odborníků označuje SOA za tzv. buzzword, tedy slovo, o kterém se hodně mluví a píše a které je marketingově zneužíváno.
Kritika se objevuje i na stránkách Wikipedia (viz [12]): „Některé kritiky SOA jsou postavené na předpokladu, že SOA je pouze jiný název pro webové služby.“ Rozdíl mezi webovými službami a SOA byl vysvětlen již v kapitole 2.2 Úvod do SOA.
Pokud bychom hledali paralelu mezi rozruchem okolo SOA a tím co se děje v současnosti okolo Web 2.0 (označení pro moderní pojetí webových stránek a aplikací, založených na interaktivním uživatelském rozhraní, rich user interface, webových standardech, multimédiích,
masové komunikaci a vytváření komunitních sítí), pak dojdeme k tomu, že ačkoli oba termíny dosáhly značné míry zprofanovanosti, je neoddiskutovatelné, že už jen samotný rozruch přináší hybnou sílu, která obě oblasti udržuje v neustálém vývoji a přináší tak pozitivní efekty (byť tyto efekty mohou být zbytečně nadhodnocovány a marketingově zneužívány) v podobě nových technologií, standardů a postupů.
Pokud se rozhodneme využít SOA, pak narazíme ještě na řadu úskalí, které je třeba mít na paměti při vývoji a úpravách informačního systému. Těmto rizikům je věnována celá následující kapitola.
2.7 Analýza kritických míst p ř echodu na SOA
Při implementaci SOA je klíčové vycházet z kvalitní analýzy podnikových potřeb. Je důležité, aby SOA byla využívána pro podporu firemních procesů a zlepšení flexibility podnikového informačního systému, aby nesloužila „sama sobě“, tedy aby SOA nebyla využívána jen z principu, že jde o moderní trend. Kvalitním mapováním firemních procesů na funkcionalitu IS postaveném na SOA lze předejít vzniku nesouladu mezi IS/ICT a podnikáním.
Dalším kritickým místem je organizace a správa služeb. Vzhledem k podstatě SOA je pravděpodobné, že podnikový informační systém bude obsahovat velké množství služeb.
V případě, že podnik podcení jejich správu, může se podnikový IS snadno stát nepřehledný a správa a další vývoj náročný na čas. Tím mizí hlavní přednosti SOA. Dalším důsledkem špatné správy může být nedostatečná bezpečnost, v rámci správy služeb se totiž spravuje taktéž jejich bezpečnostní politika a pravidla. Otázka bezpečnosti dat je přitom pro většinu současných firem prioritou.
Také znovupoužitelnost služeb má svá úskalí. Lze jen těžko vytvořit službu tak, aby byla znovupoužitelná, pokud nemáme přesné odhady jejího potencionálního budoucího využití. Při tvorbě služeb je proto třeba brát v potaz její pozdější využití a je třeba snažit se vytvářet služby o co nejmenším rozsahu, jednotkách funkcionality. Tyto služby pak lze snadno organizovat do vyšších, komplexnějších celků.
Jindřich Štumpfl (viz [4]) k znovupoužitelnosti říká: „Je nutné být zároveň realistou a uvědomit si, že i v dobře navržených SOA systémech je obtížné docílit větší znuvupoužitelnosti než 30 až 40 %. Některé služby zkrátka patří jen jedné aplikaci nebo aplikační doméně.“
S předchozím bodem souvisí jiný problém, který spočívá naopak v příliš velkém počtu služeb a nadměrnému detailu. Důležité je, aby služba poskytovala jednotku funkcionality na základě požadavků podnikových procesů. Je dobré se vyhnout situaci, kdy vytvoříme řadu služeb,
přenášeny sítí ve velkém množství. Taková situace může mít řadu nepříznivých následků pro další funkčnost a správu IS a taktéž bude mít s největší pravděpodobností vliv na celkové náklady.
„Hlavními důsledky tohoto přístupu jsou snížení výkonu a nákladný vývoj. Navíc budou muset uživatelé vyvinout vyšší úsilí při agregaci těchto příliš detailních služeb, aby zjistili, jak spolu tyto služby použít a aby získali nějaký přínos.“ Uvádí studie, kterou publikovala společnost IBM (viz [3]).
Jak je patrné z předchozích dvou bodů, některá doporučení a postupy v rámci SOA si částečně protiřečí a je třeba vybírat důkladně správný přístup v závislosti na konkrétních potřebách podniku a požadavcích na IS.
V současné době může být rizikem při volbě SOA jako architektonického přístupu také nejednotnost standardů. Stejně tak, jako i v ostatních oblastech, kde dochází ke standardizaci, dochází také k tomu, že si jednotliví hráči na trhu SOA standardy přizpůsobují a rozšiřují, čímž vznikají rozdílnosti a snižuje se tak přenositelnost a kompatibilita. Integrace částí IS od různých dodavatelů tak může být větším problémem než se předpokládalo, i přes velkou snahu jednotlivé technologie využívané v rámci SOA standardizovat.
Z hlediska bezpečnosti je třeba zabezpečit informační systém stejně jako každý jiný.
Důležité přitom je, uvědomit si, že funkcionalita informačního systému v rámci SOA je dána k dispozici jako služba obvykle na portu 80, tedy na běžném portu, na kterém pracují webové servery. Každý, kdo zná URL této služby, k ní pak může přistupovat a využívat jí. Při výběru dodavatele platformy IS, by mělo být jedním z požadavků, aby u jednotlivých služeb bylo možné podrobně nastavit pravidla pro přístup.
Možná nejvýznamnějším faktorem je inkrementální vývoj IS, který SOA umožňuje. Díky tomu je možné velké projekty rozdělit na menší celky a funkcionalitu informačního systému implementovat postupně po menších projektech. Lze se tak vyhnout situaci běžné pro tradiční vývoj a nasazování IS. Nasazování IS totiž bývá velkým projektem, který trvá řadu měsíců (někdy i let) a během tohoto projektu se nezřídka změní firemní procesy a potřeby, a to vede ke zmaření investice a k nákladnému předělávání systému. Bohužel, i při nasazování SOA, může dojít k podobné situaci. V článku o SOA, který publikovala společnost Microsoft (viz [13]) je uvedeno:
„V některých organizacích stráví 18 až 30 měsíců tvorbou infrastruktury služeb. Když konečně začnou služby využívat, zjistí, že se podnikové potřeby změnily a investice byly pouze ztrátou peněz a času.“ Je proto velmi důležité zvážit rozsah projektu a správně naplánovat jeho harmonogram a rozdělení na dílčí podprojekty.
2.8 Shrnutí
Závěrem oddílu zabývajícím se Service Oriented Architecture přichází na řadu shrnutí poznatků o tomto architektonickém přístupu, jeho výhodách a rizicích.
Přechod na SOA je jednoznačným trendem v oblasti podnikových informačních systémů. Vývoj trhu odhaduje agentura WinterGreen Research (viz [14]): „Očekává se, že trh Service Oriented Architecture (SOA), který v roce 2004 dosahoval 187 milionů dolarů, dosáhne 17,7 miliard dolarů v roce 2011. Růst trhu je dán tím, že SOA poskytuje flexibilní IT architekturu, která je potřeba při reakci na změny trhu vyvolávané zrychlenými produktovými cykly a konkurenčními boji.“
Jedná se o další přirozený vývojový stupeň v oblasti tvorby, implementace a integrace software. SOA je postavena na principu volného provázání aplikací a součástí informačního systému a umožňuje tak snazší integraci a zvyšuje jeho flexibilitu.
Tento architektonický přístup je využitelný ve třech základních oblastech vývoje, provozu a správy informačních systémů. Jedná se o integraci, vývoj kompozitních aplikací a modernizaci stávajících aplikací a systémových platforem.
Základním stavebním kamenem SOA je služba, neboli jednotka funkcionality. Tyto služby lze pomocí Business Process Execution Language propojovat a organizovat do vyšších a komplexnějších funkčních celků, které lze mapovat přímo na definované podnikové procesy. Díky tomu dochází k oddělení vrstvy podnikových procesů a služeb a podkladových aplikací a ke zvýšení flexibility a usnadnění správy systému.
Mezi základní výhody SOA patří snazší integrace, vyšší znovupoužitelnost programových částí (služeb), vyšší flexibilita a nižší investiční riziko, dané možností postupného budování systému a rozdělení implementace na menší projekty.
Nevýhody a kritická místa přechodu na SOA jsou dány zejména mládím tohoto architektonického přístupu a některými jeho porodními bolestmi, které se promítají do neúplnosti a nedostatečnosti standardů, vyšších počátečních investic do infrastruktury systému, či nižší výkonnosti.
SOA je bezpochyby cesta, kterou se budou současné informační systémy ubírat, a proto je třeba porozumět jejím výhodám, a při rozhodnutí o jejím využití se vyvarovat úskalím, která jsou uvedena v předchozí kapitole.
V následujícím oddíle Oracle Fusion Middleware přijde na řadu využití principů SOA v praxi, při budování technologické a aplikační platformy pro moderní informační systém.
3 Oracle Fusion Middleware
3.1 Moderní základna pro informa č ní systémy
Oracle Fusion Middleware je rozsáhlá (a nadále velmi rychle rostoucí) rodina software. Jedná se o technologickou a aplikační základnu pro moderní informační systémy. Tato základna je postavena na principech SOA. Na rozdíl od běžného middleware, který má za úkol plnit integrační roli mezi jednotlivými aplikacemi a umožňovat tak výměnu dat mezi jednotlivými částmi informačního systému, má Oracle Fusion Middleware, v souladu s moderními trendy v oblasti middleware, širší pole působnosti. Jeho cílem je pokrýt i další oblasti, které jsou nutné pro fungování informačního systému. Jedná se zejména o vývoj a správu tohoto systému. K tomuto účelu má Fusion Middleware řadu dalších nástrojů, které jsou zmíněny později.
Dříve než přijde na řadu samotná analýza Oracle Fusion Middleware, uvedu k čemu vlastně middleware slouží a k jakým účelům je vhodné ho v organizaci použít. Obrázek 5 zachycuje hlavní využití middleware ve společnostech, jejichž zástupci se zúčastnili průzkumu společnosti The Strategy Group v prosinci roku 2005.
Obrázek 5: Primární využití middleware v organizaci, zdroj: [1]
Jak již bylo řečeno, middleware slouží primárně jako integrační platforma pro informační systémy. Je tedy jakousi podkladovou vrstvou v rámci jejich architektury. Podle průzkumu The Strategy Group je druhým nejčastějším využitím middleware vrstvy optimalizace provozní činnosti podniku. To je spojené s integrační funkcí a jedná se například o automatizaci přenosu dat o zákaznících mezi systémy. Mezi další využití middleware patří možnost globálního pohledu na data pomocí BI, vývoj nových aplikací a služeb, nebo zlepšení bezpečnosti dat a s tím spojený identity management.
Oracle Fusion Middleware pokrývá všechny výše zmíněné oblasti využití middleware a podrobněji to bude zmíněno v následujících kapitolách.
3.2 Oracle Fusion
Oracle Fusion Middleware by v první řadě měl sloužit jako technologická a aplikační infrastruktura pro Oracle Fusion. Oracle Fusion je nový koncept informačního systému, tak jak jej v brzké době plánuje uvést společnost Oracle. Princip spočívá v tom, že informační systém již nebude tvořen (a dodáván) jako jeden ucelený balík, ale společnost, která bude nový systém pořizovat, si bude moci vybrat pro pokrytí různých podnikových procesů různé aplikace, které budou poté za využití SOA a Oracle Fusion Middleware propojeny.
V rámci této iniciativy uskutečňuje v posledních letech Oracle svou poměrně agresivní akviziční politiku. Skupuje tzv. „best-of-breed“ společnosti, které kvalitativně dominují svým produktem nebo produktovou řadou určitému segmentu trhu. Produkty těchto společností se Oracle chystá upravit do takové podoby, aby bylo možné je propojit pomocí SOA a Fusion Middleware v jeden funkční celek.
Uveďme si několik nejvýznamnějších společností, které Oracle v posledních letech ovládl (viz [15]). V roce 2005 Oracle ovládl společnost PeopleSoft a získal tak nejen jejich ERP produkt PeopleSoft Enterprise, ale taktéž ERP systémy společnosti JD Edwards, která byla ovládnuta PeopleSoftem v roce 2003 (viz [16]). V roce 2006 se součástí Oracle stala společnost Siebel, vedoucí poskytovatel CRM řešení ve světě. V roce 2007 pak Oracle provedl akvizici firmy Hyperion. Tato firma patřila k vedoucím společnostem v oblasti Enterprise Performance Managementu a Business Inteligence.
Další kroky, které Oracle pro podporu svého nového řešení podniká spočívají v postupné úpravě aplikací stávajících informačních systémů (E-Business Suite, PeopleSoft, JD Edwards, Siebel …) tak, aby je bylo možné snadno integrovat pomocí Fusion Middleware. Tyto úpravy spočívají zejména ve zpřístupnění funkcionality těchto aplikací v podobě služeb, které jsou dále využívány v rámci SOA.
Přínosy tohoto přístupu jednoznačně spočívají ve vyšší flexibilitě systému, ve větší možnosti výběru a tudíž v lepším splynutí informačního systému s potřebami podnikových procesů a zejména pak v možnosti postupného budování informačního systému po částech.
3.3 Oblasti využití Oracle Fusion Middleware
Z výše uvedených informací vyplývá, že Oracle Fusion Middleware musí pokrývat veškeré technologické zázemí informačního systému. Fusion Middleware navíc poskytuje taktéž vývojové nástroje a jedná se tak o velmi široký balík software. Vzhledem k současné agresivní akviziční politice, kterou Oracle provozuje, se dá předpokládat, že se toto řešení bude nadále rozšiřovat o další komponenty. Je třeba dodat, že při implementaci Oracle Fusion Middleware není nutné nasazovat všechny jeho součásti, ale je možné vybrat pouze potřebné komponenty. Jedná se tedy o modulární balík software, který je přizpůsobitelný potřebám podniku. Jednotlivé součásti pokrývají v současnosti následující oblasti informačních systémů (viz [17]):
1) Vývoj aplikací a komponent IS, 2) integraci,
3) orchestraci (správa podnikových procesů a kompozitních aplikací) 4) provoz,
5) správu, 6) bezpečnost,
7) analýzu dat (Business Intelligence), 8) přístup (prezentační logiku).
Klíčové oblasti funkcionality Oracle Fusion Middleware a nástroje, které je zajišťují jsou uvedeny níže. Důraz je kladen zejména na pochopení vztahu tohoto balíku a Service Oriented Architecture a ilustraci využití jednotlivých principů tohoto architektonického přístupu v rámci middlewaru. Výhody využití Fusion Middleware a jeho funkcionality jsou uvedeny jednak v následujících podkapitolách a jednak v kapitole 4 Analýza využití Oracle Fusion Middleware.
3.3.1 Vývoj aplikací a komponent IS
Fusion Middleware poskytuje několik nástrojů pro vývoj aplikací. Základem pro vývoj jsou principy Service Oriented Architecture a Java 2 Platform, Enterprise Edition (J2EE). Jako hlavní nástroje pro vývoj pak slouží Oracle JDeveloper a Oracle BPEL Designer (Oracle BPEL Designer
se někdy též uvádí pod jménem Oracle BPEL Process Manager a je možné ho nainstalovat jako součást JDeveloperu).
JDeveloper je integrované IDE (Integrated Development Environment) pro vývoj Java aplikací, ale umožňuje taktéž práci s XML (XML, XSLT, HTML), webovými službami (WSDL, SOAP) a SQL (a PL/SQL). Výhodou JDeveloperu je integrovaný UML modelovací nástroj, který umožňuje tvorbu řady diagramů (use case diagramy, class diagramy, data diagramy, business proces diagramy a další). Součástí tohoto CASE nástroje je taktéž debugger. Práce v programu je zachycena na obrázku 6.
Ačkoliv je JDeveloper primárně vytvářen pro produkty Oracle (Oracle Application Server a Oracle Database), jeho výhodou je možnost propojení na jakýkoliv J2EE kompatibilní aplikační server a na libovolnou databázi umožňující připojení přes JDBC.
U vývojových nástrojů tohoto balíku je patrná orientace na SOA. Nástroje jsou zaměřené na vývoj, nasazování a správu služeb v rámci tohoto architektonického přístupu. Umožňují modelovat procesy, programovat aplikace, vytvářet služby, zpřístupnit je aplikačnímu serveru a pomocí BPEL je propojit na podnikové procesy a zpřístupnit uživatelům.
Jako hlavní výhoda těchto nástrojů se jeví snadné ovládání pomocí grafických nástrojů. Není tedy nutné vše programovat ve zdrojovém kódu, ale mapování podnikových procesů na služby mohou pomocí grafických CASE nástrojů provádět analytici bez potřeby hlubších znalostí programování. Tímto je také podporován princip znovupoužitelnosti, kdy jednotlivé služby mohou být opakovaně mapovány pod různé podnikové procesy.
Obrázek 6: Konceptuální datový model v JDeveloperu
3.3.2 Integrace
Hlavní výhodou Fusion Middleware je, že díky využití principů a technik SOA, umožňuje integrovat a sdílet data mezi aplikacemi a dílčími informačními systémy od různých výrobců na standardizovaném základě. Díky tomu není problém globálně spravovat a pracovat s daty, která sdílí například SAP a Oracle Siebel CRM. Fusion Middleware umožňuje integraci nejen mezi aplikacemi Oracle, ale díky využití standardů SOA taktéž integraci aplikací jiných dodavatelů.
Díky SOA je taktéž možné integrovat aplikace balíkové s aplikacemi vytvořenými na míru (typové a individuální součásti podnikového IS).
Integrace může mít dvě základní podoby. V prvním případě se jedná o výměnu dat mezi dvěmi aplikacemi a jejich synchronizaci. Příkladem může být synchronizace dat mezi mySAP ERP a Oracle Siebel CRM. V druhém případě jde o centralizaci dat. K tomu slouží Oracle Data Hubs.
Integrace jako taková je základní funkcionalitou, kterou middleware poskytuje. Přednost Oracle Fusion Middleware spočívá v integraci na bázi otevřených standardů.
3.3.3 Orchestrace
V rámci balíku jsou k dispozici vývojové nástroje (JDeveloper), které umožňují spravovat, analyzovat a modelovat podnikové procesy a propojovat je na služby informačního systému. Díky tomu je uživatelům zpřístupněna potřebná funkcionalita.
Orchestrací se rozumí definování podnikových procesů a služeb a jejich skládání do funkčních celků pomocí BPEL. Orchestrace probíhá jak v rámci vývoje kompozitních aplikací tak v případě integrace jednotlivých částí informačního systému na bázi SOA. V rámci orchestrace je tedy možné propojovat vzájemně jednotlivé služby a vytvářet tak složitější služby kompozitní, tyto služby následně propojit s podnikovými procesy (které je zde taktéž možné modelovat) a tím jsou vytvářeny kompozitní aplikace. Výhoda tohoto přístupu spočívá ve vysoké flexibilitě takto poskládaných aplikací a na možnosti přizpůsobovat jednotlivé vrstvy bez nutnosti změny vrstev ostatních.
Podpora SOA je zajištěna pomocí BPEL CASE nástroje, který umožňuje práci pomocí grafického rozhraní. Schéma nad jakými technologiemi BPEL pracuje zachycuje obrázek 7.
Obrázek 7: Schéma vývoje a nasazení BPEL, propojení podnikových procesů a služeb, zdroj:
[18]
3.3.4 Provoz
Aplikační server je ve své podstatě srdcem celého balíku. Provoz jednotlivých aplikací informačního systému je v rámci Oracle Fusion Middleware zajištěn aplikačním serverem Oracle Application Server (v současnosti verze 10g). Základními součástmi jsou webový server Apache a J2EE server pro provoz Java aplikací a služeb.
Aplikační server je integrován s vývojovým a integračním prostředím a podporuje zásady SOA. Samozřejmostí je tudíž podpora standardů XML, SOAP, WSDL apod., potřebných pro provoz (nejen webových) služeb.
Aplikace, které běží nad aplikačním serverem je možné postupně přidávat a navíc zátěž rozkládat na více serverů, protože Oracle Application Server 10g podporuje grid infrastrukturu.
Proto není problém do stávajícího informačního systému přidávat další aplikace a ty poté pomocí BPEL integrovat se stávající funkcionalitou.
Výhody aplikačního serveru Oracle oproti konkurenci zhodnotila agentura Forrester Research, Inc. Ve svém průzkumu trhu aplikačních serverů (viz [19]).
Obrázek 8: Srovnání aplikačních serverů hlavních dodavatelů, zdroj: [19]
Z přehledu na obrázku 8 je patrné, že produkt Oracle dominoval v oblastech jako je podpora standardů, správě serveru, podpoře vývoje aplikací a koncepci architektury. Poměrně překvapující na průzkumu je silné postavení Oracle v oblasti penetrace trhu (hodnotící kritérium Installed base), naopak zcela v souladu se zjištěními této práce je vysoké hodnocení v oblasti produktové strategie.
3.3.5 Analýza
Díky volnému propojení aplikací v rámci SOA a možnosti sdílet data mezi aplikacemi na bázi otevřených standardů byly do Oracle Fusion Middleware začleněny také nástroje, které běžně bývají nadstavbou ERP systémů, a které, buď prolínají celým informačním systémem a organizací nebo umožňují globální pohled na data. Jedná se o systémy Oracle Business Inteligence (BI) a Oracle Business Activity Monitoring (BAM).
První systém zajišťuje globální pohled na data shromažďovaná v ERP (a dalších) systémech, druhý zajišťuje za využití metodiky Key Performance Indicators (KPI) sledování výkonnosti podniku.
Začlenění těchto systémů do middleware balíku jasně poukazuje na využití možností SOA.
Výhody tohoto řešení budou předmětem analýzy v rámci kapitoly 4 Analýza využití Oracle Fusion Middleware.
3.3.6 P ř ístup a prezenta č ní logika
Pokud začlenění analytických aplikací do Oracle Fusion Middleware jasně poukazovalo na pozitivní přínosy využití SOA jako architektonického základu informačního systému, pak pro oblast přístupu to platí v nezměněné míře.
Přístupem v tomto případě rozumíme přístup uživatelů k datům a informacím. Ten se v rámci Fusion Middleware dělí na dvě roviny.
V první řadě se jedná o přístup k výstupům informačního systému. Zde je díky využití SOA možné vytvořit jednotné uživatelské rozhraní, Oracle Portal, které může sloužit k zobrazení veškerých dat a informací přístupných v rámci informačního systému a jeho součástí, od ERP přes CRM k BI nebo BAM. Výhody tohoto řešení jsou patrné na první pohled. Dochází ke sjednocení grafického uživatelského rozhraní, uživatel nemusí pracovat s rozličnými rozhraními, čímž je mu usnadněna orientace, potenciálně zrychlena jeho práce a omezeny uživatelské chyby.
Druhou rovinou uživatelského přístupu je hromadná spolupráce uživatelů. Jedná se o komunikační kanály a úložiště dokumentů. Součástí Fusion Middleware je Oracle Collaboration Suite, což je komunikační prostředí, které zajišťuje podnikovou komunikaci.
3.4 Architektura Oracle Fusion Middleware
Pro lepší ilustraci, jak tato platforma funguje a jak jsou její jednotlivé části uspořádány následuje kapitola zabývající se architekturou Oracle Fusion Middleware.
Obrázek 9: Architektura Oracle Fusion Middleware, zdroj: [20]
Bylo již řečeno, že základem jsou služby v rámci SOA. Ty běží na aplikačním serveru Oracle Application Server, který, jak je patrné i z obrázku 9, tvoří jádro tohoto softwarového balíku. Aplikační server je uzpůsoben pro práci nad grid infrastrukturou. V místě, kde se na obrázku nachází aplikační server, by se pravděpodobně také ve výsledném informačním systému nacházela databáze.
Nad aplikačním serverem běží systémy zajišťující provoz a správu služeb, jejich komunikaci a podle obrázku dále systémy monitorující výkonnost podniku. Zde bych možná volil jiné znázornění než Oracle. Systémy BAM a BPM systémy bych přesunul na úroveň BI systémů.
Zastřešující vrstvu tvoří uživatelská rozhraní, tedy místa, kde dochází ke komunikaci uživatele s daty v systému.
V rámci celého systému lze využívat sadu vývojových nástrojů. Stejně tak celým systémem prostupuje systém pro správu uživatelů (Identity management), který zajišťuje, mimo jiné, bezpečnost v rámci informačního systému.
Poslední oblastí v rámci architektury Oracle Fusion Middleware je rozhraní pro správu systému. V případě Oracle se jedná o Enterprise Manager, který integruje všechny řídící prvky do jednoho prostředí, odkud je možné spravovat celý informační systém z technické stránky.
Výhodou architektury Oracle Fusion Middleware je její otevřenost dalšímu rozšíření. Díky podpoře otevřených standardů je snadné po částech doplňovat potřebnou funkcionalitu.
4 Analýza využití Oracle Fusion Middleware
4.1 Úvod
V této kapitole se pokusím analyzovat možné přínosy, případně hrozby, využití balíku Oracle Fusion Middleware ve společnosti, která se rozhodne implementovat systém na bázi SOA.
Přínosy se dělí do dvou oblastí. Prvním je rozhodnutí použít architektonický přístup SOA.
Přednosti a rizika byly rozebrány v oddíle věnovaném Service Oriented Architecture. Druhou oblastí přínosů jsou pak přímo efekty dosažené implementací Oracle Fusion Middleware.
Při hodnocení přínosů Oracle Fusion Middleware přijde nejprve na řadu globální pohled na volbu informačního systému. Jedná se o rozhodnutí, zda implementovat integrovaný balík nebo zda informační systém poskládat ze samostatných aplikací, které jsou integrovány na middleware vrstvě. Middleware totiž může do značné míry ovlivnit možnosti zvoleného konceptu informačního systému.
V další části přijde na řadu analýza přínosů technologického řešení Oracle Fusion Middleware. Klíčovou otázkou je nakolik tato platforma naplňuje principy SOA a v jaké míře umožňuje využít výhody tohoto architektonického přístupu.
Následuje část, která se zabývá hlavními otázkami, které by měl IT management zodpovědět před tím, než vybere pro implementaci konkrétní middleware. Zároveň tato podkapitola zkoumá nakolik Oracle Fusion Middleware uspokojí potřeby, které tyto otázky reprezentují.
4.2 Volba konceptu informa č ního systému
V případě, že se společnost rozhodne zavést nový informační systém, existuje řada rozhodnutí, které musí učinit. V první řadě se jedná o rozhodnutí, zda vyvinout vlastní informační systém (IASW), nebo zda využít některý z nabízených hotových produktů (TASW). Tato práce se zabývá výhradně druhým typem informačních systémů.
V rámci TASW má společnost na výběr mezi komplexními all-in-one integrovanými balíky a poskládáním informačního systému z best-of-breed software, který nejlépe vyhovuje potřebám v dané oblasti působnosti společnosti. Následující podkapitoly mají za úkol analyzovat výhody a nevýhody jednotlivých přístupů (viz [21]).
4.2.1 All-in-one integrovaný informa č ní systém
Informační systém dodávaný jako integrovaný balík má za úkol komplexně pokrýt potřeby podniků ve všech oblastech jejich působení od financí přes řízení projektů až po řízení lidských zdrojů. Jedná se například o balíky Oracle E-Business Suite, JD Edwards EnterpriseOne, MySAP ERP nebo Microsoft Dynamics AX.
Výhoda těchto robustních řešení spočívá zejména v tom, že stačí pouze přizpůsobit (customizovat) jejich funkcionalitu podnikovým procesům (případně provést reengeneering podnikových procesů) a není třeba provádět složitou systémovou integraci v rámci samotného řešení.
Možná klíčová výhoda spočívá v tom, že společnost, pořizující integrovaný systém, nemusí složitě vybírat a nakupovat jednotlivé dílčí aplikace pro kompletní pokrytí své činnosti. Nákupní a rozhodovací proces je tedy značně zjednodušen.
Nevýhodou all-in-one balíků spočívá v tom, že společnost nakoupí i funkcionalitu, kterou nemusí nutně využít, ale která je součástí dodávaného produktu. Jde tedy o vyšší počáteční investici. Navíc, ve většině případů, má společnost menší možnosti parametrizace produktu podle svých potřeb, protože velké balíky bývají méně flexibilní.
Nákup integrovaného balíku je vhodný zejména pro větší společnosti (ačkoliv trendem poslední doby je pronikání odlehčených integrovaných řešení i do oblasti SMB), které lépe využijí komplexní funkcionalitu a které mají dlouhodobě plánovanou IT/ICT strategii, která jim umožní dlouhodobě s nakoupeným produktem pracovat a využít tak vysokou počáteční investici.
4.2.2 Kombinace best-of-breed software
Poskládání informačního systému ze specializovaných aplikací má svá specifika, která je třeba předem důkladně zhodnotit. V první řadě je třeba zvážit rozsah výsledného informačního systému.
Informační systém, kde by bylo potřeba integrovat velké množství samostatného software (přičemž slovo velké lze jen těžko definovat a je třeba důkladně zhodnotit konkrétní situaci) sice bude možné důkladně podřídit podnikovým potřebám, ale náklady na integraci a čas, potřebný pro implementaci, by pravděpodobně narostl do nepřijatelných relací.
Tento přístup je tedy vhodný spíše pro menší společnosti, které mají specifické požadavky.
Nákup jednotlivých aplikací přináší výhodu v rozdělení implementace do menších částí a taktéž v lepším přehledu o investicích do IS. Best-of-breed software navíc poskytuje detailnější funkcionalitu oproti prvnímu přístupu.
V případě složitějších požadavků na informační systém, se jako lepší způsob jeví kombinace integrovaného balíku se specializovanými aplikacemi. Nicméně tato cesta vyžaduje dodatečné investice.
4.2.3 Vývoj na trhu ERP systém ů
Trendem na trhu ERP systémů se ukazuje zvyšování podílu all-in-one informačních systémů. Zatímco v roce 2001 byl podíl best-of-breed ERP systémů na trhu 39%, v roce 2005 to bylo již jen 26%.
Obrázek 10: Trh ERP systémů v ČR v letech 2001 – 2005, zdroj: [22]
Tento trend se pokusím vysvětlit několika faktory. Prvním faktorem je zvyšující se orientace na malé a střední podniky (SMB). Ta se projevuje nabídkou odlehčených integrovaných balíků (někdy nazývané jako lite verze). Tyto balíky jsou zaměřeny zejména na malé a střední firmy, pro které je pořízení velkého integrovaného informačního systému finančně a časově neúnosné. Navíc firmy v sektoru SMB mají většinou vyšší požadavky na změny, prostředí ve kterém se pohybují je turbulentnější, a proto jsou pro ně odlehčené produkty kombinované s best- of-breed softwarem ideální volbou. To, že se na trh SMB začínají orientovat i velcí dodavatelé informačních systémů dokazují produkty jako například SAP Business One, nebo Oracle Business Accelerators for JD Edwards EnterpriseOne (přednastavené řešení JD Edwards EnterpriseOne).
Dalším faktorem, který může situaci na trhu ovlivňovat je fakt, že velcí dodavatelé IT/ICT řešení začínají skupovat menší firmy vyvíjející best-of-breed produkty. Produkty těchto firem jsou následně začleňovány do řešení, které velcí dodavatelé poskytují. Zde se dostáváme k přednostem, které přináší architektonický přístup SOA. V následujícím oddíle se proto podíváme, jak do této situace zapadá Oracle Fusion Middleware a co tato platforma přináší.
