Fakulta elektrotechnická

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická ČVUT FEL katedra počítačů Bakalářská práce Databáze pacientů Zdeněk Křepela Vedoucí práce: Ing. Zdeněk Troníček, Ph.D. Studijní program: Elektrotechnika a informatika strukturovaný bakalářský Obor: Informatika a výpočetní technika červen 2008

2 ii

3 Poděkování Chtěl bych na tomto místě poděkovat panu Ing. Zdeňku Troníčkovi, Ph.D. za jeho trpělivost a podporu, které mi pomohly při zpracování bakalářské práce. iii

4 Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne iv

5 Abstract The work is concerned with remote procedure call communication in distributed systems environment. It is focused especially on Web Services technology and platform independent SOAP protocol. The part of the work is sample database application based on the JEE architecture. Abstrakt Tato práce se zabývá komunikací založené na vzdáleném volání procedur v distribuovaných systémech. Je zaměřena především na technologii Webových služeb a platformně nezávislý protokol SOAP. Součástí je ukázková databázová aplikace postavená na architektuře JEE. v

6 vi

7 Obsah Seznam obrázků ix 1 Úvod Popis řešeného problému Webové služby XML Protokol SOAP WSDL UDDI WS-Security WS-I Analýza a návrh implementace Use Case Model Databázová vrstva JPA Vrstva výkonné logiky Rozhraní webové služby Prezentační vrstva Swingový klient Bezpečnost Popis implementace Databázová vrstva Vrstva výkonné logiky Prezentační vrstva Závěr Testování A Příloha A - Use Case Lékař 47 B Příloha B - Obsah CD 51 C Příloha C - Popis rozhraní webové služby - WSDL 53 vii

8 viii

9 Seznam obrázků 3.1 Třívrstvá architektura Use Case - Administrátor systému Use Case - Lékař E-R Diagram Klient - Založení pacienta ix

10 x

11 Kapitola 1 Úvod 1.1 Popis řešeného problému Navrhněte a implementujte ukázkovou JEE aplikaci. Aplikace bude obsahovat databázi pacientů a bude přístupná přes webové služby. Pro každou službu implementujte klienta, který umožní ověřit funkčnost webové služby. V tomto případě je tedy práce návrhově-implementačního charakteru. S vedoucím práce jsme se již předem dohodli na použité technologii, která je tak uvedena přímo v zadání. Chtěl bych dále ukázat, že použití webových služeb řeší problém univerzálnosti rozhraní pro komunikaci mezi objektově distribuovanými systémy. Zkratka JEE (Java Platform, Enterprise Edition) naznačuje, že pro implementaci bude použit programovací jazyk Java. JEE 1 (dříve J2EE 2 ) je sada dílčích technologií, které nám umožňují jednoduše vyvíjet, nasazovat a udržovat vícevrstvé aplikace především na straně serveru. Způsob, jakým tyto technologie mezi sebou spolupracují je definován specifikací. Abychom mohli využívat veškeré možnosti, které nám tato specifikace nabízí, existují různé implementace, kterým říkáme aplikační servery. Pro tuto práci jsem si zvolil volně dostupný aplikační server JBoss 3. JBoss je široce rozšířený open source aplikační server, certifikovaný pro platformu J2EE 1.4. Plně však podporuje technologie EJB 3.0 a JAX-WS, které bych chtěl v této práci použít. JBoss je distribuován pod LGPL licencí. Je založen na architektuře mikrojádra, které pokytuje pouze klíčové služby a činí tak z JBossu vysoce modulární systém. Lze tak jednoduše přidat služby jako transakční manager, jmennou službu, webový server, ejb kontejner atd. Za zmínku stojí též aplikační servery WebSphere (IBM) nebo GlassFish, což je referenční implementace od firmy Sun Microsystems. GlassFish je postaven již na technologii JEE 5. Výhody této technologie oproti J2EE lze stručně charakterizovat jako zjednodušený programovací model. V této práci výběr aplikačního serveru není příliš podstatný. Rád bych též zmínil, že Enterprise aplikace dodržující specifikaci jsou ve většině případů velmi dobře přenositelné, což znamená, že je lze v případě potřeby přesunout z jednoho aplikačního serveru na

12 2 KAPITOLA 1. ÚVOD druhý bez výrazných zásahů do zdrojového kódu. Zásah do konfiguračních souborů, které jsou nedílnou součástí takové aplikace, je ale v praxi většinou nutný.

13 Kapitola 2 Webové služby Webové služby je českým překladem anglického termínu Web Services. V dnešní době tento termín může být poněkud zavádějící, neb jak si řekneme dále, nejedná se pouze o služby poskytované přes webové (http) rozhraní. Web Services jsou další alternativní technologií pro vzdálené volání procedur v distribuovaných systémech. W3C[9] definuje webovou službu jako softwarový systém podporující interoperabilní sít ovou komunikaci mezi dvěma počítači a definovaný většinou jazykem WSDL. Vzdálené volání procedur není nic nového. Za podobným účelem zde byla již v roce 1991 uvedena specifikace CORBA 1, která definovala interoperabilitu mezi vzdálenými počítačovými uzly, běžícími v heterogenním prostředí. Mezi další objektové technologie vzdálené komunikace patří například DCOM 2 od firmy Microsoft. Narozdíl od těchto předchůdkyň webové služby v počátcích nebyly tak vyspělé a nepodporovaly například zabezpečenou komunikaci, spolehlivost při doručování zpráv nebo transakce. V dnešní době je ale situace jiná a vzniklo mnoho dalších specifikací pod zkratkou WS-*, které rozšiřují schopnosti a možnosti webových služeb a umožňují tak například používat i výše zmíněnou bezpečnost, digitální podpisy nebo transakční zpracování. Webové služby jsou modulárně složeny z několika specifikací. Neexistuje tedy jeden dokument, v němž by bylo obsaženo vše. Veškeré klíčové technologie jsou však otevřené standardy organizací W3C[9] nebo OASIS[4]. SOAP - Simple Object Access Protocol je platformě, procesorově a jazykově nezávislý komunikační protokol založený na standardu XML a určený k přenosu zpráv v heterogenním sít ovém prostředí, viz kapitola 2.2 WSDL - Web Service Definition Language je XML jazyk určený pro popis rozhraní k Webovým službám. Specifikuje umístění služby a operace (metody), které služba poskytuje, viz kapitola 2.3 UDDI - Universal Description, Discovery and Integration slouží jako adresář k ukládání informací o webových službách. Jsou zde uloženy rozhraní ve formě WSDL. Adresář umožňuje tyto služby vyhledávat, případně publikovat. 2.4 Díky těmto standardům je možné rychle a jednoduše vytvořit rozhraní k aplikacím přístupným přes web a vystavit tak některé jejich služby. Tyto technologie budou po- 1 Common Object Request Broker Architecture Distributed Component Object Model 3

14 4 KAPITOLA 2. WEBOVÉ SLUŽBY drobně probrány v dalším textu. Nejprve se ale pojd me podívat na základní stavební prvek webových služeb a tím je značkovací jazyk XML XML XML je značkovací jazyk podobný HTML 4. Základní rozdíl mezi těmito dvěma jazyky je už v samotném účelu použití. HTML byl vyvinut za účelem zobrazování informací a toho, jak výsledné zobrazení vypadá. Naproti tomu XML je od samého počátku určeno pro popis informací a dat, které tyto informace v sobě obsahují. Vlevo je krátký výpis kódu v HTML, který říká, zobraz následují text Hello tučným písmem. Vpravo je pak ukázka XML dokumentu, který pouze nese určitou informaci a neříká nic o tom, jak se tato informace dále využije[12]. <html> <body> <b>hello</b> </body> </html> <person sex= female > <id>123456</id> <name>jane</name> <surname>knuth</surname> </person> Protože XML dokument může obsahovat libovolné objekty, lze pro jejich zápis též využít libovolné tagy. XML dokument není svázán určitou množinou tagů jako je tomu v například v HTML. Je možné si nadefinovat vlastní. Pro definici tagů je možné využít DTD 5 nebo XSD 6, které je k tomu přímo určeno a umožňuje mnohem podrobnější popis. XSD umožňuje používat například základní datové typy, enumerace, dovoluje rozhodnout, zda daný element může být vynechán, nebo které znaky může obsahovat. Následující ukázka demonstruje část jednoduchého XML schéma, které definuje některá pravidla a omezení pro výše zmíněný typ person. V zápisu je vynechána hlavička pro úsporu místa. <xs:element name= person > <xs:complextype> <xs:element name= id type= xs:int /> <xs:element name= name > <xs:simpletype> <xs:restriction base= xs:string> <xs:pattern value= [a-za-z]{3,9} /> </xs:restriction> </xs:simpletype> </xs:element> <xs:attribute name= sex type= xs:string use= required /> </xs:element> 3 Extensible Markup Language 4 Hypertext Markup Language 5 Document Type Definition 6 XML Schema Definition

15 2.1. XML 5 Tímto se omezila hodnota id pouze na čísla typu xs:int. Element name je pak typu xs:string a může obsahovat pouze velká nebo malá písmena v minimálním počtu tří a maximimálním počtu devět. Podrobnější informace lze nalézt na stránkách W3C 7. Dále definice říká, že element person obsahuje atribut typu xs:string, který je povinný. Symbol xs určuje odkaz na takzvaný namespace, neboli jmenný prostor, ze kterého pochází daný element. Jmenný prostor se používá k tomu, abychom měli zajištěnou jedinečnost pojmenování. Všechny elementy uvnitř jmenného prostoru musí být unikátní. Jde o to předejít situaci, kdy se někdo rozhodne vytvořit stejný typ person, který jsme nadefinovali výše, pouze s tím rozdílem, že id bude typu xs:string. Jak tedy potom rozhodnout, o kterou osobu se vlastně jedná a který typ vložit do elementu id. Řešení je právě v použití jmenného prostoru. Pokud do hlavičky XML Schématu vložíme následující dva řádky, <xs:schema xmlns:xs= targetnamespace= > říkáme atributem targetnamespace, že námi definovaná osoba je ze jmenného prostoru Není povinnost zadávat namespace jako URL, dodržuje se však konvence, že jmenné prostory se takto zadávají. Přispívá to i k dodržení unikátnosti, neb na internetu standardně nemohou existovat dvě stejné URL adresy. Dále je zde také vidět, kde se vzal prefix xs. Specifikace definuje hned několik základních jmenných prostorů, které nám umožňují vytvořit XML Dokument a vedle něj XML Schéma, které tento dokument popisuje. Zápisem xmlns:xs= říkáme, že veškeré elementy a datové typy prefixované symbolem xs pocházejí ze jmenného prostoru XMLschema. Dále tak při použití prefixu můžeme odkazovat na datové typy element, attribute, complextype, simpletype a další, které nám umožní definovat vlastní datové typy. Definice vlastních typů pak dále dovoluje vytvářet strukturované XML dokumenty, které vyhovují předloze ve formě XML schématu a je možné je validovat. Simple type I když jsme nikde nedefinovali typy xs:int a xs:string, přesto jsou v definici typu person použity. Tyto typy se zpřístupnily právě použitím jmenného prostoru XMLSchema, ve kterém jsou již vydefinovány. Jedná se o takzvané zabudované typy. V Případě xs:string jde o zabudovaný primitivní typ a v případě xs:int jde o primitivní typ odvozený od primitivního typu xs:decimal takzvanou restrikcí. Restrikce jednoduše znamená, že na nadřazený typ byla aplikována některá omezení. V případě xs:int se může jednat například o omezení intervalu. Je možné též vytvořit vlastní jednoduchý typ tím, že omezíme některý již existující, a použít ho při definici schématu. Takto například vytvoříme typ, do kterého je možné přiřadit pouze hodnoty A, B atd. Tím jsme de facto vytvořili datový typ enumerace známý z programovacích jazyků. 7 World Wide Web Consorcium

16 6 KAPITOLA 2. WEBOVÉ SLUŽBY <xs:simpletype name= krevniskupina > <xs:restriction base= xs:string > <xs:enumeration value= A /> <xs:enumeration value= B />... </xs:restriction> </xs:simpletype> Deklarace takto nadefinovaného typu v XML Schéma vypadá následovně: <element name= pacienttypkrve type= krevniskupina /> Další informace o jednotlivých předdefinovaných typech lze nalézt na stránkách W3C. Complex type Simple type a Complex type se od sebe liší tím, že jednoduchý typ v sobě nemůže obsahovat další elementy nebo atributy. Náš typ person je tedy názorným příkladem komplexního typu. Je však nutné rozlišovat dva druhy. Komplexní typ s jednoduchým obsahem může obsahovat pouze atributy nebo textový obsah. Nesmí obsahovat žádné další elementy. Takové typy mohou vzniknout například restrikcí či rozšířením jednoduchých typů a přidáním atributu. <xs:element name= student type= studenttype > <xs:complextype name= studenttype > <xs:simplecontent> <xs:extension base= xs:string > <xs:attribute name= class type= xs:integer /> </xs:extension> </xs:simplecontent> Takto potom vypadá XML element, který vyhovuje výše uvedenému schématu: <student class= 4 >John Smith</student> Namísto toho komplexní typ s komplexním obsahem vnořené elementy obsahovat může, viz typ person, což je příklad komplexního typu s komplexním obsahem. XML Dokument Doposud jsme mluvili vesměs o XML Schématu, což je definice, která umožňuje popisovat XML Dokumenty. Pokud již máme vytvořenou definici, je na čase vytvořit instanci tohoto schématu. Tou je právě XML Dokument. Jedná se o klasický xml soubor, který v hlavičce odkazuje na příslušné xml schéma (xsd soubor) pomocí atributu schemalocation, aby bylo jasné, kde se nachází popis jednotlivých elementů. <person xmlns= xmlns:xsi= xsi:schemalocation= person.xsd >...

17 2.2. PROTOKOL SOAP 7 schemalocation má prefix xsi, který je v hlavičce přidružen jmennému prostoru XMLSchema-instance. Tento prostor obsahuje typy a atributy pro použití v XML instancích. person.xsd je soubor,který v tomto případě obsahuje definici a popis tohoto XML Dokumentu v podobě XML Schématu. Víme tedy, jak vytvořit XML Dokument popisující nějaký objekt. Jak tento objekt přenést, bude předmětem další kapitoly. 2.2 Protokol SOAP SOAP 8 je obecně komunikační protokol pro výměnu informací ve formě XML zpráv. Umožňuje posílání zpráv mezi dvěma aplikacemi a pracuje tedy na principu peer-to-peer. Tyto aplikace přitom mohou běžet decentralizovaně na různých operačních systémech a mohou být napsány v různých programovacích jazycích. Decentralizací je myšleno, že aplikace mohou být umístěné na různých místech v síti. Jedná se tedy o sít ový protokol. Sít ová komunikace jako taková je rozdělena do vrstev, které mezi sebou spolupracují. Fyzická vrstva - umožňuje přístup k fyzickému sít ovému zařízení (Ethernet, Token Ring, FDDI). Sít ová vrstva - zajišt uje především adresaci, směrování a předávání datagramů, a je tedy implementována ve všech prvcích sítě (IP). Transportní vrstva - poskytuje koncovým systémům spojové (TCP) či nespojové služby (UDP) Aplikační vrstva - jednotlivé aplikace (procesy) běžící na koncovém systému, které využívají sít ových služeb (HTTP, SMTP, Telnet) SOAP je postaven nad aplikační vrstvou. Využívá převážně HTTP případně HTTPS přenosu a je tím pádem také bezestavový a dobře prostupný pro firewall. Někdy je proto označován jako lightweight a toto je také jeden z argumentů pro jeho použití ve webových službách. Kromě výše zmíněných protokolů lze též využít transportu přes SMTP nebo přes jakýkoliv jiný protokol aplikační vrstvy. Pojem Webové služby, který spíše naznačuje použití v HTTP však zůstal nezměněn. Vzdálené volání procedur je určitě známé v trochu jiné podobě. Následující příklad demontruje zavolání funkce secti se dvěma parametry předané metodou GET. Pokud server obsahuje danou funkci, provede sečtení a vrácení výsledku. Nevýhodou takového přístupu je jednak omezení délky URL v některých prohlížečích a také skutečnost, že výsledek volání dostaneme většinou v HTML. Je určitě jasné, že parsovat HTML pro získání výsledku by bylo poněkud neohrabané. Problémy by nastávaly též s validací. Metoda POST nabízí pohodlnější způsob, jak přenést data na server. Od té doby, co byl standardizován formát multipart/form-data (viz [6]) pro nahrávání souborů, který je narozdíl od application/x-www-form-urlencode efektivnější pro přenos souborů a binárních dat, nic už nebránilo v tom, přenášet v těle HTTP XML Dokumenty. XML má tu výhodu, že umožňuje přenášet jak objekty (viz. 8 Simple Object Access Protocol

18 8 KAPITOLA 2. WEBOVÉ SLUŽBY person v kapitole 2.1) či dokonce kolekce těchto objektů, tak také binární data jako například obrázky. V kombinaci se schématem, které nám určuje předlohu XML Dokumentu je navíc možné popsat strukturu předávaných dat a tím zajistit interoperabilitu na obou stranách. Pokud navíc přidáme jmenné prostory 2.1, zamezíme tím konfliktům v pojmenování těchto xml objektů. Ukážeme si nyní, jak vypadá SOAP požadavek zaslaný serveru (request) a příchozí odpověd (response). <soap:envelope xmlns:soap= soap:encodingstyle= > <soap:header> <m:sessionid xmlns:m= soap:mustunderstand= 1 >11111</m:SessionId> </soap:header> <soap:body xmlns:ns1= > <ns1:ulozdokosiku> <ns1:idzbozi>123456</ns1:idzbozi> </ns1:ulozdokosiku> </soap:body> </soap:envelope> Elementy s prefixem soap tvoří základní kostru SOAP zprávy. Ta se tedy skládá z povinné obálky soap:envelop, která tvoří kořenový element a musí být vždy uvedena. Dále je zde nepovinná hlavička soap:header, která ve většině případů rozšiřuje informace obsažené v těle zprávy. Může obsahovat autentizační údaje jako jméno nebo heslo, časové razítko nebo elektronický podpis, který zabezpečí danou zprávu vůči změně mezi odesílatelem a příjemcem. V tomto případě nese hlavička sessionid, které identifikuje klienta. Pokud je hlavička v obálce přítomna, musí být uvedena jako první element následující po elementu soap:envelop. Specifikace 9 protokolu SOAP dává navíc možnost označit údaje uvedené v hlavičce jako povinné. To je zajištěno nastavením atributu soap:mustunderstand na hodnotu 1 nebo true. Příjemce takové zprávy je povinen hlavičku zpracovat(rozpoznat daný element) nebo vygenerovat chybu a zaslat zpět na klienta. Tím můžeme například zajistit, že autentizační údaje, které pošleme v hlavičce na server, budou bud serverem rozpoznány a zpracovány, nebo nikoliv a v tom případě server bude ignorovat tělo zprávy a zašle zpět chybu. Tělo zprávy soap:body, jak je vidět z příkladu, pak obsahuje samotný XML Dokument se všemi náležitostmi, které jsme uvedli v kapitole 2.1. XML element UlozDoKosiku obsahuje podřízený element IdZbozi, který v sobě nese posloupnost čísel zakódovanou například do jednoduchého typu xs:long. Obecně se dá říci, že tělo zprávy tvoří žádost o provedení nějaké služby. Obsah odpovědi pak tvoří výsledek tohoto požadavku nebo v případě neúspěšného provedení chyba. Předpokládejme, že server tento request zpracoval a zašle klientovi odpověd, která může vypadat například takto. 9

19 2.2. PROTOKOL SOAP 9 <soap:envelope xmlns:soap= soap:encodingstyle= > <soap:body xmlns:ns1= > <ns1:ulozdokosikuresponse> <ns1:status>ok</ns1:status> </ns1:ulozdokosikuresponse> </soap:body> </soap:envelope> Server tím dává najevo, že uložení proběhlo úspěšně. V případě chyby, server vrátí takzvaný SOAP Fault. Pro úsporu místa uvedu jen tělo zprávy. Obálka zůstává stejná jako u předchozího příkladu. <soap:body xmlns:ns1= > <env:fault> <env:faultcode>env:server</env:faultcode> <env:faultstring>nevalidni ID</env:faultstring> <env:detail> ID musi obsahovat alespon 5 znaku </env:detail> </env:fault> </soap:body> Takto může například vypadat reakce serveru na špatně vyplněnou položku IdZbozi, kterou server nedokáže zpracovat. Pro chybové zprávy platí, že element env:fault, pokud je obsažen, musí být umístěn jako první v těle zprávy. V praxi se o tyto záležitosti starají jednotlivé implementace specifikací webových služeb. Programátor se tak může více soustředit na daný problém a nemusí se zabývat parsováním elementů popřípadě validací zpráv. Protože systém přenosu a odhalování chyb je velmi důležitý při vývoji distribuovaných systémů, bude na něj kladen velký důraz i v této ukázkové aplikaci. Objasním ve stručnosti, co které položky znamenají. Předem bych chtěl říci, že je zde názorně vidět výhoda protokolu SOAP a webových služeb jako takových, oproti technologiím typu RMI, CORBA, DCOM. Veškerá data, tedy i chybové zprávy, se šíří v textové podobě a je tedy v případě nutnosti snadné je odchytit a určit místo problému. To samozřejmě neplatí v případě použití šifrované komunikace (HTTPS). Nicméně za účelem ladění systému je vždy možné toto šifrování vypnout a přejít na komunikaci nešifrovanou. Element faultcode tedy může obsahovat následující hodnoty. VersionMismatch element env:envelop. pokud příjemce nalezne špatný jmenný prostor pro kořenový MustUnderstand v případě, že element v hlavičce s nastaveným atributem mustunderstand na 1 nebo true nebyl příjemcem rozpoznán.

20 10 KAPITOLA 2. WEBOVÉ SLUŽBY Client indikuje, že příchozí zpráva byla nekorektně zformována nebo obsahuje nekorektní informace Server značí problém na serverové straně. Server například nebyl schopný zpracovat request díky nevalidnímu obsahu, nebo mohla nastat chyba v komunikaci s databází. K upřesnění těchto kódů slouží element detail, ve kterém můžeme posílat námi vyspecifikované informace. Pokud například požadujeme, aby se na klienta přenášela naše vlastní výjimka, pak toto je místo, kam ji umístit. Aby obě strany, které spolu komunikují, věděly, jaké informace si mohou mezi sebou vyměňovat, a které elementy a parametry mohou od protější strany očekávat, byl ustaven formát WSDL 10, kterým je možné tuto komunikaci popsat. 2.3 WSDL WSDL je jazyk na bázi XML, který slouží pro popis rozhraní webových služeb. Verze 2.0 je definována svou specifikací [11]. Předchozí verze 1.2 nebyla organizací W3C [9] schválena jako specifikace, nicméně zde existuje její working draft 11. Je to hlavně z toho důvodu, že mnoho dnešních vývojových nástrojů a implementací webových služeb zatím neposkytuje dostatečnou podporu pro specifikaci 2.0. WSDL dokument je de facto sada definicí. Je to jednoduchý XML dokument, který obsahuje následující sekce jakožto povinné elementy: <definitions> <types> definice datových typů... </types> <message> definice struktury zpráv... </message> <porttype> popis služby, operací a zpráv... </porttype> <binding> definice protokolu a formátu zpráv... </binding> </definitions> Types je sekce, ve které jsou nadefinovány datové typy, jenž daná služba používá. WSDL neposkytuje nový jazyk pro definici datových typů. Namísto toho používá XML Schéma. Není však vyloučeno z hlediska budoucího vývoje, že se typový systém může změnit. Gramatika WSDL tuto rozšiřitelnost umožňuje. 10 Web Service Description Language 11 Working Draft je dokument, který byl publikován organizací W3C ke zhodnocení. Je to tzv. Pracovní Návrh a je to počáteční stupeň ve schvalovacím procesu dokumentu. Konečný stupeň se stává standardem a označuje se jako WC3 Recommendation. Více viz [9]

21 2.3. WSDL 11 Messages je sekce, která definuje strukturu vstupních, tj. příchozích a výstupních, tj. odesílaných zpráv. Obsahuje odkazy na datové typy, které se v této zprávě vyskytují. Z hlediska běžného programovacího jazyka je možné na tuto sekci nahlížet jako na definici argumentů vstupujících do metod nebo z metod vystupujících. PortType je sekce, která popisuje samotnou webovou službu. Jsou zde uvedeny operace, které tato služba poskytuje a u každé operace jsou též popsány vstupní a výstupní zprávy s touto operací spojené. Pokud se na tuto sekci opět podíváme z hlediska běžného programovacího jazyka, lze ji přirovnat ke třídě, která poskytuje určité metody, nebo ještě lépe k jejímu rozhraní. Stejně tak jako v běžném programovacím jazyce existují metody, které nemají žádný vstupní argument (void) nebo nemají žádný návratový typ, existují i zde operace, které jsou jednosměrné, tj. nevrací žádný response. Pokud v o- peraci neuvedeme výstupní element, jedná se o tzv. One-Way operaci neboli ping. Není to totiž tak, že služba vůbec neodpoví. Nesmíme zapomínat, že SOAP je nadstavbou protokolu HTTP. One-Way tedy odpoví, ale to, zda kromě hlavičky obsahuje i nějaká XML data záleží především na použitém BindingStyle. Binding je sekce, obsahující informace o použitém komunikačním protokolu, např. (HTTP) a definuje formát zpráv (BindingStyle). Tato sekce obsahuje operace, které jsou ve skutečnosti vystavené klientům. BindingStyle Je způsob, jakým se zprávy napojují na podřízený protokol (většinou SOAP). Protože tento atribut dosti ovlivňuje tvar WSDL a vůbec celý způsob komunikace, věnuji mu pár řádků. BindingStyle může být typu RPC 12 nebo typu document. Jeho použití může být encoded nebo literal. Vznikají nám tak 4 různé modely použití. Pro lepší představu uvedu příklad. Vyjdeme z následující metody. public void soucet(int x, int y); 1. RPC/encoded Část WSDL pro výše uvedenou operaci vypadá následovně: <message name= vstup > <part name= x type= xsd:int /> <part name= y type= xsd:int /> </message> <message name= vystup /> <porttype name= portname > <operation name= soucet > <input message= vstup /> <output message= vystup /> </operation> </porttype> Po zavolání takovéto metody přijde na server request v následující podobě: 12 Remote Procedure Call

22 12 KAPITOLA 2. WEBOVÉ SLUŽBY <soap:body> <soucet> <x xsi:type= xs:int >6</x> <y xsi:type= xs:int >7</y> </soucet> </soap:body> Tento styl má několik výhod. WSDL je opravdu jednoduché a srozumitelné. Jméno operace je obsaženo v těle zprávy, a pro server je tedy jednoduché rozpoznat, kterou z vystavených metod má vyvolat. Nevýhoda spočívá v tom, že typ encoding vkládá k jednotlivým argumentům metody také část XML Schéma, které popisuje typy těchto argumentů. Protože parsování XML je samozřejmě procesorově náročná operace, může tento typ zpráv při obsáhlejším dotazu snižovat výkon. Další nevýhodou může být nemožnost validace této příchozí zprávy. Vstupní argumenty x a y obsahují informace, na základě kterých je možno ověřit, zda obsah vstupních elementů opravdu odpovídá číslům typu xs:int. Element soucet zde však představuje jméno operace a nikoliv typ z XML Schématu. Toto znemožňuje validaci. I přesto, že je tento typ WSDL validní, není doporučen organizací WS-I, viz kapitola RPC/literal WSDL pro tento typ je většinou stejné, a tedy jednoduché. Zpráva zaslaná na server se zde liší pouze v tom, že u jednotlivých vstupních elementů není obsažena část XML Schéma. To nám zajišt uje použití literal. Jméno operace je opět obsaženo v těle zprávy, a je tedy snadné zprávu předat té správné metodě. Bohužel tak stále není možné provést validaci této zprávy. Tento typ vyhovuje doporučení organizace WS-I. 3. Document/encoded V praxi se téměř nepoužívá a není ani doporučen organizací WS-I. Nebudu se s ním proto zabývat. 4. Document/literal Oproti RPC/literal zde nastává drobná změna ve WSDL. Ukážeme si jen část message. <message name= soucet > <part name= x element= TypX /> <part name= y element= TypY /> </message> Jak je vidět, místo typů u jednotlivých argumentů, je udán odkaz na element do sekce types, která zde není uvedena. V ní je pak obsažena přesná definice tohoto elementu. Změnila se i příchozí zpráva. <soap:body> <TypX>6</TypX> <TypY>7</TypY> </soap:body>

23 2.4. UDDI 13 Takto tvarovaná příchozí zpráva nám eliminuje některé nedostatky předchozích typů. Především je možné tuto zprávu zvalidovat, neb veškeré informace přenášené v těle jsou popsané v XML Schématu uvnitř WSDL. Zpráva neobsahuje nadbytečné encoding informace. Tento styl má však také svá omezení. Doporučení organizace WS-I dovoluje pouze jeden podřízený element v těle zprávy. Je to právě z důvodu přiřazení zpráv jednotlivým operacím. Tělo totiž v tomto případě neobsahuje jméno operace a pokud bychom vystavili dvě metody se vstupním argumentem void, server by nevěděl, které metodě má request přiřadit. Odstranili jsme tedy některá omezení předchozích typů, ale ztratili jsme jméno operace. 5. Document/literal wrapped je řešením předchozího problému. Příchozí zpráva na server vypadá stejně jako v případě RPC/literal, kromě jedné drobnosti. Element soucet zde není jméno operace, nýbrž jméno tzv. zaobalovacího elementu (wrraped). Formát zprávy je pak dán následující definicí ve WSDL: <message name= soucet > <part name= vstup element= soucet /> </message> Na element soucet lze pak nahlížet jako na komplexní typ, který zahrnuje podřízené elementy x a y. Tento způsob napojování zpráv je doporučen organizací WS-I, avšak není součástí žádné specifikace. Pochází od firmy Microsoft a organizace WS-I doporučuje tento styl právě kvůli interoperabilitě mezi MS a ostatními implementacemi Webových služeb. [1] V této práci tedy bude použit tento typ napojení. 2.4 UDDI Universal Description Discovery and Integration neboli registr pro evidenci, popis a integraci webových služeb. Jedná se o adresář, který umožňuje vyhledávat, které jsou na internetu k dispozici a publikovat nové. Tento registr nebudeme v naší práci využívat. Více se lze dozvědět zde [7]. 2.5 WS-Security WS-Security [10] je příkladem jednoho z mnoha rozšíření protokolu soap o mechanizmus šifrování a digitálních podpisů. Výhodou oproti standardnímu šifrování, které zajišt uje transportní protokol SSL (TLS), je ten, že WS-Security aplikují šifrování na každou zprávu zvlášt a tudíž zabezpečují přenos od odesílatele až ke koncovému příjemci, bez ohledu na to kudy zpráva putovala. Nevýhodou může být pomalejší zpracování vzhledem k použítí asymetrické kryptografie. SSL po navázání spojení přechází na symetrickou kryptografii, která významně zvyšuje rychlost přenosu.

24 14 KAPITOLA 2. WEBOVÉ SLUŽBY 2.6 WS-I Mnoho implementací webových služeb často ne zcela vychází z dané specifikace. Organizace WS-I 13 byla zformována proto, aby vyjasnila tyto nesrovnalosti a umožnila větší interoperabilitu mezi těmito frameworky. Organizace poskytuje profily, vzorové aplikace a testovací nástroje, které napomáhají zjistit, zda webová služba vyhovuje doporučení. 13 Web Service Interoperability Organization

25 Kapitola 3 Analýza a návrh implementace Podívejme se nyní na systém evidence pacientů z hlediska použité technologie JEE. Dříve se při vývoji rozsáhlejších aplikací používala tzv. monolitická architektura, kdy databázová vrstva, aplikační vrstva a prezentační vrstva splývaly do jediného monolitického celku. Celý systém tak běžel na jednom centrálním počítači a klienti se připojovali prostřednictvím terminálů. Výrazná nevýhoda takového řešení je samozřejmě spolehlivost, nebot pokud tento server selže, pak je mimo provoz celý systém. Dalším evolučním stupněm se stala dvouvrstvá architektura, nebo též architektura klient - server. Jak již název napovídá, je zde aplikace rozdělena do dvou vrstev. Oddělená je prezentační (klientská) a databázová (serverová) vrstva. Aplikační logika je přesunuta bud na klientskou část (tlustý klient), nebo na server (tenký klient). Nevýhody této architektury se objevily s příchodem komplexních systémů, kde počet připojených uživatelů vzrůstá. V případě tlustého klienta dochází ke zvýšení nároků na klientské počítače v důsledku náročnější aplikační logiky. V případě tenkého klienta se aplikační logika přesouvá na server a vzrůstají nároky na výkon serveru. Pokud navíc systém udržuje pro každého klienta spojení (keep alive), může velmi často dojít k vyčerpání systémových zdrojů. Řešení se našlo v podobě přidání dalších vrstev, které byly vloženy mezi vrstvu databázovou a prezentační. Samozřejmě bylo nutné znovu vyspecifikovat funkce jednotlivých vrstev a jejich role v celém systému. Aplikační logika se zde kompletně přesouvá na server. Zatížení je v této architektuře efektivně rozděleno mezi databázový stroj, aplikační server a klienta. Je to především z toho důvodu, že databázový stroj může komunikovat s více aplikačními servery a ty dále propagují data k jednotlivým klientům. [8] Aplikační servery umožňují rozdělení zátěže (load balancing) nebo předání řízení jinému aplikačnímu serveru v případě výpadku (fail over). Další možnosti, jak zvýšit spolehlivost aplikace, je propojení aplikačních serverů do clusteru a umožnit replikaci session a v případě JEE architektury též dalších komponent. Session je objekt uložený v paměti daného aplikačního serveru, jehož účelem je držet uživatelská data a tím obejít například bezestavovost protokolu HTTP. Klient se tak může nacházet v určitém stavu, například být příhlášený pod určitým uživatelským jménem. Replikace session zajistí v případě výpadku jednoho uzlu přenesení tohoto objektu do paměti dalšího aplikačního serveru tak, že hrozí jen minimální ztráta dat a client může pokračovat ve své rozdělané práci. Clustering není doménou pouze aplikačních serverů, nýbrž i některých databází. Například databáze Oracle nebo PostgreSQL umožňuje zařadit do clusteru jednotlivé instance a tím zajistit větší spolehlivost datové vrstvy. Zapojení do clusteru, případně load balancing je otázkou spíše nasazení takového systému do ostrého provozu. V ukázkové 15

26 16 KAPITOLA 3. ANALÝZA A NÁVRH IMPLEMENTACE aplikaci nemá tento krok příliš velký význam, proto jej při implementaci vynecháme. Následující obrázek ukazuje schéma třívrstvé architektury JEE aplikace. Obrázek 3.1: Třívrstvá architektura 3.1 Use Case Model Ze všeho nejdříve je podstatné vyspecifikovat, co má navrhovaný systém umět, a které služby má poskytovat. Pokud nějaký systém implementujeme, není dobré začít psát hned zdrojový kód s tím, že vše podstatné máme v hlavě. Softwarové inženýrství definuje postupy a modely, které napomáhají zjednodušit vývoj aplikace od samotného návrhu až po nasazení. Prvním mým krokem bylo vytvořit Model jednání, který zobrazuje hranice systému, dále uživatele, kteří s ním interagují a funkce, které by tento systém měl poskytovat. Hranice systému na obrázku 3.1, je tvořena databázovou a aplikační vrstvou. Klientská vrstva přestavuje bud přistupující okolní systémy (nemocnice), nebo jednotlivé uživatele (lékaře). V modelu jednání (Use Case Model) však použitá architektura není podstatná. Měli bychom zde popsat uživatelské akce a události, na ktére systém musí umět zareagovat. Roli zde hraje uživatel. Měly by zde být též jasně vymezeny hranice, tj. která událost je součástí systému a která již stojí mimo něj. Ukažme si Use Case model pro roli Administráror. 4.1 Od uživatele vedou čáry k jednotlivým případům užití. Z obrázku je vidět, že administrátor bude mít možnost zakládat, vyhledávat a případně upravit a odstranit lékaře. Symbol <<include>> naznačuje, že lékař půjde upravit či odstranit ze systému pouze prostřednictvím scénáře pro vyhledání. Je to tak proto, že nelze upravovat lékaře, aniž bychom si před tím načetli ze systému aktuální data. Při odstranění platí to samé.

27 3.1. USE CASE MODEL 17 Obrázek 3.2: Use Case - Administrátor systému Pro implementaci testovacího prostředí jsem zvolil variantu tlustého klienta napsaného v jazyce Java (knihovna Swing). Je to proto, že přímo samotný klient bude generovat dotazy, zasílat serveru a starat se o zobrazování příchozích informací. Kromě toho bude obsahovat validace pro vstupní formuláře. Je samozřejmě možné použít pro přístup i tenkého klienta. Pouze jsem se rozhodl pro jednu z možných variant. V případě tenkého klienta (webový prhlížeč), který neobsahuje tuto aplikační logiku, bychom museli použít server jako mezičlánek, ke kterému by klient přistupoval a teprve tento server by generoval odchozí SOAP zprávy pro vzdálený systém. Use Case Model poskytuje pouze základní přehled služeb. Pro podrobnější popis je nutné dopsat jednotlivé scénáře. Ty definují kroky, které uživatel musí v tomto scénáři provést pro dosažení avizovaného cíle. V souvislosti s předchozím diagramem (obr. 3.2) uvedu scénáře pro roli Administrátor. UC01: Založení lékaře 1. Uživatel siskne tlačítko Založení lékaře. 2. Systém zobrazí formulář se vstupními políčky jméno, příjmení, rodné číslo, datum narození, adresa, telefon, uživatelské jméno, heslo a pole určující platnost účtu. Součástí adresy je ulice, číslo popisné a psč. 3. Uživatel zadá vstupní údaje a stiskne tlačítko Uložit. 4. Systém ověří, zda byla správně vyplněna vstupní pole a provede validaci na povinné položky. U rodného čísla a uživatelského jména systém ověří zda jsou unikátní. U

28 18 KAPITOLA 3. ANALÝZA A NÁVRH IMPLEMENTACE rodného čísla navíc ověří dělitelnost 11. Pokud je vše splněno, uloží záznam do databáze. V opačném případě zobrazí popis chyby. UC02: Vyhledání lékaře 1. Uživatel stiskne tlačítko Vyhledání lékaře. 2. Systém zobrazí formulář se vstupními políčky jméno, příjmení, rodné číslo. 3. Uživatel zadá vyhledávací kritéria a stiskne tlačítko Vyhledat. 4. Systém ověří, že bylo vyplněno alespoň jedno vstupní políčko a v případě rodného čísla zvaliduje na modulo 11. Poté bud zobrazí požadované záznamy, nebo popis chyby. 5. Uživatel vybere z tabulky zobrazených záznamů požadovaného lékaře. UC03: Odstranění lékaře 1. Uživatel nejprve provede UC02. Ze zobrazeného seznamu vybere požadovaný záznam. 2. Systém zobrazí formulář se vstupními políčky jméno, příjmení, rodné číslo, datum narození, adresa, telefon, uživatelské jméno, heslo a pole určující platnost účtu. Součástí adresy je ulice, číslo popisné a psč. 3. Uživatel uvede pole určující platnost účtu do neaktivního stavu. 4. Systém zkontroluje, zda uživatel pracuje s aktuálním záznamem. Pokud ano, zneplatní lékaře v systému. V opačném případě zobrazí popis chyby. UC04: Úprava lékaře 1. Uživatel nejprve provede UC02. Ze zobrazeného seznamu vybere požadovaný záznam. 2. Systém zobrazí formulář se vstupními políčky jméno, příjmení, rodné číslo, datum narození, adresa, telefon, uživatelské jméno, heslo a pole určující platnost účtu. Součástí adresy je ulice, číslo popisné a psč. 3. Uživatel upraví příslušné záznamy a stiskne tlačítko Upravit. 4. Systém ověří správnost zadaných údajů a v případě rodného čísla zvaliduje na modulo 11. Dále zkontroluje, že záznam je aktuální. Poté bud upraví dané údaje v databázi, nebo zobrazí popis chyby. Na základě těchto scénářů jsme získali základní představu o tom, jaké funkce musí poskytovat systém pro uživatele v roli administrátor. Jelikož vyhledávací funkce budou vracet více záznamů, pro úpravu je nutné nejprve vyhledat konkrétní záznam. UC03 Odstranění lékaře neznamená jeho fyzické odstranění ze systému. Záznam se pouze zneplatní. Je to tedy speciální případ UC04, což je zde vyznačeno šipkou a značkou <<extends>>. Nyní následuje Use Case model pro roli lékař. Pro úsporu místa zde nebudu vypisovat všechny scénáře. Najdete je v příloze A.

29 3.2. DATABÁZOVÁ VRSTVA Databázová vrstva Obrázek 3.3: Use Case - Lékař Dalším krokem v analýze je vyspecifikovat datový model nebo též E-R diagram. Teorie říká, že tabulky by měly být alespoň ve třetí normální formě. Normální formy slouží pro omezení redundance dat v databázi a zefektivňují SQL dotazy. 1NF říká, že všechny atributy použité ve sloupcích by měly být atomické. Kdybychom tak uložili například ULICI, PSČ a ČP do jednoho sloupce ADRESA, těžko bychom pak získali všechny záznamy týkající se například daného PSČ. Tím bychom porušili 1NF. 2NF se týká spíše případů, kdy se v tabulkách vyskytuje složený primární klíč. Budeme se proto snažit veškeré tabulky navrhnout tak, aby primárním klíčem bylo ID. Protože ve většině databází se primární klíče automaticky indexují, což napomáhá rychlejšímu vyhledávání, vždy je efektivnější indexovat jeden namísto dvou sloupců. 3NF nám říká, že žádné dva neklíčové atributy tabulky na sobě nesmí být závislé. Informace o pacientovi budeme ukládat do tabulky PACIENT. Informace o lékařích budeme ukládat do tabulky LEKAR. Protože lékař je zároveň uživatelská role, a musí mít někde uloženy přihlašovací údaje, měl by je mít z bezpečnostních důvodů uloženy ve zvlášt tabulce. Proto vytvoříme též tabulku osoba (PERSON), která bude obsahovat přihlašovací údaje včetně zašifrovaného hesla. Kdokoliv bude přistupovat k systému, musí mít záznam v tabulce PERSON. Zde tedy bude uložen i administrátor. K zašifrování hesla použijeme jednosměrnou hashovací funkci MD5 1, která sice již není nejbezpečnější, 1 RFC 1321

30 20 KAPITOLA 3. ANALÝZA A NÁVRH IMPLEMENTACE ale pro náše účely postačí. Výsledný otisk zakódujeme pomocí Base64 2, aby v databázi nebyl vidět přímo hash. I když klient bude umožňovat pro jednu osobu přihlášení bud jako administrátor nebo jako lékař, z hlediska návrhu musí být možné přiřadit jednomu uživateli více rolí. Na klienta by se tak po přihlášení vrátil seznam rolí, které může využít a klient by se dotázal v jaké roli chce uživatel pracovat. Z toho důvodu je dobré umístit tabulku rolí (ROLES) zvlášt a odkazovat z ní cizím klíčem na tabulku PERSON. Cizím klíčem zde bude přihlašovací jméno, které v tabulce PERSON bude unikátní. V praxi by se zřejmě přihlašovací údaje oddělily úplně na jiný databázový stroj. To je ale v tomto případě zbytečné. Protože jak pacient, tak lékař mohou mít svou adresu, vytvoříme pro adresu zvlášt tabulku (ADRESA) a do tabulek PACIENT a LEKAR budeme ukládat pouze její ID. Složka praktického lékaře má být přístupná také přes webovou službu. Umístíme ji tedy do zvlášt tabulky (PRAKT LEKAR) a spojíme přes cizí klíč v tabulce PACIENT, aby bylo po vyhledání pacienta jasné, zda již složku založenou má (ID složky) a nebo nemá (NULL). Protože pacient může mít pouze jednu složku, bude se jednat o vzah 1:1. Tabulka PACIENT obsahuje též informace o zdravotní pojišt ovně, krevní skupině a RH faktoru pacienta. Pokud bychom kód a název pojišt ovny ukládali přímo do tabulky PACIENT, porušili bychom tím třetí normální formu. Kód a název jsou totiž na sobě přímo závislé. Proto vytvoříme číselník zdravotních pojišt oven (CIS POJISTOVNY) a postavíme ho mimo tabulku PACIENT vztahem 1:N. Pokud se některá pojišt ovna v budoucnosti přejmenuje, bude stačit změnit záznam pouze v číselníku a nebudeme muset složitě upravovat všechny záznamy v tabulce PACIENT. Krevní skupiny jsou 4 typy a z hlediska budoucího vývoje lidstva, těžko někdo objeví další. Jedná se navíc o informaci, kde kód krevní skupiny má plnou vypovídací hodnotu a nepotřebuje další popis. Proto je celkem zbytečné vytvářet kvůli tomu další tabulku v podobě číselníku. Zesložitili bychom tím vybírání a pro databázový stroj by to znamenalo režii navíc. Krevní skupina je tedy spíše kandidátem na typ enumerace. To samé platí o RH faktoru. Daný pacient může či nemusí trpět nějakou chorobou. Tyto informace budou ukládány do zvlášt tabulky NEMOC. Protože pacient může v danou chvíli trpět i více chorobami, bude se jednat o vztah 1:N. Vzhledem k tomu, že každá nemoc dle Mezinárodní Klasifikace Nemocí má přiřazen jednoznačný identifikátor, vytvoříme též číselník diagnóz, kde bude každá choroba klasifikována dle kódu. Na obrázku 3.4 je na základě tohoto rozboru uveden E-R diagram, který splňuje první tři normální formy JPA Java Persistence API je součástí specifikace EJB 3.0, vytvořená ke zjednodušení práce s datovou vrstvou. Protože JPA definuje jednotný interface který však může používat různé implementace. Například aplikační server GlassFish je založený na implementaci TopLink zatímco námi zvolený JBoss používá Hibernate. Tyto ORM 3 nástroje lze samozřejmě použít i samostatně mimo aplikační server. V kombinaci s aplikačním serverem však dostáváme velmi mocný nástroj pro objektově relační mapování přístupné přímo z vrstvy 2 RFC Objektově relační mapování. Tak se nazývá přístup, který umožňuje mapování objektů na tabulky relační databáze

31 3.2. DATABÁZOVÁ VRSTVA 21 Obrázek 3.4: E-R Diagram výkonné logiky díky dependency injection. EJB kontejner navíc umožňuje řídit jednotlivé transakce, poskytuje auto-commit či rollback. Pokud toho ovšem chceme využít. Je možné definovat hranice transakcí programově, to však v této aplikaci nepotřebujeme. Transakční zpracování je důležité v případě, že budeme chtít provést více databázových operací typu DELETE nebo UPDATE v jedné atomické operaci. Pokud například budeme upravovat základní informace lékaře, rozložené v tabulkách LEKAR a ADRESA, JPA provider vygeneruje více databázových příkazů UPDATE. Může se lehce stát, že první UPDATE uspěje zatímco druhý z nějakého důvodu neproběhne. Databáze by se nacházela v nekonzistentním stavu. Pokud provedeme tyto dvě operace v jedné transakci, je tato v případě neúspěchu označena pro rollback. Samotné transakce ovšem k zabezpečení konzistence nestačí.

32 22 KAPITOLA 3. ANALÝZA A NÁVRH IMPLEMENTACE Optimistické zamykání Představme si situaci, kdy dva různí lékaři mají načtenou složku pacienta a upravují stejný záznam. Oba lékaři se pokusí uložit tento záznam a oba uspějí. V databázi však budou úloženy jen data lékaře, který ukládal jako poslední. Dojde k přepsání záznamu uloženého prvním lékařem, aniž by ho někdo někdy četl. Tomuto jevu se říká lost update nebo též ztracený zápis. Ve vysoce konkurečním prostředí lze použít pesimistické zamykání, kdy se přímo zamkne daná tabulka případně záznam a ostatní klienti musí čekat dokud zámek není uvolněn. Takový přístup ale značně ovlivňuje výkonnost a propustnost systému. V případě, že se takové prostředí nepředpokládá 4 je použití pesimistických zámků zbytečný nadstandard. V tomto případě tedy použijeme variantu optimistického zamykání. O implementaci tohoto přístupu bude řeč v kapitole 4. EntityManager Je právě tím spojovacím mostem mezi vrstvou výkonné logiky a databázovým strojem. Entity jsou v jazyce java reprezentovány obyčejnými třídami (objekty), které obsahují metody set a get. Tabulku PACIENT lze tak například reprezentovat třídou Pacient, tabulku ADRESA třídou Adresa atd. Protože mezi těmito entitami existuje relace, umístíme do třídy pacient referenci na třídu adresa. Pro bližší specifikaci tohoto vztahu, případně dalších integritních omezení nám poslouží již zmiňované anotace. Takto převedeme datový model do modelu objektového a podrobnější údaje jako názvy sloupců, kardinalitu vztahů určíme anotacemi. EntityManager pak umožňuje pracovat s databázovými tabulkami skrze tyto objekty. Poskytuje metody pro vyhledávání, ukládání či úpravy a umožňuje nadefinovat vlastní dotazy do databáze. 3.3 Vrstva výkonné logiky Často se též užívá termínu business logika. Architektura JEE nabízí pro programování business logiky takzvané Enterprise Java Beany (EJB). Enterprise Beana je softwarová komponenta, která byla navržene pro zjednodušení sít ové logiky a správu paměti. Tuto komponentu tvoří interface a implementační třída případně do třetice konfigurační soubor, který popisuje nějaké její další vlastnosti. Od verze EJB 3.0 je možné přenést informace specifikované v souborech přímo do implementační třídy v podobě anotací. Aplikační server JBoss, který budeme používat, EJB 3.0 plně podporuje, tudíž k detailnímu popisu chování komponent použijeme anotace. Z hlediska programátora není EJB nic jiného, než kus kódu běžící ve specializovaném prostředí, které se nazývá EJB kontejner. Ten poskytuje komponentám bezpečné, transakční a distribuované prostředí. Umožňuje komponentám snadno přistupovat k dalším zdrojům, což může být například databáze, fronta zpráv nebo jiné komponenty třeba i na vzdáleném stroji. Programátor se tak může soustředit přímo na daný problém a nemusí se zaobírat tématikou jako multithreading, konkurentní přístup, connection pooling, atd. To vše řeší kontejner. Veškerá business logika, kterou použijeme k implementaci, běží uvnitř EJB kontejneru. EJB 3.0 specifikace poskytuje dvě základní komponenty. 4 Pacient se vždy může nacházet pouze u jednoho lékaře, který vyplňuje jeho kartu. Pokud by například ve stejnou chvíli přišly jinému lékaři výsledky z laboratoře, a bylo nutné je do systému vložit, optimistické zamykání zaručuje, že nebudou přepsány aktuálnější data

33 3.3. VRSTVA VÝKONNÉ LOGIKY 23 Message Driven Beans Tyto komponenty byly navrženy převážně k asynchronní komunikaci. Pracují na principu vybírání z fronty zpráv a v našem systému je nebudeme potřebovat. Session Beans Protože se bavíme o vrstvě výkonné logiky, jsou to právě session beans, které vykonávají různé operace na této úrovni. Existují dva druhy těchto komponent. Stateless a Statefull. Jak již název napovídá, Stateless session beans neudržují svůj stav přes více klientských požadavků. Jinými slovy, pokaždé, když server obdrží request z klienta, může ke zpracování použít jakoukoliv právě dostupnou instanci session beany z EJB kontejneru. Naproti tomu Statefull jsou schopné udržet stav mezi jednotlivými klientskými requesty. Vzhledem k tomu, že logika na serveru bude kompletně bezestavová, Statefull session beany nebudeme v této práci využívat. Naopak Stateless session beany budou představovat výkonné jádro celého systému. Tím zajistíme bezpečnou, transakční aplikační vrstvu. Zde budou umístěny metody pro přístup k samotné databázi, doplněné o validační procedury, ale také rozhraní k webovým službám. Rozhraní je v terminologii objektového programování interface, který v případě EJB 3.0 poskytuje aplikačnímu serveru abstraktní popis dané komponenty v podobě názvu metody a vstupních a výstupních parametrů. Aplikační server pak deleguje požadavky na jakoukoliv instanci třídy, která je právě dostupná v EJB kontejneru a implementuje toto rozhraní. Protože aplikace bude umožňovat práci odděleně s daty lékaře a daty pacienta, vytvoříme dvě session beany, které budou mít za úkol obsluhovat požadavky na úrovni této vrstvy. Každá beana bude určena pro jednu uživatelskou roli a bude obsahovat operace potřebné k naplnění funkčnosti vyspecifikované v Use Case diagramu. V případě role administrátor a práci s daty lékaře, musí beana umět vyhledat lékaře, založit, upravit, anebo odstranit ze systému. V případě role lékař musí umět to samé včetně podřízených záznamů jako jsou nemoci či složka praktického lékaře. Popíšeme si konkrétně jednotlivé případy, z hlediska aplikační logiky. Budeme předpokládat, že klient zaslal požadavek na server. Server přetransformuje SOAP request z XML do Java objektů a předá příslušné metodě business logiky. Dále mohou nastat tři situace. INSERT Pokud metoda rozpozná, že jde o insert, zjistí zda v tabulce do níž insert směruje, neexistuje některý z unikátních klíčů. To by znamenalo, že podobný záznam již existuje a musíme o tom informovat klienta. V případě vložení lékaře jsou tyto unikátní klíče dva (login a rodné číslo). Pokud bychom chtěli informovat klienta, který z klíčů byl porušen, museli bychom tabulku LEKAR zamknout. Během testu na duplicitu a samotným vložením záznamu, je totiž časová prodleva, v níž může jiná transakce do tabulky normálně vkládat. To je samozřejmě závislé na izolační úrovni nastavené na databázi. PostgreSQL má standardně nastavenou úroveň READ COMMITED, ze které budu dále vycházet. Nastavením na úroveň SERIALIZABLE, která zabraňuje paralelnímu běhu transakcí, bychom zbytečně snížili propustnost systému. Úroveň READ COMMITED nezabraňuje fenoménům jako Nonrepeatable read a Phantom read. Skutečnost že test na duplicitu a vložení záznamu běží v jedné transakci tedy neznamená, že

34 24 KAPITOLA 3. ANALÝZA A NÁVRH IMPLEMENTACE na úrovni databázového stroje nemůže paralelně proběhnout transakcí více. Kontejner zajišt uje pouze commit či rollback a nikoliv izolační úroveň databáze. Pokud přece jen dojde k porušení unikátnosti dat ve sloupci, Entity Manager vyhazuje výjimku EntityExistsException, kterou lze snadno odchytit a informovat klienta obecně o tom, že byl porušen unikátní klíč. Problém je s tím, že přesně nevíme který. To lze samozřejmě zjistit parsováním výpisu zásobníku, což ale není příliš elegantní způsob. V případě lékaře, který má dva unikátní klíče, tedy budeme tabulku zamykat pro zápis (číst bude možné). V případě vložení pacienta s jedním unikátním klíčem postačí odchytit výše zmíněnou výjimku. Pokud je tedy vše v pořádku, metoda přejde k uložení objektu. UPDATE Pokud metoda rozpozná, že jde o update, znamená to, že v databázi již taková entita existuje a vstupní data musí obsahovat ID a vzhledem k optimistickému přístupu též verzi upravovaného záznamu. Z toho plynou i požadavky na validace na straně serveru. Pakliže nebude obsahovat ID nebo verzi je to chyba a musí být informován klient. JPA poskytuje několik možností jak entitu upravit. Prvním způsobem je vyhledání entity pomocí primárního klíče, tedy ID, které v tomto případě máme k dispozici. EntityManager vrátí nalezenou entitu v tzv. attached stavu. Stručně řečeno to znamená, že jakákoliv operace, kterou provedeme na entitě v tomto stavu je po skončení transakce promítnuta do datové vrstvy. Dálší možností je vytvořit zcela nový objekt a nastavit mu hodnoty z requestu. Takto vytvořený objekt se nachází ve stavu detached a můžeme s ním provádět jakékoliv operace bez vlivu na datový model. Ve chvíli, kdy objekt předáme metodě EntityManager.merge(), převedeme objekt do attached stavu a po skončení transakce se upraví v databázi. Nesmíme však zapomenout nastavit ID a Verzi upravováného záznamu jinak optimistické zamykání nebude fungovat. Pokud Entity Manager nebude mít k dispozici ID, nebude vědět který záznam upravit a pokusí se založit nový. Problém u tohoto způsobu spočívá v tom, že musíme správně nastavit reference na ostatní entity. Pokud bychom například upravovali tabulku LEKAR, vytvořili bychom nový objekt lékař. Tomuto objektu bychom museli nastavit reference na všechny tabulky, na které lékař odkazuje. To umožňuje metoda EntityManager.getReference(). Potřebujeme však k tomu znát ID referenční entity. Může se stát, že jej nebudeme mít vždy k dispozici. Například pokud budeme upravovat základní informace pacienta (tabulka PACIENT), těžko budeme současně vědět ID záznamu z tabulky PRAKT LEKAR. Museli bychom na klienta zasílat ID všech podřízených záznamů. Proto je lepší použít první způsob a entitu si nejprve načíst. Aby EntityManager nenačítal automaticky všechny podřízené entity, je možné nastavit anotací tzv. LAZY loading. To způsobí, že EntityManager získá podřízenou entitu z databáze až v momentě, kdy ji opravdu budeme potřebovat. V praxi to znamená volání metody get na této entitě nebo v případě seznamu zavolání metody size. V případě LAZY načítání můžou však vznikat nekonzistence a je potřeba tyto situace nějak ošetřit. Řešení, které dle mého názoru nejméně snižuje propustnost systému je zámek daného řádku v nadřízené tabulce. (SELECT FOR UP- DATE) Po vyhledání entity zkontrolujeme čísla verzí přicházejících z klienta. Pokud se liší, záznam byl upraven někým jiným a klient obdrží informaci. Pokud se neliší provedeme transformaci z Java objektů přicházejících z rozhraní do entitních objektů. Protože business logika bude připravovat odpověd pro klienta, v níž musí být osaženo vždy ID upravovaného záznamu a nově zvětšené číslo verze, je nutné donutit Entity

35 3.3. VRSTVA VÝKONNÉ LOGIKY 25 Manager, aby provedl veškeré změny ihned, a nečekal na konec transakce. Pokud by změny provedl až na konci transakce, která standardně nastává při zavolání return na business metodě, nemohli bychom v této metodě již připravit response. Příkazem EntityManager.flush(). tedy získáme aktuální číslo verze, které spolu s ID můžeme opět přetransformovat do objektů rozhraní a poslat na klienta. DELETE K mazání záznamů, stejně jako k úpravě, potřebujeme znát ID a číslo verze. Při mazání pacienta budeme provádět CASCADE DELETE všech záznamů, jinak by mohlo dojít k nekonzistencím. 5 Princip ale zůstává podobný jako při úpravě. Vyhledáme entitu a provedem test verzí. Pokud se neshodují, záznam nemůže být smazán, neb byl mezitím někým upraven. Při shodě můžeme záznam smazat. Pokud se bude jednat o pacienta, zkontrolujeme dle UC09 zda lékař, který pacienta odstraňuje je současně tím, kdo jej založil. Tuto informaci budeme uchovávat ve sloupci autupd. Pokud je vše v pořádku, smažeme záznam z databáze příkazem EntityManager.remove(). Pseudokód by vypadal nějak takto. Pacient p = EntityManager.find(Pacient.class, pacientid)...test verze zaznamu......test vlatnika zaznamu EntityManager.remove(p) Rozhraní webové služby Popsali jsme analyticky, jak bude fungovat jádro celého systému. Nyní se podíváme na rozhraní webové služby, které by mělo poskytovat funkce vyspecifikované v Use Case diagramu a zpřístupnit je jako webovou službu. I když je toto rozhraní součástí business logiky, věnuji mu speciální odstavec, protože bude sloužit jako vstupní bod do systému. Víme, které operace má systém poskytovat vzdáleným klientům. Abychom mohli vytvořit výkonnou logiku je potřeba vyspecifikovat co mají být vstupní a výstupní argumenty. Protože přenos bude probíhat v XML je potřeba navrhnout takové XML Schéma, které bude umožňovat objektově popsat request a response a zároveň bude obsahovat příslušné elementy odpovídající databázovým sloupcům. Abychom toto schéma nemuseli psát v jazyce XML můžeme použít JAXB 6 a v XML doladit případné detaily. JAXB umožňuje, na základě anotací, mapovat třídy v jazyce Java na XML objekty. Takto bychom v XML nadefinovali komplexní typ adresa jehož instanci by bylo možné zaslat v těle SOAP zprávy. <complextype name= CtAdresa > <complexcontent> <sequence> <element name= bydliste type= xs:string /> <element name= cp type= xs:string /> <element name= psc type= xs:string /> </sequence> 5 V databázi nemůže existovat podřízený záznam již neexistujícího pacienta 6 Java Architecture For XML Binding

36 26 KAPITOLA 3. ANALÝZA A NÁVRH IMPLEMENTACE </complexcontent> </complextype> Adekvátní javovská třída po zpracování Binding Compileru může vypadat = CtAdresa, proporder = { bydliste, cp, psc }) public class CtAdresa { protected String bydliste; protected String cp; protected String psc; } nám říká, že přístup serializátoru ke třídě je skrze proměnné a nikoliv skrze metody. Druhá anotace nám mapuje třídu na komplexní typ CtAdresa a určuje pořadí jednotlivých elementů v sekvenci. Typ xs:string je použit i na číselné položky proto, že na něj lze aplikovat regulární výrazy při validaci schématu. Je tak možné validovat délku případně vzor. Takto budeme tedy postupovat při definici rozhraní webové služby. Abychom nepoužívali společné datové typy jako adresa zvlášt pro pacienta a zvlášt pro lékaře, použijeme jmenné prostory a budeme se v nich odkazovat na jeden konkrétní datový typ. Jménné prostory jsou adekvátní javovským balíčkům. V XML schématu se pak místo konkrétního typu objeví reference na již nadefinovaný komplexní nebo jednoduchý typ. Protože tyto třídy budou velmi podobné třídám JPA, konečná transformace mezi nimi uvnitř business logiky bude o to snažší. V těle SOAP zprávy může být dle doporučení WS-I jen jeden kořenový XML element. Zabalíme tedy všechny informace nutné k přenosu do jednoho Java objektu, který v XML schématu bude reprezentován jedním komplexním typem. Rozhraní pak bude vypadat například public VyhledaniLekareResponse vyhledanilekare( VyhledaniLekareRequest public UlozeniLekareResponse ulozenilekare( UlozeniLekareRequest request)...atd... Nyní se podívejme, jak budou vypadat vstupní a výstupní argumenty u jednotlivých metod.

37 3.3. VRSTVA VÝKONNÉ LOGIKY 27 VYHLEDANI Vyhledávací metody budou vždy vracet seznam záznámů na základě nějakého vstupního filtru, který musíme přenést směr server. Součástí filtru budou vyhledávací kritéria. V případě lékaře či pacienta to budou položky jméno, příjmení a rodné číslo. V případě vyhledávání nemocí, kde bude umožněno stránkování, bude součástí filtru ID pacienta, maximální počet vrácených záznamů(velikost seznamu) a číslo databázové stránky. Směrem na klienta budeme předávat seznam vyhledaných položek. Přenášet se budou pouze základní data nutná k identifikaci osoby případně nemoci, nikoliv celá tabulka. Abychom předešli zahlcení sítě, budeme vždy v případě osob vracet prvních 100 záznamů. Pokud uživatel nedostane požadovaný záznam bude muset zúžit vyhledávací kritéria. V případě nemocí bude na 100 záznamů omezena maximální velikost stránky. Pokud klient zadá větší, bude tato velikost ignorována. NACTENI Načítací metody rozhraní budou jako vstup obsahovat vždy ID požadovaného záznamu. Jako výstup pak budou vracet data z příslušné tabulky. Abychom byli schopni určit, ze které tabulky máme data vzít, doplníme do vstupních argumentů atribut projekce. Mohli bychom samozřejmě přenášet veškeré údaje pacienta, ale tím bychom zbytečně zatěžovali nejen sít, ale také výpočetní kapacitu serveru. Atribut projekce bude v případě pacienta určovat, zda načítáme základní informace, složku praktického lékaře, případně konkrétní nemoc. Pro lékaře tento atribut nemá smysl, protože vždy načítáme všechny základní údaje, kterých není mnoho. Součástí odpovědi musí být též aktuální číslo verze daného záznamu. Toto číslo bude klient zasílat zpět při požadavku na úpravu či smazání. INSERT, UPDATE, DELETE Vzhledem k tomu, že tyto operace budou pracovat vždy se stejnou množinou dat, spojíme tyto tři operace do jedné a o konkrétním významu příchozího požadavku rozhodne atribut statement. Ten bude nabývat jak jinak než tří hodnot: INSERT, UPDATE a DELETE. Součástí požadavku s atributem INSERT a UPDATE musí být i ukládaná či upravovaná data. V případě UPDATE pak tento požadavek musí nést zároveň ID záznamu a verzi. V případě DELETE stačí ID a verze záznamu. Stejně jako při načítání jsme určovali projekcí konkrétní tabulku, nebo skupinu tabulek, použijeme projekci i pro tyto situace. V případě pacienta nám tak vzniká šest různých kombinací. Je vidět, že pokud bychom implementovali pro každou operaci zvlášt službu, mohli bychom u většího systému narazit na problém s přílišnou složitostí. CHYBOVÉ STAVY Zbývá rozhodnout, jak budeme postupovat v případě že nastane chyba. Je samozřejmě důležité, aby se klient dozvěděl, jak dopadl jeho požadavek. Pokud v systému nastane chyba kterou dokážeme rozpoznat, měla by být ve výstupní odpovědi obsažena. To můžeme zajistit dědičností. Každý objekt typu response bude například dědit od třídy BasicResponse, která obsahuje následující datový CtFault ) public class CtFault { private Integer errcode; private String errmessage; private String detail; }

38 28 KAPITOLA 3. ANALÝZA A NÁVRH IMPLEMENTACE Kdykoli nastane chyba, místo standardní odpovědi zašleme na klienta chybový kód, důvod chyby a detail. V případě některých RuntimeException, jako třeba NullPointerException 7 není žádoucí zasílat tyto informace na klienta. Proto budeme tyto výjimky odchytávat na nejvyšší vrstvě, a zabalíme je do naší specifické výjimky, do které vložíme zprávu srozumitelnější. Pokud například selže spojení s databází při vyhledávání lékaře. Vrátíme na klienta text Nepodařilo se vyhledat lékaře. Kontaktujte prosím administrátora. Protože naše aplikace je ukázková a žádného administrátora nemá, budeme zasílat na klienta část chybového výpisu, aby bylo možné při testování lépe odhalit příčinu chyby. 3.4 Prezentační vrstva Prezentační vrstvu bude tvořit vzdálený klient. V technologii JEE tuto vrstvu vetšinou obstarává webový kontejner na straně serveru. Stejně jako v EJB kontejneru zde existují komponenty, které jsou navržené převážně pro zpracování HTTP požadavků z klienta. Tyto komponenty se nazývají servlety. Celá komunikace probíhá tak, že servlet odbaví příchozí request, zjistí co klient požaduje a na základě toho zavolá příslušnou metodu na nižší vrstvě. V případě webové aplikace servlet na základě výsledku volání dané metody zformuje odpověd (nejčastěji ve formě HTML) a zašle zpět na klienta. Klientem může být například webový prohlížeč. V našem případě tomu nebude jinak, pouze s tím rozdílem, že komunikační protokol je SOAP. Servlet zachytí příchozí HTTP request směřující na adresu webové služby. Na základě definice webové služby ve WSDL (viz.2.3) se pokusí rozpoznat, které operaci má předat řízení. V našem systému reprezentují operace jednotlivé metody výkonné logiky. Protože metodám se nepředává XML, ale samotná data, ještě před tím, než servlet předá řízení metodám business logiky, musí vyparsovat příslušné informace z těla SOAP zprávy. Celý tento proces bude obstarávat modul JBossWS 8, který je součástí aplikačního serveru JBoss. Verze JBossWS 3.0.1, kterou budeme používat, v tuto chvíli téměř zcela následuje specifikaci JAX-WS 9. Tento modul tak poskytuje kompletní framework pro vývoj webových služeb v Javě. Umožňuje označit session beany speciálními anotacemi a tím je zpřístupnit jako webovou služby. Tím odpadá starost se psaním parsovacího enginu přesně dodržujícího specifikaci. Je samozřejmě možné napsat na základě specifkace vlastní modul pro zpracování SOAP protokolu, ale to není předmětem této práce. I když první kontakt s klientskou aplikací zajišt uje servlet, nelze příliš mluvit o prezentační vrstvě. Servlet zde spíše slouží jako dispatcher, který rozděluje jednotlivé požadavky. Webová vrstva serveru v tomto případě odpadá a dostáváme se tak k opravdové prezentační vrstvě, kterou v tomto případě představuje swingový klient Swingový klient Jak už název napovídá, klient bude implementován v programovacím jazyce Java s pomocí knihovny Swing. Úvodní obrazovka musí být přihlašovací se vstupními políčky username a password. Protože klient bude bezestavový, přihlášením se klient pouze doptá 7 Tyto chyby by nastávat neměly, ovšem nikdo není neomylný

39 3.5. BEZPEČNOST 29 webové služby jakou má v systému roli. Na základě toho přesměruje uživatele bud na obrazovku pro lékaře nebo na obrazovku pro administrátora. Pokud by uživatel měl více rolí, musel by se klient dotázat v jaké roli chce uživatel pracovat. Vzhledem k vyspecifikovaným dvěma rolím toto nebude implementováno. Obrazovky klienta budou kopírovat jednotlivé scénáře Use Case diagramu. Volání webových služeb jsou časově náročné operace a jako takové poběží v novém vlákně, abychom nebrzdili Event Dispatch Thread. Na vstupní políčka budou aplikovány validační metody, které zamezí uživateli zadání nesprávného vstupu. 3.5 Bezpečnost V kapitole 2.2 bylo ukázáno volání protokolu SOAP. SOAP přenáší pouze XML Dokumenty v normální textové podobě. V případě ostrého systému se ale může jednat o citlivá data pacientů a jako taková by měla být zabezpečena. K systému též nemůže přistupovat každý, proto je nutné nejprve provést autentizaci. Máme na výběr z těchto možností. Basic Autentizace Je založena na tom, že uživatel zašle v hlavičce protokolu HTTP své uživatelské jméno a heslo. Tyto jsou zakódovany pomocí Base64, což neposkytuje téměř žádnou ochranu před případným odposlechem. Proto se často kombinuje tento způsob a zabezpečení pomocí SSL/TLS. Digest autentizace Vznikla na základě požadované vyšší bezpečnosti, než kterou zajišt uje basic autentizace. V tomto případě klient zasíla pouze MD5 otisk uživatelského jména, hesla, řetězce který obdržel od serveru, HTTP metody daného požadavku a požadovaného URI 10. Certifikáty Protože protokol HTTP nezajišt uje potřebnou ochranu, používá se obvykle nižší vrstva, která zajišt uje šifrovanou komunikaci prostřednictvím certifikátů. K tomu slouží transportní protokol SSL případně jeho vylepšení TLS. Kromě těchto tří způsobů, které nabízí protokol HTTP, poskytují i WS-Security možnost zvanou UserToken, která posílá autentizační údaje v SOAP hlavičce. JBossWS framework však v době, kdy jsem začínal psát tuto práci, neumožňoval posílat tyto informace zabezpečené. Navíc by bylo nutné s klientem distribuovat další nativní knihovny, které by tyto údaje vkládaly do hlavičky SOAP zprávy. Proto jsem zvolil jako řešení HTTP basic autentizaci. Použití WS-Security ponechám jako možnost budoucího rozšíření. Vzhledem k tomu, že systém neudržuje žádný stav s klientem, při každém volání služby musí HTTP hlavička obsahovat autentizační údaje. Jak jsem již zmínil, tato komunikace není právě nejbezpečnější. Proto je lepší jako transportní protokol použít SSL případně TLS. HTTPS je však zabezpečení point-to-point a to může mít někdy své nevýhody. Rozšíření webových služeb WS-Security (viz kapitola 2.5) aplikuje šifrování přímo na elementy SOAP zprávy, čímž poskytuje zabezpečení i v případě že zpráva putuje k cíli přes jednotlivé prostředníky (multi-hop relay) nebo je uložena ve frontě či na disku. Navíc umožňuje přidat elektronický podpis, který zaručuje, že zpráva na své cestě k cíli nebude 10 Uniform Resource Identifier

40 30 KAPITOLA 3. ANALÝZA A NÁVRH IMPLEMENTACE modifikována. Tato rozšíření lze použít i v této aplikaci. Je však nutné vygenerovat certifikáty pro klienta a server a nastavit konfigurační soubory. V praxi by pak každý klient mohl mít certifikát uložený například na chipové kartě a ověření totožnosti by probíhalo prostřednictvím čtecího zařízení a chipové karty. Autorizaci tedy zajišt uje aplikační server na základě uživatelského jména a hesla zasílaného basic autentizací. Aby se klient dozvěděl jakou uživatelskou roli mu systém přidělil, dotáže se prostřednictvím webové služby. U bezestavové komunikace mě nenapadá jiná možnost jak toto zařídit. Klient potřebuje znát roli z toho důvodu, aby uživatele přesměroval na správnou obrazovku. Bud administrátorskou nebo lékařskou. V praxi by byl spíše implementován klient zvlášt pro roli administrátor a zvlášt pro roli lékař. Úkolem této je práce je však implementovat klienta pro ověření funkčnosti systému.

41 Kapitola 4 Popis implementace Pro implementaci jsem zvolil vývojové prostředí Eclipse 1 a pluginy pro spouštění aplikačního serveru JBoss, XML editor a CVS plugin. Aplikaci jsem rozdělil do dvou projektů. Projekt samotného systému a projekt klienta, který má ověřit funkčnost. Protože systém je vždy potřeba zabalit do specifických balíčků a provést deployment na server, použil jsem Ant 2, který umožňuje celý proces automatizovat. 4.1 Databázová vrstva Pro implementaci datové vrstvy jsem se rozhodl zvolit databázi PostgreSQL. Je to multiplatformní databázový systém s otevřeným zdrojovým kódem. Plně podporuje cizí klíče, indexy, vnořené dotazy a operace join. Umožňuje též použítí triggerů a funkcí. Mapování jednotlivých typů na konkrétní datové typy dané databáze zajišt uje konkrétní JDBC ovladač. Na základě entity diagramu byly vytvořeny následující tabulky. Tabulka PERSON CREATE TABLE person ( id int8 NOT NULL, datupd timestamp NULL, login varchar(255) NULL, passwd varchar(50) NOT NULL, jmeno varchar(255) NOT NULL, prijmeni varchar(255) NOT NULL, version int8 NULL, platny varchar(255) NOT NULL, autupd int8 NOT NULL, CONSTRAINT person_pkey PRIMARY KEY (id), CONSTRAINT fk_person_person FOREIGN KEY (autupd) REFERENCES person (id), CONSTRAINT person_login_key UNIQUE ( login ) );

42 32 KAPITOLA 4. POPIS IMPLEMENTACE V této tabulce jsou umístěni uživatelé systému, jejich hesla a přihlašovací jména doplněná o základní informace. Primárním klíčem je Id. Sloupec platny indikuje, zda daná osoba má platný účet či nikoliv. Přihlašovat do systému se mohou pouze lékaři či administrátoři s platným účtem. Mazání lékaře tak neprobíhá opravdovým odstraněním lékaře ze systému, nýbrž zneplatněním účtu. V případě, že bychom lékaře smazali, museli bychom smazat též všechny jeho pacienty. To však neodpovídá realitě. V každé tabulce je uchovávána informace, kdo (AUTUPD) a kdy (DATUPD) naposled data upravoval. Sloupec datupd se plní automaticky triggerem, který se spouští na operaci insert či update. Sloupec AU- TUPD bude vyplňován přes aplikaci a bude obsahovat vždy ID osoby, která záznam upravovala. V případě, že z aplikace nepřijde konkrétní ID, trigger vloží systémového uživatele. Ten bude založen současně se zakládacím skriptem a bude mít roli administrátor. Sloupec version slouží k optimistickému zamykání, o kterém bude řeč na konci tohoto odstavce. Tato tabulka je v programu reprezentována entitou Person.java. Protože sloupce AUTUPD a DATUPD jsou součástí každé entity a JPA využívá objektového přístupu byla pro tyto dva sloupce vytvořena abstraktní třída BasicEntity.java, od které každá entita dědí. Tato entita byla označena která zajístí, že nebude ovlivněna struktura tabulek. Sloupec AUTUPD je v této entitě namapován na tabulku PERSON následující protected Person autupd; Kromě toho, jak se sloupec bude jmenovat nám anotace říkají, že daná osoba může být autorem updatu u více stejných entit a naopak každá entita musí mít právě jednoho autora updatu. Parametr fetch zajistí, že při každém dotažení entity se nebude zároveň dotahovat i osoba, která ji naposledy upravila. Tabulka ROLES CREATE TABLE roles ( id int8 NOT NULL, datupd timestamp NULL, role varchar(255) NULL, autupd int8 NOT NULL, login varchar(255) NOT NULL CONSTRAINT roles_pkey PRIMARY KEY (id), CONSTRAINT fk_roles_person_login FOREIGN KEY ( login ) REFERENCES person ( login ), CONSTRAINT fk_roles_person_id FOREIGN KEY (autupd) REFERENCES person (id) ); V této tabulce jsou umístěny uživatelé ve vztahu k rolím. Cizí klíč na sloupci LOGIN napovídá, že uživatel může mít více rolí a NOT NULL značí, že každá konkrétní role musí mít uživatele. Opět jsou zde sloupce DATUPD a AUTUPD pro uchování času poslední úpravy a autora této úpravy, což je ID do tabulky PERSON, tedy ID konkrétního účtu uživate. Tato tabulka je v programu reprezentována entitou Roles.java. Sloupec LOGIN je namapována následující anotací.

43 4.1. DATABÁZOVÁ VRSTVA protected Person user; Parametr cascade říká, že současně s rolí má být vložen i uživatelský účet. Parametr optional říká, že nesmí existovat role bez uživatele. Tabulka LEKAR CREATE TABLE lekar ( id int8 NOT NULL, titul varchar(255) NOT NULL, rc varchar(10) NOT NULL, adresa_fk int8 NULL, CONSTRAINT lekar_pkey PRIMARY KEY (id), CONSTRAINT fk_lekar_adresa FOREIGN KEY (adresa_fk) REFERENCES adresa (id), CONSTRAINT fk_lekar_person FOREIGN KEY (id) REFERENCES person (id), CONSTRAINT lekar_rc_key UNIQUE (rc) ); Tabulka LEKAR má s tabulkou PERSON společný primární klíč, což indikuje, že LEKAR je též uživatelem a může se přihlásit do systému, pokud má platný účet. JPA toto umožňuje opět zajistit dědičností. na tabulce PERSON říká, že pro jakýkoliv záznam, který od ni dědí, se použije zvlášt tabulka. RC je zde unikátní klíč, tudíž nemohou existovat dva lékaři se stejným rodným číslem. Tato tabulka je reprezentována entitou Lekar.java. Adresa je namapována protected Adresa adresa; Parametr cascade říká, že chceme adresu upravovat zároveň při volání persist či merge na entitě Lékař. Protože při načítání lékaře vždy budeme potřebovat současně adresu, necháme parametr fetch na defaultní hodnotě (EAGER). V praxi to znamená, že JPA provider vygeneruje namísto dvou selektů pouze jeden s operací JOIN.

44 34 KAPITOLA 4. POPIS IMPLEMENTACE Tabulka ADRESA CREATE TABLE adresa ( id int8 NOT NULL, datupd timestamp NULL, bydliste varchar(33) NULL, cp varchar(15) NULL, psc varchar(5) NULL, version int8 NULL, autupd int8 NOT NULL, CONSTRAINT adresa_pkey PRIMARY KEY (id), CONSTRAINT fk_adresa_person FOREIGN KEY (autupd) REFERENCES person (id) MATCH SIMPLE ); Tato tabulka opět obsahuje sloupec VERSION, který slouží pro optimistické zamykání. Data jsou součástí základních informací pacienta a lékaře a může zde tedy nastávat konkurentní přístup. Tato tabulka je reprezentována entitou Adresa.java. Tabulka PACIENT CREATE TABLE pacient ( id_pacient int8 NOT NULL, datupd timestamp NULL, jmeno varchar(255) NOT NULL, prijmeni varchar(255) NOT NULL, rc varchar(255) NOT NULL, birth date NULL, telefon varchar(255) NULL, krevni_skupina varchar(255) NULL, rh_faktor varchar(255) NULL, poznamky varchar(255) NULL, version int8 NULL, autupd int8 NOT NULL, adresa_fk int8 NULL, pl_id int8 NULL, id_pojistovny varchar(255) NULL, CONSTRAINT pacient_pkey PRIMARY KEY (id_pacient), CONSTRAINT fk_pacient_adresa FOREIGN KEY (adresa_fk) REFERENCES adresa (id) CONSTRAINT fk_pacient_cis_pojistovny FOREIGN KEY (id_pojistovny) REFERENCES cis_pojistovny (kod_pojistovny) CONSTRAINT fk_pacient_person FOREIGN KEY (autupd) REFERENCES person (id) CONSTRAINT fk_pacient_prakt_lekar FOREIGN KEY (pl_id) REFERENCES prakt_lekar (id) CONSTRAINT pacient_rc_key UNIQUE (rc) );

45 4.1. DATABÁZOVÁ VRSTVA 35 Pacient je tedy výchozí tabulka pro všechny podřízené záznamy, se kterými lékař může pracovat. Základní informace se budou získávat přímo z této tabulky a zároveň z tabulky adresa, která je s touto spojena cizím klíčem adresa fk. Na záznamy praktického lékaře ukazuje cizí klíč pl id. Sloupec datupd opět uchovává datum vkládaného případně upravovaného záznamu. Sloupec autupd odkazuje do tabulky PERSON na identifikátor lékaře, který založil tohototo pacienta. Zde provedeme výjimku a do tohoto sloupce zapíšeme pouze při vkládání nového záznamu. Je to proto, že chceme uchovávat informaci o tom, který lékař pacienta založil. Pouze ten je oprávněn pacienta smazat, případně upravit jeho základní údaje. Spojení na číselník pojišt oven je přes cizí klíč id pojistovny. Protože kód pojišt ovny je v tomto číselníku unikátní a je tedy primárním klíčem, vkládá se do tabulky PACIENT přímo tento kód. Tato tabulka je reprezentována entitou Pacient.java. Číselník zdravotních pojišt oven je namapován protected CisZdrPojistovny zdravotnipojistovna; Adresa je opět ve vztahu jedna ku jedné a všechny operace na osobě se propagují i na protected Adresa adresa; Složka praktického může být pouze jedna a není žádoucí ji dotahovat vždy zároveň s protected PraktickyLekar praktickylekarinfo; Každý pacient může mít více chorob a při vložení nemoci do seznamu požadujeme založení i příslušného záznamu v tabulce NEMOC. Vlastníkem vztahu je entita Nemoc a v ní pole pacient, které drží cizí mappedby= pacient ) protected List<Nemoc> nemoci; Tabulka PRAKT LEKAR CREATE TABLE prakt_lekar ( id int8 NOT NULL PRIMARY KEY, datupd timestamp NULL, vaha varchar(255) NOT NULL, vyska varchar(255) NOT NULL, nestovice bool NOT NULL, priusnice bool NOT NULL, spala bool NOT NULL, spalnicky bool NOT NULL, zardenky bool NOT NULL, version int8 NULL, autupd int8 NOT NULL, CONSTRAINT fk_prakt_lekar_person FOREIGN KEY (autupd) REFERENCES person (id) );

46 36 KAPITOLA 4. POPIS IMPLEMENTACE Zde jsou uveny informace ze složky praktického lékaře. Zda byl pacient očkován či kolik měřil nebo vážil při preventivní prohlídce. Opět zde musíme počítat s konkurentním přístupem a umístit zde sloupec VERSION. Tato tabulka je reprezentována entitou PraktickyLekar.java. Tabulka CIS POJISTOVNY CREATE TABLE cis_pojistovny ( kod_pojistovny varchar(255) NOT NULL, datupd timestamp NULL, nazev varchar(255) NULL, autupd int8 NOT NULL, CONSTRAINT cis_pojistovny_pkey PRIMARY KEY (kod_pojistovny), CONSTRAINT fk_cis_pojistovny_person FOREIGN KEY (autupd) REFERENCES person (id) ); Funkci číselníku zdravotních pojišt oven, jsem vysvětlil v kapitole 3. Zde bych jen poznamenal, že primárním klíčem bude samotný kód pojišt ovny. Ten by měl být unikátní. Název pojišt ovny slouží spíš jako dokumentační sloupec. Tato tabulka je reprezentována entitou CisZdrPojistovny.java. Přístup k číselníku z webové služby nezajišt ují metody session beany nýbrž speciální DAO 3 objekt implementovaný jako singleton. Ten je vytvořen pouze jednou a při každém dotazu použije volné databázové spojení z connection poolu. Maximální velikost connection poolu aplikačního sereru JBoss ve standardním nastavení je 20, což pro tuto aplikaci plně postačí. Pokud by bylo současně využito 20 spojení, další klienti by museli čekat na uvolnění jednoho z nich. Výhodou použití DAO objektu jsou rychlé dotazy přímo na vrstvě JDBC. Tabulka CIS DIAGNOZA CREATE TABLE cis_diagnoza ( kod_diagnoza varchar(255) NOT NULL, datupd timestamp NULL, nazev varchar(255) NULL, popis varchar(255) NULL, poznamka varchar(255) NULL, kod_skdiagnoza varchar(255) NULL, pohlavi varchar(255) NULL, autupd int8 NOT NULL, CONSTRAINT cis_diagnoza_pkey PRIMARY KEY (kod_diagnoza), CONSTRAINT fk_cis_diagnoza_person FOREIGN KEY (autupd) REFERENCES person (id) MATCH SIMPLE ); 3 Data Access Object

47 4.1. DATABÁZOVÁ VRSTVA 37 Číselník diagnóz bude sloužit podobnému účelu jako číselník pojišt oven. Obsahuje kód diagnózy z tabulky NEMOC. Klient bude moci uložit pouze nemoc, jejíž diagnóza je v tomto číselníku. Pro přístup z webové služby bude opět vytvořen DAO objekt. Tato tabulka je reprezentována entitou CisDiagnoza.java Tabulka NEMOC CREATE TABLE nemoc ( id_nemoc int8 NOT NULL, datupd timestamp NULL, kod varchar(255) NOT NULL, datumod timestamp NULL, datumdo timestamp NULL, poznamka varchar(255) NULL, stav varchar(255) NULL, pacient_fk int8 NOT NULL, version int8 NULL, autupd int8 NOT NULL CONSTRAINT nemoc_pkey PRIMARY KEY (id_nemoc), CONSTRAINT fk_nemoc_cis_diagnoza FOREIGN KEY (kod) REFERENCES cis_diagnoza (kod_diagnoza) CONSTRAINT fk_nemoc_pacient FOREIGN KEY (pacient_fk) REFERENCES pacient (id_pacient) CONSTRAINT fk_nemoc_person FOREIGN KEY (autupd) REFERENCES person (id) ); Daná nemoc nesmí existovat bez diagnózy a bez pacienta. Pro stejného pacienta bychom měli zamezit duplicitě v kódu diagnózy. Pacient může trpět více chorobami, ale něměl by mít dvakrát stejnou diagnózu. Toto provedeme v aplikační vrstvě. Mapování entity je následující. Tento typ má defaultně nastaven EAGER loading, tj. při dotažení nemoci se zároveň dotáhne kód protected CisDiagnoza kod; Tato entita je též vlastníkem cizího klíče na tabulku PACIENT. Při dotažení nemoci budeme potřebovat zároveň ID a verzi pacienta. Proto použijeme defaultní = pacient_fk, nullable = false) protected Pacient pacient; Optimistické zamykání Optimistické zamykání se nejčastěji implementuje přidáním dalšího sloupce do kterého se zapisuje takzvaná verze záznamu. Verze je číslo, které se inkrementuje při každém zápisu do dané tabulky. Při načítání dat je číslo verze získáno a odesláno na klienta. Klient poté upraví záznam a odešle zpět na server s původním číslem verze. Pokud se verze shodují může proběhnut úprava v databázi. Pokud se verze

48 38 KAPITOLA 4. POPIS IMPLEMENTACE liší, znamená to, že záznam byl mezitím upraven. JPA provider umožňuje takto kontrolovat sloupce označené Tento sloupec je použit na všech tabulkách, které mohou být editovány na klientském systému a kde se předpokládá konkurentní přístup. Kompletní zakládací schéma včetně triggerů, sekvencí a s konkrétními datovými typy pro PostgreSQL je umístěno na přiloženém CD. Triggery jsou použity pro plnění sloupců AUTUPD a DATUPD. Trigger na AUTUPD se spustí jen v případě, že vstupující ID je null. Například pro uživatele administrator vkládáného přes zakládací skript. Sekvence jsou nastaveny na počáteční hodnotu deset. ID administrátora je 1 a v případě, že bychom nastavili počáteční hodnotu sekvence v tabulce PERSON na 0 mohlo by prvním vložení uživatele dojít k porušení unikátnosti na sloupci primárního klíče. Skript obsahuje též naplnění číselníků. 4.2 Vrstva výkonné logiky Dále následuje výpis jednotlivých tříd a metod, které budou provádět operace na straně serveru. Na konci každé operace se zaloguje její názav a doba trvání. Logování poskytuje lepší orientaci a hledání přičiny v případě chyby, ale také lepší ladění a optimalizaci ve fázi vývoje. LekarBean.java Jak již bylo řečeno v analýze, tato komponenta obluhuje požadavky administrátora. Protože administrátor pracuje s údaji lékaře, nazval jsem třídu LekarBean.java. Obsahuje 3 business metody, které obstarávají jednotlivé požadavky. public VyhledaniLekareResponse findlekar(vyhledanilekarerequest req); Tato metoda nejprve provede validaci vstupních dat na základě regulárních výrazů a poté se pokusí vyhledat požadované záznamy. Databázový select je omezen na 100 záznamů, abychom nezahltili databázi a stejně tak je omezen i seznam nalezených lékařů, které zasíláme na klienta. Tady zase hrozí zahlcení sítě. Tato metoda generuje pouze jeden databázový select a je tedy zbytečné, aby běžela v transakci. Proto má nastaven transakční scope na NOT_SUPPORTED. Vyhledávací dotazy byly implementovány pro lepší efiktivitu a znovupoužitelnost. public UlozeniLekareResponse savelekar(ulozenilekarerequest req); Tato metoda nejprve provede validaci vstupních dat, na základě regulárních výrazů. Před tím, než zkontroluje unikátní klíče zamkne tabulku person pro zápis. Poté na základě atributu Statement provede příslušnou operaci typu INSERT, UPDATE, DELETE. V případě UPDATE a DELETE též zkontroluje čísla verzí. Protože je zapisováno do více tabulek současně je nutné, aby tato metoda běžela v transakci. To zajistíme anotací REQUIRES_NEW, což způsobí start nové transakce a v případě chyby odrolování všech databázových změnových operací. public NacteniLekareResponse getlekar(nactenilekarerequest req);

49 4.2. VRSTVA VÝKONNÉ LOGIKY 39 Tato metoda nejprve provede validaci vstupních dat, na základě regulárních výrazů. Protože zde jsou načítány záznamy z různých tabulek metodou LAZY, je nutné zajistit konzistenci načítaných dat. K tomu poslouží zámek na entitě lékař. Protože LAZY loading vyžaduje běh uvnitř transakce, transakční scope bude REQUIRES_NEW. S načítanými daty předává metodám rozhraní též ID záznamu a číslo aktuální verze. PacientBean V případě role lékař bude beana trochu složitější. Lékař má totiž možnost upravovat i záznamy z jiných tabulek. Nejednoduší metoda je opět ta vyhledávací. public VyhledaniPacientResponse findpacient(vyhledanipacientrequest req) Tato metoda nejprve provede validaci vstupních dat na základě regulárních výrazů. Na základě vstupního filtru se se pokusí vyhledat dané záznamy. V případě pacienta je filtr tvořen rodným číslem, jménem či příjmením. V případě nemocí se vyhledává jejich seznam pro zadané ID pacienta. Protože JPA provider umožňuje stránkování, využil jsem tuto možnost a seznam nemocí bude možné získávat postupně. Vstupní filtr bude též obsahovat číslo požadované stránky a velikost seznamu. Tu jsem omezil na maximální hodnotu 100. Tato metoda v případě základní projekce generuje pouze selecty. V případě vyhledání nemocí je nutné zkontrolovat, zda pacient stále existuje. Abychom zajistili integritu mezi dotazem do tabulky pacient a dotazem do tabulky nemoc je nutné záznam pacienta zamknout. Vzhledem k použití LAZY načtení pacienta tato metoda poběží v transakci REQUIRED. public NacteniPacientResponse getpacient(nactenipacientrequest req) Tato metoda nejprve provede validaci vstupních dat, na základě regulárních výrazů. Atributy projekce a ID záznamu vstupující z requestu jednoznačně určují záznam, který klient požaduje. Protože v případě pacienta se využívá LAZY loading podřízených záznamů, je nutné použít zámek na nadřízené entitě. Zámek bude pro zápis a bude aplikován na konkrétního pacienta, tak aby neovlivňoval ostatní řádky. Kdokoliv bude chtít upravit pacienta případně pracovat s jeho daty rozloženými ve více tabulkách, bude muset nejprve získat tento zámek. Pokud bychom se chtěli vyhnout použití zámků, museli bychom načítat data atomicky. public UlozeniPacientResponse savepacient(ulozenipacientrequest req) Tato metoda nejprve provede validaci vstupních dat, na základě regulárních výrazů. Na základě atributu projekce a atributu statement provede příslušnou operaci INSERT, UPDATE, DELETE. V případě vkládání pacienta či složky praktického lékaře není co zamykat. Unikátnost rodného čísla je zajištěna přímo na sloupci v databázi a při pokusu o vložení již existujícího čísla odchytíme výjimku. V případě vkládání nemoci musíme ověřit, zda pro tohoto pacienta již stejná diagnóza nebyla stanovena. Abychom nemuseli zamykat celou tabulku NEMOC pro zápis a tím omezovat ostatní lékaře, aplikujeme zámek na entitu pacienta. V případě úpravy a odstranění jakéhokoliv záznamu opět použijeme zámek na nadřízené entitě, kterou je pacient. Transakční scope je nastaven na REQUIRES_NEW, což zajišt uje start nové transakce a v případě chyby odrolování všech databázových změnových operací.

50 40 KAPITOLA 4. POPIS IMPLEMENTACE NemServiceBean Tato komponenta reprezentuje rozhraní webové služby. Představuje vstupní bod do systému a rozděluje požadavky na základě rolí. Má nastaven transakční scope na NOT_SUPPORTED. Veškeré transakce se tedy startují až s metodami tříd PacientBean a LekarBean. Je tak zaručeno, že chybové stavy, které nastávají až po skončení transakce, mohou být v této komponentě odchyceny. Metody rozhraní vyhazují výjimku ServerException, která může být zobrazena na klientském systému jako chybová zpráva. Ostatní výjimky vzniklé například při validaci, kdy se aplikační logika nedostala vůbec do hry, se na klientovi zaobalí do obecné zprávy pro uživatele. Například Chyba v systému. Kontaktujte administrátora. Rozhraní tedy vystavuje celkem šest metod business logiky plus jedné metody pro autorizaci uživatele. Další dvě služby umožňují dotahovat data z číselníku diagnóz a zdravotních pojišt oven. Protože klient tyto položky vyplňuje ve formulářích, je důležité, aby hodnoty v číselnících byly totožné. To zaručíme dotažením aktuálních dat přímo ze serveru. Pokud bychom tyto dvě služby postavili mimo bezpečnostní doménu, která v tuto chvíli vyžaduje autentizaci a zabraňuje tak anonymnímu přístupu, mohly by je tak využít i další okolní systémy. Prostřednictvím anotací aplikačního serveru JBoss, zajistíme, aby webová služba byla zpřístupněna pod námi definovaným services,urlpattern= /NemService )... Jakákoliv SOAP zpráva směřující na tuto adresu je odchycena servletem a v případě, že souhlasí autentizační údaje, přetransformována z XML do Java objektů a zaslána ke zpracování nižší vrstvě. Celé rozhraní je popsáno jazykem WSDL a najdete jej v příloze C. Součástí jsou i XML schémata pro jednotlivé komplexní či jednoduché typy. Transformační třídy Rozhraní netvoří jen samotná NemServiceBeana, ale také třídy do kterých se transformují XML objekty. Jak již bylo popsáno v analýze jsou to třídy, které umožňují mapovat Java objekty na XML dokumenty. Protože z těchto objektů musíme přetransformovat vstupní data do entitních objektů, je nutné vytvořit transformace. V případě změny rozhraní například přidáním elementu je snadné upravit pouze tuto transformaci namísto všech roztroušených výskytů daného elementu v aplikaci. Z toho důvodu je dobré umístit transformaci do jednoho místa. Zvolil jsem tedy přímo tyto třídy rozhraní, které po převodu z XML budou obsahovat formulářová data z klienta. V business metodě pak stačí zavolat příslušnou transformační metodu, která vrátí přímo naplněný entitní objekt, který do této transformace vstupuje. Podobně se postupuje i v opačném případě. Abychom nemuseli dvakrát parsovat číslo verze, vrací tyto transformační metody boolean hodnotu, která informuje business logiku, zda vyhovují čísla verzí upravovaného objektu. V případě, že ne, je zformována chybová odpověd a informován klient. Pro transformaci základních datových typů, například Long a String, byl zvolen systém adaptérů. ID v entitním objektu je typu Long, avšak do XML ho tranformujeme jako xs:string. Je to z toho důvodu, že na řetězce lze aplikovat regulární výraz. Dále xs:string je v hierarchii typů základním typem. Zatímco xs:long je odvozený dvojitou restrikcí a hrozí, že ne všechny implementace webových služeb jej budou umět správně

51 4.3. PREZENTAČNÍ VRSTVA 41 vyparsovat. JBossWS, stejně jako referenční implementace JAX-WS, pro tyto případy umožňuje vytvořit třídu adaptérů, ve které můžeme specifikovat jednotlivé transformace. public static class LongAdapter extends XmlAdapter<String, Long> // java to xml public String marshal(long v) throws Exception { return v.tostring(); } // xml to java public Long unmarshal(string v) throws Exception { return Long.parseLong(v); } Tento adaptér lze aplikovat použitím anotace přímo v konkrétní třídě UlozeniPacientRequest ) public class UlozeniPacientRequest protected Long id;... } 4.3 Prezentační vrstva Klient má k dispozici definici webové služby ve formě WSDL, na základě které je schopný volat jednotlivé metody rozhraní. Aby klient mohl odesílat a přijímat SOAP zprávy, potřebuje také umět transformovat z Java objektů do XML a naopak. Moderní jazyky typu Java a.net a jejich vývojové nástroje často umí vygenerovat tyto třídy přímo z WSDL automaticky. JBossWS k tomu poskytuje dávkový soubor wsconsume.bat, který uvnitř používá příslušnou knihovnu. Po aplikaci na WSDL soubor máme tedy na klientovy přesný obraz rozhraní serveru spolu s třídou, která umožňuje zavolat webovou službu. Takto vygenerované spojky jsou často nedostatečné. Neobsahují atributy pro nastavení autentizace a šifrování a je proto nutné je do kódu dopsat. Zprávu je pak možné odeslat naplněním vstupních objektů a zavoláním příslušné metody, např. vyhledanilekare. Odpověd získáme v návratovém Java objektu, který můžeme snadno přetransformovat do formulářových polí. K implementaci samotného volání a transformace byla použita třída SwingWorker, která umožňuje spouštět výkonově náročné operace v samotném vlákně. Stránkování v případě nemocí bylo implementováno kompletně na klientovi. Klient načte ze serveru o jeden záznam více, než pak zobrazí na obrazovce. V případě že načtené údaje obsahují více záznamů než zobrazujeme, zpřístupní se tlačítko další stránka. Pro udržení čísla stránky je využita statická Cache implementovaná jako rozhraní. Tu používají všechny třídy, u kterých je potřeba udržovat stav. Bezestavový klient si tak uchovává posledně načteného pacienta a jeho verzi. Při přesunu z jedné editační záložky

52 42 KAPITOLA 4. POPIS IMPLEMENTACE na druhou tak klient umožňuje přímo volat načítací metody na serveru a tím obejít proces vyhledávání. V případě, že mezi tím někdo pacienta odstraní, je server připraven o tom klienta informovat a ten zareaguje přesměrováním uživatele na vyhledávací obrazovku. Obrázek 4.1: Klient - Založení pacienta