SOAP webszolgáltatások oktatóanyag: Mi a SOAP protokoll? PÉLDA

Mi a SOAP?

A SOAP egy XML-alapú protokoll a webes szolgáltatások HTTP-n keresztüli elérésére. Van néhány specifikációja, amely minden alkalmazásban használható.

A SOAP az egyszerű objektum-hozzáférési protokoll néven ismert, de a későbbi időkben csak rövidítették SOAP v1.2-re. A SOAP egy protokoll, más szóval annak meghatározása, hogy a webszolgáltatások hogyan beszélnek egymással vagy az őket meghívó ügyfélalkalmazásokkal.

A SOAP köztes nyelvként lett kifejlesztve, 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.

Ebben a SOAP webszolgáltatások oktatóanyagban megismerheti

• SOAP Bevezetés
• A SOAP előnyei
• SOAP Építőelemek
• SOAP üzenet felépítése
• SOAP boríték elem
• SOAP kommunikációs modell
• Gyakorlati SOAP példa

SOAP Bevezetés

A mai világban rengeteg alkalmazás van, amelyek különböző programozási nyelvekre épülnek. Lehet például egy Java alkalmazásban tervezett webalkalmazás, egy másik a .Net-ben és egy másik a PHP-ben.

Az alkalmazások közötti adatcsere kulcsfontosságú a mai hálózatban. De a heterogén alkalmazások közötti adatcsere bonyolult lenne. Így lesz ez a kód összetettsége az adatcsere megvalósításához.

A bonyolultság leküzdésére az egyik módszer az XML (Extensible Markup Language) használata, mint az alkalmazások közötti adatcsere közbenső nyelve.

Minden programozási nyelv megérti az XML jelölőnyelvet. Ezért az XML-t használták az adatcsere alapjául szolgáló közegként.

De nincsenek szabványos előírások az XML használatára az összes programozási nyelven az adatcseréhez. Itt jön be a SOAP szoftver.

A SOAP-t úgy tervezték, hogy az XML-en keresztül HTTP-n keresztül működjön, és valamilyen specifikációval rendelkezik, amelyet minden alkalmazásban fel lehet használni. A SOAP protokoll további részleteit a következő fejezetekben vizsgáljuk meg.

A SOAP előnyei

A SOAP az alkalmazások közötti adatcseréhez használt protokoll. Az alábbiakban bemutatjuk a SOAP használatának néhány okát.

• A SOAP alapú webszolgáltatások fejlesztésekor rendelkeznie kell olyan nyelvvel, amelyet a webszolgáltatásokhoz használhat az ügyfélalkalmazásokkal való beszélgetéshez. A SOAP a tökéletes közeg, amelyet e cél elérése érdekében 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. Vegye figyelembe a „ light ” kulcsszót . Mivel a SOAP programozás az XML nyelvre épül, amely maga is könnyű adatcsere-nyelv, ezért a SOAP mint protokoll, amely szintén ugyanabba a kategóriába tartozik.
• A SOAP platformfüggetlen, és operációs rendszertől független is. Tehát a SOAP protokoll bármilyen programozási nyelv alapú alkalmazást képes használni mind a Windows, mind a Linux platformon.
• Működik a HTTP protokollon - A SOAP a HTTP protokollon működik, amely az összes webalkalmazás alapértelmezett protokollja. Ennélfogva nincs szükség a SOAP protokollra épülő webszolgáltatások futtatásához a világhálón történő működéséhez.

SOAP Építőelemek

A SOAP specifikáció meghatározza az úgynevezett " SOAP üzenetet ", amelyet elküld a webszolgáltatásnak és az ügyfélalkalmazásnak.

A SOAP architektúra alábbi diagramja bemutatja a SOAP üzenet különböző építőelemeit.

A SOAP üzenet nem más, mint puszta XML dokumentum, amely az alábbi összetevőket tartalmazza.

• Boríték elem, amely az XML dokumentumot SOAP üzenetként azonosítja - Ez a SOAP üzenet részét képezi, és a SOAP üzenet minden részletének beágyazására szolgál. Ez a gyökérelem a SOAP üzenetben.
• Fejléc-információt tartalmazó fejléc-elem - A fejléc-elem tartalmazhat olyan információkat, mint például a hitelesítési hitelesítő adatok, amelyeket a hívó alkalmazás használhat. Tartalmazhatja a SOAP üzenetben felhasználható összetett típusok meghatározását is. Alapértelmezés szerint a SOAP üzenet tartalmazhat olyan paramétereket, amelyek egyszerű típusúak lehetnek, például karaktersorozatok és számok, de lehetnek összetett objektumtípusok is.

Az alábbiakban egy összetett típusú egyszerű SOAP szolgáltatási példa látható.

Tegyük fel, hogy strukturált adattípust akartunk elküldeni, amely tartalmazta egy "oktatóanyag neve" és egy "oktatóanyag leírása" kombinációját, majd megadjuk az összetett típust az alábbiak szerint.

A komplex típust az elem tag határozza meg. Ezután a komplex típusgyűjteményben meghatározzuk a struktúra összes szükséges elemét és a megfelelő adattípusokat.

• Body elem, amely hívás- és válaszinformációt tartalmaz - Ez az elem tartalmazza azokat a tényleges adatokat, amelyeket el kell küldeni a webszolgáltatás és a hívó alkalmazás között. Az alábbiakban bemutatunk egy SOAP webszolgáltatási példát a SOAP törzsre, amely valójában a fejléc szakaszban meghatározott komplex típuson működik. Itt található az oktatóanyag neve és az oktatóanyag leírása, amelyet elküld a hívó alkalmazásnak, amely felhívja ezt a webszolgáltatást.

Web ServicesAll about web services

SOAP üzenet felépítése

Egy dolgot meg kell jegyezni, hogy a SOAP üzeneteket általában a webszolgáltatás automatikusan generálja, amikor hívják.

Amikor egy ügyfélalkalmazás meghív egy módszert a webszolgáltatásban, a webszolgáltatás automatikusan létrehoz egy SOAP üzenetet, amely tartalmazza a szükséges adatokat a webszolgáltatásból az ügyfélalkalmazáshoz.

Amint azt a SOAP oktatóanyag előző témájában már említettük, egy egyszerű SOAP üzenet a következő elemeket tartalmazza:

• A Boríték elem
• A fejléc elem és
• A test elem
• A Hiba elem (opcionális)

Nézzünk meg egy egyszerű SOAP-üzenet alábbi példáját, és nézzük meg, mi az elem valójában.

1. A fenti SOAP üzenetből kitűnik, hogy a SOAP üzenet első része a boríték elem, amelyet a teljes SOAP üzenet beágyazására használnak.
2. A következő elem a SOAP törzs, amely az aktuális üzenet részleteit tartalmazza.
3. Üzenetünk egy webszolgáltatást tartalmaz, amelynek neve "Guru99WebService".
4. A "Guru99Webservice" elfogadja az "int" típusú paramétert, és a TutorialID nevet viseli.

Most a fenti SOAP üzenet továbbításra kerül a webszolgáltatás és az ügyfélalkalmazás között.

Láthatja, hogy a fenti információk mennyire hasznosak az ügyfélalkalmazás számára. A SOAP üzenet megmondja az ügyfélalkalmazásnak, mi a webszolgáltatás neve, és milyen paraméterekre számít, valamint azt is, hogy milyen típusúak a webszolgáltatás által vett egyes paraméterek.

SOAP boríték elem

Az építőelem első bitje a SOAP boríték.

A SOAP borítékot a webszolgáltatás és az ügyfélalkalmazás között kicserélt SOAP-üzenetek összes szükséges adatának összefoglalására használják.

A SOAP boríték elem a SOAP üzenet kezdetének és végének jelzésére szolgál. Ez lehetővé teszi, hogy a webszolgáltatást hívó ügyfélalkalmazás megtudja, mikor fejeződik be a SOAP üzenet.

A következő pontokat lehet megjegyezni a SOAP boríték elemen.

• Minden SOAP üzenetnek tartalmaznia kell egy gyökér boríték elemet. A SOAP üzenetnek feltétlenül kötelező boríték eleme lennie.
• Minden borítékelemnek rendelkeznie kell legalább egy szappantestelemmel.
• Ha egy boríték elem tartalmaz fejléc elemet, akkor legfeljebb egyet tartalmazhat, és a boríték első gyermekeként kell megjelennie a törzs elem előtt.
• A boríték akkor változik, amikor a SOAP verziók változnak.
• A v1.1-kompatibilis SOAP processzor hibát generál, amikor egy v1.2 boríték névteret tartalmazó üzenetet kap.
• A v1.2-kompatibilis SOAP processzor Verzió-eltérés hibát generál, ha olyan üzenetet kap, amely nem tartalmazza a v1.2 boríték névterét.

Az alábbiakban bemutatjuk a SOAP API példáját a SOAP boríték elem 1.2 verziójára.

int

A Hiba üzenet

Amikor egy SOAP webszolgáltatáshoz kérelmet nyújtanak be, a visszaküldött válasz kétféle lehet, amelyek sikeresek vagy hibásak. Ha siker jön létre, a szerver válasza mindig SOAP üzenet lesz. De ha SOAP hibák keletkeznek, akkor "HTTP 500" hibaként kerülnek visszaadásra.

A SOAP Fault üzenet a következő elemekből áll.

1. - Ez a kód jelöli a hiba kódját. A hibakód bármelyik alábbi érték lehet
   1. SOAP-ENV: VersionMismatch - Ilyenkor a SOAP Envelope elem érvénytelen névteret talál.
   2. SOAP-ENV: MustUnderstand - A Header elem azonnali gyermek elemét nem értették, a mustUnderstand attribútum értéke "1".
   3. SOAP-ENV: Ügyfél - Az üzenet hibásan lett kialakítva, vagy helytelen információkat tartalmazott.
   4. SOAP-ENV: Szerver - Hiba történt a szerverrel, ezért az üzenet nem tudott tovább haladni.
2. - Ez az a szöveges üzenet, amely részletesen leírja a hibát.
3. (Opcionális) - Ez egy szöveges karakterlánc, amely jelzi, hogy ki okozta a hibát.
4. (Opcionális) - Ez az alkalmazásspecifikus hibaüzenetek eleme. Tehát az alkalmazásnak külön hibaüzenete lehet a különféle üzleti logikai forgatókönyvekhez.

Példa a hibaüzenetre

Az alábbiakban egy hibaüzenetet mutatunk be. A hiba akkor keletkezik, ha az a forgatókönyv, amelyben az ügyfél megpróbálja a TutorialID nevű módszert használni a GetTutorial osztályban.

Az alábbi hibaüzenet akkor generálódik, ha a módszer nem létezik a megadott osztályban.

SOAP-ENV:ClientFailed to locate method (GetTutorialID) in class (GetTutorial)

Kimenet:

Amikor végrehajtja a fenti kódot, megjelenik a következő hiba: "Nem sikerült megtalálni a metódust (GetTutorialID) az osztályban (GetTutorial)"

SOAP kommunikációs modell

A SOAP-on keresztüli minden kommunikáció a HTTP protokollon keresztül történik. A SOAP előtt sok webszolgáltatás a szokásos RPC (Remote Procedure Call) stílust használta a kommunikációhoz. Ez volt a legegyszerűbb típusú kommunikáció, de sok korlátja volt.

Most ebben a SOAP API oktatóanyagban vegyük figyelembe az alábbi diagramot, hogy lássuk, hogyan működik ez a kommunikáció. Tegyük fel, hogy ebben a példában a kiszolgáló egy webszolgáltatást üzemeltet, amely 2 metódust biztosított

• GetEmployee - Ezzel megkapja az alkalmazottak összes részletét
• SetEmployee - Ennek megfelelően állítja be a részletek értékét, például az alkalmazottak részlegét, fizetését stb.

A normál RPC stílusú kommunikáció során az ügyfél csak meghívja a kérésében szereplő módszereket, és elküldi a szükséges paramétereket a kiszolgálónak, majd a szerver elküldi a kívánt választ.

A fenti kommunikációs modell az alábbi komoly korlátokkal rendelkezik

1. Nem nyelvfüggetlen - A módszereket tároló szerver egy adott programozási nyelven zajlik, és általában a szerverre irányuló hívások csak az adott programozási nyelven zajlanak.
2. Nem a szokásos protokoll - Ha hívást kezdeményeznek a távoli eljárásra, a hívás nem a szabványos protokollon keresztül történik. Ez problémát jelentett, mivel többnyire az egész webes kommunikációt a HTTP protokollon keresztül kellett lebonyolítani.
3. Tűzfalak - Mivel az RPC hívások nem a normál protokollon mennek keresztül, külön portokat kell nyitni a szerveren, hogy az ügyfél kommunikálhasson a szerverrel. Normális esetben az összes tűzfal blokkolja az ilyen típusú forgalmat, és általában sok konfigurációra volt szükség annak biztosításához, hogy az ilyen típusú kommunikáció működjön az ügyfél és a szerver között.

Az összes fent említett korlát leküzdésére a SOAP az alábbi kommunikációs modellt használja

1. Az ügyfél az eljáráshívással és az esetleges argumentumokkal kapcsolatos információkat SOAP-üzenetbe formázza, és HTTP-kérés részeként elküldi a szervernek. Az adatok SOAP üzenetbe foglalásának ezt a folyamatát Marshalling néven ismerték .
2. Ezután a szerver kibontja az ügyfél által küldött üzenetet, megnézi, hogy mit kért az ügyfél, majd SOAP üzenetként visszaküldte a megfelelő választ az ügyfélnek. Az ügyfél által küldött kérés kibontásának gyakorlata Demarshalling néven ismert .

Gyakorlati SOAP példa

Most ebben a SoapUI oktatóanyagban nézzünk meg egy gyakorlati SOAP példát,

Valószínűleg az egyik legjobb módszer a SOAP-üzenetek létrehozásának megtekintésére, ha egy webszolgáltatást valóban működés közben látunk.

Ez a témakör a Microsoft.Net keretrendszer használatát vizsgálja az ASMX webszolgáltatás felépítéséhez. Ez a típusú webszolgáltatás támogatja a SOAP 1.1 és 1.2 verzióit is.

Az ASMX webszolgáltatások automatikusan létrehozzák a Web Service Definition Language (WSDL) dokumentumot. Ezt a WSDL dokumentumot a hívó kliens alkalmazás igényli, hogy az alkalmazás tudja, mire képes a webszolgáltatás.

Példánkban egy egyszerű webszolgáltatást fogunk létrehozni, amelyet egy karakterlánc visszaadásához fogunk használni a webszolgáltatást hívó alkalmazáshoz.

Ezt a webszolgáltatást egy Asp.Net webalkalmazás tárolja. Ezután meghívjuk a webszolgáltatást, és megnézzük az eredményt, amelyet a webszolgáltatás visszaad.

A Visual Studio megmutatja azt is, 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ának első előfeltétele, amelyet az alábbi lépések követésével lehet megtenni.

Kérjük, ellenőrizze, hogy a Visual Studio 2013 telepítve van-e a rendszerére ehhez a példához.

1. lépés: Az első lépés egy üres ASP.Net webalkalmazás létrehozása. A Visual Studio 2013 alkalmazásban kattintson a Fájl-> Új projekt menüpontra.

Miután rákattint az Új projekt opcióra, a Visual Studio megad egy újabb párbeszédpanelt 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 magyarázzuk.

2. lépés) Ebben a lépésben

1. Először válassza ki az ASP.NET webalkalmazás C # websablonját. A projektnek ilyen típusúnak kell lennie a SOAP szolgáltatási projekt létrehozásához. Ennek a lehetőségnek a kiválasztásával a Visual Studio elvégzi a szükséges lépéseket a szükséges fájlok hozzáadásához, amelyekre bármely webalapú alkalmazás szükséges.
2. Adjon nevet a projektjének, amelyet esetünkben webservice.asmx néven kaptunk. Ezután adjon meg egy helyet, ahol a projektfájlok tárolódnak.

Ha elkészült, látni fogja a Visual Studio 2013-ban a megoldásfelfedezőben létrehozott projektfájlt.

3. lépés) Ebben a lépésben

Webprojekt fájlt fogunk hozzáadni a projektünkhöz

1. Először kattintson jobb gombbal a projektfájlra az alábbiak szerint

2. Miután a jobb egérgombbal rákattint a projektfájlra, lehetősége van kiválasztani az "Add-> Web Service (ASMX)" lehetőséget egy webszolgáltatási fájl hozzáadásához. Csak adja meg a Tutorial Service nevet a webszolgáltatás névfájljához.

4. lépés: Adja hozzá a következő kódot az Oktatószolgáltatás asmx fájljához.

Kód Magyarázat:

1. Ez a kódsor megadja a webszolgáltatási fájl nevét. Ez azért fontos lépés, mert utat enged az ügyfélalkalmazásnak a webszolgáltatás hívására a webszolgáltatás nevén keresztül.
2. Normál esetben egy osztályfájlt használnak a webszolgáltatás funkcióinak beágyazására. Tehát az osztályfájl meghatározza az összes webes módszert, amely bizonyos funkciókat biztosít az ügyfélalkalmazás számára.
3. Itt a [WebMethod] attribútumként ismert, amely leír egy függvényt. A következő lépés létrehozza a "Guru99WebService" nevű függvényt, de a [WebMethod] attribútum hozzáadásának ezen lépésével a felhasználó biztosíthatja, hogy ezt a módszert meghívhatja egy ügyfélalkalmazás. Ha ez az attribútum nincs a helyén, akkor a módszert soha nem tudja meghívni egy kliens alkalmazás.
4. Itt definiálunk egy 'Guru99WebService' nevű függvényt, amely egy karakterlánc visszaadására szolgál a hívó kliens alkalmazás számára. Ez a funkció egy webes szolgáltatás, amelyet bármely kliens alkalmazás meghívhat.
5. A return utasítással visszaküldjük az "Ez egy Guru99 webszolgáltatás" karakterláncot az ügyfélalkalmazáshoz.

A kód sikeres végrehajtása esetén a következő kimenet jelenik meg, amikor a böngészőben futtatja a kódot.

Kimenet:

• A kimenet világosan mutatja, hogy webszolgáltatásunk neve "Guru99 Web Service", ami annak eredménye, hogy nevet adunk webszolgáltatásunknak.
• Azt is láthatjuk, hogy meg tudjuk hívni a webszolgáltatást. Ha rákattintunk az Invoke gombra, az alábbi választ kapjuk a webböngészőben.

A fenti kimenet,

• Világosan mutatja, hogy a webes módszer meghívásával az "Ez egy Guru99 webszolgáltatás" karakterlánc kerül visszaadásra.
• A Visual Studio lehetővé teszi a SOAP üzenet kérésének és válaszának megtekintését is, amely a fenti webszolgáltatás hívásakor jön létre.

A webszolgáltatás hívásakor létrehozott SOAP kérés az alábbiakban látható.

Kód Magyarázat:

1. A SOAP üzenet első része a boríték elem, amelyet az előző fejezetekben tárgyaltunk. Ez az a kapszulázó elem, amely minden SOAP üzenetben megtalálható.
2. A SOAP Body a következő elem, és tartalmazza a SOAP üzenet tényleges részleteit.
3. A harmadik rész az az elem, amely meghatározza, hogy a "Guru99WebService" nevű szolgáltatást szeretnénk hívni.

string

Kód Magyarázat:

1. A SOAP üzenet első része a boríték elem, amelyet az előző fejezetekben tárgyaltunk. Ez az a kapszulázó elem, amely minden SOAP üzenetben megtalálható.
2. A SOAP Body a következő elem, és tartalmazza a SOAP üzenet tényleges részleteit.
3. A most érdekes rész a 'string' attribútum. Ez azt mondja az ügyfélalkalmazásnak, hogy a hívott webszolgáltatás egy string típusú objektumot ad vissza. Ez nagyon hasznos, mert ha az ügyfélalkalmazás, amely egyébként nem tudná, mit ad vissza a webszolgáltatás.

Összegzés

• A SOAP egy olyan protokoll, amelyet adatcserére használnak a különböző programozási nyelvekre épülő alkalmazások között.
• A SOAP az XML specifikációra épül, és a HTTP protokollal működik. Így tökéletes a webalkalmazásokon belüli használatra.
• A SOAP építőelemek egy SOAP üzenetből állnak. Minden SOAP üzenet boríték elemből, fejlécből és törzs elemből áll.
• A boríték elem a kötelező elem a SOAP üzenetben, és a SOAP üzenet összes adatának beágyazására szolgál.
• A fejléc elem felhasználható információk, például hitelesítési információk vagy összetett adattípusok meghatározására.
• A törzs elem az a fő elem, amely tartalmazza a webes módszerek meghatározását, és szükség esetén a paraméterekkel kapcsolatos információkat.