Koncept infrastruktury a nástrojů pro práci s ICS

Transkript

1 Autodesk Academia Grant 2005 Koncept infrastruktury a nástrojů pro práci s ICS Návrh na propojení produktů Autodesku s technologií.net Vypracovali: Vlastimil Kaluža Jiří Špaček

2 Obsah 1. Předmluva Úvod Seznam zkratek Úvod do webových služeb Vývoj webových služeb Webová služba a webová aplikace Princip webových služeb Základ webových služeb SOAP WSDL UDDI Jak webová služba funguje Podrobný popis UDDI Specifikace UDDI Datové struktury UDDI Programové rozhraní UDDI (UDDI API) Inquiry API Publication API (a primární klíče UDDI) Zprávy Zprávy typu Inquiry Zprávy typu Publishing Zprávy typu Response Společné přístupové body (Common Access Points) Datový model UDDI Identifikátory Kategorizace Úvod do UML Použití UML Základní stavební bloky Předměty Relace Diagramy Komerční produkty pro práci s UML Produkty šířené pod GPL a podobnými licencemi Spojení ICS s aplikací Autodesku Základní informace o návrhu Návrh infrastruktury na straně klienta Napojení infrastruktury na aplikaci Autodesk Infrastruktura na straně serveru Literatura...49

3 1. Předmluva Cílem tohoto projektu je vypracovat návrh infrastruktur pro tvorbu nových ICS, jejich vyhledávání v rámci sítě Internet, nástrojů pro jejich správu a práci s nimi v produktech firmy Autodesk s technologií.net od společnosti Microsoft. Důvodem je, že většina produktů firmy Autodesk v současné době pracuje na operačních systémech této společnosti. V současné době neexistuje v České republice řešení podobného druhu, které by bylo všeobecně známé, dostupné a použitelné širokou odbornou veřejností ve školství a komerční sféře. Firma Autodesk výrazně využívá prostředí intra/internetu a oblast.net technologií Microsoftu se také stává základní platformou pro další vývoj idesign technologií.

4 2. Úvod První část je věnována popisu webových služeb. Druhá část je věnována UDDI, které je stěžejní technologií pro definování a vyhledávání požadovaných webových služeb. Třetí část je věnována popisu UML, což je standard pro modelování jednoduchých i složitých aplikací pomocí formální syntaxe. Čtvrtá část je věnována vlastnímu popisu modelu internetové CAD služby. Tento projekt by měl sloužit správcům počítačového vybavení škol při zřizování vlastních serverů se službami pro výuku a nastavení parametrů pro využití serverů firmy Autodesk a jiných serverů. Dále by měl sloužit jako inspirace pro návrháře jednotlivých webových služeb, které by tak měly co nejlépe sloužit nejen k další výuce, ale i pro komerční oblast. Taktéž poslouží jednotlivým konstruktérům, při vyhledávání, přidávání a používání jednotlivých služeb Seznam zkratek Zkratka HTTP XML SOAP WSDL UDDI UML W3C RPC Popis HyperText Transfer Protocol protokol pro přenos webových stránek extensible Markup Language standardní jazyk pro zápis strukturovaných informací v textové podobě; hlavním rysem standardu XML je rozšiřitelnost zápisu a existence nástrojů pro automatickou kontrolu a konverzi dat zapsaných v jazyce XML Simple Object Access Protocol standard konsorcia W3C pro komunikaci v prostředí internetu; hlavním rysem standardu SOAP je přenos dat v textové podobě vytvořené v jazyce XML Web Services Description Language standard konsorcia W3C pro popis webových služeb Universal Description, Discovery and Integration standard konsorcia UDDI, který popisuje webovou službu určenou k registraci a vyhledávání dalších webových služeb Unified Modeling Language standardní grafický jazyk pro popis architektury programu World Wide Web Consortium konsorcium pro vývoj webových technologií Remote Procedure Call metoda volání procedur na dálku po síti; hlavním rysem metody RPC je automatické generování kódu, který maskuje komunikaci po síti jako volání procedur, z popisu rozhraní těchto procedur

5 3. Úvod do webových služeb O webových službách se mluví mezi odbornou veřejností již delší dobu, nicméně teprve v posledních letech, zejména od doby nástupu.net technologie firmy Microsoft, se zdá, že se webové služby budou stále více rozšiřovat pro běžné použití širokou veřejností. Máme-li webové služby definovat, potom bude zřejmě nejvýstižnější následující tvrzení: webové technologie umožňují integrovat libovolné aplikace provozované na různých platformách a ovládat je prostřednictvím webového rozhraní, tedy z běžného internetového prohlížeče. Společnost IBM nabízí jinou, technicky přesnější, definici: webové služby jsou nové služby charakteristické třístupňovým zásobníkem s technologiemi SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) a UDDI (Universal Discovery, Description and Integration). Mottem většiny strategií, které v oblasti webových služeb softwarové firmy prezentují, je informace kdekoliv. Znamená to, že k datům by měl být možný přístup kdekoliv a z jakéhokoliv zařízení (PDA, mobilní telefon, notebook či stolní počítač). Webové služby by měly fungovat jako více či méně univerzální prostředník (rozhraní) mezi firmou (aplikací) a uživateli Vývoj webových služeb Internet se ve svém vývoji dostává do třetí etapy či generace: První generaci představují statické (HTML) stránky určené k přenosu informací směrem od serveru ke klientovi. Druhá generace jsou interaktivní stránky s podporou obousměrné komunikace klient - server. V obou případech je příjemcem informace člověk. Třetí generace internetu (programování webu) se vyznačuje webovými službami, které jsou jejím dominantním představitelem.

6 Příjemcem informace se může stát stroj a člověk hodnotí výsledky vzájemné webové komunikace počítačů. Technologie webových služeb není ve světě počítačové vědy revolucí, ale evolucí starých koncepcí vývoje softwaru na bázi komponentů. [1] Úsilí o zvýšení efektivnosti programování vedlo v 80. letech minulého století ke vzniku objektově orientovaného programování. Definování a opakované využívání objektů a využívání tříd postupně pronikalo do všech programovacích jazyků, vývojových prostředí a technologií, někde ve větší, jinde v menší míře. Nejdříve se využívaly knihovny tříd, později dynamicky připojené knihovny. V první polovině 90. let tento vývoj vyvrcholil tvorbou a využíváním komponentů - objektů COM (Component Object Model). Ve druhé polovině 90. let se v podobě DCOM (distributed COM) podařilo překročit hranici jednoho počítače, čímž byla vytvořena možnost, aby program běžící na jednom počítači v síťovém prostředí využíval třídy umístěné na jiném počítači. Webové služby jsou pokračováním této expanze za hranice počítače umožňují překročení hranice jedné platformy, programovacího jazyka a dokonce i síťového protokolu. [2] Vývoj internetu založený na postupné inovaci jednotlivých standardů znázorňuje obr. 1. Obrázek č. 1: Vývoj webových technologií [3]

7 3.2. Webová služba a webová aplikace Mezi tradičními webovými aplikacemi a webovými službami existují tři podstatné rozdíly: webové služby využívají místo zpráv MIME zprávy SOAP, webové služby nejsou typu http, webové služby poskytují metadata popisující zprávy, které produkují a konzumují. První rozdíl je v tom, že webová služba komunikuje pomocí zpráv typu SOAP. SOAP formalizuje použití XML jako způsobu přenosu údajů mezi dvěma procesy, definuje rámcový model pro rozšiřitelnost a verze protokolu, způsob přenosu chybových informací a způsob zasílání zpráv přes HTTP. Tělo zprávy SOAP obsahuje jakýkoli XML obsah posílaný aplikací. Posun od zprávy typu MIME k XML zprávám souvisí s podstatným rozdílem mezi klientem tradiční webové aplikace (prohlížečem) a klientem webové služby. Prohlížeče obyčejně pouze provázejí (rendují) HTML (HyperText Mark-up Language) stránky (nebo jiné údaje typu MIME, jako jsou například obrázky) a interpretaci zobrazené informace ponechávají na uživateli. Klient webové služby naopak většinou potřebuje interpretovat údaje, které dostal, a něco smysluplného s nimi poté udělat - dokonce nemusí mít ani uživatelské rozhraní. XML představuje standardní způsob reprezentace a správy údajů a nástroje pro práci s XML jsou všudypřítomné, takže jeho volba jako formátu pro webové služby je zcela logická. Druhým velkým rozdílem mezi webovou službou a tradiční webovou aplikací je to, ž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), čisté TCP (Transmission Control Protocol) nebo protokol přímých zpráv jako Jabber či libovolný jiný protokol. Ačkoli většina SOAP zpráv

8 bude v blízké budoucnosti posílaná přes HTTP, schopnost použít jiné protokoly je velmi důležitá. HTTP není určeno na podporu dlouhotrvajících požadavků nebo potvrzení události odeslání klientem. Tyto problémy jsou lépe řešené v jiných protokolech a jejich standardizovaná podpora se v blízké budoucnosti očekává. Třetím podstatným rozdílem je skutečnost, že webová služba je samopopisující. Poskytuje metadata popisující produkované a konzumované zprávy, modely výměny zpráv na vyjádření režimu činnosti, použitý fyzický transportní protokol a logickou adresnou informaci potřebnou na její vyvolání. Formáty zpráv webových služeb jsou definované pomocí XML schémat XSD (XML Schema Definition). XML schéma je dostatečně flexibilní k popisu širokého rozsahu struktur zpráv, včetně otevřených modelů obsahu (open content models) s jemným řízením rozšiřitelnosti, což je kritické pro služby, jež mají být volně vázané. [10] Obrázek č. 2: Schéma webové aplikace [8]

9 Obrázek č. 3: Schéma webové služby [8] 3.3. Princip webových služeb Jednoduchost interakcí ve webovém programovacím modelu umožňuje inkrementální vytváření systémů. Na rozdíl od těsně vázaných systémů RPC a systémů distribuovaných objektů, které vyžadují rozmístění a vytvoření všech částí aplikace najednou, k systémům založeným na webu je možné přidávat klienty a servery podle potřeby. Vytvoření připojení k novým aplikacím je jednoduché, dá se dělat decentralizovaně, bez jakékoli centrální koordinace kromě registrace DNS jménem, a s podstatně vyšším stupněm vzájemné součinnosti, rozšiřovatelnosti a ovladatelnosti. Základní idea webové služby spočívá v přizpůsobení volně vázaného webového modelu programování na použití v aplikacích, které nejsou založené na využití prohlížečů. Cílem je poskytnout platformu pro vývoj distribuovaných aplikací s využitím softwaru pracujícího na různých operačních systémech a zařízeních, vytvořených v různých programovacích jazycích a vývojových nástrojích od různých dodavatelů, vše s možností nezávislého vývoje a aplikace. [9]

10 3.4. Základ webových služeb Webová služba je softwarový systém identifikovaný URI (Uniform Resource Identifier). Jeho rozhraní a vazby jsou definované a popsané pomocí XML. Definice může být objevená jinými softwarovými systémy. Tyto systémy jsou pak schopny vzájemně působit s webovou službou způsobem předepsaným v její definici a s použitím zpráv založených na XML a přepravovaných pomocí internetových protokolů. [7] Základem webových služeb je trojice standardů SOAP, WSDL a UDDI pro komunikaci, popis služeb a vyhledávání služeb. SOAP je označení protokolu, s jehož pomocí Webové služby komunikují. WSDL je speciální jazyk, kterým jsou popsány Webové služby a UDDI označuje registr, kde lze ukládat a vyhledávat informace o jednotlivých Webových službách. Vzájemný vztah SOAP, WSDL a UDDI je patrný z obrázku č. 4. Obrázek č. 4: Vztah SOAP, WSDL a UDDI [8] Princip webové služby je poměrně jednoduchý. Vytvořenou aplikaci (funkci) je potřeba umístit někam na síť a určitým jazykem (konkrétně WSDL) definovat její rozhraní. Když se někdo rozhodne tuto službu využít, pošle dohodnutým protokolem (SOAP) vstupní údaje a dostane zpět výsledek. Při vytváření aplikací je potřebné nejdříve ve speciálním katalogu (UDDI) zjistit vhodné existující webové služby a ty potom stačí připojit.

11 3.5. SOAP Simple Object Access Protocol (SOAP) je standard pro komunikaci v prostředí internetu vydaný konsorciem W3C [4]. Definuje kódování předávaných zpráv textovým zápisem v jazyce XML, kdy se každá zpráva skládá ze série hlaviček a těla s vlastním obsahem zprávy. Ačkoliv takto kódované zprávy mohou být delší, než je nezbytně nutné, jejich textový formát umožňuje předávat je prostřednictvím protokolu HTTP. To je velmi důležité v prostředí internetu, kde jiné protokoly než HTTP nemusí být kvůli různým technickým či bezpečnostním překážkám použitelné WSDL Web Services Description Language (WSDL) je standard pro popis webových služeb, také od konsorcia W3C. [5] Tento popis, opět v jazyce XML, obsahuje definice všech typů dat a formátů zpráv nutné pro komunikaci s webovou službou. Popis obsahuje také specifikaci přenosového protokolu, specifikaci kódování zpráv a informaci o tom, na kterých konkrétních adresách je daná webová služba k dispozici. Popis podle standardu WSDL tak obsahuje všechny údaje potřebné pro volání webové služby UDDI Universal Description, Discovery and Integration (UDDI) je standard konsorcia UDDI [6], který popisuje webovou službu určenou k registraci a vyhledávání dalších webových služeb. UDDI se opírá o třídění služeb podle některého ze standardních katalogů, jako je registr DUNS nebo katalogy NAICS či UNSPSC. Záznam o každé webové službě obsahuje vedle zatřídění služby také informace o jejím poskytovateli a popis služby podle standardu WSDL.

12 3.8. Jak webová služba funguje Komunikaci klienta a serveru znázorňuje obrázek č. 5. Ten vychází z případu, kdy se použije Microsoft SOAP Toolkit na straně klienta i na straně serveru a kdy webovou službu poskytuje komponenta COM (tak se implementuje prostřednictvím aplikace vytvořené ve Visual FoxPro). V prostředí.net to funguje trochu jinak. Obrázek č. 5: Princip komunikace s webovou službou Celý proces začíná požadavkem ze strany klientské aplikace. Ta kontaktuje klienta SOAP, předá mu parametry pro webovou službu a sdělí mu její URL adresu. Adresa služby je ve skutečnosti adresou souboru WSDL. Klient SOAP si stáhne ze souboru WSDL informace o službě. Pomocí získaných dat ověří, zda daná služba opravdu obsahuje metodu, kterou aplikace požaduje a ověří datové typy získaných parametrů. Dále sestaví požadavek SOAP (SOAP request) a odešle jej v těle požadavku HTTP (http request) na zjištěnou adresu "listeneru, který přijímá požadavky pro webovou službu. Listener (poslouchač/naslouchač) může být dvojího typu. Buďto se jedná o server ISAPI nebo stránku ASP. Rozdíl mezi nimi je především v rychlosti. ISAPI je asi čtyřikrát rychlejší. Stránka ASP se

13 používá v případě, že chceme před předáním požadavku serveru SOAP provést ještě nějaké dodatečné zpracování, či úlohu serveru SOAP úplně vynechat. Pokud tedy není na stránce ASP příslušného listeneru specifikováno jinak, předá se požadavek přímo serveru SOAP. Server SOAP z přijatého požadavku zjistí jméno metody komponenty COM, kterou má zavolat a jaké parametry jí má předat. Nakonec si ze souboru WSML načte poslední informace potřebné k vytvoření objektu komponenty COM. Nyní dochází k samotnému volání požadované metody objektu COM spolu s požadovanými parametry. Objekt COM požadavek zpracuje a vrátí výsledek zpět serveru SOAP. Ten na základě návratové hodnoty sestaví odpověď ve formátu XML, odpověď vrátí listeneru a ten jí vrátí zpět klientovi SOAP. Klient SOAP nakonec z odpovědi zjistí návratovou hodnotu a vrátí ji aplikaci. Je důležité si uvědomit, že z pohledu uživatele je objekt COM při každém požadavku vytvořen a znovu zrušen. Není proto možné, aby si do příští interakce s uživatelem uchovával jakékoliv stavy, jako jsou například hodnoty vlastností. Ve skutečnosti se objekt COM z důvodu lepší výkonnosti ponechává v paměti i pro případná další volání.

14 4. Podrobný popis UDDI Pro účely tohoto projektu je významný především standard UDDI, který je dále v textu podrobně rozepsán. První specifikace UDDI pochází ze září 2000 a označuje se jako 1.0. Následovala 2.0 (březen 2001) a 3.0 (prosinec 2001). Specifikace UDDI má umožnit podnikům rychle, snadno a dynamicky najít partnera a rozvinout s ním obchodní styky. Toho se dosáhne: popsáním vlastního businessu a služeb, vyhledáním partnerských podniků, které nabízejí služby, jež daný podnik požaduje, propojením s těmito podniky. Obecněji řečeno, UDDI má umožnit širší, snazší a výhodnější spolupráci firem nejrůznějších odvětví z celého světa, která se má následně pozitivně odrazit v jejich ekonomických výsledcích, např. formou úspory nákladů nebo vyšší efektivnosti. Kromě toho UDDI též představuje globální informační a reklamní médium. Podíváme-li se na to z technologického hlediska, UDDI znamená snahu o vytvoření systému pro dynamické vyhledávání, připojování a využívání webových služeb business aplikacemi. Cílem UDDI je přitom poskytnout uživateli jak klasická data (především informace o poskytovateli služby), tak metadata (způsob použití služby) [5]. To se realizuje tzv. UDDI protokolem, který je základem uvedeného standardu. Protokol je založen na (starší) verzi protokolu SOAP (Simple Object Access Protocol), též označované jako "XML Protocol messaging specifications", jejímž tvůrcem je dobře známé konsorcium W3C. UDDI funguje na principu registrace webových služeb jejich poskytovateli. V současné době existuje implementace nesoucí název "The UDDI Business Registry" (čili "UDDI-obchodní rejstřík"), kde producenti těchto služeb registrují svou firmu (popis, druh služeb obecně) a dále konkrétní nabízené webové služby (obvykle formou URL odkazů, a příp. i

15 přesně definovaného typu služby - pomocí tmodelů) a naopak zákaznické podniky zde pak mohou tyto služby vyhledávat. Systém je provozován rovněž pod záštitou OASIS, konkrétně firmami IBM, Microsoft a SAP, jako distribuovaná aplikace se společným rozhraním a průběžnou datovou synchronizací. Je zatím zdarma volně přístupný v režimu 24x7, očekává se připojení dalších uzlů. Kromě toho je samozřejmě možné (a doporučené), aby podobné registry vznikaly nezávisle na čistě privátní bázi, tj. v rámci intranetu, a poskytovaly služby pouze svým registrovaným uživatelům. IBM, Microsoft, resp. Novell nabízejí pro tuto oblast produkty WebSphere UDDI Registry, Microsoft Enterprise UDDI Services in Windows.NET Server, resp. Novell Nsure UDDI Server. Vyhledávání v UDDI lze provést jak podle názvu a dalších charakteristik firmy či verbálního popisu služeb, tak podle vymezeného typu služby. K dispozici je jak webové, tak programové (služební) rozhraní vyhledavače pracující na protokolu SOAP. UDDI ovšem nepředepisuje žádný formát či metodiku pro popis vlastního rozhraní nabízené webové služby. Může se jednat o prostý text, vlastní (uživatelské) XML schéma, nebo kód ve WSDL (Web Services Description Language). Z toho vyplývá, že odpověď vyhledavače může být nesourodá Specifikace UDDI Specifikace UDDI se už od verze 1.0 skládala z několika základních dokumentů, které postupně přibývaly: UDDI Programmer's API - popisuje programové (raději než "programátorské" - pozn.překl.) rozhraní UDDI, které je závazné pro každý UDDI registr. Tedy vlastně metody, kterým odpovídají příslušné vyměňované zprávy v protokolu SOAP. Původně (v1.0) se jednalo především o dotazovací a registrační funkce. UDDI Data Structure Reference - popisuje detailně datové struktury (objekty) používané v UDDI registru, především jejich jednotlivá pole (atributy) a jejich význam [6].

16 UDDI XML Schema - představuje formální zápis datových struktur UDDI v jazyce XML. Uvádí se jako samostatný jazyk (XSD - XML Schema Definition (Language)) UDDI WSDL Service Interface Descriptions - popis registru UDDI (jakožto webové služby) v jazyce WSDL, jakási "metametadata". UDDI tmodel - popisuje tmodely potřebné pro vnitřní fungování UDDI registru, povinně implementované UDDI Replication Specification a XML Schema - popisují proces replikace dat a příslušné interface mezi jednotlivými distibuovanými UDDI uzly. K tomu se váže též dokument UDDI Operator's Specification s požadavky na provozovatele uzlu Datové struktury UDDI UDDI umožňuje: vyhledání webové služby podle definovaného rozhraní, vyhledání producenta podle zvolených klasifikačních znaků, zjištění podporovaných protokolů dané webové služby, vyhledání webové služby podle klíčových slov, uložení zjištěných informací (např. během tvorby aplikace) a jejich online update za běhu. Specifikace UDDI popisují obsah UDDI serveru a zprávy používané pro komunikaci se serverem. Popis v další části textu se bude týkat specifikací UDDI verze 2.0, které zahrnují specifikaci datové struktury, která definuje obsah UDDI registru, a API specifikaci, která definuje zprávy zasílané do a z registrů. K tomu slouží následující datové struktury (objekty), obsah registrů: businessentity - popisuje poskytovatele služeb: jeho název a popis v různých jazycích, kontakt, klasifikační znaky. Může dále obsahovat

17 vnořené objekty businessservice a bindingtemplate, sloužící k popisu poskytovaných služeb. businessservice - představuje seznam poskytovaných služeb : u každé název, popis, klasifikační znaky. Každá businessservice je podřízena jediné businessentity. bindingtemplate - popisuje konkrétní webovou službu, a to z čistě technologického hlediska (jakým způsobem se k ní připojit): obsahuje buďto její adresu (typicky URL) nebo nepřímý odkaz. tmodel (celým názvem Technical Model) - představuje abstraktní vlastnost/atribut/rozhraní jiného UDDI objektu. Každá detailní specifikace, každý typ přenosu, protokol nebo jmenný prostor jsou dány jedním tmodelem, který může být zapsán např. pomocí WSDL nebo XSD (XML Schema Definition). Každá bindingtemplate pak obsahuje odkazy na relevantní tmodely, které popisují jednotlivé vlastnosti dané webové služby a v souhrnu vlastně určují její typ. Webové služby jsou stejného typu, pokud obsahují odkazy na stejné tmodely. Každý tmodel může být samozřejmě takto použit libovolněkrát. Z hlediska fyzické realizace je podstatné, že tmodel opět obsahuje pouze odkazy na definiční dokumenty, nikoli přímo definici daného rozhraní. publisherassertion vztah mezi dvěmi jednotkami businessentity Jednotka businessentity může obsahovat žádnou nebo několik jednotek businessservice, které mohou obsahovat žádnou či více jednotek bindingtemplate. Jednotka bindingtemplate se může vztahovat k jedné či více jednotkám tmodel a publisherassertion se vztahuje ke dvěma jednotkám businessentity Programové rozhraní UDDI (UDDI API) UDDI API se skládá z několika dílčích rozhraní, která vznikala postupně. Podstatu služby UDDI nicméně tvoří dvě z nich, přítomné již od verze 1.0:

18 Inquiry API - rozhraní pro dotazování Publication API - rozhraní pro aktualizaci 4.4. Inquiry API Inquiry API slouží k dotazování UDDI registru. Umožňuje tři základní typy dotazů: The browse pattern (procházení) - umožňuje zadat široký dotaz (např. název firmy) a v obdrženém výsledku následně listovat a získávat detailnější informace (např. zvolit ze seznamu služeb podle požadovaných tmodelů). The drill-down pattern (detail) - vrátí záznam (businessentity, businessservice, bindingtemplate, tmodel) podle primárního klíče, slouží ke zpodrobnění nebo opakování předchozího dotazu. The invocation pattern (volání) - vrací informace potřebné k volání zvolené webové služby, zajišťuje dynamickou vazbu - jedná se především o vrácení aktuální bindingtemplate v případě, kdy dříve nalezená služba z nějakých důvodů neodpovídá. K realizaci uvedených dotazů slouží následující funkce (metody). Všechny jsou synchronní a přístupné pomocí HTTP/POST. Metody vracejí seznamy objektů, z nichž každý má ve specifikaci opět vlastní název (kvůli přehlednosti není uveden). Kromě toho je vhodné rozdělit metody na dva typy: metody find_, sloužící k hledání podle různých kritérií, a metody get_, vracející objekty podle primárního klíče. find_binding - vrací seznam bindingtemplate (k množině businessservice) find_business - vrací seznam businessentity find_relatedbusinesses - vrací seznam businessentity, které mají potvrzený vztah k zadané businessentity (viz též 2.3.2, metoda add_publisherassertions)

19 find_service - vrací seznam businessservice (k množině bussinessentity) find_tmodel - vrací seznam tmodelů get_bindingdetail - vrací seznam bindingtemplate - za účelem volání služeb (invocation) get_businessdetail - vrací seznam businessentity get_operationalinfo - vrací interní data UDDI objektů (čas poslední aktualizace, uzel registrace, identitu zakládajícího uživatele) get_servicedetail - vrací seznam businessservice get_tmodeldetail - vrací seznam tmodelů Metody find_ umožňují použití sady operátorů označované jako Find Qualifiers. Metody find_binding, find_business a find_service umožňují navíc ještě vnořené dotazy Publication API (a primární klíče UDDI) Publication API slouží k publikování, resp. aktualizaci dat v UDDI registru. Uživateli je přitom ponechána možnost a zodpovědnost, aby si zvolil uzel UDDI, který bude nadále výlučně k publikování využívat. Případné duplicity záznamů nejsou nijak řešeny. Metody rozhraní jsou opět synchronní, a navíc atomické (tj. mají charakter transakce). Základní otázkou při zápisu do UDDI registru jsou primární klíče. Nejprve popišme, jakou mají tyto klíče strukturu. Primární klíč UDDI (uddikey) je založen na všeobecně známých principech URI (Uniform Resource Identifier, RFC 2396) a UUID ((formatted) Universally Unique Identifier, OSF) a má jednu ze tří následujících podob: uuidkey - uddi:<uuid>, přičemž <uuid> představuje řetězec 8,4,4,4,12 hexadecimálních číslic oddělených pomlčkami (dohromady 128 bitů), celkově tedy uuidkey např. uddi:4cd7e4bc- 648B-426D EAAC8AE23.

20 domainkey - uddi:<doména> (podle RFC 2459) derivedkey - uddi:<uuid>:<kss>[:<kss>...], kde <kss> znamená "key specific string" a představuje řetězec alfanumerických a některých dalších povolených znaků, který se může libovolněkrát opakovat. Existují dvě možnosti generování nových klíčů: automatické přidělení ze zvoleného uzlu - řídí se následujícími hierarchickými pravidly : každý uzel má právo generovat klíče z předem určené podmnožiny (partition) všech uddikey, a dále toto oprávnění delegovat - k tomu slouží tmodel keygenerator, který se "restriktivně dědí". Přesněji řečeno, vlastník keygeneratoru může přidávat na konec klíče libovolné kss, přidělený začátek však musí dodržet. Na nejvyšší úrovni nutně existuje několik uzlů, které spravují celý prostor uddikey (root partition), a to jsou právě uzly "The UDDI Business Registry". návrh uživatele (v orig. publisher) - pokud k tomu obdržel od příslušného uzlu oprávnění, tj. svůj keygenerator (tato možnost vlastně představuje nejnižší úroveň hierarchie, která už nikomu dalšímu služby generování klíčů neposkytuje). První způsob je na rozdíl od druhého vždy dostupný. Použije se vždy v případě, že uživatel klíč nezadal. Metody Publication API: add_publisherassertions - přidá jednu nebo více vazeb vlastních businessentity na jiné businessentity, vlastní nebo cizí (tj. mající jiného vlastníka). Slouží k realizaci metody find_relatedbusinesses, která vrací seznam businessentity s komplementárními vazebními atributy (např. mateřská<->dceřinné společnosti). Vazba má podobu tvrzení (assertion), což znamená, že v případě cizí businessentity musí její vlastník příslušnou vazbu potvrdit, jinak

21 zůstane neviditelná. Z datového hlediska jsou tvrzení realizována objekty publisherassertion delete_binding - provede výmaz zadané bindingtemplate delete_business - provede výmaz zadané businessentity delete_publisherassertions - provede výmaz jednoho nebo více zadaných vazebních tvrzení, s dopadem na viditelnost příslušných vazeb delete_service - provede výmaz zadané businessservice delete_tmodel - skryje uživateli informace o zadaném tmodelu. tmodel zůstává uložen v registru a je nadále přístupný odkazem, a rovněž pomocí metody get_tmodeldetail, ale neobjevuje se ve výstupech metody find_tmodel. Fyzický výmaz tmodelu provést nelze get_assertionstatusreport - vrací seznam vazebních tvrzení, jednak publikovaných daným uživatelem o vlastních businessentity, jednak tvrzení jiných uživatelů o těchto businessentity. Slouží ke správě publikovaných tvrzení get_publisherassertions - vrací seznam vazebních tvrzení, (oproti předchozí metodě pouze) publikovaných daným uživatelem o vlastních businessentity get_registeredinfo - vrací stručný seznam businessentity a tmodelů spravovaných daným uživatelem. Slouží ke správě vlastních dat save_binding - vloží nebo aktualizuje (pokud již existuje) jednu či více zadaných bindingtemplate save_business - vloží nebo aktualizuje (pokud již existuje) jednu či více zadaných businessentity save_service - vloží nebo aktualizuje (pokud již existuje) jednu či více zadaných businessservice save_tmodel - vloží nebo aktualizuje (pokud již existuje) jeden či více zadaných tmodelů

22 set_publisherassertions - nahradí současný seznam vazebních tvrzení daného uživatele zadaným seznamem (existující tvrzení, která nejsou uvedena, jsou odstraněna) [12] 4.6. Zprávy Když klientské aplikace objeví informaci o webových službách, tak posílají do UDDI registrů zprávy typu Inquiry, pokud klientské aplikace registrují informace o webových službách, posílají zprávy typu Publishing. Jako odpověď na oba druhy zpráv odesílá webová služba zprávu typu Reponse. Následující typy zpráv lze zasílat do a z registrů: zprávy typu Inquiry slouží k hledání potenciálně použitelných objektů a k získání detailních informací o daných objektech zprávy typu Publishing vytvářejí a udržují obsah registrů zprávy typu Response poskytují výsledky vyhledávání Všechny typy zpráv se dále dělí do několika podtypů, v závislosti na funkčních charakteristikách. Následující schéma popisuje celkový konceptuální model UDDI včetně obsahu registrů, zpráv do registrů zasílaných a odpovědí, které registry vracejí. Schéma č. 6 popisuje celkový konceptuální model UDDI včetně obsahu registrů, zpráv do registrů zasílaných a odpovědí, které registry vracejí: