Ověřování nahraditelnosti EJB komponent. Pavel Stuna

Ověřování nahraditelnosti EJB komponent Pavel Stuna 17. května 2005

Abstract Verification of EJB components substitutability The aim of this diploma thesis is to compare two Enterprise JavaBeans components (version 2.1) from the client-side view. It is assumed, that one of the components is to be replaced with the second one, so two versions of one component are compared. EJB component is thought to be some kind of software package, which provides some functionality and also has some requirements. This view of components is defined in ENT component meta-model. There is given a big emphasis on comparing Java classes, which are the main part of EJB components. Theory of subtyping is mentioned here, because it is connected with substitutability. The created program loads the components from JAR-files, compares them and generates a value, from which can be decided the possibility of substitutability. A XML document with detailed descriptions of differences is also generated as a secondary output.

Obsah 1 Úvod 1 2 Enterprise JavaBeans 2 2.1 Softwarové komponenty....................... 2 2.2 J2EE.................................. 2 2.3 Distribuované vícevrstvé aplikace.................. 3 2.4 J2EE komponenty.......................... 4 2.5 JavaBeans Enterprise JavaBeans................. 4 2.6 Kontejnery v J2EE.......................... 4 2.7 Architektura EJB (verze 2.1).................... 5 2.7.1 EJB kontejner........................ 7 2.7.2 Druhy EJB komponent................... 7 2.8 Struktura EJB komponenty..................... 8 2.8.1 Deployment Descriptor................... 8 2.9 Session beans............................. 8 2.10 Entity beans............................. 9 2.10.1 Container Managed Persistence............... 9 2.10.2 Bean Managed Persistence................. 9 2.11 Message-driven beans........................ 9 3 ENT meta-model 10 3.1 Podobnosti v současných komponentních modelech........ 10 3.2 Klasifikační systém.......................... 10 3.3 Traits (charakteristické rysy).................... 11 3.4 Kategorie rysů............................ 11 3.5 ENT meta model EJB komponent................. 12 3.5.1 Typy komponent....................... 12 3.5.2 Tags (značky)......................... 13 3.5.3 Traits (rysy)......................... 13 3.5.4 Příklad jednoduché EJB komponenty........... 15 4 Nahraditelnost komponent 17 4.1 Druhy rozdílů............................. 17 4.2 Striktní nahraditelnost........................ 18 4.3 Podtypování.............................. 18 4.3.1 Rozšíření funkčnosti..................... 19 4.3.2 Podtypování funkcí...................... 19 4.3.3 Podtypování atributů.................... 19

5 Použité technologie 21 5.1 Programovací jazyk.......................... 21 5.2 Vývojové prostředí.......................... 21 5.3 Načtení komponenty......................... 22 5.3.1 Třída JarFile......................... 22 5.3.2 Document Object Model................... 22 5.4 Introspekce.............................. 23 5.4.1 Třída ClassLoader...................... 23 5.4.2 Třída Class.......................... 23 5.4.3 Třída Field.......................... 23 5.4.4 Třída Method......................... 23 5.4.5 Třída Constructor...................... 23 5.5 J2EE server.............................. 23 6 Implementace 25 6.1 Podtypové relace tříd v Javě.................... 25 6.1.1 Primitivní datové typy.................... 25 6.1.2 Klíčové slovo void...................... 26 6.1.3 Pole.............................. 27 6.1.4 Třídy............................. 27 6.2 Podtypové relace v ENT meta-modelu............... 27 6.2.1 Tagy.............................. 27 6.2.2 Rysy (traits)......................... 29 6.3 Důležité algoritmy.......................... 31 6.3.1 Porovnání tříd........................ 31 6.3.2 Operace nad množinou rozdílů............... 39 6.3.3 Načtení EJB komponent................... 40 6.3.4 Porovnání EJB komponent................. 40 6.4 Výsledek porovnání EJB komponent................ 41 6.4.1 Příklad výsledku porovnání................. 41 6.5 Technické nároky programu..................... 42 6.6 Ověření funkčnosti.......................... 43 7 Struktura programu 44 7.1 cz.zcu.stuna.beancmp........................ 44 7.2 cz.zcu.stuna.beancmp.classcmp................... 45 7.3 cz.zcu.stuna.beancmp.entejb..................... 45 7.4 cz.zcu.stuna.beancmp.utilities.................... 45 8 Závěr 47 Literatura Přílohy III IV

Prohlášení Prohlašuji, že jsem diplomovou práci vypracoval samostatně a výhradně s použitím citovaných pramenů. V Plzni dne 20.5.2005 Pavel Stuna,

1 Kapitola 1 Úvod Podnikovou softwarovou aplikaci můžeme rozložit do tří vrstev. Nejnižší vrstva zajišťuje úschovu dat (například do databáze nebo souboru). Nejvyšší vrstvou je prezentační logika, která slouží k zobrazování uživatelského rozhraní. Mezi těmito dvěma vrstvami se nachází aplikační logika, která představuje výkonný kód, provádějící převod dat z databázové vrstvy do prezentační logiky. Enterprise JavaBeans (EJB) je komponentní architektura, tvořící aplikační logiku. V této práci se budu zabývat EJB architekturou verze 2.1 (v současnosti je nejnovější verze 3.0). Softwarová komponenta je programový balík, který poskytuje sadu funkcí k řešení společného problému. Zapouzdřuje softwarovou funkcionalitu, umožňuje vícenásobné použití a lze ji použít s více komponentami, čímž se vytvoří softwarová aplikace. Jedna aplikace obsahuje zpravidla několik komponent, které mezi sebou komunikují přes daná rozhraní. Cílem práce je navrhnout a vytvořit program, který porovná dvě EJB komponenty. Z výsledků porovnání by mělo být mimo jiné jasné, zda jedna z komponent může nahradit druhou, aniž by se změnila funkcionalita celé aplikace, jejíž součástí je první z komponent. Nejčastěji se toto porovnání vyžaduje při pořízení novější verze komponenty. V úvodních kapitolách se budu snažit seznámit čtenáře s architekturou EJB. Poté se budu věnovat popisu ENT komponentního meta-modelu, který rozlišuje součásti komponenty podle toho, zda něco poskytují nebo vyžadují. V další kapitole se zmíním o teorii podtypových relací (podtypování, anglicky subtyping), která silně souvisí s nahraditelností. Dále popíši technologie použité na vývoj programu a poslední kapitoly budou patřit popisu implementace programu na porovnávání EJB komponent. V této práci se vyskytují různé anglické technické výrazy, které jsem se pokud to nepůsobí nezvykle rozhodl přeložit. U těchto slov ale vždy při prvním výskytu uvedu i jeho anglický tvar. Nicméně existují termíny, které jsem se rozhodl nepřekládat vůbec, protože jejich anglické názvy jsou v oboru vžité a jejich překlad do češtiny by mohl způsobit nedorozumění (v lepším případě pobavení čtenáře). Jsou to například termíny Enterprise JavaBeans nebo deployment descriptor.

2 Kapitola 2 Enterprise JavaBeans Enterprise JavaBeans je komponentní architektura, vyvíjená firmou Sun Microsystems. 2.1 Softwarové komponenty Softwarová komponenta je programový balík, který poskytuje množinu služeb, přístupných přes jedno nebo více rozhraní a je navrhována, implementovaná a testovaná zvlášť před začleněním do softwarové aplikace. Softwarové komponenty musí umět mezi sebou komunikovat, aby mohly být použitelné v jedné aplikaci. Existuje několik standardů pro vývoj softwarových komponent. Jedním z nich je například CORBA (Common Object Request Broker Architecture), který vyvinulo sdružení OMG (Object Management Group). CORBA je otevřená, platformově nezávislá architektura a infrastruktura, kterou počítačové aplikace používají ke spolupráci v síťovém prostředí. Ke komunikaci se využívá protokol IIOP (Internet Inter-Orb Protocol). Více informací najdete v [OMG]. Další z komponentových architektur je COM 1 (Component Object Model). Přestože byla implementována na několika platformách, nejvíce se používá v operačních systémech Microsoft Windows. Další informace viz [COM]. Třetí komponentovou technologií je EJB (Enterprise JavaBeans) firmy Sun. Touto technologií se budu dále zabývat více podrobněji. 2.2 J2EE Protože Enterprise JavaBeans komponenty jsou součástí architektury J2EE, pokusím se zde krátce tuto architekturu představit. V dnešní době se vytváří mnoho distribuovaných podnikových aplikací, a proto je důležité zvýšit rychlost, bezpečnost a spolehlivost tzv. server-side technologií, na nichž jsou většinou tyto aplikace založeny. Samozřejmou snahou je vyvíjet je rychleji, jednodušeji a za méně peněz. Proto se používají technologie, založené na tří-vrstvém modelu například Java 2 Platform, Enterprise Edition (J2EE). 1 Předchůdcem této technologie bylo OLE (Object Linking and Embedding) a COM bude pravděpodobně nahrazen technologií Microsoft.NET.

Distribuované vícevrstvé aplikace 3 Tato platforma rozšiřuje standardní Javu (J2SE Java 2 Platform, Standard Edition) o nástroje pro práci s vícevrstevnými aplikacemi třídy a rozhraní pro vývoj aplikace, aplikační server, webový server a databázový server pro běh těchto aplikací. J2EE poskytuje komponentový přístup k návrhu, vývoji a nasazení enterprise (podnikových) aplikací, což vede ke snížení nákladů na návrh a vývoj aplikace. J2EE nabízí vícevrstevný model distribuovaných aplikací, znovupoužitelných komponent, jednotný bezpečnostní model, flexibilní správu transakcí a podporu webových služeb. J2EE je navíc nezávislá na platformě (stejně jako Java samotná). 2.3 Distribuované vícevrstvé aplikace Platforma J2EE používá model distribuovaných mnohovrstevnatých aplikací. Aplikační logika je rozdělena podle funkcí na komponenty, různé komponenty tvořící aplikaci jsou instalovány na různých strojích (počítačích) podle toho, do které vrstvy komponenta patří. Na obrázku 2.1 jsou znázorněny dvě aplikace rozdělené do tří nebo čtyř vrstev. Obrázek 2.1: Vícevrstvé aplikace Klientská vrstva komponenty této vrstvy běží na klientském počítači. Webová vrstva komponenty běží na J2EE serveru. Business vrstva komponenty běží na J2EE serveru. Vrstva podnikového informačního systému (Enterprise IS - EIS) běh na EIS serveru. Tento tří- nebo čtyř-vrstevný model rozšiřuje klasický model klient/server, když vkládá více-vláknový aplikační server mezi klientskou aplikaci a úložiště dat.

Kontejnery v J2EE 4 2.4 J2EE komponenty J2EE aplikace je tvořena z komponent. Komponenta obsahuje potřebné třídy, rozhraní a další soubory; každá komponenta komunikuje s ostatními v dané aplikaci. Specifikace J2EE určuje 3 druhy komponent: Klient aplikace nebo applet běžící na klientském počítači. Java Servlet nebo JavaServer Pages (JSP) tyto komponenty běží na webovém serveru. Enterprise JavaBeans (EJB, enterprise beans) business komponenty, běží na serveru. J2EE komponenty jsou naprogramovány v jazyku Java a jsou překládány stejným způsobem jako jakýkoliv jiný program v Javě. Rozdíl mezi komponentami a normálními třídami je ten, že J2EE komponenty jsou sestaveny do aplikace, je ověřena jejich správnost podle J2EE specifikace a nakonec jsou nasazeny do výroby, kde jsou spouštěny a řízeny J2EE serverem. 2.5 JavaBeans Enterprise JavaBeans Existuje ještě technologie JavaBeans [JB], která ale s Enterprise JavaBeans nemá mnoho společného. JavaBeans je sice také komponentový architektura, ale komponenty zde hrají roli pouze při vývoji desktopové aplikace, nejsou instalovatelné do aplikačního serveru. Nejčastěji se JavaBeans používají při tvorbě grafického uživatelského rozhraní. JavaBeans komponenty jsou součástí prezentační vrstvy, zatímco EJB komponenty tvoří aplikační (business) vrstvu. 2.6 Kontejnery v J2EE Kontejner (jako součást J2EE) je rozhraní mezi komponentou a samotnou implementací aplikačního serveru (která se výrobce od výrobce liší). Předtím než může být komponenta spuštěna, musí být vložena (instalována) do kontejneru. Před vložením do kontejneru se nastaví pro každou komponentu její specifické vlastnosti i vlastnosti celé aplikace. Do těchto vlastností patří například nastavení zabezpečení a správy transakcí, nastavení jmenných a adresářových služeb (Java Naming and Directory Interface JNDI, viz [JNDI]) a nastavení vzdáleného připojení. Pro každý druh komponentové technologie (webová, EJB, klientská komponenta) existuje jeden kontejner. Na obrázku 2.2 je znázorněna architektura J2EE z pohledu kontejnerů. J2EE se skládá z těchto částí: J2EE server běhové prostředí J2EE. J2EE server se skládá z EJB a webového kontejneru. EJB kontejner má na starosti spouštění a běh EJB komponent J2EE aplikace. Webový kontejner řídí spouštění a běh JSP skriptů a servletů J2EE aplikace.

Architektura EJB (verze 2.1) 5 Kontejner aplikačního klienta řídí spouštění a běh komponent aplikačního klienta. Aplikační klienti a jejich kontejner běží na straně klientského počítače. Appletový kontejner Má na starosti spouštění a běh appletů. Skládá se z webového prohlížeče a z Java Plugin, obojí běží spolu na straně klientského počítače. Obrázek 2.2: Kontejnery v J2EE Kontejnery mají na starost i další (neovlivnitelné) vlastnosti. Je to například životní cyklus komponenty, sdílení připojení k databázi, perzistenci (stálost) dat a přístup k aplikačnímu rozhraní J2EE. 2.7 Architektura EJB (verze 2.1) EJB specifikace je jedno z aplikačních programových rozhraní (API) definovaných v J2EE. EJB komponenty poskytují funkce pro: Vzdálenou komunikaci s CORBA Perzistenci dat Transakční zpracování Souběžný přístup Práce s událostmi Jmenné a adresářové služby (JNDI) Bezpečnost EJB komponenty lze charakterizovat: EJB komponenta typicky obsahuje business (aplikační) logiku, která pracuje s nějakými (podnikovými enterprise) daty.

Architektura EJB (verze 2.1) 6 Instance EJB komponenty jsou vytvářeny a spravovány v době běhu (runtime) kontejnerem. EJB komponenta může být upravena v době tzv. nasazení (instalace do kontejneru) editací atributů prostředí. Atributy pro správu transakcí a bezpečnostní atributy jsou odděleny od zdrojového kódu třídy komponenty (ejb-class). To umožňuje tyto atributy upravovat ještě před nasazením komponenty do kontejneru. Přístup klienta ke komponentě je zprostředkován kontejnerem, ve kterém je komponenta nasazena. Mohou se vyskytovat specializované EJB kontejnery, poskytující nějaké nové služby navíc. EJB komponenta může být vložena do aplikace, aniž by bylo potřeba jejího zdrojového kódu nebo rekompilace. Obrázek 2.3: RMI - Remote Method Invocation Každá EJB komponenta obsahuje tzv. ejb-třídu (ejb-class), což je samotná implementace funkčnosti komponenty. Kontejner ji použije při vytvoření instance této komponenty. Dále EJB komponenty 2 obsahují dvě rozhraní home a remote. Rozhraní home slouží k vytváření, rušení a vyhledávání komponenty. Rozhraní remote je používáno klientem (klientskou aplikací, servletem nebo jinou EJB komponentou) pro přístup k business metodám. Tato rozhraní slouží jako zástupce (spojka) skutečné implementace. Klient volá metody zástupce, který pošle parametry serveru a ten pošle výsledek volání metody zpět klientovi. Toto se odehrává v rozhraní RMI (Remote Method Invocation), které slouží ke vzdálenému volání metod [RMI]. Na obrázku 2.3 je v levém obdélníku znázorněn klient, v pravém je server (zde představovaný kontejnerem viz. dále). Komunikace mezi nimi probíhá přes rozhraní RMI a JMS [JMS]. JMS (Java Message Service) je rozhraní asynchronní komunikace pomocí zpráv. 2 Kromě komponent typu message-driven beans. Ty jsou řízené zasíláním zpráv, proto tato rozhraní nepotřebují.

Architektura EJB (verze 2.1) 7 EJB komponenta může obsahovat tzv. lokální rozhraní. Ta jsou dvě a odpovídají rozhraním home a remote. Označují se local-home a local. Tyto rozhraní slouží k urychlení práce. Používají se od verze EJB 2.0 a jsou nepovinná (volitelná). Pokud klient (tím může být i jiná komponenta) běží ve stejném virtuálním stroji jako aplikační server, může se použít pro vytvoření instance komponenty rozhraní local-home. Poté se pro volání metod komponenty využívá rozhraní local. Při tomto volání se nevytváří spojky (stubs) a při volání metod se parametry předávají odkazem (při použití remote rozhraní se parametry předávají hodnotou posíláním zpráv, viz. obrázek 2.3). 2.7.1 EJB kontejner Do EJB kontejneru se vkládají EJB komponenty. Do jednoho kontejneru může být vloženo více komponent, tyto komponenty jsou v kontejneru spravovány spouštěny a řízeny. EJB kontejner může komponentu pasivovat (odložit do perzistentního úložiště) nebo naopak aktivovat. Kontejner může také spravovat perzistenci entitních komponent (viz dále) nebo řídit transakční zpracování. Kontejner je odpovědný za zpřístupnění home rozhraní skrz JNDI rozhraní. Díky tomu může klient vyhledat určitou komponentu pomocí jejího JNDI názvu. Na obrázku 2.4 je zobrazen EJB kontejner z pohledu klientské aplikace. EJB objekty jsou jednotlivé instance jedné komponenty. Obrázek 2.4: Pohled klienta na EJB kontejner 2.7.2 Druhy EJB komponent V EJB architektuře existují 3 druhy komponent. Session Beans (dočasné komponenty) mají relativně krátkou dobu života (proto dočasné) a představují nějakou akci. Entity Beans (entitní komponenty) poskytují objektový pohled na data (entity) z databáze. Message-Driven Beans (událostmi řízené komponenty) se spouští na základě přijetí zprávy od klienta. Stejně jako session beans představují nějakou akci.

Session beans 8 2.8 Struktura EJB komponenty EJB komponenta je distribuována v Java archívu. Uvnitř archívu jsou třídy komponenty (rozhraní home, remote, ejb-class,... ) a adresář META-INF, který musí obsahovat manifest (soubor MANIFEST.MF) a soubor ejb-jar.xml, neboli deployment descriptor. Tento soubor obsahuje informace o komponentě a lze díky němu upravit specifické vlastnosti komponenty bez nutnosti rekompilace tříd komponenty. Takto uložená komponenta může být nasazena na jakýkoliv aplikační server, který podporuje technologii EJB. Informace nutné pro běh na konkrétním aplikačním serveru se uloží do adresáře META-INF. Například pro kontejner serveru JBoss je to jboss.xml, pro server firmy Sun je to sun-ejb-jar.xml. Tyto soubory většinou obsahují názvy komponent, které jsou uloženy v archívu a jejich JNDI názvy. 2.8.1 Deployment Descriptor Deployment Descriptor je soubor, ve kterém jsou v XML formátu uloženy informace o EJB komponentě. Některé z těchto informací se mohou měnit a tím se částečně mění i funkčnost komponenty. Lze například změnit práva pro přístup ke komponentě nebo jejím metodám. Ostatní informace mají informativní charakter. Z deployment descriptoru lze zjistit typ komponenty, jaké další komponenty jsou vyžadovány nebo jakým způsobem je řešeno spojení s databází (u entitních komponent). 2.9 Session beans Tyto komponenty slouží k zapouzdření aplikační (business) logiky. Třída této komponenty musí implementovat rozhraní javax.ejb.sessionbean. Pro správu instancí SB (session beans) kontejnerem je velmi důležité, zda si instance udržuje vlastní stav zpracování nebo ne. Tato informace je uložena v deployment descriptoru. V zásadě platí, že stavové komponenty jsou skutečně vytvářeny pro každého klienta zvlášť (vztah 1:1), zatímco bezstavové komponenty mohou být sdíleny více klienty (tzv. pooling), jedna bezstavová komponenta může tedy obsluhovat několik klientů. Stavové komponenty mohou být v určitém stavu uloženy do perzistentního úložiště, odkud mohou být opět načteny. Pokud je instance session bean komponenty využívána delší dobu, může být pasivována, tj. dočasně uložena do perzistentního úložiště. Tím může kontejner ušetřit paměť. Jestliže přijde do kontejneru požadavek na uloženou komponentu, kontjener ji aktivuje (obnoví). Před těmito činnostmi jsou volány metody komponenty ejbpassivate() a ejbactivate(). Do těchto metod lze napsat ošetření dat, která nemohou být uložena (například připojení k databázi). Obě metody jsou součástí i entitních komponent.

Message-driven beans 9 2.10 Entity beans Entitní komponenta reprezentuje objektově orientovaný pohled na libovolnou entitu uloženou v perzistentním (trvalém) úložišti (v relační databázi) nebo na entitu implementovanou v existující podnikové aplikaci. Doba života těchto komponent je dána existencí odpovídajících záznamů (entit) v databázi. Po celou dobu své existence se tyto komponenty nachází v prostředí kontejneru, který pro ně zajišťuje bezpečnost, řízení souběžného přístupu, transakcí, perzistence a další služby. Třída entitní komponenty musí implementovat rozhraní javax.ejb.entitybean. V této třídě musí být implementovány metody ejbcreate (vytvoří novou instanci), ejbpostcreate (zde se určí další vlastnosti instance, například primární a cizí klíč), ejbactivate, ejbpassivate, ejbremove (odstranění dat z databáze), ejbload a ejbstore (synchronizace instance s její perzistentní podobou), ejbfind (vyhledání instance). 2.10.1 Container Managed Persistence Perzistence dat entitních komponent může být zajištěna buď kontejnerem nebo vývojářem komponenty (ve zdrojovém kódu komponenty). Pokud je perzistence řízena kontejnerem, vývojář komponenty se nemusí starat o připojení k databázi, pouze se v deployment descriptoru určí namapování dat z databáze do entitní komponenty a o ostatní se postará EJB kontejner. Dále se u tohoto druhu komponent vytváří tzv. abstraktní schéma perzistence, které určuje vztahy s ostatními entitními komponentami. Abstraktní schéma je také uloženo v deployment descriptoru. 2.10.2 Bean Managed Persistence Perzistence těchto komponent je zajištěna autorem komponenty ve zdrojovém kódu komponenty (ve třídě ejb-class). Vývojář je tedy plně odpovědný za připojení k databázi (například použitím JDBC) a přístup k datům, který implementuje v metodách ejbcreate, ejbremove, ejbfind, ejbload a ejbstore a případně i v business metodách třídy komponenty. 2.11 Message-driven beans Tyto komponenty jsou novinkou v EJB architektuře od verze 2.0. Jsou to komponenty řízené (aktivované) zprávami. Proto tyto beany nemají vzdálené ani home rozhraní, veškerá komunikace probíhá díky JMS systému pro zasílání zpráv. Message-driven komponenta je konzumentem zpráv, klient jí zprávy zasílá. Všechny instance jedné message-driven komponenty jsou ekvivalentní, a proto příchozí požadavek klienta může být zpracován libovolnou instancí. Třída messagedriven komponenty musí implementovat rozhraní javax.ejb.messagedrivenbean.

10 Kapitola 3 ENT meta-model ENT meta-model je komponentní model, který definoval P.Brada v [BR03] ([BR04]). Komponentní model [BR04] definuje, mimo jiné, druhy struktur, které jsou viditelné na rozhraní komponenty a jejich konkrétní syntaxi. Komponentní modely jsou implementovány v komponentních rámcích (frameworks); příkladem takového rámce je třeba CORBA nebo EJB. Komponentní meta-model definuje slovník a struktury, ze kterých jsou odvozeny schopnosti konkrétního komponentního modelu. Některé meta-modely jsou tvořeny na zelené louce, jiné vznikly odvozením z běžných částí už existujících komponentních modelů. 3.1 Podobnosti v současných komponentních modelech Jak už bylo zmíněno, existuje více komponentních modelů (CORBA, COM, EJB). A každý z těchto modelů používá jiná pojmenování pro víceméně stejné (nebo podobné) pojmy. Specifikace daného rozhraní komponenty se skládá z prvků (elementů), které definují schopnosti komponenty přístupné zvenku. Většina těchto prvků je jednoznačně pojmenována (v rozsahu rozhraní komponenty) a mohou být rozlišeny podle mnoha charakteristik (vlastností). Elementy můžeme rozlišovat například podle toho, zda reprezentují data nebo funkcionalitu, zda je element ve formě jedné položky nebo struktury nebo zda je element konstantou, instancí nebo typem. Elementy lze také rozlišit podle toho, v jaké části životního cyklu komponenty jsou používány. 3.2 Klasifikační systém Nalezené charakteristiky můžeme formalizovat do klasifikačního systému. Objekt se klasifikuje tzv. ENT klasifikátorem, což je uspořádaná osmice (nature,

Kategorie rysů 11 kind, role, granularity, construct, presence, arity, lifecycle), kde každý prvek reprezentuje podmnožinu (většinou jedno-prvkovou) jemu odpovídající množiny. Tyto množiny jsou vytvořeny z nalezených charakteristik: N ature = {syntax, semantics, nonf unctional}, Kind = {operational, data}, Role = {provided, required, neutral}, Granularity = {item, structure, compound}, Construct = {constant, instance, type}, P resence = {mandatory, permanent, optional}, Arity = {single, multiple}, Lif ecycle = {development, assembly, deployment, setup, runtime} Z klasifikátoru lze tedy celkem jasně poznat význam a postavení klasifikovaného prvku v rozhraní komponenty. Tento klasifikační systém postačuje na většinu komponentních modelů, je však možné ho pro určitý model rozšířit nebo zúžit. Více v [BR03] a [BR04]. 3.3 Traits (charakteristické rysy) Aby mohl být komponentní model bližší lidskému vnímání, zavedeme tzv. charakteristické rysy komponenty (traits [BR04]). Rys je definován uspořádanou čtveřicí (název, metatyp, klasifikátor, množina hodnot), kde název je názvem charakteristického rysu (traitu), metatyp je nadtyp všech prvků tohoto rysu (traitu), klasifikátor je uspořádaná n-tice, tvořená prvky množin z charakteristik definovaných v předcházející části. Množina hodnot je množina všech povolených hodnot rysu. Informace o meta-typu a o klasifikátoru jsou zjištěny z dřívější analýzy nebo z návrhu konkrétního komponentního modelu. Účelem je vytvořit kompletní, ale minimální množinu meta-typů a klasifikátorů, která může spolehlivě rozlišit požadované charakteristické rysy prvků. 3.4 Kategorie rysů Různé rysy lze dále třídit do kategorií (category sets). Tímto tříděním lze ještě lépe zpřehlednit komponentní model. Můžeme například vytvořit dvě kategorie, kde do jedné kategorie se zařadí prvky s nějakou funkcionalitou a do druhé kategorie se zařadí prvky s datovým významem. ENT meta model je založen na roztřídění částí komponentního modelu do těchto tří kategorií podle charakteristiky Role. Komponenta obsahuje elementy, které komponenta: Poskytuje (Exports, role ={provided}), Vyžaduje (Needs, role ={required})

ENT meta model EJB komponent 12 Vyžaduje i poskytuje (Ties, role ={provided, required}) A právě z počátečních písmen anglických názvů těchto kategorií je složen název ENT meta modelu (Exports-Needs-Ties). Analogii tohoto dělení lze vidět ve funkcích v programovacích jazycích funkce poskytuje nějaký výstup (Exports), požaduje nějaké parametry (Needs) a některé parametry mohou být současně výstupními parametry (Ties, například ukládání výsledků do parametrů typu ukazatel). Díky tomuto rozdělení se tedy lze dívat na komponenty jako na funkce, což může být užitečné právě při porovnávání komponent. 3.5 ENT meta model EJB komponent V této části bude specifikován komponentní model Enterprise JavaBeans na základě dělení do kategorií Exports, Needs a Ties (ENT). Podrobnější informace o tomto modelu viz [BR04]. Tagy (tags) jsou určeny názvem a množinou povolených hodnot, odkazy na zdroje odkazují na zdrojový kód komponenty (deployment descriptor nebo třídu), kde je trait nebo tag definován. 3.5.1 Typy komponent Meta-model Enterprise JavaBeans definuje tři typy komponent: SessionBean, EntityBean a MessageDrivenBean. Pro stručnost jejich definicí se deklarují následující dvě množiny definic tagů a traitů, společných všem typům: tagset common = security id traitset common = T provided T required, kde T provided = { business interfaces, home interfaces, security roles} a T required = { business references, msg destination references, web service ref erences, home ref erences, env entries, resource managers, resource env ref erences, timer service} SessionBean tags: tagset common {state, transaction} definice množiny rysů: traitset common { web service endpoint} EntityBean tags: tagset common {persistence, reentrancy, schema} definice množiny rysů: traitset common {attributes} MessageDrivenBean tags: tagset common {transaction, msg type} definice množiny rysů: traitset common { message consumed, msg activation}

ENT meta model EJB komponent 13 3.5.2 Tags (značky) msg type= Identif iers, standardně javax.jms.messagelistener Java rozhraní (interface) pro příjem zpráv. Zdroj: deployment descriptor (element message type). persistence = {container, bean}, standardně ɛ (pouze u entitních komponent) Zdroj: deployment descriptor (element persistence). reentrancy = {reentrant, non reentrant}, standardně reentrant Mód reentrance (znovu-vstoupení). Zdroj: deployment descriptor (element reentrant). schema = Identif iers, standardně ɛ Název abstraktního schématu. Užívá se pouze, když persistence = container. Zdroj: deployment descriptor (element abstract-schema-name). security id = {use caller, run as}, standardně use caller Jakou totožnost použít pro ověření. Zdroj: deployment descriptor (element security-identity). state = {statef ul, stateless}, standardně ɛ Způsob chování Session Bean komponenty (stavová nebo bezstavová). Zdroj: deployment descriptor (element session-type). transaction = {container, bean}, standardně ɛ Správce transakcí (kontejner nebo komponenta). Zdroj: deployment descriptor (element transaction-type). 3.5.3 Traits (rysy) attributes perzistentní data entitní komponenty. meta-typ = attribute klasifikátor = ({syntax}, {data}, {provided}, {item}, {instance}, {permanent}, {multiple}, Lifecycle) tags: status = {normal, primary key} Pozn.: Zdroj: deployment descriptor pro CMP entitní komponenty (elementy cmp field a primkey field). business interfaces základní funkcionalita komponenty. meta-typ = interf ace klasifikátor = ({syntax}, {operational}, {provided}, {structure}, {type}, {mandatory}, {multiple}, {development, assembly, deployment, runtime}) tags: locality = {local, remote} Pozn.: Zdroj: deployment descriptor (elementy remote a local), zdrojový kód. business references rozhraní použitých komponent v dané komponentě. meta-typ = interf ace klasifikátor = ({syntax}, {operational}, {required}, {structure}, {instance},

ENT meta model EJB komponent 14 {permanent}, {single}, Lifecycle) tags: locality = {local, remote} Pozn.: Zdroj: deployment descriptor (části elementů ejb-ref a ejb-local-ref). env entries proměnné prostředí, které komponenta vyžaduje. meta-typ = structure env entry type klasifikátor = ({syntax}, {data}, {required}, {item}, {instance}, {permanent}, {single}, Lifecycle) tags: Pozn.: Zdroj: deployment descriptor (element env-entry), typem proměnné musí být primitivní datový typ (například java.lang.integer). home interfaces správa životního cyklu komponenty. meta-typ = interf ace klasifikátor = ({syntax}, {operational}, {provided}, {structure}, {type}, {mandatory}, {multiple}, {development, assembly, deployment, setup}) tags: locality = {local, remote} Pozn.: Zdroj: deployment descriptor (elementy home a local-home). Přestože rozhraní typu home mohou být použity v době běhu programu (run-time), jejich nejdůležitější role je v době nastavení (set-up). home references přístup ke komponentám, které komponenta používá. meta-typ = interf ace klasifikátor = ({syntax}, {operational}, {required}, {structure}, {instance}, {permanent}, {single}, {development, assembly, deployment, setup}) tags: locality = {local, remote} bean = Identifiers Pozn.: Zdroj: deployment descriptor (elementy ejb-ref a ejb-local-ref). msg activation komunikační aktivační vlastnosti komponent typu messagedriven. meta-typ = map klasifikátor = ({syntax}, {data}, {provided}, {item}, {instance}, {permanent}, {multiple}, {development, deployment}) tags: Pozn.: Zdroj: deployment descriptor (element activation-config-property). msg consumed názvy tříd zpráv, které komponenta přijímá. meta-typ = class klasifikátor = ({syntax}, {operational}, {provided}, {item}, {instance}, {permanent}, {multiple}, {development, assembly, runtime}) tags: Pozn.: Zdroj: Zdrojový kód (implementace metody onmessage()). msg destination references cíle komunikace pomocí zpráv. meta-typ = structure msg destination ref type klasifikátor = ({syntax}, {data}, {required}, {item}, {instance}, {permanent}, {single}, Lifecycle}) tags: Pozn.: Zdroj: deployment descriptor (element message-destination-ref).

ENT meta model EJB komponent 15 resource env references odkazy na potřebné zdroje. meta-typ = map klasifikátor = ({syntax}, {data}, {required}, {item}, {instance}, {permanent}, {single}, {development, deployment, setup, runtime}) tags: Pozn.: Zdroj: deployment descriptor (element resource-env-ref). resource managers správci zdrojových prostředků. meta-typ = map klasifikátor = ({syntax}, {operational}, {required}, {structure}, {instance}, {permanent}, {single}, {development, deployment, setup, runtime}) tags: sharing = {shareable, unshareable} authentication = {application, container} Pozn.: Zdroj: deployment descriptor (element env-entry), typem proměnné musí být primitivní datový typ (například java.lang.integer). security roles bezpečnostní role spojené s business rozhraními. meta-typ = Identif iers klasifikátor = ({nonfunctional}, {operational}, {provided}, {item}, {constant}, {permanent}, {na}, {assembly, deployment}) tags: Pozn.: Zdroj: deployment descriptor (element security-role-ref). timer service reakce na časové události. meta-typ = interf ace klasifikátor = ({syntax}, {operational}, {required}, {structure}, {type}, {permanent}, {single}, {development, setup, runtime}) tags: Pozn.: Zdroj: Zdrojový kód. web service endpoint přístup k funkcionalitě pomocí webových služeb. meta-typ = interface sei klasifikátor = ({syntax}, {operational}, {provided}, {structure}, {type}, {permanent}, {multiple}, {development, assembly, deployment, runtime}) tags: Pozn.: Zdroj: deployment descriptor (element service-endpoint), pouze u bezstavových (stateless) komponent typu session bean. web service references odkazy na používané webové služby. meta-typ = structure service ref group klasifikátor = ({syntax}, {operational}, {required}, {structure}, {instance}, {permanent}, {multiple}, {development, deployment, setup, runtime}) tags: Pozn.: Zdroj: deployment descriptor (element service-ref). 3.5.4 Příklad jednoduché EJB komponenty Následuje příklad jednoduché session komponenty. Zde je uveden deployment descriptor komponenty Fyzika2, která používá další komponentu Matematika2

ENT meta model EJB komponent 16 (viz element ejb-ref): <enterprise-beans> <session> <ejb-name>fyzika2</ejb-name> <home>fyzika2.interfaces.fyzika2home</home> <remote>fyzika2.interfaces.fyzika2</remote> <ejb-class>fyzika2.ejb.fyzika2session</ejb-class> <session-type>stateless</session-type> <transaction-type>container</transaction-type> <ejb-ref> <ejb-ref-name>matematika2</ejb-ref-name> <ejb-ref-type>session</ejb-ref-type> <home>matematika2.interfaces.matematika2home</home> <remote>matematika2.interfaces.matematika2</remote> <ejb-link>matematika2</ejb-link> </ejb-ref> </session>... </enterprise-beans> Značky (tags): state = stateless, transaction = container Rysy (traits): business interfaces = {(ɛ, f yzika2.interf aces.f yzika2, {(locality, remote)}, ;)} home interfaces = {(ɛ, f yzika2.interf aces.f yzika2home, {(locality, remote)}, ;)} business references = {(M atematika2, matematika2.interf aces. Matematika2, {(locality, remote)}, ;)} home references = {(M atematika2, matematika2.interf aces. Matematika2Home, {(locality, remote)}, ;)}

17 Kapitola 4 Nahraditelnost komponent Objekt je nahraditelný jiným objektem, pokud po nahrazení nedojde ke změně funkčnosti systému, ve kterém docházi k nahrazení. Na nový objekt, který má nahradit původní, můžeme klást různě přísná omezení. Podle toho rozlišujeme několik druhů nahraditelnosti striktní (podtypová), kontextová nebo částečná [BR03]. Definice nahraditelnosti, ve které jsou zahrnuty pouze komponenty, které se přímo účastní nahrazení [WZ88]: Nahrazující komponenta (která je podtypem původní) by měla být použitelná všude, kde je očekávaná původní komponenta (která je nadtypem nahrazující), bez toho, že si klient všimne změny. Úkolem této práce bylo porovnání pouze na základě znalostí obou komponent, bez jejich dalšího kontextu. K dispozici máme pouze obě komponenty a nic jiného. Budeme tedy vyžadovat pouze striktní (podtypovou) nahraditelnost, kde nás okolí (kontext) komponenty nezajímá. 4.1 Druhy rozdílů Pro zjištění možnosti nahraditelnosti musíme komponenty porovnat. Výsledkem porovnání (nejen komponent) je nalezený rozdíl (pokud nějaký je). V [BR03] byla vytvořena množina druhů rozdílů Dif f erences. Do této množiny jsem pro větší odlišení přidal navíc tři druhy Insertion, Deletion a U nknown. Differences = {None, Insertion, Specialization, Deletion, Generalization, Mutation, Unknown} Rozdílem dvou objektů je pak prvek množiny Dif f erencies, který je generován funkcí diff: diff(σ 1, σ 2 ) = none, pokud σ 1 = σ 2. (žádný rozdíl) diff(σ 1, σ 2 ) = insertion, pokud σ 1 není definován a σ 2 je. (vložení) diff(σ 1, σ 2 ) = specialization, pokud σ 2 rozšiřuje vlastnosti σ 1 (σ 2 je podtypem σ 1 ). (specializace)

Podtypování 18 diff(σ 1, σ 2 ) = deletion, pokud σ 2 není definován a σ 1 je (smazání). diff(σ 1, σ 2 ) = generalization, pokud σ 1 rozšiřuje vlastnosi σ 2 (σ 1 je podtypem σ 2 ). (generalizace) diff(σ 1, σ 2 ) = mutation, pokud porovnání obsahuje příznaky specializace (nebo vložení) i generalizace (nebo smazání). (mutace) diff(σ 1, σ 2 ) = unknown, pokud nelze objekty porovnat (například u rekurzivních datových typů (viz. dále). (neznámý rozdíl). 4.2 Striktní nahraditelnost Nahrazující komponenta (C r ) může nahradit stávající (původní) komponentu (C c ), pokud její rozhraní poskytuje stejnou nebou rozšířenou funkčnost a požaduje stejné nebo obecnější vstupy. Přesná definice striktní nahraditelnosti je v [BR03]. Striktní nahraditelnost můžeme vyjádřit pomocí ENT meta-modelu (podle [BR03], s přidáním nových druhů rozdílů): Nahrazující komponenta s reprezentací ENT C r = {E r, N r, T r } je striktní náhradou za současnou komponentu C c = {E c, N c, T c }, pokud diff(e c, E r ) = {none, insertion, specialization}, diff(n c, N r ) = {none, deletion, generalization} a diff(t c /A, T r /A) = {none, insertion, specialization}. 4.3 Podtypování Podtypování je nejčastěji definováno zákonem nahraditelnosti Barbary Liskovové (Liskov Substitutability Principle) [LI88]: To co je požadováno, je něco jako následující vlastnost nahrazení: jestliže pro každý objekt o 1 typu S existuje objekt o 2 typu T takový, že v každém programu P s výskytem typu T se chování P při nahrazení o 2 objektem o 1 nezmění, pak S je podtypem T. Relace podtypování se značí S <: T (S je podtypem T ). Tento vztah můžeme vyjádřit i pomocí funkce diff: diff(s, T ) = generalization. Toto je pouze jedna z mnoha definic podtypování. Většina však ztotožňuje podtypování s nahrazením, to znamená že pokud a je podtypem b, a může b také kdykoliv nahradit.

Podtypování 19 4.3.1 Rozšíření funkčnosti Pokud máme dvě třídy (objektové typy) S a T, kdy S má všechny atributy i funkce stejné jako T a navíc obsahuje libovolný počet nových metod či atributů, pak S je podtypem T. Jinak řečeno S obsahuje novou funkčnost a zároveň poskytuje stejnou funkčnost jako třída T. Pokud tedy bude třída S použita v programu, který původně očekával na jejím místě původní třídu T, program bude bez problémů přeložen a navenek nepůjde poznat, že se jedná o novější třídu. Třída S tedy může nahradit třídu T. 4.3.2 Podtypování funkcí Mějme dvě funkce stejného jména (například foo). Původní (první) funkce měla předpis R 1 foo(p 1 ), nahrazující (druhá) funkce má předpis R 2 foo(p 2 ), kde R i je návratový typ funkce a P i je typ parametru funkce. Návratové typy Funkce foo je volána na nějakém místě v nějakém programu s parametry typu P 1 a poskytuje výsledek návratového typu R 1. Výsledek funkce se v programu ukládá do proměnné typu R 1. Aby tedy druhá funkce mohla nahradit funkci první, musí být z návratového typu druhé funkce možné odvodit objekt třídy R 1. A to lze jen tehdy, pokud R 2 <: R 1 (v objektových jazycích může potomek nahradit svého rodiče, ale opačně to nejde, proto R 2 je potomkem R 1 ). Kdyby například program očekával jako výsledek třídu se dvěma atributy (veřejnými, například souřadnice x, y) a nová funkce by poskytovala výsledek pouze s jedním atributem, který je stejný jako jeden ze dvou atributů původního návratového typu (například x), došlo by ke ztrátě informace (nemáme informace o očekávané souřadnici y), proto by nová funkce nemohla nahradit funkci původní. Pro návratové typy funkcí tedy platí, že nová funkce musí poskytovat buď výsledek stejného typu jako původní funkce nebo výsledek se stejnými informacemi a nějakými informacemi navíc (výsledek s přidanou hodnotou ). Této vlastnosti se říká kovariance. Návratové typy funkcí jsou tedy kovariantní. Argumenty Opačné je to ale u argumentů funkcí. Nová funkce nesmí mít větší nároky na argumenty (vstupy) než původní funkce. V místě volání jsou totiž funkci předávány argumenty původního typu. Pokud by nová funkce požadovala argument typu s přidanou hodnotou navíc, nešlo by nový typ změnit přetypováním. Této vlastnosti se říká kontravariance. Typy argumentů funkcí jsou kontravariantní. 4.3.3 Podtypování atributů Všechny společné veřejně přístupné atributy obou tříd (původní i nové) musí být stejných typů. Veřejné atributy totiž mohou být čteny (podobnost s návratovým typem funkce), zároveň však do nich může být zapisováno (podobnost s argumenty funkcí). Jedině stejné typy jsou svými nadtypy i podtypy. Jestliže typy atributů budou různé, není možné rozhodnout, zda mezi nimi platí relace

Podtypování 20 podtypování nebo nadtypování. Při porovnání těchto dvou atributů by funkce dif f vrátila hodnotu mutation (mutace). Atributy jsou tedy invariantní. Více o podtypování v [SI02] a v [SI03].

21 Kapitola 5 Použité technologie V této kapitole se budu věnovat technologiím, které jsem se rozhodl využít při psaní programu. Objasním důvody pro výběr programovacího jazyka a vývojového prostředí. 5.1 Programovací jazyk Protože komponenty se mají porovnávat přímo tak, jak jsou distribuovány (v tzv. Java archívu), nebudeme mít k dispozici zdrojový kód komponenty. K práci s přeloženým kódem Javy (tzv. byte-kód) existují v programovacím jazyku Java pomocné třídy, které tuto práci významně zjednodušují. Například pro načtení Java-archívu existuje třída JarFile, pro načtení informací o přeložené třídě existují třída ClassLoader a Class. Tyto třídy umožňují tzv. introspekci. Díky těmto okolnostem jsem pro implementaci porovnání EJB komponent zvolil programovací jazyk Java (J2SE verze 1.4.2 a platformu J2EE 1.4). 5.2 Vývojové prostředí Program jsem vytvářel ve vývojovém prostředí Eclipse 3.0 [Ecl]. Toto prostředí jsem zvolil pro jeho výbornou správu zdrojových kódů (refactoring, doplňování kódu, atd.) a pro zabudovanou podporu nástroje pro kompilaci v Javě programu Apache Ant [ANT]. Tento program je obdobou programu make, používaného pro kompilaci programů v jazyce C. Místo souboru Makefile se vytvoří soubor build.xml (standardně) a do něj se zapisují ve formátu XML úkoly, které má Ant provádět. Pomocí tohoto nástroje lze jednoduše vytvářet adresáře, kopírovat soubory, vytvářet JAR-soubory a samozřejmě kompilovat. Následuje příklad cíle programu Ant, který přeloží všechny zdrojové soubory z adresáře daném proměnnou src, uloží je do adresáře build a při kompilaci se použijí externí třídy uložené v adresáři j2eedir. Tento cíl compile závisí na jiném cíli init, který se automaticky provede před provedením compile. Soubory typu buildfile jsou díky XML dobře čitelné, narozdíl od souborů typu Makefile.

Načtení komponenty 22 <target name="compile" depends="init" description="kompilace"> <javac srcdir="${src}" destdir="${build}" classpath="${j2eedir}"/> </target> 5.3 Načtení komponenty V následujících odstavcích stručně popíšu třídy nebo rozhraní, která jsem použil pro načtení EJB komponenty. 5.3.1 Třída JarFile EJB komponenty jsou distribuovány v jednom balíku, což je Java-archív, ve kterém jsou uloženy potřebné třídy, adresář META-INF a případně další potřebné soubory. K načtení Java-archívu (JAR) jsem využil třídu java.util.jar.jar- File. 5.3.2 Document Object Model Pro načtení deployment descriptoru, který je XML dokumentem, jsem použil třídy a rozhraní implementující Document Object Model. DocumentBuilder Třída javax.xml.parsers.documentbuilder poskytuje metody pro rozpoznání elementů v XML dokumentu (tzv. parsování). Instance této třídy se vytváří ve třídě javax.xml.parsers.documentbuilderfactory. Document Rozhraní org.w3c.document reprezentuje XML dokument, načtený (parsovaný) metodou parse() ve třídě DocumentBuilder. Document poskytuje metody pro přístup ke všem elementům XML dokumentu. Obsahuje metodu getdocument- Element(), která vrací kořenový element (rozhraní org.w3c.dom.element). Rozhraní Document i Element jsou potomky rozhraní Node. Toto rozhraní představuje jeden uzel stromu dokumentu. Následuje ukázka načtení XML souboru. V příkladu je cesta k souboru uložena v proměnné path. Třída DocumentBuilderFactory slouží k vytvoření instance třídy DocumentBuilder a je ze stejného balíku. File f = new File(path); Document doc = null; DocumentBuilderFactory factory=documentbuilderfactory.newinstance(); try { DocumentBuilder builder = factory.newdocumentbuilder(); doc = builder.parse(f); } catch (...

J2EE server 23 5.4 Introspekce Programovací jazyk Java umožňuje tzv. introspekci. To znamená, že objekt může díky introspekci získat informace o sobě, třídě, ze které je vytvořen nebo o své rodičovské třídě. Následuje stručný popis tříd, poskytujících funkce pro introspekci. 5.4.1 Třída ClassLoader Objekt třídy java.lang.classloader slouží k načítání tříd. Umožňuje načíst třídu ze souboru nebo z jakéhokoliv proudu bytů (zdrojem může být například jiná aplikace nebo proud bytů přijatý z Internetu). 5.4.2 Třída Class Výsledkem načtení třídy je instance třídy java.lang.class. Každý objekt v běžící Java aplikaci obsahuje odkaz na svou třídu (přesněji na instanci třídy Class, obsahující informace o dané třídě). Primitivní datové typy (boolean, byte, int,... ) a klíčové slovo void jsou také reprezentovány jako instance třídy Class. Z instance třídy Class lze zjistit veškeré informace všechny atributy (nejen globální (public)), metody, konstruktory, vnitřní třídy i instanci třídy ClassLoader, která danou třídu načetla. 5.4.3 Třída Field Tato třída (java.lang.field) poskytuje informace o atributu dané třídy to znamená lze zjistit jméno atributu a jeho typ (třídu). 5.4.4 Třída Method Třída java.lang.method umožňuje získat informace o dané metodě. V instanci této třídy jsou uloženy informace o návratovém typu (třídě) metody, o všech argumentech (typech argumentů), o všech výjimkách, které metoda propaguje a samozřejmě také o názvu metody. 5.4.5 Třída Constructor Tato třída (java.lang.constructor) zapouzdřuje informace o daném konstruktoru. Z instance této třídy lze zjistit (podobně jako u třídy Method) typy argumentů a výjimky, které konstruktor propaguje. Třídy Field, Method a Constructor mají společného předka třídu java.lang.accessibleobject. Tato třída umožňuje nastavit přístupnost k danému objektu (atributu, metodě nebo konstruktoru). 5.5 J2EE server Pro vyzkoušení porovnávaných komponent jsem zvolil dva aplikační servery JBoss (verze 4.0) [JBOS] a server firmy Sun Sun Java TM System Application

J2EE server 24 Server Platform Edition 8. Oba dva používají J2EE verze 1.4. Servery jsem provozoval v prostředí operačního systému Windows XP. Tvorba komponent (vytvoření balíku s deployment descriptorem) pro server firmy Sun probíhá v grafickém uživatelském prostředí, čímž je na první pohled jednodušší. Komponenty pro server JBoss jsem vytvářel pomocí nástroje XDoclet [XDOC], který umožňuje automaticky vytvořit deployment descriptor (a další XML soubory) z informací (atributů), získaných ze zdrojového kódu třídy komponenty (rozhraní home a remote). Tyto informace se zapisují ve speciálním formátu do komentářů tříd (rozhraní), atributů a metod. Programátor se tedy může soustředit pouze na funkcionalitu komponenty. Navíc existuje plugin do prostředí Eclipse (JBoss Eclipse IDE), který umožňuje s pomocí XDoclet vytvářet komponenty pro aplikační server JBoss. Tento plugin navíc umožňuje vytvořit balík (JAR soubor), do kterého komponentu uloží ve správném formátu. J2EE servery jsou velmi náročné na operační paměť (ostatně jako většina Java aplikací). Můj počítač je bohužel vybaven pouhými 256 MB operační paměti, proto jsem se během spuštění aplikačního serveru setkal s častým odkládáním obsahu paměti na pevný disk (tzv. swapping). Jestliže jsem měl spuštěný navíc prostředí Eclipse, běh aplikací se zpomalil na neúnosnou míru.

25 Kapitola 6 Implementace Program, který jsem vytvořil, se nazývá BeanComparator. Může se používat buď z příkazového řádku nebo v jiném Javovském programu, pro který poskytuje potřebné aplikační rozhraní (výsledky porovnání se ukládají do instance třídy BeanDifferences). V následujících kapitolách popíšu jednotlivé kroky, vedoucí k dokončení implementace porovnání komponent. Nejdůležitějším z nich je nalezení podtypových relací mezi třídami v Javě a mezi rysy ENT meta-modelu. Dále jsem musel načíst informace o EJB komponentách do datových struktur (tříd) a na závěr jsem musel porovnat jednotlivé části (tagy a rysy) komponent. 6.1 Podtypové relace tříd v Javě Protože třídy (rozhraní) jsou nejdůležitější součástí EJB komponenty (home, remote rozhraní, reference na jiné komponenty, atd. (viz. ENT meta-model)), musel jsem vytvořit porovnávač tříd a datových typů. Datové typy v Javě se dělí na dva druhy primitivní datové typy a standardní Java třídy (potomci třídy Object). 6.1.1 Primitivní datové typy V jazyku Java je definováno osm primitivních datových typů (tabulka 6.1). Ty se dělí na tři druhy celočíselné, s plovoucí desetinnou čárkou a typ boolean. Typ Počet bitů Znaménkový Druh boolean?? boolean byte 8 ano celočíselný short 16 ano celočíselný int 32 ano celočíselný long 64 ano celočíselný char 16 ne celočíselný float 32 ano desetinný double 64 ano desetinný Tabulka 6.1: Primitivní datové typy v Javě

Podtypové relace tříd v Javě 26 Typ boolean nabývá dvou hodnot true a false. Proměnné typu boolean lze přiřadit explicitním přetypováním jakoukoliv číselnou hodnotu. Pak nulová hodnota znamená hodnotu false a libovolné nenulové číslo odpovídá hodnotě true. Pokud bychom přetypovali instanci třídy Object (nebo jakéhokoli potomky této třídy), hodnota null by odpovídala hodnotě false a jakákoliv jiná hodnota než null by odpovídala hodnotě true. Typ boolean by tedy mohl být jakýmsi nadtypem všech ostatních typů. Jenže v Javě je povoleno pouze implicitní přetypování typu boolean na sebe sama, proto je typ boolean mimo hierarchii podtypování. (boolean : jiny typ) (jiny typ : boolean), kde jiny typ je jakýkoliv typ jiný než boolean. (Boolean není podtypem ani nadtypem žádného jiného typu. Nebo také diff( boolean, jiny typ) = mutation) Z celočíselných znaménkových typů (byte, short, int a long) už lze podtypovou hierarchii vytvořit. Pokud by program (klient) očekával na nějakém místě typ long, a my bychom chtěli tento typ nahradit jeho podtypem, klient nesmí poznat změnu. Nesmí dojít ke ztrátě informace (musí být povolená implicitní konverze), proto typ long může být nahrazen typem (podtypem) int (nebo short, byte). Tímto způsobem bychom mohli dále pokračovat pro hledání podtypu typu int a short. byte <: short <: int <: long Typ char je jediným neznaménkovým typem. Je šestnácti-bitový, tvoří tedy horní polovinu (čísla větší než 0) 32-bitového typu int. Konverze z typu int na typ char tedy proběhne bez ztráty informace (implicitní typová konverze je povolena). char <: int <: long Primitivní datové typy s plovoucí desetinnou čárkou (floating point) jsou v Javě dva float a double. Typ float je podtypem typu double. float <: double Protože při konverzi celočíselného typu na typ desetinný (s plovoucí desetinnou čárkou) může dojít ke ztrátě přesnosti, neexistuje žádná další podtypová relace mezi těmito a ostatními typy. 6.1.2 Klíčové slovo void Klíčové slovo void označuje prázdný nebo žádný datový typ. Používá se pouze pro označení metody, která nevrací žádnou hodnotu (obdoba tzv. procedury v jazyce Pascal). Při introspekci metody, která vrací typ void, příslušná metoda třídy Class vrátí instanci třídy Class, která má název void. Void lze tedy v těchto případech považovat za datový typ. Pro porovnání typu void jsem zavedl pravidla (druhy rozdílů): diff(void, jiny typ) = mutation, kde jiny typ je jakýkoliv jiný typ než void.