Web Services (2004)

Web services

Bc. Tomáš Šalamon duben, prosinec [email protected]

Hlavní specializace: informační technologieVedlejší specializace: peněžní ekonomie a bankovnictví

ObsahObsah...........................................................................................................................................2Úvod............................................................................................................................................4Co jsou to webové služby............................................................................................................5Architektura webových služeb.....................................................................................................7WSDL..........................................................................................................................................9

Struktura WSDL......................................................................................................................9Types....................................................................................................................................9Interface.............................................................................................................................12Operation...........................................................................................................................12Binding..............................................................................................................................12Endpoints...........................................................................................................................13Service...............................................................................................................................13Feature a Property..............................................................................................................13Documentation...................................................................................................................13

Shrnutí....................................................................................................................................14SOAP.........................................................................................................................................15

Základní východiska..............................................................................................................15Princip užití SOAPu..............................................................................................................15Směrování zpráv....................................................................................................................20Přenosové protokoly..............................................................................................................20Verze SOAPu.........................................................................................................................21

UDDI.........................................................................................................................................23Základní východiska..............................................................................................................23Datové struktury UDDI.........................................................................................................23Použití UDDI.........................................................................................................................24Získávání dat z UDDI............................................................................................................25Verze UDDI...........................................................................................................................26

Ostatní iniciativy v rámci web services.....................................................................................28Fast Web Services..................................................................................................................28WS-Addressing......................................................................................................................28Web Service Choreography Interface....................................................................................29WSIF......................................................................................................................................29WS-MessageDelivery............................................................................................................29WS-Policy..............................................................................................................................30WS-Security...........................................................................................................................30Web Services User Interface..................................................................................................30

Postup použití webových služeb................................................................................................31Nástroje pro implementaci webových služeb............................................................................32

Aplikační server.....................................................................................................................32Srovnání a výběr aplikačního serveru................................................................................32

Ostatní software.....................................................................................................................33Vývojové nástroje..................................................................................................................33Opensourcové projekty týkající se webových služeb............................................................37

Implementace SOAPu.......................................................................................................37Pluginy do Eclipse.............................................................................................................38Implementace UDDI..........................................................................................................39Ostatní................................................................................................................................40

Uživatel webových služeb.....................................................................................................40Případové studie – provozovaná řešení.....................................................................................41

InfoMapServices....................................................................................................................41Amazon.com..........................................................................................................................41

Závěr..........................................................................................................................................43

2/47

Základní pojmy..........................................................................................................................44Seznam použitých informačních zdrojů....................................................................................46

3/47

ÚvodWebové služby jsou v poslední době v odborných textech skloňovány ve všech pádech.

Diskutuje se, jestli tento nový fenomén je pouze aktuálním módním hitem a časem zapadne (jako v minulosti např. WAP) nebo zda má šanci uspět a rozšířit se jako nepostradatelná technologie.

Cílem této práce je:

1) zjistit, co si pod pojmem webové služby představit2) zmapovat standardy, na kterých webové služby stojí3) popsat jaké prostředky jsou pro vývoj a implementaci webových služeb třeba a jaké náklady

jejich pořízení představuje

Jakýmsi celkovým cílem této práce by měla být odpověď na otázku, jaké místo na internetu webové služby vlastně zaujaly, zda jde pouze o dočasnou záležitost nebo jestli je to opravdu „nová dimenze internetu“, která posune pomyslnou laťku technického vývoje společnosti o další kousek dál nebo přinejmenším technologie, která firmám umožní uskutečňovat reálné úspory nebo vytvářet výnosy, kterých by jinak nedosáhly, zkrátka jestli webové služby dokáží přinést skutečnou konkurenční výhodu a ekonomický užitek.

Z výše uvedeného plyne, že rozsah problémů, kterými se tato práce zabývá, je poměrně široký. Při řešení budu postupovat tak, že nejprve shromáždím co největší množství materiálů o standardech, na kterých webové služby stojí, a vytěžím z nich skutečnosti podstatné z hlediska dalšího řešení. Pro lepší proniknutí do podstaty se pokusím provést jednoduchou implementaci webové služby v programovacím nástroji Sun Java System Application Server a zjistit tak problémy, se kterými se vývojář může reálně setkat. Zároveň se pokusím otestovat fungování online nástrojů s webovými službami (a zejména s registrem UDDI) souvisejících. Dále bude třeba zjistit, jakých softwarových nástrojů je třeba pro implementaci této technologie použít a jak jsou dostupné a konečně se budu zabývat zjišťováním, zda a s jakým úspěchem jsou webové služby komerčně využívány.

Jako informační zdroje k této práci jsem použil především internetové vyhledávače, dále jsem čerpal z odborných článků vyhledaných systémem Proquest 5000 a z dokumentace vývojových nástrojů Sun Java System Application Server, Systinet Developer a Microsoft Visual Studio.NET 2003.

4/47

Co jsou to webové službyDonedávna byly webové stránky určeny především lidským uživatelům. Struktura jazyka

HTML, stejně jako celá koncepce webu (který byl koneckonců původně navržen jako prostředek pro sdílení vědeckých dokumentů) předpokládala, že prezentovaná data bude prohlížet člověk a HTML tak bylo zprvu chápáno především jako jednoduchý jazyk pro vhodné naformátování textu. Automatizované zpracování webových stránek bylo (a dodnes vlastně je) omezeno na prohledávání a indexování jednotlivých dokumentů roboty (nebo též „pavouky“) za účelem jejich následného prohledávání pomocí vyhledávacích služeb (Altavista, později Google, atd…). Časem vykrystalizovala nutnost oddělit data přenášená na internetu od jejich grafického zobrazení, což vedlo k úpravám původní koncepce HTML a později ke zrodu XML jakožto univerzálního jazyka pro předávání strukturovaných dat. To se později stalo východiskem pro vznik fenoménu webových služeb.

Druhým východiskem pro webové služby byl vzestup použití komponentových technologií, jako DCOM, J2EE, atd., které umožnily vytvářet znovupoužitelné části programového kódu s „ukrytou“ vnitřní strukturou a s jasně definovaným rozhraním, pomocí kterého je bylo možno implantovat do různých aplikací, aniž by vývojář musel znát „vnitřek“ příslušné komponenty. Takové komponenty potom pomocí příslušných komunikačních technologií (např. CORBA) umožnily širší distribuci kódu a spolupráci různých komponent běžících na různých počítačích s různými operačními systémy.

Webové služby vznikly jako logický důsledek těchto dvou jevů. Jde o technologii, která umožňuje prostřednictvím běžných jednoduchých internetových technologií jako je protokol HTTP a formát XML zajistit komunikaci a interoperabilitu komponent umístěných na internetu bez ohledu na platformu, na které běží a programovací jazyk, v němž byly vytvořeny. Umožňují strukturovanou formu komunikace, provádění transakcí a standardizovaný způsob jejich vyhledávání a popis jejich rozhraní.

Výhodou webových služeb oproti proprietálním technologiím (jako např. výše zmíněné DCOM) je hned několik skutečností (1,2):

Veškerá komunikace se provádí prostřednictvím zpráv ve formátu XML v textové podobě na rozdíl od binárních zpráv, které používá ORPC nebo JRMP a které je třeba při přechodu z jedné platformy na jinou konvertovat. Zároveň to samozřejmě výrazně usnadňuje ladění takových aplikací.

Přenos dat pomocí HTTP a XML podstatně usnadňuje správu takového systému, neboť komunikace se děje prostřednictvím standardního portu 80 (HTTP) a nebývají tedy problémy s firewally.

Technologie webservices nepatří žádné konkrétní firmě, ale je rozvíjena a podporována konsorciem velkých informatických společností jako je Microsoft nebo IBM a je to standard otevřený. Každý jej tedy může využívat zdarma.

Implementace je poměrně levná, stačí i obyčejný prohlížeč na straně klienta a např. volně šiřitelný software na straně serveru.

Webové stránky nebo aplikace mohou využívat webových služeb k rozšíření své funkcionality a integrovat je do sebe.

Ukažme si, jak vlastně práce s webovou službou probíhá. Dejme tomu, že na internetu existuje webová služba, která zajišťuje překlad textu z angličtiny do francouzštiny (taková komponentu vskutku existuje, ale to není důležité). Na našich webových stránkách chceme vytvořit aplikaci, která bude překládat texty do různých jazyků – nemusíme vlastnit nebo vytvářet příslušné překladače, pokud na internetu nalezneme webové služby, které příslušnou funkcionalitu zajistí a ty pouze integrujeme do našeho webu. Dejme tomu, tedy, že uživatel bude chtít přeložit text z angličtiny do francouzštiny. Celá akce je znázorněna na obr 1.

5/47

Uživatel nejprve zadá text v angličtině, webová stránka jej předá prostřednictvím protokolu SOAP webové službě, webová služba provede překlad do francouzštiny a pomocí protokolu SOAP vrátí výsledek zpět serveru, na kterém běží naše webové stránky, které výsledek pouze vhodně zobrazí. Naprosto stejným způsobem by bylo vše provedeno i v případě, že by uživatel nepracoval s aplikací v prohlížeči, ale s normální „tlustou“ aplikací na počítači.

6/47

<SOAP-ENV:Envelope xmlns:SOAP-ENV="htt xmlns:xsi="http://w xmlns:xsd="http://w

<SOAP-ENV:Body> <ns1:translateRespo <return xsi:type=

Mon nom est Tom </return> </ns1:translateResp </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Internet Explorer

www.preklad,cz

Výsledek překladu:

Mon nom est Tom.

<SOAP-ENV:Envelope xmlns:SOAP-ENV="htt xmlns:xsi="http://w xmlns:xsd="http://w

<SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <ns1:translate <text xsi:type="

My name is Tom. </text> </ns1:translate> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Internet Explorer

www.preklad,cz

Zadejte text v angličtině:

My name is Tom.| OK

uživatel napíše text do aplikace běžící na aplikačním serveru

WSa

aplikační server zformuluje dotaz s textem k překladu v protokolu SOAP a pošle serveru s webovou službou

webová služba text přeloží a výsledek pomocí protokolu SOAP pošle zpět aplikačnímu serveru

aplikační server zobrazí uživateli výsledek na stránce

Obr 1 – způsob fungování webových služeb

Architektura webových služebZ výše uvedeného je již asi patrné, že webové služby nejsou jedna monolitická technologie

nebo jeden komplexní protokol, ale jde o celou rodinu protokolů, které vzájemně spolupracují (podobně jako např. rodina protokolů TCP/IP). Nejdůležitější z nich jsou protokoly SOAP, WSDL a UDDI. SOAP je základní komunikační protokol, pomocí kterého se vyvolávají jednotlivé funkce webových služeb, zasílají se jim parametry a získává se od nich odezva. WSDL slouží k popisu rozhraní webových služeb a UDDI je protokol a služba, pomocí které lze v internetu jednotlivé služby a jejich poskytovatele vyhledávat. Kromě těchto základních existuje ještě celá řada dalších protokolů, které v rámci fenoménu webových služeb doplňují další specifickou funkcionalitu. Např. jsou to: XLANG, XKMS, XFS, ad.

Protokol SOAP,WSDL a UDDI jsou navrženy nad protokolem XML (Obr 3) se všemi výhodami i nevýhodami z toho plynoucími; zejm. s tou výhodou, že všechny zprávy, které jsou mezi servery předávány, jsou v poměrně přehledném textovém tvaru, což výrazně snižuje nároky na ladění a odstraňuje problémy s případnou nekompatibilitou mezi platformami. Díky využití protokolu XML

7/47

SOAP

WSDL

UDDI

Obr 2 – vzájemná provázanost protokolů webových služeb

SOAP

XML

WSDL

UDDI

HTTP

Obr 3 – Architektura webových služeb

jsou protokoly SOAP, WSDL a UDDI – a tím i celá technologie webových služeb – odstíněny od konkrétní implementace a jsou tím pádem dokonale platformově nezávislé.

Protokol XML sám o sobě ale samozřejmě neumí žádná data přenášet, proto jsou dokumenty XML, které si mají servery vyměnit, vkládány do transportních protokolů. Nejčastěji jde o HTTP (port TCP: 80), tedy stejný protokol, který se používá pro přenos běžných webových stránek ve formátu HTML, a existují i aplikace využívající „poštovní“ protokol SMTP (port TCP: 25) a další. Teoreticky lze využít i celou řadu dalších protokolů, ale klíčovou roli bezpochyby hraje a i v budoucnu hrát bude především protokol HTTP, neboť (na rozdíl od proprietálních protokolů, které využívají některé komponentové technologie jako třeba protokol IIOP), nemá problém s průchodem firewally, je jednoduchý a široce rozšířený.

8/47

WSDLPokud nějakou webovou službu nalezneme a chceme využít, potřebujeme vědět, pomocí

jakého rozhraní můžeme se službou komunikovat, co přesně nabízí za funkce, jak je vyvolávat, jak a jaké argumenty jim předat a v jaké podobě očekávat odpověď. To vše řeší služba WSDL (Web Services Description Language), která popisuje rozhraní dané webové služby. Obecně řečeno, jde o šablonu, pomocí které mohou být webovské služby popsány a propojeny s klienty (5) nebo o jakýsi metaprotokol pro popis protokolů a standardů komunikace webových služeb.

Konkrétně to znamená, že pro každou službu existuje tzv. WSDL soubor (na webu, případně lokálním disku), ke kterému je třeba při začleňování služby do vlastní aplikace přistoupit a zjistit, jaké má služba funkce, jaké parametry tyto funkce vyžadují, jak je jimi předávána návratová hodnota, atd.

Základní vlastností WSDL je abstrakce a rozdělení popisu komunikace do jednotlivých složek. Ty tak nejsou na sobě závislé a je možno např. upravovat vzor podoby zasílaných zpráv nezávisle na tom, jak má vypadat jejich pořadí, argumenty nebo na jakém serveru je služba konkrétně provozována. WSDL je ve verzi 2.0 založen na tzv. komponentovém modelu – všechny jeho složky jsou samostatné komponenty se vzájemnými vazbami.

WSDL vzniklo na základě protokolů SOAP a NASSL od IBM. V současné době se každý autor píšící o WSDL musí vypořádat s problémem, že aktuální široce podporovaná verze tohoto protokolu je stále ještě verze 1.1 z roku 2001, která navíc existuje pouze jako NOTE, tedy nikoliv oficiální standard (24). Chystá se nová verze 2.0 (25), která má přinést mnohé změny, avšak dosud existuje pouze ve fázi „Last Call Working Draft“ (pracovní návrh), což znamená, že ještě uplyne nějaký čas než dospěje do fáze „Candidate Recommendation“ a další čas – s největší pravděpodobností ještě mnoho měsíců – než bude přijat jako plnohodnotný standard ve fázi „Recommendation“. Budu tedy popisovat verzi 2.0 s tím, že upozorním na případné rozdíly oproti verzi 1.1. Verzí 2.0, nebude-li uvedeno jinak, budu mít na mysli tento výše uvedený pracovní návrh.

Struktura WSDLWSDL je samozřejmě definováno příslušným XML schématem, konkrétně je to ve verzi 2.0

http://www.w3.org/2004/08/wsdl (v následujícím textu budu pro tento jmenný prostor používat prefix wsdl).

Celý obsah WSDL dokumentu je uzavřen do elementu wsdl:definitions. V rámci tohoto elementu se definují jednotlivé prvky komunikace.

TypesZákladní jednotkou komunikace jsou tzv. zprávy, které si lze představit jako vzdálené metody,

které mohou být volány. Aby s nimi bylo možno pracovat, musí být nadefinovány jejich názvy a pořadí a typy jejich argumentů. V WSDL 2.0 se to děje pomocí syntaxe XML schémat. Každá metoda je definována jako XML element nejvyšší úrovně (global element declarator). Struktura jejích argumentů je typ definovaný například jako ComplexType.

V rámci elementu wsdl:types lze připojit příslušný XSD soubor s definovanými metodami pomocí elementu import nebo je lze podle stejné syntaxe přímo definovat (vložit do elementu wsdl:types). Je třeba dbát na to, že takto definované elementy musí být z jiného jmenného prostoru, než zbytek WSDL dokumentu a tak není možno místo import použít element include (který předpokládá stejný jmenný prostor).

Co se týče jednoduchých typů, WSDL 2.0 samo o sobě obsahuje specifikaci několika základních typů ve jmenném prostoru http://www.w3.org/2004/08/wsdl-simple-types.

Lépe než tento teoretický popis bude předvést konkrétní fungování na následujícím příkladu, kde je definován element reserveFlight, který představuje vzdálenou metodu se dvěma argumenty, které jsou definovány ve struktuře tReserveFlight. Odpovídající deklarace této metody např. v Javě by vypadala zhruba následovně:

void reserveFlight(Date departureDate, String airport)

9/47

http://www.w3.org/2004/08/wsdl-simple-types

http://www.w3.org/2004/08/wsdl

Stejným způsobem se definují i faults – chybové stavy, které lze zhruba přirovnat k výjimkám ve vyšších jazycích.

Předchozí verze 1.1 měla pro práci s argumenty metod ještě zvláštní element message, ale ten byl ve verzi 2.0 opuštěn.

Základní WSDL 2.0 komponenty jsou interface, binding a service. Datové struktury WSDL si předvedeme na následujícím příkladu WSDL zprávy, který jsem si

vypůjčil z (25) a upravil. Definice typů je uvedena v elementu wsdl:types, který se odkazuje na XML schéma TicketAgent.xsd, u kterého předpokládáme, že obsahuje výše uvedenou definici typů reserveFlight a tReserveFlight.

10/47

<xs:element name="reserveFlight" type="tReserveFlight "/> <xs:complexType name="tReserveFlight "> <xs:sequence> <xs:element name="departureDate" type="xs:date"/> <xs:element name="airport" type="xs:string"/> </xs:sequence> </xs:complexType>

11/47

<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace="http://example.org/TicketAgent.wsdl20" xmlns:xsTicketAgent="http://example.org/TicketAgent.xsd" xmlns:wsdl="http://www.w3.org/2004/08/wsdl" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/2004/08/wsdl wsdl20.xsd"> <wsdl:types> <xs:import schemaLocation="TicketAgent.xsd" namespace="http://example.org/TicketAgent.xsd" /> </wsdl:types> <wsdl:interface name="TicketAgent">

<wsdl:fault name="invalidDataFault" element="xsTicketAgent:invalidData"/>

<wsdl:operation pattern="http://www.w3.org/2004/08/wsdl/in-out">

<wsdl:input element="xsTicketAgent:listFlights"/> <wsdl:output element="xsTicketAgent:listFlightsResponse"/>

<wsdl:outfault ref="invalidDataFault"/> </wsdl:operation> <wsdl:operation

pattern="http://www.w3.org/2004/08/wsdl/in-out"> <wsdl:input element="xsTicketAgent:reserveFlight"/> <wsdl:output element="xsTicketAgent:reserveFlightResponse"/> </wsdl:operation> </wsdl:interface>

<wsdl:binding name="TicketAgentSOAPBinding" interface="xsTicketAgent:TicketAgent"

type="http://www.w3.org/2004/08/wsdl/soap12" wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"

<wsdl:fault ref="xsTicketAgent:invalidDataFault" wsoap:code="soap:Sender"/>

</wsdl:binding>

<wsdl:service name="TicketAgentService" interface="xsTicketAgent:TicketAgent">

<wsdl:endpoint name="TicketAgentEndpoint" binding="xsTicketAgent:TicketAgentSOAPBinding" address="http://example.org/TicketAgent"/> </wsdl:service>

</wsdl:definitions>

InterfaceElement wsdl:interface nahradil element portType, který se vyskytoval ve verzi 1.1. Ve

verzi 2.0 jsou ale jeho možnosti rozšířeny. Podle (25) „popisuje interface posloupnosti zpráv, které služba přijímá a vysílá. To je zajištěno spojováním souvisejících zpráv do operací (operations). Operace je sada vstupních a výstupních zpráv a interface je sada operací. Tímto způsobem interface definuje podobu aplikace“.

Interface, stejně jako řada dalších elementů obsahuje atribut extends který umožňuje vyjmenovat jiné interfacy, jejichž sadu operací námi definovaný interface rozšiřuje. Nově definovaný interface potom obsahuje nejen svoje vlastní operace, ale i operace všech elementů, které rozšířil. Do jisté míry to poněkud připomíná dědičnost z objektově orientovaného programování a ve verzi 2.0 je to proti verzi předchozí novinka. Kromě dalších může element interface obsahovat podelementy operation a fault.

OperationOperaci si lze představit jako sjednaný vzor komunikace v tom kterém případě: definuje

pořadí a kardinalitu zasílání jednotlivých zpráv při komunikační seanci. Pokud je například třeba, aby při rezervaci lístků došlo nejprve ke vstupnímu požadavku od uživatele, potom je ze serveru odeslána zpracovaná nabídka a nakonec je třeba, aby ji uživatel potvrdil, bude taková operace teoreticky sestávat ze složek input-output-input. Podobu takového komunikačního vzoru lze v elementu operation vymezit pomocí atributu pattern, který obsahuje URI určující vzor komunikace. WSDL 2.0 definuje 8 vzorů, které mají abstraktní povahu.

Podelementy elementu wsdl:operation mohou být wsdl:input, wsdl:output, wsdl:infault a wsdl:outfault.

Elementy input a output jsou tzv. řádné a slouží k přiřazení konkrétních zpráv (které jsou definovány zvlášť, jak bude popsáno dále) určité pozici v komunikačním vzoru. Nejdůležitějším atributem těchto elementů je element, kterému se přiřazuje kvalifikované jméno příslušné zprávy. Tu si lze představit například jako název vzdálené metody, která má být volána. Např. ve výše uvedeném příkladu WSDL dokumentu je v první operaci jako vstupní definována metoda (zpráva) xsTicketAgent:listFlights na kterou server odpoví zprávou xsTicketAgent:listFlightsResponse. Další parametry komunikace, jako např. které argumenty tyto metody obsahují, jsou definovány jinde.

Kromě řádných elementů mohou být v rámci operace použity i elementy chybové: infault a outfault, které by měly být předávány v případě vzniku chyb – lze je tedy přirovnat ke generování výjimek ve vyšších programovacích jazycích. Jejich definice je analogická s definicí input a output s tím rozdílem, že se neodkazují přímo na jinde definovaný element, ale pomocí atributu ref se odkazují na příslušný element fault, který je definován v rámci interface. Je tomu tak z toho důvodu, aby různé operace mohly generovat stejná chybová hlášení.

Tato oblast byla ve verzi 2.0 razantně předělána, předchozí verze např. nerozlišuje vstupní a výstupní chybu, implicitně podporuje pouze 4 komunikační vzory a postrádá řadu elementů a atributů.

BindingDalším problémem, který musí být řešen, je vazba abstraktně definovaných metod a datových

struktur na konkrétní přenosový protokol (27). WSDL podporuje teoreticky jakýkoliv protokol nižší úrovně, standardně je definována vazba na SOAP verze 1.2 a HTTP.

Binding definuje, jak budou abstraktní definice metod transformovány do podoby konkrétního komunikačního protokolu. Pokud např. zvolíme protokol HTTP, určuje binding, zda budou data přenášena v rámci metody GET či jako součást zprávy POST a jak konkrétně budou vypadat. Vazby na protokol lze vytvořit na více úrovních – jak vazbu jednotlivých interfaců, tak operací, faultů, atd. Platí však pravidlo, že pro jednu datovou entitu (ať už interface, operaci, atd.) nelze vytvořit více vazeb.

Jak konkrétně vytvoření vazby vypadá: použije se element wsdl:binding, který v sobě uzavírá shodnou strukturu, jako element wsdl:interface. Odkaz na konkrétní vazbu je určen

12/47

atributem type elementu binding, který nabývá URI příslušného schématu (pro SOAP 1.2 je to http://www.w3.org/2004/08/wsdl/soap12, pro HTTP http://www.w3.org/2004/08/wsdl/http, atd.). Všechny podelementy jsou poté vázány na daný protokol nebo mohou být vazby jednotlivých elementů řešeny individuálně. Existuje i jednodušší možnost zápisu vazby celého interface, kdy stačí do atributu wsdl:interface elementu wsdl:binding přiřadit příslušné kvalifikované jméno daného interface a pak už není třeba v rámci elementu wsdl:binding řešit podobu vnitřní struktury daného interface.

V příkladu, který je uveden výše, je ukázána vazba celého definovaného rozhraní TicketAgent na protokol SOAP 1.2 (pomocí atributu wsoap:protocol je nabíc určeno, že podkladovým protokolem SOAPu bude HTTP). Zvlášť je ještě na SOAP navázána chyba invalidDataFault s tím, že je určeno, že tato chyba bude generovat SOAPovskou chybu Sender.

EndpointsPoslední co zbývá pro jednoznačné určení webové služby nadefinovat jsou tzv. endpoints,

koncové body komunikace, tozn. zjednodušeně řečeno adresy URI serverů, na kterých služba běží. Ve WSDL 1.1 se tato entita nazývala ports.

Endpoint je nějak pojmenován a je u něj určeno, k jaké vazbě (binding) náleží. Tak lze vytvářet různé endpoints pro různé vazby a ty zase mohou zahrnovat různé interfacy a operace. Díky tomu může být ve WSDL popsána i služba, jejíž implementace je distribuována na více serverech.

Atributy elementu wsdl:endpoint jsou poměrně zřejmé, kromě name nesoucího vnitřní kvalifikované jméno této entity jsou to binding určující, ke které vazbě endpoint patří a address, kde je URI serveru, na kterém je daná služba k dispozici (viz. výše uvedený příklad).

ServiceService (služba) je skupina endpointů. To znamená, že jakýkoliv endpoint v rámci daného

service musí být schopen poskytovat stejnou službu a uživatel si tedy mezi nimi může libovolně vybrat. Jednotlivé endpointy dané služby nemohou komunikovat mezi sebou.

Service musí obsahovat jeden nebo více endpointů. Service obsahuje jeden povinný atribut interface, který určuje interface, který je danou službou zastoupen.

Feature a PropertyFeature a Property jsou další významné elementy, které se objevují nově ve WSDL 2.0.

Mohou se vyskytovat v rámci interfaců, operací, faultů, ale i v rámci vazeb, služeb a endpointů, zkrátka v rámci většiny ostatních entit, které jsou ve WSDL definovány.

Feature je abstraktní vlastnost (příznak) dané entity, do které je wsdl:feature vložen. Neexistuje žádné omezení, vlastnost lze pojmout jakkoliv, např. „zabezpečené“, „nepovinné“, atd. Vlastnost je pojmenována skrze URI a kromě toho existuje ještě atribut required, který stanovuje, zda jde o feature, které je povinné či nikoliv. Tuto vlastnost lze použít například k tomu, aby bylo možno identifikovat, se kterými funkcemi je možno komunikovat zabezpečeně nebo které jsou např. zatím pouze v testovací, nikoliv produkční verzi, apod.

Property je element, díky kterému mohou být jednotlivým entitám přiřazovány určité hodnoty, které lze vzdáleně přirovnat k proměnným prostředí. Tak lze např. určité vazbě přiřadit timeout nebo počet opakování spojení při jeho rozpadu nebo ovlivnit chování určité vzdálené metody. Atributy jsou stejné jako u elementu wsdl:feature, kromě toho ale může property obsahovat ještě podelementy wsdl:value (vlastní hodnota daného elementu) a wsdl:constraint (omezení hodnot, např. určením typu).

DocumentationElement wsdl:documentation slouží pro vytváření komentářů. Může být vložen do

různých úrovní XML struktury a obsahovat jak text, tak strukturu uživatelských podelementů. Kromě toho lze samozřejmě používat pro komentáře i běžnou XML notaci .

13/47

http://www.w3.org/2004/08/wsdl/http

http://www.w3.org/2004/08/wsdl/soap12

Shrnutí

Protokol WSDL je řádově složitější než např. protokol SOAP, protože musí postihnout daleko komplexnější souvislosti, proto nelze tento popis považovat zdaleka za vyčerpávající. Navíc je znát, že mezi verzemi 1.1 a 2.0 došlo k radikálním změnám, které jsou koneckonců vyjádřeny i změnou čísla verze a nikoliv pouze revize protokolu. V dokumentaci jsou uvedeny desítky dalších upřesňujících atributů a elementů. V nové verzi protokol např. lépe pracuje s modularizací kódu do více souborů (přibyl element include), WSDL nyní představuje ucelený konceptuální komponentový model, byl rozšířen počet komunikačních vzorů, některé elementy byly zcela přejmenovány, jiné opuštěny, atd.

WSDL ve verzi 2.0 mi nyní připadá mohutnější, vnitřně konzistentnější, ale zároveň bohužel složitější. Navíc díky značným změnám a odlišnostem se masivní implementace nové verze jistě v nejbližší době nedočkáme.

14/47

SOAP

Základní východiskaPokud už známe službu, kterou chceme použít a známe i její rozhraní, umíme naformulovat

příkazy pomocí protokolu SOAP (Simple Object Access Protocol), které službě pošleme. V našem příkladu (překlad z angličtiny do francouzštiny) šlo o triviální případ, kde jsme volali

pouze jedinou funkci („translate“) s jediným parametrem (text k překladu). Webové služby však mohou být (a bývají) dosti složité, mohou mít i desítky různých funkcí, z nichž každá může požadovat několik parametrů na vstupu. Protokol SOAP je natolik robustní, že se s jím dají všechny tyto požadavky vyjádřit.

Následující popis se týká verze SOAPu 1.2 (odlišnosti mezi verzí 1.2 a předchozí verzí 1.1 budou popsány dále).

Jak již bylo uvedeno, SOAP existuje nad protokolem XML a jeho struktura – stejně jako struktura jakéhokoliv jiného XML dokumentu – je tedy dána příslušným XML schématem. V případě aktuální verze SOAPu jsou to jmenné prostory http://www.w3.org/2003/05/soap-envelope (v následujícím textu a uvedených příkladech bude přiřazen tomuto jmennému prostoru prefix env), http://www.w3.org/2003/05/soap-encoding a http://www.w3.org/2003/05/soap-rpc (prefix rpc).

Použití SOAPu je velmi široké. V souvislosti s webovými službami se někdy uvádí pouze použití pro RPC – volání vzdálených metod. Ve skutečnosti je ale použití tohoto protokolu daleko širší, SOAP podporuje více komunikačních vzorů počínaje jednoduchým odesláním SOAP zprávy a přijetím odpovědi, přes „konverzaci“, kdy je vyměněno několik zpráv v obou směrech až po uvedené vzdálené volání, kdy SOAP zpráva vyvolá metodu na vzdáleném serveru s příslušnými parametry a nazpět obdrží návratovou hodnotu, výstupní parametry (do jisté míry něco na způsob předávání parametrů metodě odkazem ve vyšších programovacích jazycích) případně chybovou zprávu – výjimku.

Princip užití SOAPuKaždá zpráva v SOAPu obsahuje hlavní povinný element env:Envelope, ve kterém je celá

zpráva uzavřena. Dále následuje nepovinný, ale doporučený env:Header, který vymezuje hlavičku a nese metadata související s komunikací, která ale nejsou přímo předmětem komunikace. Mohou zde být například přihlašovací údaje, číslo transakce, časové razítko či směrovací cesta SOAP zprávy, pokud ta prochází přes více tzv. SOAP intermediaries – zprostředkovatelů, tedy serverů, které SOAP zprávy ve změněné či nezměněné formě předávají dál.

Takovéto zprostředkující servery mohou upravovat obsah hlavičky, ale neměly by sahat do těla zprávy vymezené povinným elementem env:Body, které je určeno konečnému příjemci.

Element env:Body obsahuje další úrovně členění elementů, které již nejsou definovány v rámci protokolu SOAP, ale vlastními komunikujícími stranami za použití jejich vlastních schémat. Lze zde rozlišovat různé komunikační vzory.

Výměna zpráv – dva servery si v rámci jedné seance vyměňují zprávy. Nejde zde tedy o vyvolávání metod na vzdáleném serveru, ale o strukturovanou konverzaci mezi dvěma body v síti.

Ukázka komunikace. Předpokládejme, že probíhá komunikace mezi klientem uživatele a serverem při objednávání letenek. Nějaká výměna dat již proběhla a nyní z jednoho uzlu v síti přichází dotaz na upřesnění požadavku na letiště startu a přistání. Podoba dotazu:

15/47

http://www.w3.org/2003/05/soap-rpc

http://www.w3.org/2003/05/soap-encoding

http://www.w3.org/2003/05/soap-envelope

V hlavičce jsou data pro udržení konzistence komunikace. Je zde datová struktura m:reservation – ta není definována protokolem SOAP, ale je definována uživatelským schématem http://travelcompany.example.org/reservation. Je v ní identifikátor m:reference, který obsahuje identifikaci seance, aby mohla být zpráva korektně přiřazena a časové razítko (mohou zde být samozřejmě další data, která jsou pro komunikaci potřebná). Za zmínku stojí ještě atribut env:role, který určuje, kdo a zda vůbec musí zpracovávat datové struktury v hlavičce. Odvolání na schéma role/next znamená, že tak musí učinit další zprostředkovatel, který SOAP zprávu předává vč. konečného příjemce a hodnota atributu env:mustUnderstand="true" značí, že hlavička musí být zpracována (tedy vyhodnocena, případně musí být vrácena chyba).

V env:Body je obsažena datová struktura p:itineraryClarification, která již není součástí protokolu SOAP, ale je definována ve schématu http://travelcompany.example.org/reservation/travel. Jejím účelem je přenášet data o nástupních a cílových letištích.

Jako odpověď na tento upřesňující dotaz je serveru odeslána následující zpráva:

16/47

<!— obálka SOAP --><?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <!— hlavička s řídícími a meta daty --> <env:Header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference> <m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime> </m:reservation></env:Header><!— tělo s vlastními přenášenými daty --> <env:Body> <p:itineraryClarification xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing> <p:airportChoices> JFK LGA EWR </p:airportChoices> </p:departing> </p:departure> <p:return> <p:arriving> <p:airportChoices> JFK LGA EWR </p:airportChoices> </p:arriving> </p:return> </p:itineraryClarification> </env:Body></env:Envelope>

http://travelcompany.example.org/reservation/travel

http://travelcompany.example.org/reservation

Remote procedure calls – vzdálené volání procedur. Jedna strana je klientem – iniciátorem a vyvolává na vzdáleném serveru metodu s danými parametry a očekává návratovou hodnotu či další výstupní data.

Pokud voláme vzdálené metody, potřebujeme znát přinejmenším server, na kterém jsou k dispozici, jejich název, vstupní a výstupní parametry. Kromě toho lze samozřejmě další data včlenit do hlavičky, ad.

Účel a podoba hlavičky SOAP zprávy je stejná jako v předchozím případě. Tělo zprávy je rovněž na první pohled stejné, ale struktury v něm obsažené jsou názvy vzdáleně volaných metod a jejich dceřiné elementy jsou potom jednotlivými vstupními parametry. Příklad volání:

17/47

<!— obálka SOAP --><?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <!— hlavička s řídícími a meta daty --><env:Header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference> <m:dateAndTime>2001-11-29T13:36:50.000-05:00</m:dateAndTime> </m:reservation> </env:Header><!— tělo s vlastními přenášenými daty --> <env:Body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>LGA</p:departing> </p:departure> <p:return> <p:arriving>EWR</p:arriving> </p:return> </p:itinerary> </env:Body></env:Envelope>

<!— obálka SOAP --><?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <!— hlavička s řídícími a meta daty --><env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true" >5</t:transaction></env:Header><!— tělo s voláním vzdálené metody --> <env:Body> <m:chargeReservation env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://travelcompany.example.org/"> <o:creditCard xmlns:o="http://mycompany.example.com/financial"> <o:number>123456789099999</o:number> <o:expiration>2005-02</o:expiration> </o:creditCard> </m:chargeReservation> </env:Body></env:Envelope>

V příkladu byla volána vzdálená metoda m:chargeReservation, která má jeden strukturovaný vstupní parametr, který obsahuje dva primitivní atributy o:number a o:expiration. Struktura parametrů volané metody, stejně jako parametrů samotných je definována vlastními schématy. Takové řešení umožňuje velkou robustnost a otevřenost standardu.

Jak vypadá odpověď serveru? Ten vrátí zprávu v protokolu SOAP, která obsahuje název metody, která byla volána doplněný slovem Response a příslušné výstupní parametry (a případně návratovou hodnotu). Struktura výstupních parametrů je samozřejmě definována příslušným schématem a nikoliv samotným protokolem SOAP.

Příklad odpovědi serveru:

Odpověď na volání vzdálené metody je uzavřena v elementu m:chargeReservationResponse a obsahuje výstupní parametry m:code a m:viewAt. Výstupní parametry lze, jak již bylo řečeno, přirovnat k parametrům předávaným referencí ovšem s tím rozdílem, že vzdálená metoda volaná prostřednictvím SOAPu může vracet i takové parametry, které nebyly původně na vstupu – struktura je opět definována příslušným schématem.

Za povšimnutí stojí element rpc:result, který obsahuje kvalifikované jméno jiného elementu, který je mezi výstupními parametry, v tomto případě m:status. Takovýto element již není považován za výstupní parametr, ale za návratovou hodnotu příslušné metody. Vložení do daného elementu umožňuje určení typu takového parametru. Element rpc:result je nepovinný. Pokud není definován, chápe se, že metoda návratovou hodnotu nevrací (což např. v C++ odpovídá návratové hodnotě typu void).

Princip předávání chyb je posledním důležitým komunikačním mechanismem. Je to podle mého názoru nejkonkrétněji standardizovaná oblast SOAPu, jejíž struktura je na rozdíl od výše uvedených poměrně přesně definována a daleko menší prostor je ponechán na kreativitě uživatelů vyjádřené vlastními schématy.

Pokud SOAP zpráva nese chybové hlášení, je v elementu env:Body obsažen element env:Fault. Tento element obsahuje následující podelementy:

18/47

<!— obálka SOAP --><?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <!— hlavička s řídícími a meta daty --><env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true" >5</t:transaction></env:Header><!— tělo s daty vrácenými od volané procedury --> <env:Body> <m:chargeReservationResponse env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:rpc="http://www.w3.org/2003/05/soap-rpc" xmlns:m="http://travelcompany.example.org/"> <rpc:result>m:status</rpc:result> <m:status>confirmed</m:status> <m:code>FT35ZBQ</m:code> <m:viewAt> http://travelcompany.example.org/reservations?code=FT35ZBQ </m:viewAt> </m:chargeReservationResponse> </env:Body></env:Envelope>

env:Code (povinný) env.Reason (povinný) env:Detail (nepovinný) env:Node (nepovinný) env:Role (nepovinný)

První povinný element env:Code nese kód příslušné chyby. Obsahuje povinný element env:Value s chybovým kódem z pětimístného seznamu, který definuje SOAP (env: VersionMismatch, env: MustUnderstand, env: DataEncodingUnknown, env: Sender, env: Receiver). Vzhledem k tomu, že tato paleta chybových kódů je poměrně chudá a příslušné kódy jsou protokolově specifické, lze v rámci env:Code použít ještě i nepovinný element env:SubCode, který opět obsahuje env:Value s chybovým kódem, který je ale tentokrát aplikačně specifický a uživatelsky definovaný.

Dalším povinným elementem je env.Reason s textovým chybovým hlášením. Text konkrétní hlášky je uzavřen v elementu env.Text. Těchto subelementů může být v elementu env.Reason obsaženo i více pro různé jazyky. Ty jsou poté odlišeny atributem xml:lang.

Další elementy jsou již nepovinné. Element env:Detail může nést konkrétnější chybovou informaci definovanou aplikací, v env:Node může být obsaženo URI SOAPovského uzlu, kde k chybě došlo a v env:Role obsahuje roli, což je vlastně požadavek chování příslušného SOAPovského zprostředkovatele.

Pokud k chybě dojde v hlavičce SOAPovské zprávy, generuje se chyba env:NotUnderstood a zpráva má poněkud specifickou podobu. Tento element (env:NotUnderstood) se objeví i v hlavičce s vlastností qname, které bude přiřazeno kvalifikované jméno chybného elementu.

Příklad chybové zprávy:

Příklady k protokolu SOAP byly převzaty z (20) a upraveny.

19/47

<!— obálka SOAP --><?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:rpc='http://www.w3.org/2003/05/soap-rpc'> <!— tělo s chybovým hlášením --> <env:Body> <env:Fault> <env:Code> <env:Value>env:Sender</env:Value> <env:Subcode> <env:Value>rpc:BadArguments</env:Value> </env:Subcode> </env:Code> <env:Reason> <env:Text xml:lang="en-US">Processing error</env:Text> <env:Text xml:lang="cs">Chyba zpracování</env:Text> </env:Reason> <env:Detail> <e:myFaultDetails xmlns:e="http://travelcompany.example.org/faults"> <e:message>Name does not match card number</e:message> <e:errorcode>999</e:errorcode> </e:myFaultDetails> </env:Detail> </env:Fault> </env:Body></env:Envelope>

Směrování zprávDalší důležitou schopností SOAPu je směrování zpráv. Už jsem se o něm zmínil v souvislosti

s hlavičkou zprávy. Na tomto místě samozřejmě nemám na mysli směrování dat na nějaké nižší úrovni – směrování paketů na úrovni protokolu IP nebo třeba zprostředkování přenosu proxy serverem na protokolu HTTP. I v rámci protokolu SOAP je umožněno směrování zprávy mezi jednotlivými servery – tzv. zprostředkovateli SOAP – ale vlastní definice cesty není součástí protokolu. Očekává se, že jednotliví zprostředkovatelé si budou schopni sami poradit s tím, kam zprávu nasměrovat. To je koneckonců analogické s některými protokoly nižších vrstev. Ve zprávě je definována pouze role následujícího příjemce – a sice, jestli jde o konečného příjemce nebo zprostředkovatele či zda obsah zprávy nemá být vůbec zpracován.

Zprostředkovatelé mohou být buď pouze směrující (forwarding intermediary), kteří neprovádějí ve zprávě žádné změny (mohou např. pouze podle obsahu zprávy rozhodovat, kam bude zpráva dále směrována) a aktivní (active intermediary), kteří dělají ve zprávě změny a poté ji posílají dál. Tak či tak, zprostředkovatelé by, jak již bylo řečeno, neměli zasahovat do vlastního těla zprávy ohraničeného elementem env:Body, ale pouze do její hlavičky.

Představme si tedy například následující cestu zprávy: první ji obdrží zprostředkovatel SOAP, který nějakým způsobem, např. na základě nižší přenosové vrstvy ověří autentizaci a vloží příslušný údaj do hlavičky (aktivní zprostředkovatel). Poté zprávu předá dalšímu zprostředkovateli, který ji vyhodnotí, vybere server, který ji zpracuje a předá mu ji (směrující zprostředkovatel). Zde teprve dojde ke zpracování zprávy a odeslání odpovědi.

Přenosové protokolyPrávě tak, jak je protokol SOAP otevřený ze shora a je schopen být nosným protokolem pro

prakticky jakoukoliv strukturovanou komunikaci, je velmi otevřený i „ze zdola“ a může být přenášen širokým spektrem různých přenosových protokolů na různých vrstvách.

Využití určitého protokolu k přenosu SOAPu se nazývá binding – vazba. Tato vazba může být zcela transparentní, ale je třeba počítat s tím, že zvolený přenosový protokol bude muset vyhovovat svým fungováním parametrům komunikace, které jsou v dané aplikaci vyžadovány. Problém je v tom, že mnoho internetových protokolů je primárně koncipováno jako jednosměrných, zatímco komunikace prostřednictvím zpráv v SOAPu je zpravidla naopak obousměrná – obvykle dochází minimálně k výměně dvou zpráv – otázky a odpovědi.

SOAPovské zprávy je možno mezi dvěma systémy, které jsou takovým způsobem vytvořeny, přenášet přímo v datagramech protokolu TCP. V takovém případě musí být samozřejmě nějak vyřešen problém koordinace komunikace dvou bodů v síti, ale teoreticky nic nebrání tomu, aby k takové komunikaci došlo a aby byla obousměrná. Obousměrná může být nejen vlastní komunikace, ale i její zahájení může být iniciováno z kterékoliv strany.

20/47

ověření autentizace

(aktivní zprostředkovatel)

výběr adresáta

(směrující zprostředkovatel)

platební server

(konečný příjemce)

objednávkový server

(konečný příjemce)

příchod zprávy do systému

výběr serveru pro zpracování

odeslání odpovědi

Legenda:SOAP server

cesta zprávy

Obr 5 – schéma směrování SOAP zpráv

Takové řešení ale není příliš běžné, protože mezi TCP a SOAPem musí existovat de facto vlastní proprietální protokol, který definuje, jak bude která komunikace zahájena, na jakém portu, v jakém pořadí bude komunikováno, jaké budou timeouty, jak bude zajištěno šifrování přenosu, případně autentizace, atd. – vlastně celý protokol relační a prezentační vrstvy dle ISO OSI modelu (21).

Daleko častější je SOAP komunikace na bázi nějakého protokolu vyšší vrstvy – HTTP nebo SMTP. Protokol HTTP je zdaleka nejpoužívanější a to mnoha důvodů. Když pomineme důvody historické, jeho struktura odpovídá nejběžnějšímu způsobu užití SOAPu – typu dotaz-odpověď, podporuje abstraktní webové metody GET, PUT, POST a DELETE (zúžené obvykle jen na GET a POST), které mohou pracovat s každým zdrojem dostupným přes URI a především je podporován takovým množstvím softwarových nástrojů jako snad žádný jiný protokol. Nevýhodou je, že komunikace může být iniciována pouze z jedné strany – od klienta, není zabezpečeno šifrování přenosu (pokud není použito SSL) a HTTP samo o sobě neobsahuje dostatečnou autentizaci.

Rozlišují se dva režimy komunikace – režim GET, který je de facto pasivní a slouží pouze k získání dat ze serveru prostřednictvím protokolu SOAP a režim POST, který zároveň vzdálená data může modifikovat např. voláním vzdálené metody.

Třetí možností je přenos SOAP zpráv prostřednictvím služeb elektronické pošty, zejména protokolu SMTP. Vlastní zpráva může být obsažena v těle, jakož i příloze poštovní zprávy. Výhodou tohoto řešení je na jednu stranu jeho obousměrnost – komunikace může být iniciována z obou stran. Citelnou nevýhodou je naopak její negarantovanost. Existují sice možnosti potvrzování doručení zpráv (doručenky DSN), ale jejich implementace je dle mého soudu netriviální. Těžkosti v implementaci vyplývají i z toho, že je zpráva zpravidla na SMTP vrstvě doručována přes několik poštovních serverů, na kterých se může při jejich vysokém zatížení zpozdit. Tím, že se dotaz a odpověď přenáší v oddělených mailech, vyvstává další problém se spárováním zpráv patřících k jedné komunikační seanci. Přes tyto zjevné nevýhody nelze tuto vazbu na protokol SMTP jednoznačně zavrhovat.

Pro předávání SOAP zpráv prostřednictvím nižších protokolů se ve verzi 1.2 specifikace doporučuje používat MIME typ média: application/soap+xml (22).

SOAP sám neposkytuje žádné zajištění bezpečnosti, ať už jde o šifrování, autorizaci, autentizaci či integritu zpráv. Tyto techniky je nutno zajistit na nižších (např. SSL) nebo naopak na vyšších (šifrování přenášených dat) vrstvách.

Verze SOAPuSOAP byl původně ve verzi 0.9 a 1.0 vyvinut společnostmi Microsoft, Userland a

Developmentor. Později byly ke spolupráci přizvány další společnosti: IBM a Lotus, s tím, že se na vývoji podílely další firmy (Ariba, Commerce One, Compaq, HP, Iona a SAP) a tak byla vytvořena verze 1.1. V roce 2000 převzalo SOAP pod svá křídla W3 konsorcium (4), ale verze 1.1 se nikdy nestala oficiálním standardem. W3C ji označilo pouze jako NOTE. Přesto jde o de facto standard, protože je v současnosti velmi rozšířen a široce podporován. Verze 1.2 byla vydána po poměrně dlouhé době jako skutečný standard v roce 2003. Od předchozích „neoficiálních“ verzí se poměrně liší a není dosud dostatečně podporován.

Verze 0.9 – první publikovaná verze. Šlo o protokol pro vzdálené volání metod vyvinutý na základě implementace XML-RPC, což byl protokol společnosti Userland pro vzdálené volání metod. HTTP byl pro verzi 0.9 jediným možným přenosovým protokolem.

Verze 1.0 – původně byla vyvinuta pro použití v modelu COM (23) a stále ještě dokázala pracovat pouze s HTTP (event. HTTPS) jako podkladovým protokolem. Šlo tedy o do jisté míry platformově specifické prostředí. Umožňovala volat vzdálené metody napsané v různých prostředích (DCOM, CORBA, Java) a data byla strukturována pomocí XML.

Verze 1.1 – nebyl nikdy oficiálně standardizován, přesto je to dodnes nejpodporovanější verze SOAPu a de facto standard. Největším rozdílem oproti předchozí verzi je její nezávislost na jednotlivých platformách. Není závislá na přenosovém protokolu (již ne pouze HTTP), jazyku, kódování dat, atd. Verze 1.1 je poměrně velice flexibilní a dává vývojářům značnou svobodu při psaní

21/47

kódu. Nevýhodou u verze 1.1 je, že se nestala oficiálním standardem. Díky tomu nejsou některé její implementace vzájemně 100% kompatibilní.

Verze 1.2 – aktuální verze, která přináší mnohé změny. Zle je shrnout zhruba následovně: SOAP je standardizovanější, mnohé detaily, které nebyly v předchozích verzích řešeny jednoznačně, byly upřesněny nebo změněny tak, aby byl protokol vnitřně konzistentní (např. u chybových hlášení byla zrušena tečková notace a nahrazena standardním kvalifikovaným jménem). Doporučený media type byl změněn z obecného text/xml na application/soap+xml. Byl zaveden element rpc:result, přibyla chybová hlášení, nové elementy a atributy a to zejména v hlavičkách zpráv.

Jak již bylo naznačeno a jak bude patrné i v kapitole o nástrojích pro implementaci webových služeb, v současné době je dosud bezkonkurenčně nejšířeji podporována verze 1.1. Verze 1.2, přestože je uvolněna od června 2003, není dosud většinou dostatečně podporována (případně pouze v nefinální verzi Candidate Recommendation).

Přesto přese všechno je protokol SOAP velmi rozšířen a skvělé vyhlídky má i do budoucna. Současná masivní poptávka po integraci B2B nástrojů a stále silnější rozšiřování webových služeb podle mého názoru přispěje k jeho dalšímu rozšiřování. Jeho výhodou je vedle otevřenosti též jednoduchost – na pár předešlých stránkách jsme prošli naprostou většinu jeho vlastností – a univerzálnost použití.

22/47

UDDI

Základní východiskaJednou ze základních technologií, které s fenoménem webových služeb souvisejí, je UDDI,

kterým se budeme zabývat podrobněji. Jde o otevřený univerzální registr firem, jimi poskytovaných služeb a datových rozhraní, pomocí kterých je s nimi možno komunikovat.

Nejprve je třeba vymezit, co budeme rozumět pod pojmem UDDI. Jednak je to technologie a forma poskytování informací o webových službách. UDDI server si může nakonfigurovat (např. s použitím SW Microsoft Windows Server 2003 nebo volně šířeného jUDDI) v rámci internetu nebo intranetu každý a poskytovat tak určité webové služby svému okolí prostřednictvím protokolu UDDI (založeného na protokolu SOAP). Častěji se však pod pojmem UDDI rozumí tzv. UDDI Business registry (UBR), což je služba poskytovaná společnostmi Microsoft, IBM, SAP a dalšími, které u zrodu UDDI stály, a která vytváří jednotný celosvětový registr UDDI, do kterého může kdokoliv vložit záznam o své firmě a svých službách. Nebude-li řečeno jinak, budeme v tomto dokumentu pod pojmem UDDI rozumět UBR. Tato služba je poskytována zdarma a to jak z aktivního, tak i z pasivního hlediska. Bez poplatku tedy může každý svá data vkládat a bezplatně je může kdokoliv rovněž vyhledávat a získávat.

Registr UDDI obsahuje tři kategorie informací (8):

white pages – obchodní informace jako je název firmy, adresa, kontaktní osoby, telefony, email, atd.

yellow pages – členění firem podle nejrůznějších kritérií (geografické, oborové kritérium, podle používaných protokolů, atd.)

green pages – technické informace o webových službách, které jsou firmou poskytovány – popis jejich rozhraní

Datové struktury UDDIData v rámci UDDI jsou konkrétně uložena v několika datových strukturách (8,10,13):

businessEntity – obsahuje údaje o firmě – její název a popis a dále odkazy na seznam kontaktních informací (telefon, email, atd.) – tzv. identifierBag, odkazy na seznam kategorií, do kterých firma patří – tzv. categoryBag a konečně odkazy na businessService, tedy seznam služeb, které firma poskytuje

businessService – obsahuje údaje o webových službách, které firma poskytuje, jejich název a popis, opět odkaz na categoryBag a odkaz na bindingTemplate, který obsahuje konkrétní technický popis rozhraní služby

bindingTemplate – účelem této entity je poskytnout konkrétní popis rozhraní služby. To však není přímo popsáno v této datové entitě, ale je zde odkaz (accessPoint), kde lze takový popis nalézt. Doporučuje se, aby bylo rozhraní popsáno pomocí WSDL, aby byla zajištěna co nejširší kompatibilita. Povinnost to však není a rozhraní může být popsáno i jakýmkoliv jiným způsobem.

tModel – specifická datová struktura, která má v UDDI několik významů (12). V prvé řadě je to zobecnělý popis rozhraní různých služeb, které mají něco společného. Pokud je v UDDI správně využit, umožňuje to např. vyhledávat webové služby od různých poskytovatelů se stejnou funkcionalitou. Najdeme podle nějakých kritérií jednu, zjistíme UUID jejího tModelu a můžeme vyhledat jiné služby se stejnou funkcionalitou. Dalším využitím tModelu je kategorizace dat, kdy je

23/47

definován tModel obsahující různé kategorie a ten je přes asociativní třídy categoryBag a identifierBag přiřazen různým instancím businessEntity a businessService. Tato otevřenost umožňuje pružně přidávat nové modely kategorizace dat a identifikátorů bez nutnosti změny standardu.

Použití UDDI

Hlavním účelem UDDI je usnadnit vyhledávání webových služeb a umožnit získávání strukturovaných informací o firmách a službách. Leckoho asi napadne otázka, proč vlastně něco takového jako UDDI vzniklo, když máme celou řadu poměrně velmi sofistikovaných a velmi rozšířených obecných vyhledávačů jako Googe či Yahoo. Důvodem je, že UDDI na rozdíl od obecných vyhledávačů, které jsou více či méně založeny na fulltextovém vyhledávání, udržuje data ve strukturované podobě, umožňuje vyhledávat podle různých kategorií a definovat mezi webovými službami rozličné vazby. Vyhledaná data se předávají ve strukturované podobě, která je vhodná pro další automatické zpracování (i když se objevují hlasy, že UDDI v současné podobě obsahuje až příliš plného textu (14)).

24/47

Obr 6 – zjednodušený model tříd UDDI – obrázek převzat z (8)

UDDI pravděpodobně nebude s vyhledávači soupeřit, naopak jeho cílem je spíše integrace s různými vyhledávacími portály a elektronickými tržišti, kterým by mělo dodávat přidanou funkcionalitu (což je v podstatě účel webových služeb obecně). Podle konsorcia OASIS by se měli uživatelé UDDI rozlišovat na dvě skupiny (8):

obchodníci – kteří by služeb UDDI využívali zprostředkovaně přes různé portály a tržiště, pomocí kterých by mohli zadávat sofistikovanější dotazy, např. vyhledávání produktu za danou cenu v určité geografické oblasti, atd. Tyto služby UDDI samo o sobě v současné době neposkytuje; elektronický portál by jej využil pro vyhledání podkladové informace, kterou by doplnil (např. pomocí jiných webových služeb) o další údaje.

technici – např. programátoři, kteří by přistupovali k UDDI přímo a zjišťovali konkrétní technické informace např. o rozhraní té které webové služby

Vztah UDDI a vyhledávačů je tedy komplementární.

Je ovšem třeba poznamenat, že existují webové služby, které nejsou z nejrůznějších důvodů zaneseny v UDDI. Buď autor webové služby nepovažuje za nutné ji do UDDI registrovat nebo není ještě dostupná ve finální verzi (existují testovací UDDI registry, kde jsou registrovány některé webové služby ve vývoji), obchodní model autora nemusí počítat s využitím UDDI k propagaci služby nebo existuje jiný důvod. Každopádně se nelze v žádném případě spolehnout na to, že pokud webová služba, kterou hledáme, není k nalezení v UDDI, neexistuje.

Ovšem platí to i naopak – to že je služba zanesena v UDDI rozhodně nezaručuje, že je funkční a dostupná (i když UDDI verze 3 rozšiřuje možnosti, jak se vypořádat s dočasnou nedostupností některých služeb). Nepovažuji to však za překážku – koneckonců celý internet je založen na tom, že funkčnost žádné jeho služby není garantována.

Dále by na tomto místě bylo dobré zmínit organizaci UDDI jako sítě serverů. Jak již bylo řečeno, existuje více serverů UBR, které mezi sebou replikují data. Kdokoliv může postavit své vlastní severy a připojit je k síti a tyto servery potom mohou odpovědi na svoje dotazy čerpat z nadřízených UDDI serverů. Struktura sítě je podobná struktuře sítě DNS serverů.

Získávání dat z UDDIJak konkrétně data z UDDI získat? UDDI Business registry běží, jak již bylo řečeno,

na serverech firem, které standard UDDI prosadily a které jej podporují. V současné době jsou to např. servery firem:

25/47

Obr 7 – skupiny uživatelů UDDI – obrázek převzat z (8)

Poskytovatel Informace poskytovatele o UDDI

UDDI server pro dotazy

IBM http://uddi.ibm.com http://uddi.ibm.com/inquireMicrosoft http://uddi.microsoft.com http://uddi.microsoft.com/inquireSAP http://uddi.sap.com http://uddi.sap.com/UDDI/inquireNTT Networks http://www.ntt.com/uddi http://www.uddi.ne.jp/ubr/inquiryapiAriba nepodařilo se zjistit http://uddi.ariba.com/UDDIProcessor.aw/ad/

process

Stále přibývají další servery, které tuto technologii nabízejí. Nezáleží na tom, který server si vybereme, servery mezi sebou neustále replikují data a tak by měla být odpověď na stejný dotaz od všech serverů stejná. Pokud nechceme v UDDI registru jenom vyhledávat, ale i do něj své služby přidávat, upravovat a mazat, je dobré vědět, že se jednotliví poskytovatelé liší rozhraním pro realizaci takových změn. Bezpečnost totiž není v rámci standardu UDDI verze 2 příliš dobře definována a každý provider ji má vyřešenu po svém (obvykle použitím jména a hesla). Je ale zaručeno, že všichni poskytovatelů služeb dodržují stejnou minimální úroveň ochrany dat.

Primárně je, jak již bylo uvedeno, služba UDDI postavena nad standardy SOAP a XML, tozn. že je určena k tomu, aby byla „oslovována“ speciálními klienty tento formát podporujícími. Pro lepší orientaci však většina výše uvedených poskytovatelů nabízí i lepší či horší webové rozhraní, které umožňuje používat UBR pomocí internetového prohlížeče.

V rámci psaní této práce jsem důkladně v dubnu 2004 a v prosinci 2004 testoval UBR servery společností IBM, SAP a Microsoft a ukázalo se, že v kvalitě a dostupnosti jednotlivých služeb jsou rozdíly. Při přístupu ke službě pomocí SOAPu byly výsledky u všech providerů uspokojivé a plně srovnatelné.

V případě webovského rozhraní byly rozdíly větší: služba Microsoftu sice nabízí pěkné a přehledné rozhraní a nejširší nabídku vyhledávacích taxonomií, ale zato měla při vyhledávání podle kategorií opakovaně takové doby odezvy, že nebylo možno dotazy vůbec dokončit. V tomto směru se situace v prosinci 2004 nijak nezlepšila. Web SAPu, který při testech v dubnu 2004 opakovaně havaroval, byl v prosinci kompletně předělán, přehlednější a uživatelsky přívětivý. Bohužel doby odezvy nemohly konkurovat serveru IBM. Nejlépe si vedl web IBM, který odpovídal spolehlivě, subjektivně mi ale zase připadá jako nejméně přehledný a v tomto směru se nic neměnilo ani po půl roce. Je nutno podotknout, že na objektivnější zhodnocení kvality služeb jednotlivých poskytovatelů by bylo třeba daleko hlubší a systematičtější přístup.

Verze UDDI

UDDI bylo původně technologií firem Microsoft a IBM, ale nyní se o rozvoj tohoto standardu stará konsorcium OASIS, které tyto (a další) firmy utvořily (9).

Verze 1 – byla uvolněna v září 2000 a nabídla základní datové struktury internetového registru, zavedla 6 základních klasifikačních tříd dat (taxonomií): podle North American Industry Classification System (NAICS), 2 taxonomie podle různých verzí United Nations Standard Products and Services Code System (UNSPSC), geografickou klasifikaci podle ISO 3166, podle D-U-N-S® Number Identifier Systém a podle Thomas Register Supplier Identifier Code System. Ve verzi 1 bylo 11 typů tModelů (viz. příloha 2). Specifikaci verze 1 lze nalézt na stránce: http://www.oasis-open.org/committees/uddi-spec/doc/contribs.htm

Verze 2 – z června 2001 lépe propojila UDDI se vznikající architekturou webových služeb a nabídla daleko flexibilnější systém kategorizace entit (rozšířeno o UDDI OwningBusiness Taxonomy, UDDI Relationships Classification System a UDDI Operators Taxonomy a UDDI IsReplacedBy System umožňující značit entity, které byly nahrazeny novou verzí). Bylo přidáno několik základních druhů tModelů – srovnání mezi verzemi 1 a 2 viz. příloha 2. V této verzi přibývá v datovém modelu entita publisherAssertion, která umožňuje popsat vazbu mezi dvěma businessEntities, entitám existujícím ve verzi 1 přibyly některé nové atributy a zprávy, např. assertionStatusReport. V této

26/47

http://www.oasis-open.org/committees/uddi-spec/doc/contribs.htm

http://www.oasis-open.org/committees/uddi-spec/doc/contribs.htm

http://uddi.ariba.com/UDDIProcessor.aw/ad/process

http://uddi.ariba.com/UDDIProcessor.aw/ad/process

http://www.uddi.ne.jp/ubr/inquiryapi

http://www.ntt.com/uddi

http://uddi.sap.com/UDDI/inquire

http://uddi.sap.com/

http://uddi.microsoft.com/inquire

http://uddi.microsoft.com/

http://uddi.ibm.com/inquire

http://uddi.ibm.com/

verzi bylo podstatně upraveno API pro vkládání informací do UDDI zejména zjednodušením vkládání informací od velkých firem a doplněna či přepracována řada dalších drobnějších záležitostí. Verze 2 je v současné době využívána jako verze produkční u většiny poskytovatelů. Specifikaci verze 2 lze nalézt na stránce: http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv2

Verze 3 – z července 2002 (v současnosti již existuje revize 3.0.1 a ve schvalovacím řízení je 3.0.2 – obě pouze s nepatrnými změnami ve schématech) přinesla řadu vylepšení. Byla zavedena vlastnost entity promotion, která umožnila, aby klíče entit mohly být předávány a zachovány mezi jednotlivými UDDI servery. Celkově byl podpořen vznik prostředí s více registry s tím, že kořenovým registrem se stalo UBR (tím služba začala více připomínat DNS). Byly zavedeny „human friendly“ klíče a dány na roveň automaticky generovaným klíčům UUID. Verze 3 začala podporovat digitální podpis a zavedla možnost pracovat s uživatelskými právy (policies). Informační model UDDI verze 3 byl rozšířen mimo jiné o třídu operationalInfo, která shromažďuje informace např. o čase a datu modifikace jednotlivých entit, atd. Důvodem je umožnění výpočtu digitálního podpisu. Objevují se zde také možnosti komplexní kategorizace, která umožní např. používat stejné hodnoty v různých kontextech nebo sdružovat data, která k sobě logicky patří (jako jsou např. geografické souřadnice). Model verze 3 se stal uživatelsky rozšiřitelným a obsahuje podporu mezinárodního prostředí. Zlepšily se i možnosti vyhledávání – např. vícekrokové zužující vyhledávání (subqueries), vylepšení podpory zástupných znaků (wildcards), stránkování výsledků tam, kde jsou nalezeny velké soubory dat a vyhledávací operátory.Dále je zde zlepšená podpora notifikace při změnách registrovaných údajů a podpora replikace dat mezi různými UDDI servery. Specifikaci verze 3 lze nalézt na stránce: http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3

Problém je, že přestože verze 3 je na světě již déle než 2 roky, nedočkala se dosud své širší praktické implementace. Servery poskytovatelů UBR nabízejí nadále „ostrou“ službu pouze ve verzi 2 a verzi 3 pouze v podobě beta testování. I dostupná softwarová řešení podporují, jak je naznačeno v další kapitole, pouze verzi 2. Na masivní rozšíření verze 3 si tedy patrně budeme ještě muset počkat.

V dalších verzích se plánuje (9), že by UDDI mělo dále rozšířit svoji funkcionalitu, podporovat více „obchodní“ formu dotazů a neomezovat se pouze na vyhledávání podle technických kritérií. Mělo by podporovat vyhledávání výrobků a služeb a zohlednit v UDDI existenci hierarchické struktury organizací.

27/47

http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3

http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv2

Ostatní iniciativy v rámci web servicesV oblasti webových služeb existují a stále vznikají další větší či menší iniciativy, které si

dávají za úkol řešit nějakou specifickou oblast webových služeb. Některé fungují pod hlavičkou velkých standardizačních organizací jako W3 Consorcium nebo OASIS, jiné jsou dosud vyvíjeny nezávisle.

Níže uvedené projekty jsou různě životaschopné a je možné, že v budoucnu budou některé z nich sloučeny či zastaveny. Je ale dobré i tyto okrajovější projekty sledovat, neboť často určují, kudy se bude vývoj webových služeb v budoucnu ubírat.

Následující výčet si nečiní nároky na úplnost ani přesnost. Úplnost nelze nikdy zajistit, neboť se stále rodí nové projekty a ty původní se mění, spojují a zanikají. Přesnost nelze zaručit, protože chybí přesné vymezení toho, co do oblasti webových služeb ještě patří a co už ne. Zahrnul jsem pouze obecné iniciativy a vyřadil ty, které technologii webových služeb vymezují úžeji pro využití v určité oblasti (např. OGC pro geografické aplikace). Dále mezi oblast webových služeb nepočítám standardy týkající se sémantického webu, jako např. OWL, SWSI, SWSL, ad., protože se domnívám, že doba, kdy budou nějak reálně využitelné, je ještě daleko – pokud vůbec někdy nastane.

Fast Web ServicesFWS je iniciativa společnosti Sun. Vychází z předpokladu, že standardní webové služby

založené na XML jsou z hlediska výpočetních zdrojů poměrně neefektivní. XML má řadu výhod vyplývajících z toho, že jde o textový formát. Všechny zprávy jsou čitelné i pro lidi, poměrně snadno se v nich hledají chyby, existuje mnoho softwarů, které s nimi umí pracovat, atd. Na druhou stranu přináší takové kódování dat poměrně vysokou režii a nároky na paměť, procesor, disky a síťovou infrastrukturu.

Sun přichází s tím, že by v rámci Fast Web Services rád změřil výkonnost tradičních komunikačních protokolů a určil kde se objevují největší ztráty. Podle toho by sestavil nový use case pro FWS a stanovil standardy webových služeb, které umožní tyto ztráty snížit. Dosáhnout toho hodlá zavedením nových formátů založených na binárních datech, které jsou pochopitelně podstatně úspornější. Místo WSDL přichází s protokolem ASN.1, který je určen k definici struktury zpráv a popisu komunikace v binární formě.

Podle mého názoru jde o zajímavou iniciativu, která jde ale poněkud „proti proudu“. Jednou z hlavních výhod, které se u webových služeb udávají, je právě jejich úzké propojení s textovým XML, díky kterému jsou nejen jednoduché pro vývoj, ale zároveň nemají např. problém zdolávat firewally. Kromě toho dnešní stále rychlejší internet nemá nezbytnou potřebu šetřit své kapacity, neboť než zavádění nových standardů vyjde obvykle levněji natažení nových linek. Přesto může mít tato iniciativa smysl např. u přenosných zařízení a jiných specifických prostředí.

Více informací lze nalézt na: http://java.sun.com/developer/technicalArticles/WebServices/fastWS/

WS-AddressingWS-Addressing je standard pro zajištění směrování zpráv nezávisle na transportním

mechanismu.Zprávy v rámci web services neobsahují samy o sobě údaje nutné k adresaci (na rozdíl např.

od e-mailů). Jsou předávány mezi jednotlivými rozhraními s tím, že trasa kterou putují je zanesena v aplikační logice jednotlivých serverů, které s těmito službami mají pracovat. Iniciativa WS-Addressing vytváří standard, který by měl – zjednodušeně řečeno – dodat zprávám adresační údaje a tím pádem do nich inkorporovat logiku, která byla dosud obsažena přímo v serverech. Směrovací data se vkládají na základě příslušného XML schématu do hlavičky SOAP zprávy, kde je obsaženo např. odkud a kam se má zpráva doručit, případně i přes jaké servery má cestovat. Zprávy webových služeb se tímto způsobem mohou osamostatnit na serverech, které je předávají.

Více informací lze nalézt na: http://www.w3.org/Submission/ws-addressing/

28/47

http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/

http://java.sun.com/developer/technicalArticles/WebServices/fastWS/

Web Service Choreography InterfaceWSCI je iniciativa konsorcia W3C, jejímž cílem je vyvinout standard pro popis komunikace

webových služeb z dynamického hlediska. Standardní webové služby popsané protokolem WSDL jsou do značné míry definovány staticky – jako jisté komunikační rozhraní, které má definované vstupy a výstupy, ale podle dřívějších předpokladů se chová de facto bezestavově. Ve verzi WSDL 2.0 byl v tomto směru sice učiněn jistý pokrok, když byla rozšířena funkcionalita komunikačních vzorů, ale přesto u WSDL převládá spíše jednorázový, statický pohled na komunikaci.

Cílem WSCI je popsat pravidla složitější komunikace a komunikace více služeb. Má jím být popsáno pořadí v jakém lze posílat zprávy na rozhraní jednotlivých webových služeb, jaké vztahy mají mezi jednotlivými rozhraními existovat, atd. Má umožnit definici sekvence zasílaných zpráv, která má mít určitou podobu a do jisté míry má připomínat transakci v databázovém slova smyslu, tozn. má mít definováno jak má začít, jak skončit, zda je či není možné, aby byly provedeny jen některé úkony v rámci dané sekvence zpráv, zda mají změny vstoupit v platnost najednou apod. Jako příklad je uvedeno objednávání letenek, kdy klient kupuje letenky u letecké společnosti a v prvním kroku posílá osobní data, která zpracovává jedna služba, poté vybírá příslušný spoj, což zajišťuje jiná služba a poté provádí platební transakci. Pomocí WSCI má být takový postup formálně definovatelný, má být definovatelné co se stane, když není např. dokončena platební transakce (zda zrušit rezervaci letenky nebo i uložení osobních dat), atd.

Více informací lze nalézt na: http://www.w3.org/TR/wsci/

WSIFÚčelem WSIFu (vyvíjeného pod křídly Apache Foundation) je umožnit vzdálené volání

procedur (tedy de facto to samé, co poskytuje protokol SOAP) implementovaných na různých technologiích: EJB, SOAP, JMS, atd.

Princip je následující: standardně webové služby fungují tak, že volání vzdálené procedury je pomocí příslušné implementace transformováno na SOAP dotaz, odesláno na vzdálený server, zde transformováno do interního formátu příslušné serverové aplikace a stejným způsobem je odpověď zaslána zpět. Transformace do SOAPu ale nemusí být vždy výhodná co do výkonu, nehledě na to, že na straně serveru může dojít ke změně, např. přechodu z EJB na .NET, atd. WSIF se tento problém snaží řešit vytvořením abstraktní vrstvy, která dokáže obecné volání vzdálené procedury (která je popsána pomocí WSDL) transformovat na konkrétní volání ve formátu té které technologie. Vývojář potřebuje například volat metodu obsaženou v Java Beanu, zná její název a strukturu parametrů a má WSDL, které je popisuje. Nevolá příslušný EJB přímo, ale předá volání (které je očištěno ode všech platformově závislých dat) vrstvě WSIF, ta jej transformuje na příslušné volání EJB a stejným způsobem vrátí návratovou hodnotu. Výhodou je, že pokud z jakéhokoliv důvodu bude stejná služba dostupná nikoliv jako EJB, ale například v podobě .NET nebo prostřednictvím SOAPu, nebude třeba upravovat celou aplikaci.

Více informací lze nalézt na: http://ws.apache.org/wsif

WS-MessageDeliveryWS-MessageDelivery je iniciativa usilující o vyvinutí standardu pro doručování zpráv

souvisejících s webovými službami.Zprávy webových služeb neobsahují implicitně žádné adresování, to znamená, že směrování

zpráv je zajištěno nastavením aplikační logiky jednotlivých serverů, přes které zprávy procházejí. Iniciativa WS-MessageDelivery dodává webovým zprávám patřičnou funkcionalitu pro směrování zpráv. Na první pohled to vypadá, že se účel této iniciativy kryje s iniciativou WS-Addressing a skutečně je tomu tak. Tyto dvě iniciativy se liší spíše v detailech než v nějakých zásadních otázkách. Např. WS-MessageDelivery nedefinuje chybové zprávy, WS-Addressing rozšiřuje možnosti SOAPu s použitím WS-Policy, zatímco WS-MessageDelivery využívá features a properties z WSDL. Za touto dichotomií vidím především to, že za oběma standardy stojí různé skupiny společností (WS-Addressing – Oracle, Arjuna, Sun, Nokia, IONA; WS-MessageDelivery – Microsoft, IBM, SAP, Sun, BEA).

29/47

http://ws.apache.org/wsif

http://www.w3.org/TR/wsci/

Z dlouhodobého hlediska není příliš mnoho důvodů, proč by tyto dvě iniciativy měly fungovat dál vedle sebe a považuji za pravděpodobné, že budou nějakou formou sloučeny nebo jedna z nich prostě zanikne.

Podrobné srovnání obou iniciativ a z nich vyplývajících standardů je uvedeno např. ve (28).Více informací lze nalézt na: http://www.w3.org/Submission/ws-messagedelivery/

WS-PolicyÚčelem standardu WS-Policy není přinášet nějakou novou funkcionalitu či nové vlastnosti

webovým službám. WS-Policy obsahuje prvky pro definování pravidel použitých uvnitř zpráv webových služeb k nastavení jejich vnitřní logiky a spojování vlastností více standardů webových služeb v jedné zprávě. Např. zpráva podporuje šifrování dvěma typy klíčů, avšak pomocí WS-Policy je určeno, že najednou může být použit jen jeden z nich. Pravidly z WS-Policy lze takový vztah definovat. Standard obsahuje pouze 3 elementy, na základě kterých lze sestavovat různá logická pravidla.

Více informací lze nalézt na: http://www.ibm.com/developerworks/library/specification/ws-polfram/

WS-SecurityCíl iniciativy WS-Security je patrně jasný už z jejího názvu. Celý internet má v posledních

letech tendenci zvyšovat bezpečnost veškerých systémů a zajištění proti nekalým úmyslům a webové služby, jejichž potenciál je právě v oblasti obchodních aplikací největší, nemohou stát stranou. Je jistě nadbytečné uvádět zde technické prostředky zajištění internetové bezpečnosti, jako jsou asymetrické šifry, PKI, digitální podpisy, atd. WS-Security definuje standard, který by měl umožnit propojit všechny tyto známé prvky s technologií webových služeb tak, aby bezpečnost byla zajištěna nejen na nižších vrstvách, ale i přímo na vrstvě webových služeb.

WS-Security umožňují šifrování obsahu zpráv, zajištění jejich důvěrnosti, integrity a digitální podepisování. Obsah zprávy může být šifrován a předáván v binární formě. WS-Security zavádí tzv. „security tokens“, identifikátory uživatele, které mohou být navíc chráněny asymetrickou kryptografií podle různých standardů (v součastosti X.509 a Kerberos).

Nicméně jak se uvádí v příslušném standardu (29): „WS-Security samo o sobě nezajišťuje bezpečnost ani neposkytuje komplexní bezpečností řešení. WS-Security je stavební kámen, který ve spojení s dalšími aplikačně-specifickými protokoly zahrnuje širokou škálu bezpečnostních modelů a šifrovacích technologií. Implementování WS-Security neznamená, že aplikace nemůže být napadena a bezpečností model nemůže být prolomen“

Více informací lze nalézt na: http://www-106.ibm.com/developerworks/webservices/library/ws-secure/

Web Services User InterfaceWSUI je standard sdružení OASIS pro snadnou definici uživatelských rozhraní webových

služeb. Jeho cílem je vytvořit jednoduchý jazyk, který umožní vytvářet grafické uživatelské rozhraní webových služeb v podobě webových stránek, které bude přímo inkorporovatelné do webových aplikací. Funkčně to má být zajištěno skrze kontajner WSUI, který má být vytvořen pro různé platformy (Java, .NET, apod.) a má zajišťovat integraci takto napsaných skriptů (WSUI deskriptorů a stylů XSLT) do webových aplikací.

Ze základních komponent, kterými jsou stránky, události, komponenty užívající XSLT a standardní proměnné a výrazy bude možno vytvářet uživatelské prostředí pro prakticky jakoukoliv webovou službu. Pokud se záměr podaří, mělo by být při znalosti virtuálního rozhraní popsaného prostřednictvím WSDL možno velmi snadno vytvořit reálné uživatelské rozhraní (stránky, dialogové rámečky, apod.) této webové služby.

Více informací lze nalézt na: http://www.wsui.org/

30/47

http://www.wsui.org/

http://www-106.ibm.com/developerworks/webservices/library/ws-secure/

http://www.ibm.com/developerworks/library/specification/ws-polfram/

http://www.ibm.com/developerworks/library/specification/ws-polfram/

http://ws.apache.org/wsif

Postup použití webových služebTypický postup implementace webové služby vypadá zhruba následovně:

1) stanovíme kritéria výběru – jaké požadavky potřebujeme pomocí webové služby řešit2) pomocí UDDI vyhledáme webovou službu, která vyhovuje našim kritériím3) z UDDI zjistíme adresu WSDL souboru a popis rozhraní4) podle popisu rozhraní vytvoříme příslušný kód, který umožní se službou komunikovat

Předchozí 4 kroky se provádějí zpravidla jednorázově při zavádění webové služby. Další komunikace se již děje při běžném používání webové služby na rutinní bázi pomocí zpráv na protokolu SOAP.

31/47

Nástroje pro implementaci webových služeb

Aplikační serverNa straně poskytovatele webových služeb je základem aplikační server, na který přistupují

klienti. Podle mého názoru jde v rámci webových služeb o zcela zásadní, klíčovou část software, proto se jí budu zabývat podrobněji.

Stejně jako v dalších oblastech, i zde v současnosti soupeří dvě hlavní řešení: jednak se jedná o platformu .NET společnosti Microsoft a poté platformu ONE společnosti Sun, která je založená na technologii Java.

Microsoft nabízí aplikační server IIS ve verzi 6.0 v rámci svého produktu Windows Server 2003. Tento balík obsahuje celou škálu produktů pro provozování webových služeb počínaje vlastním aplikačním serverem s podporou standardů pro webové služby, serverem UDDI a programovacím rozhraním .NET Framework, které webové služby rovněž podporuje. Celá řada dalších dodavatelů nabízí pro tuto technologii své rozšiřující a podpůrné softwary, komponenty, atd.

Většina ostatních výrobců aplikačních serverů používá jako platformu pro jejich provoz technologii Java. Existuje teda celá řada aplikačních serverů různých výrobců pro webové služby. Mezi nejznámější patří IBM Websphere, Oracle Application Server, BEA WebLogic, Sun Java System Application Server (dříve Sun ONE Application Server) a další. Za zmínku určitě stojí, že většina serverů těchto výrobců je vybudována na technologii Apache Tomcat, který je vyvíjen jako opensourcový server „pod křídly“ Apache Foundation a je tím pádem dostupný zdarma včetně zdrojových kódů. Dále bych zmínil řešení Java Server (dříve WASP) od firmy Systinet, které je zajímavé tím, že nabízí jak variantu s využitím Javy, tak s využitím C++. Kromě těchto existují samozřejmě desítky dalších aplikačních serverů „menších hráčů“, kteří jsou ale méně významní.

Srovnání a výběr aplikačního serveru

Nelze jednoznačně tvrdit, že ten či onen aplikační server je výrazně lepší, než ostatní. Dokonce bych se zdráhal soudit i zda je lepší používat servery na platformě Java či .NET. Aplikační servery jsou dost komplikované technologie, při jejichž výběru je nutno zvážit obrovské množství různých kritérií. Jednotlivé produkty se liší spíše v jednotlivostech nebo lepší kompatibilitě s jinými softwary svých výrobců (např. kompatibilita aplikační server – databáze). Některé mají své ojedinělé vlastnosti, které mohou být pro určité aplikace výhodné (např. Cold Fusion MX je jediným aplikačním serverem podporujícím technologii Cold Fusion). Kromě mnoha jiných faktorů je nutno zvážit také jak „velká“ aplikace má být provozována, jaké jsou nároky na spolehlivost, jaké jsou nároky na interoperabilitu s jinými aplikacemi, jak drahé bude spravování serveru a aplikace a mnoho dalších otázek.

Za podstatný fakt a klad většiny řešení na bázi Javy považuji to, že je jejich výrobci povětšinou nabízejí pro účely vývoje a testování (někteří případně i pro školní účely) zdarma. To samozřejmě představuje výhodu, neboť vývoj software je o to levnější. Na druhou stranu je ale třeba poznamenat, že jinak jde o zcela normální komerční aplikace, k jejichž produkčnímu používání je třeba licence a ta nebývá právě levná.

.NET framework od Microsoftu je naproti tomu díky penetraci Windows Serverů všeobecně vysoce rozšířen, je o něco univerzálnější než Java, neboť umožňuje používat širší škálu programovacích jazyků a je nutno vzít v úvahu i jeho relativně nízkou cenu. Z těchto a dalších důvodů je proto samozřejmě třeba před výběrem konkrétního řešení provést detailní analýzu a snažit se o co nejkomplexnější pohled.

V následující tabulce jsem shromáždil údaje o cenách výše zmíněných produktů. Vzhledem k tomu, že každý produkt je nabízen v celé řadě konfigurací, snažil jsem se vycházet vždy z ceny nejlevnější použitelné varianty (např. pokud výrobce nabízí verzi pro 1 a pro 2 procesory, uvedl jsem cenu verze pro 1 procesor). Ceny jsou platné v listopadu 2004, byly zjištěny z veřejně dostupných zdrojů a je třeba chápat je jako orientační. Přesto je třeba mít na paměti, že takto sestavený přehled může být díky různým vlastnostem různých verzí jednotlivých řešení matoucí, daleko podrobnější, důslednější a pravidelně aktualizované srovnání lze nalézt např. v (19).

32/47

Název aplikačního serveru Přibližná cena v USDBorland Enterprise Server 12000IBM Websphere Application Server 10000Oracle Application Server 10000Sybase EAServer 7500Cold Fusion MX 6000BEA Weblogic 4000Sun Java System Application Server 2000Systinet Java Server 2000Microsoft Windows Server 2003 999Microsoft Windows XP Professional 299Apache Tomcat 0

Dále musíme mít na paměti, že ceníková cena aplikačního serveru (stejně jako koneckonců jakéhokoliv jiného software) vyjadřuje jen část nákladů na jeho provoz a vybírat software pouze podle ní by bylo velmi krátkozraké. Je třeba zohlednit TCO (total costs of ownership) jednotlivých softwarů, což už není triviální záležitost, nelze ji vyjádřit tak snadno jako ceníkovou cenu, nehledě na to, že je pro různé subjekty různá. Např. Apache Tomcat může být nejlevnějším řešením pro nadšence, který poskytuje webové služby ze svého domácího počítače a má dost času si „s tím hrát“, naopak pro velkou nadnárodní firmu může být toto řešení vzhledem k nákladům na správu, konfiguraci, bezpečnost, atd. tím vůbec nejdražším.

Ostatní softwarePro implementaci a provoz webových služeb bude dále třeba řada dalšího software, jako jsou

operační systémy, databáze a další. Výběr těchto systémů samozřejmě závisí částečně na volbě aplikačního serveru a na řadě dalších kritérií. Nemá smysl se na tomto místě jejich výběrem nějak do hloubky zabývat, neboť s webovými službami souvisí jen zprostředkovaně.

Vývojové nástrojeVýběr vhodného vývojového prostředí do značné míry závisí od výběru aplikačního serveru.

Většina výrobců aplikačních serverů dodává svoje vývojové prostředí, které je zvlášť vhodné pro aplikační server příslušného výrobce. Na druhou stranu ale není na tomto faktu třeba příliš bazírovat, neboť současné vývojové nástroje jsou většinou poměrně mocné a univerzální, kromě toho je třeba brát v úvahu i vývoj aplikací na straně klienta a řadu dalších faktorů.

Altova XMLSPY (www.altova.com/xmlspy)Tento produkt vybočuje z řady produktů, které jsou popsány výše, protože není založen jako

tradiční vývojové nástroje na překladači programového kódu, ale naopak vychází primárně z protokolů XML, SOAP a dalších a nabízí jejich dokonalou podporu a provázanost. Zároveň umožňuje do vývoje aplikací integrovat databáze na jedné straně nebo technologie jako je JSP nebo ASP.NET na straně druhé. Zjednodušeně řečeno – zatímco tradičně je těžiště vývoje aplikací v programu napsaném v programovacím jazyce a vše kolem bylo dotvořeno k jeho podpoře, XMLSPY staví do centra zájmu XML a technologie webových služeb. K takto vytvořeným dokumentům XML dokáže poté vygenerovat i patřičný kód v Javě, C++ nebo C# tak, aby mohly být provázány s konkrétní aplikací (18).

Je to velmi rychlý a účinný způsob vývoje a při vhodné integraci s nějakým klasickým nástrojem podle mého názoru ukazuje cestu, kterou se budou tyto systémy v následujících letech možná ubírat.

33/47

BEA Weblogic Workshop (www.bea.com)Společnost BEA nabízí vývojové prostředí pro jazyk Java a technologii J2EE zaměřené na

vývoj aplikací pro svůj aplikační server BEA WebLogic. Prostředí v oblasti webových služeb podporuje protokoly SOAP 1.2, WSDL 1.2 a UDDI 2.0 a v souladu s očekáváními, která jsou na takovýto software kladena, obsahuje vizuální vývojové nástroje, funkce pro implementaci webových služeb (např. mapování WSDL do javovských tříd), ad.

Borland Delphi/Kylix (www.borland.com/delphi)Delphi je vývojový nástroj pod Windows umožňující vývoj aplikací na platformě .NET pro

servery společnosti Microsoft. Kylix je plně kompatibilní s Delphi a vyvíjejí se na něm aplikace pod Linuxem. Jejich význam z hlediska tržního potenciálu je spíše okrajový, nepřinášejí ani žádné jiné významné přednosti, je ale dobré je zmínit, neboť je to jediný produkt, který podporuje jazyk ObjectPascal, čímž zcela vybočuje z mainstreamu technologií pro vývoj webových služeb.

Tato platforma má nástroje pro vizuální implementaci SOAPu jak na platformě .NET, tak Win32.

Borland JBuilder (www.borland.com/jbuilder)JBuilder je tradičním vývojovým nástrojem společnosti Borland. Podle mých zkušeností se

vyznačuje především velice kvalitním programátorským editorem s ještě širšími schopnostmi, než např. v případě netBeans, které zpříjemňují psaní programového kódu. V nejširší verzi nabízí prostředí např. vizualizační nástroj UML pro refaktoring kódu podle UML schémat. Součástí je samozřejmě debugger, vč. předkompilačního upozorňování na chyby a výkonný profiler pro optimalizaci aplikací.

JBuilder obsahuje WYSIWYG tvorbu JSP stránek, servletů a webových služeb. V aktuální verzi je podporována J2SE verze 5.0 a J2EE ve verzi 1.4. Podporovány jsou aplikační servery firem Borland (Borland Enterprise Server, jenž je s vývojářskou licencí dodáván společně s vyššími verzemi JBuilderu), IBM WebSphere, JBoss, BEA WebLogic, Sun Java Application Server, Sybase EAServer a samozřejmě Tomcat.

JBuilder má ve své Enterprise verzi pro vývoj webových služeb celou řadu prostředků vč. wizardů pro automatickou tvorbu WSDL schémat, nástroj pro vizuální editaci komponent webových služeb a mnoho dalšího. Kompletní přehled funkcí je dostupný v (17).

Dreamweaver MX (www.macromedia.com/software/dreamweaver)Dreamweaver MX je produktem společnosti Macromedia pro vývoj webových stránek a

aplikací v ASP.NET, JSP, PHP, Cold Fusion, ad. Od ostatních výše uvedených vývojových prostředí se podstatně liší – je to totiž v první řadě prostředí pro tvorbu webových stránek, proto jsou jeho schopnosti jakožto programovacího nástroje poněkud chudé. Vývoj aplikací např. v Cold Fusion je odlišný od vývoje webových aplikací v jiných jazycích – CFML připomíná více HTML než např. kód v Javě.

Dreamweaver MX neobsahuje funkce jako je debugger, ani jiné pro vývojáře běžné a standardní nástroje. Je zde však plná podpora webových služeb ve všech jazycích, které lze v rámci Dreamweaweru použít a implementace webové služby je velmi snadná a to dokonce i pro neprogramátora (zejména v jazyce CFML).

Pravověrní „kodeři“ nad tímto prostředím asi ohrnou nos právě kvůli absenci funkcí, které považují za běžné, avšak pro uživatele, kteří neprogramují, může tento přístup znamenat významnou výhodu oproti jiným vývojovým nástrojům. Kromě toho je to jedno z mála prostředí, kde lze vyvíjet aplikace v Cold Fusion, takže pokud se z jakéhokoliv důvodu rozhodneme právě pro tuto platformu, nemáme příliš na výběr a je dobré o tomto softwaru vědět.

Eclipse (www.eclipse.org)Eclipse není klasický vývojový nástroj, ale univerzální prostředí na bázi open source, které

umožňuje vývoj „čehokoliv“. Samo o sobě toho mnoho neumí, ale prostřednictvím vložení zvláštních modulů – tzv. plug-inů – s konkrétní funkcionalitou se dokáže proměnit ve vývojový nástroj Javy, C++ a dalších jazyků. V rámci projektu Eclipse vzniká Eclipse Web Tools Platform Project, jehož cílem

34/47

je vytvořit v rámci Eclipse nástroje pro budování vícevrstevných aplikací a Web Standard Tools Subproject, pod kterým jsou vyvíjeny jednotlivé komponenty pro tvorbu webovských služeb (WSDL, UDDI, XSD, XSLT, atd.)

Eclipse je do budoucna velmi slibné prostředí a zdá se, že se stane standardem, nad kterým budou v budoucnu svá řešení stavět i mnozí komerční poskytovatelé, tak jako je tomu např. v případě serveru Apache Tomcat.

IBM WebSphere Studio Application Developer (www.ibm.com/software/awdtools/studioappdev)

WSAD je vývojový nástroj společnosti IBM založený na open sourcovém prostředí Eclipse. Podporuje Javu a obsahuje širokou paletu standardních vývojových prostředků, funkcí pro týmovou práci a standardních vizualizačních nástrojů.

Podpora webových technologií je solidní a přítomny jsou editory pro WSDL, kde je možno editovat kód jak textově, tak vizuálně, rozhraní pro UDDI, konverzní wizardy, nástroje pro deployment a další funkce.

Microsoft Visual Studio .NET (msdn.microsoft.com/vstudio)Jde o nástroj Microsoftu a jedno z nejrozšířenějších a nejkvalitnějších vývojových prostředí

vůbec. Výhodou je podpora více programovacích jazyků vč. Javy (resp. J#), což umožňuje vývoj jak aplikací pro javovské webové servery (i když pro tento účel rozhodně není optimální volbou), webových aplikací na bázi ASP.NET, tak třeba i nativních Win32 aplikací na straně klientů, atd. Visual Studio má velmi dobrou podporu XML a webových služeb – pomocí zabudovaných wizardů lze snadno příslušnou webovou službu vyhledat v UDDI nebo přímo nalézt příslušný WSDL skript a z něho zcela automaticky vygenerovat příslušné rozhraní. Stejně mocné nástroje jsou i při vytváření kódu na straně serveru. Díky všem těmto vlastnostem je bezesporu jeden z nejdůležitějších vývojových produktů na trhu.

Microsoft Web Matrix (www.asp.net/webmatrix)Jde o volně šířený produkt společnosti Microsoft, který tato firma vydala za účelem podpory a

většího rozšíření technologie ASP.NET. Je cílen na programátory v Javě a PHP, kteří jsou zvyklí na open sourcové vývojové nástroje nabízené zdarma. Vzhled a ovládání Web Matrixu záměrně v mnohém imituje Visual Studio .NET, což má pochopitelně rovněž dobré důvody – případný přechod z Web Matrixu na „opravdové“ VS.NET je pro uživatele velmi jednoduchý.

Na rozdíl od Visual Studia je Web Matrix – jak už koneckonců jeho název napovídá – určen pouze pro programování webových aplikací a webových služeb, postrádá tedy podporu desktopovým a dalším „okenním“ aplikacím. I škála programovacích jazyků je chudší, přesto je možno vyvíjet v C#, Visual Basicu a J#, což představuje konkurenci pro volně šířené javovské nástroje.

Ve Web Matrixu jsou webové služby podporovány jak aktivně, tak pasivně – lze zde programovat řešení jak na straně klienta, tak na straně serveru.

netBeans (www.netbeans.org)Vývojový nástroj netBeans je dnes již tradičním a velmi mocným vývojovým prostředím pro

tvorbu aplikací v Javě a příbuzných technologiích. Za zmínku stojí, že vzniknul v Čechách, byl ale koupen společností Sun a v současnosti je jí plně podporován. V netBeans nejsou webové služby podporovány na rozdíl od příbuzného Sun Java Studia přímo –je zde pouze editor pro XML a odvozené formáty. Existuje ale komerčně dostupný plug-in do netBeans, který se jmenuje iopsis iNsight a který umožňuje velmi kvalitní práci zejména s WSDL, má komfortní vizuální prostředí založené na UML notaci a umožňuje rychle webovou službu vytvořit či připojit.

Oracle JDeveloper (www.oracle.com/tools)Oracle JDeveloper je jeden z „nejvizuálnějších“ vývojových nástrojů, jaké jsou na trhu. Je

založen na jazyku Java a obsahuje veškeré tradiční vývojové prostředky, jako jsou editory Javy, XML,

35/47

HTML ad., debugger, profiler a mnoho dalších nástrojů pro vývoj standardních i webových aplikací a webových služeb.

Hlavní předností JDeveloperu jsou však jeho tzv. „vrstvy“, které podporují vývoj řešení vizuálními modely v UML i proprietální oraclovské notaci. Na rozdíl od řady jiných řešení, kde se tu a tam začínají objevovat UML editory, zde je vizualizací podporován celý vývojový cyklus projektu.

Velkou výhodou Oracle JDeveloperu je, že jej lze na základě speciální vývojářské licence stáhnout zdarma ze serveru Oraclu (podmínkou je, že na základě této licence lze software používat pouze pro vývoj; pro ostré nasazení vytvořené aplikace je nutno samozřejmě zakoupit standardní licenci).

PhpED (www.nusphere.com/products)PhpED od firmy NuSphere je zástupcem vývojových prostředků podporujících PHP. Jde o

poměrně vyspělý nástroj, který nezapře, že se jeho autoři značně inspirovali Visual Studiem .NET. PhpED podporuje funkce knihovny NuSOAP a umožňuje v PHP webové služby implementovat. Přece jen je ale toto prostředí z hlediska podpory webových služeb podstatně méně komfortní, než většina výše uvedených.

Sun Java Studio (www.sun.com/software/javasystem/javastudio)Sun Java Studio (dříve Sun ONE Studio) je de facto komerční verze netBeans a existuje

v několika verzích. Sun Java Studio Standard má navíc podporu webových služeb již přímo zakomponovánu v sobě. Podpora webových služeb je víceméně standardní, umožňuje tvořit automaticky SOAP dotazy z javovských metod, generovat automaticky rozhraní pro testování WSDL a registrovat webovou službu v UDDI. Chybí vizuální podpora vývoje webových služeb a další funkce. I do SJS lze však stejně jako do netBeans pro rozšíření podpory webových služeb doplnit plug-in iopsis iNsight.

Sun Java Studio Enterprise má navíc lepší podporu týmové práce a je integrováno s aplikačním serverem společnosti Sun, který se v momentálně jmenuje Sun Java Application Server.

Sybase PowerBuilder (www.sybase.com/powerbuilder)Power Builder je vizuální vývojový nástroj firmy Sybase, který je dodáván ve 3 verzích –

Enterprise, Professional a Desktop, z nichž webové služby podporuje pouze verze Enterprise. Prostřednictvím wizardů, tak jako ve většině podobných aplikací, mohou být na základě dat z UDDI a odkazu na WSDL odvozeny automaticky klientské aplikace ve standardním „okenním“ provedení nebo jako JSP. PowerBuilder umožňuje vyvíjet a instalovat aplikace přímo na aplikační server EAServer, ale prostředí není omezeno pouze na tento jeden systém: podporuje vývoj jak v Javě, resp. J2EE, tak v .NET. Prostředí používá software Axis pro zpracování datového rozhraní s protokolem SOAP.

Systinet Developer (www.systinet.com/products/wasp_developer)Jde o vývojový nástroj společnosti Systinet určený přímo pro vývoj webových služeb, který

nahradil předchozí produkt Systinet WASP Developer. Integruje se jako plug-in do vývojového prostředí Eclipse, které bylo zmíněno výše. Vzhledem k vysoké specializaci tohoto software je jeho používání velmi pohodlné – např. z javovské třídy lze několika kliknutími vytvořit veškerá rozhraní pro komunikaci prostřednictvím SOAPu, vytvořit popis ve WSDL a vzniklý JAR balík nahrát na server. Zároveň lze naopak z WSDL rozhraní nalezeného např. prostřednictvím UDDI registru vygenerovat zdrojový kód klientské aplikace. Systém podporuje programovací jazyk Java.

Tento výčet si nečiní nároky na úplnost. Existuje celá řada dalších jak komerčních, tak volně šiřitelných vývojových nástrojů umožňujících tvorbu webových služeb a jak je v IT obvyklé, situace se neustále mění – vznikají nová prostředí, původní se vyvíjejí, mění, přejmenovávají a některá i zanikají. Mojí snahou bylo vybrat významné produkty, ať už z hlediska významu firmy či organizace, která za nimi stojí nebo takové, které nabízejí nějakou ojedinělou vlastnost.

36/47

Opensourcové projekty týkající se webových služeb

Implementace SOAPuPod pojmem webové služby si většina vývojářů představuje právě implementaci protokolu

SOAP obvykle v podobě servletu na aplikačním serveru, který dokáže nějakým způsobem transformovat volání metod v kódu na volání vzdálených metod prostřednictvím protokolu SOAP.

Když jsem testoval jednotlivá řešení, nemohl jsem si nevšimnout dominantního postavení projektu Apache Axis mezi open sourcovými řešeními webovských služeb. Drtivá většina zkoumaných aplikací se s Axisem (případně jeho předchůdcem – Apache SOAP) poměřovala nebo s ním deklarovala kompatibilitu. Axis je navíc, jak již bylo uvedeno, základem řady komerčních produktů. Jde tedy v podstatě o svého druhu „průmyslový standard“ a je otázkou, zda má smysl při implementaci webovských služeb – uvažujeme-li o open source řešení – význam přemýšlet o něčem jiném.

Apache Axis (ws.apache.org/axis)Podporuje: SOAP 1.1 (verzi 1.2 podle „Candidate Recommendation“), WSDL 1.1, SAAJ 1.1,

JAX-RPC 1.0Axis je aktuální projekt organizace Apache Foundation a následovník Apache SOAP.

Vzhledem k tomu, že Apache Foundation znamená v open source zhruba to samé, co Microsoft ve sféře komerční, je jasné, že Axis je jedna z nejpopulárnějších platforem pro webovské služby. Díky dodržování standardů a silné vazbě na Apache Tomcat (který je de facto v pozadí většiny komerčních aplikačních serverů) je Axis velmi široce rozšířen. Je obsažen v řadě komerčních aplikačních serverů firem Borland, Macromedia, IBM, ad.

Původně byl Axis určen pro platformu Java, nicméně existuje již i projekt AxisCPP pro C++.Axis má velmi dobrou „komunitní“ technickou podporu a na internetu k němu lze nalézt

dostatek informací. Výhodou je i jednoduchá implementace webových služeb v Axisu. Nabízí se zde dva způsoby

deploymentu – standardní, kdy musí vývojář napsat WSDD schéma, příslušnou třídu přeložit, atd. a zjednodušený, kdy stačí pouze nahrát zdrojový .java soubor na aplikační server a ten se již o vše postará automaticky a službu zprovozní. Tento režim sice není dobrý pro běžné používání, neboť jsou zpřístupněny veškeré veřejné entity dané třídy, ale je ideální pro testování či výuku.

Všechny tyto vlastnosti dělají z Axisu mezi open sourcovými řešeními webových služeb patrně volbu č. 1.

Apache SOAP (ws.apache.org/soap)Apache SOAP je předchůdce projektu Axis a de facto představuje 3. generaci tohoto software.

Apache SOAP je pomalejší, zastaralý, nepodporuje WSDL a je pracnější jej používat. Navíc není již téměř 2 roky vyvíjen a většina zdrojů se již odvolává na Axis, i když některé starší dokumenty Apache SOAP stále ještě zmiňují. Je proto dobré o něm vědět, ale nemá mnoho smyslu se jím dále zabývat.

SOAPAnywhere (sourceforge.net/projects/soapanywhere)Podporuje: SOAP 1.2SOAPAnywhere je zajímavá alternativa k Axisu – jde opět o implementaci SOAPu, autoři

tvrdí, že verze 1.2, ale vzhledem k tomu, že poslední úpravy na tomto projektu byly provedeny v červenci 2002, přičemž 1.2 Recommendation byla přijata až v červnu 2003, jde pravděpodobně o implementaci dle Candidate Recommendation. V tomto směru by tedy měl být aktuálnější Axis, přestože u něj autoři garantují komaptibilitu pouze s verzí 1.1 a 1.2 ve fázi Candidate Recommendation.

Zvláštností SOAPAnywhere je, že dokáže běžet i bez aplikačního serveru, kdy se chová jako samostatná aplikace – HTTP a HTTPS server. To může být teoreticky výhoda pro testování, ale pochybuji, že by tak v praxi někdo dělal. Kromě toho ale samozřejmě může SOAPAnywhere běžet i v rámci aplikačního serveru Tomcat, JBoss, atd.

37/47

Instalace webové služby je podobná „standardnímu“ deploymentu Axisu, tozn. že příslušná třída je zkompilována, musí k ní být vytvořen popisovací soubor v XML (obdoba WSDD schématu Axisu), zkomprimován do SARu (JARu) a nahrán na server.

Programování klienta je zase naopak podobné „nízkoúrovňové“ tvorbě klienta ve Spheon JSOAP, kdy musí programátor sám ošetřit komunikaci a převod dat prostřednictvím příslušných datových struktur. Celkově mi práce se SOAPAnywhere připadala poměrně dost složitá a ve srovnání s Axisem nebo např. Systinet Java Serverem zbytečně komplikovaná. K tomu přispívá i to, že SOAPAnywhere nepodporuje WSDL, čili neexistuje žádné pohodlné automatické generování rozhraní, apod.

Za zmínku stojí i to, že projekt momentálně není rozvíjen, jeho home page byla zrušena a poslední úpravy jsou více než 2 roky staré.

Spheon JSOAP (soap.fmui.de)Podporuje: SOAP 1.1Jde o soubor knihoven a nástrojů pro implementaci SOAPu v Javě a to jak na straně klienta,

tak na straně serveru. Připadá mi, že strana serveru je lépe propracovaná, než strana klienta: existují zde wizardi pro podporu implementace služby, WSDL je podporováno pouze na straně serveru, atd.

Podporuje předávání SOAP zpráv nejen prostřednictvím HTTP, ale i skrze SMTP.Klient může být napsán dvojím způsobem – nízkoúrovňově, kdy přímo pracuje s objekty

příslušných tříd zastupujících složky protokolu a musí je více méně „ručně“ dekódovat a ošetřit nebo vysokoúrovňově (což je přístup podobný jako u Axisu i většiny komerčních implementací), kdy je na webovou službu namapováno javovské rozhraní a vývojář může ke službě přistupovat stejně, jako by šlo o interní metodu. Vytknout lze absenci podpory WSDL na straně klienta, která nutí napsat příslušné rozhraní ručně a implementaci tak komplikuje.

K dispozici je sice stručná, ale přehledná dokumentace.

XSOAP toolkit (www.extreme.indiana.edu/xgws/xsoap)Podporuje: SOAP 1.1, WSDL 1.1XSOAP toolkit je vyvíjen na univerzitě v Indianě jakožto výzkumný projekt jehož cílem je

zkoumat využití webových služeb ve vědě. Jde o knihovny implementující RMI (Remote Method Invocation) na protokolu SOAP v Javě a v C++, v aktuální verzi kompatibilní s Apache Axis.

XSOAP se vyznačuje naprosto nedostatečnou dokumentací, díky které je jeho implementace velmi nesnadná. Mám ale za to, že autoři ani nikdy nepočítali s masovým rozšířením tohoto software.

Pluginy do EclipseProstředí Eclipse je stále populárnější, proto není divu, že pro něj vzniká celá řada plug-inů

souvisejících s webovými službami.

Eclipse WSDL2Java plugin (wsdl2javawizard.sourceforge.net)Jeho funkcionalita je podobná jako u SOAPclipse – na základě WSDL souboru vygeneruje

automaticky příslušné Javovské třídy. Autoři připouštějí inspiraci Microsoft Visual Studiem.NET – generování je skutečně vizuální za pomoci wizarda. Tento projekt se zdá být v současnosti více životaschopný, než SOAPclipse.

Improve Axis Plugin (www.improve-technologies.com/alpha/axis)Plug-in do Eclipse se širší funkcionalitou – umožňuje z WSDL vytvářet javovské interface a

naopak, z javovských tříd vytvořit WSDL, popisovač WSDD a publikovat webovou službu na Axis server.

Projekt je vyvíjen v Improve Technologies jako open source. Z pluginů do Eclipse týkajících se webových služeb mi připadá jako jeden z neužitečnějších a jeho použití je jednoduché.

38/47

SOAPclipse (soapclipse.sourceforge.net)SOAPclipse je plug-in, který umožňuje propojení Axisu do univerzálního prostředá Eclipse,

konkrétně zatím generování .java souborů z WSDL protokolu. Autoři slibují širší funkcionalitu, ale projekt momentálně není příliš živoucí.

Implementace UDDI

jUDDI (ws.apache.org/juddi)Podporuje: UDDI 2.0Dalším projekterm konsorcia Apache je jUDDI. Jde vlastně o UDDI server, tedy aplikaci,

která umožňuje ukládat a vyhledávat data o webovských službách prostřednictvím protokolu UDDI. Ke svému provozu potřebuje jUDDI nějaký databázový stroj, přičemž podporována je široká

škála možností počínaje MySQL, přes PostgreSQL a HSQLdb, až po Oracle či DB2, ad. a aplikační server, který podporuje specifikaci Servlet 2.3 (např. Apache Tomcat a komp.).

Instalace jUDDI je sice relativně snadná, ale díky absenci jakéhokoliv instalačního skriptu rozhodně nikterak pohodlná. Na druhou stranu nutno uznat, že UDDI server není žádná masová aplikace a když už se jej někdo rozhodne implementovat, dá se očekávat, že k tomu bude mít potřebné znalosti.

jUDDI má i vnitřní podporu autentizace (v UDDI 2.0 ještě není podchycena standardem a proto má každá implementace vlastní řešení – jUDDI však umožňuje i autentizaci na úrovni serveru), záznam do logů a další vlastnosti.

Na dobré úrovni hodnotím vývojářskou dokumentaci, která je poskytována v tradiční podobě JavaDocu.

UDDI4j (www-124.ibm.com/developerworks/oss/uddi4j)Podporuje: UDDI 2.0UDDI4j je javovská knihovna pro zpřístupnění služby UDDI na straně klienta. Jde o open

sourcový projekt, který je vyvíjen „pod křídly“ IBM a HP. Je zdarma dostupná na základě IBM Public License.

V knihovně jsou zastoupeny třídy a metody, které umožňují vkládání, měnění, mazání a vyhledávání všech typů záznamů podle specifikace UDDI 2.0 v serverech UDDI. Vzhledem k tomu, že – jak bylo uvedeno v kapitole „Architektura webových služeb – UDDI komunikuje s registrem UDDI prostřednictvím protokolu SOAP, pro využití knihovny UDDI4j je třeba vložit do aplikace i nějakou implementaci tohoto protokolu, např. Axis, Apache SOAP, aj.

Je nutno pochválit dokumentaci tohoto software, která mi připadala poměrně obsáhlá a přehledná, daleko lepší, než např. u jUDDI. Je ale jasné, že tyto produkty lze těžko srovnávat, neboť UDDI4j má daleko širší potenciální uživatelskou základnu.

UDDI server in Java (soapuddi.sourceforge.net)Podporuje: UDDI 2.0UDDI server in Java (dříve SOAP UDDI) je o open sourcový produkt UDDI serveru, který

jeho autoři zamýšlejí především pro potřeby vývoje a testování.Ke svému provozu potřebuje podobně jako např. jUDDI databázový stroj (rozumí si s MS

Accessem, MS SQL, PostreSQL a Sybase) a aplikační server – např. Apache Tomcat.Instalační dokumentace je opět poměrně slabá, ale i zde platí, že je to produkt pro odborníky,

nikoliv pro laiky.UDDI server in Java nepodporuje sám o sobě autentizaci – tu lze zajistit na úrovni aplikačního

serveru na bázi protokolu SOAP pomocí Apache modulu mod_soap_auth a tato varianta je v dokumentaci poměrně dobře popsána. Dále není podporována replikace a synchronizace dat mezi různými servery, ale autoři s ní do budoucna počítají (tato vlastnost je teprve ve standardu UDDI 3.0) –v současnosti ji však nenabízí ani „konkurenční“ jUDDI.

Vývojářská dokumentace v podobě, jakou ji nabízí jUDDI zde schází.

39/47

Ostatní

WSIF (ws.apache.org/wsif)Implementace WSIFu má podobu javovské knihovny, která se dá připojit k vytvářenému

software a prostřednictvím které lze uskutečňovat jednotlivá volání. Vlastní komunikaci v jednotlivých formátech zajišťují tzv. providery, kdy každý provider zajišťuje komunikaci s tou kterou službou. Existuje tedy např. provider pro EJB, SOAP, JMS, atd.

WSIF je podle mého soudu zajímavý software, který může být užitečný zejména tam, kde existuje množství různých ne zcela dobře integrovaných aplikací. Na webu je podpořen velmi kvalitní a přehlednou dokumentací s množstvím příkladů.

Uživatel webových služebDíky univerzálnosti a multiplatformitě webových služeb lze klientský software, který by

využíval webové služby, napsat v nepřeberné řadě nástrojů a jazyků. Od jednoduchých klientů napsaných ve skriptovacích jazycích Perl či PHP, přes aplikace běžící na aplikačním serveru s Javou či .NET až k plnohodnotným aplikacím napsaným v C++ běžícím pod systémem Windows, Linux a dalšími. Vývojové nástroje tedy budou v tomto případě minimálně stejně různorodé jako v případě vývoje serverové části aplikace – koneckonců většina výše zmíněných vývojových nástrojů umožňuje vývoj jak aplikací na straně serveru, tak na straně klienta.

Velmi důležité – a z hlediska rozšíření webových služeb asi klíčové – je to, že webové služby nevyžadují instalaci žádných dalších speciálních softwarů a rozhraní – stačí pouhé internetové připojení. Jejich implementace na straně klienta tedy může být velmi snadná a nenáročná na technickou podporu, čímž se liší od jiných dřívějších standardů, jako např. CORBA.

40/47

Případové studie – provozovaná řešení

InfoMapServicesVtipným použitím principů a technologie webových služeb je služba InfoMapServices

společnosti PJSoft. PJSoft je producent geografických informačních systémů (GIS) a mezi jeho neznámější produkty patří InfoMapa – geografický software umožňující zobrazování a vyhledávání v mapách, hledání nejkratších cest, apod.

InfoMapServices je webová služba pracující s technologií vyvinutou pro InfoMapu a přenášející její funkcionalitu skrze technologii webových služeb do prostředí WWW. Služba není zanesena v registru UDDI, potřebné informace o ní nalezne zájemce na webu společnosti PJSoft na adrese http://www.pjsoft.cz/dig_mapy3.html; případně na adrese http://www.infomapservices.cz/ je dostupný velmi podrobný popis jednotlivých funkcí a to jak v textové podobě, tak v podobě rozhraní definovaného WSDL souborem.

Celá aplikace běží podle dokumentace na IIS 5.0 a je naprogramována na platformě .NET Framework v jazyku C# společnosti Microsoft.

Princip funkce služby je poměrně jednoduchý: klient vyvolá příslušnou funkci rozhraní getMapOfAreal s parametry jako jsou rozměry mapy, koordináty, měřítko a mnohé další a funkce příslušnou mapu vygeneruje. Pomocí funkce getImageData si poté klientský software vyžádá výsledky zpracování dotazu v podobě obrázku s příslušným výřezem mapy. Rozhraní nabízí další funkce, které umožní vložit do výřezu na příslušné místo např. logo, výřez posouvat, atd.

Webovou službu InfoMapServices využívá například společnost Seznam a.s., který jí poskytuje v rámci své služby http://www.mapy.cz nebo společnost Český mobil a.s., která ji zakomponovala do své služby OskarKompas.

Amazon.comAmazon.com, největší světové internetové knihkupectví s obratem kolem 3,9 mld. USD a

7500 zaměstnanci, využívá webové služby pro integraci dodavatelů do svého obchodního řetězce (15,16). Společnost Amazon již dávno neprodává pouze knihy, ale rozšířila své obchodní portfolio o celou řadu produktů, které jí dodává mnoho dodavatelů, vč. malých. Zároveň firma nabídla svůj prodejní kanál velkým značkovým prodejcům, kteří neměli dostatečně kvalitní vlastní technologii. Aby bylo možno efektivně spravovat procesy spojené s komunikací s těmito dodavateli, objednáváním zboží, fakturací a dalšími obchodními činnostmi, bylo nutné tyto postupy automatizovat. Amazon to vyřešil napojením jednotlivých dodavatelů v rámci tzv. Advantage Programu na svůj systém.

Dodavatelé posílají prostřednictvím webové služby Amazonu informace o svých nových titulech, díky čemuž se do systému Amazonu zakládají data automaticky ve standardizované podobě. To samozřejmě výrazně šetří náklady na správu databáze, neboť odpadá ruční přepisování informací nebo jejich reformátování. Díky využití webových služeb mohou dodavatelé tato data posílat přímo ze svých informačních systémů (pokud tuto technologii podporují) a tím jsou úspory realizovány i na jejich straně. Systém neustále monitoruje stav zásob na skladě a pokud zásoba klesne pod určitou úroveň, automaticky je doobjedná. Dále jsou přes webové služby komunikována data o platbách a potvrzení úhrad. Do budoucna se plánuje, že obchodní partneři Amazonu budou moci využívat funkcí jeho infrastruktury ve svých vlastních webech.

Díky využití webových služeb nezáleží na tom, zda dodavatel ve svém vlastním systému používá řešení postavené na architektuře .NET, J2EE či jakékoliv jiné. Pokud dodavatelé webové služby implementovány nemají, je jejich implementace levnější, než případná implementace komunikačních technologií využívajících proprietálních formátů.

K zajištění těchto služeb je využit server Java Server společnosti Systinet. Vzhledem k tomu, že Amazon tradičně používá řešení Linux/Apache, byl nasazen server ve verzi C++. Tento software byl podle (16) vybrán především díky podpoře nejnovějších komunikačních protokolů SOAP (vč. SOAP s přílohami v MIME a DIME, SOAP 1.2 s podporou asynchronních webových služeb na straně klienta i serveru, ad.). Server podporuje autorizaci a autentifikaci SSL a autentifikaci prostřednictvím HTTP.

41/47

http://www.mapy.cz/

http://www.infomapservices.cz/

http://www.pjsoft.cz/dig_mapy3.html

Jednotliví obchodní partneři jsou propojeni a komunikují skrze webové služby. Tím mohou nejen sdílet obchodní data, ale i využívat technologie Amazonu i pro svůj vlastní business. Schéma na obr. 7 znázorňuje, že díky nasazení webových služeb mohou mezi jednotlivými partnery probíhat informace o produktech, objednávkách a platbách, obchodní partneři mohou mít nabídku Amazonu na svých webech a naopak jiní maloobchodníci mají šanci své produkty prodávat na stránkách Amazonu. Přitom nezáleží na tom, jakou technologii používají, multiplatformní prostředí webových služeb a jejich otevřené standardy zajistí transparentnost.

42/47

Obr 8 – schéma komunikace Amazonu s obchodními partnery prostřednictvím webových služeb – převzato od společnosti Amazon.com

ZávěrWebové služby jsou relativní novinkou v oblasti internetových technologií. Zdá se však, že

mohou nabídnout zajímavou funkcionalitu a rozšířit tak výrazně současný potenciál služeb, které jsou internetem a na internetu nabízeny.

V první části práce jsme si podrobně rozebrali strukturu webových služeb, zjistili jsme, že se skládají ze služby SOAP, která zajišťuje vlastní komunikaci mezi klientem a serverem webové služby, služby WSDL, která poskytuje popis rozhraní webové služby a služby UDDI, která slouží k vyhledávání webových služeb. Všechny tyto formáty jsou otevřené, což umožňuje nasazení technologie webových služeb na široké škále platforem s využitím celého spektra programovacích jazyků a především výrazně snižuje náklady na vývoj a provoz takových služeb.

Technologie UDDI umožňuje vyhledat na internetu dodavatele webové služby podle nejrůznějších kritérií a získat odkaz na rozhraní této služby tak, aby ji bylo možno snadno implementovat do aplikace. Budoucí vývoj této služby bude spět k širšímu zakomponování obchodních kritérií do této technologie a tím k lepšímu propojení s elektronickými tržišti a vyhledávacími portály, kterým může dodat novou funkcionalitu, neboť obsahuje a umí vyhledávat a poskytovat informace ve strukturované a automaticky zpracovatelné podobě.

Na trhu existuje v dnešní podobě pestrá nabídka software pro podporu provozu a vývoje webových služeb. Díky své mutiplatformnosti lze webové služby provozovat bez ohledu na technické řešení, použitý HW, operační systém a programovací jazyk. Pro všechny varianty řešení existuje škála nástrojů pro všechny typy zákazníků počínaje opensourcovými technologiemi dostupnými zdarma každému až po špičkové nákladné komerční softwary pro nejnáročnější zákazníky. Výhodou je, že i při takto široké diverzitě použitelných technických prostředků zůstávají webové služby vzájemně kompatibilní a široce dostupné, což posiluje jejich pozici na trhu.

Konečně jsme si na dvou případových studiích demonstrovali dva případy konkrétního nasazení webových služeb v hospodářské praxi a tím jsme dokázali, že webové služby nejsou pouze předmětem akademických diskusí nebo technickou hříčkou, ale staly se prostředkem reálného ekonomického využití.

To vše znamená, že webové služby jsou zavedenou technologií internetu, jejíž možnosti využití jsou velmi široké a která může svým uživatelům přinášet skutečnou přidanou hodnotu. Domnívám se, že webové služby mají budoucnost a že jde o technologii, která způsobí podstatnou změnu ve fungování a vnímání toho, co si představujeme pod pojmem internet.

43/47

Základní pojmy

.NET komponentová technologie společnosti Microsoft, nástupce ASP, přímý konkurent J2EE. Umožňuje vytváření standardních aplikací, stejně jako dynamických webových stránek a webových služeb.

ASP Active Server Pages – skriptovací technologie společnosti Microsoft pro vytváření dynamického obsahu webů. Konkurece technologii JSP, popř. PHP.

CORBA Common Object Request Broker Architecture – otevřená architektura a infrastruktura, která umožňuje softwarovým aplikacím komunikovat skrze síť.

DCOM Distributed Component Object Model – protokol, který umožňuje softwarovým komponentám komunikovat přímo skrze síť spolehlivým, bezpečným a efektivním způsobem.

extranet síť založená na internetových technologiích, která spojuje organizaci se svými partnery nebo umožňuje pracovníkům firmy přistupovat k interním informačním zdrojům firmy zvenčí

GIS Geografický informační systém – zpravidla systém pracující s geografickými mapami a umožňující nad nimi aplikovat některé pokročilé funkce, jako je např. vyhledávání či určení nejkratší cesty.

GPL General Public License – všeobecná licence používaná pro distribuování volně šiřitelného software – vymezuje, že software může být libovolně šířen a upravován, ale všechny budoucí verze musí být rovněž šířeny podle GPL

HTML Hypertext Markup Language – nejrozšířenější hypertextový jazyk používaný k vytváření webových stránek

HTTP Hypertext Transfer Protocol – protokol určený pro přenášení souborů HTML na síti WWW. Časem došlo k jeho mnoha vylepšením (obousměrná komunikace, šifrování), takže v současné době jde o jeden z nejrozšířenějších internetových standardů. Standardně funguje na TCP portu 80.

intranet vnitřní podnikový informační systém založený na internetových technologiích

JAX-RPC Java API for XML-Based RPC – standard pro zajištění kompatibility webových služeb napříč platformami. Obsahuje programový model pro vývoj klientských a serverových aplikací založených na SOAPu, mapování mezi WSDL a Javou, atd.

J2EE komponentově založená technologie firmy Sun pracující na bázi jazyka Java určená pro vývoj enterprise aplikací.

JSP Java Server Pages - – skriptovací technologie společnosti Sun pro vytváření dynamického obsahu webů pracující s jazykem Java. Konkurence technologie ASP, popř. PHP.

konektivita schopnost informačních technologií přenášet data; veličina udávající kapacitu průtoku dat

outsourcing vytěsnění některých vedlejších podnikových činností mimo podnik a jejich zajištění externím dodavatelem

RPC Remote procedure call – vzdálené volání metod. Síťová infrastruktura typu client/server, která umožňuje vzdálené volání funkcí aplikací a tím vytváření distribuovaných systémů.

SAAJ Sun SOAP with Attachments API for Java – standard pro odesílání a přijímání XML dokumentů po internetu na platformě Java

SOAP protokol postavený na bázi XML určený k posílání zpráv ke spouštění a ovládání funkcí na vzdálených serverech. Jedna

44/47

z nejdůležitějších technologií pro webové služby.TCO Total Cost of Ownership – celkové náklady vlastnictví software,

zahrnující pořizovací cenu, náklady na obsluhu, hardwarové náklady, atd.

TCP/IP rodina základních protokolů internetu zprostředkovávající komunikaci mezi různými body v síti. Pod tímto označením se zpravidla skrývají protokoly: IP, TCP, UDP a ICMP.

tModel zvláštní entita v rámci protokolu UDDI, která vyjadřuje shodu určitých vlastností jiných entit. Používá se jednak k definování skupiny webových služeb, které mají společnou část komunikačního rozhraní (a tím odpovídají zhruba tomu, čím je v Javě interface) a dále se používá k přiřazení jistého klíče entitě v rámci určité kategorie vlastností.

UBR UDDI Business Registry – síť serverů provozovaných v současnosti společnostmi IBM, Microsoft, SAP, Ariba a NTT Communications, která poskytuje informace o firmách a jejich webových službách a to prostřednictvím protokolu UDDI.

UUID Universal Description, Discovery and Integration – služba na internetu, která umožňuje vyhledávat webové služby na internetu podle celé škály kritérií. Vzhledem k tomu, že je postavena nad jazykem XML, dokáže vracet data ve strukturované a automaticky zpracovatelné podobě.

W3C World Wide Web Consortium – mezinárodní fórum, které vytváří standardy technologií pro síťovou komunikaci.

WAP Wireless access protocol – rodina protokolů, která byla zamýšlena jako obdoba HTML/HTTP pro mobilní zařízení. Dosud však z ekonomických i technických důvodů nedošlo k jeho tak masovému rozšíření, aby to bylo srovnatelé s jinými internetovými technologiemi. Mnoho autorů soudí, že k tomu již ani nedojde.

webové služby Internetová technologie, která umožňuje spouštět metody (funkce) objektů na vzdálených počítačích, posílat jim parametry a získávat zpět zpracované údaje. Díky tomu je široce využitelná pro budování distribuovaných systémů a sdílení funkcionality mezi různými aplikacemi na internetu.

WSDL Web Services Description Language – metajazyk pro popis komunikačních rozhraní webových služeb, který tak umožňuje jejich automatizované využití

XML eXtensible Markup Language – jednoduchý flexibilní formát odvozený od SGML umožňující efektivní výměnu strukturovaných dat.

45/47

Seznam použitých informačních zdrojů

(1) Modi T., Clean up your wire protocol with SOAP, http://www.javaworld.net/javaworld/jw-03-2001/jw-0330-soap.html

(2) Microsoft, Web Service Basics, http://msdn.microsoft.com/webservices/understanding/webservicebasics/default.aspx

(3) Skonnard A., Understanding SOAP, http://msdn.microsoft.com/webservices/understanding/webservicebasics/default.aspx?pull=/library/en-us//dnsoap/html/understandsoap.asp

(4) Box D., Ehnebuske D., Kakivaya G., Layman A., Mendelsohn N., Nielsen H.F., Thatte S., Winer D., Simple Object Access Protocol (SOAP) 1.1, http://www.w3.org/TR/2000/NOTE-SOAP-20000508

(5) Vasudevan V., A Web Services Primer, http://webservices.xml.com/pub/a/ws/2001/04/04/webservices/index.html?page=2#wsdl

(6) Refsnes Data, WSDL Documents, http://www.w3schools.com/wsdl/wsdl_documents.asp(7) Christensen E., Curbera F., Meredith G., Weerawarana S., Web Services Description

Language (WSDL) 1.1, http://www.w3.org/TR/wsdl(8) UDDI.org – UDDI Technical white paper,

http://www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf(9) UDDI.org – The Stencil Group, The Evolution of UDDI,

http://www.uddi.org/pubs/the_evolution_of_uddi_20020719.pdf(10) Kosek J., Inteligentní podpora navigace na WWW s využitím XML, diplomová práce

VŠE, http://www.kosek.cz/diplomka/html/dp.html#pic.komunikace-wasp-8(11) Ogbuji U., Using WSDL in SOAP applications,

http://www-106.ibm.com/developerworks/webservices/library/ws-soap/?dwzone=ws(12) Boubez T., Clément L., UDDI tModels – Classification Schemes, Taxonomies, Identifier

Systems, and Relationships, Version 2.04, http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm

(13) Microsoft, Introduction to UDDI services, http://isb.oio.dk/UDDI/help/1033/intro.whatisuddi.aspx#instance

(14) Song W., Semantic Web Applications, http://www.db.pku.edu.cn/sw/sw-course-pku-web%5Csw-8app.pdf

(15) Wagner J., Amazon Brings Web Services to its Vendors, http://www.internetnews.com/ec-news/article.php/3077221

(16) Systinet, Amazon Powers Merchant Network Using Systinet Web Services – case study, Systinet 2003, http://www.systinet.com/download&file=cs_Systinet_amazon.pdf

(17) Borland, Borland JBuilder 2005 Feature Matrix, Borland 2004, http://www.borland.com/jbuilder/pdf/jb2005_feature_matrix.pdf

(18) Sybase, Comparing Sybase PowerBuilder and Microsoft .NET, Sybase 2004, http://www.sybase.com/content/1029995/Comparing_PB_and_MS_wp.pdf

(19) TheServerSide, TheServerSide Application Server Matrix, http://www.theserverside.com/reviews/matrix.tss

(20) Mitra, N. (ed.), SOAP Version 1.2 Part 0: Primer, W3C Recommendation 2003, http://www.w3.org/TR/2003/REC-soap12-part0-20030624/

(21) Blanchard, E. Introduction to Networking and Data Communications. 2001. https://secure.linuxports.com/howto/intro_to_networking/c4412.htm

(22) Internet Assigned Numbers Authority. MIME Media Types. http://www.iana.org/assignments/media-types/

(23) Bisson, S. Cleaning up with SOAP. http://www.sandm.co.uk/simon/comjourns/Columns/Introducing_SOAP/introducing_soap.html

(24) Christensen, E. Curbera, F. Meredith, G. Weerawarana, S. Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/2001/NOTE-wsdl-20010315

46/47

http://www.w3.org/TR/2001/NOTE-wsdl-20010315

http://www.sandm.co.uk/simon/comjourns/Columns/Introducing_SOAP/introducing_soap.html

http://www.sandm.co.uk/simon/comjourns/Columns/Introducing_SOAP/introducing_soap.html

http://www.iana.org/assignments/media-types/

https://secure.linuxports.com/howto/intro_to_networking/c4412.htm

http://www.w3.org/TR/2003/REC-soap12-part0-20030624/

http://www.theserverside.com/reviews/matrix.tss

http://www.sybase.com/content/1029995/Comparing_PB_and_MS_wp.pdf

http://www.borland.com/jbuilder/pdf/jb2005_feature_matrix.pdf

http://www.systinet.com/download&file=cs_Systinet_amazon.pdf

http://www.internetnews.com/ec-news/article.php/3077221

http://www.internetnews.com/ec-news/article.php/3077221

http://www.db.pku.edu.cn/sw/sw-course-pku-web%5Csw-8app.pdf

http://www.db.pku.edu.cn/sw/sw-course-pku-web%5Csw-8app.pdf

http://isb.oio.dk/UDDI/help/1033/intro.whatisuddi.aspx#instance

http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm

http://www-106.ibm.com/developerworks/webservices/library/ws-soap/?dwzone=ws

http://www.kosek.cz/diplomka/html/dp.html#pic.komunikace-wasp-8

http://www.uddi.org/pubs/the_evolution_of_uddi_20020719.pdf

http://www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf

http://www.w3.org/TR/wsdl

http://www.w3schools.com/wsdl/wsdl_documents.asp

http://webservices.xml.com/pub/a/ws/2001/04/04/webservices/index.html?page=2#wsdl

http://www.w3.org/TR/2000/NOTE-SOAP-20000508

http://msdn.microsoft.com/webservices/understanding/webservicebasics/default.aspx?pull=/library/en-us//dnsoap/html/understandsoap.asp

http://msdn.microsoft.com/webservices/understanding/webservicebasics/default.aspx?pull=/library/en-us//dnsoap/html/understandsoap.asp

http://msdn.microsoft.com/webservices/understanding/webservicebasics/default.aspx

http://www.javaworld.net/javaworld/jw-03-2001/jw-0330-soap.html

(25) Chinnici, R. Gudgin, M. Moreau, J. Schlimmer, J. Weerawarana, S. Web Services Description Language (WSDL) Version 2.0. http://www.w3.org/TR/wsdl20/

(26) Booth, D. Liu, C.K. Web Services Description Language (WSDL) Version 2.0 Part 0: Primer, http://www.w3.org/2002/ws/desc/wsdl20-primer

(27) Haas, H. Le Hégaret, P. Moreau, J..Orchard, D. Schlimmer, J. Weerawarana, S. Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings, http://www.w3.org/TR/wsdl20-bindings

(28) Orchard, D. WS-Addressing and WS-MessageDelivery, http://www.pacificspirit.com/blog/2004/07/29/ws-addressing%20ws-messagedelivery%20comparison

(29) Kaler, Ch. (ed.). Specification: Web Services Security (WS-Security). http://www.ibm.com/developerworks/webservices/library/ws-secure/

47/47

http://www.ibm.com/developerworks/webservices/library/ws-secure/

http://www.pacificspirit.com/blog/2004/07/29/ws-addressing%20ws-messagedelivery%20comparison

http://www.pacificspirit.com/blog/2004/07/29/ws-addressing%20ws-messagedelivery%20comparison

http://www.w3.org/TR/wsdl20-bindings

http://www.w3.org/2002/ws/desc/wsdl20-primer

http://www.w3.org/TR/wsdl20/

Date post:	18-Nov-2014
Category:	Documents
Upload:	tomas-salamon
View:	106 times
Download:	1 times