Použití CASE nástrojů pro řízení architektury SOA

Transkript

Použití CASE nástrojů pro řízení
architektury SOA
Semestrální práce předmětu 4IT450
Vypracovali: Tomáš Bauer, Radek Škrabal, Tomáš Dohnal, Martin Olšovský
Hlavní specializace: Informační systémy a technologie
Kurz 4IT450: LS 2009/2010
Obsah
1
Úvod ................................................................................................................................................ 5
2
Úvod do SOA (Service Oriented Architecture) ................................................................................. 6
3
2.1
Základní pilíře SOA................................................................................................................... 7
2.2
Hlavní přínosy SOA pro oblast podnikání ................................................................................ 8
2.3
Hlavní přínosy SOA pro oblast IT ............................................................................................. 8
2.4
Nevýhody SOA ......................................................................................................................... 9
2.5
Životní cyklus SOA ................................................................................................................. 10
2.5.1
Expose (návrh) ............................................................................................................... 10
2.5.2
Compose (kompozice) ................................................................................................... 10
2.5.3
Consume (konzumace) .................................................................................................. 10
2.6
Referenční rámec SOA ........................................................................................................... 11
2.7
Zjednodušený model zralosti služeb aplikovaný na SOA ...................................................... 12
SOA od Oracle................................................................................................................................ 14
3.1
3.1.1
Integrované servisní prostředí ...................................................................................... 15
3.1.2
Oracle BPEL Process Manager ....................................................................................... 15
3.1.3
Oracle ESB (Enterprise Service Bus) .............................................................................. 16
3.1.4
Oracle Integration BAM (Business Activity Monitoring) .............................................. 16
3.1.5
Oracle Business Rules .................................................................................................... 17
3.1.6
Oracle UDDI registr ........................................................................................................ 17
3.1.7
Oracle Web Services Manager ...................................................................................... 18
3.1.8
Oracle Application Server .............................................................................................. 19
3.2
4
Co nabízí Oracle SOA Suite?................................................................................................... 14
Životní cyklus Oracle SOA aplikace ........................................................................................ 19
Mashup aplikace............................................................................................................................ 20
4.1
4IT450
Co je mashup? ....................................................................................................................... 20
Stránka 2
4.1.1
Konzumní mashup ......................................................................................................... 20
4.1.2
Datový mashup .............................................................................................................. 21
4.1.3
Business (podnikový) mashup ....................................................................................... 22
4.2
Oblasti nasazení mashups ..................................................................................................... 23
4.3
Mashups a role při vývoji....................................................................................................... 24
4.3.1
IT oddělení ..................................................................................................................... 24
4.3.2
Outsourcingová firma .................................................................................................... 24
4.3.3
Specializovaná firma ...................................................................................................... 24
4.3.4
Business uživatelé.......................................................................................................... 25
4.3.5
Náklady na tvorbu a provoz........................................................................................... 26
4.4
4.4.1
Přínosy nasazení ............................................................................................................ 30
4.4.2
Technologie nástroje Business Mashups....................................................................... 30
4.4.3
Oblasti nasazení............................................................................................................. 30
4.5
5
Business Mashups firmy Serena ............................................................................................ 27
Aris MashZone ....................................................................................................................... 31
4.5.1
Náklady na Aris MashZone ............................................................................................ 31
4.5.2
Klíčová funkcionalita Aris MashZone ............................................................................. 32
4.5.3
Jak vytvořit mashup v Aris MashZone ........................................................................... 33
4.5.4
Výhody a nevýhody Aris MashZone .............................................................................. 34
Zdroje............................................................................................................................................. 35
5.1
4IT450
SOA a Mashup nástroje ......................................................................................................... 36
Stránka 3
Seznam obrázků
Obrázek 1: Životní cyklus SOA. *4+ ......................................................................................................... 10
Obrázek 2: Referenční rámec SOA. ....................................................................................................... 11
Obrázek 3: Model zralosti SOA. *9+ ....................................................................................................... 13
Obrázek 4: Schéma Oracle SOA Suite [19] ............................................................................................ 15
Obrázek 5: Schéma Oracle BPEL Process Manager *19+........................................................................ 16
Obrázek 6: Schéma Oracle BAM *19+ .................................................................................................... 17
Obrázek 7: Schéma Oracle Service Registry *19+................................................................................... 18
Obrázek 8: Schéma životního cyklu Oracle SOA aplikace *19+ .............................................................. 19
Obrázek 9: Ukázka Google Mashup Editoru. ......................................................................................... 21
Obrázek 10: Ukázka nástrojů WebSphere sMash. ................................................................................ 22
Obrázek 11: Ukázka nástroje Business Mashups od firmy Serena. ....................................................... 23
Obrázek 12: Příklad vývojového prostředí pro business mashup. ........................................................ 25
Obrázek 13: Nástroj Serena Business Mashups (TeamTrack). .............................................................. 27
Obrázek 14: Ukázka editoru pro návrh webových formulářů. .............................................................. 28
Obrázek 15: Možnosti historie a reportingu nástroje Business Mashups. ............................................ 29
Obrázek 16: Ukázka Mashup aplikace v prostředí ARIS MashZone *20+ ............................................... 31
Obrázek 17: Editor ARIS MashZone – modelování datových vláken *20+ ............................................. 34
4IT450
Stránka 4
1 Úvod
Servisně orientovaná architektura představuje způsob projektování informačních systémů
založených na službách. V poslední době se o SOA mluvilo v negativním duchu, jako o technologii,
která je zastaralá a bude brzy nahrazena cloud computingem, SaaS, mashupy a jinými
architektonickými přístupy závislými na službách. Opak je však pravdou.
SOA nejenže není „mrtvá“, ale naopak se začíná stále více uplatňovat. Diskuze o SOA se posunula od
témat „Jak implementovat SOA“ k tématům, jak ji využít v byznysu spolu s dalšími technologiemi.
Analytická společnost IDC ve své předpovědi uvádí, že výdaje na SOA se mezi roky 2008 – 2013 zvýší
v Severní Americe o bezmála 25 procent a v Evropě o 24 procent [11]. SOA se tak stává součástí celé
řady nových projektů a vhodně se doplňuje s cloud computingem a mashup aplikacemi.
Důkazem těchto předpovědí může být i fakt, že americké námořnictvo se nedávno rozhodlo podpořit
projekt založený na SOA - Wave System of Systems (Wave-SOS), který by měl vytvořit rámec pro
sloučení a analýzu informací z mnoha vzdálených zdrojů a poskytnout tak jasnější obraz velitelům
ponorek [13].
V naší práci na téma „Použití CASE pro řízení architektury SOA“ jsme se rozhodli zaměřit zejména na
novou oblast tzv. mashup aplikací, které vhodně využívají právě architekturu SOA.
Práce se skládá ze tří hlavních částí, přičemž první část navazuje na předchozí výsledky našich kolegů.
První část tedy předkládá úvod do problematiky servisně orientované architektury a jsou zde zmíněny
základní pilíře SOA, přednosti a nedostatky této architektury a její životní cyklus.
Druhá část obsahuje popis SOA architektury z pohledu společnosti Oracle, která je jedním z předních
dodavatelů SOA na trhu. Konkrétně je zde popsána řada aplikací Oracle SOA Suite, která obsahuje jak
nástroje pro procesní řízení, tak integraci aplikací a webové služby.
V poslední části, která tvoří hlavní část naší práce, se čtenář dozví o tom, co to vlastně tzv. mashup
aplikace jsou, jak je můžeme klasifikovat a k čemu jsou vhodné. Bude zde také diskutována role
mashups při vývoji. Na závěr jsme vybrali několik významných zástupců v oblasti mashup aplikací,
které jsme se pokusili detailněji popsat.
Cílem práce je tedy nejen teoreticky představit servisně orientovanou architekturu, ale zejména
popsat problematiku tzv. mashup aplikací, které využívají vlastní CASE nástroje, a vhodně využívají
spojení právě se servisně orientovanou architekturou.
4IT450
Stránka 5
2 Úvod do SOA (Service Oriented Architecture)
SOA, neboli servisně orientovaná architektura, je přístup k organizování IT zdrojů pomocí jednotného
řešení, které má za cíl maximální zvýšení flexibility managementu v podniku. Architektura SOA
pomáhá vzájemně provázat jednotlivé interní a externí procesy. [3] Toto provázání je možné i napříč
organizacemi, tudíž lze propojit společnost s externími partnery, dodavateli, zákazníky apod. Toto s
sebou přináší velkou pružnost a možnost přizpůsobení se a zefektivnění činností. *5+ Díky takovému
propojení lze velmi rychle reagovat na nové požadavky. SOA je také schopna snížit procesní
náročnost fungování infrastruktury ve společnosti. Další velkou výhodu, kterou s sebou SOA přináší,
je její modulární infrastruktura, ve které lze měnit jednotlivé komponenty dle aktuálních požadavků.
Součástí je také používání otevřených standardů. Integrace z pohledu SOA neprobíhá pomocí
klasického propojení, ale na bázi procesního řízení. Jelikož SOA ve velkém podporuje možnost
znovupoužitelnosti, přináší velmi efektivní využívání již naprogramovaných aplikací. *8+ SOA také
přináší standardizaci stávající infrastruktury a zjednodušení prostředí, čímž pomáhá zvýšit kontrolu
managementu nad firemními procesy. Implementaci architektury SOA lze chápat jako životní cyklus,
tzn. po jednotlivých fázích. [1] [2]
Lze také říci, že SOA je nástrojem pro integraci různorodých systémů a aplikací. Každý IT prostředek,
systém, aplikace nebo obchodní partner může vystupovat jako služba. *9] SOA je v podstatě
souborem služeb, které vzájemně komunikují a ke komunikaci používají standardizované protokoly a
předem dohodnutá rozhraní. Díky těmto rozhraním lze měnit implementaci služeb, aniž by byla
ovlivněna schopnost systému tyto služby používat. [4][8]
„SOA vnímá IT infrastrukturu VÝHRADNĚ v kontextu procesů podnikání a proto je základním úkolem
IT zajistit provozní prostředí pro podnikové procesy a poskytnout řídícím pracovníkům informace
nezbytné pro řízení společnosti. IT tak není pouze nákladová položka, ale aktivní nástroj podílející se
na realizaci klíčových cílů podniku. Přes nesporné technologické výhody je jádro SOA v efektivnosti
podnikání a pružnosti reakce na tržní změny.“ *2]
4IT450
Stránka 6
2.1 Základní pilíře SOA
- výčet pilířů v této kapitole je převzat z [9+, další informace jsou čerpány z *6] a [7]
Principy současné architektury SOA jsou nástupcem předchozích distribuovaných architektur CORBA,
DCOM a webových služeb. Současná SOA architektura stojí podle *9] na následujících pilířích:
Služby jsou volně vázané (loosely coupled)
o pomocí generalizovaného rozhraní je docíleno toho, že jednotlivé služby jsou na sobě
ve velké míře nezávislé, což znamená, že provedeme-li změnu v jedné službě, není
nutné provádět změnu i v ostatních službách, které na ní navazují, nebo s ní jinak
spolupracují; lze také říci, že jednotlivé služby jsou tzv. zapouzdřeny – jejich zdrojový
kód není přímo propojen se zdrojovým kódem jiných služeb (podobně jako objekty v
C++, Java, atd.)
Služby mají hrubozrnné (coarse grained) aplikační programovací rozhraní (API)
o hrubozrnné aplikační programovací rozhraní znamená, že služby poskytují širší
úroveň funkcionality, naopak jemnozrnná služba poskytuje užší úroveň funkcionality
Komunikace mezi službami je typicky asynchronní (asynchronous communications)
o služby fungují tak, že po odeslání zprávy pokračují v dalším zpracování dat a nečekají
na to, až jim druhá služba odpoví; neblokují tedy kanály pro zasílání dalších zpráv
jiným službám (podobné jako komunikace serveru a klienta pomocí HTTP)
Důsledně se využívají oborové „standardy“ (standard based)
o striktně se dodržují standardy typu XML, HTTP, SOAP, WSDL, apod., což např.
pomáhá znovupoužitelnosti služby či porozumění funkcionalitě
Služby jsou univerzální (service reuse)
o na znovupoužitelnost se nahlíží jako na žádoucí vedlejší efekt (nikoli cíl) potvrzující
dobrou implementaci SOA principů - teprve tehdy, když jsou služby využívány
opakovaně, se projeví síla konceptu SOA; jde o to, aby co nejvíce aplikací využívalo co
nejméně služeb, což s sebou mimo jiné přináší nižší náklady na tvorbu aplikací
Metadata služeb jsou v repozitáři (metadata repository)
o repozitář by měl obsahovat dokumentaci pro provoz, vývoj a testování služeb
4IT450
Stránka 7
2.2 Hlavní přínosy SOA pro oblast podnikání
Následující kapitola čerpá z *2], [4], [8], [9]
Propojení s dodavateli, zákazníky a s byznysem celkově
o dynamické aplikace jsou k dispozici jak zákazníkům, tak dodavatelům, umožňují jim
lepší vzájemnou komunikaci a spolupráci
SOA pomáhá podnikové procesy zbavovat závislosti na konkrétní implementaci podpůrných
systémů a tím umožňuje rychlé reakce procesů na potřeby organizace
o viz jeden z pilířů SOA (loosely coupled)
Přesné rozhodování
o pomocí distribuce informací mezi kompozitními aplikacemi mají vedoucí pracovníci k
dispozici přesná data; současně lze tato data získávat a zobrazovat dle aktuální
potřeby ve velkém množství různých forem (náhledů)
Možnost znovupoužití stávajících aplikací pro další rozvoj
o viz jeden z pilířů SOA (service reuse)
2.3 Hlavní přínosy SOA pro oblast IT
Následující kapitola čerpá z [2]a [3]
Hlavní přínosy SOA vychází především ze základních pilířů SOA, které jsou popsány v předchozí části.
Proto je tato kapitola pouze shrnutím dříve již vysvětlených skutečností.
Nezávislost na platformě, aplikaci či programovacím jazyku (služby nejsou propojené přímo,
ale pomocí rozhraní)
Důsledné využívání otevřených oborových standardů
Aplikace jsou schopné mezi sebou sami lépe komunikovat
Při změně aplikace zůstávají procesy a ostatní integrační rozhraní zachovány (zapouzdření)
Flexibilita při přidání nové aplikace (služby) a možnost kombinace s existujícími službami
Možnost pružně měnit procesní zpracování v závislosti na podnikatelských potřebách (není
potřeba měnit celé systémy, ale mnohdy postačí vyměnit jednu službu (proces) za jinou)
Opětovná použitelnost aplikací (i když se jedná spíše o vedlejší produkt a ne o hlavní cíl
architektury)
4IT450
Stránka 8
2.4 Nevýhody SOA
Následující kapitola čerpá z [2] a [5]
Je mnohem složitější naprogramovat aplikaci orientovanou na služby, než provést standardní
integraci aplikací
Nákladné uvedení do provozu v porovnání s provozními náklady a dalším rozvojem
o toto úzce souvisí s první popsanou nevýhodou -> jelikož celý koncept SOA musí být
postaven na jednotlivých samostatných službách, které jsou propojeny pomocí
určitého rozhraní, přináší to sebou podstatně vyšší komplikace a tudíž i náklady na
zprovoznění takového modelu; naopak následná investice při výměně jedné služby za
jinou bývá obvykle nižší než v případě nutnosti přepsat část zdrojového kódu v
aplikaci; tento rozdíl v nákladech pak ještě více narůstá, pokud danou službu
použijeme znovu v dalších aplikacích
4IT450
Stránka 9
2.5 Životní cyklus SOA
Tato kapitola vychází z anglického článku *4].
prostředky IT každé organizace zahrnují data, provozované systémy, různé druhy specializovaných
aplikací a informace o obchodních partnerech. Všechny tyto zdroje vystupují jako služby produkující
celou škálu výstupních dat. Servisní architektura seskupuje tyto odlišné zdroje informací společně s
operačními systémy, technologiemi a komunikačními protokoly. Toto seskupování probíhá iterativně
ve třech krocích: nejprve jsou vytvořeny nové služby (vytvoření), poté jsou tyto služby
zakomponovány do větších aplikací (kompozice) a nakonec jsou výstupy služeb předány ke
zpracování koncovým uživatelům (konzumace).
Obrázek 1: Životní cyklus SOA. *4+
2.5.1 Expose (návrh)
V první fázi je třeba navrhnout, jaké služby je třeba vytvořit nad stávajícími aplikacemi a daty. Návrh
těchto služeb může být jak jemnozrnný (1 služba = 1 business proces), tak hrubozrnný (více služeb
odpovídá určité skupině podnikových funkcí). V této fázi je třeba zvážit jejich implementaci – buď
přímo pomocí webových aplikací, anebo nepřímo pomocí nějakého rozhraní.
2.5.2 Compose (kompozice)
Po vytvoření jednotlivých služeb je lze zkombinovat do větších celků. Díky tomu, že jsou tyto služby
na sobě i na platformě nezávislé, lze je navzájem kombinovat a znovu používat s maximální
flexibilitou. Současně při dalším vývoji business aplikací je lze snadno upravovat bez omezení,
vyplývajících ze stávajících aplikací a systémů.
2.5.3 Consume (konzumace)
Jakmile jsou nové aplikace nebo business procesy vytvořeny, jejich funkcionalita musí být poskytnuta
pro jiné IT systémy a koncové uživatele. Cílem tohoto procesu je dodat nové dynamické aplikace,
které umožní zvýšení produktivity a lepší možnost nahlížet do fungování a výkonnosti byznysu.
4IT450
Stránka 10
Uživatelé mohou tyto služby využívat mnoha způsoby včetně webových portálů, kancelářských
aplikací, mobilních zařízení apod.
„Z pohledu IBM se jedná o hledání cest, jak za pomoci nejmodernějších technologií zajistit
uspokojování nových potřeb a požadavků neustále se měnícího trhu.“ *10]
Termíny SOA a webové služby bývají často zaměňovány. Přestože s pomocí webových služeb se
implementace SOA stává jednodušší, tyto termíny nelze volně zaměňovat. SOA je způsob navrhování
systémů, zatímco webové služby jsou implementační technologie, které používají specifické
standardy a protokoly k dosažení řešení založeného na principech SOA. *8], [9]
2.6 Referenční rámec SOA
Obrázek 2: Referenční rámec SOA.
4IT450
Stránka 11
2.7 Zjednodušený model zralosti služeb aplikovaný na SOA
- převzato z *9]
Jednotlivé úrovně zralosti definují fázi, v níž se organizace při zavádění SOA nachází.
ÚROVEŇ 1 – POČÁTEČNÍ SLUŽBY (Initial Services): tato úroveň zralosti reprezentuje fázi učení a
počáteční fáze zavádění SOA. Typické projekty v této fázi jsou zaměřeny na implementaci
funkcionality pomocí nových technologií a testování technologií SOA v laboratorním prostředí.
Zavedení SOA je iniciováno z vývojářské strany organizace a SOA je zpravidla součástí projektu pro
integraci aplikací. Na této úrovni zralosti se implementují základní standardy pro služby (XML, SOAP,
WSDL), formují se nové dovednosti potřebné pro vývoj služeb a definují se základní metriky
hodnocení.
ÚROVEŇ 2 – SLUŽBY ZASAZENÉ DO SOA ARCHITEKTURY (Architected Services): na této úrovni
zralosti jsou již zavedeny technologické standardy SOA a zavádění SOA je kontrolované a řízené
oddělením podnikové SOA architektury. Klíčovým přínosem na této úrovni je snížení nákladů vývoje a
zavádění díky využití infrastruktury a komponent SOA v porovnání s tradičními projekty.
ÚROVEŇ 3 – OBCHODNÍ SLUŽBY A SLUŽBY PRO SPOLUPRÁCI: těžištěm zájmu je propojení
podnikových procesů s IT. Úroveň 3 je definována ve dvou částech – byznys služby (Business
Services), které se zaměřují na zlepšení interních podnikových procesů, a služby pro spolupráci
(Collaborative Services), které jsou zaměřeny na zlepšení spolupráce s obchodními partnery.
ÚROVEŇ 4 – MĚŘENÉ OBCHODNÍ SLUŽBY (Measured Business Services): úroveň se zaměřuje na
měření výkonnosti procesů zavedených na předchozí úrovni a jejich vlivu na podnikání. Součástí této
úrovně je monitorování procesů, které umožňuje uživatelům měnit způsob reakce na podnikové
události.
ÚROVEŇ 5 – OPTIMALIZOVANÉ PODNIKOVÉ SLUŽBY (Optimized Business Services): tato úroveň
přidává automatickou reakci na měření zavedené na předchozí úrovni. Tím se informační systém
založený na SOA stává klíčovým podnikovým systémem. Automatizované reakce na měření a
výsledky přicházející z úrovně 4 umožňují přijmout okamžitá opatření, jakmile se objeví konkrétní
podnět. Vzhledem k tomu, že většina společností se dnes chová reaktivně, zůstává otázkou jejich
připravenost na takové chování informačního systému.
4IT450
Stránka 12
Obrázek 3: Model zralosti SOA. [9]
4IT450
Stránka 13
3 SOA od Oracle
Nástrojem SOA, který nabízí jeden z IT gigantů, firma Oracle, je produkt Oracle SOA Suite. Oracle SOA
Suite je kompletní sada komponent tvořící infrastrukturu pro vytváření, nasazení a správu SOA.
Oracle SOA Suite umožňuje jak tvorbu a správu jednotlivých služeb, tak i jejich orchestraci.
Produkt dále zahrnuje integrované vývojové prostředí SOA, nativní BPEL engine pro orchestraci
webových služeb, jednotnou konzoli pro zabezpečení a správu webových služeb a technologii Oracle
Business Activity Monitoring pro přehled o obchodních operacích v reálném čase. Balík Oracle SOA
Suite je plně kompatibilní s ostatními middleware platformami a jeho dosud poslední vydanou verzí
je verze 11g.
3.1 Co nabízí Oracle SOA Suite?
Oracle SOA Suite je komplexním nástrojem pro vytváření, nasazování a řízení služeb. Dále umožňuje
vytvářet architekturu postupně a zároveň dodržovat bezpečnost a řízení celé architektury. Všechny
komponenty nabízejí jednotnou distribuci, řízení, bezpečnost a jednotný metadata management.
Technologie Oracle SOA Suite nabízí následující nástroje:
Integrované Servisní Prostředí (ISE) pro vývoj služeb
Oracle BPEL Process Manager pro orchestraci služeb do business procesu
ESB k propojení existujících IT systémů a obchodních partnerů jako soubor služeb
Oracle Business Rules pro dynamické rozhodování
OracleAS Integration Business Activity Monitor k sledování služeb a oddělených událostí
k poskytnutí okamžitého pohledu na stav podnikání, procesů a systémů
Oracle Web Services Manager k zajištění autentifikace a zabezpečení služeb
UDDI registr pro správu životního cyklu webových služeb
Oracle Application Server
4IT450
Stránka 14
Obrázek 4: Schéma Oracle SOA Suite [19]
3.1.1 Integrované servisní prostředí
Integrované servisní prostředí ISE je součástí nástroje Oracle JDeveloper 10g a nabízí možnost
vyvíjení, skládání a orchestraci služeb do business procesu. Business procesy mohou být
distribuovány, registrovány a využívány z různých uživatelských rozhraní, včetně desktop klientů,
prohlížečů a telnet zařízení.
JDeveloper umožňuje vývojářům aplikace založené na službách nejen vytvářet, ale i testovat,
udržovat, synchronizovat nebo skládat. JDeveloper podporuje principy SOA a standardy XML
webových služeb, stejně tak jako tradiční Javu nebo J2EE.
3.1.2 Oracle BPEL Process Manager
Oracle BPEL Process Manager poskytuje prostředí pro jednoduchý návrh, distribuci, monitorování a
spravování procesů založených na BPEL standardech. Oracle BPEL Process Manager podporuje
mnoho funkcí jako například:
standardy webových služeb jako XML, SOAP a WSDL
„dehydratace“ a „korelace“ asynchronních zpráv
paralelní zpracovávání úkolů
kontrola verzí
sledování výjimek a chyb během návrhu i běhu procesu
4IT450
Stránka 15
Obrázek 5: Schéma Oracle BPEL Process Manager [19]
Pomocí tohoto nástroje je možné integrovat BPEL procesy s externími službami. Dále je možné do
procesů integrovat technologie a služby jako například lidské úkoly, transformace, notifikace a
business pravidla.
3.1.3 Oracle ESB (Enterprise Service Bus)
ESB sběrnice posílá data do různých konečných bodů uvnitř podniku i mimo něj. Využívá open
standardy k propojení, transformaci a směřování business dokumentů (jako například XML zprávy) do
oddělených aplikací. Umožňuje monitorovat a spravovat data s minimálním vlivem na existující
aplikace. Sběrnice ESB je základem pro služby užívající servisně-orientovanou architekturu (SOA) a
event-driven architekturu (EDA).
3.1.4 Oracle Integration BAM (Business Activity Monitoring)
Oracle Integration Business Activity Monitoring (BAM) dává business manažerům možnost
monitorovat služby podnikových procesů v reálném čase a srovnávat jejich klíčové indikátory
s aktuálními business procesy. Oracle BAM poskytuje uživateli souhrny servisních metrik a informace
o parametrech kritických business procesů.
Oracle BAM zobrazuje informace pomocí výstrah a vizuálních ovládacích panelů, čímž zvyšuje
efektivitu operativních zásahů a umožňuje uživateli rozhodovat se na základě kvalitních informací.
Oracle BAM dále poskytuje uživateli možnost měnit business procesy a upravovat je v případě změny
business prostředí. Tento nástroj je kompletním řešením pro sledování běžících aplikací.
4IT450
Stránka 16
Obrázek 6: Schéma Oracle BAM [19]
Obrázek znázorňuje architekturu aktivních dat Oracle BAM k dynamickému poskytování aktuálních
dat koncovým uživatelům. Zobrazuje různé mechanismy čerpající data do Oracle BAM. Oracle BAM
zpracovává příchozí data a analyzuje události. Webové aplikace Oracle BAM umožňují uživatelům
sestavit Oracle BAM schéma a výstrahy. BAM Data Control umožňuje vývojářům vytvářet ADF stránky
s obsahem aktivních dat. Oracle BAM a jeho aplikace pak poskytují výstupy uživatelům
3.1.5 Oracle Business Rules
Oracle Business Rules je nástroj pro dynamické rozhodování za běhu programu, který umožňuje
aplikacím rychlou adaptaci okamžité podněty. Tato zvýšená pružnost je umožněna tím, že business
analytici využívající Oracle Business Rules mohou vytvářet a měnit business pravidla, která jsou
oddělena od aplikačního kódu.
Díky nástroji Oracle Business Rules je možné měnit business pravidla bez nutnosti zastavovat
samotné procesy. Externalizace business pravidel navíc umožňuje analytikům spravovat business
pravidel přímo, bez nutnosti zapojení programátorů.
3.1.6 Oracle UDDI registr
Oracle UDDI registr je klíčovou komponentou jakékoliv SOA architektury s úložištěm webových
služeb, které mohou být řízeny a spravovány Oracle Fusion Middlewarem. Oracle UDDI Registr
splňuje potřeby řízení klíčových služeb jakéhokoliv podniku:
Umožňuje providerům služeb publikovat své nabídky.
Umožňuje uživatelům služeb hledat a přistupovat k hledaným službám
Poskytuje kritické funkce pro řízení SOA
4IT450
Stránka 17
Obrázek 7: Schéma Oracle Service Registry [19]
Integrace je zajištěna s dalšími produkty řady Oracle Fusion Middleware včetně Oracle BPEL Control,
Oracle Web Services Manager a JDeveloper, a umožňuje uživatelům zasílání požadavků do registru
publikovaných služeb. Oracle UDDI Registr plně podporuje poslední UDDI V3 standardy a poskytuje
širokou škálu funkcí dnešních SOA registrů.
3.1.7 Oracle Web Services Manager
Oracle Web Services Manager je bezpečnostní administrátorské prostředí pro zabezpečení přístupu
k webovým službám a sledovat aktivit zabezpečených služeb. Je sloužen ze dvou hlavních součástí:
PDP (Policy Decision Point) a PEP (Policy Enforcement Point). PDP zahrnuje bezpečnostní a řídící
komponenty, které jsou přístupné přes webové konzole. PEP jsou interceptory, které mohou být buď
agenty, nebo branami. Agenty běží ve stejném kontejneru jako jimi chráněné webové služby, zatímco
brány jsou zcela nezávislé podobně jako proxy servery. Kombinace agentů a bran pak může být
použita jako end-to-end zabezpečení webových služeb.
Při obvyklém postupu bezpečnostní administrátor zaregistruje webové služby, které mají být
chráněny a řízeny a definuje bezpečnostní pravidla pro každou registrovanou službu. Taková pravidla
mohou být například, jakým způsobem jsou kódovány a podepisovány zprávy, jakým způsobem se
logují události a podobně.
PEP interceptory zachycují požadavky na registrovanou webovou službu a zajišťují dodržování
pravidel stanovených administrátorem. Dále pak PEP shromažďuje bezpečnostní a řídící informace,
které předává PDP. PDP tyto informace shromažďuje a formátuje je tak, aby byly zobrazitelné
v jednoduše čitelných grafech či schématech. Příslušné metriky jsou získávány informací od
administrátora v řídící konzole.
4IT450
Stránka 18
3.1.8 Oracle Application Server
Oracle Application Server je standardizovaným aplikačním serverem, jenž je komplexní a plně
integrovatelnou platformou pro webové stránky, J2EE aplikace a webové služby. Server nabízí
zabudovaný software podnikového portálu, vysokorychlostní caching, funkci pro analýzu obchodních
informací, rychlý vývoj aplikací, integraci aplikací a firemních procesů, bezdrátové funkce a další
vlastnosti.
3.2 Životní cyklus Oracle SOA aplikace
Obrázek 8: Schéma životního cyklu Oracle SOA aplikace [19]
1. Využití Oracle JDeveloperu k vytvoření kompozitní SOA aplikace s různými SOA komponenty
2. Zabalení aplikace k distribuci
3. Distribuce SOA aplikace do SOA infrastruktury. SOA Infrastrukturou je Java EE aplikace běžící
na Oracle Application Sereru. Aplikace řídí komponenty a jejích životní cyklus.
4. Použití Oracle Fusion Middleware Control k sledování a řízení kompozitní aplikace.
4IT450
Stránka 19
4 Mashup aplikace
V poslední době se stále častěji objevuje trend zapojení uživatelů, kteří nejsou vystudovanými IT
odborníky, do procesů automatizace workflow. Tato tendence vyplývá především ze skutečnosti, že
se neustále zvětšuje okruh lidí, kteří ve svém volném čase aktivně pracují s technologiemi
označovanými pojmem Web 2.0. V rámci těchto aktivit se mnohdy seznamují s postupy tvorby
jednoduchých aplikací. Tvorba těchto (mashup) aplikací totiž nespočívá v kódování, ale
v kombinování dostupných softwarových služeb s cílem vytvořit tak novou aplikaci s požadovanou
funkcionalitou.
Pro uživatele, kteří si tyto technologie dostatečně osvojí, je pak přirozené, aby získané znalosti využili
pro tvorbu takzvaných business mashup aplikací v rámci pracovního poměru. Není pak důvod
netrpělivě čekat na řešení IT útvaru, jehož řešení nemusí být vždy takové, jaké uživatel očekával.
4.1 Co je mashup?
Pojmem mashup (nejvýstižnější překlad je „míchanice“) označujeme hybridní webové aplikace
vytvořené specifickým kombinováním několika existujících služeb za účelem vytvoření nové užitečné
funkcionality.
Mashups aplikace jsou obvykle děleny do tří různých kategorií:
Konzumní mashup
Datové mashup
Business (podnikové) mashup
Tento typ kategorizace kombinuje různé způsoby tvorby mashups a jejich věcný obsah. Pro všechny
uvedené typy mashups však platí společná výchozí vlastnost. Vždy se jedná o webovou aplikaci a jako
takovou má smysl ji provozovat pouze na nějakém hostitelském portálu, nikoliv jako izolované
aplikace označované jako stand-alone či aplikace typu peer-to-peer.
4.1.1 Konzumní mashup
Ke vzniku konzumních mashups začalo docházet v době, kdy nejvýznamnější webové portály
umožnily přístup k jejich službám prostřednictvím webových služeb. Tento fakt umožnil uživatelům
těchto veřejně přístupných webových portálů nabídnout novou hodnotu kombinováním existujících
zdrojů.
Mezi nejvýznamnější konzumní mashups patří například populární komunitní portál FaceBook. Stále
častěji jsou pak také v oblasti konzumních mashups využívány služby portálu Google Maps. Vlastní
mashup je pak provozován na nějakém veřejném hostitelském portálu.
4IT450
Stránka 20
Konzumní mashups jsou obvykle vyvíjeny pomocí jednoduchých skriptovacích nástrojů. Jako příklad
takových skriptovacích nástrojů lze zmínit Google Mashup Editor nebo Microsoft Popfly. Podmínkou
pro vývoj konzumních mashups je tedy znalost konkrétního skriptovacího jazyka, méně podstatnou
záležitostí je pak zvládnutí vlastního vývojového prostředí.
Obrázek 9: Ukázka Google Mashup Editoru.
4.1.2 Datový mashup
Pojmem datové mashups označujeme ty, které se zaměřují na kombinaci dat z různých zdrojů. Mezi
hlavní a nejvíce používané datové zdroje pro tuto kategorii patří RSS informační kanály.
Hlavním nástrojem pro vývoj datových mashups jsou opět především skriptovací nástroje, které jsou
rozšířené o podporu pro práci s metadaty, neboli informacemi o struktuře informací. Příklad
takového vývojového nástroje pro tvorbu datových mashups je například IBM sMash.
Podmínkou pro tvůrce datových mashups je stejně jako u kategorie konzumních mashups znalost
daného skriptovacího jazyka spolu s různými pravidly transformačních gramatik.
4IT450
Stránka 21
Obrázek 10: Ukázka nástrojů WebSphere sMash.
4.1.3 Business (podnikový) mashup
Business mashup, jehož doslovný překlad znamená „podniková míchanice“, je kategorie mashups
využívající přístupů a technologií konzumních mashups pro vytváření podnikových aplikací. Podnikové
mashups se nejčastěji zaměřují především na tvorbu „nadstavbových aplikací“, které využívají služby
a data existujících podnikových aplikací. Ty jsou poté jejich pomocí kombinovány do podoby
webových aplikací, které slouží pro automatizaci určitých podnikových procesů.
Pro vývoj podnikových mashups však nelze jednoduše použít nástroje, které jsou určené pro tvorbu
konzumních mashups, neboť příslušné nástroje jsou obvykle závislé na platformě, na které jsou poté
mashups provozovány. Dalším problémem použití nástrojů založených na skriptování je nutná znalost
příslušného skriptovacího jazyka a daného vývojového prostředí.
Z tohoto důvodu se pro tvorbu podnikových mashups obvykle využívá uživatelsky orientovaných
nástrojů, které umožňují strukturu aplikací „naklikat“. Do takto připravené kostry poté lze snadno
začlenit volání funkcí webových služeb. Jedním z nejvýznamnějších nástrojů tohoto typu je Business
Mashups od americké firmy Serena (www.serena.com/mashups). Hlavní výhodou takového nástroje
je fakt, že větší část, ne-li celý mashup, mohou vytvářet samotní business uživatelé.
4IT450
Stránka 22
Obrázek 11: Ukázka nástroje Business Mashups od firmy Serena.
4.2 Oblasti nasazení mashups
Forma hybridních webových aplikací nazývaných Mashups je vhodná především pro oblast
administrativních procesů, které bývají jejich pomocí automatizovány. Dále pak nachází uplatnění u
specifických částí klíčových procesů, které jsou však zpracovávány pouze omezenou skupinou
uživatelů.
Největší výhodou využití mashups v této oblasti je právě to, že zkušenější uživatelé si je mohou
vytvářet sami a zároveň zde nehrozí bariéra nezanedbatelných IT nákladů na zabezpečení dostatečné
výkonnosti.
I přesto, že doménou tradičního IT vývoje zůstává právě tato oblast, je pro využití služeb těchto
aplikací v rámci mashups nutností počítat s použitím technologie webových služeb pro jejich
zpřístupnění. Technologie webových služeb kromě využití v rámci mashups koneckonců obecně
zjednodušují integraci aplikací.
Vzhledem k tomu, že pojem mashups pojednává o hybridních webových aplikacích, je možné jejich
tvorbu rozdělit do třech oblastí:
4IT450
Stránka 23
1. Platforma – provozní technologie, ve které mashup poběží.
2. Webové služby – vytvoření a zpřístupnění služeb, které mashup využívá.
3. Mashup – vytvoření vlastního mashup.
Jednotlivé oblasti mohou být vytvářeny a zajišťovány různými subjekty.
4.3 Mashups a role při vývoji
4.3.1 IT oddělení
Hlavní úlohou IT oddělení je, jak je asi zřejmé, zajištění především webových služeb a dané platformy.
Je pravdou, že platforma mashups využívá soudobé webové technologie, které jsou již v IT
odděleních naprosté většiny firem k dispozici, nicméně vzhledem k faktu, že mashups aplikace
obvykle nebývají celopodnikové aplikace, není nutné alokovat pro běh mashups příliš vysoký výkon.
4.3.2 Outsourcingová firma
Hlavní a nejběžnější příležitostí pro využití outsourcingových služeb při vytváření mashups je oblast
platformy pro jejich provoz. Zde může outsourcing uspořit značné náklady související s osvojením
webových technologií pro provoz mashups.
Na druhou stranu využití outsourcingu v oblasti tvorby webových služeb či dokonce tvorby vlastních
mashups nemá příliš logiku z hlediska dosažení přínosů s nimi spojených. V případě webových služeb
je totiž důležité, aby nebyly pouze jednorázově vytvořeny, ale aby byla také udržována jejich
konzistence při provádění změn v systémech, jejichž služby zpřístupňují. Při tvorbě mashup je
s ohledem na shora uvedené zaměření mashups na určité typy procesů klíčová znalost procesu, která
je přirozená právě pro business uživatele.
4.3.3 Specializovaná firma
Vhodný prostor pro zapojení specializované firmy je především ve fázi osvojení jednotlivých oblastí
tvorby a provozu mashups, ať už je to platforma provozování mashups, tak i prostředí pro vytváření
mashups. Budování mashups na zakázku specializovanou firmou má nákladové opodstatnění
především jako součást osvojení prostředí a postupů tvorby mashups.
4IT450
Stránka 24
Obrázek 12: Příklad vývojového prostředí pro business mashup.
4.3.4 Business uživatelé
Právě pro business uživatele jsou mashups největší příležitostí. Z tohoto důvodu by měli být do jejich
tvorby zapojeni od samého začátku, a to primárně v oblasti samotné tvorby. V této oblasti se jedná
především o připravení základní logiky mashup aplikace. Jedním z nejčastějších argumentů vývojářů
při zkoumání nedostatků jimi vytvořené aplikace je, že uživatelé nevědí, co chtějí. Ať už je tento
argument oprávněný, či nikoli, hlavní výhodou tvorby mashup aplikací vlastními uživateli je to, že ve
finále uživatelé nejen vědí, co chtějí, ale také dostanou to, co si představovali.
Byť se to na první pohled mohlo zdát zbytečné, uživatelé by se měli účastnit i tvorby webových
služeb. Praktické použití mashups uživateli totiž ukazuje problém v tom, že v IT vytváří webové služby
programátoři a to vede k tomu, že tyto jsou pak pochopitelné opět pouze pro programátory. Častým
problémem bývá to, že funkce webové služby, kterou business uživatel potřebuje použít při vytváření
mashup, má 30 parametrů, z toho se většinou jedná o komplexní datové struktury. Výsledkem tohoto
problému pak je, že ji daný business uživatel buď vůbec nepoužije, anebo musí zadat požadavek na IT
pracovníky týkající se jejího přepracování do „použitelnější“ podoby. Abychom tento problém
odstranili, je vhodné business uživatele zapojit do specifikace rozhraní webových služeb, které by
mohli v budoucnu potřebovat použít.
4IT450
Stránka 25
Z výše uvedených oblastí je v neposlední řadě možné odvodit náklady na pořízení, provoz a další
rozvoj mashups.
Úvodní pořizovací náklady
Úvodní pořizovací náklady jsou tvořeny náklady na pořízení platformy a jejího osvojení a pořízení
prostředí pro tvorbu mashups, taktéž s jeho osvojením.
Započítání nákladů na pořízení webových služeb již není tak jednoduché, neboť tyto náklady by měly
být rozpočítány částečně do pořizovacích nákladů a částečně do nákladů na vytvoření mashups, které
příslušné služby využívají. Kromě mashups jsou navíc webové služby obvykle využívány i v rámci
jiných aplikací.
4.3.5 Náklady na tvorbu a provoz
Náklady na tvorbu a provoz mashups jsou tvořeny především náklady na jejich vytvoření, které ale
nejdou z rozpočtu IT, a dále adekvátním podílem na provozu platformy.
Zde je nejdůležitějším rysem, který je třeba zdůraznit, fakt, že náklady spojené s vytvořením mashup
business uživateli nejdou z omezeného rozpočtu IT oddělení.
Z praktického hlediska však nástup mashup aplikací nejvíce limituje dostupnost webových služeb a
obecně míra implementace SOA (Service Oriented Architecture).
4IT450
Stránka 26
4.4 Business Mashups firmy Serena
Business Mashups (dříve znám jako TeamTrack) je webová platforma, která se používá pro procesní
řízení, umožňující namodelovat a následně opakovaně a konzistentně realizovat procesní řetězce
napříč celou organizací. Nasazení platformy Business Mashups přináší průběžné zdokonalování
automatizovaných procesů, které jsou vzájemně provázány, a také ke zlepšení týmové spolupráce.
Tato platforma v neposlední řadě vede také k důslednému využívání nejlepších praktik a ve výsledku
ke snížení nákladů a rizik.
Obrázek 13: Nástroj Serena Business Mashups (TeamTrack).
Oproti jiným nástrojům pro procesní řízení se Business Mashups vyznačuje širokou
konfigurovatelností nevyžadující nákladné programování. Další klíčovou charakteristikou je rychlá
implementace a nízké nároky na správu a údržbu.
V procesech, které byly automatizovány prostřednictvím nástroje Business Mashups, lze pracovat
tak, jak jsou uživatelé zvyklí. Při implementaci se vychází především ze zvyklostí uživatelů a
z užívaných praktik a ty jsou poté transformovány do podoby systematicky pojatých, opakovaně
vykonávaných procesů. K dodržení stanovených termínů a k efektivnímu využití zdrojů napomáhá
právě opakovatelnost a predikovatelnost.
Jedním z hlavních částí platformy Business Mashups je intuitivní grafický workflow editor, který
uživateli umožňuje snadno definovat nové či vylepšovat stávající velmi komplexní procesy. Business
Mashups disponuje silným aparátem pro flexibilní návrh webových formulářů, které se skládají
z jednotlivých polí určených pro komunikaci v rámci daného procesu. Každý z jednotlivých procesů
pak lze snadno provázat s využitím automatizovaných akcí, díky čemuž lze dosáhnou jejich vzájemné
úzké integrace.
4IT450
Stránka 27
Obrázek 14: Ukázka editoru pro návrh webových formulářů.
Business Mashups pracuje na principu rolí. Každá z těchto rolí je zodpovědná za jednotlivé aktivity
v rámci daného procesu. Každý účastník procesu tak vidí: co se má provést, kdo to má provést a co
bude následovat. Hladké předávání práce v rámci procesu zajišťuje automatická notifikace
prostřednictvím e-mailových zpráv. V případě nestandardního průběhu některého z procesů může
být automaticky zaslána eskalační zpráva, která umožní včas zajistit sjednání nápravy.
Uživatelské rozhraní je uzpůsobeno pro každou roli unikátně. Formou jakési domovské stránky jsou
zpřístupněny nejdůležitější potřebné informace. I přesto má každý uživatel možnost jejího
přizpůsobení do podoby reflektující jím osobně nejčastěji používaných pohledů. Mimo to si dále
může uživatel zvolit pro něj relevantní události, na které si přeje být upozorněn formou e-mailové
notifikace. I přes široké možnosti jsou všechna tato nastavení provedena bez použití jakéhokoli
programování. Pohledy, které si uživatel nadefinuje, pak mohou mít formu výpisů, tabulek, grafů a
mohou být využity pro zjišťování trendů a následnou optimalizaci automatizovaného procesu.
Užitečnou funkcí může být v neposlední řadě také možnost nastavení tolerančních mezí, které
uživateli usnadňují vizuální indikaci odchylek.
4IT450
Stránka 28
Business Mashups umožňuje snadné provádění změn implementovaných procesů. Každá z těchto
provedených změn je okamžitě funkční bez nutnosti přerušení provozu systému. Pokud jsou však
změny rozsáhlejšího charakteru, lze funkčnost před nasazením do produkčního systému odladit na
paralelně provozovaném testovacím serveru.
Nástroj Business Mashups obsahuje také podrobnou historii každé akce provedené jejím uživatelem,
čímž lze snadno vysledovat všechny informace o každé činnosti. Tato historická data podporují
odpovědnost za změny v systému, představují efektivní bázi pro snadné provádění auditů a také
poskytují silný nástroj pro postupnou optimalizaci veškerých procesů.
Obrázek 15: Možnosti historie a reportingu nástroje Business Mashups.
Samozřejmostí nástroje Business Mashups jsou také prostředky pro snadnou lokalizaci uživatelského
rozhraní webového klienta do různých jazyků, čehož bylo využito i pro vytvoření české verze.
Business Mashups je koncipován jako široce otevřený, robustní nástroj poskytující prostředky pro
snadnou integraci s ostatními systémy firemní infrastruktury. Pro tyto účely lze využít technologie
webových služeb nebo rozhraní API umožňující na programové úrovni volat funkce standardně
dostupné z uživatelského rozhraní. Vzhledem k transparentní struktuře databázových schémat
Business Mashups je možné integraci zajistit též na úrovni databáze.
4IT450
Stránka 29
4.4.1 Přínosy nasazení
Hlavní přínosy nasazení nástroje Business Mashups jsou:
opakovatelné, vynutitelné, snadno auditovatelné procesy
zlepšení toku informací a spolupráce mezi zúčastněnými
zavedení konzistentního procesního přístupu napříč organizačními jednotkami a efektivní
koordinace všech činností
schopnost průběžného ověřování efektivnosti procesů s cílem jejich postupné optimalizace
zajištění transparentnosti průběhu celého procesu, včetně určení metrik pro měření kvality
důsledné uplatnění nejlepších praktik
dosažení konformity s normami a standardy jako ITIL, COBIT, ISO, Sarbanes-Oxley, CMMI,
SixSigma a další
4.4.2 Technologie nástroje Business Mashups
Plné využití webových technologií nástroje Business Mashups zajišťuje snadný přístup všem
uživatelům bez nutnosti jakékoliv instalace či modifikace klientských stanic. Mimo jiné je tímto
přístupem také zajištěna maximální úroveň flexibility oproti nízkým nákladům na provoz a správu.
Bezpečné a přímé sdílení veškerých informací s kolegy, partnerskými organizacemi i dalšími subjekty,
bez ohledu na jejich geografické umístění umožňuje robustní aparát pro nastavení uživatelských práv
s nízkou úrovní granularity. Business Mashup nabízí pro autentifikaci uživatelů službu plně
kompatibilní s LDAP a zajišťuje tak podporu jediného přihlášení do systému (Single sign-on).
Odpovídající výkon systému lze snadno zajistit využitím multiprocesorových systémů, které web
server podporuje, spolu s možností jeho snadného zvyšování v případě budoucího širšího využití.
Samozřejmostí je také navržení nástroje Business Mashups tak, aby databáze, webový server a
notifikační server mohly být v případě požadavku na velmi vysoký výkon instalovány na samostatných
počítačích.
4.4.3 Oblasti nasazení
Business Mashups nachází využití v organizacích všech velikostí od začínajících firem až po
průmyslové giganty. Rozsah využití zahrnuje všechny procesy s charakterem pracovního toku, které je
účelné automatizovat.
4IT450
Stránka 30
4.5 Aris MashZone
Společnost IDS Scheer1 je známá svými špičkovými nástroji v oblasti modelování a řízení procesů.
Nedávno však na Cebitu 2010 představila zcela nový produkt zaměřený na tvorbu mashupů a
vizualizaci dat – ARIS MashZone.
Tento nový produkt dokáže na základě vytvoření prezentační vrstvy nad firemními daty zjednodušit
jejich vyhodnocení a analýzu. Výhodou pro ty, co již vlastní některé produkty z portfolia ARISu může
být fakt, že MashZone lze s těmito nástroji dobře integrovat.
MashZone je vhodný pro vyhodnocování marketingových kampaní, konkurenční analýzy, analýzu
prodejního procesu i finanční analýzy. Díky implementaci přístupů vycházejících z technologií Web
2.0 mohou zaměstnanci rychle vytvářet vlastní mashup aplikace, sdílet je a spolupracovat s dalšími
uživateli.2
4.5.1 Náklady na Aris MashZone
Obrázek 16: Ukázka Mashup aplikace v prostředí ARIS MashZone [20]
Nekomerční edice MashZone je dostupná zdarma pro jednotlivce. Komerční licence přijde jednoho
uživatele v rámci menší skupiny (1-10 uživatelů) na 95 USD. Pro firemní klientelu se náklady na
pořízení MashZone vyšplhají na 240 USD za jednoho uživatele. Tato komerční verze má navíc
omezení v maximálním počtu uživatelů na 30, s tím, že nabízí další možnosti individuálního rozšíření.
1
od července 2009 součástí skupiny Software AG
2
Ačkoliv je sdílení mashupů povoleno, přistupovat k nim mohou jen oprávnění uživatelé.
4IT450
Stránka 31
Omezená verze ARIS MashZone je volně stažitelná z webových stránek společnosti.3 Na webu
najdeme kromě samotné aplikace i názorné video tutoriály a galerii mashupových aplikací
s praktickými ukázkami použití (např. z oblasti prodeje a marketingu).
Od uvedení produktu na trh 14. ledna 2010, si speciální verzi tohoto softwaru stáhlo více než 10,000
potenciálních uživatelů [14]. Aris MashZone můžeme zařadit mezi přední hráče v oblasti Mashup
aplikací. Zajímavé také je, že v současné době nenajdeme žádný srovnatelný produkt od takových
společností jako Microsoft, IBM nebo Oracle.
4.5.2 Klíčová funkcionalita Aris MashZone
Typickým příkladem podnikových mashupů je kombinování podnikových dat, například ze systémů
ERP, CRM nebo Business Intelligence, která se spojují do smysluplných celků a jsou prezentovány na
webové stránce.
Díky podnikovým mashupům uživatel nemusí dolovat data z několika různých aplikací a ručně je
kopírovat z Excelu. Podnikové mashupy překonávají tento koncept, a to poměrně elegantní cestou a
dovolují tak uživateli vytěžit více z podnikových zdrojů, které má k dispozici. Díky tomu může uživatel
porozumět vlastním datům, rychleji je analyzovat a učinit pak rozhodnutí. Dobře vytvořené mashupy
tak mají příležitost zvýšit strategickou hodnotu IT, doručením dodatečných informací a redukcí času a
nákladů vynaložených na vývoj nových nástrojů či reportů.
Funkcionalita Aris MashZone:
Vytváření Business mashupů pro pokročilou analýzu firemních dat
Možnost využití vestavěných filtrů pro identifikaci skrytých vazeb mezi daty
Sdílení informací napříč organizací a možnost spolupráce
Aby mohla společnost využít potenciálu mashupů, její systémová architektura by měla vhodným
způsobem umožnit načtení dat z různých zdrojů. V tomto ohledu se jako vhodná ukazuje
architektura založená na službách. Služby lze snadno propojit s MashZone i pomocí webových
služeb. Aris MashZone zahrnuje nástroje sloužící ke kompozici mashupů a propojení datových
vláken. Další součástí jsou vizualizační komponenty.
3
www.mashzone.com
4IT450
Stránka 32
Aris MashZone je vytvořen tak, aby každý uživatel, nejen odborník na IT, mohl vytvořit vlastní
pohledy na data. Aplikace MashZone dokáže importovat data z různých zdrojů, od interních
datových center až po externí Webové služby. Datové adaptéry a konvertory jsou dostupné pro
většinu běžných standardů, jako je JDBC a ODBC a také podporují standardní internetové protokoly.
Zajímavostí je, že server, na kterém běží prezentační vrstva MashZone využívá architekturu Adobe
Flex.
4.5.3 Jak vytvořit mashup v Aris MashZone
První krok při vytváření mashup aplikace spočívá ve vybrání vhodných datových zdrojů, které se
následně zkombinují a agregují do datových vláken (feeds). Aby byl mashup použitelný a měl vůbec
smysl pro uživatele z řad zaměstnanců, musí se data skládat rozumným způsobem dohromady. Pokud
bude uživatel „míchat“ zcela nesouvisející nebo nahodilé datové zdroje, vznikne sice mashup, ale
naprosto nepoužitelný. Redundance dat se uživatelé nemusí bát, protože data zůstávají stále ve
svém originálním úložišti, a díky tomu jsou také aktuální.
Když máme připravená data, můžeme je smíchat do tzv. datových vláken. Datová vlákna jsou poté v
modelovacím nástroji MashZone propojena s jejich vhodnou grafickou interpretací, kterou vybírá
uživatel. Datovým zdrojem nemusí být jen ERP systém nebo datový sklad, ale také lokální excelovské
soubory nebo statistická data z webu. Pokud má společnost jiné produkty od ARISu může zde využít
jejich vzájemného propojení. Všechna tato data mohou být kombinována, uspořádána a agregována
do jednoho datového vlákna.
Vytvoření výsledné mashup aplikace je otázkou několika desítek minut. Mashup je pak prezentován
pomocí grafických komponent (diagramy, mapy, grafy, semafory). Celá webová prezentace je navíc
interaktivní a umožňuje provádět další ad-hoc analýzy nastavováním dodatečných filtrů. Mashup
může být poté dále sdílen s ostatními pověřenými uživateli. Kromě toho je také možné využít již
vytvořená datová vlákna pro další mashup.
4IT450
Stránka 33
Obrázek 17: Editor ARIS MashZone – modelování datových vláken [20]
4.5.4 Výhody a nevýhody Aris MashZone
Výhody:
Data z různých zdrojů lze zkombinovat bez znalosti programování.
Analýzy nemusí připravovat jen pracovníci IT oddělení, ale i ostatní zaměstnanci.
Mashup aplikace mohou být vytvořeny rychle.
Je možné propojit různé datové zdroje (interní i externí).
Výrazně jednodušší nasazení oproti BI.
Nevýhody:
Desktopová část ARIS MashZone je určená jen pro OS Windows.
Omezená verze je limitována na jednoho uživatele a 1000 řádků dat, resp. 32 sloupců.
Současná verze MashZone nedokáže jednoduše exportovat data.
4IT450
Stránka 34
5 Zdroje
[1] Alena Buchalcevová, Libor Gála. Modely zralosti SOA *online+. Dostupné z
http://si.vse.cz/archive/proceedings/2006/modely-zralosti-soa.pdf> *Přístup 12. 4. 2010]
[2] Petr Leština. Co je Servisně Orientovaná Architektura? *online+. Dostupné z <
http://bpmibm.blogspot.com/2007/11/co-je-servisn-orientovan-architektura.html> *Přístup
12. 4. 2010]
[3] Petr Leština. SOA pomalu na obzoru *Publikováno 22.05.07+ *online+. Dostupné z
<http://businessworld.cz/ostatni/soa-pomalu-na-obzoru-2999> *Přístup 14. 4. 2010]
[4] Microsoft. Learn About Service Oriented Architecture (SOA) [Publikováno 1.12.2006+ *online+.
Dostupné z <http://www.microsoft.com/biztalk/solutions/soa/overview.mspx> *Přístup
14. 4. 2010]
[5] Kamil Pittner. Abeceda SOA *online+. Dostupné z < http://businessworld.cz/soa-aeai/abecedasoa-2408> *Přístup 12. 4. 2010]
[6] Daniel Rydzi. SOA – východiska a výhled *online+. Dostupné z
<www.cssi.cz/cssi/system/files/all/0rydz.pdf> *Přístup 18. 4. 2010]
[7] Jiří Sova, Michal Gürtner, Marek Dušek, Petr Kovář. Integrační nástroje a jejich vazba ke CASE a
modelování vůbec *online+. Dostupné z < www.cssi.cz/cssi/system/files/all/0rydz.pdf> *Přístup
18. 4. 2010]
[8] webservices.xml.com. What Is Service-Oriented Architecture *Publikováno 30.9.2003+ [online].
Dostupné z < http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html> *Přístup 14. 4. 2009]
[9] Jindřich Štumpf. Proč SOA nemá alternativu *Publikováno 10.2006+ *online+. Dostupné z
<http://www.systemonline.cz/sprava-it/proc-soa-nema-alternativu.htm> *Přístup 14. 4. 2010]
[10]Steve Mills, Senior Vice President and Group Executive v IBM Software Group, interwiev *Přístup
18. 4. 2010]
[11]Anh Nguyen. SOA is not dead, says IDC *Publikováno 24.03.10] *online+. Dostupné z
<http://www.computerworlduk.com/management/infrastructure/applications/news/index.cfm?
newsId=19550> *Přístup 18. 4. 2010]
[12]Rakesh Saha, Enterprise Data Mashup - SOA based mashup *Publikováno 09.06.09] [online].
Dostupné z www <http://enterprisemashup.blogspot.com/2009/06/enterprise-data-mashupsoa-based-mashup.html> *Přístup 18. 4. 2010]
[13]Tisková zpráva. Modus Operandi Awarded Awarded $600,000 U.S. Navy Contract to Develop a
Data Fusion SOA Framework for Submarines *Publikováno 12.04.10] [online]. Dostupná z www
<http://www.modusoperandi.com/press%20releases/PR_Wave_SOS_Phase_II.html> *Přístup
24. 4. 2010]
[14]článek Software AG - ARIS MashZone: create the perfect business mashup in just ten minutes.
See the future of reporting live at CeBIT! *Publikováno 04.03.10+ *online+. Dostupné z
4IT450
Stránka 35
<http://www.allbusiness.com/technology/software-services-applications-electronic/140393521.html> *Přístup 18. 4. 2010]
[15]článek Gastronomie v IT aneb jak udělat chutný Mashup (časopis Connect! – listopad 2008)
[16]článek Nové možnosti automatizace workflow (časopis IT Systems – duben 2008)
5.1 SOA a Mashup nástroje
[17]LBMS – Business Mashups
http://www.lbms.cz/Nastroje/Business-Mashups/index.html
[18]SERENA - SBM (TeamTrack)
http://www.serena.com/products/sbm/
[19]ORACLE – Oracle SOA Suite 11g
http://www.oracle.com/us/technologies/soa/
[20]IDS-Scheer - ARIS MashZone
http://www.ids-scheer.com/en/ARIS/ARIS_Innovations/ARIS_MashZone/151395.html
http://www.arismashzone.com
4IT450
Stránka 36

Použití CASE nástrojů pro řízení architektury SOA

Transkript

Podobné dokumenty

SOA nástroje pro Cloud_Computing

Nástroje pro vývoj aplikací v závislosti na platformě a jejich vazba na

Návod pro DVR-4E

Bakalarska prace - Unicorn College

Web 2.0-charakteristika a služby

Digitální knihovny: principy a problémy

Soutěžní řád SK SALH pro sezónu 2015 / 2016