Mik azok a webszolgáltatások? Architecture, Típusok, Példa
⚡ Okos összefoglaló
A webszolgáltatások szabványosított közeget biztosítanak a kliens- és szerveralkalmazások számára a világhálón keresztüli kommunikációhoz. Ez az anyag ismerteti a webszolgáltatások működését, SOAP és RESTful típusaikat, a WSDL és UDDI komponenseket, az architektúra szerepköreit és a főbb jellemzőket.
Mi az a webszolgáltatás?
webes szolgáltatás egy szabványos médium a kliens és a szerver alkalmazások közötti kommunikáció terjesztésére a WWW-en (World Wide Web). A webszolgáltatás egy szoftvermodul, amelyet bizonyos feladatok elvégzésére terveztek.
- A felhőalapú számítástechnika webszolgáltatásai a hálózaton keresztül kereshetők, és ennek megfelelően meg is hívhatók.
- Meghíváskor a webszolgáltatás biztosítani tudja a funkcionalitást az ügyfél számára, amely meghívja a webszolgáltatást.
Hogyan működnek a webszolgáltatások?
A fenti diagram nagyon leegyszerűsített képet mutat arról, hogyan működne egy webszolgáltatás valójában. Az ügyfél egy sor webszolgáltatási hívást indít el a tényleges webszolgáltatást kiszolgáló szerverhez intézett kéréseken keresztül.
Ezeket a kéréseket úgynevezett távoli eljáráshívásokon keresztül küldik el. A távoli eljáráshívások (RPC) olyan hívások, amelyeket a megfelelő webszolgáltatás által üzemeltetett metódusokhoz intéznek.
Mint például, Amazon webszolgáltatást biztosít, amely az amazon.com oldalon keresztül online értékesített termékek árait biztosítja. A front end vagy a bemutató réteg lehet .Net vagy Java, de bármelyik programozási nyelv képes lenne kommunikálni a webszolgáltatással.
A webszolgáltatás tervezésének fő összetevője a kliens és a szerver között továbbított adatok, ez pedig az XML. XML (kiterjeszthető jelölőnyelv) a HTML megfelelője és egy könnyen érthető köztes nyelv, amelyet számos programozási nyelv megért.
Tehát amikor az alkalmazások kommunikálnak egymással, valójában XML-ben kommunikálnak. Ez egy közös platformot biztosít a különböző programozási nyelveken fejlesztett alkalmazások számára, hogy kommunikálhassanak egymással.
A webszolgáltatások a SOAP-ot (Simple Object Access Protocol) használják az XML adatok alkalmazások közötti küldésére. Az adatok elküldése normál HTTP-n keresztül történik. A webszolgáltatástól az alkalmazáshoz küldött adatokat SOAP üzenetnek nevezzük. A SOAP üzenet nem más, mint egy XML dokumentum. Mivel a dokumentum XML-ben készült, a webszolgáltatást hívó kliens alkalmazás bármilyen programozási nyelven írható.
Miért van szüksége webszolgáltatásra?
A modern üzleti alkalmazások különféle programozási platformokat használnak webalapú alkalmazások fejlesztéséhez. Egyes alkalmazások fejleszthetők Java, mások .Net-ben, míg mások Angular JS-ben, Node.js-ben stb.
Ezeknek a heterogén alkalmazásoknak az esetek többségében valamilyen kommunikációra van szükségük egymás között. Mivel különböző fejlesztői nyelveken készülnek, rendkívül nehéz biztosítani az alkalmazások közötti pontos kommunikációt.
Itt jönnek a webszolgáltatások programozási nyelvek hogy képesek legyenek kommunikálni egymással.
Webszolgáltatások típusai
Alapvetően kétféle webszolgáltatás létezik:
- SOAP webszolgáltatások.
- RESTful webszolgáltatások.
Ahhoz, hogy egy webszolgáltatás teljes mértékben működőképes legyen, bizonyos komponenseknek jelen kell lenniük. Ezeknek a komponenseknek jelen kell lenniük, függetlenül attól, hogy milyen fejlesztői nyelvet használnak a webszolgáltatás programozásához. Nézzük meg ezeket a komponenseket részletesebben.
SOAP (egyszerű objektum-hozzáférési protokoll)
A SOAP egy szállításfüggetlen üzenetküldő protokoll. A SOAP az XML adatok SOAP üzenetekként történő átvitelén alapul. Minden üzenet tartalmaz valamit, amit XML dokumentumnak nevezünk. Csak az XML dokumentum szerkezete követ egy adott mintát, a tartalma nem. A webszolgáltatások és a SOAP legjobb része, hogy mindegyik HTTP-n keresztül kerül elküldésre, ami a szabványos webprotokoll.
Íme, hogy miből áll egy SOAP üzenet:
- Minden SOAP-dokumentumnak rendelkeznie kell egy gyökérelemmel, amely a elem. A gyökérelem az első elem az XML-dokumentumban.
- A „boríték” viszont 2 részre oszlik. Az első a fejléc, a következő pedig a törzs.
- A fejléc tartalmazza az útvonaladatokat, amelyek alapvetően azok az információk, amelyek megmondják az XML dokumentumnak, hogy melyik kliensnek kell elküldeni.
- A törzs tartalmazza a tényleges üzenetet.
Az alábbi diagram egy egyszerű példát mutat a SOAP-on keresztüli kommunikációra.
Ebben részletesen tárgyaljuk a SOAP-ot oktatói.
WSDL (Webszolgáltatások Description nyelv)
Egy webszolgáltatás nem használható, ha nem található. A webszolgáltatást meghívó kliensnek tudnia kell, hogy a webszolgáltatás valójában hol található.
Másodszor, a kliensalkalmazásnak tudnia kell, hogy mit csinál valójában a webszolgáltatás, hogy meghívhassa a megfelelő webszolgáltatást. Ezt a WSDL, más néven webszolgáltatások segítségével teszi meg. Description nyelv. A WSDL fájl ismét egy XML-alapú fájl, amely alapvetően megmondja a kliensalkalmazásnak, hogy mit csinál a webszolgáltatás. A WSDL dokumentum használatával a kliensalkalmazás megértheti, hol található a webszolgáltatás, és hogyan használható.
Példa a webszolgáltatásra
Az alábbiakban egy WSDL fájl webszolgáltatási példája látható.
<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>
A webszolgáltatások fenti WSDL deklarációs példáival kapcsolatos fontos szempontok a következők:
- – A WSDL definícióban található üzenet paraméter a webszolgáltatás által végrehajtott egyes műveletek különböző adatelemeinek definiálására szolgál. Tehát a fenti webszolgáltatási példában két üzenetünk van, amelyeket a webszolgáltatás és a kliensalkalmazás között cserélhetünk ki: az egyik a „TutorialRequest”, a másik pedig a „TutorialResponse” művelet. A TutorialRequest tartalmaz egy „TutorialID” nevű elemet, amely karakterlánc típusú. Hasonlóképpen, a TutorialResponse művelet tartalmaz egy „TutorialName” nevű elemet, amely szintén karakterlánc típusú.
- – Ez valójában a webszolgáltatás által végrehajtható műveletet írja le, amelyet esetünkben Tutorialnak hívnak. Ez a művelet két üzenetet fogadhat: az egyik egy bemeneti üzenet, a másik pedig a kimeneti üzenet.
- – Ez az elem tartalmazza a használt protokollt. Esetünkben tehát HTTP-t használ (http://schemas.xmlsoap.org/soap/http). A művelet törzséhez egyéb részleteket is megadunk, például a névteret és azt, hogy az üzenetet kódolni kell-e.
A „WSDL”-t részletesen tárgyaljuk ebben a cikkben. oktatói.
Egyetemes Description, Discovery és Integration (UDDI)
Az UDDI egy szabvány az adott szolgáltató által nyújtott webszolgáltatások leírására, közzétételére és felfedezésére. Olyan specifikációt ad, amely segít a webszolgáltatások információinak tárolásában.
Most az előző témakörben a WSDL-ről beszéltünk, és arról, hogy az hogyan tartalmaz információkat arról, hogy mit is csinál a webszolgáltatás. De hogyan találhat meg egy ügyfélalkalmazás egy WSDL-fájlt, hogy megértse a webszolgáltatás által kínált különféle műveleteket? Tehát az UDDI a válasz erre, és egy tárhelyet biztosít, amelyen a WSDL-fájlok tárolhatók. Így az ügyfélalkalmazás teljes hozzáféréssel rendelkezik az UDDI-hoz, amely az összes WSDL fájlt tartalmazó adatbázisként működik.
Ahogyan egy telefonkönyv tartalmazza egy adott személy nevét, címét és telefonszámát, ugyanúgy az UDDI nyilvántartás is tartalmazza a webszolgáltatáshoz szükséges információkat., hogy a kliensalkalmazás tudja, hol található.
Webszolgáltatások előnyei
Már értjük, miért jöttek létre a webszolgáltatások, vagyis hogy egy olyan platformot biztosítsanak, amely lehetővé teszi a különböző alkalmazások egymás közötti kommunikációját. De nézzük meg a webszolgáltatások előnyeinek listáját, hogy miért fontos a webszolgáltatások használata.
- Az üzleti funkciók feltárása a hálózaton – A webszolgáltatás egy felügyelt kód egysége, amely valamilyen funkcionalitást biztosít a kliensalkalmazások vagy a végfelhasználók számára. Ez a funkcionalitás HTTP protokollon keresztül hívható meg, ami azt jelenti, hogy az interneten keresztül is meghívható. Manapság minden alkalmazás az interneten van, ami a webszolgáltatások célját még hasznosabbá teszi. Ez azt jelenti, hogy a webszolgáltatás bárhol lehet az interneten, és szükség szerint biztosíthatja a szükséges funkciókat.
- Az alkalmazások közötti átjárhatóság – A webszolgáltatások lehetővé teszik a különböző alkalmazások számára, hogy kommunikáljanak egymással, és adatokat, valamint szolgáltatásokat osszanak meg egymás között. Minden típusú alkalmazás képes kommunikálni egymással. Tehát ahelyett, hogy olyan specifikus kódot írnánk, amelyet csak bizonyos alkalmazások értenek meg, mostantól írhatunk általános kódot, amelyet minden alkalmazás megért.
- Egy szabványosított protokoll, amelyet mindenki megért – A webszolgáltatások szabványosított iparági protokollt használnak a kommunikációhoz. Mind a négy réteg (Service Transport, XML Messaging, Service DescriptAz ion és a szolgáltatásfelderítési rétegek) jól definiált protokollokat használnak a webszolgáltatások protokollveremében.
- A kommunikációs költségek csökkentése – A webszolgáltatások SOAP over HTTP protokollt használnak, így a meglévő alacsony költségű internetet használhatja webszolgáltatások megvalósítására.
Web Services Architectúra
Minden keretrendszernek szüksége van valamilyen architektúrára, hogy biztosítsa a teljes keretrendszer kívánt módon történő működését. Hasonlóképpen, a webszolgáltatásokban a Web Services Architectúra három különálló szerepkörből áll, az alábbiak szerint:
- Provider – A szolgáltató létrehozza a webszolgáltatást, és elérhetővé teszi azt a kliensalkalmazások számára, amelyek használni szeretnék.
- Kérelmező – A kérelmező nem más, mint az ügyfélalkalmazás, amelynek kapcsolatba kell lépnie egy webszolgáltatással. A kliens alkalmazás lehet .Net, Java, vagy bármely más nyelvi alapú alkalmazás, amely valamilyen funkciót keres egy webszolgáltatáson keresztül.
- Bróker – A bróker nem más, mint az alkalmazás, amely hozzáférést biztosít az UDDI-hez. Az UDDI, ahogy azt a korábbi témában tárgyaltuk, lehetővé teszi a kliensalkalmazás számára a webszolgáltatás megtalálását.
Az alábbi ábra bemutatja, hogyan lépnek interakcióba egymással a szolgáltató, a szolgáltatást kérő és a szolgáltatásbeállítás-nyilvántartás.
- Közzétesz – Egy szolgáltató a bróker közzétételi felületén keresztül tájékoztatja a brókert (szolgáltatás-nyilvántartást) a webszolgáltatás létezéséről, hogy a szolgáltatást elérhetővé tegye az ügyfelek számára.
- Találjon – A kérelmező konzultál a brókerrel egy közzétett webszolgáltatás megkeresése érdekében.
- köt – A brókertől (szolgáltatás-nyilvántartástól) a webszolgáltatásról gyűjtött információkkal a kérelmező képes kötni, vagyis meghívni a webszolgáltatást.
Webszolgáltatás jellemzői
A webszolgáltatások a következő speciális viselkedési jellemzőkkel rendelkeznek:
- XML alapúak – A webszolgáltatások XML-t használnak az adatok ábrázolására a reprezentációs és adatátviteli rétegekben. Az XML használata kiküszöböli a hálózati, operációs rendszeri vagy platformfüggőséget, mivel az XML a közös, mindenki által értett nyelv.
- Lazán csatolt – A laza csatolás azt jelenti, hogy a kliens és a webszolgáltatás nincs egymáshoz kötve, ami azt jelenti, hogy ha a webszolgáltatás idővel változik is, az nem változtathatja meg azt, ahogyan az ügyfél a webszolgáltatást hívja. A lazán csatolt architektúra alkalmazása a szoftverrendszereket jobban kezelhetővé teszi, és egyszerűbb integrációt tesz lehetővé a különböző rendszerek között.
- Synchronos vagy aszinkron funkció - SyncA hronikusság az ügyfélnek a szolgáltatás végrehajtásához való kötöttségét jelenti. Szinkron műveletek esetén az ügyfél ténylegesen megvárja, amíg a webszolgáltatás befejez egy műveletet. Példa erre valószínűleg egy olyan forgatókönyv, amelyben egy adatbázis-olvasási és -írási műveletet hajtanak végre. Ha az egyik adatbázisból adatokat olvasunk ki, majd egy másikba írunk, akkor a műveleteket szekvenciálisan kell végrehajtani. Az aszinkron műveletek lehetővé teszik az ügyfél számára, hogy meghívjon egy szolgáltatást, majd párhuzamosan más funkciókat hajtson végre. Ez az egyik elterjedt és valószínűleg a legelőnyösebb technika annak biztosítására, hogy más szolgáltatások ne álljanak le egy adott művelet végrehajtása során.
- Távoli eljáráshívások (RPC) támogatásának képessége – A webszolgáltatások lehetővé teszik az ügyfelek számára, hogy eljárásokat, funkciókat és metódusokat hívjanak meg távoli objektumokon XML-alapú protokoll használatával. A távoli eljárások felfedik azokat a bemeneti és kimeneti paramétereket, amelyeket a webszolgáltatásnak támogatnia kell.
- Támogatja a dokumentumcserét – Az XML egyik legfontosabb előnye, hogy nem csak adatokat, hanem összetett dokumentumokat is képes megjeleníteni. Ezek a dokumentumok lehetnek olyan egyszerűek, mint egy aktuális címet, vagy olyan összetettek, mint egy egész könyvet.




