012345

}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Grafický editor pro JBoss ESB D IPLOMOVÁ PRÁCE

Bc. Tomáš Sedmík

Brno, 2013

Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

Bc. Tomáš Sedmík

Vedoucí práce: Mgr. Jiˇrí Koláˇr ii

Podˇekování Rád bych podˇekoval vedoucímu této práce Mgr. Jiˇrímu Koláˇrovi a Ing. Jiˇrímu Pechancovi – odbornému konzultantovi z firmy Red Hat. Pracovat na tomto tématu mˇe velmi obohatilo, at’ již formou novˇe nabytých praktických zkušeností pˇri vytváˇrení kompletnˇe celé aplikace (analýza problémové oblasti, návrh rˇ ešení i implementace) nebo získáním širšího povˇedomí o SOA a EAI. V neposlední rˇ adˇe muj ˚ dík patˇrí mé rodinˇe, která mˇe pˇri psaní velmi podporovala.

iii

Shrnutí Cílem této práce bylo implementovat zásuvný modul (tzv. plugin) do vývojového prostˇredí Eclipse, který by umožnil grafické nastavení produktu JBoss ESB (Red Hat, Inc.) – software pro Enterprise Application Integration. Souˇcástí implementace je vytváˇrení, naˇcítání a ukládání konfiguraˇcního souboru a grafická manipulace s nastavením. Jsou diskutovány použité technologie a postupy.

iv

Klíˇcová slova plugin, zásuvný modul, grafický editor, XML editor, Red Hat, JBoss, ESB, EAI, Eclipse, GEF

v

Obsah 1

2

3

4 5

6

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíle . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Enterprise Application Integration . . . . . . . . . . 2.2 Service Oriented Architecture . . . . . . . . . . . . . 2.3 Enterprise Service Bus . . . . . . . . . . . . . . . . . JBoss ESB . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Význam JBoss . . . . . . . . . . . . . . . . . . . . . . 3.2 Význam JBoss ESB . . . . . . . . . . . . . . . . . . . 3.2.1 Hlavní rysy JBoss ESB . . . . . . . . . . . . . 3.2.2 Výhody JBoss ESB . . . . . . . . . . . . . . . 3.3 Komponenty JBoss ESB . . . . . . . . . . . . . . . . . 3.3.1 Služba (Service) . . . . . . . . . . . . . . . . . Posluchaˇc (Listener) . . . . . . . . . . . . . . Poskytovatel (Provider) . . . . . . . . . . . . 3.3.2 Zpráva (Message) . . . . . . . . . . . . . . . . 3.4 Nastavení JBoss ESB . . . . . . . . . . . . . . . . . . Stávající nástroj pro nastavení JBoss ESB . . . . . . . . . 4.1 Hodnocení editoru . . . . . . . . . . . . . . . . . . . Vývoj nového nástroje pro nastavení JBoss ESB . . . . . 5.1 Analýza problémové oblasti . . . . . . . . . . . . . . 5.2 Návrh rˇ ešení . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Architektura editoru . . . . . . . . . . . . . . 5.2.2 Model . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Uložení konfiguraˇcních možností JBoss ESB 5.2.4 Controller . . . . . . . . . . . . . . . . . . . . 5.2.5 View . . . . . . . . . . . . . . . . . . . . . . . 5.2.6 Inicializace editoru . . . . . . . . . . . . . . . 5.3 Použité technologie . . . . . . . . . . . . . . . . . . . 5.3.1 GEF (Graphical Editing Framework) . . . . . 5.4 Implementace . . . . . . . . . . . . . . . . . . . . . . 5.5 Popis vlastností nového editoru . . . . . . . . . . . . 5.6 Instalace editoru . . . . . . . . . . . . . . . . . . . . . Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 3 4 5 6 7 7 7 8 9 10 10 12 13 14 15 18 19 21 21 22 22 23 25 28 29 32 33 34 36 38 41 42 vi

A Obsah pˇriloženého CD . . . . . . . . . . . . . . . . . . . . . 46 B Ukázka jbossesb-properties.xml . . . . . . . . . . . . . . . . . . 47 C Ukázka jboss-esb.xml . . . . . . . . . . . . . . . . . . . . . . . 48

vii

1 Úvod Spoleˇcnost Red Hat, Inc., v rámci vývojové skupiny JBoss, pˇrináší rˇ ešení pro aplikaˇcní integraci v podobˇe produktu JBoss ESB. Jako každá aplikace má i tato uživatelské nastavení. V tomto pˇrípadˇe se jedná o konfiguraci prostˇredí JBoss ESB (pˇripojení na databáze, nastavení globálních promˇenných, . . . ) a uživatelsky zajímavˇejší konfiguraci služeb a poskytovatelu˚ (což jsou komponenty, které slouží právˇe pro aplikaˇcní integraci). Právˇe konfiguraˇcní soubor s nastavením poskytovatelu˚ a služeb bude pˇredmˇetem této práce, respektive se budeme snažit uživatelsky zpˇríjemnit práci s tímto souborem.

1.1

Motivace

Hlavní duvod, ˚ proˇc je potˇreba vyvíjet nástroje pro lepší úpravu nastavení komplexních aplikací (v našem pˇrípadˇe konfiguraˇcního souboru JBoss ESB), je ten, že ne všichni uživatelé mají detailní znalosti dané aplikace a možností její konfigurace. Takový nástroj muže ˚ velmi ulehˇcit práci napˇr. tím, že intuitivnˇe zobrazí nastavení v cˇ lovˇeku snadno cˇ itelné podobˇe. Uživatel si tak dokáže pˇredstavit co jakým zásahem ovlivní a jakou cˇ ást aktuálnˇe edituje. Jinou výhodou nástroju˚ je omezení možností zásahu uživatele do nastavení na jen takové, které zachovají konzistenci a správnost (napˇr. neumožní nastavit nesmyslné hodnoty parametru). ˚ Z tˇechto duvod ˚ u˚ vznikla i tato práce, která by mˇela všem uživatelum ˚ JBoss ESB poskytnout nástroj, respektive grafický editor, umožnující ˇ snadnou a intuitivní práci s nastavením této aplikace.

1

1. Ú VOD

1.2

Cíle

Tato práce si bere za cíl: •

popsat problematiku okolo produktu JBoss ESB,

•

popsat souˇcasné možnosti uživatelu, ˚ jak pracovat s nastavením JBoss ESB,

•

analyzovat požadavky na nový nástroj pro snadnou a intuitivní práci s nastavením JBoss ESB,

•

navrhnout a implementovat nástroj (respektive grafický editor), v podobˇe zásuvného modulu do vývojového prostˇredí Eclipse, který bude ulehˇcovat práci s konfigurací JBoss ESB.

2

2 Kontext S pˇríchodem informaˇcních technologií do podnikové sféry se zaˇcalo s vývojem aplikací (systému), ˚ datových formátu˚ a komunikaˇcních protokolu, ˚ které mˇely za úkol usnadnit práci (automatizovat doposud ruˇcní práci). Pomocí poˇcítaˇcu˚ bylo najednou možné dˇelat nevídané vˇeci – poˇcítat mzdy, plánovat rozpisy smˇen, evidovat stav zboží na skladˇe, . . . V rané fázi zaˇcaly vznikat aplikace živelnˇe, na základˇe aktuálních potˇreb podniku. Vytvoˇrilo se tedy velké množství izolovaných systému, ˚ které dˇelaly definovanou cˇ innost – napˇr. personalistika (evidence zamˇestnancu, ˚ výpoˇcet mezd, dovolené, odmˇeny, pracovní neschopnosti) nebo mužeme ˚ uvažovat státní sektor a napˇr. systém pracující s evidencí obˇcanu, ˚ katastr nemovitostí, v bankovní sféˇre systém pro evidenci hypoték a jejich splátek, evidence investic, . . . . Masové použití výpoˇcetní techniky v jednotlivých oblastech podnikání umožnilo zefektivnit a urychlit pracovní procesy, což s sebou pˇrineslo velkou úsporu finanˇcních prostˇredku˚ a zvýšení zisku. ˚ V 70. letech 21. století zaˇcala vznikat potˇreba integrace takových podnikových aplikací. Do této doby byl svˇet podnikových aplikací izolovaný. Každá firma, dokonce i její cˇ ásti mˇely vlastní aplikace, které provádˇely urˇcitou cˇ innost. V zájmu opˇetovného zvýšení efektivity zaˇcaly vznikat vazby (spoje) mezi jednotlivými aplikacemi – aplikace spolu zaˇcaly spolupracovat (vymˇenovat ˇ si data, sdílet funkcionalitu). Propojování jednotlivých aplikací nutilo vývojáˇre implementovat rozhraní pro danou aplikaci a aplikaci, s kterou mˇela spolupracovat. Pˇritom aplikace byly psány ruznými ˚ vývojovými týmy, v ruzných ˚ programovacích jazycích a v ruzné ˚ dobˇe. Pokud mˇela aplikace komunikovat s více dalšími, tak poˇcet rozhraní narustal, ˚ až se vytvoˇril tzv. špagetový systém1 (viz Obr. 2.1). Takový systém je velmi tˇežké, ne-li nemožné spravovat jako celek. Aby se do celé problematiky vnesl nˇejaký rˇ ád a bylo možné takové systémy administrovat, tak vzniká odvˇetví Enterprise Application Integration [2].

1. špagetový systém – heterogenní komplexní systém o mnoha podˇcástech, které jsou vzájemnˇe chaoticky propojeny

3

2. K ONTEXT

Obrázek 2.1: Ukázka špagetového systému (pˇrevzato z [4])

2.1

Enterprise Application Integration

Termín EAI se poprvé objevuje v USA kolem roku 1996 v publikacích velkých firem zabývajících se analýzou softwaru (autoˇri: Roy Schulte z Gartner Group [6] a Mike Gilpin z Giga Group [7]). V dnešní dobˇe je však vymezení pojmu Enterprise Application Integration (EAI) velmi obtížné. Existuje spoustu definic zachycující EAI v ruzných ˚ pohledech (s ohledem na roli pozorovatele). Jednou z definic, která vystihuje pohled této práce, muže ˚ být: EAI je soubor metod, nástroju˚ a služeb, které spolu spolupracují, aby umožnili komunikaci heterogenních aplikací, jako cˇ ást tradiˇcního, distribuovaného nebo rozšíˇreného podnikání [3]. Pojmem heterogenní aplikace rozumíme aplikace, které jsou vytvoˇreny s použitím ruzných ˚ technologií. Tudíž do domény EAI nepatˇrí aplikace s tzv. vnitˇrní komunikací (klient/server). Dále tzv. homogenní systémy – aplikace, které využívají identické technologie s nˇejakou definovanou sémantikou a syntaxí pro komunikaci. Takové systémy považujeme již za integrované. Pˇríkladem mohou být systémy založené na architektuˇre CORBA2 .

2.

http://www.omg.org/gettingstarted/corbafaq.htm

4

2. K ONTEXT

Obrázek 2.2: Komunikace heterogenních aplikací pomocí EAI (Pˇrevzato z [5])

2.2

Service Oriented Architecture

Svˇet EAI je úzce spojen s SOA (Service Oriented Architecture) pˇrístupem. SOA, jak je již z názvu patrné, je architektura, která se orientuje na služby. Službou v tomto kontextu myslíme pˇresnˇe definovanou cˇ innost (napˇr. tisk objednávky, platba skrze platební bránu, . . . ). Jednotlivé služby jsou stavebními kameny, které postupným spojováním vystaví celou komplexní aplikaci. Tím, že se aplikace sestává z mnoha komponent (každá komponenta realizuje definovanou cˇ innost), je pak snadné takový systém spravovat jako celek – napˇr. nám nemusí vyhovovat zpusob ˚ jakým se tisknou objednávky, tudíž vymˇeníme službu, která realizuje tisk objednávek (nemusíme zasahovat nikam jinam) a vše opˇet funguje dle našich pˇredstav. Aplikace postavené na SOA pˇrístupu jsou robustní (v pˇrípadˇe selhání je velmi jednoduché zjistit, která komponenta je jeho pˇríˇcinou a vymˇenit ji za jinou, funkˇcní) a stabilní (zátˇež systému se dá snadno rozložit na jednotlivé komponenty. V pˇrípadˇe velkého zatížení nˇejaké komponenty lze tuto komponentu do systému vložit vícekrát, abychom zátˇež snížili). SOA pˇrístup pˇri vytváˇrení nových aplikací je v dnešní dobˇe na vzestupu. Jedná se o elegantní rˇ ešení, které nabízí robustnost, stabi5

2. K ONTEXT litu a snadnou údržbu vytváˇrených rˇ ešení. O návrhu aplikací pomocí SOA je napsáno mnoho knih a cˇ lánku˚ ([8, 9, 10]). Všechny SOA aplikace by však mˇely vycházet z tzv. Principu˚ SOA3 . Návrh aplikací pro EAI také vychází z architektury SOA.

2.3

Enterprise Service Bus

Enterprise Service Bus (ESB) je architektura používaná pro vzájemnou interakci mezi aplikacemi, komponentami, respektive službami, které známe ze SOA pˇrístupu. Celý koncept ESB je postaven na principu sbˇernice (bus) – subsystém zajišt’ující pˇrenos informací mezi komponentami pˇripojenými ke sbˇernici. Komunikace po sbˇernici je zajištˇena pomocí zpráv, které si jednotlivé služby vymˇenují. ˇ ESB je integraˇcní platforma ve smyslu EAI – jednotlivé služby, které jsou k ESB pˇripojeny, mohou být heterogenní (psané v ruzných ˚ jazycích, komunikující ruznými ˚ protokoly, . . . ) [11]. Existuje mnoho komerˇcních i Open Source produktu, ˚ které poskytují ESB. V této práci se budeme podrobnˇe zabývat produktem JBoss ESB, který je vyvíjen pod záštitou firmy Red Hat, Inc..

3.

SOA principles poster.pdf

6

3 JBoss ESB 3.1

Význam JBoss

Historie JBoss se zaˇcala psát v roce 1999, kdy Marc Fleury spustil open source1 projekt EJBoss (Enterprise Java Beans open source software). Cílem tohoto projektu bylo poskytnout volnˇe dostupnou implementaci specifikace EJB (Enterprise Java Beans). Projekt se stal velmi rychle populární, pˇredevším díky nízkým nákladum ˚ za poˇrízení a jednoduchosti použití. Autorská práva firmy Sun Microsystems, Inc. na obchodní znaˇcku EJB, vynutily pˇrejmenování projektu v roce 2001 na JBoss. V témže roce vzniká JBoss Group – skupina zaštit’ující více open source projektu. ˚ V roce 2006 se JBoss 2 stává souˇcástí firmy Red Hat, Inc. . JBoss je v souˇcasnosti nazýván jako JBoss by Red Hat3 . Pod jeho záštitou najdeme mnoho významných open source projektu˚ – aplikaˇcní server, JBoss ESB, a jiné4 . Velký význam v kontextu JBoss má komunita, která podporuje vývoj, testování a dokumentaci projektu. ˚ V souˇcasnosti má JBoss komunita pˇres 80.000 registrovaných cˇ lenu˚ po celé planetˇe. Nˇekteˇrí cˇ lenové vyvíjí aktuální kód, jiní píší dokumentaci, poskytují zpˇetnou vazbu co se týˇce návrhu aplikací nebo reportují chyby, pˇrípadnˇe prezentují JBoss projekty na osobních cˇ i firemních webových stránkách. Poˇcet rˇ ádných zamˇestnancu˚ je v porovnání s komunitou rˇ ádovˇe nižší [12].

3.2

Význam JBoss ESB

JBoss ESB je open source projekt skupiny JBoss, jehož hlavním cílem je poskytnout prostˇredky pro vzájemnou komunikaci a sdílení funkcionality ruznorodých ˚ systému˚ (viz 2.1). JBoss ESB abstrahuje rozdíly mezi takovými systémy tím, že je považuje za logické služby, které komunikují pomocí zpráv. Vše je bud’ služba a nebo zpráva. 1. open source – software, který je nabízen zdarma, vˇcetnˇe zdrojového kódu, z kterého je sestaven 2. http://www.redhat.com 3. http://www.jboss.org 4. http://www.jboss.org/projects

7

3. JB OSS ESB Díky JBoss ESB je možné jednotlivé systémy propojit bez nutnosti psaní specifického rozhraní pro komunikaci. JBoss ESB navíc nijak nepˇredepisuje integraˇcní vzory a pˇrenechává toto rozhodnutí na uživatele. Díky tomu je zajištˇeno, že se JBoss ESB sám v budoucnu nestane systémem, který je potˇreba s nˇecˇ ím integrovat [12]. 3.2.1 Hlavní rysy JBoss ESB JBoss ESB se skládá z velkého množství komponent, které jsou využity pro snadnou aplikaˇcní integraci (viz Obr. 3.1). Mezi duležité ˚ cˇ ásti JBoss ESB patˇrí [12]: •

registrace a hostování služeb – služby implementují business logiku aplikací. Ty jsou pak hostovány JBoss ESB a pomocí registru˚ se jednotlivé služby vyhledávají, aby byly dostupné. Registry JBoss ESB využívají standard UDDI5 (Universal Description, Discovery and Integration) respektive jeho implementaci jUDDI6 . Bez použití registru˚ by klientská aplikace nebyla schopna lokalizovat cílovou službu.

•

pˇreklad protokolu˚ – umožnuje ˇ komunikaci aplikací, které používají ruzné ˚ komunikaˇcní protokoly (HTTP, souborový systém, JMS, . . . ). Vše je zajištˇeno díky pˇrekladu jednotlivých formátu˚ do univerzálního pomocí adaptéru. ˚

•

orchestrace procesu˚ – tímto je myšlena kontrola více procesu˚ jedním centrálním procesem. JBoss ESB podporuje orchestraci služeb pomocí JBoss jBPM a JBoss RiftSaw, které používají jPDL7 .

•

management – je umožnˇeno nasazení služeb na bˇežící systém tzv. hot deploy. Dále verzování zmˇen služeb (jedna služba muže ˚ být dostupná ve více verzích). V neposlední rˇ adˇe jsou dostupné nástroje pro monitorování pˇres administrativní konzolu.

5. 6. 7.

http://uddi.xml.org/ http://juddi.apache.org/ http://docs.jboss.com/jbpm/v3/userguide/

8

3. JB OSS ESB

Obrázek 3.1: Pˇrehled služeb JBoss ESB (pˇrevzato z [12]) •

kvalita služby – podpora transakcí, kterými je zajištˇena spolehlivost služeb.

•

out-of-the-box akce – obsahuje velké množství pˇredpˇripravených akcí, které usnadnují ˇ práci s širokou škálou úloh: –

Business Process Management – integrace s JBoss jBPM

–

transformace – konverze formátu˚ zpráv z jednoho druhu do jiného

–

skriptování – podpora skriptovacích jazyku˚

–

notifikace – upozornˇení na na pˇríchozí data

–

webové služby – podpora webových služeb jako služeb JBoss ESB

9

3. JB OSS ESB 3.2.2 Výhody JBoss ESB Výhody použití JBoss ESB tkví v následujícím [12]: •

nízké poˇrizovací náklady – je zdarma.

•

otevˇrenost – jsou dostupné zdrojové kódy aplikace, tudíž lze vidˇet dovnitˇr systému a sledovat jeho chování, pˇrípadnˇe si nˇejakou cˇ ást upravit dle aktuálních potˇreb. Navíc je dostupná dokumentace chyb a dokonce i e-maily a IRC chaty mezi cˇ leny vývojového týmu.

•

komunita uživatelu˚ – tisíce uživatelu˚ a organizací používá JBoss ESB.

•

standardizace – JBoss ESB je založen na standardizovaných technologiích jako JMS, UDDI, XML, . . .

3.3

Komponenty JBoss ESB

Každá komponenta v JBoss ESB je, kvuli ˚ zachování SOA principu, ˚ bud’to služba nebo zpráva. Služby zapouzdˇrují business logiku nebo integraˇcní body s aplikacemi. Zprávy jsou zpusob ˚ jak služby navzájem komunikují. V nastavení JBoss ESB se ještˇe vyskytuje tzv. poskytovatel, pomocí kterého se definují transportní detaily pro koncové body služeb (rozhraní, pˇres které bude služba dostupná klientum) ˚ [1, 12]. 3.3.1 Služba (Service) Služba je implementace ucelené cˇ ásti business logiky, která je vystavena v dobˇre definovaném kontraktu služby potenciálním klientum. ˚ Každá služba má následující vlastnosti: •

samostatnost – implementace služby není závislá na jejích klientech.

•

volné svázání – klient volá službu nepˇrímo pomocí zaslání zprávy pˇres ESB. 10

3. JB OSS ESB <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/ product/etc/schemas/xml/jbossesb-1.0.1.xsd" invmScope="GLOBAL"> <services> <service category="Retail" name="ShoeStore" description="Acme Shoe Store Service">

Obrázek 3.2: Ukázka nastavení služby v JBoss ESB (pˇrevzato z [1]) •

znovupoužitelnost – službu muže ˚ volat více klientu, ˚ kteˇrí požadují funkcionalitu dané služby.

Každá služba sestává z nˇekolika cˇ ástí. Mezi nejduležitˇ ˚ ejší patˇrí akce (actions) a posluchaˇce (listeners). Pomocí akcí je definováno chování dané služby (jednotlivé akce se provádí sekvenˇcnˇe a mohou si pˇredávat výsledky). Posluchaˇci zase urˇcují na jaké zprávy z jakých kanálu˚ bude služba reagovat, respektive pˇres která rozhraní bude služba dostupná. Jak je vidˇet na Obr. 3.2, tak každá služba má dva povinné atributy jméno (name) a kategorii (category). Pˇri nasazení služby se pomocí tˇechto atributu˚ služba registruje a je skrze nˇe dostupná – ten kdo chce službu používat musí tyto dva údaje znát. Klient muže ˚ službu zavolat pomocí tˇrídy ServiceInvoker jak je naznaˇceno na Obr. 3.3. ServiceInvoker se pˇri hledání služby obrátí na registr služeb JBoss ESB, aby mu zpˇrístupnil službu skrze nˇekterý z dostupných kanálu. ˚ Klient je zcela odstínˇen od transportních detailu˚ (doruˇcení zprávy od klienta k službˇe). V ukázce na Obr. 3.2 se muže ˚ na první pohled zdát, že služba nemá definované žádné posluchaˇce (listeners), pˇres které by byla dostupná klientum. ˚ Všimnˇeme si ale atributu invmScope u elementu <jbossesb>, kterým je umožnˇeno spouštˇet služby bˇežící na stejné instanci JVM. V pˇrípadˇe, že chceme pˇridat další koncové body k nˇejaké 11

3. JB OSS ESB ServiceInvoker invoker = new ServiceInvoker(Retail, ShoeStore); Message message = MessageFactory.getInstance().getMessage(); message.getBody().add(Hi there!); invoker.deliverAsync(message);

Obrázek 3.3: Ukázka volání služby (pˇrevzato z [1]) službˇe, tak musíme pˇridat posluchaˇce a poskytovatele. Posluchaˇc (Listener) Posluchaˇc zapouzdˇruje koncové body pro pˇríjem zpráv. JBoss ESB podporuje dva typy posluchaˇcu: ˚ •

Gateway Listeners (viz Obr. 3.4) –

–

–

jedná se o tzv. bránu (gateway), která umožnuje ˇ komunikaci s externím klientem (mimo ESB) pomocí standardních technologií (napˇr. JMS, SQL databáze, volání webových služeb pˇres HTTP, použití souborového systému, . . . ). Brána v tomto ohledu slouží jako proxy mezi dvˇema úˇcastníky – požadavek z externího klienta transformuje na zprávu, která je poslána pˇres ESB k cílové službˇe. nˇekteré brány jsou založeny na synchronních protokolech (napˇr. HTTP), které potˇrebují zpracování stylem požadavek/odpovˇed’ v rámci stejného spojení. Jiné podporují asynchronní zpracování (napˇr. JMS, souborový systém), které vyžadují pouze reakci na pˇríchozí požadavek (napˇr. uložení souboru do souborového systému). pro vytváˇrení odpovˇedí u asynchronních posluchaˇcu˚ nabízí JBoss ESB tzv. notifiers (notifikátory) a routers (smˇerovaˇce). Ty nám umožnují ˇ zasílat zprávy od ESB-Aware8 služby k externímu klientovi. Nemusíme je využívat jen pro vytváˇrení odpovˇedí, ale mohou sloužit i k zasílání asynchronních upozornˇení jakékoliv externí službˇe, která je dokáže pˇrijmout.

8. ESB-Aware – znamená být schopný zpracovávat zprávy ve formátu používaném v ESB oproti jiným formátum ˚ zpráv používaných napˇr. v HTTP, JMS, . . .

12

3. JB OSS ESB

Obrázek 3.4: Ukázka synchronního/asynchronního volání služeb na ESB (pˇrevzato z [12]) •

ESB-Aware Listeners – používá se pro výmˇenu ESB zpráv, respektive komunikaci mezi ESB-Aware komponentami v rámci JBoss ESB.

Každý posluchaˇc obsahuje referenci, v podobˇe nastaveného atributu busid, na nˇejakého poskytovatele. Díky této referenci, JBoss ESB pozná, který poskytovatel bude poskytovat zdroje jaké službˇe. Poskytovatel (Provider) Poskytovatele reprezentují servery nebo balíky, které existují mimo JBoss ESB a poskytují zdroje jeho komponentám. Použití, respektive nastavení tˇechto poskytovatelu˚ se provádí v konfiguraˇcním souboru (více viz kapitola 3.4) a v kontextu JBoss ESB definují transportní nastavení pro jednotlivé koncové body. Poskytovatelé tudíž zpˇrístup13

3. JB OSS ESB

Obrázek 3.5: Provázání služby a poskytovatele (pˇrevzato z [12]) nují ˇ JBoss ESB, respektive jeho služby pestré paletˇe externích klientu˚ (pˇres HTTP, JMS, FTP, SQL, souborový systém, . . . ). Každý posluchaˇc (respektive služba) musí být napojen na nˇejakého poskytovatele, aby byl dostupný externím klientum ˚ (výjimku tvoˇrí použití tzv. invmScope, jak je naznaˇceno v kapitole 3.3.1). Toto napojení je realizováno pomocí atributu busid, jak je schématicky znázornˇeno na Obr. 3.5. 3.3.2 Zpráva (Message) Zprávy hrají klíˇcovou roli v JBoss ESB – veškerá komunikace mezi jednotlivými komponentami probíhá právˇe formou zasílání zpráv. Zasílání zpráv v sobˇe skrývá volnost a jednoduchost použití. Zprávy jsou na sobˇe nezávislé, není tudíž potˇreba vytváˇret a udržovat souvislé spojení mezi odesílatelem a pˇríjemcem. Tímto zpusobem ˚ se šetˇrí zdroje a zárovenˇ to dává aplikacím vˇetší stabilitu a flexibilitu. Zprávy v kontextu JBoss ESB obsahují veškeré informace relevantní pro volání služeb. Pro všechny zprávy je definován jednotný formát (viz Obr. 3.6), který má následující strukturu: •

hlaviˇcka (header) – obsahuje údaje o zamýšleném pˇríjemci 14

3. JB OSS ESB zprávy, odesilateli, kam odeslat odpovˇed’, koho informovat v pˇrípadˇe chyby a další duležité ˚ smˇerovací informace. •

tˇelo (body) – obsahuje pˇrenášený obsah (data), který muže ˚ být 9 ruzného ˚ typu – textový rˇ etˇezec, serializovaný objekt, mapa (dvojice ), proud bytu. ˚

•

pˇrílohy (attachment) – do pˇríloh se umíst’ují dodateˇcné informace, které mají nˇejakou vazbu na data v tˇele zprávy. Pˇrílohy se využívají pro zlepšení logické struktury dat a pˇredevším pro zvýšení výkonu pˇri zpracování objemných zpráv (služba, která zprávu obdrží, nejprve zpracuje data v tˇele zprávy a pak si teprve muže ˚ vyžádat nˇekterou z pˇríloh, tudíž není nutné nacˇ ítat celou zprávu do pamˇeti). Pˇrílohy mužeme ˚ napˇr. použít pro obrázky, binární dokumenty, zip archivy, atp..

•

vlastnosti (properties) – obvykle specifikují zpusob ˚ doruˇcení zprávy. Vˇetšinou jsou závislé na použitém transportním protokolu (napˇr. v pˇrípadˇe JMS mohou obsahovat název fronty, na kterou se má zpráva zaˇradit).

3.4

Nastavení JBoss ESB

Nastavení produktu JBoss ESB se provádí pomocí konfiguraˇcních XML souboru. ˚ Tyto soubory se zpravidla nachází v koˇrenovém adresáˇri projektu a mají standardnˇe tyto názvy: •

jbossesb-properties.xml – obsahuje globální nastavení JBoss ESB serveru [13] – nastavení globálních promˇenných, pˇripojení na databázi, konfigurace prostˇredí, . . . (viz pˇríloha B).

•

jboss-esb.xml – obsahuje nastavení služeb, akcí, poskytovatelu, ˚ filtru˚ a zabezpeˇcení. Tato práce se vˇenuje nastavení právˇe tohoto souboru. Ukázka takového souboru je uvedena v pˇríloze C.

9. serializace – proces pˇrevedení libovolnˇe složité datové struktury do její sekvenˇcní podoby (napˇr. pro pˇrenos skrze poˇcítaˇcovou sít’)

15

3. JB OSS ESB

Obrázek 3.6: Základní struktura JBoss ESB zprávy (pˇrevzato z [1]) Soubor jboss-esb.xml má standardní formát definovaný pomocí XML schématu10 , který mužeme ˚ rozdˇelit do tˇechto logických celku: ˚ •

globální nastavení – je uložené v elementu a umožnuje ˇ nastavit zabezpeˇcení.

•

poskytovatele – se specifikují v sekci <providers>. Každý typ je charakterizován speciálním elementem (napˇr. poskytovateli JMS odpovídá element <jms-provider>). Obecnˇe je konvence pojmenovávat elementy poskytovatelu˚ následovnˇe <„typ poskytovatele“-provider>. Každá definice obsahuje: – –

jméno – jedineˇcné v rámci jednoho typu poskytovatele. atributy – které záleží na typu poskytovatele (jiné nastavení je nutné pro napˇr. JMS a jiné pro FTP).

10. XML schéma – XML soubor s pˇríponou .xsd, který popisuje strukturu XML dokumentu˚ (definuje, kde se v dokumentu mohou nacházet jaké elementy s jakými atributy, jaké jsou pˇrípustné hodnoty atributu, ˚ . . . ). Více viz http://www.w3.org/XML/Schema.

16

3. JB OSS ESB

•

–

sbˇernice – jeden poskytovatel muže ˚ mít jednu nebo více sbˇernic, pˇres které mohou služby komunikovat. Každá sbˇernice má jedineˇcný atribut busid, který slouží jako odkaz mezi poskytovatelem a napojenou službou.

–

filtr – každá sbˇernice muže ˚ mít nastaveno filtrování, pomocí kterého se filtrují, nebo smˇerují, pˇríchozí zprávy.

–

vlastnosti – obsahují dodateˇcné nastavení, které není zakotveno pˇrímo do XML schématu konfiguraˇcního souboru. Definujeme je pomocí elementu <property>, který má dva atributy – name a value. Tˇechto elementu˚ mu˚ žeme vytvoˇrit libovolné mnoho.

služby – se nastavují v sekci <services> a každá služba <service> obsahuje následující prvky: –

atributy (name a category) – které slouží pro jednoznaˇcnou identifikaci a registraci služby u JBoss ESB registru služeb.

–

posluchaˇce – jeden nebo více posluchaˇcu, ˚ kteˇrí slouží pro propojení s poskytovatelem.

–

akce – sekvenˇcní výˇcet volání metod, které se mají po zavolání služby provést.

–

bezpeˇcnost – slouží pro restrikci volání dané služby. Mu˚ žeme urˇcit jaké bezpeˇcnostní role smˇejí službu spouštˇet, pˇrípadnˇe pod jakou identitou se má služba spouštˇet.

–

vlastnosti – viz vlastnosti u poskytovatele.

17

4 Stávající nástroj pro nastavení JBoss ESB Uživatelé JBoss ESB v souˇcasnosti mohou pro snazší konfiguraci prostˇredí (úpravu konfiguraˇcního souboru jboss-esb.xml) použít editor JBoss ESB 1.3 Editor. Tento editor je vytvoˇren jako zásuvný modul (tzv. plugin) do vývojového prostˇredí Eclipse. Jeho pˇrínos tkví ve snazší práci s XML souborem, kterou usnadnuje ˇ lepší reprezentací dat v souboru uložených. Mezi hlavní rysy editoru patˇrí jeho rozdˇelení na dvˇe záložky Tree a Source, mezi kterými lze libovolnˇe pˇrecházet a získávat tím ruzný ˚ pohled na konfiguraci JBoss ESB. Záložka Source zobrazuje konfiguraˇcní soubor v textové podobˇe se zvýraznˇenou XML syntaxí. Jedná se o klasický XML editor, který je zabudován do vývojového prostˇredí Eclipse obohacený o následující funkcionalitu: •

okamžitá synchronizace se záložkou Tree – jakákoliv zmˇena se ihned projeví na druhé záložce.

•

v pˇrípadˇe stisku klávesové kombinace Ctrl+Space se vyvolá kontextový asistent, který uživatele informuje jaké elementy, atributy muže ˚ na daném místˇe souboru vytvoˇrit.

•

pokud konfiguraˇcní soubor obsahuje odkaz na nˇejaký externí soubor (jiný XML soubor, Java tˇrídu, . . . ), umožnuje ˇ pˇrímé otevˇrení odkazu.

•

pˇri editaci je poskytována zpˇetná vazba od validace souboru oproti XML schématu – uživatel se tak dozví, kde je nˇejaký problém.

Záložka Tree zobrazuje konfiguraˇcní soubor ve stromové struktuˇre, ve které se lépe orientuje (viz Obr. 4.1). Toto zobrazení velmi znesnadnuje ˇ zanesení chyby – vstupní hodnoty jsou validovány a uživateli dovolí zadat pouze platné hodnoty (napˇr. do pole, kde se oˇcekává cˇ íslo nelze zadat textový rˇ etˇezec). Tato záložka je rozdˇelena na dva grafické prvky: 18

4. S TÁVAJÍCÍ NÁSTROJ PRO NASTAVENÍ JB OSS ESB 1.

navigaˇcní okno – zobrazuje konfiguraˇcní soubor jako strom, jehož vˇetve lze rozbalovat a sbalovat. Pˇri vybrání nˇejakého prvku se v obsahovém oknˇe zobrazí detail nastavení. Kliknutím pravým tlaˇcítkem myši lze vytváˇret nové prvky (poskytovatele, služby, . . . ) nebo rušit stávající.

2.

obsahové okno – zobrazuje veškeré nastavení, které je dostupné pro daný prvek.

4.1

Hodnocení editoru

Editor je velmi propracovaný a tudíž se z nˇej stává silný nástroj pro úpravu nastavení JBoss ESB. Mezi jeho pˇrednosti patˇrí pˇredevším: •

snadná navigace v konfiguraˇcním souboru – díky zobrazení stromové hierarchie v záložce Tree.

•

rychlost a pˇresnost nastavení – editor umožnuje ˇ nastavit jen takovou množinu atributu, ˚ kterou lze dle XML schématu. Navíc disponuje validací vstupu.

•

klasický pˇrístup – lze zobrazit konfiguraˇcní soubor v jeho textové podobˇe se zvýraznˇením XML syntaxe.

Jeho jedinou slabou stránkou je názornost zobrazeného nastavení. Záložka Tree sice XML soubor zobrazuje v uživatelsky pˇrívˇetivˇejší podobˇe, ale stále se jen jedná o reprezentaci hierarchie (zanoˇrení) jednotlivých elementu˚ v konfiguraˇcním souboru. Jednotlivé komponenty JBoss ESB mají mezi sebou urˇcité vazby, které tento editor nereflektuje a tak napˇr. není na první pohled jasné, které služby jsou navázány na jaké poskytovatele, respektive sbˇernice. Manipulace s konfigurací by tedy mohla být více profilovaná na produkt JBoss ESB a více odrážet jeho specifické vlastnosti.

19

4. S TÁVAJÍCÍ NÁSTROJ PRO NASTAVENÍ JB OSS ESB

Obrázek 4.1: Ukázka JBoss ESB 1.3 Editor

20

5 Vývoj nového nástroje pro nastavení JBoss ESB Kvuli ˚ nedostatkum ˚ souˇcasného nástroje pro úpravu nastavení JBoss ESB (popsaných v pˇredešlé kapitole), vznikla potˇreba nového editoru, který by byl ještˇe více uživatelsky pˇrívˇetivˇejší a pˇritom zachovával veškeré možnosti nastavení tohoto produktu. Velký duraz ˚ je také kladen na snadnou upravitelnost, respektive rozšiˇritelnost editoru tak, aby jeho možnosti odpovídaly nejnovˇejším vlastnostem JBoss ESB. Cílem této práce bylo analyzovat problémovou oblast (rozbor požadavku˚ na nový editor), navrhnout a zárovenˇ implementovat rˇ ešení. Tato cˇ ást práce se podrobnˇe vˇenuje všem cˇ innostem, které vedly k danému výsledku (hotovému editoru). Zárovenˇ seznamuje s technologiemi, které byly pˇri rˇ ešení použity – popisuje jejich základní vlastnosti a urˇcení.

5.1

Analýza problémové oblasti

Základní a nejduležitˇ ˚ ejší požadavek na nový editor konfiguraˇcního souboru JBoss ESB je jeho jednoduchost a názornost. Bude se jednat o grafický editor, který bude jednotlivé komponenty JBoss ESB vizualizovat v podobˇe grafických objektu. ˚ Bude zachován souˇcasný koncept editoru, jako zásuvného modulu do vývojového prostˇredí Eclipse. Mezi další základní vlastnosti nového editoru bude patˇrit: •

automatické spouštˇení editoru nad XML soubory, které obsahují nastavení JBoss ESB. Rozpoznání tˇechto souboru˚ bude probíhat na základˇe identifikace jmenného prostoru.

•

možnost modifikace editoru ve smyslu snadného pˇridání a úpravy možností nastavení JBoss ESB (napˇr. nová verze JBoss ESB bude podporovat nové poskytovatele, které je žádoucí pomocí editoru umˇet vytváˇret a nastavovat). Tato modifikace editoru by mˇela být umožnˇena bez nutnosti jakkoliv zasáhnout do zdrojového kódu aplikace. 21

5. V ÝVOJ NOVÉHO NÁSTROJE PRO NASTAVENÍ JB OSS ESB •

5.2

kontrola validity vstupu, ˚ kterou musí editor provádˇet, aby výsledný konfiguraˇcní soubor byl použitelný. Editor musí minimalizovat riziko vzniku chyby zanesené uživatelem – tzn. musí uživateli nabízet pouze takové nastavení komponent, které je v souladu s XML schématem konfiguraˇcního souboru a validovat vstupy hodnot atributu, ˚ aby odpovídaly jejich datovým typum ˚ nebo povoleným hodnotám.

Návrh rˇešení

V této kapitole projdeme jednotlivé aspekty editoru a požadavky na nˇej kladené, z nich se vytvoˇrí vlastní návrh editoru – návrh vnitˇrní struktury, uživatelského rozhraní, použitých datových struktur, realizace klíˇcových operací, atd.. Jednotlivé návrhy budou podpoˇreny diagramy tˇríd v pˇrípadˇe vnitˇrní struktury a náhledy obrazovek editoru v pˇrípadˇe uživatelského rozhraní. 5.2.1 Architektura editoru Návrh architektury editoru budeme budovat od základních komponent editoru (objektové reprezentace XML souboru s konfigurací) k metodám, které s nimi budou manipulovat. Celý editor bude dodržovat architekturu MVC (Model-View-Controller). Nejprve si ujasníme základní rysy nového editoru, z kterých vyplývají nˇekteré du˚ sledky ovlinující ˇ implementaˇcní cˇ ást práce i samotný návrh editoru: 1.

výsledný editor má mít podobu zásuvného modulu do vývojového prostˇrední Eclipse, což implikuje použití programovacího jazyku Java pro implementaci, díky jeho úzkému vztahu s prostˇredím Eclipse.

2.

bude se intenzivnˇe pracovat s XML formátem souboru, ˚ na který bychom mohli použít DOM1 – pro usnadnˇení manipulace s tˇemito soubory.

1. Document Object Model – objektová reprezentace XML dokumentu, respektive API, které umožnuje ˇ pˇrístup cˇ i modifikaci obsahu nebo struktury dokumentu nebo jeho cˇ ástí.

22


3.

Místo DOM máme možnost použít SAX nebo StAX, což jsou pˇrístupy založené na proudovém zpracování XML souboru˚ (DOM naˇcítá dokument jako celek do pamˇeti). Proudové zpracování disponuje nízkou pamˇet’ovou nároˇcnost, ale nenabízí flexibilní pˇrístup k datum ˚ z XML souboru (DOM umožnuje ˇ pˇrímý pˇrístup k jakékoliv cˇ ásti dokumentu). Díky tomu, že budeme pracovat se soubory, které neobsahují velké množství dat, tak je DOM lepší varianta, právˇe kvuli ˚ flexibilitˇe pˇrístupu k datum. ˚

kvuli ˚ požadavku na upravitelnost editoru bude nutné vymyslet zpusob ˚ jakým bude editor udržovat informaci o možnostech nastavení konfiguraˇcního souboru JBoss ESB. •

V tomto ohledu se nám nabízí jednoduché rˇ ešení – XML schéma, které popisuje konfiguraˇcní soubor. Soubor se schématem obsahuje všechny potˇrebné informace (jaké máme dostupné poskytovatele, jaké hodnoty mohou mít jednotlivé atributy, . . . ). Bohužel schéma neobsahuje textový popis komponent pro uživatele typu „Co jaký element a atribut znamená a co jeho nastavení ovlivní.“. Tento popis je duležitý ˚ pro vlastní editor, aby uživatel vˇedˇel co nastavuje, a je nutné jej nˇekde uchovávat. Z tohoto duvodu ˚ je použití samotného XML schématu nedostateˇcné.

•

Nastavení, které bude uchovávat možnosti konfigurace JBoss ESB, bude realizováno pomocí tzv. properties souboru˚ 2 . Formát a zpusob ˚ použití tˇechto souboru˚ je popsán v 5.2.3.

5.2.2 Model Proto, aby mohl vyvíjený editor efektivnˇe pracovat s konfiguraˇcním souborem JBoss ESB, je nutné informace z tohoto souboru udržovat 2. Properties soubor – jedná se o textový typ souboru se specifickým formátem podobným mapˇe klíˇc-hodnota, každému definovanému klíˇci odpovídá urˇcitá hodnota.

23

5. V ÝVOJ NOVÉHO NÁSTROJE PRO NASTAVENÍ JB OSS ESB naˇctené v operaˇcní pamˇeti. Z tohoto duvodu ˚ vyvstala potˇreba objektové reprezentace XML souboru. S definováním této reprezentace nám pomohou dvˇe vlastnosti, které konfiguraˇcní soubor má: •

stromová struktura – jelikož je konfiguraˇcní soubor ve formátu XML, tak máme zaruˇcenou stromovou strukturu uložených dat – jeden koˇrenový element <jbossesb>, který má syny (elementy) <providers>, <services> a , ty mají své syny a tak dále.

•

formát uložených dat – ten vychází z toho, že se jedná o XML soubor s definovaným XML schématem. Tudíž víme, že data jsou uložena v atributech elementu˚ a mají definovaný formát (jakého jsou typu, jakých hodnot mohou nabývat, zdali jsou vyžadovaná).

Na základˇe tˇechto vlastností vytvoˇríme strukturu, která bude do jisté míry kopírovat formát XML souboru (elementy, atributy a jejich vztahy), navíc ale bude poskytovat snazší pˇrístup k informacím v nˇem uložených a nést informace duležité ˚ pro prezentaˇcní vrstvu editoru (rozmístˇení objektu˚ a jejich velikost, popisky, nápovˇedu). Definujeme tedy základní tˇrídy modelu (viz Obr. 5.1): •

XMLDocument – tˇrída reprezentuje celý konfiguraˇcní soubor. Obsahuje odkaz na koˇrenový element <jbossesb>. Navíc poskytuje základní metody pro snazší manipulaci s konfigurací (napˇr. pˇridání poskytovatele nebo služby, smazání nˇejaké cˇ ásti konfigurace, atd.).

•

XMLElement – tˇrída, která tvoˇrí ekvivalent k elementu v XML souboru s konfigurací – má své potomky typu XMLElement a atributy typu XMLAttribute. Navíc nese informaci pro prezentaˇcní vrstvu editoru (název, nápovˇeda, velikost a umístˇení objektu). Pro snazší urˇcení lokace elementu v XML souboru definujeme atribut address, který obsahuje posloupnost elementu˚ od koˇrene k aktuálnímu elementu.

•

XMLAttribute – tˇrída, která odpovídá atributum ˚ elementu. Mimo názvu a hodnoty nese také dodateˇcné informace získané z možností nastavení JBoss ESB – zdali je atribut povinný 24

5. V ÝVOJ NOVÉHO NÁSTROJE PRO NASTAVENÍ JB OSS ESB

Obrázek 5.1: Diagram tˇríd modelu editoru (musí být vždy zadán), jakého je datového typu, jakých hodnot muže ˚ nabývat. Také obsahuje informaci pro prezentaˇcní vrstvu – název a nápovˇedu (tyto údaje jsou zobrazovány uživateli pˇri editaci). Balík org.jboss.jbossesb.eclipse.plugin.model (viz Obr. 5.1), v kterém jsou uloženy základní tˇrídy modelu, obsahuje také properties soubory. Tyto soubory definují možnosti nastavení JBoss ESB (jaké poskytovatele je možné použít, jaké atributy je možné nastavit, . . . ). Více informací o funkci a formátu tˇechto souboru˚ je uvedeno v následující kapitole 5.2.3. 5.2.3 Uložení konfiguraˇcních možností JBoss ESB Kvuli ˚ požadavku na snadnou rozšíˇritelnost editoru, ve smyslu pˇridání nových možností nastavení JBoss ESB (napˇr. pˇri vydání jeho novˇejší verze), bylo potˇreba vymyslet zpusob, ˚ jak tyto konfiguraˇcní 25

5. V ÝVOJ NOVÉHO NÁSTROJE PRO NASTAVENÍ JB OSS ESB možnosti uchovávat a editovat. V pˇrípadˇe, kdybychom konfiguraˇcní možnosti integrovali pˇrímo do kódu aplikace, bychom nesplnili požadavek na snadnou rozšiˇritelnost (pˇri vydání nové verze s novými možnostmi by byl nutný zásah do zdrojového kódu editoru). Jako prostˇredek pro uložení konfiguraˇcních možností JBoss ESB byly zvoleny properties soubory, které mají vazbu na prostˇredí programovacího jazyka Java (umíme s nimi snadno pracovat) a zároven, ˇ jelikož se jedná o textové soubory, je jednoduché je editovat. Tyto soubory mají formát mapy textových rˇ etˇezcu˚ (klíˇc = hodnota). Ukázka takového souboru je znázornˇena na Obr. 5.2. Mapování možností konfigurace na tento typ souboru˚ je následující: •

•

klíˇc - obsahuje adresu daného prvku – posloupnost elementu˚ od koˇrenového k urˇcitému elementu nebo atributu. Jako oddˇelovaˇc je použit znak /. Pˇríklad klíˇce: jms-provider/name, specifikuje adresu k atributu name poskytovatele JMS. –

každý takový soubor navíc obsahuje speciální záznam s klíˇcem address, který definuje koˇrenový element pro daný soubor. Hodnotou záznamu je posloupnost názvu˚ elementu˚ od koˇrene dokumentu až k definovanému elementu. V návaznosti na pˇredchozí pˇríklad by hodnota záznamu s klíˇcem address byla následující: /jbossesb/ providers/

–

spojením hodnoty klíˇce address s klíˇcem nˇejakého jiného záznamu získáme kompletní cestu od koˇrenového elementu k cílovému elementu nebo atributu: /jbossesb/ providers/jms-provider/name.

hodnota - obsahuje informaci o daném prvku v definovaném formátu. Formát hodnot navíc mužeme ˚ rozdˇelit do dvou skupin podle toho, zdali se jedná o definici elementu nebo atributu (jako oddˇelovaˇc je použit znak #): –

definice elementu: ˚ E#required#text#hint ∗ ∗

E – identifikace, že se jedná o element. required – obsahuje na prvním místˇe znak R (je vyžadováno) nebo O (není vyžadováno). Na další po26


∗ ∗ –

zici jsou specifikovány možnosti výskytu tohoto elementu v podobˇe zápisu 11 (musí se v dokumentu nacházet jen jednou), 1N (muže ˚ se v dokumentu nacházet vícekrát, minimálnˇe alesponˇ jednou), 01 (muže ˚ se v dokumentu nacházet maximálnˇe jednou), 0N (dokument jej muže ˚ obsahovat vícekrát). text – název elementu, který bude použit pro prezentaˇcní vrstvu editoru. hint – nápovˇeda k elementu pro uživatele zobrazená na prezentaˇcní vrstvˇe.

definice atributu: ˚ A#type#required#allowedValues#implicitValues#text# hint ∗ ∗

∗ ∗

∗ ∗ ∗

A – identifikace, že se jedná o atribut. type – jakého datového typu je atribut. Muže ˚ nabývat hodnot String (textový rˇ etˇezec), int (celé cˇ íslo), boolean (pravdivostní hodnota). required – obsahuje bud’to znak R (je vyžadováno) nebo O (není vyžadováno). allowedValues – obsahuje seznam povolených hodnot, jakých muže ˚ atribut nabývat (jako oddˇelovaˇc je použit znak ,). implicitValues – obsahuje implicitní hodnotu. text – název atributu, který bude použit pro prezentaˇcní vrstvu editoru hint – nápovˇeda k atributu pro uživatele zobrazená na prezentaˇcní vrstvˇe.

Properties soubory se nachází v balíku org.jboss.jbossesb.eclipse .plugin.model a jsou rozdˇeleny podle toho, jakou cˇ ást konfiguraˇcního souboru JBoss ESB upravují: •

jbossesb – nastavení elementu <jbossesb> (koˇrenového elementu dokumentu).

•

globals – nastavení elementu (globální nastavení). 27

5. V ÝVOJ NOVÉHO NÁSTROJE PRO NASTAVENÍ JB OSS ESB address=/jbossesb/providers/ jms-provider=E\#O0N\#JMS Provider\#A provider, providing JMS. jms-provider/name=A\#String\#R\#\#\#Name\# jms-provider/jndi-URL=A\#String\#O\#\#\#JNDI URL\# The URL used to do naming lookups. jms-provider/jms-bus=E\#R1N\#JMS Bus\# A~bus using the JMS protocol. jms-provider/jms-bus/busid=A\#String\#R\#\#\#ID\#

Obrázek 5.2: Ukázka ze souboru s nastavením poskytovatele JMS •

service – nastavení elementu <service> (služby).

•

listeners – obsahuje seznam dostupných posluchaˇcu. ˚ Formát tohoto souboru je odlišný než bylo popsáno výše – jako klíˇc slouží název properties souboru, který obsahuje nastavení posluchaˇce, hodnota odpovídá textu, který bude použit pro zobrazení posluchaˇce uživateli v prezentaˇcní vrstvˇe. Pˇríklad záznamu z tohoto souboru je: jms-listener=JMS Listener.

•

providers – obsahuje seznam dostupných poskytovatelu. ˚ Formát tohoto souboru je shodný s formátem popsaným v odrážce listeners.

Jak je z popisu properties souboru˚ a jejich formátu˚ patrné, tak pˇridání napˇr. nového poskytovatele k tˇem souˇcasným znamená pouze vytvoˇrit nový properties soubor, v nˇem definovat všechny elementy a atributy použité u daného poskytovatele a záznam o tomto souboru vložit do providers.properties. Tím se automaticky nový poskytovatel zpˇrístupní a uživatel jej muže ˚ zaˇcít používat. Úprava napˇr. možností nastavení služeb v JBoss ESB se provede jednoduše editací souboru service.properties. Pˇri zachování definovaného formátu properties souboru˚ je editor velmi dobˇre a snadno rozšiˇritelný o nové možnosti nastavení. 5.2.4 Controller Mapování mezi objektovou podobou konfigurace v pamˇeti a XML souborem realizuje tˇrída XMLManipulator, která je uložena v balíku org.jboss.jbossesb.eclipse.plugin.controller (viz Obr. 5.3). Tato tˇrída 28

5. V ÝVOJ NOVÉHO NÁSTROJE PRO NASTAVENÍ JB OSS ESB obsahuje atribut typu File, který obsahuje konfiguraˇcní soubor a dvˇe sofistikované metody: •

•

loadConfiguration – zodpovídá za naˇctení souboru s konfigurací do jeho objektové podoby uložené v pamˇeti. Tento proces se skládá z nˇekolika cˇ ástí: –

ovˇerˇ ení dostupnosti souboru a jeho validace oproti XML schématu.

–

pokud je vstup v poˇrádku, tak se pomocí algoritmu pru˚ chodu grafem do šíˇrky postupnˇe naˇctou vstupní data a vytvoˇrí se jejich ekvivalentí struktura v operaˇcní pamˇeti. V tomto procesu se pro snazší manipulaci s XML souborem použije implementace DOM.

–

pˇri vytváˇrení struktury v pamˇeti se souˇcasnˇe prochází properties soubory, ze kterých se extrahují dodateˇcné informace (názvy, datové typy a povinnost vyplnˇení atributu, ˚ . . . ). Tyto informace se pˇridávají k vytváˇreným objektum. ˚

saveConfiguration – realizuje zápis objektového modelu konfigurace zpˇet do souboru. Prochází objektovou strukturu uloženou v operaˇcní pamˇeti a za pomoci DOM vytvoˇrí ekvivaletní XML strukturu, kterou následnˇe zapíše do souboru.

Mimo stˇežejní tˇrídy XMLManipulator tento balík také obsahuje tˇrídu PropertiesManipulator, která poskytuje podpurné ˚ metody, pro snazší získávání dat z properties souboru˚ s možnostmi konfigurace JBoss ESB. Umožnuje ˇ tak napˇr. získat nastavení atributu˚ nˇejakého konkrétního elementu, získat kompletní pˇrehled o možnostech nastavení urˇcitého elementu nebo získávat konkrétní údaj (typ, povinnost, jméno, . . . ) k zadanému elementu/atributu. 5.2.5 View Uživatelské rozhraní editoru je jeho duležitá ˚ souˇcást a musí jí být vˇenována náležitá pozornost. Je to pˇredevším díky tomu, že právˇe s touto cˇ ásti pˇrichází do kontaktu uživatel, pro kterého musí být rozhraní intuitivní, snadno pochopitelné a pˇritom nabízet komplexní 29


Obrázek 5.3: Diagram tˇríd controlleru editoru pohled na problémovou oblast (v našem pˇrípadˇe konfiguraci JBoss ESB). Uživatelské rozhraní bude mít v našem pˇrípadˇe podobu grafického editoru – jednotlivé komponenty JBoss ESB budou znázornˇeny jako grafické objekty, které bude snadné pˇridávat, editovat, propojovat a mazat. Z tohoto nám vyplývají základní cˇ ásti editoru: 1.

Operace – sekce, která bude poskytovat možnost manipulovat s objekty (komponentami JBoss ESB).

2.

Návrháˇr – plocha pro zobrazení jednotlivých komponent a jejich propojení.

Komponenty, které bude uživatelské rozhraní zobrazovat budou následujících typu: ˚ 1.

Poskytovatel – odpovídající elementu <provider> z konfiguraˇcního souboru. Tˇechto komponent muže ˚ návrháˇr obsahovat více.

2.

Služba – odpovídající elementu <service> z konfiguraˇcního souboru. Tˇechto komponent muže ˚ návrháˇr obsahovat více. 30


Obrázek 5.4: Návrh grafického rozhraní editoru 3.

Globální nastavení – jediná komponenta, která obsahuje nastavení z konfiguraˇcního souboru, které má globální platnost tzn. atributy elementu˚ <jbossesb> a . Tuto komponentu nelze smazat ani vložit vícekrát.

4.

Propojení – definuje vztah mezi poskytovatelem (respektive nˇekterou z jeho sbˇernic) a službou. Uživatel bude moci tato spojení vytváˇret a mazat.

Návrh uživatelského rozhraní je zobrazen na Obr. 5.4. Je rozdˇelen do dvou sekcí Operace (levá cˇ ást) a Návrháˇr (pravá cˇ ást). Mimo zmínˇených cˇ ástí musí editor umožnovat: ˇ •

snadnou úpravu komponent – pˇri dvojkliku na libovolnou komponentu se zobrazí dialogové okno, které uživateli nabídne nastavení dané komponenty (jejich atributu˚ a zanoˇrených elementu˚ vˇcetnˇe jejich vytváˇrení a mazání). Návrh dialogového okna je zobrazen na Obr. 5.5.

•

úprava zobrazení komponent – uživatel musí mít také možnost úpravy rozložení komponent v návrháˇri – tzn. má možnost pˇresouvat objekty a mˇenit jejich velikost. 31


Obrázek 5.5: Návrh dialogového (editaˇcního) okna editoru Pˇri otevˇrení detailu nˇejakého objektu (dvojklik myší na daný objekt) se zobrazí dialogové okno. Jednotlivé prvky tohoto okna jsou dynamické – tvoˇrí se na základˇe uložených vlastností objektu v pamˇeti a možností jeho nastavení (napˇr. pˇridat/odebrat akci u služby). Stejné dialogové okno se používá i pˇri vytváˇrení nových objektu, ˚ kdy se na základˇe vlastností vytváˇreného objektu (zjištˇených z properties souboru), ˚ dynamicky vytvoˇrí povinné položky (jako napˇr. jméno a kategorie u služby) a tlaˇcítka, která umožnují ˇ pˇridávat volitelné položky. Pˇri konstrukci dialogového okna se tedy zpracovávají informace jak z modelu, tak z properties souboru. ˚ 5.2.6 Inicializace editoru Proces inicializace editoru je jedna ze stˇežejních fází bˇehu celé aplikace. Pˇri inicializaci probíhají duležité ˚ úlohy, které zajišt’ují správný bˇeh editoru. Diagram zachycující proces inicializace editoru je uveden na Obr. 5.6. Jak je z obrázku patrné, tak je pro správný bˇeh editoru nutné mít 32


Obrázek 5.6: Proces inicializace editoru k dispozici soubory: •

XML schéma - popisující strukturu konfiguraˇcního souboru JBoss ESB.

•

properties soubory - obsahující dodateˇcné informace k atributum ˚ a elementum ˚ definovaných XML schématem (napˇr. názvy a popisky pro prezentaˇcní vrstvu editoru).

Tyto soubory budou souˇcástí instalace editoru. V pˇrípadˇe potˇreby je však bude možné vymˇenit, respektive upravit. Zmˇenou tˇechto souboru˚ se mˇení možnosti editoru – lze tak napˇr. pˇridávat nové poskytovatele, upravit souˇcasné možnosti nastavení jednotlivých komponent JBoss ESB, . . .

5.3

Použité technologie

Seznam použitých technologií: •

Java – programovací jazyk použitý pro kompletní implementaci editoru. 33


Eclipse – vývojové prostˇrední a zárovenˇ prostˇredí, pro které je zásuvný modul v podobˇe editoru urˇcen.

•

XML – formát souboru˚ použitý pro konfiguraˇcní soubor obsahující nastavení JBoss ESB.

•

DOM – API použité pro manipulaci s XML soubory konfigurace JBoss ESB.

•

GEF (Graphical Editing Framework) – framework použitý pro vytvoˇrení grafického rozhraní editoru (více viz kapitola 5.3.1).

5.3.1 GEF (Graphical Editing Framework) GEF umožnuje ˇ jednoduchý a rychlý vývoj grafické reprezentace datových modelu, ˚ komplexních grafických editoru˚ a pohledu˚ pro vývojové prostˇredí Eclipse [15, 16]. GEF se skládá z tˇechto komponent: •

Draw2D – nástroj pro 2D kreslení objektu˚ a jejich rozvhování na SWT kreslící ploše.

•

GEF – interaktivní MVC framework postavený nad Draw2D.

•

Zest – vizualizaˇcní nástroj postavený nad Draw2D.

Draw2D poskytuje tzv. lightweight system3 grafických komponent nazývaných figures. Tyto komponenty tvoˇrí mezi sebou vztahy typu otec-syn. Každá komponenta má definovány hranice (bounds), ve kterých je ona a její synové vykreslena. Draw2D se soustˇredí na efektivní vykreslování objektu˚ a jejich rozmístˇení po kreslící ploše. Navíc se jedná o samostatnou grafickou knihovnu, která muže ˚ být použita nezávisle na GEF, dokonce i na Eclipse. GEF sám je postaven na architektuˇre MVC (Model-View-Controller), kde jednotlivé cˇ ásti mužeme ˚ definovat následovnˇe: 3. lightweight system – je grafický systém, který je hostován uvnitˇr grafického systému operaˇcního systému. Jeho objekty se chovají jako normální okna (mohou být vybrána, mají koordináty umístˇení, zachytávají události – stisk klávesy, . . . ). Výhodou tohoto systému je flexibilita a možnost vytváˇret komplexní objekty rozliˇcných tvaru˚ bez velké pamˇet’ové nároˇcnosti [15].

34


Obrázek 5.7: Diagram stˇežejních cˇ ástí GEF (pˇrevzato z [16]) •

Model – mohou za nˇej být považována libovolná data, která chceme nˇejakým zpusobem ˚ vizualizovat/zpracovávat. Model musí mít nˇejaký mechanismus pro upozornování ˇ na zmˇeny – tzn. musí umˇet dát povel, že se data zmˇenila a zmˇeny se mají promítnout do prezentaˇcní vrstvy (View).

•

View – cokoliv co je viditelné uživateli. V kontextu GEF jsou to pˇredevším Figures (objekty z Draw2D).

•

Controller – poskytuje spojení mezi modelem a prezentaˇcní vrstvou (View). Je také zodpovˇedný za editaci modelu. V kontextu GEF se controller nazývá EditPart.

Na Obr. 5.7 je znázornˇeno rozdˇelení GEF na Model, View a Controller – pro každý objekt modelu je vytvoˇren pˇres tzv. EditPart Factory nˇejaký controller, který odpovídá za jeden nebo více objektu˚ z prezentaˇcní vrstvy. 35


5.4

Implementace

V kapitole 5.2 již byly pˇredstaveny základní kameny nového editoru a rozvinuty postupy k dosažení stanovených cílu. ˚ Jak již bylo zmínˇeno, tak implementace je realizována v jazyce Java za použití standardní knihovny. Výsledný editor má podobu zásuvného modulu do vývojového prostˇredí Eclipse. Jednotlivé cˇ ásti byly implementovány pˇresnˇe dle popisu uvedeném v kapitole 5.2. Zdrojové kódy aplikace jsou logicky dˇeleny do tˇechto balíku: ˚ org.jboss.jbossesb.eclipse.plugin. •

configuration - obsahuje soubor configuration.properties, jež nastavuje umístˇení XML schématu, které se používá pro validaci konfiguraˇcních souboru. ˚

•

controller - obsahuje tˇrídy zodpovídající za naˇcítání a ukládání informací z konfiguraˇcního souboru (více viz kapitola 5.2.4) a snazší naˇcítání informací o možnostech konfigurace JBoss ESB.

•

model - obsahuje tˇrídy reprezentující objektový model sloužící pro uložení konfiguraˇcního souboru do pamˇeti (více viz kapitola 5.2.2) a properties soubory obsahující možnosti nastavení jednotlivých komponent JBoss ESB (více viz kapitola 5.2.3).

•

view - obsahuje tˇrídy zodpovídají za prezentaˇcní vrstvu aplikace. Rozbor tohoto balíku je uveden níže.

Pomocí balíku org.jboss.jbossesb.eclipse.plugin.view se realizuje grafické zobrazení objektového modelu uloženého v pamˇeti uživateli a umožnuje ˇ mu s ním manipulovat. Pro usnadnˇení implementace prezentaˇcní vrstvy editoru byl použit framework GEF (více viz kapitola 5.3.1). Výbˇer tohoto frameworku byl nasnadˇe, kvuli ˚ jeho integraci s prostˇredím Eclipse. Díky použití GEF, staˇcilo implementovat tˇrídy rozdˇelené do následujících balíku: ˚ •

figure - definuje grafickou podobu objektu, ˚ respektive konfiguraˇcních komponent JBoss ESB. Patˇrí mezi nˇe: –

ServiceFigure - reprezentuje elementy <service>. 36

5. V ÝVOJ NOVÉHO NÁSTROJE PRO NASTAVENÍ JB OSS ESB –

ProviderFigure - reprezentuje elementy, které jsou syny <providers>.

–

JBossESBFigure - reprezentuje nastavení uložené v elementech <jbossesb> a .

•

part - obsahuje tˇrídy, které vytváˇrí a spravují objekty z balíku figure a definují, jaké operace je možné s objekty provádˇet pomocí tzv. policies (tˇríd z balíku policy).

•

factory - provádí mapování objektu˚ modelu na objekty z balíku part. Obsahuje tˇrídu EditorPartFactory, jejíž metoda createEditPart je volána pˇri inicializaci editoru a dle naˇcteného modelu vytváˇrí pˇríslušné objekty tˇríd z balíku part. Souˇcasnˇe obsahuje další tˇrídy, které se starají o vytvoˇrení nových objektu˚ na základˇe vstupu uživatele (napˇr. pˇridání nového poskytovatele).

•

command - provádí zmˇeny v objektovém modelu konfiguraˇcního souboru (vytváˇrení nových objektu˚ typu XMLElement a XMLAttribute a zmˇeny atributu˚ tˇechto objektu). ˚

•

policy - tˇrídy z tohoto balíku se pˇripojují k tˇrídám z balíku part a definují reakce na interakci s uživatelem (napˇr. vytvorˇ ení nebo smazání nˇejakého objektu). Volají metody z balíku command.

•

dialog - obsahuje pˇredevším tˇrídu EditDialog, která slouží pro zobrazení dialogového okna. Pomocí tohoto okna se provádí editace jednotlivých komponent zobrazených v editoru. Obsah dialogu je generován dynamicky podle toho, kterou komponentu chce uživatel editovat. Stejné dialogové okno je použito také pˇri vytváˇrení nových komponent (služeb, poskytovatelu, ˚ propojení).

Implementaˇcní detaily jsou popsány pomocí komentáˇru˚ pˇrímo ve zdrojovém kódu editoru. Všechny tˇrídy a metody jsou navíc anotovány JavaDoc komentáˇri, ze kterých byla vytvoˇrena aplikaˇcní dokumentace. Za velkým durazem, ˚ kladeným na popis zdrojového kódu, se skrývá snaha o zajištˇení snadné správy editoru a jeho budoucího, jednoduchého rozšíˇrení o novou funkcionalitu. 37


5.5

Popis vlastností nového editoru

Vytvoˇrený grafický editor pro úpravu nastavení JBoss ESB umožnuje ˇ snadnou a intuitivní práci s konfiguraˇcním souborem JBoss ESB. Mezi jeho základní vlastnosti patˇrí: •

spouští se pouze na XML soubory, které obsahují konfiguraci pro JBoss ESB.

•

na základˇe XML schématu, urˇceného pro konfiguraˇcní soubor JBoss ESB, provádí validaci vstupu˚ od uživatele, respektive umožnuje ˇ provádˇet pouze takové modifikace, které zachovají výsledný XML soubor validní.

•

umožnuje ˇ grafickou práci s XML souborem tzn. jednotlivé elementy XML souboru graficky znázornuje ˇ a poskytuje uživateli nástroje pro manipulaci s nimi.

•

díky grafické reprezentaci konfiguraˇcního souboru, poskytuje celkový pohled na aktuální nastavení JBoss ESB. Zobrazuje duležité ˚ informace a vazby mezi jednotlivými komponentami.

•

je snadno modifikovatelný bez nutnosti úpravy zdrojového kódu editoru – staˇcí upravit textové properties soubory a tím získat napˇr. s novou verzí JBoss ESB nové poskytovatele, . . .

Na Obr. 5.8 je zobrazeno hlavní editaˇcní okno nového editoru pro úpravu konfiguraˇcního souboru JBoss ESB. Z obrázku je na první pohled patrná transformace informací uložených v XML souboru do podoby, která je grafickým pˇriblížením zapojení jednotlivých komponent JBoss ESB. Díky tomu uživatel získá nadhled nad daným zapojením (napˇr. ihned vidí, které služby mohou spolu komunikovat, pˇres jaké poskytovatele a které jsou naopak odˇríznuté), cˇ ehož jsme chtˇeli dosáhnout Uživatel tak získává intuitivní vhled do konfigurace a muže ˚ ji snadno editovat. Hlavní editaˇcní okno umožnuje ˇ uživateli: •

pˇridávat nové objekty (pomocí nabídky v sekci Palette). Tˇemito objekty rozumíme: 38


Obrázek 5.8: Hlavní okno nového editoru –

poskytovatele

–

služby

–

a tzv. Connection, což je propojení služby s poskytovatelem, respektive s jednou z jeho sbˇernic (více viz 3.3.1).

•

pohybem myši mˇenit velikost a umístˇení zobrazených objektu. ˚

•

dvojklik na libovolný objekt otevˇre dialogové okno s vlastnostmi daného objektu – nabízí tedy editaci zobrazených objektu. ˚

•

mazání objektu˚ pomocí pˇríslušného tlaˇcítka.

•

podporuje operace Zpˇet a Vpˇred, kterými je možné zvrátit nebo naopak obnovit provedené operace.

Na Obr. 5.9 je ukázka obsahu dialogového editaˇcního okna. Toto okno slouží k editaci všech vlastností objektu. Je vytváˇreno dynamicky podle aktuálního nastavení objektu (zmˇena nastavení – napˇr. pˇridání nové akce u služby – vyvolá pˇrekreslení okna). Uživateli nabízí editaˇcní dialog následující: •

pˇrehled o aktuálním nastavení objektu. 39


Obrázek 5.9: Ukázka editaˇcního dialogu •

pˇrímou editaci vlastností objektu, vˇcetnˇe pˇridávání nebo odebírání podˇcástí konfigurace. Navíc umožnuje ˇ pˇridávat pouze takové podˇcásti (napˇr. v pˇrípadˇe služby – akce, nastavení bezpeˇcnosti a vlastnosti), které jsou korektní vuˇ ˚ ci XML schématu konfiguraˇcního souboru. Uživatel tedy nemuže ˚ svými úpravami vytvoˇrit nastavení, které by nebylo v poˇrádku.

•

pˇri pokusu o uložení provádí kontrolu validity vstupu – projde všechny nastavené atributy (vstupní hodnoty) a zkontroluje, zdali jsou korektní (ˇcíselný atribut obsahuje cˇ íslo, textový rˇ etˇezec není pˇríliš dlouhý, povinné položky jsou vyplnˇeny, . . . ). Pokud se objeví chyba, je o tom uživatel informován. Dialog se nepodaˇrí uložit dokud úspˇešnˇe neprojde kontrolou validity vstupních údaju. ˚

40


5.6

Instalace editoru

Pro správnou funkˇcnost editoru je potˇreba mít nainstalované: •

Java Standard Edition 1.6 nebo vyšší

•

vývojové prostˇredí Eclipse ve verzi 3.5 (Galileo) nebo vyšší

Pro instalaci potˇrebujeme sestavený editor v podobˇe JAR archivu, který mužeme ˚ získat tˇemito zpusoby: ˚ •

najdeme jej na pˇriloženém CD v koˇrenovém adresáˇri pod názvem JBossESB - Configuration Plugin For Eclipse (1.0.0).jar

•

projekt obsahující zdrojové soubory editoru importujeme do vývojového prostˇredí Eclipse (File → Import → Existing Projects into Workspace → dohledáme koˇrenový adresáˇr s projektem (JBossESB-Configuration-Plugin-For-Eclipse)). Následnˇe jej budeme exportovat (provede se sestavení projektu a vytvorˇ ení JAR archivu): klikneme pravým tlaˇcítkem myši na projekt a zvolíte Export → Deployable plug-ins and fragments → Finish.

Vlastní instalaci editoru provedeme zkopírováním sestaveného editoru (v podobˇe JAR archivu) do složky dropins, kterou najdeme ve složce obsahující instalaci vývojového prostˇredí Eclipse. Tímto zkopírováním je instalace editoru hotova. Pˇri dalším spuštˇení vývojového prostˇredí Eclipse se automaticky naˇcte i nový editor.

41

6 Závˇer Tato práce se vˇenovala problematice aplikaˇcní integrace v podobˇe produktu JBoss ESB, jeho konfiguraci a pˇredevším vývoji nového nástroje, který usnadnuje ˇ práci pˇri editaci konfiguraˇcního souboru JBoss ESB. Zhodnocení práce, v podobˇe splnˇení stanovených cílu, ˚ je následující: •

v úvodních kapitolách byla nastínˇena problematika aplikaˇcní integrace, historické souvislosti s ní spjaté a pˇredevším pˇredstaven produkt JBoss ESB. Dále tato práce rozebrala jednotlivé komponenty JBoss ESB a vysvˇetlila jejich úˇcel a použití.

•

byl pˇredstaven editor nastavení JBoss ESB Editor 1.3 – soucˇ asný nástroj pro úpravu konfiguraˇcního souboru JBoss ESB. Nedostatky tohoto editoru se snaží odstranit nový nástroj vyvinutý v rámci této práce.

•

na základˇe uživatelských zkušeností se souˇcasným editorem konfiguraˇcního souboru JBoss ESB a požadavku˚ vznesených konzultantem z firmy Red Hat, Ing. Jiˇrím Pechancem, byly sepsány požadavky kladené na nový editor, formou struˇcné analýzy problémové oblasti.

•

nejvˇetší cˇ ást práce byla vˇenována samotnému návrhu editoru a jeho implementaci. Podaˇrilo se vytvoˇrit úplnˇe nový editor konfiguraˇcního souboru JBoss ESB, který je založen na grafické manipulaci s jednotlivými komponentami konfigurace. Souˇcasnˇe se naplnila oˇcekávání na nový editor kladená – zobrazuje konfiguraˇcní soubor v uživateli snadno cˇ itelné podobˇe a pˇri editaci udržuje konzistenci a správnost nastavení. Navíc se podaˇrilo implementovat mechanismus, který dovoluje snadné rozšíˇrení možností nastavení editoru – bez potˇreby zásahu do zdrojových souboru˚ editoru, je možné (s pˇríchodem nových verzí JBoss ESB) pˇridávat napˇr. nové poskytovatele, nastavení služeb, . . . 42

ˇ 6. Z ÁV ER

Implementace nového editoru je volnˇe dostupná, vˇcetnˇe zdrojových souboru, ˚ na serveru GitHub1 . Dále bude nabídnuta komunitˇe JBoss k zaˇrazení do balíku JBoss Tools, který obsahuje nástroje (zásuvné moduly pro vývojové prostˇredí Eclipse) na podporu JBoss technologií, mezi které patˇrí mimo jiné i JBoss ESB. Použití tohoto editoru se nemusí vztahovat pouze na editaci konfiguraˇcního souboru JBoss ESB. Pˇri zmˇenˇe prezentaˇcní vrstvy muže ˚ editor sloužit jako nástroj pro grafickou úpravu libovolného XML souboru, jehož formát je definovaný pomocí XML schématu. Vývoj editoru se odevzdáním této práce nezastaví, ale bude pokraˇcovat. Nejvíce by se mohlo zapracovat na uživatelském rozhraní (napˇr. zjednodušení formuláˇru, ˚ dialogu˚ a pˇridání detailnˇejších možností nastavení). Další prostor se nabízí v možnosti integrace editoru s již používaným editorem, který implementuje mnoho užiteˇcných prvku˚ (vylepšený textový XML editor s podporou syntaxe konfiguraˇcního souboru JBoss ESB, vˇetší integrace do vývojového prostˇredí Eclipse – používání standardních záložek Outline a Properties).

1.

https://github.com/xsedmik/JBossESB-Configuration-Plugin-For-Eclipse

43

Literatura [1] JBossESB: Programmers Guide [online]. [cit. 2012-10-01]. Dostupné z: . [2] HOHPE, Gregor a Booby WOOLF. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Boston: Pearson Education, Inc., 2011. ISBN 03-212-0068-3. [3] MANOUVRIER, Bernard a MÉNARD. Application integration: EAI, B2B, BPM and SOA. London: ISTE, 2008, xvi, 224 s. ISBN 978-1-84821-088-2. [4] Spaghetti System. Mule Soft – Blog [online]. [cit. 2012-11-30]. Dostupné z: . [5] EAI. In: Wikipedia: the free encyclopedia [online]. [cit. 201211-30]. Dostupné z: . [6] SCHULTE, Roy. Architecture and Planning for Modern Application Styles. GartnerGroup: Strategic Analysis Report. 1997. [7] GILPIN, Mike. Bank Mergers in France Highlight City Planning: Lessons Learned for Enterprise Architecture. Giga Information Group: Ideabyte. 1999. [8] BELL, Michael. Service-Oriented Modeling: Service Analysis, Design, and Architecture. Hoboken: Wiley & Sons, 2008, xvi, 366 s. ISBN 978-0-470-14111-3. [9] ERL, Thomas. SOA: principles of service design. Upper Saddle River: Prentice Hall, 2008, xxxii, 573 s. ISBN 978-0-13-234482-1. ˇ Jiˇrí. Business Activity Monitoring. Brno, 2009. Diplo[10] KOLÁR, mová práce. Masarykova Univerzita. Vedoucí práce RNDr. Jan Pavloviˇc, Ph.D. Dostupné z: . 44

L ITERATURA [11] CHAPPELL, David A. Enterprise service bus. 1st ed. Sebastopol: O’Reilly, 2004, 247 s. ISBN 05-960-0675-6. [12] CONNER, Kevin. JBoss ESB: Beginner’s guide : a comprehensive, practical guide to developing service-based applications using the open source JBoss Enterprise Service Bus. Birmingham B3 2PB, U.K.: Packt Publishing Ltd., 2012, vii, 297 p. ISBN 978-1-84951-658-7. [13] JBossESB: Administration Guide [online]. [cit. 2012-10-01]. Dostupné z: . [14] JBossESB: Tools User Guide [online]. [cit. 2012-10-01]. Dostupné z: . [15] MOORE, Bill a David DEAN. IBM. Eclipse Development: usign the Graphical Editing Framework and the Eclipse Modeling Framework [online]. 2004 [cit. 2013-04-25]. Dostupné z: . [16] GEF Programmer’s Guide [online]. [cit. 2013-04-25]. Dostupné z: .

45

A Obsah pˇriloženého CD •

text práce

•

zdrojové kódy aplikace JBossESB Configuration Plugin For Eclipse, vyvíjené v rámci této práce

•

JavaDoc dokumentace vyvíjené aplikace

46

B Ukázka jbossesb-properties.xml <esb xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="jbossesb-1_0.xsd"> ... <properties name="core"> <property name="org.jboss.soa.esb.jndi.server.type" value="jboss"/> <property name="org.jboss.soa.esb.jndi.server.url" value="localhost"/> <property name="jboss.esb.invm.scope.default" value="NONE"/> <properties name="transports" depends="core"> <property name="org.jboss.soa.esb.mail.smtp.host" value="localhost"/> <property name="org.jboss.soa.esb.mail.smtp.user" value="jbossesb"/> <property name="org.jboss.soa.esb.mail.smtp.password" value=""/> <property name="org.jboss.soa.esb.mail.smtp.port" value="25"/> <properties name="connection"> <property name="min-pool-size" value="5"/> <property name="max-pool-size" value="10"/> <property name="blocking-timeout-millis" value="5000"/> <property name="abandoned-connection-timeout" value="10000"/> <property name="abandoned-connection-time-interval" value="30000"/> ...

47

C Ukázka jboss-esb.xml <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/ product/etc/schemas/xml/jbossesb-1.0.1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://anonsvn.labs.jboss.com/labs/jbossesb/ trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd" parameterReloadSecs="5"> <providers> <jms-provider name="JBossMQ" connection-factory="ConnectionFactory"> <jms-bus busid="quickstartEsbChannel"> <jms-message-filter dest-type="QUEUE" dest-name="queue/quickstart_webservice_producer_esb"/> <jbr-provider name="JBR-Http" protocol="http" host="localhost"> <jbr-bus busid="Http-1" port="8765" /> <services> <service category="MyServiceCategory" description="WS Frontend" name="MyWSProducerService"> <listeners> <jbr-listener name="Http-Gateway" busidref="Http-1" is-gateway="true"/> <jms-listener name="JMS-ESBListener" busidref="quickstartEsbChannel"/>

48

012345

Recommend Documents