Čo sú webové služby a prečo sú dôležité? Čo je to „webová služba“ v jednoduchej angličtine

Alexander Kačanov

Myšlienku webových služieb vyvinuli takí giganti počítačového priemyslu ako Sun, Oracle, HP, Microsoft a IBM. Táto myšlienka nie je žiadnou novinkou, ale je to veľký krok vpred v uľahčení prístupu k programom cez web. Na základe štandardných komunikačných formátov môžu webové služby vo všeobecnosti zmeniť naše chápanie toho, ako by sme mali vytvárať webové stránky.

Čo je webová služba?

Vďaka webovým službám je možné sprístupniť funkcie akéhokoľvek programu cez internet. Programy ako PHP, ASP, JSP skripty, JavaBeans, COM objekty a všetky ostatné naše obľúbené programovacie nástroje teda môžu teraz pristupovať k nejakému programu spustenému na inom serveri (t. j. webovej službe) a použiť odozvu z neho prijatú na svojej webovej stránke alebo v aplikácii.

Povedzme, že ak potrebujem vykonať nejakú programátorskú úlohu a som príliš zaneprázdnený (alebo som v rozpakoch na to, aby som sám znovu objavil koleso), môžem využiť služby webovej služby, ku ktorej bude moja stránka pristupovať cez internet. Po odoslaní požiadavky s parametrami webovej službe očakávam, že dostanem odpoveď, ktorá bude obsahovať výsledok mojej požiadavky.

Každý, kto niekedy pracoval v V poslednej dobe s horúcu poštu, sa už stretol s niektorými webovými službami: systém overovania používateľov Passport je jednou zo služieb zahrnutých v iniciatíve Microsoft .NET. pričom je k dispozícii zadarmo, takže tvorcovia webových stránok môžu jednoducho implementovať autentifikáciu používateľov na svojich stránkach.

Základy

Princípy webových služieb sú pozoruhodne jednoduché. A nepridávajú nič nové do sveta distribuovaných počítačov a internetu:

osoba zodpovedná za webovú službu definuje formát požiadaviek na svoju webovú službu a jej odpovede
ktorýkoľvek počítač v sieti odošle požiadavku na webovú službu
webová služba spracuje požiadavku, vykoná nejakú akciu a potom odošle odpoveď

Touto akciou môže byť napríklad zobrazenie ceny akcií, zobrazenie ceny konkrétneho produktu, uloženie záznamu v kalendári schôdzok, preklad textu z jedného jazyka do druhého alebo kontrola čísla kreditnej karty.

Normy v jadre

Dôvod, prečo nás všetkých zrazu zaujímajú webové služby je ten, že sú založené na štandardoch, otvorených protokoloch na výmenu a prenos dát.

Predtým mnoho spoločností vyvinulo svoje vlastné proprietárne štandardy a formáty. A teraz nám na prácu stačí poznať jednoduchý XML (eXtensible Markup Language), ktorý sa prenáša cez starý známy protokol HTTP. To znamená, že informácie o fungovaní webových služieb sú dostupné pre každého a weboví vývojári, ktorí tieto technológie poznajú z povolania, sa môžu začať hrať s webovými službami už dnes.

Rozdiel medzi webovými službami a inými technológiami, s ktorými sa vývojári stretli (napríklad DCOM, Named Pipe - Named Pipe, RMI) je v tom, že webové služby sú založené na otvorených štandardoch, dajú sa ľahko naučiť a tieto štandardy sú široko podporované na všetkých platformách Unix a Windows.

Simple Object Access Protocol (SOAP) je štandardný protokol vyvinutý W3C. Definuje formát požiadaviek na webové služby.

Správy medzi webovou službou a jej používateľom sú zabalené do SOAP obálok (SOAP obálky). Správy obsahujú buď požiadavku na vykonanie nejakej akcie, alebo odpoveď – výsledok vykonania tejto akcie. Obálka a jej obsah sú kódované v XML a sú pomerne ľahko pochopiteľné. Takto vyzerá jednoduchá požiadavka SOAP, ktorá sa odošle cez HTTP webovej službe:

xmlns:env="http://www.w3.org/2001/06/soap-envelope">

xmlns:m="http://www.somesite.com/postcode">
WC1A8GH
UK

Kľúčové prvky obálky SOAP sú ľahko rozpoznateľné: sú to dva parametre ( („PSČ“) a ("krajina")), ktoré sú obsiahnuté v rámci prvku tzv . Tento prvok je názov webovej služby, na ktorú odosielame požiadavku. Ďalšie údaje v obálke, ako je kódovanie textu a verzia SOAP, pomáhajú webovej službe správne spracovať požiadavku.

A odpoveď bude vyzerať takto:

xmlns:env="http://www.w3.org/2001/06/soap-envelope" >

env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://www.somesite.com/postcode">
Áno

Túto správu je ešte jednoduchšie dešifrovať. Element v našom dotaze zmenený na prvok ako odpoveď na žiadosť. Tento prvok obsahuje iba jeden prvok , ktorej hodnota udáva, či je naše PSČ správne alebo nie. Takže s kúzlom SOAP sme vytvorili dotaz, ktorý pre nás robí užitočnú prácu. Ako odpoveď cez sieť dostávame určitý typ odpovede v XML.

Teraz o UDDI

Aj pri jednoduchosti protokolu SOAP by vo webových službách bolo len malé využitie, keby sme ich nemali ako nájsť. Našťastie IBM, Microsoft a Ariba prevzali iniciatívu a vytvorili projekt Universal Description, Discovery and Integration (UDDI), ktorý sa, ako dúfajú, stane spoločným katalógom všetkých webových služieb na webe.

Systém UDDI umožňuje spoločnostiam sprístupniť svoju webovú službu verejnosti. Tento adresár funguje ako telefónny zoznam všetkých webových služieb. Registrácia do adresára UDDI je bezplatná a zakladatelia projektu dúfajú, že tento adresár bude obsahovať popisy všetkých všetkých služieb na celom webe, takže na nájdenie požadovanej webovej služby bude stačiť iba jeden adresár UDDI.

Ako to celé funguje

Ako teda nájdem správnu webovú službu?

Predstavme si, že som vývojár webových stránok a môj klient ma požiadal o pridanie na stránku Nová funkcia: Do registračného formulára je potrebné pridať overenie PSČ.

Na vykonanie tejto kontroly by som potreboval vytvoriť databázu všetkých poštových smerovacích čísel všetkých 30 krajín, kde naša spoločnosť podniká a následne pri registrácii skontrolovať, či sa poštové smerovacie číslo zhoduje s mestom uvedeným v registrácii. Ale tieto údaje nemám a myslím si, že zber takýchto údajov bude musieť vynaložiť značné množstvo peňazí.

Namiesto toho, aby som si kupoval databázu, písal si vlastný kód, uisťoval sa, že všetky údaje sú konzistentné a správne a ladím skripty, jednoducho idem do adresára UDDI a hľadám webovú službu, ktorá by to mohla urobiť za mňa. Po príchode na stránku http://www.uddi.org/ spustím vyhľadávanie a nájdem skvelú službu od spoločnosti XYZ Corp.

Pozorne sa pozriem na definíciu formátu webovej služby (definícia je napísaná vo WSDL (Web Services Description Language), uistím sa, že služba robí presne to, čo chcem, aby robila. Potom sa opýtam svojich kolegov na reputáciu XYZ Corp., zistím, že je solídna, a potom požiadam XYZ Corp. o cenu. Ak je cena za prístup k službe v rámci môjho rozpočtu, napíšem jednoduchú službu, ktorá na moju webovú stránku volá kód JSP a okamžite zavolá XYZ. skontrolovať.

Oplatí sa nájsť si čas

Aj keď nemáte nič spoločné s programovaním alebo technológiami vývoja webových stránok, o webových službách sa oplatí dozvedieť sa viac. Predstavte si obrázok, ako diskutujete o novej lokalite s klientom a diskutujete o všetkých funkciách nového projektu. Všetko ide skvele: rozpočet spĺňa očakávania klienta, páči sa mu náčrt plánu lokality, páčia sa mu príklady rozhrania. Zdá sa, že všetko funguje.

A zrazu si pamätajú nejakú veľmi zložitú funkciu. Už pri zmienke o tom sa tvár vášho webového vývojára zmení na zelenú a on sám sa začne dusiť kašľom. Toto je vývojár, ktorý vám dáva signál, že vývoj tejto funkcie bude vyžadovať veľa peňazí a času, alebo je jednoducho nerealizovateľný s takým rozpočtom.

Zahoďte strach! Môžem sa staviť, že na webe už existuje webová služba, ktorá je pripravená poskytnúť vám požadovanú funkciu a náklady na používanie tejto webovej služby budú oveľa nižšie ako náklady na vlastný vývoj jej analógu. Takto ušetríte svojho vývojára pred zbytočnými bolesťami hlavy, pred ktorými je váš klient mrhať peniaze, stačí stráviť pár minút prehliadaním katalógu UDDI.

Rozvoj služieb

Samozrejme, vývojári sa nemusia uspokojiť len s webovými službami vytvorenými inými. Pomocou jedného z nasledujúcich nástrojov si môžete vytvoriť vlastnú webovú službu a poskytovať jej služby ostatným obyvateľom siete.

Výber nástrojov na vývoj webových služieb je široký. Zahŕňa sady nástrojov od spoločností ako Sun (Open Net), Microsoft (.NET), (e-služby) a IBM (Web Services). Existujú aj open source frameworky. Projekt Mono sa napríklad snaží nahradiť súpravu nástrojov Microsoft .NET tým, že poskytuje kompilačný systém (kompilátory), spúšťanie kódu (runtime) a knižnice (knižnice) na spustenie rovnakých webových služieb na všetkých platformách vrátane Unixu.

Napriek rôznorodosti serverov a nástrojov na vývoj webových služieb všetky podporujú rovnaký protokol SOAP, jazyk XML a systém UDDI.

Mínusy

Skôr ako úplne zanechám kariéru programátora a budem sa venovať využívaniu webových služieb, musím si položiť otázku: "Tento obrázok je príliš ružový. Čo je na ňom zlé?". Bohužiaľ, za veľký potenciál webových služieb sa platí:

Použitie XML ako formátu na prenos údajov má za následok, že vaše správy sú veľmi veľké: samotné značky XML zaberajú veľa miesta, čo pre nás predstavuje určitú záťaž pri vytváraní, prenose a interpretácii správ.
Keďže používame vzdialené počítače na vykonávanie určitých funkcií sa úplne spoliehame na internet, ktorý vytvára príliš veľa nespoľahlivých prepojení v reťazci medzi naším webovým serverom a webovou službou.
V súčasnosti len málo spoločností vytvára webové služby a len málo spoločností ich používa. Stále trvá dlho, kým sa odladí a vylepší systém webových služieb.
Systém licencovania a spoplatňovania používania webových služieb musia vývojári ešte prijať. Vzhľadom na to, že webových služieb je stále príliš málo, väčšina spoločností sa snaží urobiť dobrý dojem na svojich potenciálnych zákazníkov zámerným znižovaním ceny služieb a ponúkaním výhodných licenčných podmienok. Bude ešte nejaký čas trvať, kým sa vyjasnia skutočné náklady na služby webových služieb.

Keď webové služby zaujmú ich miesto a stanú sa dostupnými pre každého, stanú sa neoceniteľným pomocníkom pre webových vývojárov. Poskytnú nám flexibilný prístup k plnému výkonu všetkých počítačov na webe. Je čas, aby sa tí, ktorí tvoria webové stránky, začali zaujímať o webové služby a dozvedeli sa viac o tom, čo z nich môžu získať.

Anotácia: Oblasti použitia. Výhody. Vlastnosti vývoja webových služieb pre platformu .NET. Popis a objav webovej služby

Čo je webová služba XML?

S rozvojom informačných technológií vznikli rôzne prístupy k písaniu programov: modulárne programovanie, udalosťami riadené programovanie, orientovaný na komponenty programovanie a dizajn. Logické pokračovanie týchto prístupov bolo orientované na služby vývoj softvéru.

Použitie prístupov orientovaných na služby nám umožňuje hovoriť o opätovnom použití ( opätovné použitie ) na makroúrovni (úroveň služby), na rozdiel od mikroúrovne (úroveň objektu). Prístup orientovaný na služby zahŕňa používanie jednoduchých a všeobecne uznávaných štandardov, čo umožňuje širokému spektru aplikácií vzájomne využívať svoje funkcie. Služby je možné písať pomocou širokej škály programovacích jazykov na rôznych platformách. Okrem toho môžu byť služby nasadené samostatne alebo ako súčasť softvérového balíka kdekoľvek na svete a poskytnú tak prístup k ich funkcionalite cez sieť.

Zavolajme služby zdroj, ktorý implementuje obchodnú funkciu a má nasledujúce vlastnosti:

je opakovane použiteľný;
definované jedným alebo viacerými explicitnými technologicky nezávislými rozhraniami;
voľne spojené s inými podobnými zdrojmi a môžu byť vyvolané prostredníctvom komunikačných protokolov, ktoré umožňujú zdrojom vzájomne interagovať.

Špeciálnym prípadom služby je webová služba XML.

Webová služba XML je špeciálny typ webovej aplikácie, ktorá:

nasadené na webovom serveri;
zverejňuje webové metódy, ktoré môžu volať externí klienti;
čaká na prijatie HTTP požiadaviek, čo sú príkazy na volanie webových metód;
vykoná webové metódy a vráti výsledky.

Na rozdiel od tradičnej webovej aplikácie nemá webová služba používateľské rozhranie. Namiesto toho má API, to znamená, že webová služba poskytuje funkcie (webové metódy), ktoré možno volať na diaľku (napríklad cez internet). Webová služba nie je navrhnutá tak, aby slúžila koncovým používateľom. Jeho úlohou je poskytovať služby iným aplikáciám, či už ide o webové aplikácie, GUI aplikácie alebo konzolové aplikácie.

Webová služba môže poskytovať informácie o cenách akcií v reálnom čase, kontrolovať kreditné karty alebo hlásiť počasie. Webové služby sú také rozmanité ako bežné aplikácie.

Webové služby nie sú majetkom konkrétnej spoločnosti. Ide o priemyselný štandard založený na otvorených protokoloch (SOAP, HTTP atď.). Webové služby sú nasadené na rôznych platformách (vrátane serverov so systémom Windows alebo UNIX). Webové služby je možné vyvíjať pomocou mnohých vývojových nástrojov (od textového editora až po rodinu Microsoft Visual Studio).

Metódy väčšiny webových služieb sú volané HTTP požiadavkami obsahujúcimi SOAP správy SOAP je XML jazyk ( XML slovník ) na volanie vzdialených procedúr cez HTTP a iné protokoly (úplný popis SOAP http://www.w3.org/TR/SOAP).

Miesto webových služieb medzi ostatnými technológiami vzdialeného volania

Existuje mnoho protokolov a technológií vzdialeného vyvolávania: Microsoft Distributed Component Object Model (DCOM), architektúra spoločného makléra požiadaviek na objekty (CORBA) od spoločnosti Object Management Group, vzdialené vyvolávanie metód od spoločnosti Sun (RMI), . NET Remoting, webové služby XML.

Všetky tieto komponenty orientované technológie (DCOM, CORBA a RMI) sa úspešne používajú v intranetových aplikáciách už mnoho rokov. Poskytujú robustnú, škálovateľnú architektúru. Pri používaní týchto technológií na internete sú však dva veľké problémy. Po prvé, neinteragujú medzi sebou dobre. Všetky technológie fungujú na objektoch, ale výrazne sa líšia v detailoch: správa životného cyklu, podpora konštruktérov a stupeň podpory dedičnosti. Druhým, dôležitejším aspektom je, že zameranie sa na RPC interakcie vedie ku konštrukcii tesne prepojených systémov založených na explicitných volaniach objektových metód.

Na rozdiel od týchto technológií, XML Web Services a . NET Remoting plne implementovať objektovo orientovaný prístup na programovanie webu.

Webová služba XML- komponent, ktorý poskytuje internetovým klientom súbor funkcií API alebo webových metód. XML je súčasťou názvu, pretože webové služby a ich klienti ho používajú na výmenu údajov. Webové služby sú založené na otvorených štandardoch ako HTTP, XML (Extensible Markup Language), SOAP (Simple Object Access Protocol – internetový štandard, ktorý popisuje, ako môžu aplikácie interagovať, teda volať si navzájom svoje metódy, pomocou HTTP a iných protokolov). Hlavnou úlohou webových služieb je poskytovať medziprogramovú interakciu. Mnohé bežia na serveroch UNIX a pristupujú k nim klienti Windows. Dáta odovzdávané webovým službám sú serializované do XML a odosielané v paketoch SOAP. Metadáta o obsahu takýchto správ sú uložené v zmluve WSDL webovej služby a schémach XSD. Hlavnou výhodou tohto prístupu je čitateľnosť metadát. Vývojár môže jednoducho zobraziť celý popis webovej služby a dokonca vytvoriť svoj vlastný modul, ktorý analyzuje pakety SOAP.

.NET Remoting poskytuje infraštruktúru pre distribuované objekty. Je to oveľa zložitejšie ako jednoduchá architektúra webových služieb založená na odovzdávaní správ. . NET Remoting zahŕňa odovzdávanie parametrov podľa referencie a hodnoty, spätné volania, aktiváciu viacerých objektov a zásady správy životného cyklu. Na využitie týchto funkcií musí klientska aplikácia ovládať všetky technológie. Údaje v. NET Remoting sa odosielajú v binárnom alebo SOAP formáte. V každom prípade sú však metaúdaje o štruktúre prenášaných informácií obsiahnuté v spoločnom jazyku. Bez spoločného jazykového modulu runtime (CLR) nebude klientska aplikácia schopná analyzovať súbor . NET Remoting hlavičky SOAP. Teda. NET Remoting má podstatne vyššie požiadavky ako webové služby.

Vývoj webových služieb na platforme .NET

Existuje mnoho spôsobov, ako písať webové služby. Môžu byť vyvinuté ručne alebo pomocou nástrojov SOAP poskytovaných spoločnosťami Microsoft, IBM atď.. Písanie webových služieb so spoločnosťou Microsoft. NET má dve výhody:

.NET Framework výrazne zjednodušuje proces vývoja tým, že poskytuje knižnicu tried a automatizuje jednotlivé kroky vývoja;
Webové služby napísané pomocou .NET Framework sú riadené aplikácie. To znamená, že v takýchto aplikáciách nie sú žiadne problémy s únikmi pamäte, nesprávne inicializovanými ukazovateľmi a inými typickými problémami s programovaním.

Tvorba

Poďme vyvinúť jednoduchú webovú službu AdditionService, ktorá vykoná sčítanie dvoch čísel. Bude mať iba jednu metódu Add, ktorá berie ako parameter dve celé čísla a tiež vracia celé číslo. AdditionService demonštruje niekoľko dôležitých princípov programovania webových služieb pomocou Microsoft .NET Framework.

Webové služby sú implementované ako súbory ASMX. ASMX je špeciálna prípona názvu súboru registrovaná pomocou ASP .NET (konkrétnejšie ASP.NET HTTP Handler) v hlavnom konfiguračnom súbore ASP .NET Machine.config.
Súbory ASMX začínajú direktívou @WebService. Táto direktíva musí obsahovať aspoň atribút Class, ktorý špecifikuje triedu, z ktorej webová služba pozostáva.
Triedy webových služieb môžu mať voliteľné atribúty WebService. IN tento príklad takýto atribút určuje názov webovej služby a popis, ktorý sa zobrazí na stránke HTML, keď používateľ v prehliadači zavolá AdditionService.asmx.
Webové metódy sú deklarované priradením atribútu WebMethod k verejným metódam triedy webových služieb. Pre pomocné metódy, ktoré sa používajú interne, ale nie sú dostupné pre externých klientov, je tento atribút jednoducho vynechaný.
HTTP, XML a SOAP sú „neviditeľné“. Údaje XML a správy SOAP sú spracované prostredníctvom .NET Framework.

AdditionService.asmx<%@ WebService language="C#" Class="AddService" %>pomocou systému pomocou triedy System.Web.Services AddService ( public int Add (int a, int b) ( return a + b ) )

Napriek svojej malej veľkosti je AdditionService.asmx kompletnou webovou službou pri inštalácii na webovom serveri ASP.NET. Jeho metódy sa vyvolávajú pomocou SOAP, HTTP GET a HTTP POST a môžu vrátiť výsledky ako odpovede SOAP alebo ako jednoduché obaly XML.

Pomocou kódu na pozadí možno triedy webových služieb vybrať zo súborov asmx do samostatných súborov.

Webové služby podporujú používanie komplexné dátové typy ako vstupné alebo výstupné parametre. Komplexné typy údajov sú podporované, pretože XML uľahčuje serializáciu väčšiny typov údajov. Pri automatickom testovaní webovej služby však ASP .NET negeneruje testovacie stránky pre metódy, ktoré akceptujú komplexné typyúdajov. Je to preto, že nemôžete odovzdať zložité typy údajov webovej metóde pomocou HTTP GET a POST.

Webové služby vám umožňujú volať vlastné metódy asynchrónne. Asynchrónny hovor sa vráti okamžite, bez ohľadu na to, ako dlho trvá webovej službe spracovanie hovoru. Asynchrónne hovory sú užitočné, keď spracovanie hovoru trvá dlho. Aplikácia uskutoční hovor, potom pokračuje v behu bez čakania na výsledok hovoru a neskôr prijme výsledky asynchrónneho hovoru. Výsledok sa získa, keď sa webová metóda znova zavolá vo vhodnom čase pre aplikáciu, alebo sa prihlásite na odber upozornenia o ukončení spracovania hovoru webovou službou (mechanizmus delegátov).

Webové služby je možné vytvárať pomocou nástrojov ako napr Microsoft Visual Studio 2005. Na vytvorenie webových služieb existuje samostatný typ Projekt webovej služby ASP .NET. Visual Studio vygeneruje súbor asmx, súbor s kódom na pozadí na popis tried webových služieb, konfiguračný súbor webovej služby atď. Keď sa projekt spustí na realizáciu, triedy služieb sa skompilujú a súbor asmx sa otvorí v okne prehliadača.

Popis webových služieb pomocou zmlúv

Aby mohli iní vývojári používať AdditionService, potrebujú vedieť, aké metódy odhaľuje, aké protokoly podporuje, podpisy metód a adresu webovej služby (URL). Všetky tieto a ďalšie informácie je možné popísať v jazyku WSDL (Web Service Description language).

Zisťovanie webových služieb

Ako ostatní vývojári vedia o existencii AdditionService?

Po prvé, pomocou DISCO (skratka pre slovo objavovanie) - súborového mechanizmu na vyhľadávanie lokálnych webových služieb, to znamená mechanizmu na získanie zoznamu dostupných webových služieb zo súborov DISCO hostovaných na webových serveroch. Súbory DISCO navyše obsahujú záznamy o umiestnení zmlúv WSDL o dostupných službách. DISCO súbor je súbor XML so záznamami.

Je možné použiť aj súbory VSDISCO, ktoré sú podobné súborom DISCO, ale ich obsah je výsledkom dynamického vyhľadávania webových služieb v zadaných adresároch a všetkých vnorených podadresároch. ASP .NET mapuje príponu súboru .vsdisco na obsluhu HTTP, ktorá v danom adresári a jeho podadresároch vyhľadá asmx a disco a vráti dynamicky generovaný DISCO dokument. Z bezpečnostných dôvodov je dynamické vyhľadávanie v niektorých verziách .NET Framework zakázané, ale môžete ho povoliť úpravou položiek v súbore Machine.config.

Ako však prebieha vyhľadávanie webových služieb v globálnej sieti? Na vyhľadávanie webových služieb v globálnej sieti Microsoft, IBM a Ariba spoločne vyvinuli UDDI (Universal Description Discovery and Integration) – špecifikáciu pre budovanie distribuovaných databáz, ktorá vám umožňuje nájsť webové služby. UDDI podporujú stovky spoločností. Stránky UDDI sú samy osebe webovými službami. Každý môže zverejniť svoj register založený na UDDI. Väčšina vývojárov nikdy priamo nepoužíva UDDI API. Namiesto toho k registrom UDDI pristupujú vývojové nástroje. Generujú tiež obalové triedy pre objavené a vybrané webové služby.

Výsledky

Webová služba XML je softvérový komponent, ktorý poskytuje väčšinu funkcií rôznych systémov, podporujúce štandardy, ako sú XML a klienti webových služieb HTTP, môžu byť lokálne alebo vzdialené aplikácie. Webové služby vám umožňujú vytvárať štruktúry, ktoré uľahčujú integráciu rôznych systémov na základe jednoduchých, bežne akceptovaných štandardov.

Skontrolovali sme všeobecné pojmy mechanizmus « web-služby“. Osviežme si nejaké poznatky.

Webové služby sa používajú na výmenu údajov medzi serverom a klientom; formát XML sa používa na „zabalenie“ údajov pre vzájomné porozumenie medzi oboma účastníkmi komunikácie.

KAPITOLAja

PRÍKLAD REALIZÁCIEWEB-SERVIS V SYSTÉME "1C: ENTERPRISE"

ÚLOHA: Je potrebné vytvoriť webovú službu, pomocou ktorej môžu klienti zistiť všetky potrebné informácie pre svoje aplikácie.

Úloha je demonštračná a slúži len ako príklad na pochopenie a osvojenie si mechanizmuweb-služby.

RIEŠENIE:

Krok 1. Vytvorme novú informačnú základňu bez konfigurácie na vývoj novej konfigurácie.

Krok 2 Pridajme do konfigurácie nejaké nové objekty

Adresár "Klienti";

dokument "Prihláška";

Enumerácia "Stavy aplikácií".

Krok 3 Vytvorme nový balík XDTO.

Prečo a prečo vytvárame balík XDTO? Viac o používaní mechanizmu XDTO si môžete prečítať v "Kapitola 16. Príručka pre vývojárov" a.

Len stručne poznamenajme, že mechanizmus XDTO je univerzálny spôsob prezentácie údajov pre interakciu s rôznymi externými zdrojmi údajov a softvérovými systémami.

V našom prípade je vytvorený balík XDTO, ktorý popisuje návratovú hodnotu webovej služby.

Rozbaľte vetvu „Všeobecné“ → „Balíky XDTO“ → Pridať…

Zadajte názov balíka XDTO " Údaje o dokumentoch” a jeho menný priestor http://localhost/request alebo http://192.168.1.76/request (pre jednoduchšie pochopenie a proces učenia uvádzame lokálnu IP adresu počítača, na ktorom je nainštalovaný webový server (podporované webové servery: IIS alebo Apache)). Každá webová služba môže byť jednoznačne identifikovaná svojím názvom a URI menného priestoru, do ktorého patrí.

Náš balík obsahuje dva typy XDTO objektov:

1) Zákazník- na prenos údajov prvku adresára "Klienti".

- názov ;

2) dokument- na prenos údajov dokumentu "Prihláška"

Tento typ objektu XDTO bude obsahovať nasledujúce vlastnosti:

- Zákazník- Typ zákazníka z priestoru názvov http://192.168.1.76/request; je odkaz na objekt XDTO, ktorý sme definovali vyššie;

- Postavenie- typ reťazca z http://www.w3.org/2001/XMLSchema namespace;

- Číslo- typ reťazca z http://www.w3.org/2001/XMLSchema namespace.

Krok 4 Pridajte do konfigurácie novú webovú službu

Rozbaľte vetvu "Všeobecné" → "Webové služby" → Pridať ...

Pre webovú službu zadajte nasledujúce hodnoty vlastností:

Názov - Údaje o dokumentoch

Priestory názvov URI - http://192.168.1.76/request

Balíky XDTO - Údaje o dokumentochalebohttp://192.168.1.76/request

Názov súboru publikácie - žiadosť.1cws

Krok 5 Pre vytvorenú webovú službu definujeme operáciu " getdata»

Hodnoty prevádzkových vlastností:

Typ návratu - Dokument (http://192.168.1.76/request)

Možno prázdna hodnota - Pravda

Názov procedúry - getdata.

Krok 6 Prevádzka getdata definujte parameter Zákazník pomocou nasledujúce hodnoty vlastnosti:

Typ hodnoty - typ reťazec z http://www.w3.org/2001/XMLSchema namespace;

Smer transferu - vstup.

Krok 7 Otvorme modul vytvorenej webovej služby a umiestnime do neho funkciu Get(), ktorá sa vykoná pri volaní tejto webovej služby.

Function GetData(Customer) // Získanie typov XDTO objektov ClientType = FactoryXDTO.Type("http://192.168.1.76/request", "Customer"); RequestType = FactoryXDTO.Type("http://192.168.1.76/požiadavka", "Dokument"); // Získanie klienta ClientReference = Directories.Clients.FindByName(Customer); If Not ValueFilled(ClientReference) Then Return Undefined; Koniec Ak; Žiadosť = Nová požiadavka; Request.Text = "SELECT FIRST 1 | Ticket.Reference, | REPRESENTATION(Ticket.Status) AS Status, | Ticket.Number |FROM | Document.Ticket AS Ticket |WHERE | Ticket.Client = &Client"; Request.SetParameter("Klient", ClientReference); QueryResult = Query.Execute(); If QueryResult.Empty() Then Return Undefined; Koniec Ak; Selection = QueryResult.Select(); Selection.Next(); Dokument = Selection.Reference.GetObject(); // Vytvorenie objektu tiketu XDTO Ticket = FactoryXDTO.Create(TicketType); Application.Numder = Sample.Number; Klient = FactoryXDTO.Create(ClientType); Client.Name = ClientReference.Name; Application.Customer = Klient; Application.Status = Selection.Status; // Požiadavka na vrátenie Požiadavka na vrátenie; EndFunctions

Krok 8 Publikujme vytvorenú webovú službu na webovom serveri.

Položka menu konfigurátora: "Správa" → "Publikovanie na webovom serveri".

Na karte "Webové služby" nastavte príznak "Publikovať webové služby" a tiež začiarknite políčko vedľa našej novej webovej služby.

KAPITOLAII

PRÍKLAD ODKAZU NAWEB- 1C:ENTERPRISE SERVICE Z APLIKÁCIE TRETEJ STRANY

Hlavným účelom mechanizmu webových služieb v 1C:Enterprise je prenos potrebných údajov do aplikácií tretích strán.

Pozrime sa na príklad vývoja aplikácie v Delphi, ktorá volá našu webovú službu z prvej časti tohto článku.

Krok 1. Poďme tvoriť nový projekt a umiestnite do formulára niekoľko ovládacích prvkov

Textové pole – slúži na zobrazenie informácií prijatých z webovej služby;

Dve tlačidlá - vymazanie textového poľa a prístup k webovej službe;

Vstupné pole je parameter odovzdaný webovej službe.

Krok 2 Importovanie súboru WSDL

V dôsledku toho dostaneme nový modul žiadosť(takýto názov sme definovali priamo v 1C). Tento modul obsahuje všetky potrebné informácie o webovej službe.

Krok 3 Napíšte obsluhu hovorov webovej služby

Premenná DocumentDataPortType je už v module definovaná žiadosť

Krok 4 Spustite aplikáciu a skontrolujte.

KAPITOLAIII

PRÍKLAD ODKAZU NAWEB-SERVIS V SYSTÉME "1C: ENTERPRISE"

Krok 1. Poďme vytvoriť nové externé spracovanie s názvom „WEB_Service“

Krok 2 Pre spracovanie definujeme nový formulár

Krok 3 Zadajte niekoľko podrobností pre formulár

Klient - zadajte "String"

ClientReturn - zadajte "String"

NumberReturn - zadajte "String"

StatusReturn - typ "String".

Podrobnosti zobrazíme vo formulári.

Krok 4 Pridajme príkaz formulára " Na získanie údajov»

Zadajte obsluhu príkazov

&Procedúra OnClient GetData(Command) GetDataOnServer(Client); Koniec procedúry GetDataOnServer(Client) // Vytvorenie WS proxy na základe odkazu a vykonanie operácie Get() Definícia = New WSDefinitions("http://192.168.1.76/WEB_Service/ws/request.1cws?wsdl"); Proxy = New WSProxy(Definícia, "http://192.168.1.76/request", "DocumentsData", "DocumentsDataSoap"); RequestData = Proxy.GetData(Client); Ak OrderData = Undefined Then ClientReturn = "Undefined"; StatusReturn = "Nedefinované"; ReturnNumber = "Nedefinované"; Návrat; Koniec Ak; CustomerReturn = RequestData.Customer.Name; StatusReturn = RequestData.Status; ReturnNumber = RequestData.Numder; EndProcedure

1C:Enterprise môže využívať webové služby poskytované inými poskytovateľmi dvoma spôsobmi:

Používaním statické odkazy vytvorené v konfiguračnom strome;

"plus": vysoká rýchlosť práce;

"mínus": opätovný import popisu WSDL pomocou konfigurátora a uloženie zmenenej konfigurácie.

Používaním dynamický odkazy vytvorené pomocou vstavaného jazyka

(resp. „nevýhody“ statických pre dynamické sú „plusy“)

KAPITOLAIV

LADENIE WEBOVÝCH SLUŽIEB V SYSTÉME 1C:ENTERPRISE

Pre lokálnu webovú službu potrebujete:

Krok 1. Vložte súbor na klienta, kde je spustený systém 1C webservicecfg.xml s nasledujúcim obsahom

Krok 2 Vyplniť predvolená. vrd publikovať konfiguráciu pridať riadok

Krok 3 V konfigurátore vyberte položku ponuky

"Ladenie" → "Pripojenie" → "Automatické pripojenie" → "Webové služby na serveri"

Krok 4 Kliknite na tlačidlo "OK".

Pre verziu servera musíte tiež spustiť server 1c v režime ladenia s kľúčom /debug

Čo je webová služba?

Každý, kto niekedy pracoval s horúcu poštu, sa už stretol s niektorými webovými službami: systém overovania používateľov Passport je jednou zo služieb zahrnutých v iniciatíve Microsoft .NET. pričom je k dispozícii zadarmo, takže tvorcovia webových stránok môžu jednoducho implementovať autentifikáciu používateľov na svojich stránkach.

Základy

Princípy webových služieb sú pozoruhodne jednoduché. A nepridávajú nič nové do sveta distribuovaných počítačov a internetu:

osoba zodpovedná za webovú službu definuje formát požiadaviek na svoju webovú službu a jej odpovede
ktorýkoľvek počítač v sieti odošle požiadavku na webovú službu
webová služba spracuje požiadavku, vykoná nejakú akciu a potom odošle odpoveď

Normy v jadre

Dôvod, prečo nás všetkých zrazu zaujímajú webové služby je ten, že sú založené na štandardoch, otvorených protokoloch na výmenu a prenos dát.

Simple Object Access Protocol (SOAP) je štandardný protokol vyvinutý W3C. Definuje formát požiadaviek na webové služby.

xmlns:env="http://www.w3.org/2001/06/soap-envelope">

xmlns:m="http://www.somesite.com/postcode">
WC1A8GH
UK

A odpoveď bude vyzerať takto:

xmlns:env="http://www.w3.org/2001/06/soap-envelope" >

env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://www.somesite.com/postcode">
Áno

Teraz o UDDI

Systém UDDI umožňuje spoločnostiam sprístupniť svoju webovú službu verejnosti. Tento adresár funguje ako telefónny zoznam pre všetky webové služby. Registrácia do adresára UDDI je bezplatná a zakladatelia projektu dúfajú, že tento adresár bude obsahovať popisy všetkých všetkých služieb na celom webe, takže na nájdenie požadovanej webovej služby bude stačiť iba jeden adresár UDDI.

Ako to celé funguje

Ako teda nájdem správnu webovú službu?

Predstavme si, že som vývojár webových stránok a môj klient ma požiadal o pridanie novej funkcie na stránku: Potrebujem pridať overenie PSČ do registračného formulára.

Namiesto toho, aby som si kupoval databázu, písal si vlastný kód, uisťoval sa, že všetky údaje sú konzistentné a správne a ladím skripty, jednoducho idem do adresára UDDI a hľadám webovú službu, ktorá by to mohla urobiť za mňa. Keď prejdem na stránku www.uddi.org, spustím vyhľadávanie a nájdem skvelú službu od spoločnosti XYZ Corp.

Oplatí sa nájsť si čas

Zahoďte strach! Môžem sa staviť, že na webe už existuje webová služba, ktorá je pripravená poskytnúť vám požadovanú funkciu a náklady na používanie tejto webovej služby budú oveľa nižšie ako náklady na vlastný vývoj jej analógu. Týmto spôsobom ušetríte svojho vývojára od zbytočných bolestí hlavy, svojho klienta od plytvania peniazmi a len pár minút strávených prehliadaním katalógu UDDI.

Rozvoj služieb

Napriek rôznorodosti serverov a nástrojov na vývoj webových služieb všetky podporujú rovnaký protokol SOAP, jazyk XML a systém UDDI.

Mínusy

Použitie XML ako formátu na prenos údajov má za následok, že vaše správy sú veľmi veľké: samotné značky XML zaberajú veľa miesta, čo pre nás predstavuje určitú záťaž pri vytváraní, prenose a interpretácii správ.
Keďže na vykonávanie určitých funkcií používame vzdialené počítače, spoliehame sa výlučne na internet, ktorý vytvára príliš veľa nespoľahlivých prepojení v reťazci medzi naším webovým serverom a webovou službou.
V súčasnosti len málo spoločností vytvára webové služby a len málo spoločností ich používa. Stále trvá dlho, kým sa odladí a vylepší systém webových služieb.
Systém licencovania a spoplatňovania používania webových služieb musia vývojári ešte prijať. Vzhľadom na to, že webových služieb je stále príliš málo, väčšina spoločností sa snaží urobiť dobrý dojem na svojich potenciálnych zákazníkov zámerným znižovaním ceny služieb a ponúkaním výhodných licenčných podmienok. Bude ešte nejaký čas trvať, kým sa vyjasnia skutočné náklady na služby webových služieb.

Praktické využitie webových služieb v IBM Lotus Domino 7

Čo sú webové služby a prečo sú dôležité?

Obsahová séria:

Tento obsah je súčasťou # série # článkov: Praktické využitie webových služieb v IBM Lotus Domino 7

https://www..jsp?series_title_by=Praktické+používanie+webových služieb+in+ibm+lotus+domino+7

Zostaňte naladení na nové články v tejto sérii.

Možno ste sa stretli s odkazmi na webové služby v technických článkoch, softvérové produkty alebo aj v dialógoch s kolegami. Zdá sa, že niekto potrebuje webové služby a je dôležitý, ale keď ste sa stretli s definíciami ako „XML gramatika na definovanie množín koncových bodov pre zasielanie správ“, rozhodli ste sa, že takýchto komplikovaných vecí by ste sa nemali dotýkať.

Našťastie sa webové služby dajú vysvetliť spôsobom, ktorému každý rozumie bez toho, aby sme zachádzali do podrobností o tom, ako to celé funguje. Mali by ste sa pokúsiť pochopiť, čo sú webové služby, keďže rozsah ich aplikácií (a súvisiacej architektúry orientovanej na služby, SOA) vo svete IT sa neustále rozširuje.

Webové služby si možno predstaviť ako auto: na technickej úrovni nepotrebujete vedieť, ako fungujú piesty, vačkové hriadele a vstrekovače paliva – môžete si kúpiť auto, jazdiť na ňom a rozprávať sa o autách s priateľmi (samozrejme, ak to nie sú mechanici). S webovými službami je to rovnaké, ako IT profesionál len musíte pochopiť, čo sú a ako fungujú, aby ste pochopili, prečo ich potrebujete.

Teraz je oveľa jednoduchšie pracovať s webovými službami bez toho, aby ste sa dotkli skrytých nízkoúrovňových technológií, pretože dodávatelia softvéru a open source komunita urobili za posledných pár rokov veľa, aby oddelili rozhranie webových služieb od úloh nízkej úrovne. To vám umožní pracovať jednoduchým prepojením komponentov bez toho, aby ste sa museli ponoriť do zdĺhavej dokumentácie o formátovaní správ XML.

Táto séria článkov pomôže vývojárom Domino pochopiť a používať webové služby v IBM Lotus Domino V7.0. Tento úvodný článok obsahuje dosť užitočná informácia a je užitočný pre každého, kto chce pochopiť, čo sú webové služby. Technológie v Lotus Domino V7.0 uľahčujú vývojárom vytváranie a používanie webových služieb a podrobnejšie sa tomu budeme venovať neskôr.

Po prvé, poďme pochopiť, čo je webová služba.

Čo je webová služba?

Jednoducho povedané, webová služba umožňuje počítačovým programom vzájomnú komunikáciu štandardizovaným spôsobom.

Komunikácia medzi tromi alebo viacerými strojmi

Aj keď sú príklady založené na transakciách v rámci jedného alebo dvoch počítačov, webové služby možno použiť aj na komunikáciu medzi viacerými počítačmi. Transakcie môže napríklad preposlať alebo uložiť sprostredkujúce zariadenie alebo volanie webovej služby na jednom serveri môže spustiť volanie služby na inom serveri.

Na konci tohto článku, keď sa pozrieme na skutočnú SOA, si povieme o webových službách, ktoré interagujú na viacerých počítačoch, pretože tak SOA vždy funguje.

Webová služba je abstraktný komponent, rovnako ako koncept ľudskej konverzácie je abstraktný. Dialóg zahŕňa dvoch alebo viacerých ľudí hovoriacich jazykom, ktorý poznajú. Ich jazyk definuje slová, ktoré používajú a ako tieto slová tvoria vety. Dialóg má zvyčajne štruktúru otázka-odpoveď, keď niekto položí otázku alebo urobí vyhlásenie a účastník rozhovoru na ňu odpovie. Ľudia môžu byť nablízku, telefonovať, posielať si správy e-mailom alebo chatom.

V každom prípade, dialóg má komplexná štruktúra a môže prebiehať rôznymi spôsobmi, v závislosti od počtu komunikujúcich ľudí, komunikačného jazyka používaného pre komunikačné technológie, samozrejme, ak sa nejaký používa.

Štruktúra komunikácie pomocou webových služieb zahŕňa mnoho prvkov, ktorých sa dotkneme v tomto článku. Myšlienka však zostáva rovnaká ako pri bežnom dialógu – programy komunikujú pomocou jazyka, ktorý poznajú, niekedy cez sieť. Programy môžu byť umiestnené buď na tom istom počítači, alebo môžu byť umiestnené na rôznych počítačoch v rôznych častiach sveta, prepojené cez internet prostredníctvom smerovačov a serverov. Dobrou správou je, že programy a počítače nemusia byť rovnaké. S webovými službami môžu komunikovať dva programy Microsoft .NET na tom istom notebooku, ako aj program Java na kanadskom serveri iSeries s programom C++ na počítači Linux z Číny.

Komunikácia webových služieb využíva nasledujúce štandardné technológie:

xml. Jazyk (formát údajov) používaný komponentmi webových služieb.
protokol SOAP. XML správy vymieňané medzi programami
Web Services Description Library (WSDL). Súbor XML, ktorý definuje formát správ SOAP a spôsob ich odosielania

Na komunikáciu medzi webovými službami možno použiť aj štandardnú technológiu známu ako Universal Description, Discovery a Integration (UDDI). Tomu sa budeme venovať neskôr v článku, ale keďže UDDI je voliteľné, mnohé webové služby ho nepoužívajú.

Trochu terminológie: Publikovanie a používanie webových služieb

Skôr než začneme vysvetľovať naše pojmy, pozrime sa na niektoré terminológie súvisiace s webovými službami.

Keď hovoríme o publikovaní webovej služby, máme na mysli program, ktorý publikuje súbor WSDL a umožňuje iným programom používať zodpovedajúcu službu. Programy, ktoré zverejňujú webové služby, sa nazývajú poskytovatelia.

Keď hovoríme o používaní webovej služby, máme na mysli program, ktorý zavolá webovú službu na inom počítači. Používatelia webových služieb sa nazývajú klienti.

XML: rodný jazyk

XML sa používa na komunikáciu medzi komponentmi webovej služby. Správy odosielané medzi aplikáciami, ako aj súbory, ktoré definujú webovú službu, sú vo formáte XML. Obrázok 1 zobrazuje štruktúru jednoduchého súboru XML.

Obrázok 1. Základná štruktúra XML

Ako vidíte, niektoré informácie v súbore (napríklad meno, priezvisko) sú obklopené značkami uzavretými v trojuholníkových zátvorkách. Meno John sa zobrazuje ako John. Existujú aj prvky, v ktorých sú vnorené iné prvky, napríklad v prvku Vnorené prvky , A .

Písanie webových služieb v XML má mnoho výhod, vrátane:

Štruktúra a gramatika XML je podobná štruktúre a gramatike iných programovacích jazykov, takže programy, ktoré interagujú s webovými službami, nemusia priamo analyzovať súbory XML.
Súbory XML sú textové súbory a môže ich čítať človek (inými slovami, ak ovládate jazyk XML, môžete súbor XML otvoriť v textový editor a porozumieť jej obsahu). To môže pomôcť pri ladení.
XML vám umožňuje použiť v správach akékoľvek štandardné kódovanie, takže správy môžete písať v angličtine, ruštine alebo japončine.
XML vám umožňuje používať to, čo sa nazýva menný priestor, v ktorom môžete vopred definovať požadovanú štruktúru elementu súboru so špecifickým názvom. Môžete napríklad definovať prvok Cena, ktorý musí byť vždy pohyblivý, alebo Meno osoby, ktoré obsahuje dva podprvky reťazca, Meno a Priezvisko.
Okrem toho, ak je to potrebné, priestory názvov umožňujú viacerým prvkom s rovnakým názvom mať rôzne definície. Napríklad prvok StockPrice v jednom mennom priestore môže obsahovať symbol a cenu, zatiaľ čo v inom mennom priestore môže pozostávať zo symbolu burzy, ceny, denného minima a maxima a 12-mesačného maxima.

Jediné nevýhody XML, ak sú skutočne nevýhodami, sú:

Jazyk XML je nepružný, takže akékoľvek nesprávne formátovanie správy XML spôsobí zlyhanie analýzy celej správy (aj keď je problém ľahko interpretovateľný alebo prehliadnutý). Ak však na generovanie súborov XML používate štandardnú knižnicu (čo je to, čo robíte pri vytváraní webových služieb), samotná knižnica skontroluje správne formátovanie.
Správa XML je uložená v obyčajnom textovom súbore, a preto zaberá viac miesta ako jej ekvivalent v inom formáte (ako je split, binárny alebo „self-made“ formát).

Tieto problémy sú však irelevantné v porovnaní s výhodami formátu XML.

SOAP: odoslané správy

Viete, že webové služby komunikujú vo formáte XML, ale to rieši len polovicu problému. Aplikácie môžu analyzovať správu, ale ako vedia, čo robiť s analyzovaným výsledkom?

Inštrukcia, ktorá popisuje pravidlá formátovania správ XML pre webové služby, je známa ako SOAP. Definuje štruktúru správy, takže programy vedia, ako odosielať a interpretovať údaje. Základná štruktúra správy SOAP je znázornená na obrázku 2.

Obrázok 2. Základná štruktúra správy SOAP

V XML by to vyzeralo asi takto:

FOO

V základnom prípade máte paket SOAP, ktorý obsahuje telo SOAP a telo, ktoré obsahuje údaje, ktoré sa majú preniesť. Niekedy je tiež voliteľná hlavička SOAP (vnútri paketu pred telom) obsahujúca ďalšie informácie.

inštrukcie SOAP

Aj keď je formát SOAP štandardný a má rovnaké pokyny, je potrebné mať na pamäti, že rôzni výrobcovia môžu tieto pokyny implementovať mierne odlišným spôsobom. Napríklad štruktúra menných priestorov a XML v správe SOAP vygenerovanej Apache Axis sa môže veľmi líšiť od štruktúry generovanej Microsoft .NET. Dobre napísaný klient alebo server však môže spracovať akúkoľvek správu, ktorá je dobre napísaná podľa pokynov SOAP.

Okrem toho existujú niektoré dôležité rozdiely medzi inštrukciami WSDL 1.1 a WSDL 2.0. Hoci je inštrukcia 2.0 v čase písania stále vo finálnej fáze, čoskoro začne nahrádzať verziu 1.1.

ak ste nikdy predtým nenarazili na súbor WSDL a pokúšate sa ho otvoriť a prečítať, bude pre vás ťažké získať odtiaľ všetky informácie, pretože štruktúra takéhoto súboru môže byť dosť zložitá. Všetky informácie o metóde (názov, parametre, protokol atď.) sú rozptýlené v rôznych častiach súboru a musia byť zhromaždené klientskou aplikáciou, aby mohla zostaviť správu SOAP. Popisy častí súboru WSDL a ich spoločná práca nebude v tomto článku.

Tu opäť prichádza na pomoc technika. Ako vývojár nemusíte čítať, analyzovať a rozumieť obsahu súboru WSDL. Nástroje získajú tieto informácie za vás, takže stačí prísť na to, čo poslať službe a kam umiestniť výsledky. nielen vy môžeš používať knižnice a nástroje, ale určite aj budeš. Vo všetkých komponentoch webových služieb existuje veľa výnimiek, problémov a zložitostí a mali by ste sa na to pozrieť použitím Webová služba, a nie jej demontáž, po ktorej nasleduje podrobná štúdia každého komponentu.

Protokoly: spôsob odosielania správ

Ešte sme sa nedotkli otázky, ako sa všetky tieto správy prenášajú cez SOAP?

A zvyčajne sa prenášajú cez sieť (a / alebo internet) pomocou protokolu HTTP, v podstate rovnakým spôsobom, ako sa stránky prenášajú zo servera do vášho prehliadača. HTTP sa nepoužíva vždy (jeho hlavným konkurentom je SMTP, ale je ďaleko pozadu). Protokol používaný webovou službou je definovaný v súbore WSDL.

Typicky je v súbore WSDL protokol používaný na odoslanie správy SOAP definovaný ako HTTP. SOAP klient posiela správy podľa zadaného protokolu.

Ďalšie podmienky webových služieb, s ktorými sa môžete stretnúť

Základné pojmy sme už prebrali, no pri rozprávaní o webových službách možno budete počuť niekoľko ďalších.

Slabé väzby

Programy, ktoré používajú webové služby, sú zvyčajne voľne spojené so službami, to znamená, že služby potrebné na spustenie programu s nimi nie sú priamo viazané, rovnako ako program nie je viazaný na služby. Program môže jednoducho využívať akékoľvek služby, ktoré potrebuje, a čakajú na volanie z programu – z akéhokoľvek programu, ktorý potrebuje ich odpoveď.

Skutočným príkladom slabých väzieb je obed s priateľmi. Niekoľko priateľov sa medzi sebou nejako dohodne (osobne, telefonicky, prostredníctvom email atď.). Do reštaurácie sa dostane každý sám a po večeri si každý platí jedlo sám. Bez ohľadu na to, ako obed prebiehal, konečný výsledok je rovnaký - bol to priateľský obed.

Ale šoférovať auto je akcia s užšími spojeniami. Máte pevne stanovený súbor nástrojov, pomocou ktorých dosiahnete vopred stanovené ciele. Pri odchode z garáže zaradíte spiatočku a stlačíte plyn. Pri odbočovaní doľava otočíte volantom doľava. Nemáte možnosť robiť to isté rôznymi spôsobmi, keďže celý systém je veľmi presný a koordinovaný a každý jeho prvok je prepojený s ostatnými.

UDDI

UDDI je štandard na vytváranie katalógu webových služieb poskytovaných ľubovoľným počtom programov. Je to niečo ako telefónny zoznam pre poskytovateľov webových služieb. Klienti môžu vyhľadať informácie, ktoré potrebujú, v registri UDDI a register vráti údaje, ktoré potrebujú na pripojenie k službe.

Aj keď je UDDI pomerne dôležitým štandardom na definovanie webových služieb, jeho význam výrazne znižuje skutočnosť, že ide o voliteľný prvok webových služieb, a keď dostanú na výber, či ho použiť alebo nie, mnohí sa ho rozhodnú nepoužívať.

Väčšina organizovaných podnikových prostredí s mnohými internými webovými službami má registre UDDI. Je skvelé mať firemnú stránku UDDI, ktorá obsahuje informácie o webových službách dostupných vo vašej spoločnosti. Spojením všetkých služieb vám UDDI umožňuje bezproblémovo a bezproblémovo meniť ich poskytovateľov. Ak si klienti vyhľadajú služby cez UDDI, potom sa volania SOAP automaticky odošlú novému poskytovateľovi.

Tento komponent sa však nevyžaduje v architektúre webových služieb.

Bezpečnosť webových služieb

Keď čítate o SOAP a WSDL, môžete si všimnúť, že téma bezpečnosti nie je pokrytá. Ako prebieha autentifikácia pri volaní služieb, ak poskytovateľ pracuje s citlivými informáciami? Koniec koncov, je jasné, že nie všetky webové služby sú dostupné širokej verejnosti, však?

Toto je dôležitá otázka, na ktorú nie je ľahké jednoznačne odpovedať. Existujú rôzne schémy, ktoré môžete použiť v závislosti od situácie, napríklad:

Môžu správy SOAP prísť ako obyčajný text alebo musia byť šifrované?
Stačí vám jednoduché overenie prihlásením a heslom, alebo by malo byť silné a založené na značkách?
Ak sa používajú tokeny, je potrebné, aby boli podpísané a aký je správny spôsob, ako ich zahrnúť do správy SOAP?
Čo však v prípade, ak klient neposiela správy SOAP priamo, ale prostredníctvom nejakej medzištruktúry, ako je napríklad front správ alebo prostredníctvom inej webovej služby?

Správy tiež nemôžu vždy používať HTTP, takže okrem existujúceho zabezpečenia HTTP nemôžete použiť iba zabezpečenie webových služieb.

Existuje niekoľko pokynov, ktoré pokrývajú tieto a ďalšie aspekty zabezpečenia webových služieb: WS-Security, WS-Policy, WS-Trust a WS-Privacy. Niektorí dodávatelia softvéru a výbory pracujú na týchto otázkach už niekoľko rokov. Hoci nie všetky implementácie webových služieb podporujú všetky bezpečnostné pokyny, existujúce bezpečnostné štandardy zvyčajne implementujú aspoň niekoľko základných bezpečnostných ciest.

Middleware a Enterprise Service Bus

Existuje ďalší pomerne veľký súbor štandardov pre webové služby, združených do jedného pomerne veľkého balíka, bežne označovaného ako inštrukcie WS-*. Spoločne pokrývajú veľa problémov s dizajnom, ktoré sa objavia, keď zhromažďujete veľa webových služieb do jedného prostredia. Štandardy WS-* sa zaoberajú problémami ako:

Bezpečnosť
Spoľahlivosť
Výmena správ
Transakcie
Kvalita služby

Tento počet štandardov je potrebný, pretože posielanie správ medzi klientom webovej služby a serverom v produkčnom prostredí môže byť oveľa zložitejšie ako jednoduchá požiadavka/odpoveď. Ako napríklad zabezpečíte, aby sa správa dostala k poskytovateľovi a vrátila sa klientovi? Čo ak má požiadavka SOAP viacero častí? Ako riadite procesy, ktoré zahŕňajú prístup webových služieb k iným webovým službám? Čo ak program odošle sekvenciu požiadaviek s požiadavkami na čas odozvy?

Pre veľkých dodávateľov softvéru predstavuje práca s týmito štandardmi výzvy aj príležitosti. Niekoľko predajcov ponúka celé balíky middlewaru webových služieb, často označované ako Enterprise Service Bus alebo ESB, ktoré sa zaoberajú všetkými alebo aspoň niektorými z vyššie uvedených úloh naraz. Tieto ESB sú cenné aj preto, že dokážu spojiť viacero webových služieb v rámci tej istej organizácie a poskytovať svoju funkčnosť, zaznamenávať svoje akcie a ukladať správy do frontov.

Architektúra orientovaná na služby

A nakoniec architektúra orientovaná na služby. Vo väčšine prípadov je to len kombinácia všetkého vyššie uvedeného: voľne prepojené webové služby od rôznych dodávateľov, interagujúce podľa akceptovaných štandardov (možno s ESB) a zostavené rôznymi programami, ktoré berú dáta zo služieb a používajú ich rôznymi spôsobmi.

Pretože SOA je softvérová architektúra, jej budovanie vyžaduje veľa koordinácie a plánovania. Nie je to len zhluk služieb pomiešaných dohromady; je to organizácia toho, ako sa služby zostavujú a zverejňujú, aké nástroje na správu a middleware sa používajú a ako sa služby a systém ako celok monitorujú a riadia.

Ak sa pozriete viac globálne, SOA je tiež typ myslenia. Núti nás premýšľať nie o samostatných veľkých programoch, ale všetko vnímať ako možné komponenty, ktoré sa dajú publikovať a použiť vo výrobe. Namiesto bohatých aplikácií myslíte na konkrétne a dobre definované služby – čo sú webové služby.

Prečo je to dôležité?

Teraz už viete niečo o tom, ako fungujú webové služby – klient si prečíta súbor WSDL poskytovateľa, podľa toho naformátuje a odošle správu SOAP a ako odpoveď dostane ďalšiu správu SOAP. Prečo je to teda také dôležité? Čo sa deje?

Časť dôležitosti služieb spočíva v tom, že poskytujú štandardný spôsob komunikácie programov bez ohľadu na jazyky, v ktorých sú napísané, alebo platformy, na ktorých bežia. Predtým sme museli pracovať s formátmi údajov, ktoré sú jedinečné pre rôzne programy, alebo s funkciami na úrovni API, s ktorými programy v iných jazykoch nemohli pracovať. Z používania XML vo všetkých štandardoch webových služieb vyplýva, že všetky služby sú prístupné a jasne definované.

V skutočnosti to umožňuje úplne odlišným programom navzájom jednoducho komunikovať v jazyku, ktorému všetci rozumejú. Jednou z hlavných výziev pri práci s rôznymi technológiami od rôznych výrobcov bola vždy potreba dosiahnuť, aby všetky tieto rôzne programy navzájom komunikovali a vymieňali si údaje. Teraz, keď všetky vaše aplikácie môžu poskytovať a/alebo využívať webové služby, je neuveriteľne ľahké medzi nimi komunikovať.

Ďalšou výhodou webových služieb je, že zákazníci a predajcovia môžu byť na rôznych strojoch, používať rôzny hardvér a softvér, bez toho, aby zasahovali do komunikácie. Programy môžu byť použité inými programami v rámci toho istého počítača alebo z iných počítačov, ale pomocou špecifického formátu prenosu údajov. Webové služby potrebujú iba sieťové pripojenie a obsluhu XML.

Keď sa všetky tieto faktory zohľadnia spolu, výsledok je významný. Keď už máme štandardná náprava pre komunikáciu medzi aplikáciami cez sieť môžeme naše programy zostaviť iným spôsobom. Namiesto písania monolitických programov, v ktorých sa koleso zakaždým znovu vynájde, môžeme písať programy, ktoré sa skladajú z modulov.

Napríklad namiesto veľkého programu, ktorý zhromažďuje informácie o niekoľkých procesoch, premieňa ich na grafy a zobrazuje ich používateľom, môžeme vytvoriť dashboard, ktorý bude zobrazovať údaje prijaté z niekoľkých webových služieb. Zostavené údaje sú prijímané z jednej alebo viacerých služieb a výsledné grafy sú vytvárané inou webovou službou, ktorá berie údaje a vytvára nejaký graf.

Prístrojová doska sa transformuje z veľkého programu na jednoduché rozhranie. Keď chceme pridať nové komponenty, jednoducho si zavoláme ďalšie služby. Ak potrebujeme iný graf, obrátime sa na inú grafickú službu. Ak potrebujeme interaktívnejší dashboard so schopnosťou učiť sa alebo triediť, potom dashboard môže odovzdávať správy od používateľa príslušnej službe. Môžeme dokonca úplne zmeniť volané služby bez toho, aby si to používatelia všimli (kým sa nezmení súbor WSDL) a panel zostane rovnaký.

Ako IT profesionál môžete vyvinúť front-end, vývoj služieb alebo oboje. Pre prácu na takomto projekte je dôležité pochopiť, ako to všetko spolu funguje (alebo aspoň vedieť, čo to je).

Je tiež dobré, že existuje veľa nástrojov, ktoré vám pomôžu poskytovať a využívať webové služby a môžu za vás urobiť veľa ťažkej práce. V nasledujúcich častiach tohto článku uvidíme, ako môžete jednoducho dodávať webové služby klientom alebo systémom pomocou IBM Lotus Domino V7.0.