Mik azok a webszolgáltatások? Architecture, Típusok, Példa

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ödik a WebServices?

Hogyan működik a WebServices
Hogyan működik a WebServices

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.

Ezek a kérések az úgynevezett távoli eljáráshívásokon keresztül történnek. A Remote Procedure Calls (RPC) olyan metódusok hívása, amelyeket a megfelelő webszolgáltatás tárol.

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 (bővíthető jelölőnyelv) a HTML megfelelője, és könnyen érthető a köztes nyelv, amelyet számos programozási nyelv megért.

Tehát amikor az alkalmazások beszélnek egymással, valójában XML-ben beszélnek. Ez közös platformot biztosít a különféle programozási nyelveken fejlesztett alkalmazások számára, hogy beszéljenek 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 számos programozási platformot használnak webalapú alkalmazások fejlesztésére. Előfordulhat, hogy egyes alkalmazások fejlesztésére is sor kerül Java, mások .Netben, míg mások Angular JS-ben, Node.js-ben stb.

Leggyakrabban ezeknek a heterogén alkalmazásoknak szükségük van valamilyen kommunikációra, hogy megtörténjenek közöttük. Mivel különböző fejlesztői nyelvekkel készülnek, nagyon nehéz lesz az alkalmazások közötti pontos kommunikációt biztosítani.

Itt jönnek a webszolgáltatások programozási nyelvek hogy képesek legyenek kommunikálni egymással.

Webszolgáltatás típusa

Főleg kétféle webszolgáltatás létezik.

  1. SOAP webszolgáltatások.
  2. RESTful webszolgáltatások.

Ahhoz, hogy egy webszolgáltatás teljesen működőképes legyen, bizonyos összetevőknek a helyükön kell lenniük. Ezeknek az összetevőknek jelen kell lenniük, függetlenül attól, hogy a webszolgáltatás programozásához milyen fejlesztői nyelvet használnak.

Nézzük ezeket az összetevőket részletesebben.

SOAP (egyszerű objektum-hozzáférési protokoll)

A SOAP szállítástól független üzenetkezelési protokollként ismert. A SOAP az XML adatok SOAP üzenetként történő átvitelén alapul. Minden üzenetnek van valami, amit XML-dokumentumnak nevezünk. Csak az XML-dokumentum szerkezete követ egy meghatározott mintát, de a tartalom nem. A webszolgáltatások és a SOAP legjobb része az, hogy mindegyiket HTTP-n keresztül küldik, amely a szabványos webprotokoll.

Íme, miből áll a 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 útválasztási adatokat, 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.

SOAP protokoll

SOAP protokoll

Ebben részletesen tárgyaljuk a SOAP-ot oktatói.

WSDL (webszolgáltatások leírási nyelve)

Egy webszolgáltatás nem használható, ha nem található. A webszolgáltatást hívó ügyfélnek tudnia kell, hogy a webszolgáltatás hol található.

Másodszor, az ügyfélalkalmazásnak tudnia kell, hogy valójában mit csinál a webszolgáltatás, hogy a megfelelő webszolgáltatást hívhassa meg. Ez a WSDL, az úgynevezett webszolgáltatások leírási nyelve segítségével történik. A WSDL fájl ismét egy XML-alapú fájl, amely alapvetően elmondja az ügyfélalkalmazásnak, hogy mit csinál a webszolgáltatás. A WSDL dokumentum használatával az ügyfélalkalmazás képes lenne megérteni, 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:

  1. – A WSDL-definíció üzenetparamétere a webszolgáltatás által végrehajtott egyes műveletek különböző adatelemeinek meghatározására szolgál. Tehát a fenti webszolgáltatási példákban 2 üzenetünk van, amelyek a webszolgáltatás és az ügyfélalkalmazás között válthatók, az egyik a „TutorialRequest”, a másik a „TutorialResponse” művelet. A TutorialRequest egy „TutorialID” nevű elemet tartalmaz, amely karakterlánc típusú. Hasonlóképpen, a TutorialResponse művelet egy „TutorialName” nevű elemet tartalmaz, amely szintén egy típuskarakterlánc.
  2. – Ez tulajdonképpen azt a műveletet írja le, amelyet a webszolgáltatás végezhet el, amit esetünkben Tutorialnak hívunk. Ez a művelet 2 üzenetet vehet igénybe; az egyik egy bemeneti üzenet, a másik pedig a kimeneti üzenet.
  3. – Ez az elem tartalmazza a használt protokollt. Tehát a mi esetünkben úgy határozzuk meg, hogy http (http://schemas.xmlsoap.org/soap/http). Más részleteket is megadunk a művelet törzséhez, például a névteret és azt, hogy az üzenetet kódolni kell-e.

Ebben részletesen tárgyaljuk a „WDSL”-t 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.

Ahogy a telefonkönyvben szerepel egy adott személy neve, címe és telefonszáma, ugyanúgy az UDDI nyilvántartó rendelkezik a webszolgáltatáshoz szükséges információkkal.. Hogy egy kliens alkalmazás tudja, hol található.

Webszolgáltatások előnyei

Már értjük, miért jöttek létre a webszolgáltatások, amelyek célja egy olyan platform biztosítása, amely lehetővé tette a különböző alkalmazásoknak, hogy beszéljenek egymással.

De nézzük meg a webszolgáltatások előnyeinek listáját, hogy miért fontos a webszolgáltatások használata.

  1. Az üzleti funkciók feltárása a hálózaton – A webszolgáltatás a felügyelt kód olyan egysége, amely valamilyen funkcionalitást biztosít az ügyfélalkalmazások vagy a végfelhasználók számára. Ez a funkció a HTTP protokollon keresztül hívható meg, ami azt jelenti, hogy az interneten keresztül is meghívható. Manapság minden alkalmazás megtalálható az interneten, ami hasznosabbá teszi a webszolgáltatások célját. Ez azt jelenti, hogy a webszolgáltatás bárhol megtalálható az interneten, és szükség szerint biztosíthatja a szükséges funkciókat.
  2. Az alkalmazások közötti átjárhatóság – A webszolgáltatások lehetővé teszik a különböző alkalmazásoknak, hogy beszéljenek egymással, és megosszák egymással az adatokat és szolgáltatásokat. Minden típusú alkalmazás képes beszélni egymással. Tehát ahelyett, hogy konkrét kódot írna, amelyet csak bizonyos alkalmazások érthetnek meg, most általános kódot írhat, amelyet minden alkalmazás megérthet
  3. Egy szabványosított protokoll, amelyet mindenki megért – A webszolgáltatások szabványos iparági protokollt használnak a kommunikációhoz. Mind a négy réteg (Service Transport, XML Messaging, Service Description és Service Discovery rétegek) jól meghatározott protokollokat használ a webszolgáltatások protokollveremében.
  4. 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 a teljes keretrendszer a kívánt módon működjön, hasonlóan a webszolgáltatásokban. A Web Services Architectúra három különböző szerepkörből áll, az alábbiak szerint:

  1. Provider – A szolgáltató létrehozza a webszolgáltatást, és elérhetővé teszi azt a használni kívánó ügyfélalkalmazások számára.
  2. 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 nyelv alapú alkalmazás, amely valamilyen funkcionalitást keres egy webszolgáltatáson keresztül.
  3. Bróker – A bróker nem más, mint az alkalmazás, amely hozzáférést biztosít az UDDI-hoz. Az UDDI, amint azt a korábbi témakörben tárgyaltuk, lehetővé teszi az ügyfélalkalmazás számára, hogy megtalálja a webszolgáltatást.

Az alábbi diagram azt mutatja be, hogy a Szolgáltató, a Szolgáltatást igénylő és a Szolgáltatás-nyilvántartás hogyan lépnek kapcsolatba egymással.

Web Services Architectúra

Web Services Architectúra
  1. Közzétesz – A szolgáltató a közvetítő közzétételi felületén keresztül tájékoztatja a brókert (szolgáltatásnyilvá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.
  2. Találjon – A kérelmező konzultál a brókerrel, hogy megkeresse a közzétett webszolgáltatást
  3. köt – A brókertől (szolgáltatásnyilvántartástól) a webszolgáltatásról szerzett információkkal az igénylő képes a webszolgáltatást lekötni, illetve meghívni.

Webszolgáltatás jellemzői

A webszolgáltatások a következő speciális viselkedési jellemzőkkel rendelkeznek:

  1. XML alapúak – A Web Services XML-t használ az adatok megjelenítésére a reprezentációs és adatátviteli rétegekben. Az XML használata megszünteti a hálózattól, operációs rendszertől vagy platformtól való függést, mivel az XML a mindenki által értett közös nyelv.
  2. 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.
  3. 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.
  4. 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.
  5. 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.