Webové služby v knihovnictví

Automatizace knihovnických procesů 2005 (AKP 2005), 10. ročník semináře, Liberec, 3. a 4. květen 2005

Webové služby v knihovnictví Vilém Jirouš * [email protected] Abstrakt: O technologii „Webové služby“ (Web Sevices) je stále více slyšet. Jde o standardizaci prostředků využívání služeb internetu, které může vývojář zahrnout do své aplikace. Využívá se zejména protokolu http (https) a obecně formátu XML. Byly standardizovány formáty registrace služeb a jejich nabídky (UDDI), popisu služeb (WSDL), protokoly (SOAP). Pro technologii WS byly vyvinuty specializované softwarové nástroje usnadňující jejich implementaci. V příspěvku je uvedena vize využití této moderní technologie pro knihovní aplikace. Klíčová slova: Webové služby, UDDI, WSDL, SOAP, knihovní služby

1

Úvod

Čím dál větším požadavkem současného světa informačních technologií a knihoven především je nutnost komunikace a to zpravidla mezi různorodými informačními systémy. V současném prostředí zatím nebyl definován široce použitelný a flexibilní standard pro výměnu dat (pomineme-li např. EDI nebo robustní a těžkopádné technologie typu CORBA a DCOM). Komunikační problémy se tedy často řeší úzce specializovaným softwarem a různými „ad hoc“ řešeními, které sice umožňují komunikaci, ale pouze omezenému okruhu uživatelů. Právě tuto „komunikační“ mezeru by mohla zaplnit poměrně slibně vyvíjející se technologie označovaná jako „Web Services“ – webové služby (WS). Technologie webových služeb je často spojována s tzv. „Servisně Orientovanou Architekturou“- zkr. SOA. SOA vlastně představuje distribuovaný softwarový model, nebo chcete-li filosofii, pro budování informačních systémů, kde jsou právě webové služby jedním ze základních stavebních kamenů.

2

Webové služby

Pojem webová služba (Web Service) nelze striktně definovat. Webová služba může ve své výsledné formě nabývat různých podob, zejména v závislosti na použitých technologiích. Existuje však skupina pravidel, které z obecné služby tvoří právě službu webovou a měly by být pro všechny formy závazné. Obecně lze pojem webová služba definovat jako prostředek pro přístup k aplikacím, který je: dostupný přes internet nebo privátní intranet, používá standardizovaný systém zpráv založený na XML, není závislý na operačním systému nebo programovacím jazyku, jeho rozhraní je popsáno strojově zpracovatelnou XML gramatikou, existuje jednoduchý vyhledávací mechanismus pro nalezení služby. Filosofií webových služeb je v maximální možné míře využít stávající technologie. Jako standard pro výměnu XML zpráv je doporučen protokol SOAP, ale může jím být protokol * České vysoké učení technické v Praze, Fakulta elektrotechnická

1


XML-RPC, příp. architektura REST nebo lze jednoduše využít funkcí protokolu HTTP GET/POST pro zasílání libovolných XML bloků. Transportní vrstvu tvoří některý z protokolů HTTP(S), FTP, SMTP apod.. Pro popis rozhraní služby je doporučeno použití strojovězpracovatelné XML gramatiky zapsané v jazyku WSDL (Web Service Description Language). Pro vyhledávání a publikaci služeb slouží logicky centralizované adresáře služeb označované jako UDDI. Hlavní síla webových služeb je ukryta ve striktním oddělení komunikace a technické stránky komunikujících aplikací. Díky tomu je vždy zajištěna „komunikační kompatibilita“ různorodých informačních systémů (situaci ilustruje obr. 1). Navíc využívá současné technologie a zahrnuje silný aparát pro přesnou a standardizovanou definici služby.

Obr. 1

3

Protokoly webových služeb

Skupina protokolů využívaných webovými službami se stále vyvíjí. V současnosti se rozděluje do čtyř hlavních vrstev, které lze zařadit aplikační vrstvy ISO/OSI modelu. Rozdělení je ilustrováno na obr. 2.

Obr. 2 2


3.1

SOAP ve webových službách

Protokol SOAP je často prezentován jako jeden ze základních stavebních kamenů webových služeb. Definice současné verze 1.2 protokolu SOAP přesně neurčuje, čeho je SOAP zkratka. Budeme-li předpokládat jeho primární účel a tím je, stejně jako v případě RPC-XML, vzdálené volání procedur a funkcí, je SOAP zkratkou pro Simple Object Access Protocol. Druhý výklad zkratky SOAP těží z faktu, že je tento protokol často prezentován jako jeden ze základních kamenů webových služeb, potažmo servisně orientované architektury a v této souvislosti je zkratka SOAP vykládána jako Service Oriented Architecture Protocol. OAP obsahuje nástroje pro vlastní popis obsahu zprávy, způsobu jejího zpracování, množinu pravidel pro vyjádření vlastních datových typů a konvence pro vlastní reprezentaci vzdáleného volání funkcí. Pro tyto účely využívá mimo jiné osvědčené XML technologie, jakými jsou jmenné prostory (zajišťující jednoznačnost jednotlivých XML elementů) a technologii XML Schema (pro definici struktury XML dokumentu, vyspělejší obdoba DTD). Součástí standardu SOAP 1.2 je jeho vazba na protokol HTTP. XML struktura SOAP zprávy je znázorněna na obr. 3. SOAP se ve webových službách dá použít dvěma způsoby a podle toho se dělí i označení webových služeb: SOAP RPC Web services – webové služby využívající SOAP v souladu se svým původním účelem – tzn. využívají zabudovaných funkcí SOAPu k volání vzdálených procedur a funkcí. Klient volá webovou službu na základě specifikace

Obr.3 konkrétní operace a množiny parametrů. V odpovědi se vrací výsledné hodnoty. Definice operací, požadovaných parametrů a návratových hodnot je specifikována ve WSDL

dokumentu – proto dokumentace RPC služby musí být ve formátu WSDL.

SOAP Web services – SOAP je zde použit pouze jako „obálka“ pro přenos libovolného

obsahu uvnitř SOAP zprávy. Tento způsob aplikace SOAPu se někdy označuje jako „document-oriented“ nebo „document-style“. Narozdíl od vzdáleného volání funkcí posílá klient službě jako parametr obecný XML blok, jehož definice může být součástí WSDL dokumentu. Výhody protokolu SOAP oproti přímému posílání XML bloků přes HTTP metodou POST/GET jsou především formalizace datových typů, zaručení jednoznačnosti XML elementů a možnost formálního zápisu operací ve WSDL. Další z výhod je možnost použití některého předefinovaného vzoru pro výměnu zpráv (MEP), začínající jednosměrnou komunikací a končící sofistikovaným systémem pro výměnu sekvencí zpráv. Dokumentace služby musí být ve formátu WSDL. 3


3.2

WSDL

Technologie WSDL (Web Service Description Language) je jedním ze základních stavebních kamenů webových služeb a je v ní ukryta značná část potenciálu webových služeb. WSDL je jazyk pro popis veřejného rozhraní webových služeb pomocí XML formátu, zahrnující kompletní, strojově zpracovatelnou dokumentaci služby – od abstraktního popisu funkcionality služby, až po konkrétní data, říkající „jak“ a „kde“ je tato funkcionalita dostupná. Popis webové služby je rozdělen na dvě části (viz obr. 4): abstraktní část – definuje XML struktury a zprávy (element types), 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 (interface). 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á (endtype) a určení služby (service), kterou tyto cílové body tvoří.

Obr. 4

Obr. 5

4


Obr. 5 demonstruje možnost využití tohoto aparátu v praxi. Rozhraní aplikace (definice vyměňovaných zpráv a XML struktur) je definováno v rámci abstraktní části WSDL (Types, Operations). Logické seskupení těchto operací je určeno abstraktním rozhraním (Interface), přičemž těchto rozhraní může být definováno více – např. rozhraní poskytující uživatelské funkce služby a rozhraní s administračními funkcemi. Na toto rozhraní je „navázán“ konkrétní protokol realizující výměnu zpráv (Binding) – např. SOAP. Koncový bod je přístupný pomocí URI a tvoří tedy konkrétní webovou službu (Service), přičemž každá služba může mít více koncových bodů (např. každý pro jiný komunikační protokol). 3.3

UDDI

Technologie UDDI (Universal Description, Discovery and Integration) po WSDL druhou fundamentální součástí webových služeb. Jejím účelem je naplnění jednoho z pravidel vymezující tento pojem – totiž že webová služba musí být snadno „vypátratelná“. Technologie UDDI je vlastně „Zlatými stránkami“ webových služeb. Jedná se o soubor technologií pro budování distribuovaného adresáře webových služeb, jak na veřejné úrovni, tak i pro vnitřní účely organizací. Technologii UDDI v současnosti tvoří: specifikace UDDI - definuje XML formát pro uložení dat a metadat o službách a společnostech (hierarchická XML struktura uložení metadat je předmětem obr. 6) a definuje API rozhraní pro manipulaci s nimi. Dále zahrnuje aparát pro replikaci veřejných adresářů a s příchodem verze UDDI 3.0 i komplexní pravidla pro komunikaci s privátními UDDI registry, veřejné UDDI adresáře – tzv. UBR (UDDI Business Registry) – plně funkční veřejně přístupné implementace specifikace UDDI (v současnosti verze 2.0).

businessEntity: Informace o organizaci, která prostřednictví UDDI publikuje webové služby.

tModel: Popis rozhraní služby nebo odkaz na externí technickou specifikaci (WSDL), příp. taxonomii.

businessService: Informace o konkrétní webové službě.

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.

Obr. 6 Hlavním účelem technologie UDDI je prostřednictvím webového rozhraní nebo API rozhraní na bázi protokolu SOAP umožnit: publikování služeb – obchodní společnosti mohou využít veřejných adresářů ke svému zviditelnění a dát tak vědět, jaké elektronické služby jsou schopné svým potenciálním zákazníkům nabídnout (např. SOAP rozhraní pro elektronické objednávky zboží). Druhou

5


možností je vybudování UDDI registru pro koordinaci komunikace jednotlivých oddělení v rámci jedné organizace, vyhledávání služeb – registr UDDI nabízí několik standardizovaných vyhledávacích schémat. Uživatel může podle nich necíleně vyhledávat služby z určité oblasti nebo cíleně zjistit bližší technické informace o konkrétní službě (např. získat WSDL dokument).

Pro získání lepší představy o tom, jak technologie UDDI funguje doporučuji navštívit a prozkoumat některý z veřejných UDDI registů (UBR), které jsou aktuálně v provozu. Vzhledem k pravidelně probíhajícím synchronizacím dat by měl být obsah jednotlivých registrů totožný, nicméně přehlednost webového rozhraní a práce s daty se u jednotlivých poskytovatelů značně liší. Přehled současných UBR: Microsoft (http://uddi.microsoft.com) IBM (https://uddi.ibm.com/ubr/registry.html) SAP (http://uddi.sap.com/) NTT Communicatons (http://www.ntt.com/uddi/) Současný stav UDDI Když bylo UDDI poprvé spuštěno, všechna iniciativa byla zaměřena na koncepci centralizované databáze veřejných UDDI adresářů. Když si však člověk prochází tyto adresáře dnes, čtyři roky po jejich spuštění, zjišťuje, že obsahují poměrně skromnou populaci registrovaných služeb. Veřejné UDDI registry bylo první místo, kde jsem čerpal informace o webových službách a můj první pocit byl, že se zřejmě technologie webových služeb trochu minula účinkem. Pravda je pravděpodobně někde jinde. Vzhledem ke složitosti a „technické“ povaze webových služeb bylo milnou představou se domnívat, že budou (aspoň zpočátku) určeny pro širokou veřejnost, která v pojmech HTTP, SOAP, WSDL apod. vidí jen prázdné zkratky. Webové služby však mají obrovský význam v komunikaci mezi spolupracujícími organizacemi, podniky a jejich odděleními. Toho si je vědoma specifikace UDDI 3 a proto více vsází na privátní nebo semi-privátní UDDI registry a jejich vzájemnou kooperaci. Je však nanejvýš pravděpodobné, že do budoucna se tato situace změní. Především díky technologiím webových služeb – zejména právě onomu strojově zpracovatelnému WSDL a API rozhraní veřejných UDDI registrů bude možné integrovat vyhledávání a schopnost automatického volání webových služeb do laicky zvládnutelného HTML editoru. Uživatel pak bude moci i bez sebemenšího tušení o existenci protokolu SOAP umístit do své stránky službu, zobrazující aktuální teplotu nebo informaci o tom, kdo má dnes svátek.

4

Jak to celé funguje v praxi?

Proces typické integrace webové služby popisuje obr. 7. Prvotní nalezení spotřebitele a poskytovatele 1. Poskytovatel nabízející službu jí publikuje prostřednictvím technické specifikace (nejlépe WSLD dokumentu) v adresáři služeb – typicky UDDI. 2. Potenciální spotřebitel služby se musí o její existenci dozvědět. Jedna z cest je využití registru UDDI. Požadavky spotřebitele na službu lze formulovat v kritériích pro vyhledávání. Využití UDDI není samozřejmě povinné.

6


Obr. 7 3. Výsledkem je přímo technická specifikace veřejného rozhraní služby nebo odkaz na specifikaci (v případě UDDI je to tzv. tModel). V případě komplexních SOAP aplikací se zpravidla jedná o WSDL dokument, v ostatních případech se může jednat např. o pouhý slovní popis. Získání WSDL dokumentu rovněž není závislé na UDDI – výměna může být realizována e-mailem, na disketě, apod. Shoda spotřebitele a poskytovatele na výsledné podobě služby 4. Pokud to situace vyžaduje (jedná se o specifickou službu), musí se zúčastněné strany dohodnout na sémantice konkrétních operací. Sémantika není přímo obsahem popisu veřejného rozhraní služby. 5. Případné změny mohou být provedeny v poskytované službě a samozřejmě i v aplikaci klienta. Interakce mezi klientem a poskytovatelem služby 6. Interakce se službou – výměna zpráv mezi klientskou aplikací a poskytovanou službou prostřednictvím webové služby.

5 Webové služby v knihovnictví Všechny současné knihovny samozřejmě využívají některý z komerčních knihovních informačních systémů, které trh nabízí. Přirozeně byl v prvopočátcích vývoje těchto systémů kladen především důraz na služby spojené s chodem jedné konkrétní instituce, komunikace s okolním světem byla až poslední bod zájmu. Současný trend však klade důraz právě na komunikaci. Výrobci knihovních informačních systémů se sice snaží tyto požadavky zakomponovat do svých systémů, ale často je výsledkem pouze jakési „ad hoc“ řešení, limitované používáním softwaru dané firmy (např. SFX společnosti ExLibris, apod.).

7


5.1

Knihovní on-line služby jako webové služby

Knihovními on-line službami rozumíme služby, které knihovna poskytuje prostřednictvím internetu. Jedná se především o služby nabízené uživateli pomocí webových stránek knihovny, nicméně to je pouze „vrchol ledovce“. Každá tato služba se ve skutečnosti skládá z řady elementárních operací a často využívá i jiných on-line služeb - např. rezervaci výpůjčky může předcházet vyhledávání, apod.. Stejně tak řada elementárních operací, jako je např. autorizace uživatele, vyhledání ISBN publikace a jiné, je pro velkou část on-line služeb společná. A právě tyto operace jsou vhodnými adepty na implementaci pomocí webových služeb. Tento přístup nám dává zajímavé možnosti budovat nové on-line služby na základech již fungujících služeb nebo je různými kombinacemi spojovat do rozsáhlejších celků. V řeči servisně orientované architektury se tento proces nazývá „orchestrace“. 5.2

Studie knihovního IS realizovaného v souladu se SOA

Značná část knihovních on-line služeb je integrovanou součástí komerčních knihovních informačních systémů. Tyto služby jsou sice určeny především čtenářům (jsou nabízeny prostřednictvím webu knihovny), ale je mezi nimi nezanedbatelná skupina služeb, které by mohly být téměř ve stávající koncepci nabídnuty jiným knihovnám nebo organizacím. Kooperující knihovny by mohly mít např. zpřístupněné své katalogy pro vyhledávání, objednávání či rezervaci výpůjček nebo zadávání služeb DDS a MVS. Tato komunikace by se samozřejmě odehrávala zejména na úrovni informačních systémů – např. právě prostřednictvím webových služeb.

Obr.8 8


Studie vychází z faktu, že většina on-line operací je volána z webového rozhraní. Tato webová aplikace tedy musí přirozeně komunikovat se zbytkem informačního systému knihovny (databáze, systémové aplikace, atd.). Pokud by tato vnitřní komunikace probíhala s využitím standardizovaných webových služeb, bylo by velice jednoduché tyto služby zpřístupnit i ostatním institucím (samozřejmě po splnění určitých licenčních podmínek) bez nutnosti programování dalších „ad hoc“ nástrojů. Podstatnou výhodou je rovněž využití UDDI registru, který by ve spojení s WSDL definicemi mohl značně snížit čas potřebný na řešení implementačních problémů mezi provozovatelem a potencionálním uživatelem služby. V souladu s filosofií servisně orientované architektury není nutné realizovat celý informační systém od „základů“. Jak je znázorněno na obr. 7 je možné vybudovat pouze nadstavbu (adaptér) nad současným IS, realizovaný např. jako servlet. Nové verze knihovních IS již mají většinou implementován tzv. X-server – tzn. server schopný zpracovávat/generovat standardizované XML bloky, což výrazně ulehčí implementaci rozhraní webové služby. Tuto vlastnost má například knihovní IS Aleph společnosti ExLibris. Adaptér rovněž není nutné implementovat najednou – jednotlivé webové služby lze implementovat postupně. Koexistence původního IS a nové „nadstavby“ je rovněž ilustrována na obr. 8. Knihovní web může využívat jak webové služby, tak i původní implementace informačního systému knihovny, aniž by o tom uživatel věděl. Důležitou roli v tomto návrhu hraje internetová brána (firewall), s jejíž pomocí je možno řídit přístup k jednotlivým webovým službám knihovny z internetu, např. na základě IP adresy, VPN apod., případně řídit směrování SOAP zpráv na příslušné podnikové servery. 5.3

Knihovny budoucnosti

Možnost „propagace“ některých webových služeb za brány knihovny nám dává možnost tvořit daleko komplexnější a pro čtenáře komfortnější služby, jejichž základem je právě komunikace knihoven a příp. dalších institucí, poskytujících informace. Při realizaci se lze opřít o některý standard meziknihovní komunikace např. NCIP (NISO Z39.50), který přichází s konsorciálním modelem a s tím spojeným systémem DCB (Direct Consorcial Borrowing). V kostce to znamená, že čtenář si může objednávat a půjčovat cokoliv v rámci knihoven v konsorciu (fondy jednotlivých knihoven konsorcia se uživateli jeví jako jediný fond). Výpůjčka může být uživateli doručena do jakékoliv knihovny konsorcia a vrácena stejným způsobem vrácena. NCIP formalizuje komunikaci mezi různorodými IS jednotlivých knihoven – tzn. definuje výpůjční systém konsorcia. V případě, že by se všechny tyto technologie podařilo skloubit dohromady, mohl by v „nedaleké“ budoucnosti celý knihovní systém fungovat třeba takto – demonstrativní příklad: Čtenář se chce dozvědět něco o problematice webových služeb a rozhodl se, že si zkusí půjčit tištěnou publikaci na toto téma. Mohl by tedy postupovat například takto (viz obr. 9): 1. Přihlášení ke svému kontu Čtenář se přihlásí na své konto v domovské knihovně. Přihlašovací procedura realizovaná jako webová služba automaticky ověří přihlašovací údaje v centrálním registru uživatelů a v případě kladného ověření, zašle přístupová práva a uživatelova privilegia. 2. Nalezení publikací pojednávajících o daném tématu Čtenář zvolí on-line rešeršní službu (vyhledání podle tématu obsahu) a vyplní webový formulář. Hledaná fráze se odešle prostřednictvím webové služby instituci, poskytující služby rešeršního katalogu. Po obdržení XML odpovědi se tato zpracuje a čtenáři se zobrazí bibliografické informace o publikacích týkajících se daného tématu. 9


Obr. 9 3. Nalezení publikace Čtenář si ze seznamu nalezených zvolí publikaci, která ho zaujala. Knihovna automaticky provede vyhledávání v lokálním katalogu. Nalezne-li publikaci, zajistí pomocí lokálních on line služeb (objednávka, rezervace výpůjčky) čtenáři požadovanou publikaci. Pokud knihovna tuto publikaci nevlastní, je uživateli nabídnuta možnost vyhledávání v externích katalozích (např. CASLIN, apod.). 4. Prohledání katalogů Dotaz je z knihovny odeslán na externí vyhledávací službu (např. Metalib cross-search vyhledávač). Vyhledávač odešle pomocí webové služby (např. SRW) dotazy na příslušné katalogy a počká na obdržení výsledků. Tyto pak standardní cestou přepošle žádající knihovně. Pozn.: Data do souborných katalogů mohou být získávány rovněž na základně webových služeb. Konkrétní implementací je již fungující protokol OAI-PMH. 5. Výběr konkrétního exempláře a velké finále webových služeb Domovská knihovna obdrží seznam výsledků. Pomocí standardizovaných webových služeb (závazných pro všechny členy konsorcia) kontaktuje jednotlivé knihovny s dotazem na volné exempláře. Stejnou cestou kontaktuje např. geografickou databázi knihoven na ministerstvu kultury a zjistí vzdálenost knihoven od domovské knihovny.Uživateli je „ve finále“ zobrazen seznam knihoven, které mají hledanou publikaci aktuálně k dispozici, seřazen podle vzdálenosti od domovské knihovny i s informacemi o cenách za výpůjčku (případně registraci) v jednotlivých institucích. Uživateli je přirozeně rovnou nabídnuto on-line zadaní MVS.

6

Závěr

Webové služby své místo na slunci určitě mají, i když ne v tak „veřejné“ podobě, jak bylo původně zamýšleno. V současné době je jejich hlavní uplatnění především v komunikaci mezi obchodními partnery, jednotlivými odděleními podniku nebo v rámci konsorcií, poskytující podobné služby. Doba, kdy technologie webových služeb budou přístupné i laickým uživatelům a široké veřejnosti je ještě před námi. Rostoucí význam webových služeb a servisně orientované architektury je zřejmý i ze značné podpory světových IT gigantů, jako jsou Sun, Microsoft či Oracle, apod. Všechny tyto 10


společnosti ve svých nových produktech s fenoménem webových služeb počítají. Tato řešení jsou mnohdy, zcela jistě z důvodu investice do budoucnosti, zatím zdarma k dispozici. Opomenout nesmíme rovněž celou řadu překvapivě kvalitních „open-source“ produktů. Webové služby a SOA však představují pouze technické řešení komunikace. Další důležitou součástí komunikace je samotný koncept a kooperační protokoly. Webové služby a další současné technologie nabízí mnohem více možností, než kterých je v současnosti využíváno. Pro plné využití jejich potenciálu je nutné „oproštění“ se od léta zaběhlých systémů.

Použitá literatura a WWW odkazy 1. CERAMI, E. Web Services Essentials. Sebastopol : O’Reilly & Associates, 2002. 2. BARRY, D. Web Services and Service-Oriented Architectures. San Francisco : Morgan

Kaufmann Publishers, 2003.

3. ANSPACH, K. a kol. ANSI/NISO Z39.83 Protocol. Bethesda : NISO Press, 2002. 4. ANSPACH, K. a kol. ANSI/NISO Z39.83 Protocol Implementation Profile 1. Bethesda : NISO

Press, 2002.

5. BOOTH, D. a kol. Web Services Architecture [online]. Dostupné na World Wide Web:

.

6. W3C - SOAP Version 1.2 Part 0: Primer (24. 6. 2003) [online]. Dostupné na World Wide Web:

.

7. W3C - SOAP Version 1.2 Part 1: Messaging Framework (24. 6. 2003) [online]. Dostupné na

World Wide Web:

.

8. W3C - SOAP Version 1.2 Part 2: Adjuncts (24. 6. 2003) [online]. Dostupné na World Wide Web: . 9. Service Oriented Enterprise - SOAP

http://www.serviceoriented.org/soap.html

10. WSI-I Basic Profile Version 1.0 http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html 11. W3C – WSDL Version 1.2 Part 1: Core Language http://www.w3.org/TR/2003/WD-wsdl12-20030611 12. W3C – WSDL Version 1.2 Part 3: B indings http://www.w3.org/TR/2002/WD-wsdl12-bindings-20020709 13. W3C –WSDL Version 2.0 Part 0: Primer http://www.w3.org/TR/2004/WD-wsdl20-primer-20041221 14. UDDI Technical White Paper http://uddi.org/pubs/uddi-exec-wp.pdf 15. UDDI Version 2.03 Data Structure Reference http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm 16. UDDI Spec Technical Committee Draft, Dated 20041019 http://uddi.org/pubs/uddi-v3.0.2-20041019.htm 17. Aleph Overview http://www.exlibris.co.il/aleph.htm 18. WS vyhledávače GOOGLE http://www.google.com/apis/download.html 19. Web Services for Digital Libraries http://www.elag2003.ch/pres/pres_hickey.pdf

11

Webové služby v knihovnictví

Recommend Documents