Mis on veebiteenused ja miks need on olulised? Mis on lihtsas inglise keeles "veebiteenus".

Aleksander Kachanov

Veebiteenuste idee töötasid välja sellised arvutitööstuse hiiglased nagu Sun, Oracle, HP, Microsoft ja IBM. See idee pole midagi uut, kuid see on suur samm edasi programmidele veebi kaudu juurdepääsetavamaks muutmisel. Standardsete suhtlusvormingute põhjal võivad veebiteenused üldiselt muuta meie arusaama sellest, 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 teised 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 rakenduses.

Oletame, et kui mul on vaja mõnda programmeerimisülesannet täita ja ma olen liiga hõivatud (või ei suuda ise jalgratast 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 tulemust.

Igaüks, kes on kunagi töötanud Hiljuti Koos kuum kiri, on juba mõne veebiteenusega kokku puutunud: kasutajate autentimissüsteem Passport on üks Microsofti .NET-i algatusse kaasatud teenustest. kuigi see on tasuta saadaval, et veebisaitide loojad saaksid hõlpsalt oma saidil kasutaja autentimist rakendada.

Põhitõed

Veebiteenuste põhimõtted on märkimisväärselt 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 veebiteenusele päringu
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, kohtumiste kalendrikirje salvestamine, 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 andmete vahetamise ja edastamise protokollidel.

Enne seda töötasid paljud ettevõtted välja oma patenteeritud standardid ja vormingud. Ja nüüd peame tööks teadma ainult 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.

Erinevus veebiteenuste ja muude tehnoloogiate vahel, millega arendajad on kokku puutunud (näiteks DCOM, named pipes – named pipes, RMI), seisneb selles, et veebiteenused põhinevad avatud standarditel, neid on lihtne õppida ja neid standardeid on laialdaselt toetatud kõik Unixi 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 (SOAP-ümbrikutesse). Sõnumid sisaldavad kas taotlust mõne toimingu sooritamiseks või vastust – selle toimingu tulemust. Ümbrik ja selle sisu on XML-kodeeringuga ja neid on üsna lihtne mõista. Lihtne SOAP-i päring, mis saadetakse HTTP kaudu veebiteenusele, näeb välja järgmine:

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

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

SOAP-ümbriku põhielemente on lihtne ära tunda: need on kaks parameetrit ( ("postiindeks") ja ("riik")), mis sisalduvad elemendis nimega . See element on 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 päringus muudeti elemendiks vastuseks palvele. See element sisaldab ainult ühte elementi , mille väärtus näitab, kas meie sihtnumber on õige või mitte. Nii et SOAPi võlu abil oleme loonud päringu, mis teeb meie jaoks kasulikku tööd. Vastuseks saame võrgu kaudu teatud tüüpi vastuse XML-is.

Nüüd UDDI kohta

Isegi SOAP-protokolli lihtsuse juures oleks veebiteenustest vähe kasu, kui meil poleks võimalust neid leida. Õnneks on IBM, Microsoft ja Ariba võtnud initsiatiivi ja loonud 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 töötab nagu kõigi veebiteenuste telefoniraamat. Registreerumine UDDI kataloogis on tasuta ja projekti asutajad loodavad, et see kataloog sisaldab kõigi veebiteenuste kirjeldusi, nii et soovitud veebiteenuse leidmiseks piisab vaid ühele viitamisest. 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: registreerimisvormile tuleb lisada sihtnumbri kinnitamine.

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

Selle asemel, et osta andmebaasi, kirjutada oma kood, veenduda, et kõik andmed on järjepidevad ja õiged, ning siluda skripte, lähen lihtsalt UDDI kataloogi ja otsin veebiteenust, mis võiks selle töö minu eest ära teha. Saabudes aadressile http://www.uddi.org/, käivitan otsingu ja leian suurepärase teenuse XYZ Corp.

Vaatan hoolikalt üle veebiteenuse formaadi määratlus (definitsioon on kirjutatud WSDL-s (Web Services Description Language), veendun, et teenus teeb täpselt seda, mida vajan. Seejärel uurin kolleegidelt XYZ Corp. maine kohta, saan teada, et see on kindel ja siis võtan hinna saamiseks ühendust ettevõttega XYZ Corp. Kui teenusele juurdepääsu hind jääb minu eelarve piiresse, kirjutan oma saidi jaoks lihtsa JSP-lehe, mis kutsub XYZ Corpi veebiteenust, ja hei, kohe ilmub kassasse sait. postiindeks.

Tasub aega võtta

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 saiti, arutades kõiki uue projekti funktsioone. Kõik sujub suurepäraselt: eelarve vastab kliendi ootustele, talle meeldis kohaplaani ülevaade, 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 ja ta ise hakkab köhasse lämbuma. See on arendaja, kes annab teile signaali, et selle funktsiooni väljatöötamine nõuab palju raha ja aega või pole lihtsalt sellise eelarvega teostatav.

Loobu hirmust! Võin kihla vedada, et veebis on juba olemas veebiteenus, mis on valmis teile vajalikku funktsiooni pakkuma ja selle veebiteenuse kasutamise hind on palju väiksem kui selle analoogi enda väljatöötamise hind. Nii säästate oma arendajat tarbetute peavalude eest ja klienti jäätmed raha, kulutades vaid paar minutit UDDI kataloogi sirvides.

Teenuse arendamine

Loomulikult ei pea arendajad leppima ainult teiste loodud veebiteenustega. Ühe järgneva tööriistakomplekti abil saate luua oma veebiteenuse ja pakkuda selle teenuseid teistele võrgu elanikele.

Tööriistade valik veebiteenuste arendamiseks on lai. See sisaldab tööriistakomplekte sellistelt ettevõtetelt nagu Sun (Open Net), Microsoft (.NET), (e-teenused) ja IBM (veebiteenused). Samuti on avatud lähtekoodiga raamistikud. Näiteks üritab Mono Project asendada Microsoft .NET-i tööriistakomplekti, pakkudes kompileerimissüsteemi (kompilaatorid), koodikäivitust (käitusaeg) ja teeke (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 ma oma programmeerijakarjääri täielikult hülgan ja veebiteenuste kasutamisele pühendun, pean endale esitama küsimuse: "See pilt on liiga roosa. Mis sellel viga on?". Kahjuks on veebiteenuste suure potentsiaali eest makstav hind:

Kui kasutate XML-i andmeedastusvorminguna, on teie sõnumid 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 teatud funktsioonide täitmiseks tugineme täielikult Internetile, mis loob meie veebiserveri ja veebiteenuse ahelasse liiga palju ebausaldusväärseid linke.
Praegu loovad veebiteenuseid vähesed ettevõtted ja vähesed ettevõtted kasutavad neid. Veebiteenuste süsteemi silumine ja täiustamine võtab ikka veel kaua aega.
Veebiteenuste kasutamise litsentsimise ja tasude võtmise süsteemi peavad arendajad veel vastu võtma. Kuna veebiteenuseid on endiselt liiga vähe, püüab enamik ettevõtteid jätta oma potentsiaalsetele klientidele head muljet, langetades teadlikult teenuste maksumust ja pakkudes soodsaid litsentsimistingimusi. Veebiteenuste tegeliku maksumuse selgumiseni läheb veel aega.

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 veebis olevate arvutite täisvõimsusele. Veebisaitide tegijatel 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-veebiteenus?

Infotehnoloogia arenguga on tekkinud 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 korduskasutusest ( taaskasutamisest ) makrotasandil (teenusetasemel), mitte mikrotasandil (objekti tasandil). Teenusele orienteeritud lähenemisviis hõlmab lihtsate ja üldtunnustatud standardite kasutamist, mis võimaldab paljudel erinevatel rakendustel kasutada üksteise funktsioone. Teenused saab kirjutada mitmesuguste programmeerimiskeelte abil erinevatel platvormidel. Lisaks saab teenuseid juurutada eraldi või tarkvarapaketi osana kõikjal maailmas ja seega pakuvad need juurdepääsu nende funktsioonidele võrgu kaudu.

Helistame teenust 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 neid saab kasutada sideprotokollide kaudu, mis võimaldavad ressurssidel üksteisega suhelda.

Teenuse erijuhtum on XML-veebiteenus.

XML-i 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 API, st veebiteenus pakub funktsioone (veebimeetodeid), 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 teatada ilmast. 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 tekstiredaktorist kuni Microsoft Visual Studio perekonnani).

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 seas

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

Kõiki neid komponentidele orienteeritud tehnoloogiaid (DCOM, CORBA ja RMI) on sisevõrgurakendustes edukalt kasutatud juba aastaid. Need pakuvad tugevat, skaleeritavat arhitektuuri. Nende tehnoloogiate kasutamisel Internetis on aga kaks suurt probleemi. Esiteks ei suhtle nad üksteisega hästi. Kõik tehnoloogiad toimivad objektidel, kuid erinevad oluliselt üksikasjade poolest: elutsükli haldamine, konstruktorite tugi ja päranditoetuse määr. Teine, olulisem aspekt on see, et keskendumine RPC interaktsioonidele viib tihedalt seotud süsteemide ehitamiseni, mis põhinevad selgesõnalistel objektimeetodi kutsetel.

Erinevalt nendest tehnoloogiatest kasutavad XML-i veebiteenused 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 on osa nimest, kuna veebiteenused ja nende kliendid kasutavad seda andmete vahetamiseks. Veebiteenused põhinevad avatud standarditel, nagu HTTP, XML (laiendatav märgistuskeel), SOAP (Simple Object Access Protocol – Interneti-standard, mis kirjeldab, kuidas rakendused saavad suhelda, st kutsuda üksteise meetodeid HTTP ja muude protokollide abil). Veebiteenuste peamine ülesanne on pakkuda programmidevahelist suhtlust. Paljud töötavad UNIX-i serverites ja neile pääsevad juurde Windowsi kliendid. Veebiteenustele edastatavad andmed jadatakse XML-vormingusse 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 analüüsib SOAP-pakette.

.NET Remoting pakub infrastruktuuri hajutatud objektidele. See on palju keerulisem kui lihtne veebiteenuste arhitektuur, mis põhineb sõnumite edastamisel. . NET Remoting hõlmab 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 sisse. NET Remoting saadetakse kahend- või SOAP-vormingus. Kuid igal juhul sisalduvad metaandmed edastatava teabe struktuuri kohta üldkeeles. Ilma ühise keele käitusajaga (CLR) ei saa klientrakendus sõeluda . NET Remoting SOAP päised. See on. NET Remotingul on oluliselt kõrgemad nõuded kui veebiteenustel.

Veebiteenuste arendamine .NET platvormil

Veebiteenuste kirjutamiseks on palju võimalusi. Neid saab välja töötada käsitsi või Microsofti, IBMi jt SOAP-tööriistade abil.Veebiteenuste kirjutamine koos Microsoftiga. 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 sellistes rakendustes pole probleeme mälulekke, valesti lähtestatud osutite ja muude tüüpiliste programmeerimisprobleemidega.

Loomine

Arendame välja lihtsa AdditionService'i veebiteenuse, mis teostab kahe numbri liitmise. Sellel on ainult üks lisamismeetod, mis võtab parameetrina kaks täisarvu ja tagastab samuti täisarvu. AdditionService demonstreerib mitmeid olulisi põhimõtteid veebiteenuste programmeerimiseks Microsoft .NET Frameworki abil.

Veebiteenused on rakendatud ASMX-failidena. ASMX on spetsiaalne failinimelaiend, mis on registreeritud ASP .NET-iga (täpsemalt ASP.NET HTTP-käitlejaga) 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 see näide selline 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, jäetakse see atribuut lihtsalt välja.
HTTP, XML ja SOAP on "nähtamatud". XML-andmeid ja SOAP-sõnumeid haldab .NET Framework.

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äikesele suurusele on AdditionService.asmx ASP.NET-i veebiserverisse installitud täielik veebiteenus. Selle meetodid käivitatakse SOAP-i, HTTP GET-i ja HTTP POST-iga ning see võib tulemusi tagastada SOAP-vastustena või lihtsate XML-mähistena.

Taustkoodi kasutades saab veebiteenuste klassid asmx-failidest välja võtta eraldi failidesse.

Veebiteenused toetavad kasutamist keerulised andmetüübid sisend- või väljundparameetritena. Toetatakse keerulisi andmetüüpe, kuna XML-i abil on enamiku andmetüüpide järjestamine lihtne. Veebiteenuse automaatsel testimisel ei loo ASP .NET aga aktsepteeritavate meetodite jaoks testlehti keerulised tüübid andmeid. Selle põhjuseks on asjaolu, et te ei saa HTTP GET-i ja POST-i abil veebimeetodile edastada keerulisi andmetüüpe.

Veebiteenused võimaldavad teil helistada oma meetoditele asünkroonselt. Asünkroonne kõne naaseb kohe, olenemata sellest, kui kaua kulub veebiteenusel kõne töötlemiseks. Asünkroonsed kõned on kasulikud, kui kõne töötlemine võtab kaua aega. Rakendus teeb kõne, jätkab seejärel töötamist kõne tulemust ootamata ja saab hiljem asünkroonse kõne tulemused. Tulemus saadakse siis, kui veebimeetodile rakendusele sobival ajal uuesti helistada või tellides veebiteenuse kõnetöötluse lõppemise teatise (delegatimehhanism).

Veebiteenuseid saab luua kasutades selliseid tööriistu nagu Microsoft Visual Studio 2005. Veebiteenuste loomiseks on olemas 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 kirjeldamine lepingute abil

Selleks, et teised arendajad saaksid AdditionService'i kasutada, peavad nad teadma, milliseid meetodeid see paljastab, 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 saavad teised arendajad AdditionService'i olemasolust teada?

Esiteks DISCO (lühend sõnast discovery) abil - failimehhanism kohalike veebiteenuste otsimiseks, st mehhanism saadaolevate veebiteenuste loendi hankimiseks veebiserverites hostitud 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 pesastatud 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 loodud DISCO dokumendi. Turvakaalutlustel on dünaamiline otsing mõnes .NET Frameworki versioonis keelatud, kuid saate selle lubada, muutes faili Machine.config kirjeid.

Kuidas aga läheb veebiteenuste otsimisega globaalses võrgus? 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 leida veebiteenuseid. UDDI-d toetavad sajad ettevõtted. UDDI saidid on ise veebiteenused. Igaüks saab avaldada oma registri UDDI põhjal. 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 ümbrisklassid.

Tulemused

XML-veebiteenus on tarkvarakomponent, mis pakub kõige enam funktsioone erinevad süsteemid, toetavad standardeid nagu XML ja HTTP veebiteenuste kliendid võivad olla kas kohalikud või kaugrakendused. Veebiteenused võimaldavad luua struktuure, mis lihtsustavad erinevate süsteemide integreerimist lihtsate üldtunnustatud standardite alusel.

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

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

PEATÜKKI

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

ÜLESANNE: Vajalik on luua veebiteenus, millele viidates saavad kliendid määrata kogu oma rakenduste jaoks vajaliku info.

Ülesanne on näidisülesanne ja see on vaid näide mehhanismi mõistmiseks ja õppimiseksvõrk-teenused.

LAHENDUS:

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

2. samm Lisame konfiguratsiooni mõned uued objektid

Kataloog "Kliendid";

dokument "Avaldus";

Loend "Avalduste staatused".

3. samm Loome uue XDTO paketi.

Miks ja miks me XDTO paketti loome? Lisateavet XDTO mehhanismi kasutamise kohta saate lugeda peatükist 16. Arendaja juhend ja.

Märgime lühidalt vaid seda, 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.

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

Määrake XDTO paketi nimi " 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- kataloogielemendi "Kliendid" andmete edastamiseks.

- Nimi ;

2) dokument- edastada dokumendi "Taotlus" andmed

Seda tüüpi XDTO objektil on järgmised omadused:

- Klient- Kliendi tüüp nimeruumist http://192.168.1.76/request; on viide XDTO objektile, mille me eespool määratlesime;

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

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

4. samm Lisage konfiguratsioonile uus veebiteenus

Laiendage haru "Üldine" → "Veebiteenused" → Lisa ...

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

nimi - DokumendidAndmed

URI nimeruumid – 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 " hankige andmed»

Operatsiooni omaduste väärtused:

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

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

Protseduuri nimi - hankige andmed.

6. samm Operatsioon hankige andmed määrake kliendi parameeter järgmised väärtused omadused:

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

Ülekande suund - sisend.

7. samm Avame loodud veebiteenuse mooduli ja paneme 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 ClientReference = Directories.Clients.FindByName(Customer); Kui ei ole ValueFilled(ClientReference), siis tagasta Undefined; EndIf; Taotlus = uus taotlus; Request.Text = "VALI ESIMESE 1 | Pilet.Viide, | ESINDUS(Pileti.Olek) AS-i olek, | Pilet.Number |KÄTTE | Dokument.Ticket AS Pilet |KUS | Pilet.Klient = &Klient"; Request.SetParameter("Client", ClientReference); QueryResult = Query.Execute(); Kui QueryResult.Empty() siis Return Undefined; EndIf; Valik = QueryResult.Select(); Valik.Järgmine(); Dokument = Selection.Reference.GetObject(); // XDTO piletiobjekti loomine Ticket = FactoryXDTO.Create(TicketType); Application.Numder = Näidis.Number; Klient = FactoryXDTO.Create(ClientType); Client.Name = ClientReference.Name; Application.Customer = Klient; Application.Status = Selection.Status; // Tagastamisnõue Tagastamistaotlus; Lõppfunktsioonid

8. samm Avaldame loodud veebiteenuse veebiserveris.

Konfiguraatori menüüelement: "Haldamine" → "Avaldamine veebiserveris".

Määrake vahekaardil "Veebiteenused" lipp "Avalda veebiteenused" ja märkige ka ruut meie uue veebiteenuse kõrval.

PEATÜKKII

VIIDE NÄIDEVÕRK- 1C: ETTEVÕTETE TEENUS KOLMANDA OSAPOOLE RAKENDUSEST

1C: Enterprise'i veebiteenuste mehhanismi põhieesmärk on vajalike andmete edastamine kolmandate osapoolte rakendustele.

Vaatleme näidet selle artikli esimesest jaotisest, kuidas arendada rakendust 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 sellise nime otse 1C-s). See moodul sisaldab kogu vajalikku teavet veebiteenuse kohta.

3. samm Kirjutage veebiteenuse kõne töötleja

Muutuja DocumentDataPortType on moodulis juba defineeritud nõuda

4. samm Käivitage rakendus ja kontrollige.

PEATÜKKIII

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

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

2. samm Töötlemiseks määratleme uue vormi

3. samm Määrake vormi jaoks mitu üksikasju

Klient – tippige "String"

ClientReturn – tippige "String"

NumberReturn – tippige "String"

StatusReturn – tüüp "String".

Kuvame üksikasjad vormil.

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

Määrake käsutöötleja

&OnClient protseduur GetData(Command) GetDataOnServer(Client); Protseduuri lõpp Protseduuri GetDataOnServer(Client) // Looge lingi põhjal WS-i puhverserver ja käivitage 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"); RequestData = Proxy.GetData(Client); Kui OrderData = Undefined, siis ClientReturn = "Määratlemata"; StatusReturn = "Määratlemata"; ReturnNumber = "Määratlemata"; Tagastamine; EndIf; CustomerReturn = RequestData.Customer.Name; StatusReturn = RequestData.Status; ReturnNumber = RequestData.Numder; Lõppprotseduur

1C: Ettevõte saab kasutada teiste pakkujate pakutavaid veebiteenuseid kahel viisil:

Kasutades staatiline konfiguratsioonipuus loodud lingid;

"pluss": suur töökiirus;

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

Kasutades dünaamiline sisseehitatud keele abil loodud lingid

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

PEATÜKKIV

VEEBITEENUSTE SILUMINE SÜSTEEMIS 1C:ENTERPRISE

Kohaliku veebiteenuse jaoks vajate:

Samm 1. Pange kliendile, kus 1C süsteem käivitatakse, fail 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".

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

Mis on veebiteenus?

Igaüks, kes on kunagi koos töötanud kuum kiri, on juba mõne veebiteenusega kokku puutunud: kasutajate autentimissüsteem Passport on üks Microsofti .NET-i algatusse kaasatud teenustest. kuigi see on tasuta saadaval, et veebisaitide loojad saaksid hõlpsalt oma saidil kasutaja autentimist rakendada.

Põhitõed

Veebiteenuste põhimõtted on märkimisväärselt 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 veebiteenusele päringu
veebiteenus töötleb päringu, teeb mõne toimingu ja saadab seejärel vastuse

Standardid keskmes

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

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

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

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

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

Nüüd UDDI kohta

UDDI-süsteem võimaldab ettevõtetel oma veebiteenust avalikkusele tutvustada. See kataloog toimib kõigi veebiteenuste telefoniraamatuna. Registreerumine UDDI kataloogis on tasuta ja projekti asutajad loodavad, et see kataloog sisaldab kõigi veebiteenuste kirjeldusi, nii et soovitud veebiteenuse leidmiseks piisab vaid ühele viitamisest. 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 kinnitamise.

Selle asemel, et osta andmebaasi, kirjutada oma kood, veenduda, et kõik andmed on järjepidevad ja õiged, ning siluda skripte, lähen lihtsalt UDDI kataloogi ja otsin veebiteenust, mis võiks selle töö minu eest ära teha. Kui ma lähen saidile www.uddi.org, käivitan otsingu ja leian suurepärase teenuse XYZ Corp.

Tasub aega võtta

Loobu hirmust! Võin kihla vedada, et veebis on juba olemas veebiteenus, mis on valmis teile vajalikku funktsiooni pakkuma ja selle veebiteenuse kasutamise hind on palju väiksem kui selle analoogi enda väljatöötamise hind. Nii säästate oma arendajat tarbetutest peavaludest, klienti raha raiskamisest, kulutades vaid paar minutit UDDI kataloogi sirvides.

Teenuse arendamine

Loomulikult ei pea arendajad leppima ainult teiste loodud veebiteenustega. Ühe järgneva tööriistakomplekti abil saate luua oma veebiteenuse ja pakkuda selle teenuseid teistele võrgu elanikele.

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

Miinused

Kui kasutate XML-i andmeedastusvorminguna, on teie sõnumid 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.
Praegu loovad veebiteenuseid vähesed ettevõtted ja vähesed ettevõtted kasutavad neid. Veebiteenuste süsteemi silumine ja täiustamine võtab ikka veel kaua aega.
Veebiteenuste kasutamise litsentsimise ja tasude võtmise süsteemi peavad arendajad veel vastu võtma. Kuna veebiteenuseid on endiselt liiga vähe, püüab enamik ettevõtteid jätta oma potentsiaalsetele klientidele head muljet, langetades teadlikult teenuste maksumust ja pakkudes soodsaid litsentsimistingimusi. Veebiteenuste tegeliku maksumuse selgumiseni läheb veel aega.

Veebiteenuste praktiline kasutamine rakenduses IBM Lotus Domino 7

Mis on veebiteenused ja miks need on olulised?

Sisu seeria:

See sisu on # osa # artiklisarjast: Veebiteenuste praktiline kasutamine rakenduses IBM Lotus Domino 7

https://www..jsp?series_title_by=Practical+using+web services+in+ibm+lotus+domino+7

Olge kursis selle sarja uute artiklitega.

Võib-olla olete tehnilistes artiklites kohanud viiteid veebiteenustele, tarkvaratooted või isegi dialoogides kolleegidega. Ilmselt vajab keegi veebiteenuseid ja on oluline, kuid olles kohtunud selliste määratlustega nagu "XML-grammatika sõnumside lõpp-punktide komplektide määratlemiseks", otsustasite, et selliseid keerulisi asju ei tohiks puudutada.

Õnneks saab veebiteenuseid seletada nii, et kõik arusaadavad ilma selle toimimise üksikasjadesse laskumata. Peaksite püüdma aru saada, mis on veebiteenused, kuna nende (ja sellega seotud teenusele orienteeritud arhitektuuri, SOA) rakenduste ulatus IT-maailmas laieneb pidevalt.

Veebiteenuseid võib käsitleda kui autot: te ei pea teadma tehnilisel tasemel, kuidas kolvid, nukkvõllid ja kütusepihustid töötavad – võite osta auto, sellega sõita ja sõpradega autodest rääkida (v.a. loomulikult on nad mehaanikud). Sama lugu on veebiteenustega, IT-professionaalina peate lihtsalt aru saama, mis need on ja kuidas need töötavad, et mõista, miks te neid vajate.

Nüüd on veebiteenustega palju lihtsam töötada ilma peidetud madala taseme tehnoloogiaid puudutamata, sest tarkvaramüüjad ja avatud lähtekoodiga kogukond on viimastel aastatel palju ära teinud, et eraldada veebiteenuste liides madala tasemega ülesannetest. See võimaldab teil töötada lihtsalt komponendid omavahel ühendades, ilma et peaksite süvenema pikkadesse XML-sõnumite vormindamise dokumentatsiooni.

See artiklisari aitab Domino arendajatel mõista ja kasutada veebiteenuseid IBM Lotus Domino V7.0-s. See sissejuhatav artikkel sisaldab piisavalt kasulik informatsioon, ja on kasulik kõigile, kes soovivad mõista, mis on veebiteenused. Lotus Domino V7.0 tehnoloogiad muudavad arendajatel veebiteenuste loomise ja tarbimise lihtsaks ning me käsitleme seda üksikasjalikult hiljem.

Esiteks mõistame, mis on veebiteenus.

Mis on veebiteenus?

Lihtsamalt öeldes võimaldab veebiteenus arvutiprogrammidel omavahel standardsel viisil suhelda.

Side kolme või enama masina vahel

Kuigi näited põhinevad tehingutel ühes või kahes masinas, saab veebiteenuseid kasutada ka mitme masina vahel suhtlemiseks. Näiteks võib vaheseade edastada või salvestada tehinguid või kõne ühes serveris asuvale veebiteenusele võib käivitada kõne teise serveri teenusele.

Selle artikli lõpus, kui vaatame tõelist SOA-d, räägime veebiteenustest, mis suhtlevad mitme masina vahel, sest nii SOA alati töötab.

Veebiteenus on abstraktne komponent, nagu inimvestluse mõiste on abstraktne. Dialoogis osaleb kaks või enam inimest, kes räägivad keelt, mida nad oskavad. Nende keel määrab sõnad, mida nad kasutavad ja kuidas need sõnad lauseid moodustavad. Tavaliselt on dialoogil küsimus-vastus struktuur, kui keegi esitab küsimuse või avalduse ja vestluskaaslane vastab sellele. Inimesed võivad olla läheduses, rääkida telefoniga, saata üksteisele sõnumeid meili või vestluse teel.

Dialoogis on igal juhul keeruline struktuur ja võib toimuda erineval viisil, olenevalt suhtlevate inimeste arvust, suhtlustehnoloogiate jaoks kasutatavast suhtluskeelest, muidugi, kui seda kasutatakse.

Veebiteenuseid kasutava suhtluse struktuur sisaldab paljusid elemente, mida selles artiklis käsitleme. Mõte jääb aga samaks, mis tavalisel dialoogil – programmid suhtlevad kasutades keelt, mida nad oskavad, mõnikord ka võrgu kaudu. Programmid võivad asuda kas samas arvutis või majutatud erinevates masinates erinevates maailma paikades, ühendatud Interneti kaudu ruuterite ja serveritega. Hea uudis on see, et programmid ja arvutid ei pea olema samad. Veebiteenustega saavad suhelda kaks Microsofti .NET programmi ühes sülearvutis ning Java programm Kanada iSeries serveris C++ programmiga Hiinast pärit Linuxi arvutis.

Veebiteenuste suhtlus kasutab järgmisi standardtehnoloogiaid:

xml. Veebiteenuste komponentide kasutatav keel (andmevorming).
SOAP protokoll. Programmide vahel vahetatavad XML-sõnumid
Web Services Description Library (WSDL). XML-fail, mis määrab SOAP-sõnumite vormingu ja nende saatmise

Veebiteenuste vaheliseks suhtlemiseks saab kasutada ka standardset tehnoloogiat, mida tuntakse universaalse kirjelduse, avastamise ja integratsiooni (UDDI) nime all. Me käsitleme seda artiklis hiljem, kuid kuna UDDI on valikuline, ei kasuta paljud veebiteenused seda.

Mõni terminoloogia: veebiteenuste avaldamine ja kasutamine

Enne kui hakkame oma tingimusi selgitama, vaatame mõnda veebiteenustega seotud terminoloogiat.

Kui me räägime veebiteenuse avaldamisest, siis peame silmas programmi, mis avaldab WSDL-faili ja võimaldab teistel programmidel vastavat teenust kasutada. Programme, mis avaldavad veebiteenuseid, nimetatakse pakkujateks.

Kui me räägime veebiteenuse kasutamisest, peame silmas programmi, mis helistab mõnes teises masinas olevale veebiteenusele. Veebiteenuste kasutajaid nimetatakse klientideks.

XML: emakeel

XML-i kasutatakse veebiteenuse komponentide vaheliseks suhtlemiseks. Rakenduste vahel saadetavad sõnumid ja failid, mis määratlevad veebiteenuse, on XML-vormingus. Joonis 1 näitab lihtsa XML-faili struktuuri.

Joonis 1. XML-i põhistruktuur

Nagu näete, on osa failis leiduvast teabest (nt eesnimi, perekonnanimi) ümbritsetud kolmnurksulgudes olevate siltidega. Nimi John on näidatud kui John. Samuti on elemente, millesse pesastatakse näiteks elemendis teisi elemente Pesastatud elemendid , Ja .

Veebiteenuste XML-vormingus kirjutamisel on palju eeliseid, sealhulgas:

XML-i struktuur ja grammatika sarnanevad teiste programmeerimiskeelte omaga, seega ei pea veebiteenustega suhtlevad programmid XML-faile otse sõeluma.
XML-failid on tekstifailid ja neid saab lugeda inimene (teisisõnu, kui teate XML-keelt, saate avada XML-faili tekstiredaktor ja mõista selle sisu). See võib aidata silumist.
XML võimaldab kasutada sõnumites mis tahes standardset kodeeringut, nii et saate kirjutada sõnumeid inglise, vene või jaapani keeles.
XML võimaldab kasutada nn nimeruumi, milles saab eelnevalt määratleda konkreetse nimega failielemendi soovitud struktuuri. Näiteks saate määratleda hinnaelemendi, mis peab alati olema ujuv, või elemendi Isikunimi, mis sisaldab kahte stringi alamelementi Eesnimi ja Perekonnanimi.
Lisaks võimaldavad nimeruumid vajadusel mitmel sama nimega elemendil olla erinevad definitsioonid. Näiteks võib StockPrice'i element ühes nimeruumis sisaldada tickeri sümbolit ja hinda, samas kui teises nimeruumis võib see koosneda tickeri sümbolist, hinnast, päeva madalaimast ja kõrgeimast hinnast ning 12 kuu maksimumist.

XML-i ainsad puudused, kui need on tõepoolest puudused, on järgmised:

XML-keel on jäik, nii et XML-sõnumi vale vormindamine põhjustab kogu sõnumi sõelumise nurjumise (isegi kui probleemi on lihtne tõlgendada või sellest mööda vaadata). Kui aga kasutate XML-failide genereerimiseks standardset teeki (see on see, mida teete veebiteenuste loomisel), kontrollib teek ise õiget vormindamist.
XML-sõnum salvestatakse lihttekstifailis ja seetõttu võtab see rohkem ruumi kui selle ekvivalent mõnes muus vormingus (nt poolitatud, kahend- või "isetehtud" vormingus).

Kuid need probleemid on XML-vormingu eelistega võrreldes ebaolulised.

SEEP: saadetud sõnumid

Teate, et veebiteenused suhtlevad XML-vormingus, kuid see lahendab vaid poole probleemist. Rakendused saavad sõnumit sõeluda, kuid kuidas nad teavad, mida sõelutud tulemusega teha?

Juhend, mis kirjeldab veebiteenuste XML-sõnumite vormindamise reegleid, on tuntud kui SOAP. See määrab sõnumi struktuuri, et programmid teaksid, kuidas andmeid saata ja tõlgendada. SOAP-sõnumi põhistruktuur on näidatud joonisel 2.

Joonis 2. SOAP sõnumite põhistruktuur

XML-is näeks see välja umbes selline:

FOO

Põhijuhul on teil SOAP-pakett, mis sisaldab SOAP-i keha ja keha, mis sisaldab edastatavaid andmeid. Mõnikord on valikuline SOAP-päis (paketi sees enne kehaosa), mis sisaldab lisateavet.

SEEBI juhised

Kuigi SOAP-vorming on standardne ja sellel on samad juhised, tuleb meeles pidada, et erinevad tootjad võivad neid juhiseid veidi erinevalt rakendada. Näiteks võib Apache Axise genereeritud SOAP-sõnumi nimeruumide ja XML-i struktuur olla väga erinev Microsoft .NET-i loodud struktuurist. Hästi kirjutatud klient või server võib aga töödelda mis tahes sõnumit, mis on hästi kirjutatud vastavalt SOAP-i juhistele.

Lisaks on WSDL 1.1 ja WSDL 2.0 juhiste vahel mõned olulised erinevused. Kuigi 2.0 juhised on kirjutamise ajal alles lõppjärgus, hakkab see peagi versiooni 1.1 asemele asuma.

Kui te pole kunagi varem WSDL-faili kohanud ja proovite seda avada ja lugeda, on teil raske sealt kogu teavet välja võtta, kuna sellise faili struktuur võib olla üsna keeruline. Kogu meetodi kohta käiv teave (nimi, parameetrid, protokoll jne) on hajutatud faili erinevatesse osadesse ja klientrakendus peab selle SOAP-sõnumi koostamiseks koguma. WSDL-faili osade ja nende kirjeldused ühine töö selles artiklis ei ole.

Siin tuleb tehnoloogia taas appi. Arendajana ei pea te WSDL-faili sisu lugema, sõeluma ega sellest aru saama. Tööriistad saavad selle teabe teie eest, nii et peate lihtsalt välja mõtlema, mida teenusele saata ja kuhu tulemused panna. sina mitte ainult sa saad kasutada raamatukogusid ja tööriistu, aga ka kindlasti sa saad. Kõigi veebiteenuse komponentide puhul on palju erandeid, luksumisi ja keerukust ning neid tuleks uurida kasutades Veebiteenus, mitte selle lahtivõtmine, millele järgneb iga komponendi üksikasjalik uurimine.

Protokollid: kuidas sõnumeid saadetakse

Me pole veel puudutanud küsimust, kuidas kõik need sõnumid SOAP-i kaudu edastatakse?

Ja need edastatakse tavaliselt võrgu (ja/või Interneti) kaudu HTTP-protokolli abil, samamoodi nagu lehti edastatakse serverist teie brauserisse. HTTP-d ei kasutata alati (selle peamiseks konkurendiks on SMTP, kuid see jääb kaugele maha). Veebiteenuse kasutatav protokoll on määratletud WSDL-failis.

Tavaliselt on WSDL-failis SOAP-sõnumi saatmiseks kasutatav protokoll defineeritud kui HTTP. SOAP-klient saadab sõnumeid vastavalt määratud protokollile.

Muud veebiteenuste tingimused, millega võite kokku puutuda

Oleme juba põhimõisteid käsitlenud, kuid veebiteenustest rääkides võite kuulda veel mõnda.

Nõrgad sidemed

Veebiteenuseid kasutavad programmid on tavaliselt teenustega lõdvalt seotud, see tähendab, et programmi tööks vajalikud teenused ei ole sellega otseselt seotud, nii nagu programm pole teenustega seotud. Programm saab hõlpsasti kasutada kõiki vajalikke teenuseid ja nad ootavad kõnet programmilt - mis tahes programmilt, mis vajab nende vastust.

Nõrkade sidemete näide elust on lõunasöök sõpradega. Mitmed sõbrad lepivad kuidagi omavahel kokku (isiklikult, telefoni teel, läbi email jne.). Igaüks jõuab restorani ise ja pärast õhtusööki maksab igaüks ise oma toidu eest. Ükskõik, kuidas lõuna läks, on lõpptulemus sama – oli sõbralik lõuna.

Kuid autojuhtimine on tihedamate ühendustega tegevus. Teil on kindel komplekt tööriistu, millega etteantud eesmärke saavutada. Garaažist väljudes lülitad sisse tagurpidikäigu ja vajutad gaasile. Vasakpöördel keerate rooli vasakule. Teil ei ole võimalust teha sama asja erineval viisil, kuna kogu süsteem on väga täpne ja koordineeritud ning selle iga element on teistega seotud.

UDDI

UDDI on standard paljude programmide pakutavate veebiteenuste kataloogi loomiseks. See on nagu veebiteenuse pakkujate telefoniraamat. Kliendid saavad otsida vajalikku teavet UDDI registrist ja register tagastab teenusega ühenduse loomiseks vajalikud andmed.

Kuigi UDDI on veebiteenuste määratlemisel üsna oluline standard, vähendab selle olulisust oluliselt asjaolu, et see on veebiteenuste valikuline element ja kui antakse võimalus seda kasutada või mitte, otsustavad paljud seda mitte kasutada.

Enamikul organiseeritud ja paljude sisemiste veebiteenustega ettevõttekeskkondadel on UDDI registrid. On suurepärane, kui teil on UDDI ettevõtte sait, mis sisaldab teavet teie ettevõttes saadaolevate veebiteenuste kohta. Ühendades kõik teenused, võimaldab UDDI nende pakkujaid sujuvalt ja sujuvalt vahetada. Kui kliendid otsivad teenuseid UDDI kaudu, saadetakse SOAP-kõned automaatselt uuele pakkujale.

See komponent pole aga veebiteenuste arhitektuuris nõutav.

Veebiteenuste turvalisus

SOAP-i ja WSDL-i kohta lugedes võite märgata, et turvalisuse teemat ei käsitleta. Kuidas toimub autentimine teenustele helistamisel, kui teenusepakkuja töötab tundliku teabega? Lõppude lõpuks on selge, et kõik veebiteenused pole üldsusele kättesaadavad, eks?

See on oluline küsimus, millele pole lihtne üheselt vastata. Olenevalt olukorrast saate kasutada erinevaid skeeme, näiteks:

Kas SOAP-sõnumid võivad tulla lihttekstina või peavad need olema krüptitud?
Kas teie jaoks piisab lihtsast sisselogimise ja parooli autentimisest või peaks see olema tugev ja markeripõhine?
Kui žetoone kasutatakse, kas need peavad olema allkirjastatud ja kuidas on õige viis need SOAP-sõnumisse lisada?
Aga mis siis, kui klient ei saada SOAP-sõnumeid otse, vaid mõne vahestruktuuri kaudu, näiteks sõnumijärjekorra või mõne muu veebiteenuse kaudu?

Samuti ei saa sõnumsides alati HTTP-d kasutada, seega ei saa te kasutada lisaks olemasolevale HTTP-turvalisusele ka veebiteenuste turvalisust.

Neid ja muid veebiteenuste turvalisuse aspekte hõlmavad mitmed juhised: WS-Security, WS-Policy, WS-Trust ja WS-Privacy. Mõned tarkvaramüüjad ja komiteed on nende probleemidega tegelenud juba mitu aastat. Kuigi kõik veebiteenuste juurutused ei toeta kõiki turbejuhiseid, rakendavad olemasolevad turbestandardid tavaliselt vähemalt mõnda põhilist turbeteed.

Vahevara ja ettevõtte teenindusbuss

Veebiteenuste jaoks on veel üks üsna suur standardite kogum, mis on koondatud üheks üsna suureks kimbuks, mida tavaliselt nimetatakse WS-* juhisteks. Üheskoos hõlmavad need paljusid disainiprobleeme, mis tekivad paljude veebiteenuste ühte keskkonda koondamisel. WS-* standardid käsitlevad selliseid probleeme nagu:

Ohutus
Töökindlus
Sõnumivahetus
Tehingud
Teenuse kvaliteet

See arv standardeid on vajalik, kuna veebiteenuse kliendi ja serveri vaheline sõnumivahetus tootmiskeskkonnas võib olla palju keerulisem kui lihtne päring/vastus. Näiteks kuidas tagada, et sõnum jõuaks pakkujani ja naaseb kliendini? Mis siis, kui SOAP-i päringul on mitu osa? Kuidas haldate protsesse, mis hõlmavad veebiteenuste juurdepääsu teistele veebiteenustele? Mis siis, kui programm saadab päringute jada koos reageerimisaja nõuetega?

Suurte tarkvaratootjate jaoks pakub nende standarditega töötamine nii väljakutseid kui ka võimalusi. Mitmed müüjad turustavad terveid veebiteenuste vahevarapakette, mida sageli nimetatakse Enterprise Service Busiks või ESB-deks, mis tegelevad kõigi või vähemalt mõne ülaltoodud ülesannetega korraga. Need ESB-d on väärtuslikud ka seetõttu, et nad suudavad ühendada mitu veebiteenust samas organisatsioonis ja pakkuda nende funktsioone, salvestada nende toiminguid ja salvestada sõnumeid järjekordadesse.

Teeninduskeskne arhitektuur

Ja lõpuks teenustele orienteeritud arhitektuur. Enamasti on see lihtsalt kõigi eelnimetatute kombinatsioon: erinevate tarnijate lõdvalt seotud veebiteenused, mis suhtlevad vastavalt aktsepteeritud standarditele (võib-olla ESB-dega) ja on kokku pandud erinevate programmide poolt, mis võtavad teenustest andmeid ja kasutavad neid erineval viisil. .

Kuna SOA on tarkvaraarhitektuur, on selle loomisel palju koordineerimist ja planeerimist. See ei ole lihtsalt hunnik teenuseid, mis on kokku segatud; see on korraldus selle kohta, kuidas teenuseid kokku pannakse ja avaldatakse, milliseid haldustööriistu ja vahevara kasutatakse ning kuidas teenuseid ja süsteemi tervikuna jälgitakse ja hallatakse.

Kui vaadata globaalsemalt, siis SOA on ka mõtlemise tüüp. See sunnib meid mõtlema mitte iseseisvatele suurprogrammidele, vaid tajuma kõike võimalike komponentidena, mida saab avaldada ja tootmises kasutada. Rikkalike rakenduste asemel mõtlete konkreetsetele ja täpselt määratletud teenustele – need on veebiteenused.

Miks see oluline on?

Nüüdseks tead veebiteenuste toimimisest juba üht-teist – klient loeb pakkuja WSDL faili, vormindab ja saadab vastavalt sellele SOAP-teate ning saab vastuseks uue SOAP-teate. Miks see siis nii oluline on? Mis viga?

Osa teenuste tähtsusest seisneb selles, et need pakuvad programmidele standardset suhtlusviisi, olenemata sellest, mis keeles need on kirjutatud või millistel platvormidel need töötavad. Varem pidime töötama erinevate programmide jaoks ainulaadsete andmevormingutega või API-taseme funktsioonidega, millega teiste keelte programmid ei saanud töötada. XML-i kasutamine kõigis veebiteenuste standardites tähendab, et kõik teenused on juurdepääsetavad ja selgelt määratletud.

Tegelikult võimaldab see täiesti erinevatel programmidel üksteisega hõlpsasti suhelda keeles, millest nad kõik aru saavad. Üks peamisi väljakutseid erinevate tootjate erinevate tehnoloogiatega töötamisel on alati olnud vajadus saada kõik need erinevad programmid omavahel suhtlema ja andmeid vahetama. Nüüd, kui kõik teie rakendused saavad pakkuda ja/või tarbida veebiteenuseid, on nendevaheline suhtlemine uskumatult lihtne.

Veebiteenuste teine eelis on see, et kliendid ja müüjad saavad viibida erinevates masinates, kasutades erinevat riist- ja tarkvara, ilma suhtlust segamata. Programme saavad kasutada ka teised programmid samas masinas või teistest masinatest, kuid kasutades kindlat andmeedastusvormingut. Veebiteenused vajavad ainult võrguühendust ja XML-käsitlejat.

Kui kõiki neid tegureid koos vaadelda, on tulemus märkimisväärne. Kui meil on standardne abinõu rakenduste vaheliseks suhtluseks üle võrgu saame oma programme koostada erineval viisil. Selle asemel, et kirjutada monoliitseid programme, milles ratas leiutatakse iga kord uuesti, saame kirjutada programme, mis koosnevad moodulitest.

Näiteks suure programmi asemel, mis kogub infot mitme protsessi kohta, muudab selle graafikuteks ja näitab neid kasutajatele, saame luua armatuurlaua, mis kuvab mitmest veebiteenusest saadud andmeid. Koostatud andmed võetakse vastu ühest või mitmest teenusest ja saadud graafikud loob teine veebiteenus, mis võtab andmed ja loob mingisuguse graafiku.

Armatuurlaud muudetakse suurest programmist lihtsaks liideseks. Kui tahame lisada uusi komponente, kutsume lihtsalt lisateenuseid. Kui vajame teistsugust diagrammi, pöördume mõne teise kaardistamisteenuse poole. Kui vajame interaktiivsemat armatuurlauda koos õppimis- või sortimisvõimalusega, saab armatuurlaud edastada sõnumeid kasutajalt vastavale teenusele. Saame isegi täielikult muuta teenuseid, millele helistatakse ilma, et kasutajad seda märkaksid (kuni WSDL-fail muutub) ja paneel jääb samaks.

IT-professionaalina saate arendada esiosa, teenusearendust või mõlemat. Sellise projekti kallal töötamiseks on oluline mõista, kuidas see kõik koos töötab (või vähemalt teadmine, mis see on).

Samuti on hea, et on palju tööriistu, mis aitavad teil veebiteenuseid pakkuda ja tarbida, ning suudavad teie eest palju rasket tööd ära teha. Selle artikli järgmistes osades näeme, kuidas saate hõlpsasti pakkuda veebiteenuseid klientidele või süsteemidele, kasutades IBM Lotus Domino V7.0.