ZS 2008/20 09. Použití CASE nástrojů pro řízení architektury SOA

ZS 2008/20 09 Použití CASE nástrojů pro řízení architektury SOA Jiří Mizera, Václav Vašíček, Marek Saktor, Ondřej Hlavička VŠE Praha, KIT, 4IT450 CASE ZS 2008/2009

Obsah 1 Úvod... 4 2 Architektura SOA... 5 2.1 Vývojový cyklus architektury SOA, SOA Maturity Model... 6 2.2 Řízení architektury SOA- SOA Governance... 8 3 IDS (IDS Scheer 2008) Scheer, nástroje ARIS... 9 3.1 ARIS SOA Architect... 9 3.1.1 Proces přeměn podnikového procesu na spustitelnou službu... 10 3.2 ARIS Business Rules Designer... 11 3.3 ARIS Process Performance Manager... 11 3.4 Závěr IDS Scheer, ARIS... 12 4 Nástroje společnosti Telelogic... 13 4.1 O společnosti... 13 4.2 Přehled nástrojů... 13 4.3 Telelogic System Architect... 14 4.3.1 System Architect - vlastnosti a podporované koncepty... 14 4.3.2 System Architect a SOA... 15 4.3.3 System Architect klady a zápory... 16 4.4 Telelogic Tau... 16 4.4.1 Telelogic Tau specifikace... 17 4.4.2 Telelogic Tau a SOA... 18 4.5 Ukázkový scénář zavádění SOA za pomocí nástrojů Telelogic... 19 5 Oracle SOA suite... 21 5.1 Úvod... 21 5.2 Komponenty Oracle SOA Suite... 21 5.3 Životní cyklus a podpora tvorby služby... 22 5.4 Procesy a Oracle SOA Suite... 26 5.5 Závěr... 28 6 CASE nástroje společnosti IBM pro řízení architektury SOA... 29 6.1 Servisně orientovaná architektura v pojetí IBM... 29 2 S t r á n k a

6.1.1 Styly SOA... 29 6.1.2 Vstupní body do architektury SOA... 30 6.2 Oblasti servisně orientované architektury pokryté IBM... 32 6.3 Smart SOA... 33 6.4 Business process management nástroje od IBM pro řízení architektury SOA... 35 6.4.1 WebSphere Business Modeler... 35 6.4.2 WebSphere Integration Developer... 37 6.4.3 WebSphere Process Server... 37 6.4.4 WebSphere Business Monitor... 38 6.4.5 WebSphere Business Services Fabric... 39 6.4.6 Hra Innov8... 40 6.5 Shrnutí IBM SOA... 40 7 Závěr... 41 8 Bibliografie... 42 3 S t r á n k a

1 Úvod Architektura SOA je v současnosti fenoménem, o kterém se zmiňuje prakticky každá významnější i méně významná IT společnost. S raketovým nástupem architektury SOA můžeme zároveň pozorovat i větší pozornost odborné veřejnosti na analýzu a především na správu business procesů (podnikových procesů). CASE nástroje, které jsou k modelování podnikových procesů používány, většinou rychle odpovídají a v portfoliu jejich produktů se objevují nástroje, které jsou přímo určeny k vývoji nebo správě architektury SOA. Stejně tak velké IT společnosti, které dříve podnikovými procesy spíše opovrhovali a považovali modelování podnikových procesů spíše za manažerskou záležitost, dnes používají a vyvíjejí nástroje, které umožňují analyzovat business svět, do kterého chtějí následně implementovat svůj přístup k SOA architektuře. Z předešlých řádků vyplývá, že CASE nástroje pro potřeby architektury SOA se nám v posledních letech začali překrývat. Na jedné straně jsou klasické produkty např. od společnosti IDS Scheer, které jsou určeny pro podporu managementu, simulaci namodelovaných podnikových procesů nebo pro přiřazování KPI (Key Performance Indicators). Tyto berou architekturu SOA spíše jako nadstandard ke svým službám a pomáhají určit, které procesy mohou být automatizované SOA architekturou apod. Naproti tomu velcí vývojáři software jako Oracle nebo IBM mají namodelované business procesy pouze jako vstupní bod do vývojového cyklu, kde jim následně přiřazují webové služby, nebo je organizují za pomoci ESB (Enterprise Service Bus). Aby bylo možné popsat jednotlivé produkty, je zapotřebí nejprve vysvětlit základní principy SOA architektury. Následně je zapotřebí vysvětlit u každého analyzovaného nástroje, v jakém vývojovém cyklu tento produkt stojí. Z uvedeného vyplývá, že je tedy velice obtížné tyto produkty hodnotit mezi sebou, protože si konkurují pouze ve zlomku své funkcionality. Nástroje ARIS si nekladou za cíl provozovat perfektní ESB a naopak nástroje IBM nejsou primárně určeny pro podporu manažerského rozhodování např. metodou six sigma (uvidíme, jak tomu bude v budoucnu). Protože jsme první skupina, která s tímto novým tématem přišla, je na dalších následovnících, aby téma podrobněji rozpracovalo. Náměty na toto budou uvedeny v závěru práce. 4 S t r á n k a

2 Architektura SOA Architektura SOA je dnes prakticky novým přístupem pro budování podnikové architektury informačního systému. Každá společnost má pro SOA svůj vlastní přístup a metodiku zavádění, v této práci budou jmenovány přístupy společností IBM a Oracle. Je zapotřebí si uvědomit, že architektura SOA není balíkové řešení, které si můžeme zakoupit, nainstalovat a následně používat dokud nepřijde nová verze nebo něco jiného. Architektura SOA v sobě obsahuje nový přístup k budování informačních systémů, jedná se podle mého názoru zatím o nejměkčí metodiku podnikové architektury, která byla dosud obecně přijata. Právě proto, je zde velké místo vyhrazeno pro business procesy a jejich modelování, který bývalo dříve při vývoji velkých systémů opomíjeno a následně docházelo k rozčarování při spuštění balíkových řešení do provozu. Principy architektury SOA jsou podle (Jindřich Štumpf, Progress 2006) následující: Služby jsou vázané (loosely coupled) Služby mají hrubozrnné (coarse grained) aplikační programovací rozhraní API. Komunikace mezi službami je typicky asynchronní (asynchronous communications). Důsledně se využívají oborové standardy (standard based). Služby jsou znovupoužitelné (service reuse). Na znuvupoužitelnost se nahlíží jako na žádoucí vedlejší efekt (nikoli cíl) potvrzující dobrou implementaci SOA principů. Metadata služeb jsou uložena v úložišti (metadata repository). Na implementaci SOA architektury můžeme podle uvedeného nahlížet prakticky ze dvou základních pohledů a to, přes web services (webové služby) a ESB (Enterprise Service Bus). Podnikové procesy a jejich modely hrají významnou roli v obou těchto přístupech. CASE nástroje pak prakticky v celém vývojovém i udržovacím a řídícím cyklu. 5 S t r á n k a

Obrázek 1 Rozdíl mezi klasickou a SOA Architekturou, zdroj: (SUN Microsystems 2008) 2.1 Vývojový cyklus architektury SOA, SOA Maturity Model Jak jsem se pokoušel vysvětlit výše, tak zavádění architektury SOA je značně závislé na přístupu celého podniku k jeho zavedení, a to ještě důležitější než tomu bávalo dříve např. u zavádění ERP systémů. SOA je totiž architektura, je nadmíru flexibilní a potřebuje neustálou kontrolu, dohled a rozvíjení. Pokud je efektivně řízená splní i ty nejnáročnější požadavky. Proto, aby byla stanovena úroveň daného podniku a dané architektury, která je nebo bude zavedena. Vznikl tzv. SOA Maturity Model (Model zralosti architektury SOA). Pro názornost uvedu dva příklady, jeden opět podle (Jindřich Štumpf, Progress 2006), a to SOAMM (Service-Oriented Architecture Maturity Model), který je společným dílem společností AmberPoint, BearingPoint, Sonic Software a Systinet na obrázku 2. 6 S t r á n k a

Obrázek 2 SOAMM Maturity model, zdroj: (Jindřich Štumpf, Progress 2006) Stejně jako všechno v SOA architektuře, tak i zralostní modely se mírně liší u každé velké IT společnosti. Druhým příkladem je SOA Maturity Model od společnosti Oracle na obrázku 3. Obrázek 3 Oracle SOA Maturity model, zdroj: (Griffiths Waite, The Oracle SOA Company 2008) Na modelu společnosti Oracle je více znatelný důraz na BPM (Business Process Modelling), BPA (Business Process Analysis) a BAM (Business Activity Monitoring). Je vyzdvihován i důraz na optimalizaci jednotlivých procesů, tedy stále větší podporu IT služeb do celého fungování daného podniku. Přístup společnosti IBM je opět mírně odlišný a bude zmíněn níže. 7 S t r á n k a

2.2 Řízení architektury SOA- SOA Governance Pro potřeby naší práce o nástrojích CASE stačí zmínit, že SOA Governance je série přístupů pro řízení, údržbu a monitorování SOA Architektury. Vzhledem k rozlehlosti a heterogenitě SOA je však nadmíru složité tyto výstupy zobrazovat a efektivně řídit. Pro tyto potřeby jsou CASE nástroje naprosto ideální. Např. nástroje ID- Scheer jsou v tomto ohledu na velice vysoké úrovni. Kromě řízení SOA z hlediska IT pak v sobě SOA governance skýtá možnosti, kdy je v reálném čase možné pozorovat např. počet uživatelů v systému, na přepážce atd. S kvalitními dashboardy a prezentací výsledků pak prakticky může do jisté míry suplovat i nástroje Business Intelligence. Obrázek 4 Řízení Architektury SOA za pomoci BPM, zdroj: (AlterFiction 2008) Nyní po zevrubném popsání SOA Architektury a jak si v ní stojí nástroje CASE nástroje a podnikové procesy můžeme přistoupit k analýze vybraných CASE nástrojů na trhu. 8 S t r á n k a

3 IDS (IDS Scheer 2008) Scheer, nástroje ARIS Německá společnost IDS- Scheer je pravidelně vedoucí společností ve výzkumech Gartneru pro Business Process Analysis. Majitel a ředitel společnosti Prof. Dr. Augustem Wilhelmem Scheer, je navíc právem považován za jedno ze zakladatelů tohoto přístupu pro řízení společnosti I pro vývoj software. V současnosti má společnost kolem 7000 zákazníků po celém světě. Nástroje ARIS mají propracovanou metodiku pro návrh, implementaci, strategii a kontrolu podnikových procesů. V duchu metodologie ARIS Business Process Excellence, procházejí všechny nástroje ARIS. Tedy i nástroje pro návrh a řízení architektury SOA. Nástroj pro, který IDS Scheer používá pro SOA architekturu, se jmenuje ARIS SOA Architect, je začleněn do fáze Process Implementation, kde se jedná o nejnižší technologickou úroveň kam až je platforma ARIS schopná zajít. Obrázek 5 Vývojový cyklus ARIS, zdroj: (IDS Scheer ČR 2008) 3.1 ARIS SOA Architect Nástroj ARIS SOA Architect umožňuje z již definovaných a namodelovaných business procesů vygenerovat BPEL (Business Process Execution Language) specifikaci pro spuštění samotných služeb. Případně může použít nástrojů ARIS Business Architect pro namodelování business procesů, které ještě nejsou vytvořené. Je důležité si uvědomit, že nástroj ARIS SOA Architect neslouží pro samotné spuštění a orchestraci webových nebo jiných služeb. ARIS generuje spustitelnou BPEL specifikaci, která je přímo určena pro spouštěcí platformy IBM WebSphere, BEA WebLogic nebo SAP XI. Společnost Oracle má pak vlastní řešení Oracle Process Manager, který byl vyvíjen spolu s ID-Scheer, není tedy zahrnut do tohoto výčtu. 9 S t r á n k a

3.1.1 Proces přeměn podnikového procesu na spustitelnou službu Pro výrobu služby architektury SOA na platformě ARIS, je jak jsem výše napsal, nutný již exitující business proces. Ten může být namodelován jak v klasických arisovských EPC (Event process chain) diagramech tak v notaci BPMN (Business Process Management Notation), tedy v BPD (Business Process Diagram, jediný model používaný v BPMN). Tyto modely jsou mezi sebou navzájem převoditelné, pro případ že by daná společnost již měla vytvořený procesní model a chtěla ho zakomponovat do SOA architektury. Výhodou SOA je znuvupoužitelnost služeb, aby tyto mohly být neustále využívány, musí být k dispozici jejich popis a přiřazení k jednotlivým business procesům. K tomuto účelu využívá ARIS tzv. ARIS Service Browser, kde řídí přístupová práva, definuje, která služba využívá které business procesy a vede záznamy o všech službách, aby mohly být využity jinými komponentami. Pokud jsme se dostali až do této fáze, je možné vygenerovat z daného EPC nebo BPD modelu spustitelný BPEL proces. Ještě předtím, ale ARIS umožňuje za použití svého nástroje ARIS UML Designer vygenerování UML (Unified Modelling Language) diagramu, aby bylo možné v budoucnu rozvíjet danou službu na úrovni vývojáře software. Následně je vygenerován samotný BPEL proces, který je spuštěn na doporučovaných platformách, popsaných výše. Jednou z největších zbraní IDS Scheer a ARIS SOA Architecture je pak ARIS Central Repository. Toto centrální úložiště neustále udržuje konzistenci mezi jednotlivými modely ARISu, BPEL modely a spustitelnými službami z daného BPEL enginu. Tímto je zajištěna neustálá konzistence ve všech stupních dané služby a business proces lze neustále vyvíjet. ARIS SOA Repository dokonce použil i Oracle u svého Process Composera. 10 S t r á n k a

Obrázek 6 ARIS SOA Repository, zdroj: (IDS Scheer ČR 2008) 3.2 ARIS Business Rules Designer Umožňuje řídit pravidla, oprávnění a role jednotlivých zaměstnanců společnosti. Umožňuje tak velice efektivně řídit přístupová práva k jednotlivým službám SOA Architektury. Kromě samotného zdokumentování přístupových pravidel a řízení bezpečnosti má mnoho automatických kontrolních mechanismů. Například duplicitu pravidel, vyvýšenost určité role nad ostatní ve stejné linii řízení, kontrolu proti sobě jdoucích pravidel atd. 3.3 ARIS Process Performance Manager Díky provázanosti služeb v SOA Architektuře a procesních modelů v ARISu, je možné řídit celou architekturu za pomoci nástrojů dříve určených spíše pro ukazování výkonnosti podniku. Výhody nástroje ARIS PPM pro architekturu SOA jsou především následující: Performance Dashboard umožňuje za pomoci stanovených KPI sledovat výkonnost jednotlivých procesů. Zároveň je možné business procesy, které ukazují nejlepší výkonnost publikovat pro celou společnost a vytvořit tím jakýsi best practice model. 11 S t r á n k a

Zjištění vytíženosti jednotlivých procesů, kdy umožňuje zjistit, které služby jsou přetěžované, a které se naopak nevyužívají. Online monitoring a systém včasného varování, umožňují například sledovat procesy související se SLA (Service Level Agreement), což je pro SOA architekturu velice důležité. Při vznikajících problémech a překročení definované prahové hodnoty je příslušný pracovník varován. Všechna vyjmenovaná funkcionalita pak může být zobrazována za pomoci klasického manažerského kokpitu. 3.4 Závěr IDS Scheer, ARIS Společnost ISD Scheer je dlouhodobě na špičce BPM. Trend architektury SOA jí pouze nahrává, protože podobná funkcionalita je prakticky obsažena v jejích dřívějších produktech. Zároveň IDS Scheer chytře odhadla svoje možnosti a nepouštěla se do, pro ni, neprověřených oblastí jako jsou ESB nebo BPEL engine pro spouštění služeb. Raději spolupracuje s předními výrobci v těchto oblastech jako IBM nebo Oracle. Naproti tomu co se týče ARIS SOA Repository, tedy jednotného úložiště pro modely používané v SOA Architektuře, jedná se o referenci v oboru, kterou využívá i společnost jako je Oracle. V budoucnu můžeme od ARISu čekat další vývoj v této oblasti a rozvíjení spolupráce mezi modely EPC a notací BPMN, který se stává spolu s nástupem SOA, stále podstatnější. 12 S t r á n k a

4 Nástroje společnosti Telelogic 4.1 O společnosti (CXO Today, IBM acquires Telelogic, Telelogic AB je původem švédská společnost, v dubnu 2008 ji však převzalo IBM 2008). O úspěšnosti jejich produktů hovoří zejména fakt, že je používají velké světové společnosti z oblasti automobilismu, telekomunikace a zbrojařství, mezi jinými např. Airbus, Boeing, Lockheed Martin, BMW, GM, DaimlerChrysler, Ericsson, Siemens, T-Mobile, Vodafone, Motorola, Philips, Deutsche Bank nebo General Electric. Telelogic také zaujímá dobré pozice v Gartner kvadrantech pro Enterprise Architecture Tools Quadrant for EA, 2008), a BPA. (Gartner, Magic 4.2 Přehled nástrojů Produkty Telelogic podporují celou řadu činností, budováním podnikové architektury (enterprise architecture) za pomocí BPM počínaje, přes definici a správu SOA až po vývoj a řízení životního cyklu aplikace. Z hlediska naší práce jsou nejzajímavější nástroje System Architect a Tau, které SOA přímo podporují. Telelogic Focal Point Telelogic DOORS Telelogic Synergy Telelogic Rhapsody Telelogic DocExpress Telelogic System Architect Telelogic Tau Management portfolia produktů Management a sledování požadavků SVN a správa nastavení UML modelovací nástroj pro technické systémy Produkce dokumentace modelování a správa BPM a EA UML modelování, vývoj a testování aplikací 13 S t r á n k a

Obrázek 7 Architektura Telelogic řešení, zdroj: (Telelogic 2008) 4.3 Telelogic System Architect System Architect (dále SA) je nástroj pro modelování a správu BPM a EA. Na společnost nahlíží z pohledu pěti domén: strategie, procesy, informace, systémy a technologie. SA slouží celé škále rolí, jak ukazuje tabulka vpravo. Propojenost jednotlivých vrstev Obrázek 8Vrstvy modelů v SA, zdroj: (Telelogic 2008) zajišťují mimo jiné časové plány (roadmaps), které popisují vztahy mezi entitami (např. mezi procesy a službami, které je podporují) a zároveň umožňují plánovat a simulovat vývoj a změny, tedy například pokud firma plánuje rozšířit proces objednávek o nové cesty, jaký bude dopad v čase na služby, které jej podporují. (viz obrázek 11 a 12). Z tohoto důvodu SA také umí z časových plánů automaticky generovat Ganttovy diagramy. 4.3.1 System Architect - vlastnosti a podporované koncepty Nástroj je v současné době nabízen pouze pro platformu Windows. (Wikipedia, System Architect, 2008) Vlastnosti a podporované koncepty: EA frameworky a referenční modely o TOGAF (The Open Group Architecture Framework) o DoDAF 1.5 (Department of Defense Architecture Framework) o MODAF (UK Ministry of Defence Architectural Framework) o IAF v4 Integrated Architecture Framework o Federal Enterprise Architecture via irma add-on option o Zachman framework BPM 14 S t r á n k a

o simulace BPMN modelů v SA simulátoru o generování BPEL SOA Balanced Scorecard OMG Business Motivation Model (BMM) Analýza příčin a důsledků v Explorer diagramu Funkční dekompozice Organizační diagramy Modelování síťové architektury Application Portfolio Management UML podpora generování modelů na základě kódu v C++, Java, Visual Basic 6, Visual Basic.NET Logický a fyzický datový model Reverse Engineering pro: Oracle 10G, SQL Server 2005, IBM DB2 UDB V8, Sybase, and Teradata 2.6 Data flow diagramy IDEF (Integration DEFinition) Víceuživatelské prostředí Reportovací jazyk založený na SQL Přístupová oprávnění na základě rolí Native Requirements management Rozšiřitelnost skrze: o Metamodelování o VBA skripty Webový klient Podpora komunikace s MS Visio Generování webových stránek 4.3.2 System Architect a SOA Cílem SA je poskytnout uživatelům snadné provázání byznys cílů s procesy a jejich podporu IT prostředím. Na jednom konci je zde navíc integrace s Telelogic DOORS, které se detailněji zabývají požadavky a na druhém integrace s Telelogic Tau, který je více zaměřený na vývoj a implementaci služeb. Zavádění SOA většinou začne identifikováním stávajícího portfolia aplikací a služeb a vytvořením IT prostředí (landscape). Model obsahuje fyzický i logický pohled a lze na něj nahlížet skrze mnoho diagramů, například skrze diagram spolupráce nebo diagram hierarchie služeb. Dalším krokem je namapování podnikových procesů a požadavků na služby. SA pak poskytuje v reálném čase analýzu a plánování vývoje a změn. Za zmínku stojí například teplotní mapy (heatmaps) ukazující barevně výkon jednotlivých součástí systému nebo časové plány ukazující dopad budoucích změn na časové ose. Diagram závislosti zase ukazuje souvislosti zasažených součástí. Celé řešení dodává informace v různé míře abstrakce, zachovává si však integritu napříč modely, reprezentacemi a jazyky a data čerpá z jednotného úložiště, které je dostupné i dalším aplikacím. 15 S t r á n k a

Obrázek 9 Teplotní mapa v SA ukazující aplikace Obrázek 10 Diagram závislostí Obrázek 11 Časový plán v první fázi Obrázek 12 Časový plán v druhé fázi, zdroj: (Telelogic 2008) 4.3.3 System Architect klady a zápory Gartner zpráva (Gartner, Magic Quadrant for EA, 2008) uvádí jako hlavní klady SA robustní podporu vývoje a správy podnikové architektury stejně jako dobré postavení na trhu BPA nástrojů. Do budoucna předpokládá užší spolupráci s dalšími IBM produkty, což je další výhoda. Jako slabinu můžeme zmínit obtížnější osobní přizpůsobení, která má pouze sice velmi bohaté, ale pouze textové rozhraní grafické chybí. 4.4 Telelogic Tau Je nástroj pro Model Driven Development (MDD) za pomocí (Telelogic): Unified Modeling Language (UML 2.1) Systems Modeling Language (SysML 1.0) Extensible Markup Language (XML) UML Testing Profile (U2TP) knihoven často užívaných objektů a modelů Vývoj umožňuje reagovat na postupné požadavky, Tau dokáže simulovat běh modelů, čímž umožňuje v kterékoliv části vývoje ověření funkcionality. Tím se může zamezit chybám v návrhu už na počátku a tak ušetřit na nákladech na vývoj. Produkt podporuje generování kódu, dokumentace a testovacích scénářů. 16 S t r á n k a

4.4.1 Telelogic Tau specifikace (Telelogic, Official site, 2008) Zdroj: Platformy: Windows XP Sun Solaris Redhat Enterprise Linux Citrix XPe Kompilery: Java SDK (versions 1.4, 5, 6) Microsoft Visual Studio.NET C++/C# gnu gcc Sun Studio C/C++ Integrace do IDE: Obrázek 13 Vývojové prostředí Tau, zdroj: (Telelogic 2008) Microsoft Visual Studio.NET Eclipse Frameworky: J2EE Java EE 5 J2SE Java SE 5 Java SE 6 17 S t r á n k a

4.4.2 Telelogic Tau a SOA Výhodou MDD v případě vývoje SOA komponenty je platformová nezávislost a snazší znuvupoužitelnost komponent. Simulace se netýká jen jednotlivých součástí, ale i složených služeb a služeb třetích stran. Služby mohou být přidány do systému třemi způsoby: (Telelogic. Telelogic Tau for model-driven SOA, 2008) : vývoj nových služeb na základě modelu, implementovaného do Javy, C# nebo C++ včetně WSDL rozhraní reverzní inženýrství a vizualizace stávajících služeb ze zdrojového kódu obalením např. COM nebo. NET aplikací tzv. SOA wrapperem pro jejich reprezentaci jako služby Obrázek 14 Ukázka zapojení služeb různého původu v Tau, zdroj: (Telelogic 2008) S architekturou služeb je pak možné v Tau: orchestrovat a monitorovat služby generovat, importovat a vizualizovat WSDL přistupovat k ní z jednotného úložiště black-box testování automaticky kontrolovat konzistenci 18 S t r á n k a

Obrázek 7 Model WS Obrázek 15 Vygenerovaná WS Obrázek 16 Testování WS, zdroj: (Telelogic 2008) 4.5 Ukázkový scénář zavádění SOA za pomocí nástrojů Telelogic Spolupráce Telelogic nástrojů je možné ukázat na společnosti, která se rozhodla zavádět architekturu orientovanou na služby. (Telelogic, Model-Driven SOA: Achieve Higher Productivity Gains throughout the Design Process, 2008) Na začátku je nutné stanovit si cíle a následně vytvořit mnohostranný model podnikové architektury zahrnující fyzickou strukturu organizace, aktiva, požadavky, role a odpovědnosti. Na základě analýzy výše uvedeného zvolit vhodnou strategii a procesy. Každý proces je Obrázek 17 Workflow modelově řízené SOA, zdroj: (Telelogic 2008) detailně rozebrán a tím se získají specifičtější požadavky na služby, projekty a aplikace. Každý takový proces obsahuje: popis vstupů, výstupů, požadavků, včetně nároků na služby architektonický pohled na řešení fungování, způsob implementace a uživatele Během celé doby plánování je možné sledovat požadavky skrze DOORS. Ve chvíli, kdy je business model hotový, je možné v Telelogic Tau navrhovat, integrovat a implementovat služby. Tau využívá specifikací business modelu pro analýzu funkcionality a chování. Výsledkem je vývoj modelu, který definuje vnitřní řešení. 19 S t r á n k a

Analytický Tau model je dále rozváděn do návrhových a implementačních modelů a vše se testuje. Stávající aplikace a služby jsou zapojovány do dění, generuje se kód. Jakmile mají všechny komponenty orchestraci a choreografii, přichází nasazení do provozu a monitorování. Tau poskytuje náhled na úrovni technologické a návrhové, SA na vyšších business úrovních. 20 S t r á n k a

5 Oracle SOA suite 5.1 Úvod Společnost Oracle patří v současné době bezpochyby ke klíčovým hráčům na poli IT. Ačkoliv klíčovým prvkem jejího portfolia produktů je databáze, pomocí celé řady akvizic vznikla společnost s velmi širokým spektrem produktů. Vzhledem k tomu, že SOA patří v současné chvíli k nejfrekventovanějším termínům v oblasti IT, není překvapením, že Oracle chce nabídnout ucelenou skupinu produktů, která by měla být schopna po technologické stránce pokrýt všechny potřeby společnosti, jež se rozhodne přejít na servisně orientovanou architekturu. 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 do kompozitních aplikací a obchodních procesů. (Oracle, 2008, http://www.oracle.com/global/cz/technologies/soa/soasuite.html) Je však tento balík opravdu kompletním řešením? Jaké oblasti návrhu, tvorby, řízení a provozu informačních systémů založených na SOA opravdu podporuje? 5.2 Komponenty Oracle SOA Suite Jak již bylo řečeno výše, tento balík aplikací je produktem s ambicemi plně pokrýt všechny potřeby společnosti chystající se budovat, upravovat a řídit informační systém založený na službách. Skládá se ze značného množství komponent, které společnost Oracle či některé jiné společnosti (které byly firmou Oracle zakoupeny) nabízely jako samostatné produkty. Příkladem může být Oracle ESB. Hlavními komponenty tohoto komplexního produktu jsou: Oracle BPEL Process Manager Oracle Enterprise Service Bus (ESB) Oracle Web Services Manager (OWSM) Oracle Business Rules Oracle Application Server Service Registry Oracle JDeveloper Oracle Application Server Jak je vidět, jedná se o opravdu širokou škálu nástrojů a sama společnost ORACLE v tuto chvíli tvrdí, že jde o jediné portfolio produktů na trhu, které dokáže pokrýt veškeré oblasti tvorby, implementace a provozu SOA aplikací. Otázkou zůstává, zda se jedná o podstatnou výhodu v situaci, kdy většina zákazníků kombinuje různé komponenty a kompletní IT infrastruktura od jednoho dodavatele je raritou. 21 S t r á n k a

Obrázek 18 : Součásti Oracle SOA Suite, zdroj: (Oracle, 2008) 5.3 Životní cyklus a podpora tvorby služby Tato sada nástrojů zároveň pokrývá celý životní cyklus vývoje a nasazení SOA aplikací, respektive jednotlivých služeb do již fungujícího systému, a to od návrhu služby, přes tvorbu kódu, testování, verzování a nasazení produktu: 22 S t r á n k a

Obrázek 19 : Životní cyklus tvorby nové služby zdroj: (Oracle, 2008) Hlavním nástrojem pro podporu návrhu nové služby či procesu je v případě společnosti Oracle již dlouhodobě JDeveloper. Její zaměření reflektuje dlouhodobou strategii firmy z hlediska technologií, kdy je výrazně preferována platforma Java (ačkoli samozřejmě žádná marketingová prezentace neopomene zmínit, že celá tato sada je bez problémů integrovatelná s jakýmkoli řešením na platformě.net). 23 S t r á n k a

Obrázek 20 : Interface Oracle jdeveloper zdroj: (Oracle, 2008) JDeveloper historicky vychází z licence známého nástroje jbuilder od společnosti Borland, jeho záběr se však za deset let jeho existence velmi rozšířil. V současné chvíli se jedná o nástroj určený k podpoře vývoje aplikací, služeb (například webových) nebo návrhu databází (ačkoli primárním nástrojem pro návrh databází zůstává pro Oracle SQL Developer). Většina konzultantských společností výrazně varuje před zaměňováním SOA za webové služby, přičemž správně upozorňují, že webové služby jsou jen jedním z technologických prostředků k dosažení SOA architektury. I přes to však zůstávají webové služby hlavní technologií v této oblasti a JDeveloper to plně reflektuje - návrh služby a webové služby jsou v JDeveloperu v podstatě synonyma. Jakkoli mohou být odpůrci webových služeb hlasití na konferencích a prezentacích, na převaze WS jako způsobu nasazení SOA se v blízké budoucnosti pravděpodobně nic měnit nebude. Pro tvorbu služeb (WS) rozeznává JDeveloper dva hlavní přístupy: bottom-up a top-down development. Tvorba služby postupem Bottom-up 24 S t r á n k a

V případě postupu bottom-up se jedná o "transformaci" již existujícího kódu, například třídy v Javě, do podoby služby. Jako většina CASE nástrojů umožňuje JDeveloper výraznou automatizaci tvorby kódu a tvorba služeb není výjimkou. Z třídy v jazyce Java dokáže JDeveloper vytvořit webovou službu "jedním kliknutím, přičemž vše podstatné včetně WSDL souboru a JAX-WS (Java API for XML - Web Services) je vygenerováno. Obrázek 21 : Tvorba nové služby z existující třídy v Javě zdroj: (Oracle, 2008) Po vytvoření prázdné služby jednoduše dojde k jejímu provázání s příslušnou Java třídou/třídami. Pak již zbývá jen zvolit, jaké metody těchto tříd mají být vystaveny k použití danou službou. Zde ovšem, stejně jako všechny obdobné nástroje, naráží i JDeveloper na logické omezení podobného přístupu k vývoji a tvorbě kódu - bez perfektní znalosti způsobu generování kódu může snadno dojít k problémům, navíc tento způsob značně komplikuje hledání chyby a dodatečné drobné úpravy kódu. Pokud se jedná například o třídu "nevhodně" napsanou (z hlediska jejího použití v tomto kontextu), může tento postup vést ke značným komplikacím. Na druhou stranu představuje zajímavou možnost rychle "recyklace" velké části již existujícího kódu a může velmi usnadnit implementaci SOA v příslušné organizaci. Nejedná se o jediný způsob tvorby služby metodou bottom-up, v případě technologicky komplikovanější transformace je možno se oprostit od "wizard-guided" postupu. Tento příklad však pravděpodobně nejjasněji ukazuje tento způsob tvorby nové WS. Tvorba služby postupem Top-down 25 S t r á n k a

V případě postupu Top-down začíná tvorba služby u WSDL - za použití WSDL JDeveloper vygeneruje značnou část potřebných součástí. V první fázi dojde k ověření validity WSDL dokumentu, dále je na základě něj generován zbytek dokumentů a komponent potřebných pro WS v pojetí aplikace JDeveloper. Oproti prvnímu příkladu je zde výrazně menší riziko nekonzistencí a problémů při komunikaci a vyšší interoperabilita výsledné služby, jelikož její návrh v podstatě začínám popisem formátů zpráv, které bude daná služba používat. Nasazení vytvořené služby Aplikace JDeveloper pokrývá celý životní cyklus tvorby nové služby až po její nasazení. To může proběhnout na Oracle Application Server nebo na některou jinou podporovanou platformu. JDeveloper vygeneruje web archive soubor (WAR), jehož nasazení může proběhnout pouhým kliknutím v kontextovém menu. Obrázek 22 : Nasazení vytvořené služby zdroj: (Oracle, 2008) 5.4 Procesy a Oracle SOA Suite Z hlediska návrhu procesů a jejich následného využití při řízení běhu IS a lidského WF jsou, stejně jako v případě tvorby služeb, různé fáze životního cyklu podporovány různými produkty. Design těchto procesů 26 S t r á n k a

může probíhat ve výše zmíněném JDeveloperu stejně jako v otevřeném vývojovém prostředí, jakým je například Eclipse. Je tedy možno vytvořit proces klasickou drag-and-drop metodou. Obrázek 23 : Tvorba a nasazení BPEL procesů v Oracle SOA Suite zdroj: (Oracle, 2008) Zde vytvořený procesní model je pak využit Oracle BPEL Serverem. Z uvedeného obrázku je patrné, že tento server není, stejně jako většina ostatních součástí Oracle SOA Suite, vázán pouze na tuto sadu a je možno ho provozovat na různých serverech s podporou platformy J2EE. Krom Oracle Application Serveru tak může být využit například BEA Web Logic, který je čerstvou součástí portfolia Oracle, nebo zcela konkurenční produkty jako IBM WebSphere. 27 S t r á n k a

Obrázek 24 : Vlastnosti BPEL serveru společnosti Oracle zdroj: (Oracle, 2008) Z hlediska vlastností Oracle BPEL Serveru stojí za zmínku uvedená podpora BPEL 1.1. Plnou podporu BPEL 2.0 tedy pravděpodobně přinese až některá z dalších verzí této sady. V oblasti správy, ladění a kontroly BPEL procesů poskytuje Oracle BPEL Process Manager velice široké spektrum funkcí, umožňujících efektivní správu systému. 5.5 Závěr Oracle SOA Suite je bezpochyby velice kvalitní produkt, jenž v oblasti, kterou funkčně porývá, patří ke špičce trhu. Z hlediska podpory tvorby a řízení architektury založené na SOA je však jeho zaměření poněkud jinde než u některých ostatních zde zmiňovaných produktů. Výborně podporuje především samotný technologický návrh jednotlivých služeb a procesů a zároveň poskytuje silné nástroje pro jejich efektivní ladění, správu a provoz. Ačkoli tedy společnost Oracle hrdě prohlašuje, že se jedná o jediné kompletní řešení SOA na trhu, s mírným zjednodušením by se dalo tvrdit, že SOA Suite začíná tam, kde například ARIS SOA Architect končí u spustitelných modelů procesů v notaci BPEL. Je tedy možno říci, že i přes marketingové proklamace v kompletním balíku Oracle SOA Suite silný nástroj pro řízení architektury SOA chybí. 28 S t r á n k a

6 CASE nástroje společnosti IBM pro řízení architektury SOA Společnost IBM je jedním z nejvýznamnějších hráčů na trhu s nástroji pro řízení architektury SOA. IBM totiž stálo již u zrodu samotné architektury a principů servisně orientované architektury. Navíc průzkum časopisu BusinessWire prokázal, že IBM je celosvětovým leaderem na trhu se servisně orientovanou architekturou. (Anonymous 2008) IBM totiž má na celém světě 5700 klientů a její tržní podíl činí 64%. Význam společnosti navíc poroste. Tentýž průzkum totiž prokázal, že celosvětový obrat v roce 2007 činil 2 miliardy amerických dolarů a v roce 2014 obrat už má být ve výši 9 miliard dolarů. Z toho je evidentní, že je potřeba zabývat se nástroji IBM pro řízení servisně orientované architektury. 6.1 Servisně orientovaná architektura v pojetí IBM Jelikož IBM je světovou jedničkou na trhu se servisně orientovanou architekturou, a jelikož má značný vliv na její další vývoj, je velice užitečné získat přehled o tom, jak IBM vidí použití SOA v podnicích a jak SOA podle IBM lze využívat. V tomto kontextu je vhodné si představit iniciativu IBM, která se jmenuje "Service Science, Management and Engineering", tedy SSME (IBM nedatováno). Jedná se o kombinaci počítačové vědy, operačního výzkumu, inženýrství, managementu, strategického plánování, sociálních věd, kognitivních věd a právních věd za účelem zlepšení produktivity, kvality, kvality výuky i míře inovativnosti služeb. Globální trendy totiž poukazují na fakt, že se podnikání bude v budoucnu čím dál tím více soustředit na služby, a že služby budou právě z toho důvodu klíčové pro přežití v konkurenčním boji. IBM z těchto důvodů propaguje "službu jako vědu", aby se věda o službách stala stejně důležitou disciplínou, jakými dnes jsou například management nebo marketing. Proto IBM spolupracuje s různými společnostmi na světě a s univerzitami jako jsou například MIT, Stanford, Berkeley anebo Masarykova universita (IBM nedatováno). IBM ve spolupráci s těmito společnostmi a vysokými školami rozvíjí úroveň a použitelnost služeb v podnikatelském prostředí - ať už se jedná o výzkum, výuku, všeobecnou osvětu, sdílení osnov, pořádání konferencí nebo pomoci při získávání grantů. IBM navíc poskytuje SSME platformu, na které je možné publikovat články, přistupovat k nim, prohlížet si případové studie anebo spojit se s jinými subjekty, které se zajímají o rozvoj služeb. SSME tedy je praktickou ukázkou, jak se IBM podílí na rozvoji služeb a jak velký na něm má vliv. Před samotným představením nástrojů pro řízení architektury SOA proto bude nejprve vysvětleno, do jakých stylů IBM rozděluje úroveň použití SOA v podnicích a jak lze použít SOA v podnicích. 6.1.1 Styly SOA IBM například rozděluje úroveň použití SOA v různých podnicích. Tento model zralosti se skládá ze čtyř úrovní. Tyto jednotlivé úrovně jsou základní styl, komplexní styl, styl transformace a styl dynamické adaptace. 29 S t r á n k a

(IBM, The smart SOA approach 2008) Obrázek 25: Přehled o stylů použití SOA v podnicích Základní styl přináší podniku největší hodnotu ve zvýšení agility informačních technologií. V takové společnosti se realizují jen takové projekty, které mají vysokou návratnost. Informační architektura společnosti se základním stylem je taková, že méně než 10 % aplikací jsou dostupné jako služby a méně než 5 % služeb bývají znovupoužité. Komplexní styl využívání servisně orientované architektury podporuje celý průběh business procesů ve společnosti. Oddělení informačních technologií v takové společnosti má zodpovědnost za inovaci a optimalizaci procesů. Méně než celkem 40 % aplikací jsou v takovéto firmě dostupné jako služby a méně než 20 % služeb jsou znovu používané. Podniky, jejichž úroveň stylu použití architektury SOA dosahuje komplexní úrovně, podporují všechny své procesy pomocí servisně orientované architektury. IT v takových společnostech je strategickou výhodou a IT je navíc schopné inovovat i samotný business model. Méně než 80 % aplikací jsou dostupné pomocí webových služeb a méně než 50 % služeb se vícenásobně používají. Poslední, nejvyšší styl použití architektury SOA je styl dynamické adaptace. V této fázi SOA je schopna predikovat vývoj na trhu a dynamicky se přizpůsobovat změnám v tržním prostředí. IT v této úrovni již je neviditelné a podporuje business právě takovým způsobem, jak je potřeba. Počty dostupnosti a znovupoužití jsou stejné jako u stylu transformace. 6.1.2 Vstupní body do architektury SOA Většina společností ovšem ještě vůbec nemá implementovanou architekturu SOA a nenachází se na žádné ze zmiňovaných úrovní. Pro představení servisně orientovaného řešení IBM mluví o různých druzích pohledů na a práce se servisně orientovanou architekturou. Tyto druhy IBM nazývá vstupní body do architektury SOA (IBM, Vstupní body architektury SOA nedatováno). Jednotlivé vstupní body a z nich plynoucí výhody pro podnikání jsou: Vstupní bod osob Procesní vstupní bod 30 S t r á n k a

Informační vstupní bod Vstupní bod znovupoužitelnosti Vstupní bod konektivity (IBM, The smart SOA approach 2008) Obrázek 26: Vstupní body architektury SOA Vstupní bod osob se zaměřuje na využití servisně orientované architektury zaměstnanci. Tito díky SOA pracují s celistvým informačním systémem a nemusejí se učit pracovat s různými izolovanými částmi. Využívání servisně orientované architektury v podnicích podle IBM povede ke zvýšení produktivity, k jednoduššímu přistupování do různých aplikací, ke kratší době nasazení, ke flexibilnímu využití procesů, k orchestraci všech procesů ve společnosti a k zjednodušení spolupráce mezi samotnými zaměstnanci. Na servisně orientovanou architekturu ovšem lze nahlížet i z procesního hlediska. SOA je totiž schopna podporovat a automatizovat všechny business procesy napříč celé organizaci a nemusí brát ohled na různé aplikace, které podporují jeden a ten samý proces. Podpora procesů pomocí SOA tedy přinese lepší produktivitu, větší úroveň spolupráce mezi procesy a zvýšení návratnosti investic. Využití servisně orientované architektury pro procesy navíc zrychlí dobu potřebnou pro zavedení nového produktu, dobu pro změnu obchodního modelu a dobu potřebnou pro implementaci dalších procesů. SOA kvůli své povaze může být využita i ve vztahu k informacím. Servisně orientovaná architektura totiž umožní poskytovat informace jako službu. Pokud jednotlivé druhy informací budou přístupné jako služby, tak se díky tomu zlepší přístupnost k informacím, jejich konzistence, možnosti sdílení, úroveň managementu dat, jejich využití procesy, jejich využití lidmi a jejich správa. Informace v tomto případě totiž budou centrálním způsobem rozdělovány podle potřeby v celém podniku. 31 S t r á n k a

Dalším vstupním bodem je vstupní bod znovupoužitelnosti. Tento vstupní bod je IT pohled na SOA a umožňuje outsourcovat celé oblasti podnikání a identifikovat nedostatky ve využití informačních technologií ve firmě (například může existovat více služeb pro tu stejnou činnost). Znovupoužití služeb, které jsou dostupné přes servisně orientovanou architekturu, povede k nižšímu množství napsaného kódu, k maximálnímu využití stávajících systému, k nižším nákladům na správu aplikací, k možnosti sestavení kompozitních služeb a k integraci zastaralých, ale ověřených a prozkoušených systémů s nejmodernějšími produkty na trhu. Posledním vstupním bodem, o kterém IBM hovoří, je vstupní bod konektivity, který zajišťuje bezpečné spolehlivé a škálovatelné propojení a připojení lidí, procesů a informací k informačním a komunikačním technologiím společnosti, které podporují business procesy, čili chod celé společnosti. Začlenění konektivity do architektury SOA přinese firmě zlepšení ve workflow, v procesech, které probíhají napříč celou organizací. Řešení konektivity přes SOA navíc přizpůsobí informační technologie růstu společnosti a využití IS/ICT se navíc stane nezávislé na komunikačních kanálech a na prezentačních přístrojích. 6.2 Oblasti servisně orientované architektury pokryté IBM Jako celosvětově největší dodavatel servisně orientované architektury, IBM nabízí nástroje pro řízení SOA v celé řadě různých oblastí (IBM, Smart SOA. Od jednoduchého ke složitému nedatováno). Lze přímo hovořit o platformě od IBM, která pokrývá vše, co je spojené se servisně orientovanou architekturou. SOA platforma IBM se totiž z následujících komponent: Prostředí pro spotřebitele služeb Prostředí pro poskytovatele služeb Middleware Integrační prostředí Vývojové prostředí Management aktiv servisně orientované architektury Nástroj pro publikování Nástroj pro service level management Nástroj pro management bezpečnosti 32 S t r á n k a

Prostředí pro měření a monitorování Diagnostiku Podporu web service protokolů Identity management Prostředí pro deployment Nástroj pro verzování 6.3 Smart SOA Po teoretickém úvodu budou nyní představeny všechny CASE nástroje pro řízení architektury SOA od IBM. Tyto produkty IBM nabízí pod souhrnným názvem "Smart SOA" (IBM, Servisně orientovaná architektura nedatováno). Z výše uvedeného přehledu platformy IBM pro servisně orientovanou architekturu je zřetelné, že není možné představit všechny nástroje v plném detailu. Proto budou nástroje nyní shrnuty do skupin a hrubě představeny. Nástroje pro business process management v prostředí servisně orientované architektury poté budou představeny znovu a detailněji v dalším průběhu výkladu. Nyní tedy budou představeny nástroje z procesní oblasti, z oblasti informací, z oblasti orientace na uživatele, z oblasti konektivity ke službám, z oblasti znovupoužitelnosti a z oblasti administrativy a kontroly. Drtivá většina z portfolia produktů IBM, které se zabývají servisně orientovanou architekturou, patří pod skupinu nástrojů IBM WebSphere. Výklad se tedy bude týkat hlavně nástrojů IBM WebSphere. Mezi nástroje pro řízení architektury SOA, které se zabývají procesy, patří WebSphere Business Modeler, WebSphere Integration Developer, WebSphere Process Server, WebSphere Business Monitor a WebSphere Business Services Fabric. Zvláštní postavení má hra Innov8, která je business hrou od IBM, která se soustředí na modelování procesů. Jelikož se tato seminární práce zaměřuje hlavně na business process management, bude oblast procesních nástrojů rozpracována ještě detailněji v následujících částech práce. Nyní vystačí jako u ostatních nástrojů stručná charakteristika. WebSphere Business Modeler je nástroj pro modelování a iterativní simulaci podnikových procesů. WebSphere Integration Developer je nástroj, který slouží pro vývoj komponent SOA. Víceméně se jedná o programátorské prostředí Eclipse, které je rozšířeno o potřeby pro vývoj aplikací a modelů pro servisně orientovanou architekturu. WebSphere Process Server zajišťuje návaznost služeb v podnikových procesech. V podstatě lze konstatovat, že Process Server ve spolupráci s enterprise service busem je zodpovědný za poskytování služeb a za jejich propojení napříč celé organizaci s business procesy. WebSphere Business Monitor pak zajišťuje měření a monitorování celého podnikání. Business Monitor umí vytvářet a sledovat KPI, generovat dashboardy, produktové dimenze, grafy a další ukazatele. 33 S t r á n k a

Business Monitor je schopen měřit v aktuálním čase a umí vydávat varování, notifikace a reporty. WebSphere Business Services Fabric slouží k vytváření kompozitních aplikací z existujících služeb a industry content pack Business Services Fabric umožňuje firmám nakoupit předem vytvořené služby a tím pádem i best-practices pro jejich specifické odvětví. Hra Innov8 vybočuje z rámce nástrojů pro řízení architektury SOA. Přece je ale vhodné se o ní zmínit, jelikož umožňuje studentům seznámit se s oblastí business process managementu netradičním způsobem. Následující oblasti nástrojů pro řízení architektury SOA budou nástroje zabývající se prací s informacemi a s daty. Do této skupiny patří nástroje IBM Information Server a produkt IBM Information Management System. Information Server slouží k deploymentu služeb a ke správě metadat, zatímco Information Management System (IMS) je produkt, který se zabývá velkou škálou prací. Přes IMS je například možné bezpečně spravovat prostřednictvím SOA databáze. Stejně tak, ale je možné přes servisně orientovanou architekturu využívat schopnosti IMS, které se týkají business intelligence. Oblast orientace na uživatele reprezentuje jeden jediný nástroj. Tímto nástrojem je WebSphere Portal, který je těsně integrován se všemi ostatními nástroji, a který umožní do nich nahlédnout standardizovaným uživatelským rozhraním. Portal navíc zajišťuje interakční integritu, to znamená, že kontroluje, zda se uživatel dívá na aktuální data. Další zvláštností Portalu je možnost jeho integrace do groupware aplikací. Pokud Portal například je integrován s prostředím Lotus Notes, tak business uživatel je schopen prohlížet si data, která jsou dostupná přes SOA ve svém běžném pracovním prostředí, kterým v tomto příkladě je právě Lotus Notes. Nástroje, které se zabývají konektivitou ke službám, jsou WebSphere MQ, WebSphere Datapower, WebSphere ESB a WebSphere Message Broker. WebSphere MQ lze stručně označit jako middleware, který posílá transakce z technologické vrstvy do vrstvy kompozitních business aplikací. K tomu MQ například využívá technologii AJAX a http můstky. WebSphere Datapower je nástrojem, který se vyloženě stará o to, zda hardware, na kterém je servisně orientovaná architekturu provozována, funguje. Hardwarově tedy kontroluje funkčnost všech součástí a úroveň konektivity a navíc hlídá běžící software například před viry. WebSphere ESB pak je samotným technologickým jádrem servisně orientované architektury. Tento enterprise service bus společně s WebSphere Adapters vytváří prostředí, které je charakteristické pro architekturu SOA. ESB nabízí jednotlivá rozhraní, odstiňuje aplikace od technologických detailů implementace a nabízí služby, které lze využívat. ESB tedy je jádrem technologického řešení SOA a umožňuje jednoduchou standardizovanou komunikaci mezi službami prostřednictvím viditelného veřejného rozhraní. WebSphere Message Broker poté předává business události příslušným službám. Za znovupoužitelnost zodpovídají nástroje WebSphere Application Server a WebSphere Studio Asset Analyzer. Application Server umí přidávat externí webové služby a J2EE objekty do architektury SOA. Studio Asset Analyzer pak zodpovídá za správu, rozvoj, znovupoužitelnost a eventuelní transformaci služeb. Posledními nástroji pro řízení architektury SOA pak jsou Tivoli Composite Application Manager for SOA a WebSphere Service Registry and Repository. Produkt z řady Tivoli je schopný detekovat úzká místa ve 34 S t r á n k a

službách a v komunikaci mezi službami a Service Registry and Repository slouží jako seznam služeb a jako úložiště pro samotné služby, které jsou dostupné přes servisně orientovanou architekturu. 6.4 Business process management nástroje od IBM pro řízení architektury SOA V předchozím výkladu byl podán přehled o všech CASE nástrojích, které se týkají řízení servisně orientované architektury, ať už se jedná o procesní nástroj, o nástroj, který umožňuje řídit informace, uživatele, služby, konektivitu, znovupoužitelnost anebo administrativu. Nyní budou blíže popsány nástroje pro řízení podnikových procesů. (IBM nedatováno) Nástroje, které spadají do této kategorie, jsou WebSphere Business Modeler, WebSphere Integration Developer, WebSphere Process Server, WebSphere Business Monitor, WebSphere Business Services Fabric a také bude představena hra Innov8. (Noel 2005) Obrázek 27: Vhodné nástroje pro spolupráce BPM a SOA Každý z nástrojů totiž pokrývá část spolupráce SOA a BPM. Ten se skládá z klasického business process managementu, který se skládá z modelování, simulace a redesignu modelů. Poté následuje implementace, zařazení procesu do enterprise service busu a do architektury SOA a nakonec je potřeba monitorovat výkonnost vytvořeného procesu. Na BPM je určen WebSphere Business Modeler, na implementaci WebSphere Integration Developer, na zařazení WebSphere Process Server a na měření je určen WebSphere Business Monitor. Nástroj WebSphere Business Services Fabric pak je schopen vytvářet z existujících služeb kompozitní aplikace, které budou šity na míru vytvořeným modelům. 6.4.1 WebSphere Business Modeler Nejdříve bude představen WebSphere Business Modeler. (IBM, WebSphere Business Modeler data sheet nedatováno) Mezi zvláštní vlastnosti tohoto nástroje patří: Možnost customizace modelů 35 S t r á n k a

Vytvoření plaveckých bazénů Společné úložiště Modelování business rules Podpora workflow vytvořením formulářů Těsná integrace s WebSphere Integration Developerem Možnost volby notace Deployment modelů Monitorování modelů Optimalizace Spojení s firemními cíli Možnost začlenění modelů jako aktivum do Rational Asset Manageru Import dat ve formátu Excel 2007 Business Modeler lze pořídit ve verzích Basic, Advanced, Publishing Server a Publishing Edition. Business Modeler Basic umožňuje klasické modelování včetně změny barev, popisků a přidávání komentářů pro komunikace se stakeholdery. Verze Basic navíc umožňuje validovat dokumenty, generovat dokumentaci a reporty. Business Modeler Advanced již je mnohem sofistikovanější nástroj. Vedle toho, že obsahuje to, co obsahuje verze Basic má další analytické, simulační, měřící a integrační funkce. Business Modeler Advanced například umí analyzovat úzká místa, zobrazovat co se děje v běhu procesu (zobrazení front a aktivit) a generuje grafické reporty. Simulační funkcionalita zobrazuje v animaci průběh procesu, počítá s dynamickými změnami a umožňuje zadání metrik pro hodnocení vytvořených procesů. Takovými metriky, které lze v Business Modeleru Advanced definovat jsou například KPI, SLA, dimenze nebo jiné procesní indikátory. Další velkou výhodou verze Advanced oproti Modeleru je její propojení s celou řadou dalších nástrojů od společnosti IBM. Business Modeler Advanced tak lze propojit s Business Process Manager, s Business Services Fabric, s FileNet, s MQ Workflow a s Integration Developer. Integrace s Integration Developerem je velmi těsná a probíhá pomocí vygenerovaného BPEL, WSDL anebo XSD schématu. Business Modeler Publishing Server pak umožňuje zveřejnění modelů přes webové rozhraní. Podle přidělených práv pak je možné číst publikovaný obsah anebo přidávat k němu komentáře. Business Modeler Publishing Edition se pak skládá z jedné licence Publishing Server a z deseti licencí Business Modeler Advanced. 36 S t r á n k a