Mis on veebiteenused? Architektuur, tüübid, näide

Mis on veebiteenus?

Veebiteenus on standardiseeritud meedium kliendi- ja serverirakenduste vahelise suhtluse levitamiseks WWW-s (World Wide Web). Veebiteenus on tarkvaramoodul, mis on loodud teatud ülesannete komplekti täitmiseks.

• Pilvandmetöötluse veebiteenuseid saab otsida võrgu kaudu ja neid saab vastavalt ka välja kutsuda.
• Väljakutsumise korral suudab veebiteenus pakkuda kliendile funktsiooni, mis seda veebiteenust kutsub.

Kuidas veebiteenused töötavad?

Ülaltoodud diagramm näitab väga lihtsustatult, kuidas veebiteenus tegelikult töötaks. Klient kutsuks välja rea ​​veebiteenuse kõnesid päringute kaudu serverile, mis majutab tegelikku veebiteenust.

Need päringud esitatakse nn kaugprotseduurikõnede kaudu. Kaugprotseduurikõned (RPC) on kõned, mis tehakse meetoditele, mida majutab vastav veebiteenus.

Näiteks Amazon pakub veebiteenust, mis pakub hindu veebis amazon.com kaudu müüdavatele toodetele. Esiosa või esitluse kiht võib olla .Netis või Java, kuid mõlemal programmeerimiskeelel oleks võime veebiteenusega suhelda.

Veebiteenuse disaini põhikomponent on kliendi ja serveri vahel edastatavad andmed, see on XML. XML (laiendatav märgistuskeel) on HTML-i vaste ja hõlpsasti mõistetav vahekeel, mida paljud programmeerimiskeeled mõistavad.

Seega, kui rakendused omavahel suhtlevad, siis tegelikult suhtlevad nad XML-is. See pakub ühist platvormi erinevates programmeerimiskeeltes arendatud rakenduste omavaheliseks suhtlemiseks.

Veebiteenused kasutavad XML-andmete saatmiseks rakenduste vahel SOAP-i (Simple Object Access Protocol). Andmed saadetakse tavalise HTTP kaudu. Andmeid, mis veebiteenusest rakendusse saadetakse, nimetatakse SOAP-sõnumiks. SOAP-sõnum pole midagi muud kui XML-dokument. Kuna dokument on kirjutatud XML-is, saab veebiteenust kutsuva klientrakenduse kirjutada mis tahes programmeerimiskeeles.

Miks vajate veebiteenust?

Tänapäeva ärirakendused kasutavad veebipõhiste rakenduste arendamiseks mitmesuguseid programmeerimisplatvorme. Mõned rakendused võivad olla välja töötatud Java, teised .Netis, samas kui mõned teised Angular JS-is, Node.js-is jne.

Enamasti vajavad need heterogeensed rakendused omavahelist suhtlust. Kuna need on loodud erinevate arenduskeelte abil, on rakenduste vahelise täpse suhtluse tagamine väga keeruline.

Siin tulevad appi veebiteenused. Veebiteenused pakuvad ühist platvormi, mis võimaldab mitut erinevatele rakendustele rajatud rakendust programmeerimiskeeled omada oskust omavahel suhelda.

Veebiteenuste tüübid

Veebiteenuseid on peamiselt kahte tüüpi:

1. SOAP veebiteenused.
2. RESTful veebiteenused.

Veebiteenuse täielikuks toimimiseks on vaja teatud komponente. Need komponendid peavad olema olemas olenemata sellest, millist arenduskeelt veebiteenuse programmeerimiseks kasutatakse. Vaatleme neid komponente lähemalt.

SOAP (lihtne objekti juurdepääsuprotokoll)

SOAP on tuntud kui transpordist sõltumatu sõnumsideprotokoll. SOAP põhineb XML-andmete edastamisel SOAP-sõnumitena. Iga sõnum sisaldab midagi, mida nimetatakse XML-dokumendiks. Ainult XML-dokumendi struktuur järgib kindlat mustrit, kuid mitte sisu. Veebiteenuste ja SOAP-i parim osa on see, et kõik saadetakse HTTP kaudu, mis on standardne veebiprotokoll.

SOAP-sõnum koosneb järgmisest:

• Igal SOAP-dokumendil peab olema juurelement, mida nimetatakse element. Juurelement on XML-dokumendi esimene element.
• “Ümbrik” jaguneb omakorda kaheks osaks. Esimene on päis ja järgmine on keha.
• Päis sisaldab marsruutimisandmeid, mis on põhimõtteliselt teave, mis ütleb XML-dokumendile, millisele kliendile see saata tuleb.
• Keha sisaldab tegelikku sõnumit.

Allolev diagramm näitab lihtsat näidet SOAP-i kaudu suhtlemisest.

Selles käsitleme SEEPI üksikasjalikult juhendaja.

WSDL (veebiteenused Descriptioonkeel)

Veebiteenust ei saa kasutada, kui seda ei leita. Veebiteenust käivitav klient peaks teadma, kus veebiteenus tegelikult asub.

Teiseks peab kliendirakendus teadma, mida veebiteenus tegelikult teeb, et see saaks õige veebiteenuse välja kutsuda. Seda tehakse WSDL-i ehk veebiteenuste abil. Descriptioonkeel. WSDL-fail on jällegi XML-põhine fail, mis põhimõtteliselt ütleb kliendirakendusele, mida veebiteenus teeb. WSDL-dokumendi abil saab kliendirakendus aru, kus veebiteenus asub ja kuidas seda saab kasutada.

Veebiteenuse näide

Allpool on toodud WSDL-faili veebiteenuste näide.

<definitions>
   <message name="TutorialRequest">
      <part name="TutorialID" type="xsd:string"/>
   </message>

   <message name="TutorialResponse">
      <part name="TutorialName" type="xsd:string"/>
   </message>

   <portType name="Tutorial_PortType">
      <operation name="Tutorial">
         <input message="tns:TutorialRequest"/>
         <output message="tns:TutorialResponse"/>
      </operation>
   </portType>

   <binding name="Tutorial_Binding" type="tns:Tutorial_PortType">
      <soap:binding style="rpc"
         transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="Tutorial">
         <soap:operation soapAction="Tutorial"/>
         <input>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </input>

         <output>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </output>
      </operation>
   </binding>
</definitions>

Olulised aspektid, mida ülaltoodud veebiteenuste WSDL-deklaratsiooni näidete puhul tähele panna, on järgmised:

1. – WSDL-i definitsioonis olevat sõnumiparameetrit kasutatakse veebiteenuse iga toimingu erinevate andmeelementide määratlemiseks. Seega on ülaltoodud veebiteenuste näites veebiteenuse ja kliendirakenduse vahel vahetatavad kaks sõnumit: üks on toiming „TutorialRequest” ja teine ​​on toiming „TutorialResponse”. TutorialRequest sisaldab elementi nimega „TutorialID”, mis on tüübistring. Samamoodi sisaldab toiming TutorialResponse elementi nimega „TutorialName”, mis on samuti tüübistring.
2. – See kirjeldab tegelikult veebiteenuse poolt teostatavat toimingut, mida meie puhul nimetatakse õpetuseks. See toiming võib vastu võtta kaks sõnumit: üks on sisendsõnum ja teine ​​väljundsõnum.
3. – See element sisaldab kasutatavat protokolli. Seega meie puhul defineerime selle kasutama HTTP-d (http://schemas.xmlsoap.org/soap/http). Samuti määrame operatsiooni sisu jaoks muud üksikasjad, näiteks nimeruumi ja selle, kas sõnum tuleks kodeerida.

Selles artiklis käsitleme WSDL-i üksikasjalikumalt. juhendaja.

Universaalne Descriptioon, avastamine ja integratsioon (UDDI)

UDDI on standard konkreetse teenusepakkuja pakutavate veebiteenuste kirjeldamiseks, avaldamiseks ja avastamiseks. See pakub spetsifikatsiooni, mis aitab veebiteenuste kohta teavet majutada.

Nüüd arutasime eelmises teemas WSDL-i ja selle kohta, kuidas see sisaldab teavet selle kohta, mida veebiteenus tegelikult teeb. Kuid kuidas saab klientrakendus WSDL-faili leida, et mõista veebiteenuse pakutavaid erinevaid toiminguid? Nii et UDDI on vastus sellele ja pakub hoidla, kus saab WSDL-faile majutada. Seega on kliendirakendusel täielik juurdepääs UDDI-le, mis toimib andmebaasina, mis sisaldab kõiki WSDL-faile.

Nii nagu telefonikataloogis on konkreetse isiku nimi, aadress ja telefoninumber, on UDDI registris veebiteenuse jaoks asjakohane teave., et kliendirakendus teaks, kust seda leida.

Veebiteenuste eelised

Me juba mõistame, miks veebiteenused üldse tekkisid – pakkuda platvormi, mis võimaldaks erinevatel rakendustel omavahel suhelda. Aga vaatame veebiteenuste eeliseid, miks on oluline neid kasutada.

1. Ärifunktsioonide paljastamine võrgus – Veebiteenus on hallatava koodi ühik, mis pakub kliendirakendustele või lõppkasutajatele mingit funktsionaalsust. Seda funktsionaalsust saab käivitada HTTP-protokolli kaudu, mis tähendab, et seda saab käivitada ka interneti kaudu. Tänapäeval on kõik rakendused internetis, mis muudab veebiteenuste eesmärgi kasulikumaks. See tähendab, et veebiteenus võib asuda kõikjal internetis ja pakkuda vajalikku funktsionaalsust vastavalt vajadusele.
2. Rakenduste koostalitlusvõime – Veebiteenused võimaldavad erinevatel rakendustel omavahel suhelda ning andmeid ja teenuseid jagada. Kõik tüüpi rakendused saavad omavahel suhelda. Seega spetsiifilise koodi kirjutamise asemel, millest saavad aru ainult kindlad rakendused, saate nüüd kirjutada üldist koodi, millest saavad aru kõik rakendused.
3. Standardprotokoll, millest kõik aru saavad – Veebiteenused kasutavad suhtluseks standardiseeritud tööstusprotokolli. Kõik neli kihti (teenuse transport, XML-sõnumivahetus, teenuse Descriptioon ja teenuse avastamise kihid) kasutavad veebiteenuste protokollipinus täpselt määratletud protokolle.
4. Sidekulude vähendamine – Veebiteenused kasutavad HTTP-protokolli SOAP-i, nii et saate veebiteenuste juurutamiseks kasutada olemasolevat odavat internetti.

Web Services Architektuur

Iga raamistik vajab mingisugust arhitektuuri, et tagada kogu raamistiku soovitud toimimine. Samamoodi on veebiteenuste puhul Web Services Architektuur koosneb kolmest erinevast rollist, nagu allpool näidatud:

1. Provider – Pakkuja loob veebiteenuse ja teeb selle kättesaadavaks kliendirakendustele, kes seda kasutada soovivad.
2. Taotleja – Taotleja pole midagi muud kui klientrakendus, mis peab veebiteenusega ühendust võtma. Kliendirakendus võib olla .Net, Javavõi mis tahes muu keelepõhine rakendus, mis otsib mingit funktsionaalsust veebiteenuse kaudu.
3. Maakler – Vahendaja pole midagi muud kui rakendus, mis annab juurdepääsu UDDI-le. Nagu eelmises teemas käsitletud, võimaldab UDDI kliendirakendusel veebiteenust leida.

Allolev diagramm näitab, kuidas teenusepakkuja, teenuse taotleja ja teenuse register omavahel suhtlevad.

1. Avalda – Pakkuja teavitab vahendajat (teenuseregistrit) veebiteenuse olemasolust, kasutades vahendaja avaldamisliidest, et muuta teenus klientidele kättesaadavaks.
2. leidma – Päringu esitaja konsulteerib vahendajaga avaldatud veebiteenuse leidmiseks.
3. Seo – Vahendajalt (teenuse registrist) veebiteenuse kohta saadud teabe abil saab taotleja veebiteenuse siduda ehk selle käivitada.

Veebiteenuse omadused

Veebiteenustel on järgmised käitumisomadused:

1. Need on XML-põhised – Veebiteenused kasutavad XML-i andmete esitamiseks esitus- ja andmeedastuskihtidel. XML-i kasutamine välistab igasuguse sõltuvuse võrgust, operatsioonisüsteemist või platvormist, kuna XML on kõigile arusaadav ühine keel.
2. Lõdvalt ühendatud – Lõdvalt seotud tähendab, et klient ja veebiteenus ei ole omavahel seotud, mis tähendab, et isegi kui veebiteenus aja jooksul muutub, ei tohiks see muuta seda, kuidas klient veebiteenusele helistab. Lõdvalt seotud arhitektuuri kasutuselevõtt muudab tarkvarasüsteemid paremini hallatavaks ja võimaldab lihtsamat integreerimist erinevate süsteemide vahel.
3. Synchronoosne või asünkroonne funktsionaalsus - Synckroonilisus viitab kliendi sidumisele teenuse osutamisega. Sünkroonsete toimingute puhul ootab klient tegelikult, kuni veebiteenus toimingu lõpetab. Selle näiteks on tõenäoliselt stsenaarium, kus tehakse andmebaasi lugemise ja kirjutamise toiming. Kui andmeid loetakse ühest andmebaasist ja kirjutatakse seejärel teise, siis tuleb toimingud teha järjestikku. Asünkroonsed toimingud võimaldavad kliendil teenuse välja kutsuda ja seejärel paralleelselt muid funktsioone täita. See on üks levinumaid ja ilmselt kõige eelistatumaid meetodeid tagamaks, et teisi teenuseid ei peatata teatud toimingu ajal.
4. Võimalus toetada kaugprotseduurikõnesid (RPC) – Veebiteenused võimaldavad klientidel XML-põhist protokolli kasutades käivitada kaugobjektidel protseduure, funktsioone ja meetodeid. Kaugprotseduurid paljastavad sisend- ja väljundparameetrid, mida veebiteenus peab toetama.
5. Toetab dokumendivahetust – Üks XML-i peamisi eeliseid on selle üldine viis mitte ainult andmete, vaid ka keerukate dokumentide esitamiseks. Need dokumendid võivad olla sama lihtsad kui praeguse aadressi esitamine või sama keerulised kui terve raamatu esitamine.

KKK