SOAP webszolgáltatások oktatóanyaga: Mi a SOAP protokoll?
⚡ Okos összefoglaló
A SOAP (Simple Object Access Protocol) egy XML-alapú protokoll webszolgáltatások HTTP-n keresztüli eléréséhez. Ez az anyag ismerteti a SOAP építőelemeit, az üzenetstruktúrát, a burkológörbe és a hibaelemeket, a kommunikációs modellt, valamint egy gyakorlati ASMX webszolgáltatási példát.
Mi az a SZAPPAN?
A SOAP egy XML-alapú protokoll webszolgáltatások HTTP-n keresztüli eléréséhez. Vannak olyan specifikációi, amelyek minden alkalmazásban használhatók.
A SOAP Simple Object Access Protocol néven ismert, de később egyszerűen SOAP v1.2-re rövidítették. A SOAP egy protokoll, vagy más szóval annak a definíciója, hogy a webszolgáltatások hogyan kommunikálnak egymással, illetve az őket meghívó kliensalkalmazásokkal.
A SOAP-ot köztes nyelvként fejlesztették ki, hogy a különféle programozási nyelvekre épülő alkalmazások könnyen beszélhessenek egymással, és elkerüljék a rendkívüli fejlesztési erőfeszítéseket.
SZAPPAN Bevezetés
A mai világban rengeteg alkalmazás létezik, amelyek különböző programozási nyelveken készültek. Például lehet egy webes alkalmazás, amelyet úgy terveztek, hogy Java, egy másik a .Net-ben, és egy másik a PHP.
Az alkalmazások közötti adatcsere kulcsfontosságú a mai hálózati világban. Az ilyen heterogén alkalmazások közötti adatcsere azonban bonyolult lenne. Így lesz az adatcsere végrehajtásához szükséges kód összetettsége is.
Az e bonyolultság elleni küzdelem egyik módszere az XML (Extensible Markup Language) használata az alkalmazások közötti adatcsere közbenső nyelveként.
Minden programozási nyelv képes megérteni az XML jelölőnyelvet. Ezért az XML-t használták az adatcsere mögöttes médiumaként.
De nincsenek szabványos előírások az XML használatára vonatkozóan az összes programozási nyelven az adatcseréhez. Itt jön képbe a SOAP szoftver.
A SOAP-ot úgy tervezték, hogy HTTP-n keresztül működjön XML-lel, és rendelkezzen valamilyen specifikációval, amely minden alkalmazásban használható. A SOAP protokoll további részleteivel a következő fejezetekben foglalkozunk.
A SOAP előnyei
A SOAP az alkalmazások közötti adatcseréhez használt protokoll. Az alábbiakban felsorolunk néhány okot, amelyek miatt miért használjuk a SOAP-ot.
- Amikor fejlődikping A SOAP-alapú webszolgáltatásokhoz szükség van valamilyen nyelvre, amelyet a webszolgáltatások használhatnak a kliensalkalmazásokkal való kommunikációhoz. A SOAP a tökéletes közeg, amelyet erre a célra fejlesztettek ki. Ezt a protokollt a W3C konzorcium is ajánlja, amely az összes webes szabvány irányító testülete.
- A SOAP egy könnyű protokoll, amelyet az alkalmazások közötti adatcserére használnak. Jegyezze fel a kulcsszótfényMivel a SOAP programozás az XML nyelven alapul, amely maga is egy könnyű adatcsere-nyelv, ezért a SOAP, mint protokoll is ugyanebbe a kategóriába tartozik.
- A SOAP platformfüggetlennek és operációs rendszertől függetlennek is lett tervezve. Így a SOAP protokoll bármilyen programozási nyelven alapuló alkalmazással működhet mindkét platformon. Windows és a Linux platformokon.
- HTTP protokollon működik – A SOAP a HTTP protokollon működik, amely az összes webes alkalmazás által használt alapértelmezett protokoll. Ezért nincs szükség semmilyen testreszabásra ahhoz, hogy a SOAP protokollon alapuló webszolgáltatások a világhálón működjenek.
SZAPPAN építőkockák
A SOAP specifikációja úgy definiál valamit, mint „SZAPPAN üzenet„, amelyet a webszolgáltatásnak és a kliensalkalmazásnak küld a rendszer.
A SOAP architektúra alábbi diagramja a SOAP üzenetek különböző építőelemeit mutatja be.
A SOAP üzenet nem más, mint egy egyszerű XML dokumentum, amely az alábbi összetevőket tartalmazza.
- An Boríték elem, amely az XML dokumentumot SOAP üzenetként azonosítja – Ez a SOAP üzenet tartalmazó része, és a SOAP üzenet összes részletének beágyazására szolgál. Ez a SOAP üzenet gyökéreleme.
- A Fejléc fejlécinformációkat tartalmazó elem – A fejlécelem olyan információkat tartalmazhat, mint például a hívó alkalmazás által használható hitelesítő adatok. Tartalmazhatja a SOAP üzenetben használható összetett típusok definícióját is. Alapértelmezés szerint a SOAP üzenet tartalmazhat paramétereket, amelyek lehetnek egyszerű típusok, például karakterláncok és számok, de összetett objektumtípusok is lehetnek.
Egy egyszerű SOAP szolgáltatás példája egy összetett típusra látható alább. Tegyük fel, hogy egy strukturált adattípust szeretnénk küldeni, amely egy „Oktatóanyag neve” és egy „Oktatóanyag” kombinációját tartalmazza. Description”, akkor az összetett típust az alábbiak szerint definiálnánk. Az összetett típust az elemcímke definiálja A struktúra összes szükséges elemét a hozzájuk tartozó adattípusokkal együtt ezután az összetett típusgyűjteményben definiálják.
<xsd:complexType> <xsd:sequence> <xsd:element name="Tutorial Name" type="string"/> <xsd:element name="Tutorial Description" type="string"/> </xsd:sequence> </xsd:complexType>
A Test elem, amely hívási és válaszinformációkat tartalmaz – Ez az elem tartalmazza azokat a tényleges adatokat, amelyeket a webszolgáltatás és a hívó alkalmazás között el kell küldeni. Az alábbiakban egy SOAP webszolgáltatás példája látható a SOAP törzsre, amely ténylegesen a fejléc szakaszban definiált összetett típuson működik. Itt látható a Tutorial Name és a Tutorial válasza. Description, amelyet a hívó alkalmazásnak küldenek, amely meghívja ezt a webszolgáltatást.
<soap:Body> <GetTutorialInfo> <TutorialName>Web Services</TutorialName> <TutorialDescription>All about web services</TutorialDescription> </GetTutorialInfo> </soap:Body>
SOAP üzenetszerkezet
Egy dolog, amit meg kell jegyezni, hogy a SOAP üzeneteket általában automatikusan generálja a webszolgáltatás, amikor hívják.
Amikor egy kliens alkalmazás meghív egy metódust a webszolgáltatásban, a webszolgáltatás automatikusan generál egy SOAP üzenetet, amely tartalmazza a webszolgáltatásból az ügyfélalkalmazásnak elküldött adatok szükséges részleteit.
Amint azt a SOAP oktatóanyag előző témájában tárgyaltuk, egy egyszerű SOAP üzenet a következő elemekből áll:
- Az Envelope elem
- A fejléc elem, és
- A test elem
- A hiba elem (opcionális)
Nézzünk meg egy egyszerű SOAP üzenet példáját, és nézzük meg, hogy mit csinálnak az egyes elemek.

- Amint a fenti SOAP üzenetből látható, a SOAP üzenet első része a borítékelem, amely a teljes SOAP üzenet beágyazására szolgál.
- A következő elem a SOAP törzs, amely az aktuális üzenet részleteit tartalmazza.
- Üzenetünk egy webszolgáltatást tartalmaz, amelynek a neve „Guru99WebService”.
- AzGuruA „99Webservice” egy „int” típusú paramétert fogad el, és a neve TutorialID.
Most a fenti SOAP üzenetet továbbítja a webszolgáltatás és az ügyfélalkalmazás között.
Látható, mennyire hasznosak a fenti információk a kliensalkalmazás számára. A SOAP üzenet megmondja a kliensalkalmazásnak a webszolgáltatás nevét, valamint azt, hogy milyen paramétereket vár, és hogy milyen típusú paramétereket fogad el a webszolgáltatás.
SZAPPAN boríték elem
Az építőelem első része a SOAP Envelope.
A SOAP Envelope a webszolgáltatás és az ügyfélalkalmazás között cserélt SOAP üzenetek összes szükséges részletének beágyazására szolgál.
A SOAP boríték elem a SOAP üzenet kezdetének és végének jelzésére szolgál. Ez lehetővé teszi a webszolgáltatást hívó ügyfélalkalmazás számára, hogy tudja, mikor ér véget a SOAP üzenet.
A SOAP borítékelemen a következő pontok jegyezhetők fel.
- Minden SOAP üzenetnek kell lennie egy gyökér Envelope elemnek. Egy SOAP üzenet esetében abszolút kötelező, hogy legyen egy envelope elem.
- Minden borítékelemnek rendelkeznie kell legalább egy szappantest elemmel.
- Ha egy Envelope elem tartalmaz fejlécet, akkor az legfeljebb egyet tartalmazhat, és az Envelope első gyermekeként kell megjelennie a törzselem előtt.
- A boríték megváltozik a SOAP verzióinak változásával.
- Egy v1.1-kompatibilis SOAP processzor hibát generál, amikor a v1.2 boríték névterét tartalmazó üzenetet kap.
- A v1.2-kompatibilis SOAP-processzor Version Mismatch hibát generál, ha olyan üzenetet kap, amely nem tartalmazza a v1.2-es boríték névterét.
Az alábbiakban a SOAP boríték elem 1.2-es verziójának SOAP API példája látható.
<?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <Guru99WebService xmlns="http://tempuri.org/"> <TutorialID>int</TutorialID> </Guru99WebService> </soap:Body> </SOAP-ENV:Envelope>
A hibaüzenet
Amikor egy SOAP webszolgáltatáshoz kérés érkezik, a visszaadott válasz kétféle lehet: sikeres válasz vagy hibaüzenet. Sikeres válasz esetén a szerver válasza mindig SOAP üzenet lesz. Ha azonban SOAP hibák keletkeznek, akkor azokat „HTTP 500” hibaként adja vissza.
A SOAP hibaüzenet a következő elemekből áll.
- <faultCode> – Ez a kód jelöli a hiba kódját. A hibakód az alábbi értékek bármelyike lehet:
- SOAP-ENV:VersionMismatch – Ez az, amikor a SOAP Envelope elem érvénytelen névterét észleli.
- SOAP-ENV:MustUnderstand – A Fejléc elem közvetlen gyermekeleme, amelynek mustUnderstand attribútuma „1”-re van állítva, nem értelmezhető.
- SOAP-ENV:Client – Az üzenet hibásan lett kialakítva, vagy helytelen információkat tartalmazott.
- SOAP-ENV:Szerver – Probléma lépett fel a szerverrel, ezért az üzenet nem tudott továbbadni.
- – Ez az a szöveges üzenet, amely részletesen leírja a hibát.
- (Választható) – Ez egy szöveges karakterlánc, amely jelzi, hogy ki okozta a hibát.
- (Választható) – Ez az alkalmazás-specifikus hibaüzenetek eleme. Így az alkalmazásnak konkrét hibaüzenete lehet a különböző üzleti logikai forgatókönyvekhez.
Példa hibaüzenetre
Egy hibaüzenetre láthatunk egy példát. A hiba akkor keletkezik, amikor az ügyfél a GetTutorial osztály TutorialID nevű metódusát próbálja használni. Az alábbi hibaüzenet akkor keletkezik, ha a metódus nem létezik a definiált osztályban.
<?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode> <faultstring xsi:type="xsd:string"> Failed to locate method (GetTutorialID) in class (GetTutorial) </faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
output:
A fenti kód végrehajtásakor a következő hibaüzenet jelenik meg: „Nem sikerült megtalálni a (GetTutorialID) metódust a (GetTutorial) osztályban”.
SOAP kommunikációs modell
A SOAP minden kommunikációja a HTTP protokollon keresztül történik. A SOAP előtt sok webes szolgáltatások a szabványos RPC (Remote Procedure Call) stílust használta a kommunikációhoz. Ez volt a kommunikáció legegyszerűbb módja, de sok korlátja volt.
Ebben a SOAP API oktatóanyagban az alábbi ábrán keresztül mutatjuk be, hogyan működik ez a kommunikáció. Tegyük fel, hogy a szerver egy webszolgáltatást üzemeltet, amely két metódust biztosít:
- GetEmployee – Ez minden alkalmazotti adatot tartalmazna.
- SetEmployee – Ez ennek megfelelően beállítaná az olyan részletek értékét, mint az alkalmazott osztálya, fizetése stb.
A normál RPC stílusú kommunikációban a kliens csak meghívja a kérésében szereplő metódusokat, és elküldi a szükséges paramétereket a szervernek, majd a szerver elküldi a kívánt választ.
A fenti kommunikációs modellnek a következő komoly korlátai vannak:
- Nem Nyelvfüggetlen – A metódusokat tároló szerver egy adott programozási nyelven lenne, és általában a szerverhez irányuló hívások is csak ezen a programozási nyelven történnének.
- Nem a szabványos protokoll – Ha a távoli eljárást hívják, a hívás nem a szabványos protokollon keresztül történik. Ez azért volt probléma, mert az interneten keresztüli kommunikációt többnyire HTTP protokollon keresztül kellett végrehajtani.
- tűzfalak – Mivel az RPC hívások nem a normál protokollon keresztül mennek keresztül, külön portoknak kell nyitva lenniük a szerveren, hogy az ügyfél kommunikálhasson a szerverrel. Általában minden tűzfal blokkolja ezt a fajta forgalmat, és általában sok konfigurációra volt szükség ahhoz, hogy az ügyfél és a kiszolgáló közötti ilyen jellegű kommunikáció működjön.
A fent említett korlátozások leküzdésére a SOAP az alábbi kommunikációs modellt használná.
- Az ügyfél SOAP üzenetté formázta az eljáráshívással és az esetleges argumentumokkal kapcsolatos információkat, és HTTP kérés részeként elküldte a szervernek. Az adatok SOAP üzenetbe csomagolásának ezt a folyamatát ... néven ismerték. Rendezés.
- A szerver ezután kicsomagolja a kliens által küldött üzenetet, megnézi, mit kért a kliens, majd SOAP üzenetként visszaküldi a megfelelő választ a kliensnek. A kicsomagolás gyakorlataping Az ügyfél által küldött kérést úgy ismerjük, mint Demarshalling.
Gyakorlati SZAPPAN példa
Most ebben SoapUI A bemutatóban nézzünk egy gyakorlati SOAP példát. Valószínűleg az egyik legjobb módja annak, hogy bemutassuk, hogyan generálódnak a SOAP üzenetek, ha ténylegesen megnézünk egy webszolgáltatást működés közben.
Ez a témakör a Microsoft.Net keretrendszer egy ASMX webszolgáltatás felépítéséhez. Ez a típusú webszolgáltatás támogatja a SOAP 1.1-es és 1.2-es verzióját is.
Az ASMX webszolgáltatások automatikusan generálják a Webszolgáltatás-definíciós nyelv (WSDL) dokumentum. Ezt a WSDL-dokumentumot a hívó ügyfélalkalmazásnak szüksége van ahhoz, hogy az alkalmazás tudja, mire képes a webszolgáltatás.
A példánkban egy egyszerű webszolgáltatást fogunk létrehozni, amely egy karakterláncot ad vissza a webszolgáltatást meghívó alkalmazásnak. Ez a webszolgáltatás egy Asp.Net webalkalmazás. Ezután meghívjuk a webszolgáltatást, és látni fogjuk a webszolgáltatás által visszaadott eredményt.
A Visual Studio azt is megmutatja, hogy milyen SOAP üzenetet továbbítanak a webszolgáltatás és a hívó alkalmazás között. A webszolgáltatás-alkalmazás beállításának első előfeltétele az alábbi lépések követése. Kérjük, győződjön meg arról, hogy a Visual Studio 2013 telepítve van a rendszerén ehhez a példához.
Step 1) Az első lépés egy üres ASP.Net webalkalmazás létrehozása. A Visual Studio 2013-ban kattintson a Fájl->Új projekt menüpontra.
Miután rákattint az Új projekt lehetőségre, a Visual Studio egy másik párbeszédablakot ad a projekt típusának kiválasztásához és a projekt szükséges részleteinek megadásához. Ezt a következő lépésben ismertetjük.
Step 2) Ebben a lépésben a
- Először mindenképpen válassza ki a C# ASP.NET webes alkalmazás websablonja. A projektnek ilyen típusúnak kell lennie ahhoz, hogy SOAP szolgáltatásprojektet hozzon létre. Ennek a lehetőségnek a kiválasztásával a Visual Studio elvégzi a szükséges lépéseket a webes alkalmazásokhoz szükséges fájlok hozzáadásához.
- Adj nevet a projektednek, ami esetünkben webservice.asmx néven szerepel. Ezután add meg a projektfájlok tárolási helyét.
Ha kész, a létrehozott projektfájl a Visual Studio 2013 megoldáskezelőjében jelenik meg.
Step 3) Ebben a lépésben egy webszolgáltatás-fájlt fogunk hozzáadni a projektünkhöz.
- Először kattintson jobb gombbal a projektfájlra az alábbiak szerint.
- Miután jobb gombbal kattintott a projektfájlra, kiválaszthatja a „Hozzáadás->Webszolgáltatás (ASMX)” lehetőséget egy webszolgáltatásfájl hozzáadásához. Ehhez adjon meg egy „Oktatóanyag szolgáltatás” nevet a webszolgáltatásfájl névének.
Step 4) Adja hozzá a következő kódot a Tutorial Service asmx fájljához.
Code Magyarázat:
- Ez a kódsor nevet ad a webszolgáltatási fájlnak. Ez azért fontos lépés, mert lehetővé teszi az ügyfélalkalmazás számára, hogy a webszolgáltatás nevén keresztül hívja a webszolgáltatást.
- Általában egy osztályfájlt használnak a webszolgáltatás funkcióinak beágyazására. Tehát az osztályfájl tartalmazza az összes webes metódus definícióját, amely bizonyos funkciókat biztosít az ügyfélalkalmazás számára.
- Itt a [WebMethod] egy függvényt leíró attribútumként ismert. A következő lépés egy „Guru99WebService”, de a [WebMethod] attribútum hozzáadásának lépésével biztosítható, hogy ezt a metódust egy kliensalkalmazás meghívhassa. Ha ez az attribútum nincs a helyén, akkor a metódust soha nem tudja meghívni egy kliensalkalmazás.
- Itt definiálunk egy függvényt, melynek neve: 'Guru99WebService' függvény, amely egy karakterlánc visszaadására szolgál a hívó kliensalkalmazásnak. Ez a függvény egy webszolgáltatás, amelyet bármely kliensalkalmazás meghívhat.
- A return utasítást használjuk a „This is a Guru99 Web szolgáltatás” a kliensalkalmazásnak.
Ha a kód sikeresen lefut, a következő kimenet jelenik meg, amikor futtatja a kódot a böngészőben.
output:
- A kimenet egyértelműen mutatja, hogy webszolgáltatásunk neve „Guru99 Web Service”, ami a webszolgáltatásunk elnevezésének eredménye.
- Azt is láthatjuk, hogy meghívhatjuk a webszolgáltatást. Ha a Meghívás gombra kattintunk, az alábbi választ kapjuk a webböngészőben.
A fenti kimenet:
- Ez egyértelműen mutatja, hogy a web metódus meghívásával a „This is a Guru99 Web service” üzenetet ad vissza.
- A Visual Studio lehetővé teszi a SOAP-üzenetkérelem és -válasz megtekintését is, amely a fenti webszolgáltatás meghívásakor jön létre.
Az alábbiakban látható a SOAP-kérelem, amely a webszolgáltatás hívásakor jön létre.
Code Magyarázat:
- A SOAP üzenet első része a boríték elem, amelyet az előző fejezetekben tárgyaltunk. Ez a beágyazó elem, amely minden SOAP üzenetben megtalálható.
- A SOAP törzs a következő elem, és a SOAP üzenet tényleges részleteit tartalmazza.
- A harmadik rész az az elem, amely meghatározza, hogy meg akarjuk hívni a ' nevű szolgáltatást.Guru99WebService'.
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <Guru99WebServiceResponse xmlns="http://tempuri.org/"> <Guru99WebServiceResult>string</Guru99WebServiceResult> </Guru99WebServiceResponse> </soap:Body> </soap:Envelope>
Code Magyarázat:
- A SOAP üzenet első része a boríték elem, amelyet az előző fejezetekben tárgyaltunk. Ez a beágyazó elem, amely minden SOAP üzenetben megtalálható.
- A SOAP törzs a következő elem, és a SOAP üzenet tényleges részleteit tartalmazza.
- Az érdekes rész, amit most látni fogsz, a 'string' attribútum. Ez jelzi a kliensalkalmazásnak, hogy a meghívott webszolgáltatás egy string típusú objektumot ad vissza. Ez nagyon hasznos, mert különben a kliensalkalmazás nem tudná, hogy mit ad vissza a webszolgáltatás.














