Ugrás a tartalomhoz

SOAP

Ellenőrzött
A Wikipédiából, a szabad enciklopédiából
SOAP struktúra

A számítástechnikában a SOAP (Simple Object Access Protocol) egy protokoll, amelyet webszolgáltatások hálózaton keresztüli kommunikációjához terveztek. Az üzenetek XML-alapúak és általában más, alkalmazás rétegbeli protokollokra támaszkodva továbbítódnak, például Távoli Eljáráshívás (Remote Procedure Call, RPC) vagy a Hypertext Transport Protocoll (HTTP) protokollokra.

Egy példa arra, hogy működnek a SOAP eljárások. Egy SOAP üzenetet küldhetünk egy webszolgáltatással rendelkező weboldalnak, pl. egy ingatlanügynökségnek, melyben megadjuk a keresési paramétereket. Az oldal egy XML dokumentumot küld vissza a kért adatokkal, pl. az ingatlanok árai, helye, tulajdonságai. Mivel ez az adat a gépek számára könnyen feldolgozható formátumban van, így egyszerűen integrálható egy weboldalba vagy alkalmazásba.

A SOAP architektúra több réteget specifikál: üzenetformátumot (MessageExchangePatterns, MEP), az alatta lévő szállítási protokollt, az üzenetfeldolgozó modellt és a protokoll bővíthetőségét. A SOAP az XML-RPC örökösének tekinthető.

Története

[szerkesztés]

A SOAP a WSDL és a UDDI mellett a webszolgáltatások harmadik alapvető elemét képezi. A név eredetileg az angol Simple Object Access Protocol rövidítése volt, de a szabvány 1.2-es verziójától kezdve a Simple Object Access Protocol nevet már nem használják, mert az elnevezés félrevezető volt. A SOAP szabványt a W3C tartja karban.

A SOAP szabványt eredetileg Dave Winer, Don Box, Bob Atkinson, és Mohsen Al-Ghosein tervezték 1998-ban (egy Microsoft projekt keretein belül), mint egy objektum-elérési protokollt.

Specifikáció

[szerkesztés]

A SOAP által specifikált üzenetküldő keretrendszer az alábbi részekből áll:

  • A SOAP feldolgozási modell, ami leírja, hogy kell feldolgozni a SOAP üzeneteket
  • A SOAP bővíthetőségi modell, mely meghatározza a SOAP modulok és tulajdonságok koncepcióját
  • A SOAP alsóbb protokollhoz csatlakozó keretrendszer szabályokat definiál arra vonatkozóan, hogy kell csatlakozni egy alsóbb réteghez, hogy SOAP üzeneteket tudjunk továbbítani
  • A SOAP üzenetszerkezet definiálja, hogy kell felépíteni egy SOAP üzenetet

Feldolgozási modell

[szerkesztés]

A SOAP feldolgozási modell egy elosztott feldolgozási modellt definiál a résztvevői, a SOAP csomópontok számára, valamint azt, hogy hogy dolgozza fel a fogadó az üzenetet. A következő SOAP csomópont típusok lehetnek:

  • SOAP küldő

Egy csomópont, ami üzenetet küld

  • SOAP fogadó

Egy csomópont, ami üzeneteket fogad

  • SOAP üzenet útvonal

Csomópontok egy halmaza, melyeken egy üzenet áthalad

  • Kezdeti SOAP küldő

Az a csomópont, ahonnan az üzenet útvonala elindult

  • SOAP közvetítő

Egy olyan csomópont, amely küld és fogad is üzeneteket. Feldolgozza a beérkezett üzenetet és továbbítja a végső cél felé.

  • Végső SOAP fogadó

Egy olyan SOAP fogadó, mely a SOAP üzenet célpontja. Ennek a feladata az üzenet törzsének a feldolgozása. Bizonyos körülmények között előfordulhat, hogy a SOAP üzenet nem éri el a végső fogadót, például egy SOAP közvetítőnél felmerült probléma miatt. Egy végső SOAP fogadó nem lehet közvetítő is egy adott üzenet esetén.

Továbbítási eljárások

[szerkesztés]

Mind a HTTP, mind pedig az SMTP lehetséges szállítási protokollok SOAP üzenetek továbbítására, ugyanakkor a HTTP szélesebb körben elfogadott, mivel jól együttműködik az internet mai szerkezetével, különösen jól működik együtt a HTTP a tűzfalakkal. A SOAP ugyanakkor továbbítható HTTPS protokollon keresztül is.

Ez az előnye a többi elosztott protokollal szemben, úgy mint a GIOP/IIOP vagy a DCOM, amiket kiszűrnek a tűzfalak.

Üzenetformátum

[szerkesztés]

Az XML formátumra esett a választás, mint standard üzenetformátum, mivel széles körben használt a nagyvállalatoknál és a nyílt forrású fejlesztéseknél. Ezen kívül rengeteg szabadon elérhető eszköz segíti a SOAP alapú megoldásra való áttérést. Az XML szintaxisa lehet előny és hátrány is egyszerre. Az emberi szem számára könnyen olvasható, könnyebb a hibadetektálás és áthidalja az együttműködési problémákat (pl. endianizmus), emellett viszont lassan és nehezen feldolgozható. Pl. a CORBA egy sokkal egyszerűbb és rövidebb bináris üzenetformátumot használ. Másrészről viszont lehetőség van szoftveresen felgyorsítani az XML feldolgozást.

Példa

[szerkesztés]
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 299

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
  </soap:Header>
  <soap:Body>
    <m:GetStockPrice xmlns:m="http://www.example.org/stock">
      <m:StockName>IBM</m:StockName>
    </m:GetStockPrice>
  </soap:Body>
</soap:Envelope>

Előnyök és hátrányok

[szerkesztés]

Előnyök

[szerkesztés]
  • A SOAP elég sokoldalú, így különböző szállítási protokollokon keresztül is kommunikálhatunk vele. A szabvány szerint HTTP-t használnak, de működik SMTP-vel vagy JMS-sel is.
  • Mivel a SOAP jól összefér a HTTP kérés/válasz modelljével, könnyedén átjut a tűzfalakon és proxykon anélkül, hogy a SOAP protokollt módosítani kellene.

Hátrányok

[szerkesztés]
  • Az XML bőbeszédű formátuma miatt a SOAP lassabb lehet, mint mondjuk a CORBA üzenetküldési modellje. Ez nem okozhat problémát kis méretű üzenetek estén.
  • Ha a HTTP-re támaszkodunk mint szállítási protokoll, és nem használjuk a WS-Addressing vagy ESB-t, a kommunikáló felek szerepei rögzítettek. Csak az egyik fél (kliens) használhatja a másik fél szolgáltatásait.

Források

[szerkesztés]