Domov › Služby › Služba Wsdl. Jazyk popisu webových služeb (WSDL): Andrew Troelsen. Odesílání složitých objektů

Služba Wsdl. Jazyk popisu webových služeb (WSDL): Andrew Troelsen. Odesílání složitých objektů

Vazebné rozšiřující prvky se používají ke specifikaci konkrétní gramatiky pro příchozí (3) a odchozí (4) chybové zprávy (5). Mohou být také specifikovány informace o provozní úrovni (2) a úrovni vazby (1).

Prvek vazby operace obsahuje data pro operaci se stejným názvem přidruženého typu portu. Nicméně název operace v obecný případ není unikátní (příklad: přetížení metod/funkcí – použití stejných jmen s různými signaturami), proto nemusí stačit jednoznačně určit cílovou operaci typu portu. V takových případech se cílová operace řeší pomocí dodatečný úkol odpovídající názvy prvků wsdl:input a wsdl:output pomocí atributu name.

Vazba by měl nainstalovat pouze jeden protokol.

Vazba neměl by obsahovat informace o adrese.

Přístav

Port definuje jeden koncový bod nastavením adresy, na kterou se má navázat.

<wsdl:definice .... >
<wsdl:servis .... > *
<wsdl:přístav name = "nmtoken" binding = "qname" > *
<-- extensibility element (1) -->
wsdl:přístav>
wsdl:servis>
wsdl:definice>

Atribut name určuje jedinečný název mezi všemi porty v dokumentu WSDL. Atribut vazby typu QName obsahuje odkaz na vazbu (viz).

Rozšiřující prvky (1) slouží k upřesnění adresy.

Přístav neměl by uveďte více než jednu adresu.

Přístav neměl by obsahovat jakékoli jiné závazné informace než adresu.

Servis

Služba spojuje dohromady sadu souvisejících portů.

<wsdl:definice .... >
<wsdl:servis name = "nmtoken" > *
<wsdl:přístav .... /> *
wsdl:servis>
wsdl:definice>

Atribut name určuje jedinečný název mezi všemi službami definovanými v dokumentu WSDL.

Porty v rámci služby jsou připojeny následovně:

Porty spolu nekomunikují (to znamená, že výstup jednoho portu není vstupem druhého).
Pokud má služba více portů, které sdílejí obecný typ porty, ale používají jiné vazby nebo mají různé adresy, takové porty jsou alternativní. Každý takový port implementuje logicky ekvivalentní chování (v rámci omezení transportu a formátu zpráv stanovených příslušnou vazbou). To umožňuje klientovi vybrat konkrétní port pro komunikaci na základě různých kritérií (podpora transportního protokolu atd.).
Když se podíváte na porty, můžete určit, které typy portů služba podporuje. Na základě těchto údajů může klient určit schopnost interakce s konkrétní službou. To je užitečné, pokud existuje spojení mezi operacemi z různých typů portů a služba potřebuje podporovat všechny požadované typy portů k provedení určitého úkolu.

Toto je bezplatný, částečný, rozšířený překlad dokumentu Web Services Description Language (WSDL) 1.1 ze dne 15. března 2001
Je krajně nepohodlné operovat s latinsky napsanými nesklonnými termíny a navíc jsou jednoznačně přeloženy. Původní název je proto uveden pouze při zavedení nového termínu a dále v textu je použit ruský překlad.

V tomto článku budu hovořit o tom, co je soubor WSDL, proč je potřeba a jak s ním pracovat.

Mapa článku

Co je WSDL

WSDL je jazyk pro popis webových služeb, který má XML struktura. Hlavním účelem souboru WSDL je jako rozhraní pro přístup k funkcím služeb a návratovým datovým typům; cesta k serveru zpracovávajícímu požadavky atd.

Cesta k souboru wsdl obvykle vypadá takto: http://host/services/wsdl/gbdar-v2-2.wsdl

Existuje mnoho nástrojů, knihoven navržených pro čtení souboru WSDL.

SoapUi

Jedním z takových nástrojů je soapUi(). Instalací distribuce navržené pro vaši platformu můžete vytvořit nový projekt týmem projektu File/New SoapUi. V dialogu pro vytvoření nového projektu ponechte zaškrtávací políčko Vytvořit vzorové požadavky zaškrtnuté

Provádění dotazů

V novém projektu budou automaticky vytvořeny šablony požadavků pro službu, jejichž popis je obsažen v souboru wsdl. Vlevo ve stromu uvidíte seznam funkcí obsažených v souboru WSDL. Vysvětlím funkci Replikace. Uvnitř je požadavek Request1, poklepáním na něj uvidíme dialog se šablonou požadavku, místo výchozích parametrů budou otazníky. Aby se funkce provedla správně, musíte vyplnit všechny parametry, které nejsou označeny tagem Volitelné, a poté kliknout na zelený trojúhelník v levém horním rohu dialogu.

Pokud jsou všechny parametry zadány správně, odpověď služby na požadavek se zobrazí vpravo.

SoapUi poskytuje možnost zobrazit parametry souboru WSDL, abyste to udělali, musíte dvakrát kliknout na název rozhraní (označeno zelenou ikonou ve stromu souborů WSDL, pro mě - gdbar-v2-2SOAP). V dialogu najdete:

Karta Přehled - popis obecné parametry WSDL, seznam funkcí a souvisejících akcí serveru
Záložka Koncové body služby — cesta k serveru a další parametry
Obsah WSDL - strom navigace v souborech
Soulad s WS-I — zde můžete vytvořit sestavu WS-I na rozhraní

Generování dokumentace

SoapUi nám umožňuje generovat dokumentaci funkcí WSDL. Chcete-li to provést, klepněte na klikněte pravým tlačítkem přes rozhraní a zavolejte příkaz Generovat dokumentaci. V důsledku toho obdržíme podrobný manuál ve formátu html.

To je vše, přihlaste se k odběru nových příspěvků, zanechte komentáře, udělejte návrhy na vylepšení článku.

Standardizovaný popis usnadňuje pochopení a použití. Řekněme, že jste našli službu, která řeší problémy, které potřebujete, a chcete ji použít ve svých řešeních. Nejjednodušší způsob, jak získat informace o návrhu někoho jiného a jeho schopnostech, je podívat se na popis WSDL. Dokumenty WSDL se mohou skládat z více modulů nebo odkazovat na jiné dokumenty nebo schémata XML (XSD), která popisují datové typy používané ve webové službě. Zpočátku bylo navrženo několik možností pro zachování popisu a dva hlavní hráči - Microsoft a IBM - představili svou vizi tohoto problému. První vyvinul a navrhl SDL (Service Description Language), který byl součástí první verze SOAP Toolkitu společnosti. IBM představilo svou vizi problému v Network NASSL (Accessible Service Specification Language), který byl implementován v SOAP4J jako sada NASSL Toolkit. Myšlenky navržené v NASSL inspirovaly Microsoft k pokračování ve vývoji jazyka popisu, což vedlo ke zrodu SOAP Contract Language (SCL). Toto řešení se ukázalo jako velmi efektivní, bylo doladěno s ohledem na přání výrobců třetích stran a 15. března 2001 se nápady staly specifikací WSDL 1.1. Počítačový obor samozřejmě nemůže žít tolik let beze změn, proto se 27. března 2006 objevila verze 2.0 a od 26. června 2007 má poradní charakter.

Reference příkazů Unix/Linux

Příběh

WSDL 1.0 (září 2000) byl vyvinut společnostmi IBM, Microsoft a Ariba k popisu webových služeb pro sadu nástrojů SOAP.

WSDL 1.1, vydané v březnu 2001. Ve skutečnosti se jedná o formalizovaný WSDL 1.0. Mezi těmito verzemi nejsou žádné zásadní rozdíly.

WSDL 1.2 (červen 2003) stále funguje pod W3C. WSDL 1.2 není podporováno většinou výrobců SOAP.

WSDL 2.0 získal oficiální podporu od W3C v červnu 2007. WSDL 1.2 byl přejmenován na WSDL 2.0, protože měl velké rozdíly od předchozí verze.

Design webových služeb

Autorovo použití termínu webové služby se vztahuje výhradně na typ technologie, která se zaměřuje na interakci. To znamená, že tato technologie je standardizovaná: heterogenní systémy fungují pouze tehdy, pokud existují otevřené standardy. V tomto případě je relevantní otázka: budou webové služby řešením vašeho problému? Slovo „webové služby“ dnes již nestačí k tomu, abychom hovořili o renomé společnosti, která je používá, a proto by bylo lepší, kdyby pro jejich používání existovaly další pádné důvody. Pokud sledujete oba konce kanálu, je možné, že jich je více vhodné technologie. Teď je jen úsvit jedné éry otevřené standardy distribuované zpracování dat. Proto náklady na podporu webových služeb na tomto dosud nezformovaném trhu zůstávají vysoké – to znamená pokles produktivity, zvýšení nákladů na vývoj a zhoršení bezpečnosti. Myšlenka, že webové služby jsou „přátelské k firewallu“, je zavádějící. Konvenční firewally skutečně chrání podniková aktiva před „útočníky“, kteří je používají slabá místa v aplikačním softwaru, vyplývající z otevření portů, na kterých jsou vykonávány chráněné služby. Na druhou stranu webové služby odhalují aplikační software prostřednictvím těchto portů.

Jinými slovy, oslabují zabezpečení tím, že umožňují neoprávněným lidem přístup k aplikacím – přesně tomu, čemu by měl zabránit síťový firewall. Proto je potřeba nová generace firewallů. Na trhu již existuje několik nových hráčů, kteří takové produkty nabízejí. Tomuto problému začínají věnovat pozornost i běžní výrobci firewallů. Ale to je jen začátek a taková technologie se ještě musí osvědčit. I když plánujete používat webové služby, musíte mít na paměti, že nemusíte používat SOAP. Autor tohoto článku například viděl formuláře předané jako argument požadavku vzdáleného volání procedur SOAP (SOAP-RPC). Setkal se také s formuláři, které byly vráceny jako součást odpovědi vzdáleného volání procedury SOAP. Nikdy nebyl schopen najít žádnou další výhodu z používání SOAP. Pokud lze distribuované komponenty vyvíjet v různých programovacích jazycích, pak je pro specifikaci toho, jak mají být služby používány, zapotřebí jazyk IDL (Interface Definition Language) neutrální pro programovací jazyk. Ve společnosti CORBA ( Obecná architektura zprostředkovatel požadavků na objekt, architektura Common Object Request Broker, jako je DCOM (Distributed Component Object Model), existuje takový jazyk. IDL je smlouva mezi iniciátorem služby a poskytovatelem, ale shromažďuje pouze syntaxi. Sémantika zůstává nejasná: IDL nechává otevřenou otázku, co služba dělá. WSDL je IDL webových služeb. Popisuje, jak volat webové služby. Také definuje odpovědi, které mohou nebo nemusí být přijaty, když je volání úspěšné.

Specifikace WSDL přísně reguluje formát zpráv, používané protokoly a adresu, kde jsou umístěny služby. Bohužel ani jasný a strohý popis ve WSDL nezaručuje vysokou kvalitu provedení. Jako všechny jazyky IDL je WSDL silný v syntaxi a slabý v sémantice. Neměli bychom je však zanedbávat – v konečném důsledku je to sémantika, která je důležitá a syntaxe se používá pouze k jejímu odhalení.

Design rozhraní

Než začnete psát WSDL, musíte se se svými zákazníky dohodnout, co by webová služba měla dělat. Případy použití by měly být zaznamenány, jasně definující, jak služba interaguje se svým prostředím. Předpokládejme, že agentský program (herec) volá za nějakým účelem webovou službu. V tomto případě musíte vytvořit nejen scénář „slunečného dne“, který implementuje úkol, ale scénář „deštivého dne“, kdy je výsledek negativní. Jaké záruky může systém nabídnout, že cíle bylo úspěšně dosaženo? A kdy ne? Kde je hranice odpovědnosti mezi klientem a serverem? Význam jasného definování požadavků nelze přeceňovat. V této fázi stojí za to přemýšlet o účelu projektu. co to přesně je? Jaká data je třeba přijímat od klienta a co by měl dodávat server? Chyba v tomto kroku může mít za následek značné náklady. Zvažte například webovou službu, která jako parametry bere seznam nainstalovaných programů a množství volného místa na disku. Tato služba by pak měla vrátit seznam aplikací k aktualizaci.

Pokud je dostatek místa, nejsou žádné problémy. Co když to však nestačí? Jak mohu vybrat produkty, pro které potřebuji nainstalovat nové verze? Má klient sám mazat staré verze programů, aby uvolnil místo pro nové? Nejsou to jednoduché otázky, jejichž řešení bude vyžadovat vývoj složitých algoritmů, jejichž implementace může obsahovat chyby. Žádný systém by samozřejmě neměl být takto definován. Server musí poskytnout seznam aplikací, závislostí mezi nimi a požadavků na zdroje, které kladou. Je na odpovědnosti klienta, aby se rozhodl, který balíček nainstalovat. Svěřením tohoto úkolu serveru tedy klient nic nezíská, pouze zvýší náklady na vývoj serverové části. Proto je nutné analyzovat náklady počáteční fáze. V takovém případě můžete technické detaily ignorovat – na službu lze nahlížet jako na černou skříňku. Ale nemůžeme opomenout detaily týkající se interakce mezi touto službou a jejím prostředím. Dalším krokem je analyzovat, jak lze případy použití implementovat.

Bude existovat jediné rozhraní (portType ve WSDL verze 1.1), které poskytuje všechny funkce? Nebo více rozhraní? Každé rozhraní může být nabízeno na více koncových bodech, ale obecně musí být nedělitelné. To znamená, že koncový bod musí poskytovat buď všechny funkce, nebo nic. Stejně tak rozhraní musí být sémanticky konzistentní. Výše uvedené má být vodítkem a věcí zdravého rozumu, ačkoli nic ve specifikaci WSDL nebrání jiné interpretaci. Jsou vyžadována nějaká podpůrná rozhraní? Jak a kdy by měli být voláni? Jaká je povaha této závislosti? Zatím neexistují žádné standardy, pouze doporučení, jak zacházet s „servisními choreografiemi“, jak umožnit službám hypertextové odkazy na jiné služby. Jinými slovy, toto je neprobádaná problémová oblast.

WSDL (Jazyk popisu webových služeb) verze 1.1 byla zveřejněna 15. března 2001. WSDL je formát založený na XML používaný k popisu webových služeb pomocí zpráv obsahujících informace o tom, jak přistupovat ke konkrétní webové službě. WSDL rozšiřitelný, který umožňuje popisovat služby (služby) a jejich zprávy bez ohledu na to, jaké formáty zpráv resp síťových protokolů se používají pro přenos, nejčastěji se však používá WSDL 1.1 spolu s SOAP 1.1, HTTP GET/POST a MIME. Protože WSDL byl vyvinut společně se SOAP a na jeho vývoji se podílely stejné společnosti Microsoft, Ariba a IBM. Pokud vezmeme v úvahu dokument WSDL intuitivně lze říci, že umožňuje odpovědět na 4 otázky:

1) co děláš? Odpověď na tuto otázku je dána formou vhodnou pro lidské vnímání i strojově vnímatelnou formou. Odpověď pro osobu ve značkách:<jméno/>, <dokumentace/>, pro auto -<zpráva/>, <pointType>

2) jakým jazykem mluvíš? (jaké typy používáte?) Odpovězte v tagu:<typy/>

3) jak s tebou budu komunikovat? (jak bude klient přistupovat k webové službě?): HTTP nebo SMTP. Odpověď spočívá v<vazba/>

4) kde tě najdu? (kde najdu tuto webovou službu nebo jaká je její URL?). Odpověď zní:<servis/>

Struktura:

Každý dokument WSDL lze rozdělit do tří logických částí:

1. definování datových typů - určení typu zpráv odesílaných a přijímaných službou XML

2. abstraktní operace - seznam operací, které lze provádět se zprávami

3. propojení služeb - způsob, jakým bude zpráva doručena

Dokumenty WSDL lze vytvořit ručně, ale jazyk je přísně formalizován WSDL umožňuje automatizovat proces psaní WSDL- dokumenty. Mnoho nástrojů pro tvorbu webových služeb obsahuje nástroje, které se automaticky vytvářejí WSDL-soubory popisující hotové webové služby. Například Web Services Authoring Tool Apache Axis obsahuje třídu Java2WSDL, vytváření WSDL- soubor třídy Java nebo rozhraní, které popisuje webovou službu. Balíček IBM WSTK, který obsahuje Osa, obsahuje utilitu java2wsdl, který vytvoří a spustí objekt z této třídy. Funguje z příkazového řádku.

Prvky dokumentu WSDL

Pojďme si popsat nejčastěji používané značky WSDL:

Štítek je kořenový tag všech dokumentů WSDL. Definuje několik jmenných prostorů:

1)target Jmenný prostor je jmenný prostor naší webové služby

2) xmlns – standardní jmenný prostor dokumentu WSDL

3)xmlns: SOAP_ENC – jmenný prostor používaný k popisu kódování SOAP

4) xmlns: impl a intf – jmenný prostor implementace a definice naší webové služby

· Dokument definice webové služby

· Dokument pro implementaci webové služby

Pro jednoduchost zpravidla používají 1 soubor, který obsahuje všechny informace

Živel - poskytuje informace o datech, která jsou přenášena z jednoho koncového bodu do druhého.

Chcete-li popsat volání RPC, musíte vytvořit vstupní zprávu a výstupní zprávu.

V rámci tohoto prvku můžete pomocí prvku určit parametry metody

Živel popisuje a definuje operace nebo metody podporované webovou službou

Operace mohou mít vstupní zprávy i chybové zprávy.

Živel - popisuje, jak budou operace specifikované v typu portu přenášeny po síti. Protože element používá typ portu, musí specifikovat typ definovaný někde dříve v dokumentu.

Živel - označuje, kde najít webovou službu

Živel importovat . Velmi často je prvek služby přiřazen k jeho dokumentu wsdl z praktických důvodů.

Aby bylo možné jeden dokument wsdl sestavit do jednoho, použije se prvek import. Umožňuje zahrnout jeden dokument wsdl do druhého.

Živel typy umožňuje určit typy přenášených dat, pokud nejsou standardní.

WSDL podporuje 4 režimy operací:

· jednosměrné nebo jednosměrné operace. Zpráva je odeslána do koncového bodu služby. V tomto případě je operace popsána pouze jednou vstupní zprávou.

· Request-Response – režim požadavek-odpověď. Tento způsob provozu je nejběžnější. V tomto režimu popis operace obsahuje vstupní zprávu, výstupní zprávu a volitelnou chybovou zprávu.

· Operace typu požadavek-odpověď. V tomto režimu je koncový bod klientem jiného koncového bodu. Operační formát je podobný režimu požadavek-odpověď, ale výstupní data jsou uvedena před vstupními daty.

· Oznámení o operaci. Tento režim je další verzí primitiva jednosměrného přenosu, ve kterém koncový bod zprávu spíše odesílá, než přijímá. Operace obsahuje pouze výstupní zprávu.

Jak WSDL 1.1 definuje webové služby a jak vytvořit modely Java pro ověřování a transformaci dokumentů WSDL

Obsahová řada:

O této sérii článků

Webové služby - důležitou funkci Technologie Java™ v podnikových počítačích. V této sérii článků hovoří konzultant XML a webových služeb Denis Sosnovsky o hlavních strukturách a technologiích, které jsou cenné pro vývojáře v jazyce Java používající webové služby. Sledujte články v seriálu, abyste měli přehled o nejnovějším vývoji v této oblasti a věděli, jak je aplikovat ve svých vlastních projektech.

Webové služby pro podnikové aplikace silně spoléhají na použití definic služeb. Definice služeb popisují základní dohodu mezi poskytovatelem služeb a jakýmkoli potenciálním spotřebitelem, podrobně popisují typy funkcí poskytovaných službou a zprávy v rámci každé funkce. Poskytovatelé a spotřebitelé se mohou svobodně rozhodnout, jak implementovat své výměnné objekty, pokud skutečné zprávy, které odesílají, odpovídají definici služby. Použití definice služby, která popisuje, jak se vyměňují zprávy XML, je to, co odlišuje webové služby od dřívějších technologií distribuovaného programování.

Byly nabídnuty různé metody definice webových služeb, ale nejpoužívanějším přístupem zůstává WSDL 1.1. WSDL 1.1 má některé nedostatky, včetně příliš složité struktury, která znesnadňuje čtení pro nezasvěcené. Také trpí nedostatkem autority formální definice, což má za následek postupná "upřesnění", která vyplňují některé mezery v původním dokumentu specifikace. V důsledku toho se zásobníky webových služeb snaží zpracovávat dokumenty WSDL 1.1 co nejpružněji. Tato flexibilita může zvýšit zmatek v chápání WSDL 1.1, jak vývojáři vidí široký rozsah WSDL struktury bez jakéhokoli označení, který přístup je výhodnější.

V tomto článku vám ukážeme, jak analyzovat dokumenty WSDL 1.1, a podíváme se na první části modelu Java pro ověřování dokumentů WSDL a jejich převod do standardní podoby.

Analýza WSDL 1.1

Použité jmenné prostory

Tento článek používá:

prefix wsdl představující jmenný prostor WSDL 1.1 http://schemas.xmlsoap.org/wsdl/ ;
předponu soap pro http://schemas.xmlsoap.org/wsdl/soap/ jmenný prostor používaný rozšířením SOAP 1.1 pro WSDL 1.1;
prefix xs pro http://www.w3.org/2001/XMLSchema jmenný prostor používaný pro definice schématu XML.

Revize 1.1 WSDL, publikovaná na začátku roku 2001, byla technicky nahrazena doporučeními W3C WSDL 2.0, publikovanými v roce 2007. WSDL 2.0 nabízí čistší strukturu než WSDL 1.1 spolu s větší flexibilitou. Ale WSDL 2.0 trpí problémem slepice a vejce: WSDL 2.0 není široce používán, protože není široce podporován, a protože není široce používán, vývojáři balíků webových služeb mají malou motivaci jej podporovat. Přes všechny své nedostatky je WSDL 1.1 pro většinu účelů dost dobrý.

Původní specifikace WSDL 1.1 byla nepřesná, pokud jde o počet použitých funkcí. Protože se WSDL zaměřovalo na práci s definicemi služeb SOAP, zahrnovalo také podporu funkcí SOAP (jako je kódování RPC), které se později ukázaly jako nežádoucí. Organizační web Organizace pro interoperabilitu služeb (WS-I) řeší tyto problémy v základním profilu (BP), který poskytuje praktické pokyny pro webové služby využívající SOAP a WSDL. BP 1.0 byl schválen v roce 2004 a BP 1.1 byl vydán v roce 2006. Tento článek se zabývá WSDL 1.1 na základě doporučení WS-I BP a nedotýká se skutečně zastaralých funkcí, jako je kódování RPC pro SOAP.

Předpokládá se, že struktura dokumentů XML je určena definicemi schématu XML. Původní specifikace WSDL 1.1 obsahovala popis schématu, ale schéma se v několika ohledech neshoduje s textovými popisy. To bylo později opraveno upravená verze schéma, ale dokument WSDL 1.1 nebyl upraven tak, aby odrážel tuto změnu. Tým BP WS-I se pak rozhodl přispět více více změn do schématu WSDL a vytvořil to, co se nabízí jako praktické pokyny pro toto kluzké schéma. Dokumenty napsané pro jednu verzi schématu obecně nejsou kompatibilní s jinými verzemi (navzdory použití stejného jmenného prostoru), ale naštěstí většina nástrojů webových služeb schéma do značné míry ignoruje a přijímá vše, co vypadá rozumně. (Viz odkazy na mnoho schémat WSDL v této části).

Ani verze BP WS-I schématu WSDL 1.1 příliš nezajišťuje shodu se specifikací dokumentu WSDL 1.1. Diagram neodráží všechna omezení WS-I BP, zejména s ohledem na pořadí komponent. Schéma XML navíc není schopno zpracovat mnoho typů snadno nastavitelných omezení v dokumentech (jako jsou alternativní atributy nebo požadované další prvky ze samostatného schématu). Ověření, že dokument WSDL 1.1 odpovídá specifikaci WSDL 1.1 (ve znění změn WS-I BP), proto zahrnuje mnohem více než jen provedení ověření schématu XML. K tomuto tématu se vrátíme později v tomto článku. Nejprve se však podívejme na strukturu popisů služeb WSDL 1.1.

Popis Komponenty

Dokumenty WSDL 1.1 používají pevný, vhodně pojmenovaný kořenový prvek . V rámci tohoto kořenový prvek jmenný prostor WSDL 1.1 definuje jeden "pasivní" podřízený prvek (prostě odkaz na jednotlivé dokumenty WSDL 1.1) a pět "aktivních" prvků podřízené prvky(které ve skutečnosti tvoří popis služby):

odkazuje na samostatný dokument WSDL 1.1 s popisy, které mají být součástí tohoto dokumentu;
definuje typy XML nebo prvky používané pro zasílání zpráv;
definuje skutečnou zprávu z hlediska typů nebo prvků XML;
definuje abstraktní sadu operací prováděných službou;
definuje skutečnou realizaci používání specifických protokolů a formátů;
definuje službu jako celek, obvykle zahrnující jeden nebo více prvků s přístupovými informacemi pro prvky .

Existuje také prvek , který lze použít pro účely dokumentace jako první podřízený prvek , stejně jako první potomek kteréhokoli z výše uvedených prvků.

Úplný popis služby obvykle vyžaduje alespoň jeden prvek každého z těchto typů, s výjimkou , ale nemusí být všechny ve stejném dokumentu. Chcete-li sestavit kompletní Popisy WSDL lze použít z několika dokumentů , která umožňuje rozdělit popisy tak, aby vyhovovaly potřebám organizace. Například první tři prvky popisu ( , A ) společně tvoří úplný popis rozhraní služeb (možná definované skupinou architektur), takže má smysl držet je odděleně od prvků orientovaných na implementaci A . Všechny hlavní balíčky webových služeb podporují rozdělení popisů do více dokumentů WSDL.

Výpis 1 ukazuje příklad popisu služby WSDL rozděleného do dvou dokumentů WSDL, takže komponenty popisu rozhraní jsou obsaženy v souboru BookServerInterface.wsdl a komponenty implementace jsou obsaženy v souboru BookServerImpl.wsdl. Výpis 1 ukazuje BookServerInterface.wsdl.

Výpis 1. BookServerInterface.wsdl

Definice rozhraní služby knihy. ... ... Implementace knižní služby. To vytvoří počáteční knihovnu knih při načtení třídy a poté podporuje volání metod pro přístup k informacím o knihovně (včetně přidávání nových knih). Získejte knihu s konkrétním ISBN. ... Přidat novou knihu.

Výpis 2 ukazuje BookServerImpl.wsdl. Živel na začátku importuje popis rozhraní BookServerInterface.wsdl.

Výpis 2. BookServerImpl.wsdl

Definice vlastní implementace knižní služby. ...

Kromě definic prvků (a atributů) ve jmenném prostoru WSDL 1.1 definuje WSDL 1.1 také další prvky. Jsou určeny k vyplnění specifických buněk v popisech služeb WSDL 1.1 pro přenos další informace požadované pro konkrétní typ služby. Jediné další prvky WSDL 1.1, které jsou stále široce používány, jsou vazby pro SOAP 1.1 (ty jsou představeny v , v prvcích A ), které byly definovány v původní specifikaci WSDL 1.1, a pro SOAP 1.2, definované samostatnou specifikací v roce 2006.

Podrobnosti součásti

Živel obsahuje všechny definice XML používané pro zprávy jako jeden nebo více prvků . (WSDL umožňuje alternativy schématu XML pro tyto definice, ale většina zásobníků podporuje pouze schémata XML.) V případě potřeby prvky lze použít nebo zahrnout další schémata mimo WSDL (stejně jako odkazovat na samostatná schémata v rámci stejného WSDL).

Od jednoho prvku může obsahovat libovolný počet definic schématu, není důvod používat v dokumentu WSDL více než jeden prvek . K prvku se nachází v horní části BookServerInterface.wsdl.

Kromě A , všechny komponenty nejvyšší úroveň Dokumentu WSDL jsou přiřazena jednotlivá jména pomocí atributu požadovaného názvu. Při použití atributu targetNamespace na kořenovém prvku dokumentu (což je obvykle nejlepší), jsou názvy těchto komponent definovány v tomto cílovém jmenném prostoru. To znamená, že při definování názvu stačí přiřadit jednoduchou nebo "místní" část názvu, ale odkazy na tuto komponentu musí kvalifikovat název pomocí předpony jmenného prostoru nebo pomocí výchozího jmenného prostoru. Obrázek 1 ukazuje nejdůležitější vazby mezi komponentami WSDL, přičemž plné čáry představují odkazy celým jménem a tečkované čáry představují odkazy podle názvu používané pro identifikaci bez kvalifikace jmenného prostoru.

Obrázek 1. Vztahy mezi komponentami WSDL

Zprávy reprezentované prvky , jsou umístěny v jádru popisů služeb WSDL. Prvky jsou popisy dat XML přenášených mezi klientem a poskytovatelem služeb. Každý prvek obsahuje nula nebo více (obvykle jeden) podřízených prvků . Každý prvek součásti vyžaduje svůj vlastní atribut názvu (unikátní uvnitř ) a jeden z atributů prvku nebo typu odkazujících na definici schématu dat XML. Více prvků zobrazeno v , za prvkem v BookServerInterface.wsdl.

Prvky definovat rozhraní abstraktní služby ve smyslu zpráv odeslaných do služby a přijatých ze služby. Prvky obsahovat libovolný počet podřízených prvků . Každý podřízený prvek vyžaduje svůj vlastní atribut názvu (BP WS-I vyžaduje, aby byl jedinečný v rámci ) a obsahuje jeden nebo více podřízených prvků, které popisují zprávy používané operací. Podřízené prvky se dodávají ve třech typech, které odpovídají různému použití:

: data zaslaná klientem poskytovateli služeb jako vstup do operace;
: data vrácená klientovi poskytovatelem služby jako výsledek operace;
: Data vrácená klientovi poskytovatelem služby, když během zpracování dojde k chybě.

WSDL 1.1 definuje několik vzorců interakce mezi klientem a poskytovatelem služeb, reprezentovaných různými sekvencemi podřízených prvků. A , ale ne všechny modely jsou dostatečně dobře definované, aby mohly být implementovány. BP WS-I umožňuje pouze dva modely: operace požadavek-odpověď, kde by měl , a jednosměrné operace obsahující pouze . V případě operací žádost-odpověď (zdaleka nejběžnější typ) za prvky A může následovat libovolný počet prvků .

Každý prvek , nebo odkazuje na popis zprávy prostřednictvím požadovaného atributu zprávy. Toto je kvalifikovaný odkaz na jmenný prostor, takže obvykle vyžaduje přidání předpony. Příklady lze vidět v: například když prvek použitý v popisu operace getBook. (Předpona tns slouží jako definice kořenového prvku se stejným identifikátorem URI jmenného prostoru jako atribut targetNamespace.)

V mnoha ohledech lze považovat za logický ekvivalent rozhraní Java, tedy prvky jsou ekvivalentní metodám, prvkům - parametry metody, prvky - výsledky metod a prvků - zaškrtnuté výjimky. Tyto shody se používají ke generování Java kód z WSDL, stejně jako u většiny nástrojů, které generují WSDL existující kód Jáva.

Srovnání SOAP 1.1 a 1.2

SOAP 1.1 je široce používán pro webové služby od zveřejnění specifikace v roce 2000. SOAP 1.2 byl vyvinut s širší průmyslovou podporou prostřednictvím W3C a publikován jako oficiální standard W3C v roce 2007. SOAP 1.2 je lépe zdokumentovaný a čistší než SOAP 1.1, přičemž některé ošklivé aspekty 1.1 byly chirurgicky odstraněny. Navzdory této vyčištěné struktuře mezi nimi u většiny webových služeb existuje jen malý praktický rozdíl. Snad nejvýznamnějším rysem SOAP 1.2 je to, že je to jediný oficiálně podporovaný způsob, jak využít vylepšenou podporu SOAP pro XML-binary Optimized Packaging (XOP) přílohy a SOAP Message Transmission Optimization Mechanism (MTOM). Ve smyčce Webové služby Java Doposud jsem používal SOAP 1.1, protože některé starší zásobníky nepodporují SOAP 1.2, ale pro vývoj nových webových služeb je 1.2 pravděpodobně lepší volbou.

Prvky představují instanci definovaného abstraktního rozhraní , který je viditelný na začátku BookServerImpl.wsdl. Atribut type obsahuje celé jméno typ portu implementovaného ve vazbě.

Dětské prvky obsahovat podrobné informace o tom, jak je typ portu implementován. Podřízené prvky z oboru názvů WSDL odpovídají prvkům a měl by používat stejnou hodnotu názvu – a ne odkazy s upřesněním jmenného prostoru, jako v případě . toto spojení je v úrovni znázorněno tečkovanými čarami . Stejný vztah podle názvu platí pro podřízené prvky / / prvky . Navzdory tomuto opětovnému použití stejných názvů prvků se obsah těchto prvků výrazně liší, pokud se jedná o podřízené prvky , nikoli prvek .

Do hry vstupují rozšíření definovaná WSDL . Dětský prvek používá se v definici služby SOAP (jediný typ služby povolený WS-I BP, ačkoli WSDL 1.1 také umožňuje vazby HTTP). Tato položka používá atribut požadovaného transportu k určení typu transportu používaného vazbou. (HTTP, jak je vidět v http://schemas.xmlsoap.org/soap/http hodnotě v , je jedinou volbou povolenou WS-I BP.) Volitelný atribut style vám umožňuje vybrat si mezi styly rpc a document pro reprezentaci XML dat (nejčastější hodnota dokumentu odpovídá zprávám používajícím spíše prvky definice schématu než typ).

Uvnitř každého podřízeného prvku živel živel lze použít k určení hodnoty SOAPAction za účelem identifikace požadavků na volání této operace (a potenciálně také k přepsání volby stylu dokumentu nebo rpc určeného prvkem ačkoli BP WS-I takové použití zakazuje). Každý podřízený prvek / / obsahuje další doplňkový prvek, kterým je vždy prvek pro nebo , nebo jeho ekvivalent , používá se s .

Poslední složka Prvek popisu služby WSDL je , který se skládá ze skupiny prvků . Každý prvek spojuje přístupovou adresu s . Přístupová adresa je obsažena ve vnořeném dodatečném prvku .

Práce s WSDL

Není divu, že se všemi odchylkami ve schématech a pravidlech pro dokumenty WSDL 1.1 mnoho dokumentů neodpovídá osvědčeným postupům BP WS-I. Podpora mnoha odchylek od osvědčených postupů napříč sadami webových služeb pomohla zachovat používání zastaralých nebo nesprávných návrhů, což vedlo k šíření špatných postupů v celém odvětví. A rozhodně nejsem vůči této infekci imunní – při pohledu na dokumenty WSDL, které jsem poskytl jako příklady kódu pro tuto sérii, jsem s překvapením zjistil, že žádný z nich není zcela správný.

Když jsem se tedy rozhodl napsat tento článek, řekl jsem si, že by bylo hezké zahrnout nástroj, který vám umožní zkontrolovat dokumenty WSDL podle osvědčených postupů. Zdálo by se, že odtud je pouze jeden krok k převodu dokumentů WSDL do správná forma za předpokladu, že původní WSDL neobsahuje chyby. Ale bylo tam mnohem víc práce, než jsem původně plánoval, a úplné informace Informace o tomto modelu zahrnu do dalších dvou článků této série.

Pro práci s dokumenty WSDL v Javě bylo vytvořeno mnoho různých modelů, včetně široce používaného jazyka popisu webových služeb pro Java Toolkit (WSDL4J), což je referenční implementace JSR 110 (viz část ). Žádný z těchto modelů neodpovídá tomu, co jsem si předsevzal, kvůli dvojí povaze problému: za prvé, čtení dokumentů WSDL v jakékoli polointeligentní formě a hlášení chyb a odchylek od osvědčených postupů, a za druhé psaní bezchybných WSDL. dokumenty přeformátovány do podoby odpovídající praktickým doporučením. WSDL4J například nezachovává pořadí vstupních prvků, aby bylo možné hlásit problémy s řazením, a nezpracovává definice schémat, takže jej nelze přímo použít ke kontrole odkazů z prvků. . Musel jsem si tedy vybrat mezi realističtějším vyjádřením problému a psaním vlastního vlastní model. Přirozeně jsem se rozhodl napsat svůj vlastní model.

WSDL model

Validace a verifikace

V tomto článku používám termín ověření odkazovat na kontrolu platnosti dokumentu WSDL, protože alternativní termín validace, běžně používaný pro dokumenty XML, znamená kontrolu dokumentů podle definice schématu.

Již dříve jsem částečně implementoval model WSDL pro použití s datovou vazbou JiBX v rámci projektu JiBX/WS. Tento model je pouze pro odvození a zahrnuje relativní malý počet třídy, které v některých případech kombinují data z vnořených prvků struktury WSDL XML ( v kombinaci s jedním podřízeným prvkem , , A uvnitř v kombinaci s prvkem nebo atd.). Tato kompaktní struktura tříd usnadnila sestavení podmnožiny dokumentů WSDL podporovaných rámcem, ale když jsem začal uvažovat o vytvoření nástroje pro ověřování a restrukturalizaci založeného na tomto modelu, uvědomil jsem si, že model pro podporu vstupu možná špatně strukturovaného WSDL by musí být blíže k XML prezentaci.

Další možností je vygenerování kódu ze schématu WS-I BP pro WSDL 1.1. Poté, co jsem to viděl, jsem si uvědomil, že pouhé použití vygenerovaných tříd přímo by vedlo ke zmatku, protože návrh obsahuje redundantní typy a také některé nepříjemné konstrukce, které se používají k reprezentaci různých modelů zasílání zpráv (z nichž některé byly poté zakázány WS- I BP text) .

Nakonec jsem tedy třídy kompiloval ručně, ačkoli výsledek byl téměř stejný, jako kdybych začal s kódem generovaným ze schématu a jednoduše jsem snížil zbytečnou duplicitu a složitost. Datová vazba JiBX podporuje více vazeb na stejné třídy, takže jsem byl schopen vytvořit vstupní vazbu, která zvládne celou škálu variací povolených jakoukoli verzí WSDL 1.1, ačkoli nastavení výstupní vazby pro výstup WSDL bylo pouze v nejlepší praxi.

Výpis 3 ukazuje část třídy Definitions odpovídající kořenovému prvku .

Výpis 3. Definice třída (částečná)

public class Definitions rozšiřuje ElementBase ( /** Seznam podřízených prvků v očekávaném pořadí. */ statický výčet AddState ( neplatný, importy, typy, zpráva, portType, vazba, služba ); /** Seznam povolených názvů atributů. */ public statické finále StringArray s_allowedAttributes = new StringArray(new String("name", "targetNamespace" )); m_validationContext; /** Aktuální stav (používá se ke kontrole pořadí, ve kterém jsou */ /** děti přidány). */ private AddState m_state; /** Název této definice. */ private String m_name; /** Cílový jmenný prostor WSDL. */ private String m_targetNamespace; /** Seznam všech importovaných podřízených prvků. */ soukromý seznam m_imports = nový ArrayList (); /** Seznam všech typů podřízených prvků. */ soukromý seznam m_types = nový ArrayList (); /** Seznam všech zpráv podřízených prvků. */ soukromý seznam m_messages = nový ArrayList (); /** Seznam všech podřízených prvků portuType. */ soukromý seznam M_portTypes = nový ArrayList (); /** Seznam všech vazeb podřízených prvků. */ soukromý seznam m_bindings = nový ArrayList (); /** Seznam všech služeb pro děti. */ soukromý seznam m_services = nový ArrayList m_nameMessageMap = nová HashMap ();/** Mapuje kvalifikovaný název na typ portu v této definici. */ soukromá mapa< m_state.ordinal()) { // отчет о дочерних элементах вне ожидаемого порядка m_validationContext.addWarning ("Child element of wsdl:definitions out of order", comp); m_state = AddState.invalid; } } } ... /** * Добавление немаршаллизированного дочернего элемента wsdl:message. * Здесь же сообщение индексируется по имени для доступа с целью валидации. * * @param child */ public void addMessage(Message child) { checkAdd(AddState.message, child); m_messages.add(child); addName(child.getName(), child, m_nameMessageMap); } ...

m_namePortTypeMap = nová HashMap ();/** Mapujte kvalifikovaný název na zprávu v této definici. */ soukromá mapa . Každý nastavovač také provádí kontrolu stavu, aby zachytil prvky mimo pořadí.

Povoleno v libovolném prvku WSDL další atributy a elementy (obecně všechny atributy nebo elementy, které nepoužívají jmenný prostor WSDL 1.1). Příklad takového doplňkové prvky Konfigurace WS-Policy vložené do dokumentů WSDL z předchozích článků této série slouží jako reference, stejně jako odkazy na skutečné zásady. Nejlepší je, aby tyto další prvky předcházely všem podřízeným prvkům z oboru názvů WSDL 1.1, a tak se s nimi zachází ve výstupní vazbě. Vstupní vazba zpracovává další prvky a atributy pomocí kódu základní třída z tříd prvků WSDL, které nejsou uvedeny v , a umožňuje prvkům následovat v libovolném pořadí (vygeneruje varování, pokud následují za prvkem z oboru názvů WSDL 1.1).

Model zpracovává známé prvky pomocí samostatných vazeb pro každý z nich prostor navíc jména, z nichž každý má svou vlastní sadu tříd. Na zpracování těchto dodatečných prvků se podívám podrobněji v příštím čísle Webové služby Java, kde bude podrobněji uveden zdrojový kód.

Verifikace modelu

Některé základní ověření dat WSDL se provádí, když jsou nezařazené objekty odpovídající prvkům přidány do stromové struktury dokumentu WSDL, jak je znázorněno v kódu addMessage() na konci . Tento kód používá metodu checkAdd() ke kontrole pořadí podřízených prvků a metodu addName() ke kontrole, zda je uveden platný název (text odpovídá typu schématu NCName a hodnota je v rámci typu prvku jedinečná) a mapuje název objektu. Ale to je pouze kontrola nejzákladnějších informací individuální prvek; pro kontrolu dalších vlastností každého prvku a vztahů mezi prvky je nutné doplňkový kód ověření.

JiBX umožňuje volat handlery vlastní rozšíření jako součást procesu seřazování a vyřazování. K provedení ověřovací logiky používá model WSDL jeden z těchto dalších obslužných programů, metodu post-set. Metoda post-set je volána poté, co přidružený objekt dokončí demontáž, takže se to často stává dobrý způsob provádění kontrol, jako je ověřování objektů. V případě ověření WSDL je nejjednodušším přístupem provést ověření všech objektů z jediné post-set metody na kořenovém prvku. . Tento přístup se vyhýbá problému přímého odkazování na součásti dokumentu WSDL, když se součásti neobjevují v očekávaném pořadí.

Další doplňky

Tento článek poskytuje základy struktury a použití WSDL a úvod do datového modelu Java pro WSDL, který je navržen tak, aby podporoval ověřování dokumentů WSDL a jejich transformaci do nejlepší praxe.

Následující článek bude pokračovat v tomto tématu a podívá se na problémy, se kterými se běžně setkáváme při psaní tvrzení WS-Policy a WS-SecurityPolicy. Také se blíže podívá na model WSDL a proces ověřování, včetně rozšíření modelu tak, aby zahrnoval tvrzení WS-Policy/WS-SecurityPolicy zabudovaná do WSDL.

Oblíbené v kategorii: