Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Katedra informačních technologií
Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie
Diplomant: Bc. David Maleček
Vedoucí diplomové práce: Ing. Libor Gála Recenzent:
TRH WEB SERVICES V ČR
školní rok 2006/2007
Prohlášení
Prohlašuji, že jsem diplomovou práci zpracoval(a) samostatně a že jsem uvedl(a) všechny použité prameny a literaturu, ze kterých jsem čerpal(a).
V Praze dne 3.5.2007
……….
podpis
Pod ě kování
Na tomto místě bych chtěl poděkovat vedoucímu mé diplomové práce Ing. Liboru Gálovi za trpělivost, ochotu, cenné rady a odborné vedení při zpracování diplomové práce.
Abstrakt
Cílem této diplomové práce je popsat trh webových služeb v České republice a poskytnout přehled předních dodavatelů a jejich produktů. Práce je rozdělena na tři hlavní části, které jsou dále členěny do jednotlivých kapitol.
První část je věnována vymezení pozice a úlohy webových služeb v rámci celého IS/ICT.
Popisuji zde hlavní oblasti uplatnění této technologie. Zároveň se věnuji jejím výhodám a vlastnostem. Ve druhé části se zabývám dvěma pohledy na webové služby – pohledem vývojáře a pohledem architekta IS. Zde také čtenáře seznamuji s jednotlivými standardy, na kterých jsou webové služby založeny (SOAP, WSDL, UDDI). Třetí část je zaměřena na přehled předních dodavatelů webových služeb a jejich produktů. Součástí je také přehled některých implementací webových služeb v ČR a softwarových firem, které tyto implementace zajišťují. Také zde popisuji úroveň podpory webových služeb v ERP systémech dostupných na současném českém trhu. Následuje zhodnocení situace na trhu webových služeb.
Při psaní této práce jsem se opíral jednak o vlastní znalosti a jednak o odbornou literaturu a zdroje na Internetu.
Abstract
The purpose of this diploma thesis is to describe a market of web services in the Czech Republic and to provide a survey of major vendors and their products. The thesis is divided into three main parts, which are subdivided into particular chapters.
First part is attended to determination of position and role of web services within IS/ICT. I describe here main scopes of use of this technology. Herewith I attend to advantages and features of web services. In second part is concerned with two perspectives of web services – a developer’s perspective and an architect’s perspective. I also make readers acquainted with particular standards, which are web services based on, like SOAP, WSDL and UDDI. Third part is focused on the survey of major vendors and their products. I also attend to survey of any implementations of web services in the Czech Republic and software companies, which provide these implementations. I also describe the level of support of web services in ERP systems in the Czech market. Evaluation of present situation in a market of web services follows.
In the course of writing this diploma thesis I used my knowledge, technical literature and sources on the Internet.
1. Úvod ... 9
1.1. Předmět zkoumání diplomové práce ... 9
1.2. Cíle diplomové práce ... 9
1.3. Struktura práce a postup řešení ... 10
2. Místo WS v IS/ICT ... 11
2.1. Co je webová služba a proč je to „služba“ ... 11
2.2. Místo webových služeb v IS/ICT... 13
2.3. Požadavky na A2A komunikaci ... 14
2.4. Scénáře využití webových služeb v praxi ... 16
2.5. Enterprise Application Integration (EAI)... 16
2.5.1. Důvody pro integraci... 17
2.5.2. Technologie pro integraci... 18
2.5.3. Způsoby integrace ... 18
2.5.4. Integrace pomocí webových služeb ... 19
2.5.5. Způsoby napojení webových služeb na legacy systémy ... 20
2.6. Business-to-Business (B2B)... 21
2.7. Common Services ... 21
2.8. Interní versus externí webové služby ... 22
2.8.1. Interní webové služby ... 23
2.8.2. Externí webové služby ... 23
3. Hodnocení WS z pohledu vývojáře... 25
3.1. Webové služby pod drobnohledem ... 25
3.1.1. Protokol SOAP ... 25
3.1.2. WSDL... 27
3.1.3. UDDI ... 29
3.1.4. Veřejné UDDI registry ... 30
3.1.5. Soukromé (privátní) UDDI registry ... 30
3.1.6. Sdílené (semi-privátní) UDDI Registry ... 30
3.1.7. Vztah SOAP, WSDL, UDDI a webových služeb ... 31
3.1.8. DISCO ... 32
3.2. Vývojář a standardy WS ... 32
3.3. Vývojové nástroje s podporou WS... 32
3.4. Dostatek a kvalita využitelných webových služeb... 33
4. Hodnocení WS z pohledu architekta ... 35
4.1. Webové služby pod drobnohledem z pohledu architekta... 35
4.2. Zralost WS... 35
4.2.1. Bezpečnost ... 36
4.2.2. WS-* džungle ... 36
4.2.3. Interoperabilita WS a WS-I.org ... 37
4.3. Otázka billingu – placení za WS ... 37
4.3.1. Důvod placení za webové služby ... 37
4.3.2. Způsoby účtování za použití WS ... 38
4.4. Service Level Agreement a WS ... 39
4.4.1. Vysvětlení pojmu SLA... 39
4.4.2. Obsah SLA ... 40
4.4.3. Jazyk WSLA a WSLA dokument ... 42
4.5. Monitorování WS ... 42
4.5.1. Způsob monitorování WS ... 43
4.5.2. Metriky WS ... 43
4.6. Propojování (orchestrace) WS... 44
5. Stav trhu WS, nástrojů a hotových služeb, úroveň podpory v softwarových balících. 45 5.1. Trh webových služeb ... 45
5.2. Postup ... 45
5.3. UDDI ... 47
5.3.1. UBR registry (veřejné UDDI registry)... 47
5.3.2. Privátní a semi-privátní UDDI registry ... 48
5.4. Alternativní vyhledávače webových služeb ... 51
5.5. Příklady některých dalších veřejně dostupných webových služeb ... 54
5.6. Nástroje pro orchestraci WS ... 56
5.7. Vývojové nástroje s podporou WS... 58
5.8. Nástroje pro management a dohledování (monitoring) WS... 59
5.9. Nástroje pro testování WS a SOA... 61
5.10. Nástroje pro zajištění bezpečnosti WS... 62
5.11. Aplikační servery podporující WS ... 63
5.12. ESB (Enterprise Service Bus) ... 65
5.13. Další produkty ... 66
5.14. Příklady implementací webových služeb v ČR (implementace IS založených na WS) 67 5.15. Úroveň podpory v softwarových balících ... 70
5.16. Zhodnocení trhu WS v oblasti podnikových řešení ... 72
6. Závěr... 74
6.1. Shrnutí hlavních myšlenek diplomové práce ... 74
6.2. Splnění cílů... 76
7. Použité zdroje ... 77
8. Terminologický slovník ... 80
9. Příloha – Podpora WS v ERP systémech ... 81
1. Úvod
1.1. P ř edm ě t zkoumání diplomové práce
Stále větším požadavkem současného světa informačních technologií je nutnost komunikace mezi různorodými informačními systémy. Až doposud nebyl definován široce použitelný a flexibilní standard pro výměnu dat (pomineme-li např. EDI (Electonic Data Interchange) nebo robustní a těžkopádné technologie CORBA či DCOM). Komunikační problémy se tedy často řešily úzce specializovaným proprietárním softwarem a různými ad hoc řešeními.
S příchodem technologie webových služeb však komunikace mezi aplikacemi dostává nový rozměr. Webové služby představují další etapu vývoje distribuovaných informačních systémů a jsou založeny na otevřených a nezávislých standardech. Tím umožňují vzájemnou komunikaci aplikací postavených na různých platformách a programovacích jazycích.
V současné době je technologie webových služeb v popředí zájmu předních dodavatelů na světovém i českém trhu IS. Pojem webových služeb je skloňován ve všech pádech a mnoho IT odborníků v ni vkládá veliké naděje. To, nakolik tato technologie uspěje, ukáže až čas.
Avšak už dnes lze říci, že se jedná o přelomovou technologii v oblasti distribuovaných informačních systémů.
Název mé diplomové práce je „Trh web services v ČR“. Toto téma jsem si vybral z toho důvodu, že mě technologie webových služeb zajímala a chtěl jsem se o ní více dozvědět.
Osobně se sice jejich programováním nezabývám, ale už jsem se s nimi v praxi setkal a předpokládám, že díky nasazování této technologie v čím dál širším měřítku, se s nimi budu setkávat i nadále.
1.2. Cíle diplomové práce
Cílem mé diplomové práce je, jak vyplývá z názvu, popsat trh webových služeb v České republice. Provedu přehled předních poskytovatelů webových služeb a jejich produktů. Přehled budu provádět formou rešerše. Při rešerši využiji jednak vlastních znalostí a jednak různých zdrojů – zejména se bude jednat o odborné časopisy,WWW stránky odborných časopisů, internetové diskuse, elektronický informační zdroj ProQuest a v neposlední řadě WWW stránky samotných výrobců.
Jednotlivé typy produktů rozdělím do kategorií a v každé z nich pak vytvořím seznam produktů, jejich výrobců a prodejců v ČR. Nakonec zhodnotím současnou situaci celosvětového i českého trhu s webovými službami.
Dále si kladu následující dílčí cíle – vymezit místo webových služeb v IS/ICT, popsat webové služby z pohledu architekta IS, popsat webové služby z pohledu vývojáře a pokusit se odhadnout další směr vývoje této technologie.
Tato práce se nezabývá porovnáním jednotlivých produktů, které zde budu jmenovat.
1.3. Struktura práce a postup ř ešení
Diplomová práce je rozdělena na tři hlavní části, které jsou dále členěny do jednotlivých kapitol dle popisované problematiky. Dělení diplomové práce souvisí s vytýčenými cíly.
První část, „Místo WS v IS/ICT“, věnuji vymezení pozice a úlohy webových služeb v rámci celého IS/ICT. Popíši hlavní oblasti uplatnění této technologie. Zároveň se budu věnovat jejím výhodám a vlastnostem.
Ve druhé části se budu věnovat dvěma pohledům na webové služby – pohledu architekta IS a pohledu vývojáře. V kapitole „Pohled vývojáře na WS“ čtenáře seznámím s jednotlivými standardy, na kterých jsou webové služby založeny (SOAP, WSDL, UDDI).
Třetí část již budu věnovat přehledu předních dodavatelů trhu webových služeb a jejich produktů. Součástí bude také přehled některých implementací webových služeb v ČR a softwarových firem, které tyto implementace zajišťují. Také se zaměřím na úroveň podpory webových služeb v ERP systémech dostupných na současném českém trhu. Následně situaci na trhu WS zhodnotím. Také bych rád posoudil, jaké je v současné době postavení webových služeb na trhu IS/ICT, kde je jejich potenciál a uplatnění a nakonec bych se pokusil odhadnout další směr vývoje této technologie.
Pro dosažení vytýčených cílů jsem prostudoval velké množství zdrojů, jak tištěných tak elektronických (viz kapitolu Zdroje). Analýzu trhu jsem prováděl na základě článků odborných časopisů, WWW prezentací daných firem a vlastní zkušeností.
Tato diplomová práce je určena všem, koho zajímá problematika webových služeb, bez ohledu na to, zda tuto technologii již znají či nikoliv.
2. Místo WS v IS/ICT
2.1. Co je webová služba a pro č je to „služba“
[1, 2]Pojem „web services“, česky také nazývané „webové služby“, je v současné době velmi používaný. Odhlédneme-li od veškerého marketingového halasu, jímž nás přední poskytovatelé různých řešení postavených na webových službách zahlcují, a podíváme-li se na webové služby podrobněji, zjistíme, že se skutečně jedná o užitečnou technologii.
„Webová služba je softwarová aplikace identifikovaná prostřednictvím URI, jejíž rozhraní a vazby je možno definovat, popsat a vyhledávat jako artefakty XML. Podporuje přímou interakci s jinými softwarovými aplikacemi prostřednictvím zpráv zapsaných v jazyce XML a přenášených protokoly internetu.“1 Webové služby se svou podstatou podobají modelům aplikací založených na komponentách, kdy jsou tyto aplikace sestavené z malých stavebních prvků – jednotlivých komponent. V případě webových služeb tyto softwarové komponenty dohodnutým způsobem zpřístupňují své vlastnosti v rámci Internetu případně prostřednictvím lokální sítě organizace (popř. v rámci extranetu či VPN v případě mezipodnikové integrace).
Komunikace mezi poskytovatelem služby a žadatelem o službu tak probíhá pomocí osvědčených přenosových protokolů sítě Internet. Transportní vrstvu tedy tvoří některý z protokolů HTTP(S) (nejčastěji), SMTP, FTP, apod. „Termín „služby (service)“ se používá proto, že funkcionalitu aplikace, která má být sdílena jinými aplikacemi, neboli má být aplikacemi využívána, lze vlastně označit za službu jiným aplikacím.“2
Webové služby dále:
• „Užívají XML pro popis svého rozhraní, formulaci požadavků i odpovědí i mechanismus vzájemné komunikace, čímž nejsou vázány na proprietární technologie;
• Nemají mezi sebou těsnou vazbu a poskytují jednoduché mechanismy pro realizaci změn v rozhraní;
• Umožňuje skrýt složitost aplikační oblasti, která může být reprezentována sadou různě provázaných metod, právě jednou službou;“3
1 XML a webové služby; Imrich Buranský; Praha; Microsoft 2003. Dostupné též z url [http://download.microsoft.com/download/8/6/c/86c09926-affc-4e14-bec0-
3c45cd989436/XML_a_webove_sluzby.pdf]
2 Podniková informatika;Libor Gála, Jan Pour, Prokop Toman; Praha; Grada 2006
3 Podniková informatika;Libor Gála, Jan Pour, Prokop Toman; Praha; Grada 2006
Dá se říci, že technologie webových služeb se stále ještě vyvíjí a některé standardy, zejména co se týká bezpečnosti, ještě nejsou úplně vyzrálé (i když v současné době již existují nadstavby webových služeb, které se zabývají oblastmi, jež samotná technologie webových služeb neřeší, a jednou z nich je právě specifikace zabývající se zabezpečením na úrovni protokolu SOAP – viz dále). Na druhou stranu je třeba říci, že je to technologie poměrně jednoduchá, otevřená (tj. založená na standardech W3C, nikoliv na soukromém standardu jedné firmy či sdružení firem) a zcela nezávislá na platformě (operačním systému, typu procesoru či programovacím jazyku). [1]
Technologii webových služeb tvoří tři části: [1, 2]
• protokol pro vzdálené volání procedur a funkcí (výměnu XML zpráv) – SOAP,
• jazyk pro popis rozhraní webových služeb – WSDL,
• mechanismus pro publikaci a vyhledávání služeb – UDDI.
Jednou z klíčových vlastností webových služeb je, že u nich existuje popis rozhraní pomocí specifikace WSDL (Web Service Definition Language). V této specifikaci je přesně stanoveno, jak má být rozhraní služby popsáno a jaké má služba o sobě poskytnout informace.
WSDL je založeno na XML a výsledkem popisu je WSDL dokument.
Veškerá komunikace v rámci WS probíhá prostřednictvím SOAP zpráv (resp. XML bloků), které mají předem definou strukturu. Je možné si je představit jako jakousi obálku, která obsahuje záhlaví a tělo (tj. vlastní obsah zprávy). [2, 4]
2.2. Místo webových služeb v IS/ICT
Účelem této kapitoly je zprostředkovat pohled na místo, které webové služby zaujímají v rámci celého IS/ICT. Jinak řečeno, ukážeme si, jaké jsou možné scénáře využití této technologie.
Abychom lépe pochopili, jaké je jejich místo a potenciál, podíváme se nejprve na následující obrázek. [1]
Obr. č. 1: Potenciál WS v e-business řešení. Převzato z [1] str.3
Jak z obrázku vyplývá, webové služby nalézají své místo jako ideální platforma pro implementace řešení A2A (application-to-application). V dalším obrázku, rovněž převzatém z [1], uvidíme postupný vývoj procesů od tradičního (non-IT), přes H2A (human-to- application) až po na webových službách založeném přístupu A2A.
1) Tradiční nákupní/odběratelský proces (non-IT)
Je vztah
Implementováno pomocí Legenda:
e- business
B2B
B2C H2A
A2A
e- business
Business scénář Technologické řešení
Potenciál WS
ERP PC PC ERP
Nákupčí
člověk člověk
Dodavatel Tel,
fax
2) e-Procurement Portal (H2A)
3) B2B A2A pomocí webových služeb
Obr. č. 2: Vývoj B2B. Převzato z [1] str.4, odst. 1.2 B2B Evolution
V případě použití webových služeb spolu ERP systémy na straně odběratele i dodavatele komunikují přímo pomocí XML přes protokol HTTP. To znamená, že do této komunikace nemusí zasahovat člověk, jako tomu je v přístupu 2), kdy se lidská složka musí zapojit. V tom je právě výhoda formátu XML, kterému stroje rozumí (na rozdíl od HTML).
2.3. Požadavky na A2A komunikaci
V předchozím odstavci jsem objasnil výhody A2A. Nyní si uvedeme nějaké požadavky na řešení, které takovou komunikaci umožní. [1]:
• Automatizace
Abychom mohli hovořit o A2A scénáři, musíme docílit toho, aby libovolné aplikace spolu byly schopny komunikovat bez zásahu člověka. Jde tedy o to, aby mezi sebou byly schopny přímo komunikovat například ERP systém na straně odběratele a ERP systémy na straně dodavatele. Právě webové služby toto zajišťují.
• Propojitelnost heterogenních prostředí
Webové služby umožňují propojit mnoho různých počítačových platforem. Je to vůbec poprvé, co jediná jednoduchá technologie umožňuje přimět mnoho programovacích prostředí jako je J2EE (Java 2 Enterprise Edition), Microsoft .NET, C++, SAP ABAP, Lotus Domino, Perl a další. Stačí aby použitý hardware a operační systém obsahoval podporu HTTP a XML parser.
ERP
ERP
PC
PC
PC
PC
ERP
ERP Nákupčí
Nákupčí člověk
Dodavatel
Dodavatel Internet
HTML/HTTP
Internet XML/HTTP
• Sdílení informací a procesů
A2A pomocí webových služeb umožňuje sdílet jak interní data tak business procesy s obchodními partnery. Příkladem takových dat může být třeba výměna profilů zákazníků či statistiky produkce. Význam sdílení business procesů má v SCM s partnery v dodavatelském řetězci.
• Formální „kontrakt“ mezi rozhraními
Téměř v každém větším podniku vedle sebe funguje několik různých systémů od různých dodavatelů. Ty často běží na různých platformách a to s sebou přináší fakt, že každý z těchto systémů produkuje svůj vlastní datový formát (často proprietární). V případě, že jedna aplikace bude chtít poskytnout data a funkce druhé, musí mezi nimi existovat formální "kontrakt", který popisuje rozhraní dané komponenty. V případě webových služeb se o toto stará WSDL (viz kapitolu WSDL). Protože je založen na formátu XML, je jednodušší než např. definice EDI či proprietární IDL (Interface Definition Language) technologie CORBA.
• Znovupoužití a flexibilita
Znovupoužití je výhoda softwarových komponent obecně. Je to vlastně jejich smyslem. Co se týče flexibility, tak tou se rozumí možnost snadné integrace existujících komponent nezávisle na implementačních detailech. Jednoduše řečeno, jde o to, aby propojení jednotlivých aplikací mohlo být jednoduše měněno v případě změny a vývoje potřeb zákazníků a business procesů. Obě dvě vlastnosti webové služby splňují.
• Business process orchestration (BPO) bez programování
Jedná se o možnost "skládat" sub-procesy nebo aktivity do agregovaných business procesů pomocí modelovacích nástrojů tak, aniž by muselo být cokoliv programováno.
Více se touto záležitostí budu věnovat v oddíle webové služby z pohledu IT architekta.
Jak z předešlých bodů vyplývá, všechny tyto požadavky webové služby splňují. Proto se tato technologie považuje v současné době za ideální integrační A2A technologii.
Kromě obecných požadavků na A2A komunikaci, které webové služby splňují, existují ještě další výhody této technologie:
• Nízký dopad na stávající infrastrukturu
"Aplikace webových služeb nemá téměř žádný dopad na existující IT infrastrukturu. … Není požadován žádný produkt webových služeb, který by musel být koupen, instalován, řízen a udržován.4" Stačí, aby na straně serveru byl nainstalován HTTP server a XML parser. Ty jsou v dnešní době součástí téměř každého serveru.
• Standardizace a otevřenost
Jak již bylo několikrát nastíněno, síla webových služeb spočívá především v použití standardů. Podrobně se jimi budu zabývat v dalších kapitolách.
• Nízká rizikovost projektů
"Webové služby jsou nenákladnou a (téměř) bezrizikovou integrační a komunikační strategií. … XML a HTTP jsou již zavedené technologie, které jsou podniky již ve velké míře využívány.5"
2.4. Scéná ř e využití webových služeb v praxi
Mezi hlavní scénáře využití webových služeb v praxi patří [1]:
• Enterprise Application Integration (EAI)
• Business-to-Business (B2B)
• Common services (CS)
2.5. Enterprise Application Integration (EAI)
„Na podnikatelské aktivity daného podniku je vhodné nahlížet jako na podnikatelské procesy.
Podnikatelský proces (business process) je koordinovaná a logicky uspořádaná posloupnost pracovních činností (aktivit) a odpovídajících zdrojů, která vytváří hodnotu pro zákazníka (procesu) tj. osoba, organizace, další proces.“6 Jednotlivé procesy bývají podporovány IS/ICT. Bez této podpory by těžko mohlo docházet k optimalizaci podnikových procesů. Protože však jednotlivé procesy či jednotlivé části procesů (častěji) bývají zajišťovány různými aplikacemi, může se tak v průběhu života podniku nashromáždit i několik desítek
4 Perspectives on Web services: Applying SOAP, WSDL and UDDI to Real-World Projects; Olaf Zimmermann, Mark Tomlinson, Stefan Peuser; Berlin; Springer 2003
5 Perspectives on Web services: Applying SOAP, WSDL and UDDI to Real-World Projects; Olaf Zimmermann, Mark Tomlinson, Stefan Peuser; Berlin; Springer 2003
6 K integraci aplikací; Jaroslav Jandoš; Praha; Systémová integrace 2004
takových aplikací. „Aplikace jsou typicky vybírány dle jejich funkčnosti, což vede typicky k situaci, kdy podnik využívá několik heterogenních aplikací a problematiku jejich integrace je nutno řešit následně.“7
V dnešní konkurenční době je ze stran vedení firem požadován efektivní a optimalizovaný cyklus vývoje nových IS včetně integrace stávajících IS, většinou od různých dodavatelů, které často běží na různých platformách. Hovoříme zde o vnitropodnikové integraci (Enterprise Application Integration – EAI). Pod pojmem EAI tak rozumíme soubor metodik, technologií a nástrojů, jenž umožňuje jednotlivým heterogenním aplikacím uvnitř podniku komunikovat mezi sebou. [8]
2.5.1. Důvody pro integraci
Existuje mnoho důvodů pro integraci podnikových systémů. „Většina firem, u nichž došlo k výraznému růstu, ať už organizačně nebo akvizicí, zjistí dříve či později, že potřebují jejich původní systémy propojit a zajistit tak lepší spolupráci v rámci podniku.“8 Jen díky tomu může být zajištěno transparentní fungování podniku s možností sledování nákladů, zlepšování business procesů a zvyšování tak celkové výkonnosti. [9]
V následujícím odstavci bych rád vyjmenoval několik základních motivačních faktorů pro integraci aplikací: [9]
• Snaha o zachování investic vložených do původních aplikací. Jistě by bylo mnohem příjemnější nahradit všechny dosud používané heterogenní aplikace a postavit „na zelené louce“ úplně nový plně integrovaný podnikový systém. Tento způsob by byl však ve většině případech pro podnik naprosto nemyslitelný a také hlavně velmi nákladný. Navíc by došlo ke znehodnocení všech dosavadních investic do IS/ICT.
• Úspora lidských zdrojů. Existence roztříštěných aplikací vede k velké pracnosti jejich obsluhy a monitorování, vysokým nárokům na zaškolení koncových uživatelů, apod.
• Kontrola nákladů. Integrace aplikací a centralizace jejich správy vede ke kontrole a následné úspoře celkových nákladů na IS/ICT.
• Nutnost častých a rychlých změn business procesů. Konkurenční prostředí a měnící se legislativa vede k tomu, že většina procesů se musí v průběhu existence podniku
7 K integraci aplikací; Jaroslav Jandoš; Praha; Systémová integrace 2004
8 Systems Talking To Systems; Antony Adshead; ProQuest
přizpůsobovat a měnit, přičemž se předpokládá využití stávajících aplikací pro tyto nové úlohy.
Jak uvádí [2], při integraci aplikací v podniku se můžeme setkat s integračními problémy způsobenými např. tím, že:
• aplikace mohou využívat různých technologií od různých výrobců,
• neexistuje jednoduchý mechanismus, kterým by aplikace sdělila své rozhraní.
Co by tedy měla splňovat ideální integrační architektura? Měla by splňovat následující požadavky:
• minimální zásah do existujících aplikací,
• nezávislost a autonomie aplikací,
• dodržování standardů.
2.5.2. Technologie pro integraci
Od té doby, co se začalo hovořit o integraci, se dostalo ke slovu hned několik technologií, na kterých byl middleware postaven. Velký rozruch ve své době vyvolaly technologie založené na komponentách jako COM, DCOM, COM+, CORBA či JavaBeans. Ty se však neosvědčily hned z několika důvodů. Uvedená řešení jsou totiž „proprietární, složitá pro použití a navzájem spolu příliš dobře nespolupracují“9.
Právě proto se začalo opouštět od těchto přístupů a je vidět snaha o postupný přechod k ověřeným standardům jako je protokol HTTP a jazyk XML.
Vhodným řešením jsou svou podstatou právě webové služby. Dá se říci, že v EAI můžeme spatřovat sílu webových služeb (viz výše). Pojďme se nyní podívat na stručný nástin technologických řešení, jak je možné webových služeb při integraci podnikových informačních systémů využít. Nebudu zbytečně zabíhat do podrobností (jedná se o rozsáhlé téma pro řadu dalších diplomových prací), jen naznačím, jakými způsoby lze integraci IS pomocí webových služeb provést.
2.5.3. Způsoby integrace [6]
Integrace může obecně nabývat dvou podob a sice:
9 Michael Stal. Web services: Beyond Component-Based Computing; Seeking a better solution to the application integraton problem.
• integrace aplikační,
• integrace na úrovni integrační vrstvy (s využitím middleware).
V případě aplikační integrace se jedná v případě rozsáhlých informačních systémů o velmi dlouhý, náročný a drahý proces. Je nutné upravit stávající aplikace tak, aby spolu byly schopny komunikovat a svou funkčností se navzájem doplňovaly. To znamená velký zásah do celého stávajícího IS, kdy je nutné současné aplikace „přestavět“ a navíc pořídit další. S tím samozřejmě souvisí i nákup nového hardware.
Ve druhém případě naopak dochází k „přestavování“ stávajících aplikací co nejméně. Na aplikační vrstvě nedochází k téměř žádným změnám. Pod tuto vrstvu je pouze vložena integrační vrstva, tzv. middleware. Naše finanční výdaje se v tomto případě omezí pouze na nákup middleware systému, kterých je v dnešní době nepřeberné množství, a případně na adaptéry na některé části IS, pokud nejsou standardně dodávány buď dodavatelem IS či dodavatelem daného middleware. Ale ani v tomto případě se nejedná o malé částky (zejména v případě adaptérů).
Integrace IS však není jen o nákupu technologií a jejich zapojení, ale jde zejména o optimální sladění vzájemných vazeb mezi podnikovými systémy, které budou ve výsledku efektivně podporovat business procesy daného podniku. Jedná se o náročný proces, na kterém se podílí řada odborníků. Touto problematikou se však v této diplomové práci nebudu zabývat.
2.5.4. Integrace pomocí webových služeb
Aplikační integrace
Využití webových služeb jako integrační technologie pro aplikační integraci IS může být provedeno dvěma způsoby:
• využití webových služeb na úrovni objektů,
• využití webových služeb pro navázání komunikace mezi dvěma systémy na úrovni obecného XML dokumentu přenášeného pomocí protokolu SOAP.
První způsob je založen na zpřístupnění vzdálených objektů (resp. objektů vzdálených aplikací) přes proxy objekty vygenerované na základě WSDL dokumentu tak, jako by byly lokální. Klientská aplikace pak využívá tento proxy objekt, což je pro ni stejné jako v případě využití jakéhokoliv lokálního objektu.
Druhým způsobem je využití webových služeb, konkrétně protokolu SOAP, pro přenos obecných XML dokumentů mezi dvěma systémy. V tomto případě není využito WSDL dokumentu. Webové služby zde tedy slouží jen jako prostředník pro komunikaci.
Integrace na úrovni integrační vrstvy
Integrační vrstva při použití webových služeb jako integrační technologie vlastně znamená vybudování sítě navzájem provázaných webových služeb. Jelikož jsou webové služby postaveny na všeobecných standardech, mohou být jednotlivé webové služby od různých poskytovatelů. Dokonce může být IS podniku integrován i s externími IS – s IS obchodních partnerů, atd. (viz kapitolu „2.6. Business-to-business“). Velice podstatnou roli při vzájemném provázání jednotlivých webových služeb jejich optimální sladění tak, aby byly ve výsledku efektivně podporovány business procesy a cíle podniku. Toto však není v rukách vývojáře, nýbrž v rukách architekta či analytika. V prostředí webových služeb se touto otázkou zabývá specifikace WSBPEL (Web Services Business Process Execution Language), kterou se budu zabývat v jedné z dalších částí této diplomové práce. Pro snadnější orchestraci webových služeb existují také grafické nástroje, které toto umožňují i bez znalosti programování (konkrétní nástroje zmíním v kapitole „5.6. Nástroje pro orchestraci WS“).
Z technologického hlediska je nutné se při integraci IS pomocí webových služeb a jejich provázání zastavit také u řízení transakcí, neboť toto samotná specifikace webových služeb neřeší. To je možné vyřešit dvěma způsoby. Buď na úrovni aplikační logiky, nebo na úrovni protokolu SOAP, kdy řízení transakcí řeší nadstavba webových služeb s názvem WS- Transaction. U posledně jmenovaného přístupu je možné pro sledování a řízení transakcí využít speciálních monitorovacích nástrojů WSDM (dostupnými WSDM nástroji se budu věnovat v kapitole „5.8. Nástroje pro management a dohledování (monitoring) WS“).
2.5.5. Způsoby napojení webových služeb na legacy systémy
Již jsem popsal, jakými způsoby lze využít webových služeb při integraci informačních systémů. Ještě je však nutné vyřešit další otázku a sice způsob napojení webových služeb na stávající (legacy) systémy.
Prvním a jednodušším způsobem je využití standardních adaptérů, které jsou dodávány buď dodavatelem samotného informačního systému nebo dodavatelem middleware řešení. Úkolem těchto adaptérů je zpřístupnění rozhraní daného legacy systému na úroveň věcné logiky (ta může být implementována např. pomocí CORBA, EJB, COM+, atd.). Rozhraní této věcné logiky jsme pak schopni „zabalit“ webovou službou.
Druhým o něco složitějším přístupem je v případě neexistence daného adaptéru nejprve nutné zapouzdřit standardní rozhraní podporované legacy systémem nějakou distribuovanou technologií – např. webovou službou. Legacy systém je pak přístupný přímo pomocí rozhraní webové služby.
2.6. Business-to-Business (B2B)
Business-to-business integrace (B2Bi) znamená integraci aplikací podnikatelských partnerů s aplikacemi daného podniku, jejímž cílem je využití externích dat z okolí a sdílení vlastních dat daného podniku. Kromě dat jsou sdíleny také postupy a procesy. Stejně jako v případě interní EAI, je využití webových služeb velmi vhodnou volbou. Jestliže platí, že v rámci podniku bývá několik různorodých aplikací (různé platformy a programovací jazyky), mezi podniky je tento fakt ještě zřetelnější. Mezipodniková integrace je tak možná pouze v případě využití otevřených standardů přes extranet (resp. VPN) či Internet. Jak již bylo řečeno, webové služby tento požadavek svou podstatou splňují. Jednoduše řečeno, stačí některé funkce z podnikového informačního systému zpřístupnit pomocí webových služeb a sdílet je s našimi obchodními partnery.
2.7. Common Services
Common services (CS) můžeme přeložit jako „společné“, resp. „běžné“, či „veřejné“ služby.
Záměrně budu používat spíše anglické označení, protože mi přijde nejvýstižnější.
„Běžnými/společnými službami rozumíme jakoukoliv část programu, která poskytuje určitou funkcionalitu, která není specifická pro žádný konkrétní business proces. Takové služby jsou vytvářeny pouze jednou a jsou pak využívány v různých aplikacích.10“ Cílem CS je tedy zpřístupnit funkcionalitu mnoha různým klientům (aplikacím). V tomto případě bychom mohli místo „common services“ použít české označení „společné/běžné služby“.
Příklady využití takových služeb mohou být: [1]
• logování,
• uživatelské profily, personalizace,
• služby pro řízení přístupu – autentifikace a autorizace.
10 Perspectives on Web services: Applying SOAP, WSDL and UDDI to Real-World Projects; Olaf Zimmermann, Mark Tomlinson, Stefan Peuser; Berlin; Springer 2003
Někdy do common services můžeme zařadit webové služby, které představují volně dostupné webové služby, které může využívat široká programátorská veřejnost ve svých aplikacích.
Máme tím na mysli jednoduché webové služby, nejčastěji dostupné zdarma, které mohou využívat všichni (bez ohledu na to, zda se jedná o programátora profesionála či programátora, který se svému koníčku věnuje jen ve svém volném čase). Může se tedy jednat např. o službu ukazující předpověď počasí, aktuální měnový kurz či informaci o tom, kdo má dnes svátek.
V tom případě bereme jako synonymum pro common services „veřejné (webové) služby“.
Na Internetu nalezneme několik portálů s početným seznamem příkladů pro common (web) services. Příkladem takového portálu je XMethods (www.xmethods.com). Najdeme zde například webovou službu, která počítá vzdálenost mezi dvěma geografickými místy, webovou službu přiřazující PSČ (postal codes) k názvům ulic či webovou službu na posílání emailů a SMS. Webové služby publikované na těchto portálech jsou veřejně dostupné a slouží většinou pro testovací účely.
2.8. Interní versus externí webové služby
[14]Obr. č.3: Rozdíl mezi interní a externí webovou službou. Převzato z [14].
Externí webové služby umožňují různým organizacím vyměňovat si služby přes Internet.
Organizace najde službu v nějakém depositáři webových služeb, jakým je UDDI či jiný WS prostředník (např. www.xmethods.com), uzavře s dotyčným poskytovatelem SLA (Service Level Agreement – viz níže) a může službu využívat. V případě, že je daná služba poskytována zdarma, SLA se neuzavírá.
V případě interních webových služeb je situace jiná. Všechny webové služby jsou vlastněny organizací, která je využívá. Mohou být napojeny na různé části podnikového systému jako je ERP, personální systém, účetní systém, apod.
2.8.1. Interní webové služby
Interní webové služby jsou ideálním řešením pro integraci podnikových aplikací (viz výše).
Například se může jednat o komunikaci různorodých databázových systémů, které podnik v rámci svého informačního systému využívá (např. Oracle, MS SQL Server, mySQL, atd.).
Dalším směrem využití interních webových služeb je znovupoužití aplikací v rámci organizace. „Místo aby se zbytečně programovaly nové aplikace, které mají stejné funkce jako jiné již naimplementované aplikace, vývojáři jen stávající aplikace zpřístupní pro jejich další využití pomocí webových služeb11“. Takovéto moduly mohou být následně integrovány do jakékoliv jiné aplikace. Toto využití odpovídá běžným (webovým) službám – common (web) services.
Interní webové služby budou mít samozřejmě význam pouze u středních a zejména velkých podniků, kde vedle sebe existuje více různorodých IS. Navíc podmínkou pro možnost využití webových služeb je dostatečná síťová infrastruktura, což pro malé firmy může znamenat nákladný proces, jehož kýžené efekty se nakonec nemusejí dostavit.
Tím však nechci říci, že by pro velkou firmu byl proces implementace webových služeb méně nákladný či jednodušší. Na druhou stranu investice do této infrastruktury jednou vložené zcela jistě své ovoce časem přinesou. Zde se projeví takové přednosti této technologie jako je znovupoužitelnost a rozšiřitelnost. Jakmile bude totiž tato infrastruktura (aplikační servery, dohledovací a monitorovací nástroje, apod.) v provozu a webové služby již budou v rámci IS podniku využívány, nebrání nic tomu, aby se k již využívaným webovým službám přidávaly další a další.
2.8.2. Externí webové služby
Jak jsem již řekl, externí webové služby umožňují jejich výměnu mezi organizacemi přes Internet. V podstatě jde o to, že jedna organizace vytvoří webovou službu, resp. zpřístupní nějakou svou aplikaci či část aplikace pomocí webové služby a druhá organizace tuto službu může využívat. Důvody proč ke komunikaci mezi podnikovými IS využívat právě technologii
11 Internal or External Web Services?; Johann Dumser; Web Services Architect 2001. Dostupné z url [http://www.webservicesarchitect.com/content/articles/dumser03.asp]
webových služeb jsou nasnadě. Kromě již několikrát zmiňovaných výhod jako je interoperabilita mezi různorodými IS díky standardům XML, SOAP a WSDL (pokud je toto výhodou mezi aplikacemi v rámci podniku, tak mezi organizacemi to bude výhodné dvojnásob), využití sítě Internet (tzn. již vytvořených přenosových kanálů) a protokolu HTTP (SMTP, FTP) či možnost přístupu k webovým službám (resp. jejich vráceným hodnotám) z pohledu uživatelů pomocí WWW prohlížečů, mobilních telefonůči PDA.
Z poskytování webových služeb organizací se dokonce může stát nový business. Poskytovaná služba samozřejmě musí nabízet zajímavý a užitečný obsah a musí být spolehlivá. To s sebou samozřejmě přináší také potřebu sledování webových služeb a inkasování plateb za jejich využívání. [18, 19] Otázkou billingu a monitorování se budu zabývat v jedné z dalších kapitol.
Samozřejmě i pro organizace, které neposkytují vlastní webové služby, je využití webových služeb od ostatních organizací výhodné. Například se může jednat o webové služby získávané z různých expertních center, které poskytují specifické informace v reálném čase, jež není možné získat jinde (např. služba GetWeather, GetStockQuote, či Foreign Exchange12). Kromě veřejně dostupných verzí těchto služeb existují také privátní webové služby poskytované přes zabezpečený přístup.
12 http://as.asp2.cz/ForeignExchangeService.asmx
3. Hodnocení WS z pohledu vývojá ř e
Účelem této kapitoly bude zprostředkovat pohled na webové služby z pohledu vývojáře.
3.1. Webové služby pod drobnohledem
V této kapitole se nejprve zaměřím na jednotlivé standardy webových služeb a také se pokusím vysvětlit, jak vlastně webové služby fungují.
Základní představou fungování webových služeb je to, že se nejprve popíše, co dané služby
„umějí“, jak komunikují a tyto informace se pak uloží do vhodných adresářů, které budou moci zájemci o webovou službu prohledávat. Klienti (aplikace) se pak na danou službu napojí a mohou ji využívat. Službami se v podstatě rozumí funkce, které nějaká aplikace nabízí svému okolí (tj. nabídne své rozhraní). Aby mezi sebou mohli různorodé aplikace komunikovat, je nutné, aby vše fungovalo na nezávislých standardech. Webové služby tak jsou založeny na standardu XML, protokolu SOAP, jazyku WSDL a UDDI. Pojďme se nyní na jednotlivé standardy podívat blíže.
3.1.1. Protokol SOAP [1, 12]
Protokol SOAP13 umožňuje přenášet XML zprávy mezi dvěma aplikacemi (pracuje tedy peer- to-peer) prostřednictvím protokolů transportní vrstvy. Výhodou webových služeb je fakt, „že webová služba je nezávislá na transportním protokolu. SOAP specifikace pouze definuje jak poslat SOAP zprávu přes HTTP (a dnes to dělá převážná většina webových služeb), ale je možné použít i jiný přenosový protokol. Je možné použít SMTP (Simple Mail Transfer Protocol)14, čisté TCP (Transmission Control Protocol) nebo protokol přímých zpráv jako Jabber či libovolný jiný protokol.“15 Pro přenos je možné využít například i javové messagingové služby (JMS).
SOAP se ve webových službách dá využít dvěma způsoby: [4]
• RPC style
Jedná se o nejčastější způsob využití protokolu SOAP. Jde o vzdálené volání procedur neboli RPC (Remote Procedure Call), tedy o model požadavek/odpověď. To znamená, že jedna
13 Od verze 1.2 se již nehovoří o SOAPu nehovoří jako o zkratce. Ještě ve verzi 1.1 byl SOAP zkratkou „Simple Object Access Protocol.
14 Přenos pak probíhá pomocí e-mailových zpráv
15 Webové služby – třetí generace internetu; Pavel Horovčák; Časopis IT Systems, září 2003. Dostupné z URL [http://casopis.systemonline.cz/286-webove-sluzby-treti-generace-internetu.htm]
aplikace pošle druhé aplikaci požadavek, ta požadavek vyřídí a pošle zpět první aplikaci zprávu (odpověď) s výsledkem. Webová služba bývá v tomto případě nahrána na webový server, jehož úkolem je čekat na požadavky klientů a jakmile obdrží SOAP zprávu, spustí webovou službu a požadavek jí předá. Výsledek služby pak webový server předává zpět klientovi jako odpověď. Definice operací, požadovaných parametrů a návratových hodnot je přesně specifikována ve WSDL dokumentu.
• Document style
Tento přístup je někdy také nazýván jako „document-oriented“ nebo "message-oriented".
SOAP je zde použit pouze jako „obálka“ pro přenos libovolného obsahu uvnitř SOAP zprávy.
Narozdíl od prvního přístupu, kdy ze strany klienta dochází ke vzdálenému volání funkcí, v tomto případě jde o posílání obecného XML bloku jako parametru službě, přičemž žádným způsobem neomezuje strukturu přenášeného XML bloku.
Protokol SOAP ve své první verzi (1.0) vznikl na konci roku 1999. Na jeho vytvoření se podílely firmy DevelopMentor, Microsoft a UserLand, jejichž cílem bylo vytvořit protokol pro vzdálené volání procedur (RPC) založený na všeobecně uznávaném standardu XML.
SOAP byl následníkem o rok staršího protokolu XML-RPC. V roce 2000 se k vývoji přidala i firma IBM a vznikla tak nová verze SOAPu 1.1. Tato verze byla přijata konsorciem W3C a tak se SOAP 1.1 stal standardem. [4] Poslední verze SOAPu je 1.2.
Struktura zprávy SOAP [1, 4]
Zprávu SOAP si můžeme představit jako jednoduchý XML dokument, který sestává ze tří částí (ze tří elementů):
obálka (Envelope) – kořenový element, který definuje rozhraní popisující obsah zprávy a způsob jak ji zpracovat.
V obálce jsou pak uzavřeny dva elementy:
hlavička (Header) – nepovinná, používá se pro přenos pomocných informací pro zpracování zprávy (identifikace uživatele, autentizační informace, apod.), tělo (Body) – nejdůležitější část, ve které jsou přenášeny informace
identifikující volanou službu a předávané parametry (resp. návratové hodnoty) služby.
„Jelikož se dnes SOAP typicky používá pro RPC volání, je celkem přirozené, že se pro přenos požadavku/odpovědi nejčastěji používá protokol HTTP (HyperText Transfer Protocol).
Důvodem je zejména široká podpora HTTP v různých aplikacích. Navíc webovou službu lze nahrát přímo na běžný webový server, jenž slouží jako „dispečer“, který jednotlivé požadavky předává odpovídající webové službě ke zpracování. Výhoda použití HTTP také spočívá v tom, že stávající síťová infrastruktura, zvláště ve firemní sféře, dovoluje v podstatě neomezenou komunikaci na portu vyhrazeném pro HTTP (TCP port 80). Webové služby je možné používat bez nutnosti zásahu do konfigurace aktivních síťových prvků jako jsou firewally. Při použití technologií DCOM nebo CORBA je potřeba povolit komunikaci na portech, které používají příslušné přenosové protokoly (např. IIOP pro CORBA).“16
V případě, že použijeme transportního protokolu HTTP, zpráva SOAP se zasílá v těle HTTP požadavku. To umožňuje metoda POST. Takový požadavek musí obsahovat hlavičku SOAPAction – ta může obsahovat URI s identifikací služby, která se má vyvolat. V případě, že hlavička SOAPAction obsahuje prázdný řetězec, je služba, která se má vyvolat identifikována přímo adresou, na kterou směřuje požadavek. [4]
3.1.2. WSDL
WSDL (Web Service Description Language) je jazyk pro popis veřejného rozhraní webových služeb pomocí XML. Pomocí tohoto jazyka je vytvořen WSDL dokument, který představuje strojově zpracovatelný popis služby. Popis rozhraní „využívá žadatel služby k tomu, aby dokázal sestavit požadavek, jemuž služba bude rozumět, a zároveň aby dokázal zpracovat došlou odpověď, tj. aby rozuměl došlým datům“17 Ve výsledku WSDL dokument v podstatě představuje XML dokument popisující funkcionalitu služby, „jak“ a „kde“ je daná webová služba dostupná, atd. Použití XML jako formátu popisu rozhraní je velice důležité, neboť je zajištěno, že popis rozhraní nebude závislý na poskytovateli služby. [1, 2, 4]
Na vzniku jazyka WSDL se podílely firmy Microsoft a IBM. V současné době je WSDL informativní poznámkou konsorcia W3C a jeho poslední verze je 1.1. Jeho specifikaci je možné si přečíst na adrese http://www.w3.org/TR/wsdl .
WSDL rozděluje popis služby na dvěčásti: [1]
abstraktní rozhraní (popis rozhraní) – "odhaluje strukturu rozhraní webové služby, tj.
metody podporované službou, parametry metod a abstraktní datové typy. Tato definice
16 Diplomová práce – Inteligentní podpora navigace na WWW s využitím XML (kapitola Využití webových služeb a protokolu SOAP při komunikaci); Jiří Kosek; Praha; VŠE. Dostupné z url
[http://www.kosek.cz/diplomka/html/websluzby.html]
17 Podniková informatika;Libor Gála, Jan Pour, Prokop Toman; Praha; Grada 2006
je zcela nezávislá od jakékoli síťové adresy, komunikačního protokolu nebo konkrétní datové struktury."18
konkrétní implementace (popis implementace) – "spojuje abstraktní rozhraní s konkrétní síťovou adresou, komunikačním protokolem a konkrétní datovou strukturou.
Uživatelé webových služeb se k takové implementaci mohou připojit a vyvolat službu."19
WSDL dokument je XML dokument obsahující následující elementy: [1, 4, 32]
Types – definice datových struktur používaných ve zprávách (nejčastěji se používají XML schemata).
Message – abstraktní definice formátu předávaných zpráv pomocí dříve definovaných datových struktur. Zpráva se skládá z několika logických jednotek (part). Každá taková part je spojena s konkrétním datovým typem.
Operation – abstraktní definice operací (metod), které jsou službou podporovány. Je zde tedy popsán způsob komunikace se službou.
PortType – abstraktní sada operací podporovaná jedním nebo více koncovými body (porty).
Binding – Specifikace konkrétního protokolu a datového formátu pro navázání úrčitého typu portu (portType). Je zde popsána vazba na fyzickou reprezentaci služby (tj. nějakou síťovou adresu a mechanismus přístupu k ní).
Port – jeden koncový bod služby definovaný jako kombinace vazby (binding) a síťové adresy.
Service – sdružení několika příbuzných koncových bodů (portů) do jedné služby.
Je však nutné poznamenat, že WSDL dokument jako takový nám jako potenciálním zájemcům o danou webovou službu nepomůže tuto službu najít. K tomu slouží UDDI registry, které popíši v následující subkapitole.
18 Perspectives on Web services: Applying SOAP, WSDL and UDDI to Real-World Projects; Olaf Zimmermann, Mark Tomlinson, Stefan Peuser; Berlin; Springer 2003
19 Perspectives on Web services: Applying SOAP, WSDL and UDDI to Real-World Projects; Olaf Zimmermann, Mark Tomlinson, Stefan Peuser; Berlin; Springer 2003
3.1.3. UDDI
UDDI představuje jednak specifikaci, jednak se jedná o asociaci stoupenců této specifikace s názvem UDDI.org, ve které se sdružují přední světové softwarové firmy.
UDDI (Universal Description, Discovery and Integration) je soubor technologií pro vybudování distribuovaného rejstříku webových služeb. Tento adresář nese název UDDI registr a z pohledu uživatelů webových služeb (dále jen spotřebitel) jde o centralizovaný vyhledávací engine webových služeb, který pomáhá zájemcům najít adekvátní webové služby. UDDI registr je vlastně strukturovaný seznam informací o [4]:
dostupných webových službách,
jejich poskytovatelích (business entity) – jméno, popis, kontakt a jednoznačný identifikátor,
rozhraních těchto webových služeb.
Specifikace UDDI
Specifikace UDDI definuje XML formát pro uložení dat a metadat o službách a společnostech, jež tyto služby poskytují, a definuje API rozhraní pro komunikaci s nimi.
Specifikaci UDDI nalezneme na adrese www.uddi.org. V květnu roku 2003, resp. v únoru 2005, byly specifikace UDDI verze 2, resp. specifikace UDDI verze 3, schváleny jako OASIS standardy. Aktuální verze specifikace UDDI je 3.0.2.
Specifikace UDDI vlastně popisuje způsob uložení dat a metody přístupu k těmto datům.
Skládá se ze čtyř oblastí: [6]
• struktura dat,
• rozhraní pro přístup vývojáři (programmer’s API).
Existují dva typy:
• Zveřejňovací funkce – slouží k vytváření a úpravě položek v registru.
• Dotazovací funkce – slouží pouze pro čtení a umožňují vyhledávání již existujících položek v registru.
• Replikace dat – popis, jakým způsobem replikují jednotlivé registry informace mezi sebou. To se týká pouze veřejných registrů.
• Provoz UDDI – pro provozovatele UDDI registrů specifikuje pravidla bezpečnostní politiky (např. povinnost vyplňovat identifikátor uživatele) a správy dat (např. co vše je nutné udržovat za data).
Registry UDDI se rozdělují na veřejné (public) a soukromé (private) [2].
3.1.4. Veřejné UDDI registry
Veřejné registry jsou veřejně přístupné implementace specifikace UDDI. Obsahují seznam webových služeb, které jsou přístupné široké veřejnosti (administrativní funkce veřejného registru mohou však být zabezpečené). Příkladem veřejného UDDI registru je UBR neboli UDDI Business Registry. UBR je provozováno na různých uzlech, které nabízejí různé technologie na různých platformách. To však koncovému uživateli vůbec nemusí vadit, neboť všechny služby splňují specifikaci, takže uživateli může být v konečné fázi jedno, který z uzlů si vybere. Mezi jednotlivými uzly jsou data replikována, takže pokud uložíme informace o své webové službě na jeden uzel, za nějaký čas je uvidíme i na uzlech ostatních.
3.1.5. Soukromé (privátní) UDDI registry
Do privátního UDDI registru má přístup pouze vlastník. Jedná se o interní UDDI registr, který je skrytý „branami“ firewallu a je tak zcela odříznutý od veřejné sítě. Jedná se většinou o využití v rámci podnikového intranetu. Přístup jak k administrativním funkcím tak k datům registru jsou zabezpečené. Data nejsou s ostatními registry sdílena, tzn. že registr je nezávislý UDDI uzlem, který není propojen na ostatní registry.
3.1.6. Sdílené (semi-privátní) UDDI Registry
Tento typ UDDI registrů má nejčastější pole působnosti v rámci extranetu či VPN. Jedná se o sdílení UDDI registru a zejména jeho obsahu v rámci sítě obchodních partnerů. UDDI registr samotný je umístěn u nějakého z podniků, který tak sdílí své služby s ostatními důvěryhodnými partnery. Administrativní funkce mohou být v tomto případě delegovány na obchodní partnery.
Soukromé a sdílené UDDI registry v současné době nabývají stále více na významu. Webové služby mají totiž velký význam v komunikaci jednak mezi spolupracujícími podniky (B2B integrace), jednak uvnitř těchto podniků (vnitřní integrace) – viz níže.
Funkce UDDI registru
• Publikování služeb
Administrativní funkce, o kterých jsem hovořil v předchozích odstavcích, zahrnují právě publikování webových služeb, resp. informací o nich.
• Vyhledávání služeb
Jak již bylo řečeno, UDDI registr je pouze rejstřík, tzn. že výsledkem hledání webové služby nebude služba samotná, ale pouze její popis a adresa.
3.1.7. Vztah SOAP, WSDL, UDDI a webových služeb
Vztah všech tří výše uvedených standardů (SOAP, WSDL, UDDI) a webových služeb je možné znázornit následujícím obrázkem:
Obr. č. 4: Vztah tří základních technologií (SOAP, WSDL, UDDI) a WS. Převzato z [4].
„Ke každé webové službě by měl být k dispozici její formální popis v jazyce WSDL. Z tohoto popisu již jde automaticky vygenerovat SOAPový požadavek. Ve větších systémech nebo přímo v otevřeném prostředí Internetu se popis služby může zaregistrovat do UDDI registru.
Ten slouží jako jakýsi telefonní seznam („zlaté stránky“), který umožňuje vyhledávání služeb s určitými parametry. Klient, který chce využít webovou službu, získá buď přes UDDI nebo přímo její popis. Z něj je jasné, jakou strukturu má mít SOAPová zpráva a kam se má webové službě poslat, aby ji rozpoznala.“20
20 Diplomová práce – Inteligentní podpora navigace na WWW s využitím XML (kapitola Využití webových služeb a protokolu SOAP při komunikaci); Jiří Kosek; Praha; VŠE. Dostupné z url
[http://www.kosek.cz/diplomka/html/websluzby.html]
3.1.8. DISCO [27]
DISCO (neboli SOAP Discovery) je specifikace pro vyhledávání webových služeb vytvořená firmou Microsoft. Nástroje od Microsoftu jako je Visual Studio .NET a .NET Framework v sobě mají parser na DISCO soubory, které obsahují informaci o tom, jaké webové služby jsou dostupné na daném umístění. Pokud tedy chceme zjistit seznam služeb dostupných na konkrétním serveru, použijeme protokol DISCO.
3.2. Vývojá ř a standardy WS
[5, 7, 13]V předchozích odstavcích jsem popsal principy fungování webových služeb včetně jejich základních standardů (SOAP, WSDL a UDDI). Nastává otázka, zda je pro vývojáře nezbytné znát podrobně jednotlivé standardy. Nikoliv. Principy fungování jednotlivých standardů webových služeb nejsou pro programátora, který chce nějakou webovou službu využívat, příliš důležité. Vývojář tvořící program v nějakém konkrétním jazyce ani nemusí mít podrobnou znalost specifikace XML. Veškeré volání služeb probíhá na pozadí a programátor se nemusí prakticky o nic starat. Komunikace s webovou službou totiž probíhá tak, že je na základě WSDL dokumentu vygenerován proxy objekt, se kterým následně vývojář pracuje tak, jako by se jednalo o kterýkoliv jiný objekt dostupný na lokálním stroji. [7] O generování těchto proxy objektů se stará v dnešní době generátor, který je zabudovaný již ve většině vývojových nástrojích. Pro vývojáře tak připojení se k webové službě znamená pouze pár
„kliknutí“ myší. I z tohoto důvodu jsem se popisem těchto standardů nezabýval úplně dopodrobna (není to ani účelem této diplomové práce).
Z výše uvedeného plyne pro vývojáře další výhoda webových služeb. Jejich využívání ve vlastních aplikacích není nijak složité. Samozřejmě že na tvůrce konkrétních webových služeb jsou kladeny určité nároky při jejich vývoji (jako je spolehlivost, efektivita provádění jednotlivých metod, atd.), ale rovněž to nesouvisí s jednotlivými standardy. Dnešní vývojové nástroje ulehčují i této druhé straně tvorbu webových služeb. Rovněž zde vše probíhá na pozadí (například o vygenerování WSDL dokumentu se stará WSDL generátor).
3.3. Vývojové nástroje s podporou WS
Současné vývojové nástroje většinou podporují jak tvorbu tak využití webových služeb. To znamená, že na své si přijdou jak ti, kteří chtějí své webové služby vyvíjet a následně poskytovat, tak i ti, kteří chtějí některou z webových služeb zakomponovat do své aplikace a využívat ji. Tyto vývojové nástroje v sobě tak zahrnují nástroje usnadňující tvorbu webových
služeb do takové míry, že uživatel (vývojář) nemusí znát detailně jednotlivé standardy webových služeb. Typicky obsahují automatické generátory klientů na základě WSDL dokumentu, ladící a jiné aplikace.
Existují jak komerční tak nekomerční vývojové nástroje. Komerční (placené) většinou bývají specializované nástroje pro komplexní podporu určitého programového balíku jakými jsou například MS Visual Studio .NET či Rational Application Developer for WebSphere Software od IBM.
Na druhé straně existují nekomerční (freeware, open-source či jiné „svobodné“ licence), které jsou poměrně oblíbené, ale často neposkytují vývojářům takový komfort. Asi nejznámějším a nejoblíbenějším zástupcem této kategorie je vývojový nástroj Eclipse, který je realizovaný pod záštitou firmy IBM. Také se velmi podobá jeho komerčnímu „příbuznému“ IBM Rational Application Developer for WebSphere Software. Eclipse je sice ve svém základním provedením „pouze“ vývojářským nástrojem pro jazyk Java a standardně v sobě přímou podporu webových služeb neobsahuje, ale díky velmi rozšířeným plug-inům je možné tuto podporu do nástroje přidat. Nevýhoda tohoto nástroje pramení právě z nutnosti instalace různých plug-inů.
Přehledem konkrétních vývojových a pomocných nástrojů s podporou webových služeb se budu zabývat v kapitole „5.7. Vývojové nástroje s podporou WS“.
3.4. Dostatek a kvalita využitelných webových služeb
Co se týče dostatku či nedostatku webových služeb, tomu se budu věnovat až v poslední části této diplomové práce. Jen předznamenám, že během psaní této práce jsem zjistil (ať už hledáním samotných webových služeb či zjišťováním událostí, které se za tuto dobu staly), že veřejně dostupných webových služeb už není tolik, kolik jich bývalo. Ubyly totiž veřejné UDDI registry provozované firmami Microsoft, SAP a IBM (viz kapitolu „5.3.1.Veřejné UDDI registry“), zrušeny byly i některé další prostředníci webových služeb (viz dále). Dá se konstatovat, že technologie webových služby se vydala jiným směrem, a to směrem k privátním a semi-privátním webovým službám provozovaným v rámci podnikových a mezipodnikových řešení.
Nicméně ještě stále jsou k dispozici využitelné a kvalitní webové služby dostupné i veřejně. Příkladem veřejně dostupného dosud fungujícího seznamu je např. www.salcentral.net.
Existují však také webové služby, které v žádném veřejném registru nenalezneme. Příkladem budiž server Amazon.com nebo Google (viz dále).
Pokud se vývojář rozhodne použít některou z dostupných veřejných webových služeb, měl by se při hledání adekvátní webové služby rozhodovat na základě dvou kritérií. Předpokládejme, že vývojář vybírá webovou služby pro získávání aktuálního měnového kurzu. První kritérium, podle kterého webovou službu vybere, bude jednak funkčnost, kterou daná webová služba poskytuje. Dále vývojáře bude zajímat, odkud daná webová služba získává potřebná data – například webová služba poskytující funkci převodů měn z jedné měny do druhé a využívající při tom kursovního lístku České národní banky bude jistě důvěryhodná. Také je nutné dát pozor na spolehlivost dané webové služby (ta však není garantována, dokud není uzavřena SLA – viz dále). V neposlední řadě to bude také netechnické kritérium, jako je například reputace poskytovatele, apod.
