Veebiteenus - mis see on. XML-i veebiteenused. Tehnoloogia ülevaade

Veebiteenuste idee töötasid välja arvutitööstuse hiiglased nagu Sun, Oracle, HP, Microsoft ja IBM. See idee pole midagi uut, kuid see on suur samm edasi programmidele veebi kaudu hõlpsama juurdepääsu suunas. Standardsetele suhtlusvormingutele tuginedes võivad veebiteenused täielikult muuta meie suhtumist sellesse, kuidas veebisaite teha.

Mis on veebiteenus?

Tänu veebiteenustele saab mis tahes programmi funktsioone Interneti kaudu kättesaadavaks teha. Seega saavad sellised programmid nagu PHP, ASP, JSP skriptid, JavaBeans, COM-objektid ja kõik muud meie lemmikprogrammeerimistööriistad nüüd juurde pääseda mõnele teises serveris töötavale programmile (st veebiteenusele) ja kasutada temalt saadud vastust tema veebisaidil või rakendus.

Oletame, et kui mul on vaja mõnda programmeerimisülesannet täita ja ma olen liiga hõivatud (või ei suuda ise jalgratast uuesti leiutada), saan kasutada veebiteenuse teenuseid, millele mu sait Interneti kaudu juurde pääseb. Parameetritega päringu veebiteenusele edastamisel ootan, et saan vastuse, mis sisaldab minu päringu täitmise tulemust.

Igaüks, kes on kunagi töötanud Hiljuti Koos Hotmail, on veebiteenustega juba osaliselt kokku puutunud: kasutajate autentimissüsteem Passport on üks Microsofti .NET-i algatusse kaasatud teenustest. See on praegu tasuta saadaval, nii et veebisaitide loojad saavad hõlpsasti oma saidil kasutaja autentimist rakendada.

Põhitõed

Veebiteenuste põhimõtted on üllatavalt lihtsad. Ja nad ei lisa hajutatud andmetöötluse ja Interneti maailmale midagi uut:

  • veebiteenuse eest vastutav isik määrab oma veebiteenusele esitatavate päringute vormingu ja vastused
  • iga võrgus olev arvuti esitab päringu veebiteenusele
  • veebiteenus töötleb päringu, teeb mõne toimingu ja saadab seejärel vastuse

See toiming võib olla näiteks börsihinna kuvamine, konkreetse toote hinna kuvamine, kirje salvestamine kohtumiste kalendrisse, teksti tõlkimine ühest keelest teise või krediitkaardi numbri kontrollimine.

Standardid keskmes

Põhjus, miks me kõik äkki veebiteenuste vastu huvi tunneme, on see, et need põhinevad standarditel, avatud andmevahetuse ja -edastuse protokollidel.

Enne seda töötasid paljud ettevõtted välja oma patenteeritud standardid ja vormingud. Ja nüüd on meil vaja vaid teada lihtsat XML-i (eXtensible Markup Language), mida edastatakse vana tuttava HTTP-protokolli kaudu. See tähendab, et teave veebiteenuste toimimise kohta on kõigile kättesaadav ja veebiarendajad, kes on nende tehnoloogiatega erialalt tuttavad, saavad veebiteenustega mängima hakata juba täna.

Veebiteenuste ja muude arendajate kohatud tehnoloogiate (näiteks DCOM, named pipes, RMI) erinevus seisneb selles, et veebiteenused põhinevad avatud standarditel, neid on lihtne õppida ja neid standardeid toetatakse laialdaselt kogu maailmas ja Windowsi platvormid.

Simple Object Access Protocol (SOAP) on standardprotokoll, mille on välja töötanud W3C. See määrab veebiteenuste päringute vormingu.

Veebiteenuse ja selle kasutaja vahelised sõnumid pakitakse SOAP-ümbrikutesse. Sõnumid sisaldavad kas taotlust mõne toimingu sooritamiseks või vastust – selle toimingu tulemust. Ümbrik ja selle sisu on kodeeritud XML-vormingus ja neid on üsna lihtne mõista. Lihtne SOAP-päring näeb välja selline, kui see saadetakse HTPP kaudu veebiteenusele:

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


xmlns:m="http://www.somesite.com/Postcode">
WC1A8GH
Ühendkuningriik


SOAP-ümbriku põhielemente on üsna lihtne teada saada: need on kaks parameetrit ( ("postiindeks") ja ("riik")), mis sisalduvad elemendis nimega . See element on selle veebiteenuse nimi, millele me päringu esitame. Muud ümbrikus olevad andmed, nagu teksti kodeering ja SOAP-versioon, aitavad veebiteenusel päringut õigesti töödelda.

Ja vastus näeb välja selline:

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">
Jah


Seda sõnumit on veelgi lihtsam dešifreerida. Element meie taotluses muudeti elemendiks vastuseks palvele. See element sisaldab ainult ühte elementi , mille väärtus näitab, kas meie sihtnumber on õige või mitte. Seega oleme SOAPi võlu abil loonud päringu, mis teeb meie jaoks kasulikku tööd. Vastuseks võrgu kaudu saame teatud tüüpi vastuse XML-vormingus.

Nüüd UDDI kohta

Kuigi SOAP-protokoll on lihtne, oleks veebiteenustest vähe kasu, kui meil poleks võimalust neid leida. Õnneks astusid IBM, Microsoft ja Ariba hoogu ja lõid universaalse kirjelduse, avastamise ja integratsiooni (UDDI) projekti, millest nad loodavad saada kõigi veebiteenuste ühiseks kataloogiks.

UDDI-süsteem võimaldab ettevõtetel oma veebiteenust avalikkusele tutvustada. See kataloog toimib kõigi veebiteenuste telefoniraamatuna. Registreerimine UDDI kataloogis on tasuta ja projekti asutajad loodavad, et see kataloog sisaldab kõigi, kõigi, kõigi veebiteenuste kirjeldusi, nii et soovitud veebiteenuse leidmiseks piisab vaid ühe poole pöördumisest. UDDI kataloog.

Kuidas see kõik töötab

Kuidas siis õiget veebiteenust leida?

Kujutagem ette, et olen veebisaidi arendaja ja mu klient palus mul saidile lisada uus funktsioon: peate oma registreerimisvormile lisama sihtnumbri kontrolli.

Selle kontrolli teostamiseks peaksin looma kõigi 30 riigi sihtnumbrite andmebaasi, kus meie ettevõte tegutseb, ning seejärel kontrollima, kas sihtnumber vastab registreerimisel märgitud linnale. Kuid mul pole neid andmeid ja arvan, et selliste andmete kogumine peab kulutama märkimisväärse summa raha.

Selle asemel, et koguda raha andmebaasi ostmiseks, ise koodi kirjutamiseks, kõigi andmete terviklikkuse ja õigsuse tagamiseks ning skriptide silumiseks, lähen lihtsalt UDDI kataloogi ja vaatan, kas on olemas veebiteenus, mis saaks selle töö ära teha. mina . Saabudes saidile www.uddi.org, käivitan otsingu ja leian suurepärase teenuse XYZ Corp.

Vaatan hoolikalt üle veebiteenuse vormingu määratlus (definitsioon on kirjutatud WSDL-s (Web Services Description Language), veendudes, et teenus teeb täpselt seda, mida vajan. Seejärel uurin kolleegidega XYZ Corp. mainet ja uurin et see on kindel , ja võtke seejärel hinnaküsimusega ühendust XYZ Corpiga. Kui teenusele juurdepääsu hind jääb minu eelarve piiresse, kirjutan oma saidi jaoks lihtsa JSP-lehe, mis kutsub XYZ Corpi veebiteenust, ja ennäe, kohene kinnitus. kuvatakse saidil.

See on teie aega väärt

Isegi kui teil pole programmeerimise või veebisaidi arendamise tehnoloogiatega midagi pistmist, tasub veebiteenuste kohta rohkem teada saada. Kujutage ette pilti, kuidas arutate kliendiga uut veebisaiti, arutades kõiki uue projekti funktsioone. Kõik läheb suurepäraselt: eelarve vastab kliendi ootustele, talle meeldis kohaplaani eskiis ja meeldisid liidese näited. Tundub, et kõik töötab.

Ja järsku meenuvad nad mõne väga keerulise funktsiooniga. Ainuüksi selle mainimisel muutub teie veebiarendaja nägu roheliseks ning ta hakkab lämbuma ja köhima. See on arendaja, kes annab teile signaali, et selle funktsiooni arendamine nõuab palju raha ja aega või pole lihtsalt sellise eelarvega teostatav.

Loobu oma hirmust! Olen valmis garanteerima, et Internetis on juba olemas veebiteenus, mis on valmis teile vajaliku funktsiooni pakkuma ja selle veebiteenuse kasutamise maksumus on palju madalam kui selle analoogi iseseisva arendamise maksumus. Nii säästad oma arendajat tarbetutest peavaludest ja klienti tarbetuid jäätmeid raha lihtsalt kulutades paar minutit UDDI kataloogi sirvides.

Teenuse arendamine

Loomulikult ei pea arendajad rahulduma ainult teiste loodud veebiteenustega. Kasutades ühte järgmistest tööriistakomplektidest, saate luua oma veebiteenuse ja pakkuda selle teenuseid teistele Interneti-kasutajatele.

Tööriistade valik veebiteenuste arendamiseks on lai. See sisaldab tööriistu sellistelt ettevõtetelt nagu Sun (Open Net), Microsoft (.NET), (e-teenused) ja IBM (veebiteenused). Samuti on avatud lähtekoodiga raamistikud. Näiteks on Mono projekti eesmärk asendada Microsofti .NET-i tööriistakomplekt, pakkudes kompilaatoreid, käituskeskkonda ja teeke, et käitada samu veebiteenuseid kõigil platvormidel, sealhulgas Unixis.

Vaatamata mitmesugustele serveritele ja veebiteenuste arendustööriistadele toetavad need kõik sama SOAP-protokolli, XML-keelt ja UDDI-süsteemi.

Miinused

Enne kui loobun täielikult oma programmeerijakarjäärist ja pühendun veebiteenuste kasutamisele, pean endalt küsima: "See on liiga roosiline pilt, mis sellel viga on?" Kahjuks on veebiteenuste suurel potentsiaalil oma hind:

  • XML-i kasutamine andmeedastusvorminguna tähendab, et teie sõnumid on väga suured: XML-sildid ise võtavad palju ruumi ja see paneb meile teatud koormuse sõnumite loomisel, edastamisel ja tõlgendamisel.
  • Kuna me kasutame kaugarvutid Loodame teatud funktsioonide täitmisel täielikult Internetile, mis loob meie veebiserveri ja veebiteenuse vahelises ahelas liiga palju ebausaldusväärseid linke.
  • Tänapäeval loovad veebiteenuseid vähesed ettevõtted ja vähesed ettevõtted kasutavad neid. Veebiteenuste süsteemi silumine ja täiustamine nõuab veel palju aega.
  • Veebiteenuste kasutamise litsentsimise ja tasustamise süsteemi peavad arendajad veel aktsepteerima. Kuna veebiteenuseid on endiselt liiga vähe, püüab enamik ettevõtteid jätta potentsiaalsetele klientidele hea mulje, vähendades teadlikult teenuste maksumust ja pakkudes soodsaid litsentsimistingimusi. Läheb veel aega, enne kui veebiteenuste tegelik hind selgub.

Kui veebiteenused võtavad oma koha ja muutuvad kõigile kättesaadavaks, saavad neist veebiarendajatele hindamatu abi. Need annavad meile paindliku juurdepääsu kõigi võrgus olevate arvutite täisvõimsusele. Veebisaitide koostajatel on aeg hakata veebiteenuste vastu huvi tundma ja rohkem teada saada, mida neilt saada on.

Märkus: Kasutusvaldkonnad. Eelised. NET-platvormi veebiteenuste arendamise omadused. Veebiteenuse kirjeldus ja avastamine

Mis on XML-i veebiteenus?

Infotehnoloogia arenedes tekkisid erinevad lähenemised programmide kirjutamisele: modulaarne programmeerimine, sündmustepõhine programmeerimine, komponentidele orienteeritud programmeerimine ja disain. Nende lähenemisviiside loogiline jätk oli teenustele orienteeritud tarkvara arendamine.

Teenusele orienteeritud lähenemiste kasutamine võimaldab rääkida taaskasutusest makrotasandil (teenusetasemel), mitte mikrotasandil (objekti tasandil). Teenusele orienteeritud lähenemisviis kasutab lihtsaid ja üldtunnustatud standardeid, mis võimaldab paljudel erinevatel rakendustel üksteise funktsionaalsust jagada. Teenused saab kirjutada mitmesuguste programmeerimiskeelte abil erinevatel platvormidel. Lisaks saab teenuseid juurutada eraldi või tarkvarapaketi osana kõikjal maakera ja võimaldab seega juurdepääsu nende funktsioonidele võrgu kaudu.

Helistame teenus ressurss, mis rakendab ärifunktsiooni ja millel on järgmised omadused:

  • on korduvkasutatav;
  • määratletud ühe või mitme selgesõnalise tehnoloogiast sõltumatu liidesega;
  • on lõdvalt seotud teiste sarnaste ressurssidega ja seda saab käivitada sideprotokollide kaudu, mis võimaldavad ressurssidel üksteisega suhelda.

Teenuse erijuhtum on XML-veebiteenus.

XML-veebiteenus on spetsiaalset tüüpi veebirakendus, mis:

  • juurutatud veebiserverisse;
  • avaldab veebimeetodid, mida väliskliendid saavad kutsuda;
  • ootab HTTP-päringute laekumist, mis on käsklused veebimeetodite kutsumiseks;
  • käivitab veebimeetodid ja tagastab tulemused.

Erinevalt traditsioonilisest veebirakendusest ei ole veebiteenusel kasutajaliidest. Selle asemel on sellel programmeerimisliides, st veebiteenus paljastab funktsioonid (veebimeetodid), millele saab helistada eemalt (näiteks Interneti kaudu). Veebiteenus ei ole mõeldud lõppkasutajate teenindamiseks. Selle ülesanne on pakkuda teenuseid teistele rakendustele, olgu need siis veebirakendused, GUI-rakendused või konsoolirakendused.

Veebiteenus võib pakkuda reaalajas teavet aktsiahindade kohta, kontrollida krediitkaarte või edastada ilmateadet. Veebiteenused on sama mitmekesised kui tavalised rakendused.

Veebiteenused ei ole konkreetse ettevõtte omand. See on tööstusstandard, mis põhineb avatud protokollidel (SOAP, HTTP jne). Veebiteenuseid juurutatakse erinevatel platvormidel (sh Windowsi või UNIX-i kasutavates serverites). Veebiteenuseid saab arendada paljude arendustööriistade abil (alates tekstiredaktor Microsoft Visual Studio perekonda).

Enamiku veebiteenuste meetodeid kutsuvad esile SOAP-sõnumeid sisaldavad HTTP-päringud. SOAP on XML-keel (XML-sõnavara) kaugprotseduuride kutsumiseks HTTP ja muude protokollide kaudu (SOAP-i täielik kirjeldus http://www.w3.org/TR/SOAP) .

Veebiteenuste koht muude kaugkõnetehnoloogiate hulgas

Kaugkutsumise protokolle ja tehnoloogiaid on üsna palju: Microsoft Distributed Component Object Model (DCOM), Object Management Group'i ühine objektipäringu vahendaja arhitektuur (CORBA), Suni kaugmeetodi kutsumine (RMI), . NET Remoting, XML-veebiteenused.

Kõiki neid komponendipõhiseid tehnoloogiaid (DCOM, CORBA ja RMI) on sisevõrgurakendustes edukalt kasutatud juba aastaid. Need pakuvad usaldusväärset, skaleeritavat arhitektuuri. Nende tehnoloogiate kasutamisel Internetis on aga kaks tõsist probleemi. Esiteks ei suhtle nad üksteisega hästi. Kõik tehnoloogiad töötavad objektidel, kuid erinevad oluliselt üksikasjades: elutsükli haldamine, konstruktori tugi ja päranditoetuse aste. Teine, olulisem aspekt on see, et keskendumine RPC interaktsioonidele viib tihedalt seotud süsteemide ehitamiseni, mis põhinevad selgesõnalistel väljakutsetel objektimeetoditele.

Erinevalt nendest tehnoloogiatest, XML Web Services ja. NET Remoting on täielikult rakendatud objektorienteeritud lähenemine veebiprogrammeerimiseks.

XML-i veebiteenus- komponent, mis pakub Interneti-klientidele API-funktsioonide või veebimeetodite komplekti. XML sisaldub nimes, kuna veebiteenused ja nende kliendid kasutavad seda andmete vahetamiseks. Veebiteenused põhinevad avatud standarditel, nagu HTTP, XML (Extensible Markup Language), SOAP (Simple Object Access Protocol – Inteneti standard, mis kirjeldab, kuidas rakendused saavad suhelda, st kutsuda üksteise meetodeid HTTP ja muude protokollide abil). Veebiteenuste peamine ülesanne on tagada programmidevaheline suhtlus. Paljud töötavad UNIX-i serverites ja neile pääsevad juurde Windowsi kliendid. Veebiteenustele saadetavad andmed järjestatakse XML-vormingus ja saadetakse SOAP-pakettidena. Metaandmed selliste sõnumite sisu kohta salvestatakse veebiteenuse WSDL lepingus ja XSD skeemides. Selle lähenemisviisi peamine eelis on metaandmete loetavus. Arendaja saab hõlpsasti vaadata kogu veebiteenuse kirjeldust ja isegi luua oma mooduli, mis parsib SOAP-pakette.

.NET Remoting pakub infrastruktuuri hajutatud objektidele. See on palju keerulisem kui lihtne sõnumeid edastav veebiteenuste arhitektuur. . NET Remoting sisaldab parameetrite edastamist viite ja väärtuse järgi, tagasihelistusi, mitme objekti aktiveerimist ja elutsükli halduspoliitikat. Nende funktsioonide kasutamiseks peab klientrakendus valdama kõiki tehnoloogiaid. Andmed c. NET Remoting edastatakse kahend- või SOAP-vormingus. Kuid igal juhul sisalduvad metaandmed edastatava teabe struktuuri kohta levinud keele täitmiskeskkonnas. Ilma ühise keele käitusaja (CLR)ta ei saa klientrakendus keelepõhiseid sõeluda. NET Remoting SOAP päised. See on. NET Remoting seab veebiteenustega võrreldes oluliselt kõrgemad nõuded.

Veebiteenuste arendamine .NET platvormil

Veebiteenuste kirjutamiseks on palju võimalusi. Neid saab arendada käsitsi või Microsofti, IBMi jne SOAP-tööriistade abil. Veebiteenuste kirjutamine Microsofti abil. NET-il on kaks eelist:

  • .NET Framework lihtsustab oluliselt arendusprotsessi, pakkudes klassiteegi ja automatiseerides individuaalseid arendusetappe;
  • NET Frameworkiga kirjutatud veebiteenused on hallatavad rakendused. See tähendab, et sellistel rakendustel pole probleeme mälulekke, valesti lähtestatud osutite ja muude tüüpiliste programmeerimisprobleemidega.

Loomine

Arendame välja lihtsa AdditionService'i veebiteenuse, mis lisab kaks numbrit. Sellel on ainult üks lisamismeetod, mis võtab parameetrina kaks täisarvu ja tagastab ka täisarvu. AdditionService demonstreerib mitmeid olulisi veebiteenuste programmeerimise põhimõtteid Microsoft .NET Frameworki abil.

  • Veebiteenused on rakendatud ASMX-failidena. ASMX on spetsiaalne failinimelaiend, mis on registreeritud ASP .NET-i (täpsemalt ASP.NET HTTP-käitleja) peamises ASP .NET Machine.config konfiguratsioonifailis.
  • ASMX-failid algavad @WebService direktiiviga. See käsk peab sisaldama vähemalt atribuuti Class, mis määrab klassi, millest veebiteenus koosneb.
  • Veebiteenuse klassidel võivad olla valikulised WebService atribuudid. IN selles näites See atribuut määrab veebiteenuse nime ja kirjelduse, mis kuvatakse HTML-lehel, kui kasutaja kutsub brauseris AdditionService.asmx.
  • Veebimeetodid deklareeritakse, määrates veebiteenuse klassi avalikele meetoditele atribuudi WebMethod. Abimeetodite puhul, mida kasutatakse sisemiselt, kuid mis pole välistele klientidele kättesaadavad, pole seda atribuuti lihtsalt määratud.
  • HTTP, XML ja SOAP on "nähtamatud". .NET Framework käsitleb XML-andmeid ja SOAP-sõnumeid.

AdditionService.asmx<%@ WebService language="C#" Class="AddService" %>kasutades System kasutades System.Web.Services klassi AddService ( avalik int Add (int a, int b) ( return a + b ) )

Vaatamata oma väiksusele on AdditionService.asmx täisväärtuslik veebiteenus, kui see on installitud ASP.NET-iga veebiserverisse. Selle meetodeid kutsutakse SOAP-i, HTTP GET-i ja HTTP POST-i abil ning see võib tulemusi tagastada SOAP-vastustena või lihtsate XML-mähistena.

Taustkoodi kasutades saab veebiteenuste klasse asmx-failidest eraldi failidesse teisaldada.

Veebiteenused toetavad kasutamist keerulised andmetüübid sisend- või väljundparameetritena. Keerulisi andmetüüpe toetatakse, kuna XML võimaldab enamikku andmetüüpe hõlpsasti jadada. Veebiteenuse automaatsel testimisel ei loo ASP .NET aga aktsepteeritavate meetodite jaoks testlehti keerulised tüübid andmeid. See juhtub seetõttu, et te ei saa HTTP GET-i ja POST-i abil veebimeetodile keerulisi andmetüüpe edastada.

Veebiteenused võimaldavad teil kutsuda nende meetodeid asünkroonselt. Asünkroonne kõne tagastab juhtimise kohe, olenemata sellest, kui kaua veebiteenusel kõne töötlemiseks kulub. Asünkroonsed kõned on kasulikud, kui kõne töötlemine võtab palju aega. Rakendus teeb kõne, jätkab seejärel töötamist kõne tulemust ootamata ja saab hiljem asünkroonse kõne tulemused. Tulemuse saadakse, helistades uuesti veebimeetodile rakendusele sobival ajal või tellides veebiteenuse kõne töötlemise lõpetamise teatise (delegeerimismehhanism).

Veebiteenuseid saab luua kasutades selliseid tööriistu nagu Microsoft Visual Studio 2005. Selle pakutavate veebiteenuste loomiseks eraldi tüüp ASP .NET Web Service projekt. Visual Studio genereerib asmx-faili, taustakoodiga faili veebiteenuse klasside kirjeldamiseks, veebiteenuse konfiguratsioonifaili jne. Kui projekt käivitatakse täitmiseks, kompileeritakse teenuseklassid ja avatakse brauseriaknas asmx-fail .

Veebiteenuste kirjeldus lepingute abil

Et teised arendajad saaksid AdditionService'i kasutada, peavad nad teadma, milliseid meetodeid see pakub, milliseid protokolle see toetab, meetodi allkirju ja veebiteenuse aadressi (URL). Kogu seda ja muud teavet saab kirjeldada WSDL-is (Web Service Description language).


Veebiteenuse avastamine

Kuidas teised arendajad AdditionServicei olemasolust teavad?

Esiteks, kasutades DISCO-d (lühend sõnast discovery) - failipõhist mehhanismi kohalike veebiteenuste otsimiseks, see tähendab mehhanismi saadaolevate veebiteenuste loendi hankimiseks veebiserverites asuvatest DISCO-failidest. Lisaks sisaldavad DISCO-failid saadaolevate teenuste WSDL-lepingute asukoha kirjeid. DISCO-fail on kirjetega XML-fail.

Samuti on võimalik kasutada VSDISCO faile, mis on sarnased DISCO failidega, kuid nende sisu on määratud kataloogides ja kõigis alamkataloogides veebiteenuste dünaamilise otsingu tulemus. ASP .NET kaardistab .vsdisco failinime laiendi HTTP-käsitlejaga, mis otsib antud kataloogist ja selle alamkataloogidest asmx ja disco ning tagastab dünaamiliselt genereeritud DISCO dokumendi. Turvakaalutlustel on dünaamiline otsing mõnes .NET Frameworki versioonis keelatud, kuid saate selle lubada, muutes faili Machine.config kirjeid.

Kuidas otsite ülemaailmsest võrgust veebiteenuseid? Globaalsest võrgust veebiteenuste otsimiseks töötasid Microsoft, IBM ja Ariba ühiselt välja UDDI (Universal Description Discovery and Integration) – spetsifikatsiooni hajutatud andmebaaside loomiseks, mis võimaldab otsida veebiteenuseid. UDDI-d toetavad sajad ettevõtted. UDDI saidid on ise veebiteenused. Igaüks saab avaldada oma UDDI-põhise registri. Enamik arendajaid ei kasuta kunagi UDDI API-d otse. Selle asemel pääseb UDDI registritele juurde arendustööriistad. Samuti loovad nad avastatud ja valitud veebiteenuste jaoks ümbrisklasse.

Tulemused

XML-veebiteenus on tarkvarakomponent, mis pakub enamiku jaoks kasutatavaid funktsioone erinevad süsteemid, mis toetavad standardeid, nagu XML ja HTTP, võivad olla nii kohalikud kui ka kaugrakendused. Veebiteenused võimaldavad luua struktuure, mis lihtsustavad erinevate süsteemide integreerimist lihtsate üldtunnustatud standardite alusel.

Veebiteenuste idee töötasid välja arvutitööstuse hiiglased nagu Sun, Oracle, HP, Microsoft ja IBM. See idee pole midagi uut, kuid see on suur samm edasi programmidele veebi kaudu hõlpsama juurdepääsu suunas. Standardsetele suhtlusvormingutele tuginedes võivad veebiteenused täielikult muuta meie suhtumist sellesse, kuidas veebisaite teha.

Mis on veebiteenus?

Tänu veebiteenustele saab mis tahes programmi funktsioone Interneti kaudu kättesaadavaks teha. Seega saavad sellised programmid nagu PHP, ASP, JSP skriptid, JavaBeans, COM-objektid ja kõik muud meie lemmikprogrammeerimistööriistad nüüd juurde pääseda mõnele teises serveris töötavale programmile (st veebiteenusele) ja kasutada temalt saadud vastust tema veebisaidil või rakendus.

Oletame, et kui mul on vaja mõnda programmeerimisülesannet täita ja ma olen liiga hõivatud (või ei suuda ise jalgratast uuesti leiutada), saan kasutada veebiteenuse teenuseid, millele mu sait Interneti kaudu juurde pääseb. Parameetritega päringu veebiteenusele edastamisel ootan, et saan vastuse, mis sisaldab minu päringu täitmise tulemust.

Kõik, kes on kunagi hiljuti Hotmailiga töötanud, on veebiteenustega juba mõnevõrra kokku puutunud: Passporti kasutaja autentimissüsteem on üks Microsofti .NET-i algatusse kaasatud teenustest. See on praegu tasuta saadaval, nii et veebisaitide loojad saavad hõlpsasti oma saidil kasutaja autentimist rakendada.

Põhitõed

Veebiteenuste põhimõtted on üllatavalt lihtsad. Ja nad ei lisa hajutatud andmetöötluse ja Interneti maailmale midagi uut:

  • veebiteenuse eest vastutav isik määrab oma veebiteenusele esitatavate päringute vormingu ja vastused
  • iga võrgus olev arvuti esitab päringu veebiteenusele
  • veebiteenus töötleb päringu, teeb mõne toimingu ja saadab seejärel vastuse

See toiming võib olla näiteks börsihinna kuvamine, konkreetse toote hinna kuvamine, kirje salvestamine kohtumiste kalendrisse, teksti tõlkimine ühest keelest teise või krediitkaardi numbri kontrollimine.

Standardid keskmes

Põhjus, miks me kõik äkki veebiteenuste vastu huvi tunneme, on see, et need põhinevad standarditel, avatud andmevahetuse ja -edastuse protokollidel.

Enne seda töötasid paljud ettevõtted välja oma patenteeritud standardid ja vormingud. Ja nüüd on meil vaja vaid teada lihtsat XML-i (eXtensible Markup Language), mida edastatakse vana tuttava HTTP-protokolli kaudu. See tähendab, et teave veebiteenuste toimimise kohta on kõigile kättesaadav ja veebiarendajad, kes on nende tehnoloogiatega erialalt tuttavad, saavad veebiteenustega mängima hakata juba täna.

Veebiteenuste ja muude arendajate kohatud tehnoloogiate (näiteks DCOM, named pipes, RMI) erinevus seisneb selles, et veebiteenused põhinevad avatud standarditel, neid on lihtne õppida ja neid standardeid toetatakse laialdaselt kogu maailmas ja Windowsi platvormid.

Simple Object Access Protocol (SOAP) on standardprotokoll, mille on välja töötanud W3C. See määrab veebiteenuste päringute vormingu.

Veebiteenuse ja selle kasutaja vahelised sõnumid pakitakse SOAP-ümbrikutesse. Sõnumid sisaldavad kas taotlust mõne toimingu sooritamiseks või vastust – selle toimingu tulemust. Ümbrik ja selle sisu on kodeeritud XML-vormingus ja neid on üsna lihtne mõista. Lihtne SOAP-päring näeb välja selline, kui see saadetakse HTPP kaudu veebiteenusele:

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


xmlns:m="http://www.somesite.com/Postcode">
WC1A8GH
Ühendkuningriik

SOAP-ümbriku põhielemente on üsna lihtne ära tunda: need on kaks parameetrit (("postiindeks") ja ("riik")), mis sisalduvad elemendi sees nime all. See element on selle veebiteenuse nimi, millele me päringu esitame. Muud ümbrikus olevad andmed, nagu teksti kodeering ja SOAP-versioon, aitavad veebiteenusel päringut õigesti töödelda.

Ja vastus näeb välja selline:

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">
Jah

Seda sõnumit on veelgi lihtsam dešifreerida. Meie päringu element on muutunud päringu vastuse elemendiks. See element sisaldab ainult ühte elementi, mille väärtus näitab, kas meie postiindeks on õige või mitte. Seega oleme SOAPi võlu abil loonud päringu, mis teeb meie jaoks kasulikku tööd. Vastuseks võrgu kaudu saame teatud tüüpi vastuse XML-vormingus.

Nüüd UDDI kohta

Kuigi SOAP-protokoll on lihtne, oleks veebiteenustest vähe kasu, kui meil poleks võimalust neid leida. Õnneks astusid IBM, Microsoft ja Ariba hoogu ja lõid universaalse kirjelduse, avastamise ja integratsiooni (UDDI) projekti, millest nad loodavad saada kõigi veebiteenuste ühiseks kataloogiks.

UDDI-süsteem võimaldab ettevõtetel oma veebiteenust avalikkusele tutvustada. See kataloog toimib kõigi veebiteenuste telefoniraamatuna. Registreerimine UDDI kataloogis on tasuta ja projekti asutajad loodavad, et see kataloog sisaldab kõigi, kõigi, kõigi veebiteenuste kirjeldusi, nii et soovitud veebiteenuse leidmiseks piisab vaid ühe poole pöördumisest. UDDI kataloog.

Kuidas see kõik töötab

Kuidas siis õiget veebiteenust leida?

Kujutagem ette, et olen veebisaidi arendaja ja mu klient palus mul saidile uue funktsiooni lisada: pean registreerimisvormile lisama sihtnumbri kontrolli.

Selle kontrolli teostamiseks peaksin looma kõigi 30 riigi sihtnumbrite andmebaasi, kus meie ettevõte tegutseb, ning seejärel kontrollima, kas sihtnumber vastab registreerimisel märgitud linnale. Kuid mul pole neid andmeid ja arvan, et selliste andmete kogumine peab kulutama märkimisväärse summa raha.

Selle asemel, et koguda raha andmebaasi ostmiseks, ise koodi kirjutamiseks, kõigi andmete terviklikkuse ja õigsuse tagamiseks ning skriptide silumiseks, lähen lihtsalt UDDI kataloogi ja vaatan, kas on olemas veebiteenus, mis saaks selle töö ära teha. mina . Saabudes aadressile www.uddi.org, käivitan otsingu ja leian suurepärase teenuse XYZ Corp.

Vaatan hoolikalt üle veebiteenuse vormingu määratlus (definitsioon on kirjutatud WSDL-s (Web Services Description Language), veendudes, et teenus teeb täpselt seda, mida vajan. Seejärel uurin kolleegidega XYZ Corp. mainet ja uurin et see on kindel , ja võtke seejärel hinnaküsimusega ühendust XYZ Corpiga. Kui teenusele juurdepääsu hind jääb minu eelarve piiresse, kirjutan oma saidi jaoks lihtsa JSP-lehe, mis kutsub XYZ Corpi veebiteenust, ja ennäe, kohene kinnitus. kuvatakse saidil.

See on teie aega väärt

Isegi kui teil pole programmeerimise või veebisaidi arendamise tehnoloogiatega midagi pistmist, tasub veebiteenuste kohta rohkem teada saada. Kujutage ette pilti, kuidas arutate kliendiga uut veebisaiti, arutades kõiki uue projekti funktsioone. Kõik läheb suurepäraselt: eelarve vastab kliendi ootustele, talle meeldis kohaplaani eskiis ja meeldisid liidese näited. Tundub, et kõik töötab.

Ja järsku meenuvad nad mõne väga keerulise funktsiooniga. Ainuüksi selle mainimisel muutub teie veebiarendaja nägu roheliseks ning ta hakkab lämbuma ja köhima. See on arendaja, kes annab teile signaali, et selle funktsiooni arendamine nõuab palju raha ja aega või pole lihtsalt sellise eelarvega teostatav.

Loobu oma hirmust! Olen valmis garanteerima, et Internetis on juba olemas veebiteenus, mis on valmis teile vajaliku funktsiooni pakkuma ja selle veebiteenuse kasutamise maksumus on palju madalam kui selle analoogi iseseisva arendamise maksumus. Nii säästate oma arendajat tarbetute peavalude eest ja klienti raha raiskamisest, kulutades vaid paar minutit UDDI kataloogi sirvides.

Teenuse arendamine

Loomulikult ei pea arendajad rahulduma ainult teiste loodud veebiteenustega. Kasutades ühte järgmistest tööriistakomplektidest, saate luua oma veebiteenuse ja pakkuda selle teenuseid teistele Interneti-kasutajatele.

Tööriistade valik veebiteenuste arendamiseks on lai. See sisaldab tööriistu sellistelt ettevõtetelt nagu Sun (Open Net), Microsoft (.NET), HP (e-teenused) ja IBM (veebiteenused). Samuti on avatud lähtekoodiga raamistikud. Näiteks on Mono projekti eesmärk asendada Microsofti .NET-i tööriistakomplekt, pakkudes kompilaatoreid, käituskeskkonda ja teeke, et käitada samu veebiteenuseid kõigil platvormidel, sealhulgas Unixis.

Vaatamata mitmesugustele serveritele ja veebiteenuste arendustööriistadele toetavad need kõik sama SOAP-protokolli, XML-keelt ja UDDI-süsteemi.

Miinused

Enne kui loobun täielikult oma programmeerijakarjäärist ja pühendun veebiteenuste kasutamisele, pean endalt küsima: "See on liiga roosiline pilt, mis sellel viga on?" Kahjuks on veebiteenuste suurel potentsiaalil oma hind:

  • XML-i kasutamine andmeedastusvorminguna tähendab, et teie sõnumid on väga suured: XML-sildid ise võtavad palju ruumi ja see paneb meile teatud koormuse sõnumite loomisel, edastamisel ja tõlgendamisel.
  • Kuna me kasutame teatud funktsioonide täitmiseks kaugarvuteid, siis tugineme täielikult Internetile, mis loob meie veebiserveri ja veebiteenuse ahelasse liiga palju ebausaldusväärseid linke.
  • Tänapäeval loovad veebiteenuseid vähesed ettevõtted ja vähesed ettevõtted kasutavad neid. Veebiteenuste süsteemi silumine ja täiustamine nõuab veel palju aega.
  • Veebiteenuste kasutamise litsentsimise ja tasustamise süsteemi peavad arendajad veel aktsepteerima. Kuna veebiteenuseid on endiselt liiga vähe, püüab enamik ettevõtteid jätta potentsiaalsetele klientidele hea mulje, vähendades teadlikult teenuste maksumust ja pakkudes soodsaid litsentsimistingimusi. Läheb veel aega, enne kui veebiteenuste tegelik hind selgub.

Kui veebiteenused võtavad oma koha ja muutuvad kõigile kättesaadavaks, saavad neist veebiarendajatele hindamatu abi. Need annavad meile paindliku juurdepääsu kõigi võrgus olevate arvutite täisvõimsusele. Veebisaitide koostajatel on aeg hakata veebiteenuste vastu huvi tundma ja rohkem teada saada, mida neilt saada on.

Tõlge: Aleksander Kachanov (http://webmascon.com)

Oleme üle vaadanud üldmõisteid mehhanismi kasutamine « võrk-teenused". Värskendame teadmisi.

Veebiteenuseid kasutatakse andmete vahetamiseks serveri ja kliendi vahel; XML-vormingut kasutatakse andmete "pakendamiseks" vastastikuse mõistmise eesmärgil mõlema suhtlusosalise vahel.

PEATÜKKI

RAKENDAMISE NÄIDEVÕRK- TEENUS 1C: ETTEVÕTTE SÜSTEEMI

ÜLESANNE: Vajalik on luua veebiteenus, kuhu pääsedes saavad kliendid oma rakenduste kohta kogu vajaliku teabe määrata.

Ülesanne on demonstratsioon ja see on vaid eeskujuks mehhanismi mõistmisel ja õpetamiselvõrk-teenused.

LAHENDUS:

Samm 1. Loome uue teabebaasi ilma konfiguratsioonita, et välja töötada uus konfiguratsioon.

2. samm. Lisame konfiguratsiooni mitu uut objekti

Kataloog "Kliendid";

dokument "Avaldus";

Loend "Taotluse staatused".

3. samm. Loome uue XDTO paketi.

Miks ja mis eesmärgil me XDTO paketti loome? Lisateavet XDTO mehhanismi kasutamise kohta leiate peatükkidest 16. Arendaja juhend ja .

Märgime lühidalt, et XDTO mehhanism on universaalne viis andmete esitamiseks erinevate väliste andmeallikate ja tarkvarasüsteemidega suhtlemiseks.

Meie puhul luuakse veebiteenuse tagastusväärtuse kirjeldamiseks XDTO pakett.

Laiendame haru „Üldine” → „XDTO paketid” → Lisa…

Määrame XDTO paketi nime " DokumendidAndmed"ja selle nimeruumi http://localhost/request või http://192.168.1.76/request (mõistmise ja õppimisprotsessi hõlbustamiseks näitame selle arvuti kohaliku IP-aadressi, kuhu veebiserver on installitud (toetatud veebiserverid: IIS või Apache)). Iga veebiteenust saab üheselt identifitseerida selle nime ja selle nimeruumi URI järgi, kuhu see kuulub.

Meie pakett sisaldab kahte tüüpi XDTO objekte:

1) Klient- andmete edastamiseks kataloogielemendist “Kliendid”.

- Nimi ;

2) Dokument- andmete ülekandmiseks dokumendist “Avaldus”.

See XDTO objektitüüp sisaldab järgmisi atribuute:

- Klient- tippige nimeruumi http://192.168.1.76/request tekst Сustomer; tähistab viidet XDTO objektile, mille me eespool määratlesime;

- Olek- stringi tüüp nimeruumist http://www.w3.org/2001/XMLSchema ;

- Arv- stringi tüüp nimeruumist http://www.w3.org/2001/XMLSchema.

4. samm. Lisame konfiguratsioonile uue veebiteenuse

Laiendame haru “Üldine” → “Veebiteenused” → Lisa…

Veebiteenuse jaoks määrame järgmised atribuutide väärtused:

nimi - DokumendidAndmed

Nimeruumi URI - http://192.168.1.76/request

XDTO paketid – DokumendidAndmedvõihttp://192.168.1.76/request

Väljaande faili nimi - taotlus.1cws

5. samm. Loodud veebiteenuse jaoks määratleme toimingu " GetData»

Operatsiooni omaduste väärtused:

Tagastamise tüüp - Dokument (http://192.168.1.76/request)

Võimalik tühi väärtus - Tõsi

Protseduuri nimi - GetData.

6. samm. Operatsioonil GetData defineerime parameetri Сustomer with järgmiste väärtustega omadused:

Väärtuse tüüp – tüüp string nimeruumist http://www.w3.org/2001/XMLSchema;

Ülekande suund - sisend.

7. samm Avame loodud veebiteenuse mooduli ja asetame sellesse funktsiooni Get(), mis käivitatakse selle veebiteenuse väljakutsumisel.

Funktsioon GetData(Customer) // Hankige XDTO objektide tüübid ClientType = FactoryXDTO.Type("http://192.168.1.76/request", "Customer"); RequestType = FactoryXDTO.Type("http://192.168.1.76/request", "Dokument"); // Hankige klient ClientLink = Directories.Clients.FindByName(Customer); Kui ei ole ValueFilled(ClientRef), siis tagastab Undefined; endIf; Taotlus = uus taotlus; Päring.Tekst = "VALI TOP 1 | Rakendus.Link, | ESINDUS(Rakendus.Olek) ASi olek, | Taotlus.Number |KÄTTE | Dokument.Taotlus AS Taotlus |KUS | Rakendus.Klient = &Klient"; Request.SetParameter("Client", ClientLink); RequestResult = Request.Execute(); Kui QueryResult.Empty() siis Return Undefined; endIf; Selection = Päringu tulemus.Select(); Valik.Järgmine(); Dokument = Selection.Link.GetObject(); // Tellimuse XDTO objekti loomine Order = FactoryXDTO.Create(OrderType); Application.Numder = Näidis.Number; Klient = FactoryXDTO.Create(ClientType); Client.Name = KliendiLink.Nimi; Application.Customer = Klient; Application.Status = Selection.Status; // Taotluse tagastamine Tagastamistaotlus; EndFunction

8. samm Avaldame loodud veebiteenuse veebiserveris.

Menüüelement Configurator: “Administreerimine” → “Avaldamine veebiserveris”.

Vahekaardil „Veebiteenused” märkige ruut „Avalda veebiteenused” ja märkige ka ruut meie uue veebiteenuse kõrval.

PEATÜKKII

APELATSIOONI NÄIDEVÕRK- 1C:ENTERPRISE SÜSTEEMI TEENUSELE KOLMANDA OSAPOOLE RAKENDUSEST

Veebiteenuste mehhanismi põhieesmärk süsteemis 1C:Enterprise on vajalike andmete edastamine kolmandate osapoolte rakendustele.

Vaatame selle artikli esimesest jaotisest näidet rakenduse arendamisest Delphis, mis helistab meie veebiteenusele.

Samm 1. Loome uus projekt ja asetage vormile mitu juhtnuppu

Tekstiväli - kasutatakse veebiteenusest saadud teabe kuvamiseks;

Kaks nuppu – tekstivälja tühjendamine ja ligipääs veebiteenusele;

Sisestusväli on parameeter, mis edastatakse veebiteenusele.

2. samm. WSDL-faili importimine

Selle tulemusena saame uue mooduli nõuda(määratlesime selle nime otse 1C-s). See moodul sisaldab kogu vajalikku teavet veebiteenuse kohta.

3. samm. Kirjutame veebiteenuse kõnede töötleja

Muutuja DocumentDataPortType on moodulis juba defineeritud nõuda

4. samm. Käivitage rakendus ja käivitage test.

PEATÜKKIII

APELATSIOONI NÄIDEVÕRK-TEENUS SÜSTEEMIS 1C: ETTEVÕTE

Samm 1. Loome uue välise töötluse nimega "WEB_Service"

2. samm. Määratleme töötlemiseks uue vormi

3. samm. Vormis märgime mitu üksikasju

Klient – ​​tippige "String"

ClientReturn – tippige "String"

NumberReturn – tippige "String"

StatusReturn - tippige "String".

Kuvame üksikasjad vormil.

4. samm. Lisame vormi käsu " Andmete saamiseks»

Määrame käsutöötleja

&OnClient protseduur GetData(Command) GetDataOnServer(Client); Protseduuri lõpp Protseduuri GetDataOnServer(Client) // Looge lingi põhjal WS-i puhverserver ja sooritage toiming Get() Definition = New WSDefinitions("http://192.168.1.76/WEB_Service/ws/request.1cws?wsdl") ; Puhverserver = uus WSProxy (definitsioon, "http://192.168.1.76/request", "DocumentsData", "DocumentsDataSoap"); Rakenduse andmed = Proxy.GetData(Client); Kui rakenduse andmed = määramata, siis ClientReturn = "määratlemata"; StatusReturn = "Määratlemata"; ReturnNumber = "Määratlemata"; Tagasi;

endIf; CustomerReturn = Application Data.Customer.Name; StatusReturn = Rakenduse andmed.Olek; Tagastusnumber = Application Data.Numder; Menetluse lõpp

Süsteem 1C:Enterprise saab kasutada teiste pakkujate pakutavaid veebiteenuseid kahel viisil: Kasutades staatiline

konfiguratsioonipuus loodud lingid; suur kiirus;

"miinus": WSDL-i kirjelduse uuesti importimine konfiguraatori abil ja muudetud konfiguratsiooni salvestamine.

Süsteem 1C:Enterprise saab kasutada teiste pakkujate pakutavaid veebiteenuseid kahel viisil: dünaamiline sisseehitatud keeletööriistade abil loodud lingid

(vastavalt on staatiliste "miinused" dünaamiliste jaoks "plussid")

PEATÜKKIV

VEEBITEENUSTE SILUMINE SÜSTEEMIS 1C:ENTERPRISE

Kohaliku veebiteenuse jaoks vajate:

Samm 1. Asetage fail kliendile, kus töötab 1C süsteem webservicecfg.xml järgmise sisuga

2. samm. Viilima vaikimisi. vrd avalda konfiguratsiooni lisarida

3. samm. Valige konfiguraatoris menüüelement

"Silumine" → "Ühendus" → "Automaatne ühendus" → "Veebiteenused serveris"

4. samm. Klõpsake nuppu "OK".

Serverivaliku jaoks peate ka 1c-serveri võtmega silumisrežiimis käivitama /debug

Veebiteenus, veebiteenus – veebiaadressi järgi tuvastatav tarkvarasüsteem standardiseeritud liidestega.

Veebiteenused saavad suhelda omavahel ja kolmandate osapoolte rakendustega kindlatel protokollidel põhinevate sõnumite kaudu =

  • XML-RPC
  • jne.

Veebiteenus on teenusele orienteeritud rakendusarhitektuuri kasutamisel modulaarsuse ühik.

Üldkeeles on veebiteenused Internetis pakutavad teenused.
Selles kasutuses vajab termin selgitust, kas me räägime otsingust, veebimeilist, dokumentide, failide, järjehoidjate jms salvestamisest.
Selliseid veebiteenuseid saab kasutada olenemata sellest, kus te Internetti, arvutit või brauserit kasutate.

Arhitektuur

Nagu joonisel näidatud, on veebiteenuses kolm juhtumit. Tõlgime nende nimed kui klient, töövõtja ja kataloog (teenuse taotleja, teenusepakkuja ja teenuse vahendaja).

Kui teenus on välja töötatud, registreerib töövõtja selle kataloogi, kust potentsiaalsed kliendid selle leiavad. Klient, leidnud kataloogist sobiva teenuse, impordib sealt oma WSDL spetsifikatsiooni ja arendab selle järgi oma teenuse. tarkvara. WSDL kirjeldab tööprotsessi käigus tellija ja töövõtja vahel vahetatavate päringute ja vastuste vormingut. Koostalitlusvõime tagamiseks kasutatakse järgmisi standardeid:

  • Laiendatav märgistuskeel, mis on loodud struktureeritud andmete salvestamiseks ja edastamiseks;
  • XML-põhine sõnumsideprotokoll;
  • : XML-il põhineva veebiteenuse välisliideste kirjeldamise keel;
  • Universaalne avastamis-, kirjeldus- ja integreerimisliides.

Veebiteenuste kataloog ja teave ettevõtete kohta, mis pakuvad veebiteenuseid avalikkusele või konkreetsetele ettevõtetele. Seni eksisteerib UDDI aga ainult väikestes patenteeritud võrkudes ja pole avatud Internetis veel laialdast kasutust leidnud.

Arendusmeetodid

Tööriistad veebiteenuste arenduse automatiseerimiseks on jagatud kahte põhirühma.

Alt-üles arenduses kirjutatakse esmalt rakendusklassid ja teenust dokumenteerivad WSDL-failid genereeritakse nende lähtekoodist. Selle meetodi puuduseks on Java klassid võivad sageli muutuda.Ülalt-alla lähenemise korral valmistatakse esmalt ette WSDL ja sellest genereeritakse teenust realiseeriva Java klassi skelett. Seda teed peetakse keerulisemaks, kuid see viib puhtamate ja paremini kaitstud lahendusteni. Kuni kliendi ja töövõtja vahel vahetatavate sõnumite formaat ei muutu, ei häiri muudatused nendes kummaski suhtlust. Seda tehnikat nimetatakse mõnikord "leping kõigepealt", kuna lähtepunktiks on WSDL ("leping" kliendi ja töövõtja vahel).

Eelised

  1. Veebiteenused pakuvad tarkvarasüsteemide interaktsioon olenemata platvormist. Näiteks saab Windows C# klient suhelda Linuxi all töötava Java serveriga.
  2. Veebiteenused põhinevad avatud standarditel ja protokollidel. Tänu XML-i kasutamisele Saavutatakse veebiteenuste arendamise ja silumise lihtsus.
  3. Interneti-protokolli kasutamine annab Tarkvarasüsteemide HTTP interaktsioon tulemüüri kaudu. See on märkimisväärne eelis selliste tehnoloogiate ees nagu CORBA, DCOM või Java RMI. Teisest küljest veebiteenused ei ole tihedalt seotud HTTP-ga – saab kasutada ka muid protokolle.

Puudused

  1. Vähem tootlikkust ja suurem suurus võrguliiklust võrreldes RMI, CORBA, DCOM tehnoloogiatega tänu XML tekstisõnumite kasutamisele. Mõningaid veebiservereid saab aga konfigureerida võrguliiklust tihendama.
  2. Turvalisuse aspektid. Vastutustundlikud veebiteenused peaksid kasutama krüptimist ja võib-olla nõuavad kasutaja autentimist. Kas siin piisab HTTPS-i kasutamisest või eelistatakse selliseid lahendusi nagu XML Signature, XML Encryption või SAML, selle peab otsustama arendaja.

Näited

Lennufirmade ja reisibüroode koostöö. Esimesi pakutakse veebiteenuste kaudu kasulik informatsioon, mida viimased kasutavad oma klientidele optimaalsete pakkumiste otsimisel.

Google pakkus aastatel 2002–2009 veebiteenust, mis võimaldas klientidel Internetist teavet otsida samal viisil. tavakasutajad. Mugavuse poolest on see võrreldamatu näiteks Google'i lehtede HTML-teksti automaatse sõelumisega.

Amazon.com-il on veebiteenus, mis pakub erinevaid veebipõhiseid teenuseid (midagi "teenusena" - pilvetehnoloogiad)