'. Univerzita Karlova v Praze Filozofická fakulta Ústav informačních studií a knihovnictví Studijní program: informační studia a knihovnictví Studijní obor: informační studia a knihovnictví Vladimír Fiala Webové služby a návrh jejich realizace v systému ODS pro objednávku digitalizovaného dokumentu Diplomová práce Praha 2006
'. Vedoucí diplomové práce: PhDr. Jiří Kaplický Oponent diplomové práce: Datum obhajoby: Hodnocení: 2
Vysoká škola: Univerzita Karlova v Praze Fakulta: Filozofická fakulta Součást: Ústav informačních studií a knihovnictví Školní rok: 2005/2006 ZADÁNÍ DIPLOMOVÉ PRÁCE (PROJEKTU, UMĚLECKÉHO DÍLA, UMĚLECKÉHO VÝKONU) pro obor Vladimír Fiala Informační studia a knihovnictví Název tématu: Webové služby a návrh jejich realizace v systému DDS pro objednávku digitalizovaného dokumentu Zásady pro vypracování: Cílem práce je objasnit princip fungování webových služeb jako moderního prostředku komunikace aplikací a navrhnout možné řešení objednávkového systému DDS Státní technické knihovny pomocí této teclmologie. Návrh by mohl sloužit jako podklad pro skutečnou implementaci do systému DDS Státní technické knihovny. Předběžná osnova práce: 1. Popis webových služeb (Jazyk XML, Protokol SOAP, Popis webové služby WSDL, Registr UDDI) 2. Přehled současného stavu řešení systému STK/DDS 3. Návrh řešení WS objednávkového systému pro STKIDDS 4. Zhodnocení Práce bude připravena a upravena v souladu s platnými vnitřními předpisy FF UK a dalšími metodickými pokyny a normativními dokumenty. ([EVi'] 49 395 O 1/2001 Tisk: Rapy 0078/2001
~-;- Rozsah grafických prací: Rozsah průvodní zprávy: Seznam odborné literatury: 1. KREGER, H. Web Services Conceptual Architecture (WSCA 1.0) [online]. May 2001 [cit. 2005-10-25]. 41 s. Dostupné z WWW: <httg://www-306.ibm.com/software/solutions/webservices/gdf/wsca.pdf> 2. JIROUŠ, V. Webové služby v knihovnictví. ln Automatizace knihovnických procesů- 10.: sborník z 10. ročníku semináře pořádaného ve dnech 3.-4. května 2005 v Liberci. Praha: ČVUT- Výpočetní a informační centrum, 2005, s. 33-43. Dostupné také z WWW: <httg://www.akvs.cz/akp-2005/06- jirous.gdf>. ISBN 80-01-03228-03 3. Document De/ivery Systém : kompletní dokumentace [online]. Vypracováno pro STK Praha. Praha : česká informační společnost, listopad 2002 [cit. 2005-10-25]. 54 s. Dostupné z WWW: <http://www.stk.cz/li01 018/PopisDDS.doc> Vedoucí diplomové práce: )PhDr..J i~~()kaplický... / i r;,. /// i/ Datum zadání diplomové práce: 2.11.2005 Termín odevzdání diplomové práce: L.S.... Vedoucf součásti-ředitel ÚISK FF UK V Praze dne 2.11.2005
)-25]. > {z 10. Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité informační zdroje. V Praze, 20. března 2006 podpis diplomanta 3
ldentiiikační záznam FIALA, Vladimír. Webové služby a návrh jejich realizace v systému DDS pro objednávku digitalizovaného dokumentu [Web services and design of their implementation in DDS system for digital document order]. Uherské Hradiště, 2006. 93 s., 20 s. příl. Diplomová práce. Univerzita Karlova v Praze, Filozofická fakulta, Ústav informačních studií a knihovnictví 2006. Vedoucí diplomové práce PhDr. Jiří Kaplický. Abstrakt Tématem práce je popis technologie webových služeb a jejich začlenění do systému dodání kopie digitalizovaného dokumentu (DDS) ve Státní technické knihovně. Cílem práce je objasnit princip fungování webových služeb jako prostředku pro komunikaci a přenosu informací napříč systémy, jejich aplikačm'ho využití a navrhnout řešení pomocí této technologie do zmíněného systému DDS. Technologie webových služeb je tvořena třemi základními komponentami - komunikačním protokolem SOAP (Simple Object Access Protocol), dokumentem pro jejich popis WSDL (Web Services Description Language) a registry služeb UDDI (Universa! Description, Discovery, and Integration). Tento komunikační a funkční model je vystavěn na značkovacím jazyku XML, jehož část týkající se webových služeb je v práci popsána. Jde o problematiku syntaxe XML, definice datových typů, jmenné prostory a schémata XML. Součástí práce je rovněž přehled o systému DDS obecně a popis a analýza stávajícího řešení systému DDS Státní technické knihovny. Na základě popisu funkcionality webových služeb je zpracován návrh do sytému DDS Státní technické knihovny ve formě WSDL dokumentu, který by mohl sloužit jako základ pro skutečnou implementaci webových služeb v STK. Dále je znázorněn možný popis služeb v registru UDDI. Závěr práce shrnuje představené řešení a jsou nastíněny možnosti dalšího vývoje webových služeb v informační a knihovnické sféře. Klíčová slova web services, SOAP, WSDL, UDDI, XML, schema, protocol, registry 4
OBSAH PŘEDMLUVA 1 Úvod... 9 2 Webové služby... 10 2.1 Koncept servisně orientované architektury SOA... 1 O 2.2 Model WS... ll 2.3 Jazyk XML... 14 2.3.1 Syntaxe XML... 15 2.3.2 Objektový model dokumentu DOM... 17 2.3.3 SAX... 19 2.3.4 Jmenné prostory... 20 2.3.5 SchémataXML-XSD... 23 2.4 SOAP... 28 2.4.1 Uzly a role... 31 2.4.2 SOAP Message... 31 2.4.2.1 Element Envelope... 33 2.4.2.2 Element Header... 34 2.4.2.3 Element Body... 35 2.4.2.4 Element Fault... 35 2.5 WSDL... 36 2.5.1 Definice služby... 38 2.5.1.1 Element Types... 38 2.5.1.2 Element Messages... 39 2.5.1.3 Element porttype... 40 2.5.1.4 Elementbinding... 42 2.5.1.5 Element port... 43 2.5.1.6 2.5.2 Element service... 43 SOAP Bindings... 44 2.6 UDDI... 45 2.6.1 Historie... 46 2.6.2 Princip fungování UDDI.... 47 2.6.3 Datový model UDDI.... 48 5
2.6.3.1 Entita businessentity... 49 2.6.3.2 Entita businessservice... 50 2.6.3.3 Entita bindingtemplate... 51 2.6.3.4 Entita tmodel... 52 2.6.3.5 Entita publisherassertion... 55 2.6.3.6 Entita operationallnfo... 55 2.6.4 Klasifikační a identifikační systém UDDI..... 56 2.6.4.1 Identifikační systém UDDI..... 56 2.6.4.2 Klasifikační systém UD DI... 58 2.6.5 Typy registrů UDDI... 58 3 Současný stav řešení systému DDS v STK... 60 3.1 Systém DDS... 60 3.1.1 Úvod... 60 3.1.2 Přehled poskytovatelů služeb DDS... 61 3.2 Analýza stávajícího řešení systému DDS STK... 62 3.2.1 Dekompozice systému DDS... 62 3.2.2 Technologické zázemí systému DDS STK... 63 3.2.3 Programové řešení DDS STK... 64 4 Návrh rozhraní objednávkového systému DDS pomocí webových služeb... 70 4.1 Analýza problému... 70 4.1.1 EntityWS...,... 70 4.1.2 Datový model databáze DDS STK... 71 4.1.3 Definice XML schématu... 73 4.1.3.1 Element Objednávka... 73 4.1.3.2 Element Uživatel.... 75 4.1.3.3 Element Účet uživatele... 76 4.1.4 Definice kandidátů na služby... 77 4.1.4.1 Služba zadání nové objednávky... 79 4.1.4.2 Služba úpravy objednávky... 81 4.1.4.3 Služba zrušení objednávky... 82 4.1.4.4 Služba zjištění stavu objednávky... 83 4.1.4.5 Služba vyzvednutí objednávky- digitalizovaného dokumentu... 84 4.1.4.6 Služba zm_ěny registrace... 84 4.1.4.7 Služba zrušení registrace... 85 6
4.1.4.8 Služba získání uživatelského přehledu objednávek... 86 4.1.4.9 Služba získání uživatelského přehledu o stavu účtu... 87 4.1.5 Registrace služby v registrech UDDI... 88 4.1.5.1 Mapování entity porttype... 88 4.1.5.2 Mapování entity binding... 89 4.1.5.3 Mapování do entit businessservice a bindingtemplate... 90 5 Závěr... 92 7
PŘEDMLUVA Tato diplomová práce se zabývá principy fungování a archiú~kturou webových služeb a jejich následným využitím pro návrh systému dodání kopie digitalizovaného dokumentu Státní technické knihovny v Praze. Jde o technologii, která umožňuje komunikaci informací napříč systémy, jejich následné aplikační zpracování a začíná se čím dál více uplatňovat i v informační a knihovnické oblasti. Podnětem pro tuto práci byla skutečnost, že právě STK by chtěla nabídnout za pomoci této funkcionality službu typu DDS a vypracovaný návrh by mohl sloužit jako základ tohoto systému. Podkladem pro tuto práci byly články, analýzy, studie, standardy a specifikace zabývající se problematikou webových služeb a příbuzných technologií. Cílem této diplomové práce je podat ucelený popis této technologie a vytvořit návrh WSDL rozhraní budoucího systému DDS postaveného na webových službách. Zmíněny jsou nejen současné standardy, případně návrhy těchto standardů a jejich aplikace, ale i možné směry dalšího vývoje. Diplomová práce je rozdělena do pěti kapitol včetně úvodu a závěru. První část pojednává o konceptu webových služeb a servisně orientované architektury (SOA). Je probrána tematika jazyka XML, která se vztahuje k problematice WS a dále hlavní komponenty, na kterých je tato technologie vystavěna - SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) a UDDI(Web Services Description Language). V další části je obecně pojednáno o systému DDS a jeho současné implementaci v STK Praha. Poslední část je věnována vlastnímu návrhu klientské části systému DDS na úrovni WSDL rozhraní. Rozsah diplomové práce je 93 stran a 20 stran příloh. Informační zdroje jsou citovány podle normy ISO 690 a ISO 690-2, odkazovány jsou v textu uvedením čísla citovaného zdroje. Není-li uvedeno jinak, veškerá data platí k 09.11.2005. Závěrem předmluvy bych chtěl ještě poděkovat všem, kteří mi pomohli napsat tuto diplomovou práci. 8
1 Úvod Jedním z dnešních důležitých požadavků ve světě informačních technologií je komunikace a vzájemná interoperabilita aplikací komunikujících na základě standardizovaných formátů. Existují různé iniciativy, které se o řešení tohoto problému pokouší, a to s rozdílným úspěchem. Tento požadavek dnes řeší i organizace působící v informační a knihovnické sféře jako například iniciativa otevřených archívů OAI-PHM nebo iniciativy OCLC kolem protokolu Z39.50. Jednou z otevřených technologií, pomocí které lze tyto požadavky řešit, jsou "web services" neboli webové služby. Tato technologie vychází z konceptu servisně orientované architektury (SOA) a webové služby tuto architekturu implementují, přičemž základním stavebním kamenem těchto služeb je jazyk XML- Extensible Markup Language a na něm postavené komponenty. Dnešní doba nabízí celou řadu informačních služeb jako je vyhledávání informací, elektronický obchod, výměna informací, překladové služby atd. a snahou je dosáhnout určitého stupně standardizace při dotazování se po těchto službách. Jedním z příkladů může být rovněž systém doručování dokumentů (DDS) elektronickou cestou. Státní technická knihovna dnes řeší tuto problematiku pomocí standardních webových technologií, ale jako instituce, která se přímo podílí na vývoji nových standardů, chce také nabídnout rozhraní k službám dodávky digitalizovaného dokumentu pomocí webové služby. Cílem této diplomové práce je objasnit uvedenou problematiku a tuto webovou službu ve formě rozhraní navrhnout. 9
2 Webové služby 2.1 Koncept servisně orientované architektury SOA Architekturou orientovanou na služby rozumíme v podstatě kolekci služeb. Principem je, že tyto služby jsou schopné navzájem komunikovat mezi sebou pomocí zpráv[ 1]. Vlastní službou rozumíme samostatný softwarový modul, u kterého nás nezajímá, jakým způsobem funguje jeho vnitřní implementace, je nezávislý na konkrétním vývojovém prostředku a v zjednodušené podobě nabízí pro uživatele jednu nebo více služeb, které dovede zprostředkovat. V informační a knihovnické oblasti může takovou službou například být zjištění stavu výpůjčky v knihovně, vyhledání digitálního zdroje, rezervace dokumentu, vyhledávání a sdílení informací či metadat, v jiných oblastech to může být práce s obchodní objednávkou nebo zjištění ceny akcií na burzovním trhu. Koncept SOA není novinkou, již dříve byly vyvinuty technologie CORBA, DCOM a RMI, které byly ale technicky náročné a těžkopádné, některé platformově závislé. Velký rozvoj nastal teprve s příchodem jazyka XML, na kterém byly standardy webových služeb vystavěny. Právě prudký rozvoj jazyka XML a na něm postavených webových služeb byl tedy novým impulsem pro znovuoživení S O A. Základním rysem SOA je skutečnost, že služby jsou formálně definovány zprávami, které si vyměňuje žádající a poskytující aplikace[2]. Tyto zprávy však musí splňovat určitá pravidla, aby bylo možné dosáhnout standardu jejich zpracování. Z pohledu služeb v SOA nezáleží na platformě, použitém programovacím jazyku, struktuře databáze a dalších technických aspektech komunikujících aplikací. Jak již bylo naznačeno, v případě webových služeb jde o zasílaní zpráv v jazyce XML, o kterém bude pojednáno v následujících kapitolách. SOA nám navíc umožňuje bez větších investičních nákladů integrovat tuto architekturu do současných systémů. Je to umožněno díky charakteru služeb, které mohou vytvořit v podstatě jakýsi obal kolem současných řešení a nabídnout zpracování úloh pro externí systémy. 10
2.2 Model WS Model webových služeb je založený na interakci tří prvků- poskytovatele služeb, registru služeb a jejich žadatele[3]. Mezi těmito prvky probíhají určité operace, které lze označit jako zveřejnění (publish), vyhledání (find) a svázání (bind). Schematicky to lze zobrazit následujícím obrázkem. Server t----svázánr-' ----... Žadatel služby Poskytovatel služby Obr. 2.1. Model WS Slovně lze toto schéma popsat následovně: Poskytovatel služby (service provider) zpřístupňuje určitou webovou službu, pro kterou definuje její popis(service description), ta je umístěna do registrů služeb (service registry), kde si ji žadatel služby (service requestor) může nalézt, získat její popis a následně může danou službu využít. Můžeme tedy definovat role ve webových službách a ty jsou následující: ll
Service provider - je poskytovatel služby nebo z hlediska architektury platforma, která službu zpřístupňuje. Service requestor- subjekt, který chce danou službu využít. Jde o aplikaci, která danou službu vyhledá a využije. Může jít o aplikaci s uživatelským rozhraním nebo také například o jinou webovou službu. Service registry - registr služeb, pomocí kterého daný poskytovatel svou službu zveřejní a žadatel služby si ji zde může nalézt. Dále jsme si mohli všimnout operací, které mezi jednotlivými elementy probíhají. Rozeznáváme tedy tyto operace: Zveřejnění - jde o proces zveřejnění, aby bylo možné službu dohledat. Nejčastěji se pro zveřejnění používají registry služeb. Vyhledání- v tomto procesu žadatel služby danou službu vyhledá a získá její popis. Svázání- operace, při které je služba vyvolána, jsou zjištěny detaily služby z jejího popisu za účelem jejího nalezení, kontaktování a vyvolání. Posledními činiteli v modelu WS jsou vlastní výkonné elementy: Service(služba) - je vlastní implementací rozhraní webové služby. Jde o softwarový modul, který je zjišťován, dotazován a vyvoláván žadatelem služby. Lze podotknout, že vlastní služba může být též žadatelem jiné služby. Popis služby - poskytuje detailní popis rozhraní a implementace služby. Obsahuje datové typy, operace, informace o vázání služby a umístění v síťovém prostředí. Taktéž může obsahovat další metadata usnadňující nalezení služby. Popis může být zveřejněn v registrech nebo přímo žadateli služby[3]. Tato infrastruktura je ve webových službách tvořena třemi komponentami, a to: 12
protokolem SOAP, definicí rozhraní služby WSDL, registrem webových služeb UDDI. Lze podotknout, že protokol SOAP není podmínkou (další možností je technologie REST - Representational State Transfer), SOAP je ale "de facto" standardem a používá se dnes ve většině případů. Odpovídá modelu vzdáleného volání procedur RPC v modelu požadavek- odpověď. RPC je protokolem, který umožňuje jednomu programu na jedné stanici, zavolat proceduru na vzdálené stanici bez znalosti toho, jak je tato procedura implementovaná. Zprávy, které jsou zapsány ve formátu XML, jsou zasílány pomocí protokolu HTTP, který umožňuje zasílání zpráv přes problematické elementy internetu jako jsou firewally a proxy servery a je jedním z nejdůležitějších a nejpoužívanějších protokolů Internetu. Podobně jako v případě protokolu SOAP není ani zde nutné použít protokol HTTP a stejně tak se mohou využít další z protokolů jako jsou například SMTP, MSMQ či TELNET. Obrázek 2.3 zobrazuje interakci zmíněných komponent. klinet využfvajfcf webovou službu I I hledání I služby :.. /. S_O_A_P -J / ""'.') "'""' 1// komunikace pomocí XML zpráv............... popis rozhraní.....,.. služby...... webová služba I I popisuje rozhraní : služby I -------------------~ odkaz na popis služby WSDL Obr. 2.2. Interakce komponent WS 13
2.3 Jazyk XML Webové služby, jak už bylo řečeno, používají pro zasílání zpráv a jejich popis jazyk XML. Cílem této práce není podat vyčerpávající informace o tomto jazyku, protože ten zasahuje do mnoha oblastí, kterých se problematika webových služeb netýká. Budou představeny jen zásadní rysy jazyka XML a oblasti, které se popisované problematiky týkají. Konkrétně se jedná o základní syntaxi jazyka XML, jmenné prostory a schémata jazyka XML. Extensible Markup Language XML je značkovací jazyk, který vychází z jazyka SGML(Standard Generalized Markup Language). Jazyk SGML je značkovacím jazykem, který vyvinula už v sedmdesátých letech 20. století firma IBM, a to z důvodu přenositelnosti dat. Přesněji řečeno, původ jazyka SGML je spojen už se vznikem jazyka GML vytvořeným v roce 1969 a je spjatý se jmény Goldfarb, Mosher a Lorris. V roce 1978 byl Goldfarb zvolen předsedou ANSI (American National Standartization Institute) a po dlouhých letech standardizace byl jazyk SGML oficiálně ustaven normou IS0-8879 roku 1986. Soubory SGML jsou ukládány jako text ASCII, což zajišťuje jejich použitelnost prakticky na libovolné počítačové platformě. Nicméně i jazyk SGML má své nevýhody, přičmež největší z nich je jeho složitost. SGML totiž za svou univerzálnost platí vyšší složitostí, která mu také zabránila masově se rozšířit. Jednou z aplikací jazyka SGML je populární jazyk pro tvorbu hypertextových dokumentů HTML, který vytvořil roku 1991 Tim Bemers-Lee. Jazyk HTML nabídnul vývojářům a tvůrcům těchto dokumentů možnosti pro ovlivňování vzhledu dokumentu, ale neobsahoval informace o tom, co dokument vlastně obsahuje a v podstatě si nevynucoval žádnou strukturu dokumentu. Tyto nedostatky daly vzniknout novému značkovacímu jazyku XML, který má následující rysy: může ukládat a organizovat téměř jakýkoliv typ informací v podobě, v jaké je právě potřebujeme, 14
je otevřeným standardem, který není svázán s žádnou společností nebo softwarovým produktem, podporuje kódování Unicode, nabízí způsoby kontroly platnosti dokumentu s pravidly pro jeho syntaxi, možností definování datových typů atd., díky jednoduché syntaxi a přehledné struktuře je dobře zpracovatelný jak pro počítač, tak pro člověka, lze pro něj použít styly umožňující formátování dokumentu [ 6]. Aplikace XML můžeme členit do dvou kategorií: dokumentové aplikace, určené převážně pro výstup (například za pomoci stylů), a tedy pro potřebu uživatelů, datové aplikace, pracující s informacemi, které jsou určeny převážně pro zpracování softwarem. XML, tak jak je používáno v oblasti WS, spadá tedy do kategorie druhé. V této datové oblasti bylo jedním z cílů nabídnout pro oblast správy dokumentů softwarové nástroje určené pro správu dat, například databáze a přináší způsob, jak lze distribuovat strukturovaná data napříč systémy. 2.3.1 Syntaxe XML Základním prvkem dokumentu XML je element, ze kterých se dokument skládá. Každý element má svůj název a obsah. Jeho obsah je vymezen značkami, kterým se říká počáteční a koncový tag. Každý počáteční tag elementu musí mít svůj koncový tag, jinak je dokument neplatný. Příznačné je to, že XML nedefinuje žádné vlastní elementy. Mechanismus rozmísťování značek je podobný tomu, který je známý zhtml[5]. <ISBN> 80-7300-057-1 </ISBN> 15
Zde vidíme element ISBN, jehož obsahem je vlastní ISBN číslo. Dalším rysem jazyka XML je to, že elementy se mohou do sebe "vnořovat". <KNIHA> <CENA>100</CENA> <ISBN> 80-7300-057-1 </ISBN> </KNIHA> Zde vidíme elementy ISBN a CENA, které jsou vnořeny do elementu KNIHA. Samotný element KNIHA nemá vlastní obsah, což je přípustné a obsahuje subelementy CENA a ISBN, které již vlastní obsah mají. Tato struktura vnořování se označuje jako stromová, elementy mohou obsahovat další elementy a není definována úroveň maximálního vnoření. Z toho je možné vysledovat, jak efektivní jazyk XML je aj ak jednoduše dovede mapovat datové struktury například pro přenos mezi aplikacemi. "Čistý" informační obsah XML dokumentu neboli virtuální strom informací bez doprovodných značek a dalších informací se nazývá XML InfoSet. Jednou z možných nevýhod, kterou lze u jazyka XML zmínit a kterou se platí za přehlednost, je zvětšení velikosti informace, která je nutná pro její uchování. Například pro informaci o ceně z předchozích výpisů na to potřebujeme celých 16 znaků. Ještě zřetelnější by to bylo u informace obsahující hodnotu pravda/nepravda, která by v binární soustavě zabrala pouhý 1 bit, v XML by to byl název elementu a vlastní informace ve znakové soustavě (např. ASCII, UNICODE). Tento handicap nicméně v dnešní době díky výkonným hardwarovým prostředkům není již tak markantní a dnešní výpočetní systémy se s ním čím dál lépe vyrovnávají. Jazyk XML je "case sensitive" což znamená, že rozlišuje mezi velkými a malými písmeny. Následující elementy jsou tedy rozdílné. <KNIHA> <kniha> Na první pohled je zřetelné, že struktura dokumentu zapsaného v jazyce XML je velmi dobře čitelná i pro člověka, a proto je možné z takového dokumentu získat informace i bez strojového zpracování. Pro strojové zpracování dokumentů XML se používají programové komponenty nazývané analyzátory nebo také parsery. 16
Analyzátor dokumentu XML je softwarový nástroj, který projde cyklem dokumentem XML, a podle typu analyzátoru buď načte stromovou strukturu do paměti nebo vyvolá určitou událost, která může být programově zpracována. Analyzátor Aplikace Obr. 2.3. Vztah analyzátoru a aplikace XML Obrázek 2.3 nám zobrazuje architekturu XML dokumentu a vztahu analyzátoru XML vůči aplikaci XML. Architektura programu je rozdělena na dvě části: analyzátor, pracující s dokumentem XML, aplikace, načítající a využívající obsah souboru pomocí tohoto analyzátoru. Rozeznáváme dva typy analyzátorů - DOM a SAX. Každý z těchto analyzátorů má specifickou oblast použití, i když není striktně definováno, kde se má který použít. Následující kapitoly přiblíží podstatu a možnosti jejich použití. 2.3.2 Objektový model dokumentu DOM DOM (document object model) byl vyvinut konsorciem W3C původně pro prohlížeče. Za jeho vznikem stála snaha sjednotit objektové modely dvou hlavních internetových prohlížečů- Internet Explorer a Netscape Navigator. Analyzátor typu DOM využívá toto rozhraní, kterému říkáme objektové, pro projítí celého 17
dokumentu a jeho načtení do paměti a umožňuje s takto načtenou stromovou strukturou opakovaně pracovat. Výhody tohoto přístupu mohou být například následující: proces načtení proběhne jen jednou, přičemž s modelem dokumentu se může opakovaně pracovat, jsou k dispozici všechny zpracované informace o dokumentu XML, následná práce s elementy dokumentu je díky držení modelu dokumentu v paměti velmi rychlá. Naopak lze vzít v potaz následující nevýhody: Při zpracování objemného dokumentu XML je nutné počítat s delší časovou odezvou zpracování dokumentu a vyššími požadavky na paměťové nároky hardwarových zařízení. Elementy a informace dokumentu XML jsou k dispozici až po zpracování celého dokumentu XML. Práci analyzátoru DOM s elementy dokumentu XML nám zobrazuje následující obrázek. Obr. 2.4. Práce DOM analyzátoru s dokumentem XML 18
2.3.3 SAX Událostní rozhraní SAX (Simple API for XML) nabízí alternativní zpracování dokumentu XML, které bylo zpracováno členy e-mailové konference XML-DEV a upraveno Davidem Megginsonem. Na rozdíl od analyzátoru DOM zde nedochází k tvorbě paměťového modelu dokumentu, nýbrž dochází k vyvolávání událostí při průchodu jednotlivými uzly. V okamžiku, kdy parser narazí na uzel, vyvolá tedy událost, která může být programově zpracována. Obrázek 2.5 ilustruje tuto situaci. Obr. 2.5. Zpracování uzlů pomocí analyzátoru typu SAX Rozeznáváme tyto události: počáteční tag elementu, koncový tag elementu, obsah elementů, entity, chyby v analýze. Výhodou tohoto rozhraní může být: rychlost zpracování, práce s uzly již v době průchodu, menší nároky na paměťové kapacity. Možné nevýhody: 19
větší pracnost při tvorbě kódu pro obsloužení události, absence následného modelu dokumentu. Zatímco tedy aplikace využívající DOM jsou nejvíce využívány například pro XML editory, kde se neustále pracuje s modelem dokumentu XML, rozhraní SAX bývá využíváno u rozsáhlých dokumentů XML zpracovávaných například do databáze nebo u serverových aplikací. Dalším prvkem XML, týkajícím se přímo oblasti WS, jsou jmenné prostory (namespace). 2.3.4 Jmenné prostory Jmenné prostory se mohou definovat jako mechanismus pro identifikaci elementů. Tento mechanismus přesouvá elementy do globálnějšího prostoru, který se nazývá jmenný prostor[s]. To je důsledkem toho, že jazyk XML je rozšiřitelný, a proto je nutné definovat určitá pravidla pro správu názvů elementů, neboť můžeme mít například element JMENO, který definovalo ve svém dokumentu více autorů, ale každý tento element může mít jiný význam. Z toho vyplývá, proč je nutné přiřazovat elementům tento globálnější kontext. Jednou z myšlenek bylo vytvoření globálního registru přípustných tagů a definic. To by svůj účel splnilo, ale na druhou stranu by toto řešení prudce snížilo a omezilo pružnost XML, a proto nebylo použito. S mechanismem jmenných prostorů tyto podstatné a zásadní charakteristiky jazyku XML zůstávají. Jmenné prostory nejsou důležité jen proto, aby zabránili kolizím shodných názvů, ale obecněji jsou důležité také pro procesor XML, který si je může roztřídit do skupin a pracovat s nimi různým účelovým způsobem[6]. 20
ns-prefix :lokální -název Obr. 2.6. Kvalifikovaná syntaxe názvu Na obrázku 2.6 vidíme kvalifikovanou syntaxi názvu elementu - tzn. včetně deklarace vlastního jmenného prostoru. Prefix (1) jmenného prostoru je následován dvojtečkou (2) a za ní je název (3) vlastního elementu, eventuálně může jít o atribut. xmlns:název = "url" Obr. 2. 7. Syntaxe deklarace jmenného prostoru Obrázek 2.7 nám znázorňuje syntaxi deklarace jmenného prostoru. Začíná klíčovým slovem xmlns (1) s dvojtečkou, které XML parseru říká, že tento atribut je definicí jmenného prostoru, následuje prefix jmenného prostoru (2), znaménko přiřazení a na posledním místě kvalifikátor URI (Uniform Resource ldentifier) ohraničený uvozovkami (3). Důležité je podotknout, že názvem jmenného prostoru je toto URI a ne vlastní předpona. Ta jen vytváří mechanismus pro to, abychom nemuseli vypisovat celý identifikátor URI, ale jen vhodně zvolenou zkratku. Systém URl se používá pouze pro zajištění jedinečnosti názvů a občas je pro začátečníka matoucí, protože může, ale nemusí odkazovat na popis názvů. N apříklad na adrese http://adresa/popis/ může existovat dokument s popisem nějakého elementu, ale rovněž nám může prohlížeč zobrazit chybu (chyba č. 404), že daný zdroj neexistuje, a i přesto bude 21
deklarace jmenného prostoru v pořádku. Důležitá je tedy právě pouze jedinečnost URl. Je dobrým zvykem vytvářet tento identifikátor ve tvaru vlastní domény. Jednou z dalších možností je použití identifikátoru URN (Uniform Ressource Name ). Jaký je vlastně vztah mezi URl, URL a URN? Můžeme konstatovat, že URl bývá současně adresami URL. Identifikátor URL odkazuje na soubor nebo zdroj na určitém počítači, zatímco URN je jen obecným názvem určitého zdroje a není tedy adresou. Záštitu nad tímto identifikátorem má organizace ITEF (Internet Engineering Task Force), která na jeho podobě pracuje. Příkladem identifikátoru URN může být například číslo ISBN, které jednoznačně identifikuje knihu a nemůže být duplicitní. Mohlo by vypadat například následovně: urn:isbn:o - 7897-2249 - 9 Jinou možností je využití persistentních URL- PURL (Permanent URL). Principem těchto identifikátorů je již jejich registrace, aby byly vyloučeny chyby nenalezení zdroje. Pomocí registrace je řešen případ, kdy dojde ke změně lokace daného zdroje, a stačí změnit jednou lokační údaj v registrační databázi. Samotný jmenný prostor musí být v dokumentu deklarován dříve než se použije nebo je třeba plně kvalifikovat každý element, který potřebujeme použít z jiného jmenného prostoru. Deklarace jmenného prostoru je ve stylu atributu elementu a jakýkoliv potomek tohoto elementu se stává součástí tohoto jmenného prostoru. Následuje příklad plné kvalifikace elementu, která se ale moc nepoužívá, neboť není příliš praktické neustále vypisovat celý název: < kniha xmlns="http://www.priklad.com/kniha"> Prostředí WWW </ kniha > S definovaným prefixem by kvalifikace vypadala následovně: <?xml version="l.o"?> <KN: knihovna xmlns:kn="http:// www.priklad.com/kniha"> <KN: kniha > Prostředí c/kn: kniha > </KN: knihovna > WWW 22
Výhoda této definice spočívá i v tom, že v případě změny identifikátoru URl, stačí identifikátor změnit pouze na jednom místě. Nejpoužívanějším místem, kde se obvykle definuje jmenný prostor, je kořenový element dokumentu XML. V případě nutnosti definice více jmenných prostorů, je definujeme prostě vícekrát za sebou: c?xml version="l.o"?> <knihovna xmlns:kn="http://www.priklad.com/kniha" xmlns:os="http://www.priklad.com/osoba"> <KN:kniha> ckn:titul> Prostředí WWW c/kn:titul> cos:autor> Jiří c/os:autor> </KN: kniha > </ knihovna > Novák O jmenných prostorech by bylo možné pojednat určitě v mnohem větší šíři, nicméně by se nejednalo už o problematiku užívanou v prostředí webových služeb, a proto zde nebude dále probírána. 2.3.5 Schémata XML - XSD Jazyk XML je velmi pružný a nabízí velkou flexibilitu. Občas se ale může hodit vynutit od dokumentu XML určitou schémata[s]. Tato schémata představují prostředkem strukturu zápisu. Proto vznikla XML formální popis dokumentu. Prvním pro modelování dokumetu XML se stal modelovací jazyk DTD (definice typu dokumentu), který umožnil zprostředkovat mechanismus pro popis struktury dokumentu. DTD vychází přímo z jazyka SGML a je součástí definice XML. Nepříjemnou skutečností, která z toho vyplývá je, že vlastní syntaxe DTD není Validním dokumentem jazyka XML, což se stalo terčem velké kritiky, dále nepodporuje definování vlastních datových typů (v podstatě žádných) a rovněž nepodporuje jmenné prostory. Společnost Microsoft proto začala pracovat na svém vlastnílll. návrhu a předložila organizaci W3C vlastní návrh jazyka XML Data. Reakc' 1 na tuto předlohu a stávající kritiku bylo to, že organizace W3C začala 23
pracovat usilovně na novém jazyku pro definování požadavků na obsah dokumentu a v květnu roku 2001 se objevilo XSD neboli XML Schema Definition, které bylo touto organizací doporučeno. XSD nám nabízí následující základní charakteristiky: definici základních datových typů - řetězec, datum, celé číslo a řadu dalších, možnost definice složitých typů - např. typ Jmeno _autora je složen z prvků Krestni a Prijmeni, přičemž oba jsou typu řetězec, kontrola pořadí a vzájemné hierarchie - např. Jmeno _autora smí obsahovat pouze prvky K.restni a Prijmeni, přičemž se musí vyskytovat přesně v tomto pořadí, kontrola počtu výskytu jednotlivých prvků - např. Jmeno _autora musí obsahovat nejvýše jeden prvek Krestni a právě jeden prvek Prijmeni kontrolu intervalu u měřitelných hodnot jako jsou čísla nebo časové údajenapř. věk musí být vyšší než 18, vynucení určitých hodnot prvku - např. pohlaví musí být buď "muž" nebo v " "zena, dodržení délky údaje- např. rodné číslo musí být 9 až 10 znaků, cena musí mít maximálně dvě desetinná místa, kontrola formátu pomocí regulárních výrazů - např. email musí obsahovat právě jeden znak"@" a za ním minimálně jednu tečku. Celé schéma je vlastně dokument XML, který používá speciální elementy. Všechny tyto elementy musí patřit do jmenného prostoru http://www.w3.org/2001/xmlschema. Obvykle se pro tento jmenný prostor používá prefix xs nebo xsd. Celé schéma musí být vždy uzavřeno v elementu schéma obsahujícím definice elementů. Definice elementu se zapisuje pomocí elementu element, kdy pro každý element musí schéma určit jeho typ. Rozlišovány jsou přitom dva typy - jednoduché a komplexní. Jednoduché typy se používají pro skalární hodnoty. XML schémata mají některé vlastní předdefinované typy a následující tabulka zobrazuje výčet nejčastěji používaných typů: 24
/Typ ;)string '[Popis lretezeczn llv v aků... I r--'-'--'-'- ;_;_;.'---'-"--'- ~~;logická /Ukázka/Poznámka autor : boolean true, fal se, 1, o ;hodnota. r-1------,: r::= ' -13 72 4 2 decimal ildesetinné číslo ~~,:-:--;--'-------------------------~ desetinné číslo s přesností nejméně 18 platných číslic lnoat--~ desetinné číslo I le-~, o, ov~l, 3 1415 ' ' V' t' j 32bltove c1slo v plovouc1 desetmne carce ~d r 'v'l le-3,0.001,3.1415 /uuuuu; I ese mne ClS 0 ' 64bitové číslo v plovoucí desetinné čárce. ' F. I dé.lka.ča. s.o.véh. o Pl Y2M3DT1 OH3 OM ukázka re. p.rezentuje int.e rval o dé.l ce uratwn.. 1. d k d v ' v dn d h d" v. ~ _., mterva u. pe en ro, va mes1ee, tří _ y, eset o ma třicet mmut I! I : 2005-07-05T10:58:53+02:00,2005-07-05T08:58:53Z I ldatetimet datum a čas údaj je ve formátu 1808601 a může obsahovat i časovou zónu F llčas. 12:15:00+02:oo, 10:15:ooz, 10:15:00 časovýúdaj ve 'formátu 1808601; může obsahovat časovou zónu :ldate :!datum ~~~% 0 :e-~:rmátu 1808601 (rok-měsíc-den) ~~~r-_;_;,;_:~:.:.;.:_;_;"---'-'--c:-,. http:/ /www.yahoo.com lanyuri! adresa URl pakákoliv URl adresa; může být absolutní i relativní llanguage ~.~,b..azykový k.. ód 'le-s-,-en u_s. 'i _ kód identifikující jazyk )integer ijcelé číslo.. I I long I celé číslo [-17, o, 65542-17, o, 65542 číslo je v rozsahu od -9223372036854775808 do 9223372036854775807, což odpovídá 64bitovému celému číslu Tabulka 2.1. Zabudované datové typy Obsahuje- li však element další elementy nebo atributy, musíme použít komplexní typ ( complextype ). Zde je příklad jednoduchého XML dokumentu: <?xml version="l.o"?> <kniha> cautor>tomáš Novýc/autor> cnazev>learnig XMLc/nazev> cvydavatel>computer Pressc/vydavatel> crok vydani>2004-06-04c/rok vydani> </kniha> - - Zde je možné schéma XML, které definuje jeho elementy pomocí komplexního typu: 25
c?xml version="l.o"?> cxs:schema xmlns:xs="http://www.w3.org/2001/xmlschema"> cxs:element name="kniha"> cxs:complextype> cxs:sequence> cxs:element name="autor" type="xs:string"/> cxs:element name="nazev" type="xs:string"/> cxs:element name="vydavatel" type="xs:string"/> cxs:element name="rok vydani" type="xs:date "/> c/xs:sequence> c/xs:complextype> c/xs:element> c/xs:schema> Komplexní typy slouží k modelování struktury dokumentu a definují se pomocí elementu complextype. Komplexní typ lze definovat samostatně, aby ho pak bylo možné použít v dalších definicích. Ve složených datových typech můžeme využít dalších konstrukcí. Následuje výčet indikátorů pořadí: sequence - sekvence určuje, že elementy v ní definované, musí dodržet přesně definované pořadí, choice- určuje, že lze zvolit pouze jeden element z definované množiny, all - jedná se o datový typ obsahující definovanou množinu elementů v jakémkoliv pořadí. Příklad sekvence: cxs:element name="autor"> cxs:complextype> <xs:sequence> cxs:element name="krestni_jmeno" type="xs:string"/> cxs:element name="prijmeni" type="xs:string"/> </xs:sequence> c/xs:complextype> c/xs:element> Mezi indikátory výskytu patří: maxoccurs - specifikuje maximální počet výskytu elementu, 26
minoccurs - specifikuje minimální počet výskytu elementu. Příklad indikátoru výskytu: cxs:element name="osoba"> cxs:complextype> cxs:sequence> cxs:element name="jmeno" type="xs:string"/> cxs:element name="jmena deti" type="xs:string" maxoccurs="lo"/> - c/xs:sequence> c/xs:complextype> c/xs:element> Ukázka znázorňuje skutečnost, že elementjmena_deti se musí vyskytnout minimálně jednou (defaultní hodnota pro minimální výskyt je 1) a maximálně desetkrát. Dalším významným prvkem, které schéma XML u datových typů nabízí, jsou restrikce. Mezi nejpoužívanější patří následující: řetězce - length, minlength, maxlength, pattem, enumeration, whitespace, číselné typy - maxlnclusive, maxexclusive, minlnclusive, minexclusive, totaldigits, fractiondigits, pattem, enumeration, binární data - length, minlength, maxlength, pattem, enumeration, whitespace [ 6]. Jedná se o aplikaci určitých omezení na datové typy jako například určení maximální délky řetězce, definování hranic číselného typu atd. Schémata jsou důležitým rysem jazyka XML a hrají svoji roli při definování typů operací v rámci definice dokumentu WSDL a SOAP zprávy, o kterých bude pojednáno dále. 27
2.4 SOAP SOAP (Simple Object Access Protocol) je definicí informace založené na jazyku XML, která může být využita pro výměnu strukturovaných informací mezi síťovými prvky v decentralizovaném, distribuovaném prostředí[8]. Jednodušeji řečeno jde o "odlehčený'' protokol určený pro výměnu informací v decentralizovaném prostředí na bázi XML[9]. V současné době je jeho nejnovější specifikací verze 1.2. Konsorcium W3C začalo pracovat na jeho specifikaci v roce 1999 v okamžiku, kdy se začalo vyvíjet Schéma XML, které bylo označeno za jednu z klíčových částí specifikace SOAP. SOAP toto schéma využívá k definování užívaných datových typů. Verze SOAP 1.1. byla zveřejněna v květnu roku 2000. Vznikla na základě spolupráce velkých softwarových společností Microsoft, IBM, Lotus Development a UserLand Software. Tato specifikace pak byla postoupena konsorciu W3C. Současná verze je 1.2., která obsahuje částečné změny v struktuře dokumentu, syntaxi, svázání s protokolem HTTP, definici RPC a kódování SOAP. Následující tabulka 2.2 udává stručný přehled verzí protokolu SOAP. SOAP 1.1 N amespace Name Spec Location http:/ I schemas.xmlsoap.org/ s o ap/ envelope/ http://www.w3.org/tr/soap/ SOAP 1.2 N amespace Name Spec Location http:/ /www.w3.org/2002/12/soap-envelope http://www.w3.org/tr/soap12-part0/ (Primer) http://www.w3.org/tr/soap12-partl/ http://www.w3.org/tr/soap12-part2/. Tab 2.2. Vydání verzí SOAP 28
Tento protokol je definovaný jako jednosměrný, bezstavový mechanismus přenosu zprávy mezi uzly SOAP, kde na jedné straně je SOAP odesílatel a na druhé SOAP příjemce. Nicméně se očekává, že tento mechanismus bude implementován v aplikacích v podobě více komplexnějšího vzoru komunikačního scénáře jako například ve stylu požadavek/odpověď. komunikační protokol ~-o_i_e 0 _s_~_~_e_i~~------~~~------~ ~I P_r_u_~-~-~-e--~ zpráva požadavek SOAP odesílatel SOAP příjemce odpověď Obr. 2.8. Jednosměrná a dvousměrná komunikace zpráv SOAP Jedním z cílů návrhu protokolu SOAP 1.2. bylo zapouzdření funkcionality vzdáleného volání procedur (RPC) při použití flexibility a univerzálnosti jazyka XML. Aby bylo možné vyvolat toto RPC, jsou nutné znalosti následujících informací: adresa cílového uzlu SOAP, název procedury nebo metody, znalosti typů vstupních parametrů zasílaných metodám a stejně tak parametrů výstupů nebo návratových hodnot, oddělení argumentů, které identifikují webový zdroj, který je skutečným cílem volání RPC. výměnný typ zasílání zpráv- MEP (message exchange pattems), volitelně data, která mohou být přenášena jako součást SOAP hlaviček[9]. 29
Tyto informace mohou být vyjádřeny za pomoc1 různých prostředků včetně formálního jazyka IDL (Interface Definition Language). SOAP zprávy se mohou přenášet dvěma základními způsoby: SOAP RPC - jde o zasílání zpráv založeném na interpretaci volání RPC. SOAP RPC reprezentace představuje sadu konvencí, které reprezentují RPC požadavky a odpovědi. Při použití tohoto typu volání je pak SOAP požadavek formulován jako metoda s žádným nebo více parametry. V případě jednoduché struktury pak představuje vnější element název metody a vnitřní elementy jsou parametry. SOAP odpověď je potom konstruována ve stejném stylu. Organizace WS-I (http://www.ws-i.org) zabývající se propagací webových služeb ve svém základním implementačním profilu webových služeb WS-I uvádí použití SOAP RPC jako volitelné. SOAP Document literal - SOAP rovněž podporuje komunikaci dvou aplikací ve formátu, kdy SOAP odesílatel zašle zprávu SOAP příjemci, který určuje, co s danou zprávou učinit. Odesílatel nepotřebuje znát implementaci služby na druhé straně, stačí pouze znalost formátu zprávy a přístupový bod URl. Celá zátěž je pak přenesena na SOAP příjemce, aby rozhodnu! na základě zprávy, o co odesílatel žádá a jak má požadavek zpracovat. Příklad zaslaného SOAP bloku: POST /EndorsementSearch HTTP/1.1 Host: www.snowboard-info.com Content-Type: text/xml; charset="utf-8" Content-Length: 261 SOAPAction: "http://www.snowboardinfo.com/endorsementsearch" <SOAP-ENV:Envelope xmlns:soap ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encodin g/"> <SOAP-ENV:Body> <m:getendorsingboarder xmlns:m="http://namespaces.snowboard-info.com"> <manufacturer>k2</manufacturer> <model>fatbob</model> </m:getendorsingboarder> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 30
2.4.1 Uzly a role SOAP tedy představuje distribuovaný model zasílání zpráv mezi odesílatelem a příjemcem zprávy. Tyto dva body bývají také označovány jako SOAP uzly[9]. Nicméně skutečností je,'~,:~e zpráva SOAP nemusí být zasílána pouze v rámci těchto dvou bodů, ale může být přeposílána v rámci více uzlů, kdy vnitřní uzly působí jako prostředníci předávání zprávy. Jde o tzv. SOAP intermediaries[9]. Model zpracování SOAP hovoří o tom,jak se uzel přijímající SOAP zprávu zachová. Uzel může být jeden z trojice odesílatel, příjemce nebo prostředník. Za pomoci rolí můžeme pak adresovat SOAP zprávu uzlu, který působí v konkrétní roli, prostřednictvím role atributu hlavičkového bloku. Každý uzel má při zpracování konkrétní zprávy určeny specifikované role, které se v průběhu zpracování nemění. Role je definovaná za pomoci systému URl. V SOAP 1.2 jsou definovány tři základní role: next - tuto roli hrají uzly zprostředkovávající předání zprávy dál. (http://www.w3.org/2003/05/soap-envelope/role/next), none - tuto roli nesmí představovat žádný uzel včetně cílového (http://www.w3.org/2003/05/soap-envelope/role/none), ultimatereceiver role specifikující konečného příjemce (http://www.w3.org/2003/05/soap-envelope/role/ultimatereceiver) [9]. 2.4.2 SOAP Message Zpráva SOAP je XML Infosetem, jehož kořenovým elementem je element Envelope (obálka). Tento element je povinný a může obsahovat další dva elementy Header (hlavička) a Body (tělo). Dalším elementem ve zprávě SOAP může být element Fault (chyba). Všechny elementy verze SOAP 1.2 jsou definovány ve jmenném prostoru 31
h@://~.w3.org/2002/12/soap-envelope/. Následující obrázek nám zobrazuje, - jak vypadá struktura zprávy SOAP. Obr. 2.9. Struktura SOAP zprávy Obrázek 2.9 zobrazuje strukturu standardní SOAP zprávy. Taková zpráva musí obsahovat pouze textové informace ve formátu XML. Bezesporu zajímavá je možnost přenášet zprávou SOAP i jakékoliv jiné informace jako například dokumenty PDF, obrázky, binární soubory a další digitální objekty. V této příloze je samozřejmě možné přenést taky například další XML dokumenty. Tyto informace musí být ale přenášeny vždy ve formě přílohy. Obrázek 2.1 O ilustruje tuto situaci. 32
nebo jiná data Obr. 2.1 O. Zpráva SOAP obsahující přílohu 2.4.2.1 Element Envelope Element Envelope neboli obálka je povinným elementem zprávy SOAP. Každá zpráva musí obsahovat právě jeden tento element, který je současně elementem. kořenovým <soap:envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:header> <!-- optional --> <!-- header blocks go here... --> </soap:header> <soap:body> 33
<!-- payload or Fault element goes here... --> </soap:body> </soap:envelope> V uvedeném příkladu lze spatřit strukturu tohoto elementu. Obálka definuje strukturu zprávy, verzi protokolu a volitelně další jmenné prostory, používané uvnitř zprávy. Obálka je definována jmenným prostorem <env:envelope xmlns:env="http://www.w3.org/2003/05/soapenvelope"> V případě použití jiného jmenného prostoru musí aplikace generovat chybovou hlášku a zprávu zrušit. Tento element může obsahovat atribut encodingstyle, který se používá pro definování datových typů v dokumentu. Zpráva SOAP nemá žádné implicitní kódování a tento atribut je nepovinný. Příklady hodnot atributu: "http://www.w3.org/2003/05/soap-encoding" "http://example.org/encoding/" "http://www.w3.org/2003/05/soap-envelope/encoding/none" Element Envelope může obsahovat dva další elementy - nepovinný Header a povinný element Body. 2.4.2.2 Element Header Volitelný element Header (hlavička) obsahuje aplikačně specifické informace o zprávě SOAP. Takovými informacemi může být například autentifikace, platba nebo transakční informace. Následuje příklad hlavičky SOAP: <env:header xmlns:env="http://www.w3.org/2003/05/soapenvelope"> <t:transaction xmlns:t="http://example.org/2001/06/tx" env:mustunderstand="true" > 5 </t:transaction> </env:header> 34
SOAP definuje čtyři atributy v implicitním jmenném prostoru - encodingstyle, role, mustunderstand a relay. Tyto atributy elementu Header definují, jak by měl příjemce zpracovávat zprávu SOAP. role - indikuje SOAP uzel, který má jako cíl příslušná SOAP hlavička. Typ tohoto atributu je xs:anyurj, mustunderstand - tento atribut určuje, zda zpráva musí být daným SOAP uzlem zpracována nebo je nepovinná. Implicitní hodnotou je false. V případě definování tohoto atributu musí být tato hodnota nastavena na true. Datový typ tohoto atributu je xs:boolean, relay - specifikuje, zda-li má být daný blok SOAP hlavičky přenesen, pokud nedojde k jeho zpracování, encodingstyle -viz popis v kapitole 2.4.2.1. Element Envelope. 2.4.2.3 Element Body Element Body (tělo) je povinným elementem každé SOAP zprávy. Je mechanismem pro přenos informací pro konečného příjemce (ultimate receiver) zprávy. Pokud je SOAP použit v "dokumentově - orientovaném" módu je obsahem tohoto elementu obecný XML blok. V tomto případě se o zpracování stará samotná aplikace. V druhém případě, kdy je SOAP použit pro vzdálené volání procedury (RPC), je obsahem elementu Body žádost/odpověď vzdáleného volání procedury či funkce. Opět definuje atribut encodingstyle, o kterém již bylo pojednáno dříve (kapitola 2.4.2.1. Element Envelope). Tento element může obsahovat jakýkoliv obsah dalších elementů s různými jmennými prostory. 2.4.2.4 Element Fault 35
Tento element je nepovinným elementem, který je, pokud je definován, obsažen v elementu Body. Slouží k přenášení chybových informací v SOAP zprávě. Bez tohoto elementu by musela každá aplikace definovat svoji vlastní infrastrukturu pro určení úspěchu nebo chyby. Specifikace SOAP 1.2. definuje pro obsah tohoto elementu pět dalších elementů, z toho dva povinné: code- povinný element code (kód), který obsahuje jeden z předdefinovaných typů: o VersionMismatch -nesprávná verze protokolu nebo chybný element, o MustUnderstand- uzel nemůže zpracovat povinný Header element, o DataEncodingUnknown -neznámý datový typ, o Sender- chyba u odesílatele (špatná formulace, atd.), o Reciever - chyba při zpracování u poskytovatele, reason- povinný element Reason (příčina), textově popisující chybu, node - volitelný element určující, který SOAP element způsobil chybu ve zpracování zprávy, role - volitelný element indikující, v jaké roli působil daný SOAP uzel v okamžiku výskytu chyby. Jsou definovány 3 role, a to next, no ne a ultimatereceiver. detail - nepovinný element, vyhrazený pro chybu generovanou aplikací, vztažený k tělu SOAP zprávy. 2.5 WSDL WSDL (Web Service Description Language) je jazyk pro popis veřejného rozhraní webových služeb pomocí XML formátu využívající standardy XML Namespaces a XML Schema, zahrnující kompletní, strojově zpracovatelnou dokumentaci služby - od abstraktního popisu funkcionality služby, až po konkrétní data[13]. Vznikl sloučením tří jazyků firem IBM, Microsoft a Ariba s názvy NASSL, SCL a SDL do jednoho jazyka nazvaného WSDL 1.1. Konsorcium W3C vzalo WSDL 1.1 na 36
vědomí a ustanovilo pracovní skupinu s názvem Web Services Description Working Group, která nyní pracuje na jeho novější verzi WSDL 2.0 a zatím je stále ještě ve fázi pracovního návrhu. Ukončení prací na její specifikaci se očekává začátkem roku 2006. Dokument WSDL popisuje, jakou funkcionalitu nám webová služba nabízí, jaká je s ní komunikace a na kterém místě je přístupná. Jde o mechanismus strukturovaného popisu operací webové služby, které mohou zpracovat: možné formáty zpráv, podporované protokoly a přístupové body služby[l3]. Existují rovněž taky ale vývojové nástroje pro tvorbu webových služeb, které mohou automaticky generovat z dokumentů WSDL příslušná aplikační rozhraní pro volání webových služeb (tzv. WSDL toolkity). Vlastní WSDL dokument se obecně sestává ze dvou částí: abstraktní část - definuje zprávy (element message), které jsou zasílány v rámci služby, vzor jejich výměny (MEP), určující sekvenci a kardinalitu zpráv, jeho přiřazení konkrétní operaci (operation) a sloučení těchto operací do logických skupin (operation). Abstraktní popis je nezávislý na konkrétní implementaci webové služby. konkrétní část - specifikuje vazbu na konkrétní formát přenosu zpráv (binding), síťovou adresu, kde je tato vazba dostupná (port), a určení služby ( service ), kterou tyto cílové body tvoří. Messages Operations Obr. 2.1 L Koncept WSDL 37
2.5.1 Definice služby Obecně vzato je dokument WSDL sadou různých definic. Právě kořenovým elementem WSDL dokumentu je element definitions. Struktura této části je následující: <Wsdl:definitions name="nmtoken"? targetnamespace="uri"?> </wsdl:definitions> Služby jsou definované za pomoci šesti hlavních elementů: types (datové typy) - poskytující definici datových typů určených pro popis zasílaných zpráv, message (zpráva) -reprezentující abstraktní definici přenášených dat. Zpráva se skládá z logických částí, přičemž každá z nich je asociována s definicí typů v rámci určitého systému typů, porttype- který je sadou abstraktních operací. Každá operace se odkazuje na vstupní a výstupní zprávy, binding - specifikuje konkrétní protokol, datový formát operace a zprávy definované elementem porttype, port- specifikuje adresu pro element binding. Definuje tedy koncový bod ( endpoint) komunikace. service- tento element agreguje sadu příbuzných portů. 2.5.1.1 Element Types Obsah tohoto elementu tvoří definice datových typů platných pro zasílané zprávy. Aby se dosáhlo co nejvyšší interoperability a platformové nezávislosti, je pro tento účel využíváno XML schémat, která byla blíže popsána v kapitole 3.3. Doporučení pro definování datových typů jsou následující: využívání elementů namísto atributů, 38
nepoužívat elementy a atributy, které nemají žádný vztah k abstraktnímu obsahu zprávy a jsou spojeny se síťovým prostředím (soap:root, soap:encodingstyle, xmi:id, xmi:name), datové typy typu Array by měli rozšiřovat tento typ definovaný v kódovacím schématu SOAP vl.l, využití typu xsd:anytype pro parametry, které mohou obsahovat jakýkoliv typ. Syntaxe v XML schématu: <definitions... > <types> <xsd:schema... />* </types> </definitions> 2.5.1.2 Element Messages Element Messages se skládá z několika logických částí (part). Každá tato část je spojena s určitým typem z definovaného typového systému ve formě atributu. Syntaxe pro tento element je následující (pozn. - qname je kvalifikovaným názvem XML a nmtoken platným názvem dle definice XML schématu): <definitions... > <message name="nmtoken"> * <part name="nmtoken" element="qname"? type="qname"?/> * </message> </definitions> Atribut elementu message - name obsahuje jedinečný název tohoto elementu mezi všemi elementy typu message v rámci celého WSDL dokumentu. Podobně tak atribut name elementu part definuje jedinečný název pro tento element v rámci jednotlivých elementů message. Vlastní elementy parts jsou pak flexibilním mechanismem pro popis abstraktních částí obsahu zpráv. 39
2.5.1.3 Element porttype Tento element slouží pro definici množin operací, které jsou definované elementem operation. Jeho syntaxe je následující: <wsdl:definitions... > <wsdl:porttype name="nmtoken"> <wsdl:operation name="nmtoken"... /> * </wsdl:porttype> </wsdl:definitions> WSDL rozeznává 4 druhy přenosových operací: one-way- koncový bod přijímá zprávu, request-response- koncový bod přijímá zprávu a odesílá na ni odpověď, solicit-response- jde o obrácený případ požadavku typu request-response, notification - opačný případ požadavku typu one-way. Obrázek 2.12 ilustruje tyto operace. One-way S---- Vstupniparameby-----8 Reauest-response klient ---- Vstupní parametry------i --- Výstupní parametry----- služba klient Solicit-response ---- Výstupní parametry----- ---- Vstupní parametry------i služba Notification s---- Výstupnl parameby-----,i!isilu žb a 111111 mil Obr. 2.12. Typy přenosových operací 40
Syntaxe pro operaci one-way vypadá následovně: cwsdl:definitions... > cwsdl:porttype... > * cwsdl:operation name="nmtoken"> cwsdl:input name="nmtoken"? message="qname"/> c/wsdl:operation> c/wsdl:porttype > c/wsdl:definitions> V této operaci je definovaný pouze element input, specifikující formát zprávy pro tento typ operace. Syntaxe operace request-response: cwsdl:definitions... > cwsdl:porttype... > * cwsdl:operation name="nmtoken" parameterorder="nmtokens"> cwsdl:input name="nmtoken"? message="qname"/> cwsdl:output name="nmtoken"? message="qname"/> cwsdl:fault name="nmtoken" message="qname"/>* c/wsdl:operation> c/wsdl:porttype > c/wsdl:definitions> Tento typ definuje elementy pro vstup a výstup - input, resp. output. Dalším nepovinným elementem je element fault, který může být použitý pro případnou chybovou hlášku, která může být výstupem této operace. Syntaxe operace solicit-response: cwsdl:definitions... > cwsdl:porttype... > * cwsdl:operation name="nmtoken" parameterorder="nmtokens"> cwsdl:output name="nmtoken"? message="qname"/> cwsdl:input name="nmtoken"? message="qname"/> cwsdl:fault name="nmtoken" message="qname"/>* c/wsdl:operation> c/wsdl:porttype > c/wsdl:definitions> Syntaxe této operace je stejná jako u předchozí operace s tím, že je obrácené pořadí u elementů input a output. 41
Syntaxe operace notification: <wsdl:definitions... > <wsdl:porttype... > * <wsdl:operation name="nmtoken"> <wsdl:output name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:porttype > </wsdl:definitions> Tato operace definuje element pro výstup- output. 2.5.1.4 Element binding Element binding už poskytuje konkrétní informace o použití příslušných protokolů pro odpovídající operace a zprávy definované odpovídajícím elementem porttype, přičemž pro každý element porttype může být definován libovolný počet elementů binding. Jeho obsahem je několik rozšířitelných elementů, které definují konkrétní syntax pro vstupní (input) a výstupní (output) parametry a chybové hlášky (fault). Syntaxe tohoto elementu je následující: <wsdl:definitions... > cwsdl:binding name="nmtoken" type="qname"> * <-- extensibility element {l) --> * <wsdl:operation name="nmtoken"> * <-- extensibility element {2) --> * cwsdl:input name="nmtoken"? >? <-- extensibility element {3) --> </wsdl:input> <wsdl:output name="nmtoken"? >? <-- extensibility element {4) --> * </wsdl:output> <wsdl:fault name="nmtoken"> * <-- extensibility element {S) --> * </wsdl:fault> c/wsdl:operation> c/wsdl:binding> </wsdl:definitions> Tento element obsahuje atributy name, definující jeho jedinečný název v rámci dokumentu WSDL a atribut type, který je referencí k příslušnému elementu porttype. Element operation je spjatý s konkrétní operací definovanou v rámci 42
aktuálního elementu porttype. Zde je nutné podotknout, že název operace nemusí být jedinečný vzhledem ke skutečnosti, že operace mohou být přetíženy ( overloading), tzn. definovány vícekrát se stejným jménem a různými typy či počtem parametrů. 2.5.1.5 Element port Element port definuje koncový bod ( endpoint) ve tvaru adresy pro příslušný element binding, který je definovaný v rámci jeho atributu. V jeho rámci nesmí být definována více než jedna adresa. Syntaxe pro tento element vypadá následovně: <wsdl:definitions... > <wsdl:service... > * <wsdl:port name="nmtoken" binding="qname"> * <-- extensibility element (1) --> </wsdl:port> </wsdl:service> </wsdl:definitions> 2.5.1.6 Element service Element service seskupuje skupinu portů, které tvoří dohromady určitý logický celek. Tyto porty pak mají mezi sebou následující vztahy: porty mezi sebou vzájemně nekomunikují, pokud element service obsahuje více portů sdílejících stejný element porttype, pak jsou tyto porty alternativami mezi sebou, testováním portů můžeme určit jejich porttype, což je užitečné v případě určitých vazeb mezi operacemi elementů porttype. Syntaxe je následující: <wsdl:definitions... > <wsdl:service name="nmtoken"> * <wsdl:port... I>* </wsdl:service> 43
</wsdl:definitions> 2.5.2 SOAP Bindings WSDL má vestavěný binding pro protokol SOAP 1.1, který podporuje následující specifikace: příznak, že binding je svázáno s protokolem SOAP 1.1, způsob specifikace adresy pro koncový bod, URI pro HTTP hlavičku - SOAP Action, seznam definicí hlaviček, které jsou přenášeny jako součást elementu Envelope[ 13]. Tato specifikace není vyčerpávající vzhledem ke skutečnosti, že tato část je neustále ve vývoji. Mezi nejdůležitější elementy patří: soap:binding- definuje způsob přenosu pomocí atributu transport. Hodnota URI http://schemas.xmlsoap.org/soap!http odpovídá specifikaci HTTP vazby specifikované SOAP. Jiné hodnoty na tomto místě by specifikovaly způsob jiného přenosu (FTP, SMTP). Atribut style definuje, zda se použije způsob volání RPC nebo přenos obecného bloku dokumentu XML (document). soap:operation - pomocí tohoto elementu jsou konkrétní operaci přiřazovány konkrétní implementační SOAP specifikace. Obsahuje atribut soapaction, který je pro HTTP svázání povinný a nesmí obsahovat relativní URL. Druhý atribut style může předefinovat stejný atribut elementu soap:binding soap:body-jde o bližší specifikace samotného těla SOAP zprávy. soap-fault- specifikuje obsah elementu SOAP Fault. soap:header, soap:headerfault - umožňují definovat hlavičky přenášené v elementu SOAP Envelope. soap:address - zde se zadává adresa (URI) pro jednotlivé porty. Port využívající SOAP binding musí specifikovat právě jednu adresu. Schéma URI musí odpovídat přenosu specifikovanému elementem soap:binding. 44
2.6 UDDI UDDI (Universa! Description, Discovery and Integration) jsou definované jako internetové registry zpřístupňující informace o společnostech a jiných entitách a jejich rozhraních (API) [18]. Zjednodušeně řečeno, jde o registr informací připomínající společnostech například telefonní seznam, s pomocí kterého lze nalézt informace o a jimi vystavovaných službách. Vlastní registr UDDI je rovněž webovou službou a komunikuje se s ním pomocí SOAP zpráv[9]. Je vystavěn na existujících standardech jazyka XML a protokolu SOAP. Tok služby Obr. 2.13. Zakomponování UDDI ve WS Na obrázku 2.13 můžeme vidět jak je UDDI začleněné ve vrstvách webových služeb a tvoří jednu z klíčových komponent pro specifikaci, vyhledání a vyvolání webových služeb. Specifikace UDDI definují: SOAP aplikační programové rozhraní (API) používané programy, které žádají nebo zveřejňují informace pomocí těchto registrů XML schémata datového modelu registrů a formáty zpráv SOAP definice WSDL pro programové rozhraní SOAP definice (technické modely - tmodels) identifikátorů a kategorizačních systémů používaných k identifikaci a kategorizaci UDDI registrací. 45 1!1 1[1 1[1 I r,i ' ij''.'.
Registr UDDI má 2 hlavní funkce: zveřejňovaní- obvykle dochází k registraci společností, které mají zájem na zveřejnění jimi nabízených služeb vyhledávání- jiné společnosti mohou tyto zveřejněné služby pomocí registrů nalézt a využít. Vlastní registr UDDI není nutné požívati jen pro registraci webových služeb, je navržený obecně a může registrovat jakýkoliv typ služeb. To znamená, že služby které jsou v něm registrovány nemusí podporovat SOAP rozhraní a rovněž nemusí být popsány ve formátu WSDL, nicméně ideální a doporučované je společné použití všech těchto tří zde popisovaných komponent(soap,wsdl,uddi) společně. 2.6.1 Historie UDDI 1.0 bylo původně uvedeno společnostmi Microsoft, IBM a Ariba v září 2000. Dnes vystupuje UDDI jako samostatná iniciativa QJ.ttp://www.uddi.org) pod záštitou organizace OASIS a zahrnuje již přes 300 organizací. V květnu 2001 Microsoft a IBM zprovoznili první veřejné adresáře odpovídající specifikaci UDDI 1.0. O měsíc později byla zveřejněna specifikace UDDI 2.0, která přinesla některé drobné úpravy v datovém modelu a rozšířila množinu vyhledávacích operací. V únoru 2005 byly dokončeny práce na verzi 3.0, která byla schválena organizací OASIS jak standard. Obsahuje například zásadní změny v konceptu UDDI, týkající se registrace a vzájemné interakce veřejných a privátních UDDI registrů. Tabulka 2.3 udává přehled vydání jednotlivých verzí UDDI[21]. Verze UDDI 1.0 2.0 Rok vydání 2000 2003 IDavní cíl Vytvoření základní báze registrů dat společností podnikajících prostřednictvím internetu. Připojení se ke vznikajícím standardům webových služeb a poskytnutí podpory pro flexibilní systémy 46
setřídění. 3.0 2004 Podpora zabezpečené komunikace mezi veřejnými a privátními implementacemi. Tabulka 2.3. Přehled vydání jednotlivých verzí UDDI 2.6.2 Princip fungování UDOl Registry UDDI tedy poskytují programové informace, které poskytují informace o společnostech a jimi podporovaných službách. Dále nám poskytují programovací model a schéma, které definují způsob jak s těmito registry komunikovat. Veškeré programové rozhraní (API) je definováno v jazyku XML, zabaleno do obálky SOAP a zasíláno pomocí protokolu HTTP.. Situaci ilustruje obrázek 5.2.1. na kterém je znázorněn klient zasílající požadavek registrům. Je zpracován obvykle HTTP a SOAP serverem a následně je kontaktována přímo databáze registrů UDDI odkud jsou klientovi vrácena příslušná volání API. V rámci zabezpečení se používá zabezpečeného přenosu pomocí SSL(Socket Secure Layer). Registry UDOl Klient UDDISOAP požadavek UDOl SOAP. odpověď Vytvoření,prohlednutí,aktualizace, smazaní registrace Obr. 2.14. Tok zpráv mezi klientem a registry UDDI 47
Je nutné si uvědomit, že stejně jako celá technologie webových služeb, tak i UDDije zaměřeno především na vývojáře. UDDI je a bude využíváno hlavně pro získávání technických specifikací webových služeb vedoucích k jejich snadné implementaci do firemního IS. Vyhledávání a využívání veřejných webových služeb laickými uživateli je zatím vzhledem k nutnosti "programátorských" znalostí velmi obtížná. 2.6.3 Datový model UDOl Registr UDDI je tvořen datovými entitami, které jsou definovány schématem XML. Toto schéma lze pro verzi 3.0 nalézt na adrese http://uddi.org/schema/uddi v3.xsd. UDDI definuje následující datové typy: businessentity- představuje organizaci poskytující WS, businessservice- popisuje kolekci WS poskytovaných organizací, bindingtemplate -technické informace pro použití WS, tmodel- popisuje technický model (např. typ WS, používaný protokol atd.), publisherassertion- relace jedné businessentity k jiné, subscription - souhrn změn entity. 48
businessentity: Informace o organizac~ kter.á prostřednictví I tmodel: Popis rozhraní služby nebo odkaz na externí technickou r- UDOl publikuje webové služby specifikaci (WSDL}, příp. taxonomii ~ ~ I ~ I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I \ I - businessservice: Informace o -- konkrétní webové službě - r-- bindingtemplate: Technické '--- informace o přístupu ke službě a - specifikace způsobu komunikace publisherassertion: Informace o vzájemném vztahu mezi dvěma ~ organizacemi I I I Obr. 2.15. Datový model UDDI Z obrázku 2.15 můžeme vypozorovat, že jednotlivé entity mezi sebou tvoří relace, které budou popsány v následujících kapitolách. určité 2.6.3.1 Entita businessentity Entita businessentity je na nejvyšší úrovni tohoto datového modelu. Obsahuje informace o společnosti nabízející určité webové služby, které jsou definovány entitou businessservice. Její definice v XML schématu je následující: cxsd:element name="businessentity" type="uddi:businessentity" final="restriction"/> cxsd:complextype name="businessentity" final="restriction"> cxsd:sequence> cxsd:element ref="uddi:discoveryurls" minoccurs="o"/> cxsd:element ref="uddi:name" maxoccurs="unbounded"/> cxsd:element ref="uddi:description" minoccurs="o" maxoccurs="unbounded"/> cxsd:element ref="uddi:contacts" minoccurs="o"/> cxsd:element ref="uddi:businessservices" minoccurs="o"/> cxsd:element ref="uddi:identifierbag" minoccurs="o"/> cxsd:element ref="uddi:categorybag" minoccurs="o"/> 49
cxsd:element ref="dsig:signature" minoccurs="o" maxoccurs="unbounded"/> </xsd:sequence> cxsd:attribute name="businesskey" type="uddi:businesskey" use="optional"/> c/xsd:complextype> Tato entita je jedinečně identifikována atributem businesskey, který představuje unikátní identifikátor. Při zveřejňování entity do UDDI registrů jsou dvě možnosti jak dodat daný identifikátor. První možností je, že dodáme tento klíč sami. Druhou možností pak je, že ponecháme tento atribut prázdný, přičemž v tomto případě dochází ke generování klíče v okamžiku vkládání do registrů na jejich straně. To v praxi tedy znamená, že tento identifikátor je při získávání z registrů vždy přítomen. Mechanismus dodávání těchto identifikátorů je obdobný i u dalších entit modelu UDDI. Jediným povinným elementem je name obsahující název společnosti. Element businesssenlice je seznamem služeb, které společnost zveřejňuje. Je tedy propojením k entitám businessservice. Entity identifierbag a categorybag budou blíže specifikovány v kapitolách věnovaných identifikaci a klasifikaci. Další informace v této entitě jsou deskriptivní a doplňující informace obsahující například údaje o oboru v kterém společnost podniká. 2.6.3.2 Entita businessservice Tato entita stojí, co se týká úrovně, pod entitou businessentity a představuje už jednotlivou webovou službu. Tato entita neobsahuje technické informace, ty lze získat prostřednictvím relační entity bindingtemplate. Relačním klíčem k nadřazené entitě je volitelný atribut businesskey. Jde tedy o vztah 1 :N z pohledu nadřazené entity. Následuje definice této entity v XML schématu: <xsd:complextype name="businessservice" final="restriction"> cxsd:sequence> 50
cxsd:elernent ref="uddi:narne" rninoccurs="o" rnaxoccurs="unbounded"/> cxsd:elernent ref="uddi:description" rninoccurs="o" rnaxoccurs="unbounded"/> cxsd:elernent ref="uddi:bindingternplates" rninoccurs="o"/> cxsd:elernent ref="uddi:categorybag" rninoccurs="o"/> cxsd:elernent ref="dsig:signature" rninoccurs="o" rnaxoccurs="unbounded"/> c/xsd:sequence> cxsd:attribute narne="servicekey" type="uddi:servicekey" use="optional"/> cxsd:attribute narne="businesskey" type="uddi:businesskey" use="optional"/> c/xsd:cornplextype> Analogicky i zde můžeme vidět identifikační atribut servicekey, pro jehož zadávání platí stejné podmínky jako pro klíč nadřazené entity businessentity. Volitelný atribut businesskey obsahuje referenci na nadřízenou entitu businessentity. Zde lze podotknout, že tento klíč nemusí obsahovat vždy stejnou hodnotu jakou drží entita businessentity. Může k tomu dojít v případě, kdy společnost zahrne do své entity businessentity odkaz na službu zprostředkovávanou jinou organizací. V tomto případě hovoříme o tzv. projekci služby(service projection) [20]. Element narne je názvem služby a informace o popisu služby drží element description. Element bindingternplates je seznamem podřízených entit bindingternplate. Je tedy propojením mezi těmito dvěma entitami. Opět jde o vztah 1 :N z pohledu entity businessservice. 2.6.3.3 Entita bindingtemplate li Entita bindingternplate obsahuje technické specifikace ohledně webové služby. Poskytuje tedy informace o instanci webové služby, která je přístupná pomocí síťové adresy, typicky pomocí identifikátoru URL. Říká nám jak a kde je tato webová služba přístupná. Její definice ve schématu je následující: <xsd:cornplextype narne="bindingternplate" final="restriction"> cxsd:sequence> 51 rl. I' ::1. I" /:]'i I
cxsd:element ref="uddi:description" minoccurs="o" maxoccurs="unbounded"/> cxsd:choice> cxsd:element ref="uddi:accesspoint"/> cxsd:element ref="uddi:hostingredirector"/> c/xsd:choice> cxsd:element ref="uddi:tmodelinstancedetails" minoccurs="o"/> cxsd:element ref="uddi:categorybag" minoccurs="o"/> cxsd:element ref="dsig:signature" minoccurs="o" maxoccurs="unbounded"/> c/xsd:sequence> cxsd:attribute name="bindingkey" type="uddi:bindingkey" use="optional"/> cxsd:attribute name="servicekey" type="uddi:servicekey" use="optional"/> c/xsd:complextype> Princip identifikátoru bindingkey Je opět totožný jako v případě klíčových identifikátorů dvou předchozích entit. Atribut servicekey je propojovacím článkem k nadřazené entitě businessservice. Element description opět udržuje informace o krátkém popisu služby. Element accesspoint je textovou informací obsahující síťovou adresu, která je obvykle ve formátu URL, nicméně taktéž lze například využít e-mailovou adresu nebo dokonce telefonní číslo. Další prvek ve výběru je hostingredirector, který se ale už nepoužívá a je zde jen kvůli zpětné kompatibilitě. Entita tmodellnstancedetails obsahuje seznam jednoho nebo více elementů typu tmodellnstancelnfo. Podstatná je také skutečnost, že tento element obsahuje kolekci atributů tmodelkey udržujících referenci na entitu tmodel. 2.6.3.4 Entita tmodel Tato entita je sice na nejnižší úrovni v datovém modelu UDDI, ale svým způsobem je nejdůležitější entitou v systému UDDI. Obecně je jejím hlavním účelem poskytnout abstraktní referenční systém - tzn. se používá tam, kde je potřeba se odkazovat na nějakou (externí) specifikaci. Například technická dokumentace, kterou potřebuje vývojový pracovník pro svoji práci s webovými službami, není obsažena přímo v registrech UDil, ale pomocí entity tmodel lze na ni získat odkaz adresou URL. Významná je také skutečnost, že lze z této informace získat i metadata o této 52
dokumentaci a identifikátor entity, která je svázána s daným tmodelem. Tato entita bývá používána pro následující účely v rámci UDDI: definice přenosu a transportních protokolů jako HTTP nebo SMTP, k definování množin hodnot identifikačních a kategorizačních systémů a jmenných prostorů, strukturované kategorizace při využití tzv. "kategorizačních skupin", definování formátů lokačních údajů (např. poštovní adresy), nalezení kvalifikátorů používaných k modifikaci chování UDDI API funkcí typu find _ xx využití typů atributů specifikujících typ zdroje, který je odkazován referencí URl, např. v elementu accesspoint[20]. Její syntaxe je následující: cxsd:complextype name="tmodel" final="restriction"> <xsd:sequence> cxsd:element ref="uddi:name"/> cxsd:element ref="uddi:description" minoccurs="o" maxoccurs="unbounded"/> cxsd:element ref="uddi:overviewdoc" minoccurs="o" maxoccurs="unbounded"/> cxsd:element ref="uddi:identifierbag" minoccurs="0"/> cxsd:element ref="uddi:categorybag" minoccurs="o"/> cxsd:element ref="dsig:signature" minoccurs="o" maxoccurs="unbounded"/> c/xsd:sequence> cxsd:attribute name="tmodelkey" type="uddi:tmodelkey" use="optional"/> cxsd:attribute name="deleted" type="uddi:deleted" use="optional" default="false"/> c/xsd:complextype> Jako v předchozích případech obsahuje i tato entita svůj identifikátor, pro který platí rovněž stejná pravidla jako v předchozích případech. Má název tmodelkey a v případě, že není při zavedení entity do registrů UDDI zadán, je jeho hodnota v okamžiku zápisu do registrů generována. Element name by měl být formátován ve tvaru URl. Element overviewdoc obsahuje reference k externím informacím a instrukcím, informace o typu dokumentu na dané adrese URL atd. Důležitou skutečností v souvislosti se systémem WSDL je fakt, že element overviewdoc 53
obsahuje ve své definici element overviewurl, který může odkazovat k vlastnímu dokumentu WSDL popisujícímu rozhraní služby tak, jak bylo v kapitolách věnovaným dokumentu WSDL popisováno. Následující příklad zobrazuje zápis entity tmodel odkazující se na dokument WSDL na adrese http:/ /schema. com/test. wsdl: ctmodel xm~ns="urn:uddi-org:api" AAAA-AAAA-AAAA-AAAAAAAAAAAA"> tmodelkey="uuid:aaaaaaaa cname>hp~com:creditcheckc/name> cdescription xml:lang="en">check limit reporterc/description> coverviewdoc> coverviewurl>http://schema.com/test.wsdlc/overviewurl> c/overviewdoc> ccategorybag> ckeyedreference tmodelkey="uuid:cd153257-086a-4237-b336-6bdcbdcc6635" keyname="consumer credit gathering or reporting services" keyvalue="84.14.16.01.00"/> ckeyedreference tmodelkey="uuid:clacf26d-9672-4404-9d70-39b756e62ab4" keyname="types" keyvalue="wsdlspec"/> c/categorybag> c/tmodel> Pro názornou ilustraci následuje ještě zobrazení zápisu entity businessservice odkazujícího se na tento WSDL dokument pomocí této vydefinované entity: cbusinessservice businesskey="bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb" servicekey="cccccccc-cccc-cccc-cccc-cccccccccccc"> cname>hpcu Credit Checkc/name> cbindingtemplates> cbindingtemplate servicekey="cccccccc-cccc-cccc-cccc-cccccccccccc" bindingkey="dddddddd-dddd-dddd-dddd-dddddddddddd"> caccesspoint URLType="https">https://hpcu.com/creditcheckc/accessP oint> ctmodelinstancedetails> ctmodelinstanceinfo tmodelkey="uuid:aaaaaaaa-aaaa AAAA-AAAA-AAAAAAAAAAAA"/> ctmodelinstancedetails> c/bindingtemplate> c/bindingtemplates c/businessservice> 54
2.6.3.5 Entita publisherassertion Entita publisherassertion se používá ve spojení s entitami typu businessentity a jde o mechanismus vyjádření určité relace mezi dvěma entitami(businessentity) tohoto typu. Příčinou zavedení tohoto mechanismu byla skutečnost, že u některých společností nešlo efektivně využít pro zápis dvou entit tohoto typu jedné entity businessentity. V praxi jde například o velké společnosti s mnoha pobočkami. Její definice v XML schématu je následující: cxsd:complextype name="publisherassertion" final="restriction"> cxsd:sequence> cxsd:element ref="uddi:fromkey"/> cxsd:element ref="uddi:tokey"/> cxsd:element ref="uddi:keyedreference"/> cxsd:element ref="dsig:signature" minoccurs="o" maxoccurs="unbounded"/> c/xsd:sequence> c/xsd:complextype> Tuto relaci mezi dvěma entitami businessentity zpracovávají elementy fromkey a tokey. Je nutné zabezpečit, aby obě tyto společnosti publikovaly entity publisherassertion se stejnými daty tzn., aby vztah byl reciproční. Je na jednotlivých zveřejňovatelích, aby tuto podmínku zabezpečili. Element keyedreference popisuje o jaký vztah se mezi těmito entitami jedná. 2.6.3.6 Entita operationallnfo Prostřednictvím této pomocné entity se udržuje historie publikovaných informací. To nastává v praxi v okamžiku, kdy jsou v registrech publikovány základní datové struktury UDDI. Jde o datum a čas vytvoření záznamů, jejich modifikace a identifikační údaje původců změn a operací na záznamech uzlů UDDI. Pomocí této struktury lze tedy zjistit operační údaje provedené na dříve popsaných entitách. Podoba entity operationallnfo je následující: <Xsd:complexType name="operationalinfo" final="restriction"> 55
<xsd:sequence> <xsd:element name="created" type="uddi:timeinstant" minoccurs="o"/> <xsd:element name="modified" type="uddi:timeinstant" minoccurs="o"/> <xsd:element name="modifiedincludingchildren" type="uddi:timeinstant" minoccurs="o"/> <xsd:element ref="uddi:nodeid" minoccurs="o"/> <xsd:element ref="uddi:authorizedname" min0ccurs="0"/> </xsd:sequence> <xsd:attribute name="entitykey" type="uddi:uddikey" use="required"/> </xsd:complextype> 2.6.4 Klasifikační a identifikační systém UDOl Jelikož se předpokládalo, že se registry UDDI budou neustále rozšiřovat, budou nabývat velkého objemu dat a vyhledávání bez nějakého systému bude proto velmi neefektivní a pomalé, vyvstala za tímto účelem lepšího vyhledání a zjištění informací z registrů UDDI potřeba vyvinout nějaký identifikační a klasifikační mechanismus. Pokud si uvědomíme, že jedním z hlavních smyslů registrů UDDI je proces vyhledání, pak je tato snaha naprosto zřejmá. Návrh této koncepce jde jak cestou využití stávajících identifikátorů (např. DUNS), tak cestou vytvářením vlastních schémat. Prostředkem k dosažení tohoto cíle je skutečnost, že jádrem návrhu UDDI je schopnost strukturovat a modelovat data a metadata. 2.6.4.1 Identifikační systém UDDI Identifikační systém UDDI slouží k přiřazení identifikátorů informacím vedených v registrech. Smyslem tohoto systému je, aby uživatel mohl následně vyhledat tyto informace pomocí různých identifikačních systémů. Mezi standardní podporované systémy patří: D-U-N-S Number Identifier System Thomas Register Supplier Identifier Code System. 56
Systém UDDI nabízí také možnost vytvoření vlastních systémů pro použití například v privátních registrech. Tyto identifikátory mohou být přiřazeny dvěma entitám z datového modelu UDDI a sice entitě businessentity a tmodel. Tyto entity obsahují element identifierbag, který slouží pro uchování informací vedených v registrech. Situaci ilustruje následující obrázek, který schematicky znázmňuje přiřazení tří identifikátorů (DUNS,GLN, US Tax Code) společnosti My Company Inc. busínessentlty: My Company Inc. buslnesskey: uddl:my_oompany.example Obr. 2.16. Přiřazení identifikátorů entitě businessentity V syntaxi XML by tato situace byla zapsána následovně: cbusinessentity businesskey="uddi:my_company.example"> cidentifierbag> ckeyedreference tmodelkey="uddi:uddi.org:ubr:identifier:dnb.com:du- n-s" keyname="d-u-n-s:my Company" keyvalue="12-345-6789"/> c/identifierbag> </businessentity> Element identi.fierbag obsahuje subelement keyedreference, jehož výskyt není limitován, a proto je tedy možné přiřadit jedné entitě více identifikačních klíčů. Obsahuje atribut tmode!key odkazující se na entitu tmodel, která identifikuje použitý identifikační systém. 57
2.6.4.2 Klasifikační systém UDDI Podobný systém jako pro identifikaci existuje i pro klasifikaci informací v registrech UDDI. Možnost přiřazení klasifikačních informací je podporována u tří dříve popsaných klíčových entit UDDI - businessentity, businessservice a tmodel. Tyto entity obsahují elementy categorybag s analogickým systémem jako má element pro identifikaci- identifierbag. Následuje příklad zápisu u entity businessentity: cbusinessentity businesskey="a,a-" xmlns="urn:uddiorg:api v2"> cname>companyc/name> ccategorybag> <keyedreference tmodelkey="uuid:cob9fe13-179f-413d-ba5b-5004dbbe5bb2" keyname="naics: Software Publisher" keyvalue="51121" /> ckeyedreference tmodelkey="uuid:4e49abd6-d5a2-4fc2-93a0-04lldbd19e88" keyname="california" keyvalue="us-ca" /> </categorybag> c/businessentity> Ze zápisu tohoto elementu můžeme zjistit, že jde o společnost z Kalifornie, která se klasifikovala jako softwarový vydavatel pomocí systému NAICS (North American Industry Classification System). Mezi podporované standardní klasifikace patří: NAICS (North American Industry Classification System), UNSPSC (Universa! Standard Products and Services Classification), ISO 3166 - mezinárodní standardní rozdělení do geografických regionů, zahrnující kódy zemí, apod. Stejně jako v případě identifikačních systémů je i zde možné definovat vlastní taxonomické systémy. 2.6.5 Typy registrů UDOl 58
V době začátku vývoje registrů UDDI převládala myšlenka jejich využití v globálním kontextu. Záměrem bylo vybudovat několik centrálních registrů, které by obsahovaly informace o společnostech a jejich webových službách. Postupem času bylo od tohoto konceptu upuštěno a stejná důležitost byla dána budování systémům privátních registrů. Registry z hlediska registrace a přístupu můžeme členit tedy na tyto základní typy: veřejné registry - tyto registry jsou známé pod zkratkou UBR (UDDI Business Registry). Přístup k těmto registrům je otevřený a veřejný. Data v těchto registrech mohou být sdílena a transferována mezi registry. privátní registry - tento typ registrů je izolován od vnějšího síťového prostředí například použitím firewallu apod. Přístup k nim je omezen a data těchto registrů nejsou sdílena. semi-privátní- tento typ registrů může být označen jako kombinace dvou předchozích typů. Jde o registry s řízeným autorizovaným přístupem, které jsou umístěny v kontrolovaném prostředí. Data těchto registrů mohou být sdílena s jinými registry kontrolovaným způsobem. Obr. 2.17. Komunikace UDDI registrů Obrázek 2.17 znázorňuje způsob interakce mezi všemi typy registrů. Jedná se o operace publikace, replikace a monitorování změn. 59
3 Současný stav řešení systému ODS v STK 3.1 Systém DDS 3.1.1 Úvod Dodávání kopie dokumentu( dokument delivery service) namísto výpůjčky je jednou ze služeb, které knihovny, ale i další instituce (např. databázová centra) uživateli nabízejí. Jedná se o službu, která je většinou zpoplatněná a nabízená na komerční bázi. Hlavní podíl na vzniku služby tohoto typu měly především změny v oblasti vědecké komunikace, k nimž došlo po 2. světové válce [26]. V tomto období došlo k nárůstu publikací periodik a komerčních nakladatelství, současně vznikaly nové specializace ve vědě a výzkumu a začala se zvětšovat potřeba nově vzniklé poznatky publikovat. Tento publikační nárůst dal vzniknout novým službám v informačním průmyslu, a to od vzniku nových producentů sekundárních informačních zdrojů až právě ke vzniku komerčních dodavatelů dokumentů. Služby DDS jsou neodmyslitelně spjaty s činností knihoven. Tyto služby zde prošly určitým rozvojem, a to především v souvislosti s rozvojem digitálních technologií a internetu. Můžeme definovat následující základní typy DDS: meziknihovní výpůjční služby (MVS) - jde o služby provozované v rámci spolupracujících knihoven, kdy knihovny na požádání jiné kooperující knihovny zapůjčí ze svého fondu dokumenty pro její potřeby, resp. pro potřeby koncového uživatele, kterému žádající knihovna dělá prostředníka. Jde o službu nekomerční, pouze v případě určitých výjímek (např. urgentní zpracování apod.) může dojít k platbě za tuto službu. komerční dokumentové dodavatelské služby (CDS) - jedná se o nákup dokumentů na komerční bázi, a to od komerčních dodavatelů, kteří v zájmu uživatelů shromažďují veškeré informační zdroje za účelem jejich zpřístupnění. 60
elektronické dodávání dokumentů (EDS) - jde o komunikaci informací v elektronické podobě. To může znamenat jak zprostředkování dokumentu, tak veškerých transakcí doprovázejících tuto službu jako jsou například proces objednávky, platební operace a jiné. sdílení zdrojů (RS12) -je jednou z možností poskytování dokumentů na základě vytvořených kooperačních sbírek, které knihovny využívají pro potřeby svých uživatelů a čtenářů. Na základě smluvního vztahu tedy knihovny zpřístupňují vlastní tištěné i elektronické zdroje uživatelům jiných knihoven. 3.1.2 Přehled poskytovatelů služeb ODS Mezi nejvýznamnější zahraniční poskytovatele této služby patří následující subjekty: British Library Document Supply Center - BLDSC (Velká Británie), dostupné z www <http://www.bl.uklservices/documentldsc.html>, SUBITO (Německo), dostupné z www< http://www.subito-doc.de >, JASON (Německo), dostupné z www <http://www.ub.unibielefeld.de/ english/library/ ordering>, ADONIS (Nizozemí), dostupné z www <http://www.adonis.nl> CISTI (Kanada), dostupné z www <http://cisti-icist.nrccnrc.gc.ca/main _ e.html > INIST (Francie), dostupné z www < http://www.inist.fr/index.php > UnCover (USA), dostupné z www <http://www.ulib.iupui.edu/erefs/carl.html> V České republice se knihovny spoléhaly především na zahraniční dodavatele dokumentů. K prvním projektům elektronického dodávání dokumentů patřil projekt INVIK STK - Integrovaná digitální knihovna, který byl poprvé představen v roce 1997. Byl projektem, který v sobě zahrnoval koexistenci klasické a virtuální knihovny a v rámci jeho služeb bylo možno objednávat digitální kopie dokumentů. 61
V současné době se i v dalších knihovnách rozvíjí služby elektronického dodávání dokumentů. 3.2 Analýza stávajícího řešení systému DDS STK 3.2.1 Dekompozice systému ODS Při objednávání digitalizovaného dokumentu musí žadatel za účelem získání dokumentu či jeho kopie provést určité úkony. Systém DDS stejně jako ostatní systémy lze rozložit na sadu jednotlivých obecných operací, které jsou znázorněny na následujícím obrázku. ~ Kolhmma~ 1 uživatel Obr. 3.1. Komunikace uživatele se systémemdds Obrázek 3.1 nám znázorňuje jakým způsobem může uživatel obecně pracovat se systémem elektronického dodání dokumentu. Tento proces můžeme rozložit na následující operace: 62
vyhledání dokumentu komunikaci se systémem DDS, která zahrnuje tyto dílčí operace: o přihlášení do systému o objednání dokumentu. o digitalizace dokumentu o získání kopie dokumentu,o vyúčtování služeb o odhlášeili ze systému implementace systémů se mohou sam.ozřejmě částečně lišit, nicméně všecrmv zmíněné operace jsou v určité podobě vždy impl~mentovány. Všechny tyto opera~e, tak jak byly popsány, jsou implementovány i ve stávajícím technologickém systému DDS v STK Praha. Testovací verzi tohoto systému lze nalézt na adrese http://as.stk.cz:8080/ypk/dds.mindex. 3.2.2 Technologické zázemí systému DOS STK Řešení systému DDS STK využívá následujícího technologického vybavení: operační systém Linux RedHat 7+ (http://:www.redhat.co:ml), webový server Apache Jakarta Tomcat 5:+ Chttp://www.apache.org), databázový server Firebird 1.5 (b.ttp://www.ibphoenix.coml), běhové aplikační a vývojové nástroje balíku Java J2SDK 1.4.2 (http://www.sun.com). Dřívější řešení zahrnovalo databázový server Oracle (http://www.oracle.com), který byl vzhledem k licenčním podmínkám a finanční náročnosti na provoz nahrazen DB serverem Firebird. Firebird je open-source relační databáze nabízející mnoho vlastností ANSI SQL-92 která pracuje na Linuxu, Windows a řadě unixových platforem. Současně nabízí vysokou propustnost souběžného zpracování, vysoký výkon a silnou jazykovou podporu pro tvorbu uložených procedur a spouští (trigger). Celé řešení je nyní tedy postaveno na open-source technologiích při zachování 63
dostatečného výkonu pro provozování aplikace DDS a snížení nákladů na pořízení a aktualizaci softwaru. 3.2.3 Programové řešení ODS STK Programové řešení stávajícího systému je znázorněno pomocí následujícího schématu. Žlutě podbarvená oblast klientské části je ta část, která by měla být řešena právě i za pomoci technologie webových služeb. čtenář1 IE čtenář2 Mozilla HTIP HTIPS čtenářn http browsero bl ast WS čtenář1 :Čtenář2 čtenářn IE Mozilla http browser \1 HTIPS HTIP/ fax :!'~"O'!"~!.-ll ' ' ~', - ","~ ' " \ \ " I '' \ \ Digitalizační I Digitalizační \ \ pracoviště 2 I pracoviště 3 \ I I I I I I I I I I : '---~---j ~ ~ I I 1\ I \ I I " I \ \ " I I " " \ I \ I \ " I I \ I \ Knlhovna1 1 \ Kníhovna2 \ Knihovna3 I " \ I \ I ',.,~... "".."...., ' '... ' " ",," '' ' I I I Digitalizační \ I pracoviště 4 \ I \ I I I I I I I I \ I \ I '\ ~ I I Knihovna4 I I ' '....." ' "" Obr. 3.2. Stávající řešení systému DDS STK Komunikace systému DDS s vnějším prostředím je řešena pomocí standardních webových rozhraní. Uživatel se k systému připojí pomocí webového prohlížeče (Internet Explorer, Mozilla atd.) a pokud je registrován, může zahájit přes vstupní masky komunikaci s vlastním systémem. Uživatel komunikuje s tzv. DDS servisními 64
centry (dále SC) za pomoci programových komponent napsaných v jazyce Java. Tyto komponenty se nazývají servlety. Servisní centrum plní následující funkce: zajištění objednávek, evidence objednávek, předání objednávek do účastnické knihovny podle lokace požadovaného dokumentu, předání objednávky do jiného servisního centra, kam lokace hledaného dokumentu spadá. Proces lze shrnout do sledu následujících operací (pro ilustraci je znázorněna komunikace požadavku přes dvě DDS centra): 1. Uživatel si objedná elektronickou kopii dokumentu, jehož metadata si dříve našel v katalogu (nejlépe včetně udání lokace) a zašle je (lze použít i formát OpenURL) do objednávkového formuláře v DDS kde je registrován a přihlášen. Objednávkový formulář případně doplní i dalšími údaji (např. upřesnění metadat, kvalita kopie, pokyny pro obsluhu apod.). 2. Servlet DDS převezme údaje z objednávky a zapíše je jako požadavek do vlastní databáze. 3. Program DDSXML zjistí prohlídkou databáze, že vzniknul požadavek a zanalyzuje ho. Podle lokace fondu rozhodne zda jej předá do digitalizačního pracoviště které je napojeno na tento DDS, nebo zda jej předá do jiného DDS (zde např. DDS2). Poté je tento požadavek předán do digitalizačního centra, které je schopno požadavek vyřídit a to realizuje zakázku. 4. V případě, že program DDSXML periodickou prohlídkou zjistí, že v databázi je vyřízený požadavek připravený k předání do jiného DDS, předá ho příslušnému servisnímu centru. 65
5. V databázi je změněn status u objednávky na vyřízeno, což má možnost zjistit i uživatel tím, že kontaktuje centrum DDS pomocí webovského prohlížeče. Od tohoto okamžiku je možné dokument stáhnout. Můžeme definovat následující komponenty systému: uživatelské rozhraní - komponenta určená pro komunikaci s uživatelem umožňující vstup dat a prezentaci obdržených výsledků. Implementováno v jazyce HTML a prezentace pomocí standardních webových prohlížečů. DDS servlety - komunikační článek mezi uživatelským rozhraním a databázovým systémem. Zajišťuje uživatelský přístup k systému, přihlášení a autorizaci uživatele, nabídku objednávkových formulářů, zobrazení stavu zpracování objednávek, stavy účtů, stažení souborů s digitalizovanými daty k uživateli. Dále slouží i k administrativním úkonům jako k zakládání účtů uživatelů, seznamů digitalizačních pracovišť, spolupracujících knihoven apod. datový sklad - realizován databázovým serverem Firebird, sloužícím k uchování všech potřebných dat systému. obslužný program DDSXML - používá se pro komunikaci mezi jednotlivými centry DDS a digitalizačními pracovišti. Obsahuje XML parser na analýzu XML bloků, programy pro rozklad a syntézu XML bloků, příkazy pro databázi, programy pro komunikaci s digitalizačními centry a s jinými instalacemi modulárního DDS systému. Obsahuje vlastní synchronizaci, která tento program periodicky spouští nebo je vyvolán asynchronně příchodem XML bloku ze sousedního DDS. Tento program komunikuje s programem DDS pouze pomocí dat uložených v databázi. klientský program pro digitalizační pracoviště vpkedd.exe -předává serveru nejen informace o průběhu zpracování objednávek, ale i samotné 66
digitalizované dokumenty, a následně v odpovědi přijímá kromě potvrzení o přijatých datech <:!na jejich základě provedených změnách v bázích centra též požadavky, které byly uživateli do systému nově zadány. Aplikace umožňuje zobrazovat a tisknout záznamy požadavků, měnit a doplňovat informace o průběhu jejich zpracování, a ve spolupráci s řídícím softwarem skeneru digitalizuje tištěné dokumenty a převádí je do formátu PDF spolu s kompresí grafických dat, aby výsledná velikost souborů byla co nejmenší. Kromě přímého skenování tato aplikace umí načítat grafické soubory v různých formátech. Digitalizační funkce lze aktivovat i bez vazby na konkrétní objednávku, což umožňuje aplikaci využít i pro účely nesouvisející s VPK. Z daného schématu lze vypozorovat, že v systému jsou dvě na sobě relativně nezávislé části, které spolu sdílejí informace pouze přes datový zdroj. Částí aplikace, která je důležitá pro naše potřeby a bude převedena do webových služeb, je komponenta DDS servletů. Zjednodušeným schématem, které komponenty rozkládá do vrstev, ji lze znázornit následovně( obrázek 3.3). 67
Datová vrstva Aplikační logika ~ Web kóntejrler Prezentační logika Prezentace Obr. 3.3. Stávající řešení vnější části systému DDS Rozkladem do těchto vrstev zjistíme, že vrstva aplikační logiky neobsahuje žádný element a že komponenta servletů DDS tedy komunikuje napřímo s datovým zdrojem. Nejen v souvislosti s návrhem webových služeb do stávajícího systému by stálo za úvahu přepracování systému do následující podoby( obrázek 3.4). 68
Datová vrstva... t.... I I Aplikační /, logika / ',......... L....,........ / ' / ' / ' ' WS klienti Prezentace Obr. 3.4. Návrh na úpravu vnější části systému DDS Začlenění této úpravy do systému by mohlo přinést následující výhody: centralizaci business logiky, odstranění duplicity úprav výkonné logiky, zjednodušení údržby a úprav systému, zlepšenou modularitu systému (možnost opakovaného využití objektů) 69
4 Návrh rozhraní objednávkového systému DOS pomocí webových služeb 4.1 Analýza problému Cílem úpravy stávajícího systému DDS je jeho rozšíření do oblasti webových služeb tak, aby budoucí klienti mohli využít vlastních programových řešení pro komunikaci s DDS centrem. Půjde o návrh systému na úrovni rozhraní WSDL, kdy stávající procesy komunikace uživatele s centrem DDS budou navrženy do jednotlivých webových služeb. Tento proces bude zahrnovat následující kroky: definice kandidátů na služby, návrh WSDL dokumentu: o návrh datových typů a objektů pomocí XML schématu, o návrh zpráv, o návrh metod, o navázání na konkrétní přenosový formát, o definici služby. Pro návrh systému pomocí dokumentu WSDL použijeme styl kódování documentliteral. Tento typ zvolíme s ohledem na skutečnost, že budeme definovat datové typy pomocí XML schématu a umožníme validaci dokumentu daného schématu pomocí XML analyzátoru. Díky vydefinování typů pomocí XML schématu bude také lépe zabezpečena integrita aplikace a tazatelé služby budou mít lepší přehled o použitých výčtových typech a přípustných hodnotách předávaných parametrů. 4.1.1 Entity WS V rámci jednotlivých webových služeb je možné definovat následující entity: 70
Objednávka, Uživatel, Účet uživatele. Každá entita bude obsahovat vlastnosti, které jí logicky patří a jsou obsaženy ve stávajícím systému a které budou dále vydefinovány na základě datového modelu systému (např. velikost a typ vlastností). 4.1.2 Datový model databáze ODS STK Datový model databáze pro systém DDS je tvořen soustavou tabulek a z nich vytvořených pohledů (views), které slouží pro přehlednější a kompaktnější práci s datovým systémem. Datový model je důležitou informací pro naše řešení, neboť nám poskytne informace o datových typech, které nám poslouží při navrhování datových typů pro XML schéma budoucích webových služeb. Datový model(obrázek 4.1) zobrazuje pro lepší přehlednost pouze výběr tabulek, které budou využity pro další práci a rovněž zde nejsou zobrazeny všechny číselníky, které mají obdobný charakter. 71
rolh."<:l'i. ID li<tt:gl'ji FOADD( TYPE C:rl.~l'i.(1} FBÁDDF..ESS VA1iCHAFi[255) 'v?1<jú:""yw01i.os.. ADDfiESS.. TY:"E rr---------il'>i" ~ofie!..d VNl.L':. C.'iA1i.(1} FOO:.SCŘPTlON' VARCHA1i.(2.. 1'351\i Sli\~!.!.L\1' ldsc_~c- R~ rouseii " rous!oiijd sc_usffi lntegefi F5:."'le-!A- VAF..Cl'AR(2_ f5usffi..!'iame VAi'iC.'-'Al\{60) f5cei<tt:ii ID!NTt:Gl'Ji roeilal!. VAACHAi'i.(.I(J) FOACTl'/E.. C.'!Ai'i(1) ~ f5cfi."-ated Cl-i~i'i{H) f5modlf~d Ci-'Ai'i(H) f5agr:.eitbit NO VA."iC1-'Ai'i{20) ~NG - Ci'A"i(1) f51co VARC'r'AR(15} f5dlc VA1i.C.'"'AR(1t) f5co!.'tact PERWN VARCl'A"i{OO) SC_ACCH lt re.~cc!d f5\is:ř ID F5REaiD fotra~.. TII/č FSCOST FOACCOUNT CODE Fro?E.=.ATlON COD:. f5taa\ls.. AC"~IJNT OOUS!.E!'R:.CJS.-"' ~NTEGffi VARCHJI,"i(22} Cl-'AFi[1!) IM6lC(6.2} CHA"i(1) CHAi'i(1) L'VTEGEFi roltst:rt %0 ln'tegsi. f5!.. 0GlŇ WJ/č VAACI"AR(i5} f5?ass - VA."iCrAi'i(15} F&IATE CHAl\{1) ropř.one.. VAFiC."Ai'i{.I(J} FS FAX F5?ROC lnfo f5tooo -INFO f5us:.i'i -TYPE ~.N'iJE..IĚCT TY?E r~ctive - f5eamk_acc f51..s.. SORT lt rof.eq ld 1'1 f5coi.ii.l:.nt NO f5comm5\t.. fi'iom F5COI!JtENl' )EXT VARCi'AR(tO) C."AR(1) Cl-'Aii.(1) Cl'Aii.(i) Cl-'Ai'i(1) C,'-'A'\(1) VAACHAi'i(SO) S!!A!.!.lNT / lnteger integ9\ í~teg::r VAii.Cl-'A!i.(~.. lt roit:.q ID I.'VTEC~i'i f""dforě:gn_ř~q_!d ~hi!ec..ffi FSUSEři io LV"TEC..ai. f5ctii/i CHAA(1!) f5mtlt.l:. Cl'Ai'i{14) f5dtlme CHAR(il) f5s."e::d Ci-'AFi(i} f5type Ci"A'\(1} f5fieq TYPE 0'AR(1) f5fief.. VAFiC!-'A"i[20) f5de!.iv""ci'i.y Ci-'Ai'i(1} F5D?I St'AWNT f5s!'ijtpac-es C."Ai'i{1) FBPJ:CPENT VARCPA,{&J) FO?AC-E VA.'iCi"AFi(21J) f5co:.i Nl!ME.'llC(6.2) F5DE!.AY lnfo Ci"Aii.{14) FEAtm-;0:::; VAACHAA("J) f5tm.e VAR::-r'A'i(1~J) f5.klljfinai. VARc.'Wt(1ZJ) f5issn VAAC.'!Ai'i(10} f5!s5n VAi'iCt'Ai'i(10} rttlofief VA,'iCi'Aii['20} f5yeai'i VA,'iCHA."i(10} f5vouíllif VM\CHAA(10/ f5issue VAFiCt'A'\["J) P.:-PAGES VAFiCrAI'if20/ i'sr'l!.ewjie VA,'\Ci-'AFi(100] f5d-el:-.ied c.''ai'i(1) f5c.lt SOL!iiC:: VAFiCi'AI'i(1~) F5Pi.,'ŠÍ.JSi-:EFi VAFiCHAA(s:J) F5FiEQ GRP C:rll\ii.(1) f5!_t!i/e Ci'Jl.Fi(14) f5fitij/č Ci'AR(14) F500C_TYPE Ci-'Ai\(1) Obr. 4.1. Část datového modelu databáze DDS Model obsahuje následující tabulky (část z nich lze vidět ve výše uvedeném modelu): se_ AeeH (peněžní účty uživatelů) se_addr (adresy uživatelů) se_eenter (servisní centra) se LIB (zúčastněné knihovny) se_ LIB_ DEP (oddělení zúčastněných knihoven) se_lib_sid (servisní identifikátory knihoven) se_ ONLN (statistika připojení dig. pracovišť) se _P ASS (přihlašovací jména a hesla) se REQ (seznam uživatelských požadavků na služby) se_ REQ_ LIB (knihovny, které mohou požadavky zpracovat) se REQe (komentáře k požadavkům) se REQI (mezinárodní požadavky) 72
SC_USER (seznam všech registrovaných uživatelů) SC _ WRKS (úkoly pro dig. pracoviště) Číselníkové tabulky, které nejsou ve výčtu znázorněné, budou převážně odpovídat možným hodnotám vlastností jednotlivých entit. Hlavní tabulky použité pro mapování do entit jsou SC_USER, SC_ACCH a SC_REQ. 4.1.3 Definice XML schématu XML schémata se dají definovat různým způsobem. V tomto případě zvolíme metodu, kdy nejprve vydefinujeme všechny datové typy a teprve na základě těchto datových typů budeme definovat následné elementy. Jde sice o nejpracnější metodu, ale její výhoda spočívá v tom, že je nejflexibilnější. Pro většinu datových typů bude použito odvození pomocí restrikce, což znamená, že dojde k uplatnění omezení na použité bázové typy. určitých Následující kapitoly budou věnovány definování typů jednotlivých entit a vlastních elementů entit. 4.1.3.1 Element Objednávka Element Objednávka slouží pro reprezentaci vlastního požadavku. Pro tento element definujeme následující vlastnosti: název dokumentu, číslo časopisu, název článku, autor, stránka, issn, ročník, 73
rok vydání, zákaznické číslo, typ formátu výstupu(tiff,pdf), způsob doručení (normálně,expresně), barevný výstup (barevně,čemobíle,stupně šedi), dělení stránek, konečný příjemce(pokud není shodný se zadávajícím), knihovna( zatím pouze NK), komentář. Definováním pomocí XML schématu získáme následující komplexní datový typ (úplná definice všech jednoduchých datových typů a celého WSDL dokumentu je součástí přílohy-příloha č.l): <!-- objednávka--> <xs:complextype name="torder"> <xs:annotation> <Xs:documentation> definice typu objednávky </xs:documentation> </xs:annotation> <Xs:sequence> <Xs:element name="orderid" type="stk:torderid"/> <Xs:element name="document name" type="stk:tdocument_name"/> <xs:element name="number" type="stk:tnumber"/> <Xs:element name="article name" type="stk:tarticle name"/; <Xs:element name="author" type="stk:tauthor"/> <xs:element name="pages" type="stk:tpages"/> <Xs:element name="issn" type="stk:tissn" nillable="true" minoccurs="o"/> <XS:element name="volume" type="stk:tvolume"/> <Xs:element name="publishing_year" type="stk:tpublishing_year"/> <xs:element name="custorder number" type="stk:tcustorder_number" nillable="true"/> <Xs:element name="delivery_type" type="stk:tdelivery_type"/> <xs:element name="delivery speed" type="stk:tdelivery speed"7> <Xs:element name="color output" type="stk:tcolor output~/> <Xs:element name="split pages" type="stk:tsplit pages"7> <Xs:element name="end_recipient" type="stk:tend_recipient"/> <Xs:element name="library" type="stk:tlibrary"/> 74
cxs:element name="comment" type="stk:tcomment" minoccurs="0"/> c/xs:sequence> c/xs:complextype> Z tohoto vydefinovaného komplexního typu vytvoříme definici vlastního elementu objednávky: cxs:element name="order" type="stk:torder"/> Pro potřeby další webové služby pro výpis stavu objednávek využijeme právě vydefinovaného elementu objednávky a vytvoříme následující komplexní typ: cxs:complextype name="torders"> cxs:sequence> cxs:element name="order" type="stk:torder" minoccurs="o" maxoccurs="unbounded"/> c/xs:sequence> c/xs:complextype> Můžeme si všimnout, že zde jako horní hranici možnosti výskytu elementu objednávky ( order) definujeme hodnotu unbounded, což v praxi znamená, že počet výskytu těchto elementů není omezen. Tímto způsobem lze přenést neomezený počet objednávek (teoreticky, v praxi se většinou použije určitých kritérií ke snížení přenosu dat) a jedná se tedy o pole (array). Po vydefinování tohoto typu následuje definice elementu: cxs:element name="orders" type="stk:torders"/> 4.1.3.2 Element Uživatel V rámci webových služeb bude působit entita Uživatel s následujícími charakteristikami: jméno(název) adresa elektronické pošty (e-mail) telefon 75
fax adresal (adresa ze smlouvy) adresa2 (adresa pro fakturaci) adresa3(adresa kam zaslat fakturaci, pokud se liší od adresy2). Typ, který bude tuto entitu reprezentovat, bude vypadat následovně: cxs:complextype name="tuser"> cxs:sequence> cxs:element name="id" type="stk:tuser id"/> cxs:element name="user name" type="stk:tuser_name"/> cxs:element name="email" type="stk:temail" min0ccurs="0"/> cxs:element name="telephone" type="stk:ttelephone" minoccurs="o"/> cxs:element name="fax" type="stk:tfax" minoccurs="o"/> cxs:element name="addressl" type="stk:taddressl"/> cxs:element name="address2" type="stk:taddress2" min0ccurs="0"/> cxs:element name="address2" type="stk:taddress3" minoccurs="o"/> c/xs:sequence> c/xs:complextype> Z tohoto komplexního typu nadefinujeme následující element: cxs:element name="user" type="stk:tuser" /> 4.1.3.3 Element Účet uživatele Element Účet uživatele bude sloužit k získání informací o peněžním kontu uživatele. Obsahuje následující charakteristiky: časový údaj operace typ operace s účtem (založení konta, navýšení konta,platba za služby, převod mezi účty, zrušení účtu částka zůstatek na kontě. 76
Definice komplexního typu je následující: cxs:complextype name="taccount_stmt"> cxs:sequence> cxs:sequence maxoccurs="unbounded"> cxs:element name="timestamp" type="xs:datetime"/> cxs:element name="accountoperation_type" type="stk:taccountoperation_type"/> cxs:element name="charge" type="stk:tcurrency"/> cxs:element name="output" type="stk:tcurrency"/> c/xs:sequence> cxs:element na~e="total"/> c/xs:sequence> c/xs:complextype> Definice elementu potom bude vypadat takto: cxs:element name="account stmt" type="stk:taccount stmt"/> 4.1.4 Definice kandidátů na služby Pro návrh možných kandidátů na služby použijeme grafické znázornění pomocí jazyka UML, který slouží k návrhu aplikací. Použitou metodou bude v tomto případě případ užití(use Case). Možným nástrojem pro tvorbu UML diagramů je například produkt společnosti SUN Microsystems- Java Studio Enterprise, který je v současné době nabízen zdarma (http://www.sun.com), komerční produkt Microsoft Visio společnosti Microsoft nebo produkt společnosti IBM Rational Rose(http://www.ibm.com). Případy užití neboli Use Case, jsou psány z pohledu zákazníka a podávají první představu o rozsahu projektu. V této fázi analýzy se ještě nezabýváme technologickými aspekty řešení, a proto se zde používají pouze pojmy přirozeného jazyka a termíny z problémové domény. Je to proto, aby se co nejvěrněji a pro zákazníka co nejsrozumitelněji navrhl funkční skeleton systému. Tato metoda nám vhodně poslouží pro návrh webových služeb systému. 77
Obr. 4.2. Návrh kandidátů na služby pomocí jazyka UML Schéma na obrázku 4.2 nám přehledně znázorňuje, jak by mohly vypadat operace znázorněné pomocí modelu případu užití. Uživatel webových služeb komunikuje se systémem DDS, který rozčleníme na tyto základní operace: operace s jednotlivou objednávkou, výpis zadaných objednávek, výpis peněžního konta uživatele, registrace uživatele. Tyto procesy můžeme rozložit na další podprocesy, které mohou být zpracovávány. V tomto případě budou tyto operace vhodnými kandidáty na webové služby. Operace s objednávkou může obsahovat následující podoperace: zadání nové objednávky úprava stávající objednávky 78
zrušení stávající objednávky zjištění stavu objednávky vyzvednutí objednávky. Proces registrace bude obsahovat následující služby: úprava registrace zrušení registrace. U procesu výpisu objednávek a peněžního účtu zatím není předpokládán rozklad na další operace, proto budou tyto operace brány do úvahy jako jednoduché informační služby. Součástí zasílaných parametrů každé služby budou přihlašovací údaje uživatele. 4.1.4.1 Služba zadání nové objednávky Tato služba by měla sloužit pro zadání nové objednávky pro kopii digitalizovaného dokumentu. Předpokladem pro funkčnost této služby bude zaslání všech potřebných údajů nového požadavku tak, aby byl systém schopný tuto objednávku zpracovat a připravit k vyřízení. Tyto údaje budou systémem DDS převzaty a v případě kladného zpracování bude navrácen identifikátor objednávky. V případě chyby vrátí služba identifikátor chyby v parametru návratového kódu. Může jít například o následující chyby: chybějící povinná položka identifikující požadovaný dokument nesprávně zadaná položka neplatná autorizace jiné. Správné určení možných problémů je pro aplikaci důležité především proto, aby věděla, jak má v takových situacích reagovat. To je důvod, proč budou u služeb uvažovány i předpokládané chybové varianty. 79
Definice zpráv ve WSDL dokumentu bude následující (pro návrh WSDL dokumentu použijeme vývojové prostředí Eclipse, které je dostupné zdarma na adrese http://www.eclipse.org/ ): cwsdl:message name~"neworderrequest"> cwsdl:part name="order" element="stk:order" /> cwsdl:part name="login_info" element="stk:login info" /> c/wsdl:message> cwsdl:message name="neworderresponse"> cwsdl:part name="orderid" element="stk:orderid" /> cwsdl:part name="errorcode" element="stk:errorcode" /> c/wsdl:message> Definice v části porttype: cwsdl:porttype name="stkddsws"> cwsdl:operation name="neworder"> cwsdl:input name="neworder" message="stk:neworderrequest" /> cwsdl:output name="newoiderresponse" message="stk:neworderresponse"/> c/wsdl:operation> I ITW".. cl> [ID htto:/[www.stk.cz/xsd/ Bindings :.... PortTypes Messages I ~ ~g:~u""'y' u"ď ; r:e. soap:operation ~ Eí O stkcfdsws lb S canceiorderrequest 8~Jlnput. lb.~ canceiorder lb S canceiorderre~~nse 8 soap:body [!~' 8. ~ canceireglstration J ~ [±] (v@jif i@i Ji$iijT@td 1-----> ~Jinput lb B canceiregistrationresponse 8 soap:bocjy lth ~loutput lb B changeorderrequest iť, lb ~ changeorder lb B changeorderresponse!ié. soap :operátión. lb ~ changeregistratjon lb B changeregfstrationrequest 8~loůtput...,, 8@} cancéfregistration!i1 8 ~J inpuť. <...,. IB ~ getaccountrnfo, lb B changeregistrationresponse.. B.soap:bodý 8 ~ getrnishedorder lb B getaccountrnforequest n. ~linput 8~loutp~t.,.., lb B getaccountrnforesponse.8 soqp!body ~loutput lb B getrnishedorderrequest!::~ I lb @) chi:mgéord~r lb.. ~. getordersoveniiew lb B getrnishedorderresponse lb~ changér!!gistrat(on, lb ~ getorderstatus lb B getordersoverviewrequest, ' lb ~ neit10rder :~~=~=~ ~ ~: lb B getordersovervíewresponse '"'' ~etorderstatllsh'ontlod I ~ i',' I Obr. 4.3. Návrh WSDL dokumentu pomocí vývojového prostředí Eclipse 80
Obrázek 4.3 znázorňuje využití prostředí Eclipse pro návrh WSDL dokumentu. Tento nástroj umožňuje jak návrh pomocí vlastního zdrojového kódu, tak pomocí grafického návrhového rozhraní, a to prostřednictvím balíku nástrojů WST (web standard tools), který je dostupný na adrese http://www.eclipse.org/webtools/. Tyto nástroje se instalují do prostředí Eclipse jako doplňkový modul a umožňují pokrýt celou oblast vývoje WS- od tvorby WSDL dokumentu až po generování klientské části. 4.1.4.2 Služba úpravy objednávky Tato služba bude sloužit k úpravě stávající objednávky. Parametrem služby bude element objednávky s vyplněnými položkami, které budou aktualizovány podle identifikátoru objednávky. Služba bude vracet návratový parametr identifikující úspěšnost operace. Chyby, které se zde mohou vyskytnout, jsou následující: nesprávně vyplněné údaje neúplně zadané údaje požadavek již byl digitalizován nebo je zpracováván neplatná autorizace jiné. Definované WSDL zprávy: cwsdl:message name="changeorderrequest"> cwsdl:part name="order" element="stk:order"/> cwsdl:part name="login_info" element="stk:login_info"/> </wsdl:message> cwsdl:message name="changeorderresponse"> cwsdl:part name="errorcode" element="stk:errorcode"></wsdl:part> </wsdl:message> Definice porttype: <wsdl:operation name="changeorder"> 81
cwsdl:input name="changeorderrequest" message="stk:changeorderrequest"/> cwsdl:output name="changeorderresponse" message="stk:changeorderresponse"/> c/wsdl:operation> 4.1.4.3 Služba zrušení objednávky Tato služba bude sloužit ke zrušení stávající objednávky. Parametricky bude předán identifikátor objednávky a služba bude vracet kód úspěšnosti operace. Možné problémy jsou následující: neplatný identifikátor, objednávka na digitalizaci již vstoupila do stavu, kdy ji nelze stornovat, objednávka není platná vzhledem k uživateli, neplatná autorizace, jiné. Definice zprávy: cwsdl:message name="cancelorderrequest"> cwsdl:part name="cancelorderrequest" element="stk:orderid"/> cwsdl:part name="login info" element="stk:login_inf;"/> c/wsdl:message> cwsdl:message name="cancelorderresponse"> cwsdl:part name="cancelorderresponse" element="stk:errorcode"/> </wsdl:message> Definice části v porttype: cwsdl:operation name="cancelorder"> cwsdl:input name="cancelorderrequest" message="stk:cancelorderrequest"/> cwsdl:output name="cancelorderresponse" message="stk:cancelorderresponse"/> </wsdl:operation> 82
4.1.4.4 Služba zjištění stavu objednávky Tato služba bude sloužit k zjištění stavu zadaných objednávek tak, aby uživatel věděl, v jaké fázi procesu zpracování jsou jeho požadavky. Možné stavy jsou: zpracovávané, hotové, odmítnuté. Parametrem služby bude opět identifikátor objednávky a návratovou hodnotou bude jeden z vyjmenovaných statusů a návratový kód operace. Možné chybové situace jsou: neplatný identifikátor, objednávka není platná vzhledem k uživateli, neplatná autorizace, jiné. Definice zpráv: <Wsdl:message name="getorderstatusresponse"> <wsdl:part name="order_status" element="stk:order_status"/> <Wsdl:part name="errorcode" element="stk:errorcode"/> </wsdl:message> <wsdl:message name="getorderstatusrequest"> <wsdl:part name="orderid" element="stk:orderid"/> <wsdl:part name="login info" element="stk:login_inf~"/> </wsdl:message> Definice porttype: <wsdl:operation name="getorderstatus"> <wsdl:input name=" getorderstatusrequest" message="stk:getorderstatusrequest"/> <Wsdl:output name=" getorderstatusresponse" message="stk:getorderstatusresponse"/ > </wsdl:operation> 83
4.1.4.5 Služba vyzvednutí objednávky- digitalizovaného dokumentu Tato služba bude řešit vyzvednutí zpracované objednávky. Parametrem bude identifikátor objednávky a návratovou hodnotou bude adresa URL, odkud lze dokument stáhnout. Tato adresa je privátní a přístupná pouze pro uživatele. Možné chybové situace jsou: neplatný identifikátor, objednávka není vyřízená, objednávka není platná vzhledem k uživateli, neplatná autorizace, jiné. cwsdl:message name="getfinishedorderresponse"> <wsdl:part name="url" element="stk:url"/> <wsdl:part name="errorcode" element="stk:errorcode"/> </wsdl:message> cwsdl:message name="getfinishedorderrequest"> cwsdl:part name="orderid"- element="stk:orderid"/> cwsdl:part name="login info" element="stk:login_info"/> - c/wsdl:message> Definice porttype: cwsdl:operation name="getfinishedorder"> cwsdl:input name="getfinishedorderrequest" message="stk:getfinishedorderrequest"/> cwsdl:output name="getfinishedorderresponse" message="stk:getfinishedorderresponse"/> c/wsdl:operation> 4.1.4.6 Služba změny registrace Služba je určena k tomu, aby její pomocí mohl uživatel změnit své údaje. Vstupním parametrem mimo autorizační data bude entita uživatele, výstupním potom návratový kód operace. Možné chybové situace jsou: neplatné údaje, neplatná autorizace, 84
ď " 1 1 jiné. Definice zpráv: cwsdl:rnessage narne="changeregistrationrequest"> cwsdl:part narne="changeregistrationrequestl" elernent="stk:user"/> cwsdl:part narne="changeregistrationrequest2" elernent="stk:login_info"/> c/wsdl:rnessage> cwsdl:rnessage narne="changeregistrationresponse"> cwsdl:part narne="changeregistrationresponsel" elernent="stk:errorcode"/> c/wsdl:rnessage> Definice porttype: cwsdl:operation narne="changeregistration"> cwsdl:input rnessage="stk:changeregistrationrequest" narne="changeregistrationrequest"/> cwsdl:output rnessage="stk:changeregistrationresponse" narne="changeregistrationresponse"/> c/wsdl:operation> 4.1.4.7 Služba zrušení registrace Pokud by byla tato služba implementována, sloužila by k zrušení registrace uživatele služby. Parametrem budou jen přihlašovací údaje a návratový kód operace. Možné chybové stavy: neplatná autorizace, nevyřízené požadavky, jiné. Definice zpráv: cwsdl:rnessage narne="cancelregistrationresponse"> cwsdl:part narne="cancelregistrationresponse" elernent="stk:errorcode"/> c/wsdl:rnessage> cwsdl:rnessage narne="cancelregistrationrequest"> 85
cwsdl:part name="cancelregistrationrequest" element="stk:login_info"/> c/wsdl:message> Definice porttype: cwsdl:operation name="cancelregistration"> cwsdl:input name="cancelregistrationrequest" message="stk:cancelregistrationrequest"/> cwsdl:output name="cancelregistrationresponse" message="stk:cancelregistrationresponse"/> c/wsdl:operation> 4.1.4.8 Služba získání uživatelského přehledu objednávek Pro případ, že bude chtít uživatel získat přehled o stavu všech svých objednávek v rámci určité časové periody, bude definována služba přehledu objednávek. Vstupním parametrem budou přihlašovací údaje, jaké objednávky a s jakým statusem chceme vidět (vše, zpracovávané, hotové, odmítnuté) a časové období, za které chceme přehled obdržet. Návratovou hodnotou bude seznam objednávek a návratový kód operace. Možné chybové stavy: neplatná autorizace, neplatný časový interval, jiné. Definice zpráv: cwsdl:message name="getordersoverviewrequest"> cwsdl:part name="getordersoverviewrequestl" element="stk:order_status" /> cwsdl:part name="getordersoverviewrequest2" element="stk:date_period"/> cwsdl:part name="getordersoverviewrequest3" element="stk:login_info" /> c/wsdl:message> cwsdl:message name="getordersoverviewresponse"> cwsdl:part name="getordersoverviewresponsel" element="stk:orders" /> 86
<wsdl:part name="getordersoverviewresponse2" element="stk:errorcode" /> </wsdl:message> Definice porttype: <Wsdl:operation name="getordersoverview"> <wsdl:input narne="getordersoverviewrequest" rnessage="stk:getordersoverviewrequest"/> <wsdl:output name="getordersoverviewresponse" rnessage="stk:getordersoverviewresponse" /> </wsdl:operation> 4.1.4.9 Služba získání uživatelského přehledu o stavu účtu Tato služba je navržena za účelem získání informácí o stavu a pohybech na peněžním účtu uživatele. Tento výpis bude podán na základě zadaného časového období, které bude vstupním parametrem spolu s přihlašovacími údaji. Výstupem bude entita účtu obsahující informace o účtu a pohybech na něm a opět návratový kód. Možné chybové stavy: neplatná autorizace, neplatný časový interval, jiné. Definice zpráv: <wsdl:rnessage narne="getaccountinforequest"> <wsdl:part name="getaccountinforequestl" elernent="stk:date_period" /> <Wsdl:part narne="getaccountinforequest2" elernent="stk:login_info" /> </wsdl:rnessage> <wsdl:rnessage name="getaccountinforesponse"> <Wsdl:part narne="getaccountinforesponsel" elernent="stk:account strnt" /> 87
cwsdl:part name="getaccountinforesponse2" element="stk:errorcode" /> </wsdl:message> Definice porttype: <wsdl:operation name="getaccountinfo"> cwsdl:input name="getaccountinforequest" message="stk:getaccountinforequest" /> cwsdl:output name=" getaccountinforesponse" message="stk:getaccountinforesponse" /> c/wsdl:operation> 4.1.5 Registrace služby v registrech UDOl Po následné implementaci služby, která není součástí této práce, by měla být služba zaznamenána v UDDI registrech tak, aby došlo k jejímu zveřejnění a využití. Činnost veřejných registrů UBR, o kterých bylo pojednáno v této práci, byla v průběhu ledna roku 2006 zastavena. Důvodem pro toto ukončení provozu UBR měla být skutečnost, že tyto registry jako vzor pro jejich funkčnost svou úlohu splnily, a nastal proto čas pro využití privátních a semi-privátních registrů. Následující kapitoly popisují, jak by náš WSDL dokument mohl být implementován v registrech UDDI. Tato ukázka využívá postupů "best practises", které jsou doporučeny konsorciem OASIS [28]. 4.1.5.1 Mapování entity porttype Entita porttype je v registrech UDDI reprezentována pomocí entity tmodel. <tmodel tmodelkey="uuid:e8cf1163-8234-4b35-865f- 94a7322e40c3"> cname>stkddsws</name> coverviewdoc> coverviewurl>http://www.stk.cz/stkdds.wsdl c/overviewurl> 88
</overviewdoc> <categorybag> <keyedreference tmodelkey="uuid:d01987dl-ab2e-3013-9be2-2a66eb99d824" keyname="porttype namespace" keyvalue=" http://www.stk.cz/xsd/" /> <keyedreference tmodelkey="uuid:6e090afa-33e5-36eb-81b7- lca18373f457" keyname="wsdl type" keyvalue="porttype" /> </categorybag> </tmodel> Název tmodelu je shodný s názvem entity porttype. Element overviewurl obsahuje lokaci WSDL dokumentu, v elementu categorybag jsou obsaženy informace o schématu dokumentu a o tom, že daný tmodel je typemporttype. 4.1.5.2 Mapování entity binding Stejně jako v předchozím příkladu i tato entita je mapována do tmodelu. <tmodel tmodelkey="uuid:49662926-f4a5-4ba5-b8d0-32ab388dadda"> <name>stkddswssoapbinding</name> <overviewdoc> <OverviewURL>http://www.stk.cz/stkdds.wsdl </overviewurl> </overviewdoc> <categorybag> <keyedreference tmodelkey="uuid:d01987dl-ab2e-3013-9be2-2a66eb99d824" keyname="binding namespace" keyvalue="http://www.stk.cz/xsd/" /> <keyedreference tmodelkey="uuid:6e090afa-33e5-36eb-8lb7- lca18373f457" keyname="wsdl type" keyvalue="binding" /> <keyedreference tmodelkey="uuid:082b0851-25d8-303c-b332- f24a6d53e38e" keyname="porttype reference" keyvalue="uuid:e8cfl163-8234-4b35-865f- 94a7322e40c3" /> <keyedreference tmodelkey="uuid:4dc74177-7806-34d9-aecd- 33c57dc3a865" 89
keyname="soap protocol" keyvalue="uuid:aa254698-93de-3870-8df3- a5c075d64aoe" /> <keyedreference tmodelkey="uuid:e5c43936-86e4-37bf-8196- ld04b35c0099" keyname="http transport" keyvalue=" uuid:68de9e80-ad09-469d-8a37-088422bfbc36" /> <keyedreference tmodelkey="uuid:clacf26d-9672-4404-9d70-39b756e62ab4" keyname="uddi-org:types" keyvalue="wsdlspec" /> </categorybag> </tmodel> Tento tmodel jsme také pojmenovali podle názvu elementu binding ve WSDL dokumentu. Lokace WSDL dokumentu je umístěna v elementu overviewurl. Element categorybag obsahuje informace o protokolech, jmenném prostoru dokumentu, o svém typu(binding) a referenci na tmodel elementu porttype. 4.1.5.3 Mapování do entit businessservice a bindingtemplate Do entity businessservice je mapována WSDL entita service. Do druhé entity bindingtemplate je mapována entita port. <businessservice servicekey="l02bl14a-52e0-4af4-a292-02700da543d4" businesskey="le65ea29-4e0f-4807-8098-d352d7bl0368"> <name>document Delivery Service</name> <bindingtemplates> <bindingtemplate bindingkey="f793c521-0daf-434c-8700-0e32da232e74" servicekey="102b114a-52e0-4af4-a292-02700da543d4"> <accesspoint URLType="http"> http://localhost:8080/dds/wsservices/ </accesspoint> <tmodelinstancedetails> <tmodelinstanceinfo tmodelkey="uuid:49662926-f4a5-4ba5-b8d0-32ab388dadda"> <instancedetails> <instanceparms>ddswsport</instanceparms> </instancedetails> </tmodelinstanceinfo> 90
<tmodelinstanceinfo tmodelkey="uuid:e8cfll63-8234-4b35-865f- 94a7322e40c3"> </tmodelinstanceinfo> </tmodelinstancedetails> </bindingtemplate> </bindingtemplates> <categorybag> <keyedreference tmodelkey="uuid:6e090afa-33e5-36eb-blb7- lca18373f457" keyname="wsdl type" keyvalue="service" /> <keyedreference tmodelkey="uuid:d01987dl-ab2e-3013-9be2-2a66eb99d824" keyname="service namespace" keyvalue="http://www.stk.cz/xsd/" /> <keyedreference tmodelkey="uuid:2ec65201-9109-3919-9becc9dbefcaccf6" keyname="service local name" keyvalue="ddsservice" /> </categorybag> </businessservice> Element name drží opět název v tomto případě pojmenování služby. V elementu categorybag najdeme informace o typu entity(service), jmenném prostoru WSDL a lokálním názvu služby. BindingTemplate specifikuje koncový bod služby a udržuje množinu elementů tmodellnstancedetails. Oba elementy tmodellnstancedetails odkazují k dříve definovaným entitám tmodel. 91