close

Simple Object Access Protocol

Siirry navigointiin Siirry hakuun
Image
SOAP-viestin rakenne

SOAP (alunperin lyhenne sanoista Simple Object Access Protocol ) on standardiprotokolla , joka määrittää, kuinka kaksi objektia eri prosesseissa voivat kommunikoida vaihtamalla XML -tietoja . Tämä protokolla on peräisin Dave Winerin vuonna 1998 luomasta protokollasta nimeltä XML-RPC . SOAPin ovat luoneet Microsoft , IBM ja muut. Se on tällä hetkellä W3C :n suojeluksessa . Se on yksi verkkopalveluissa käytetyistä protokollista .

Ominaisuudet

SOAP on yksisuuntainen tilaton viestintäparadigma , jonka avulla voidaan muodostaa täydellisempiä ja monimutkaisempia protokollia sen toteuttavien sovellusten tarpeista riippuen. Se voi muodostaa ja rakentaa "verkkopalveluprotokollapinon" peruskerroksen , joka tarjoaa perusviestintäkehyksen, jolle verkkopalveluita voidaan rakentaa. Tämä protokolla perustuu XML:ään ja koostuu kolmesta osasta:

  • Kirjekuori : joka määrittää, mitä viestissä on ja kuinka se käsitellään.
  • Joukko koodaussääntöjä tietotyyppien esiintymien ilmaisemiseen.
  • Yleissopimus edustaa kehotuksia menettelyihin ja vastauksiin.

SOAP-protokollalla on kolme pääominaisuutta:

  • Laajennettavuus (turvallisuus ja WS-reititys ovat kehitystyössä käytettyjä laajennuksia).
  • Neutraalisuus (siirtoprotokollan alla TCP : tä voidaan käyttää minkä tahansa sovellusprotokollan, kuten HTTP , SMTP tai JMS , yli ).
  • Riippumattomuus (sallii minkä tahansa ohjelmointimallin).

Esimerkkinä siitä, miten SOAP-mallia voidaan käyttää, tarkastellaan SOAP-sanomaa, joka voitaisiin lähettää verkkopalveluun hakemaan hintaa tietokannasta ja ilmoittamaan kyselyssä tarvittavat parametrit. Palvelu voisi palauttaa XML-muotoisen dokumentin tuloksen, esimerkin, hinnat, sijainnin tai ominaisuuksien kera. Koska vastaustiedot ovat standardoidussa jäsennettävässä muodossa, ne voidaan integroida suoraan Web-sivustoon tai ulkoiseen sovellukseen.

SOAP-arkkitehtuuri koostuu useista erittelykerroksista: MEP ( Message Exchange Patterns ) viestimuodolle, taustalla olevat siirtoprotokollasidokset, viestien käsittelymalli ja protokollan laajennettavuuskerros. SOAP on XML-RPC : n seuraaja , vaikka se lainaa muista malleista (luultavasti WDDX :stä) kuljetus- ja vuorovaikutusneutraalisuuden sekä kirjekuoren / otsikon / tekstin .

Historia

Huoli hajautetuista järjestelmistä ja siitä, miten eri koneet voivat kommunikoida keskenään, nousi esiin 1990-luvulla. Siihen asti riitti, että saman tietokoneen sovellukset pystyivät kommunikoimaan.

Vuonna 1990 COM- ja CORBA - mallit syntyivät . Ensimmäisen, Component Object Modelin, loi Microsoft ja toisen, CORBA, Object Management Group. Näillä kahdella mallilla oli kuitenkin erittäin tärkeä vaikeus: ne eivät olleet helposti yhteentoimivia, koska kahden viestintäkoneen oli tuettava COM- tai CORBA-tekniikkaa, joten sitä voitiin käyttää vain kahden COM-koneen tai kahden CORBA-koneen kanssa. Myöhemmin Microsoft loi DCOM:n ja Sunin, RMI :n (Remote Method Invocation). Vaikka nämä menetelmät mahdollistivat yhteyden muodostamisen tietokoneiden välille verkon kautta, ne eivät myöskään olleet yhteentoimivia, koska RMI on saatavilla vain Javalle, ja siksi se on ohjelmointikielestä riippuvainen. Kaikista näistä syistä Microsoft kiinnostui XML -pohjaisesta hajautetusta tietojenkäsittelystä vuonna 1997. Sen tavoitteena oli lopettaa aikaisempien ratkaisujen yhteentoimivuusongelmat ja mahdollistaa sovellusten yhdistäminen RPC:iden (Remote Procedure Calls) kautta käyttämällä HTTPjaXML- .

SOAPin suunnittelivat objektin käyttöprotokollaksi vuonna 1998 Dave Winer, Don Box, Bob Atkinson ja Mohsen Al-Ghosein Microsoftilla, jossa Atkinson ja Al-Ghosein työskentelivät tuolloin. SOAP-spesifikaatiota ylläpitää tällä hetkellä World Wide Web Consortiumin XML-protokollatyöryhmä .

SOAP-versio 1.1 esiteltiin vuonna 2000 ja IBM osallistui sen luomiseen. Osallistuminen oli erittäin myönteistä, sillä sen myöhempää käyttöä varten tuotettiin merkittäviä ja ratkaisevia muutoksia: se suunniteltiin modulaarisemmalla ja skaalautuvammalla tavalla, mikä eliminoi patentoidusta tekniikasta, tässä tapauksessa Microsoftista, johtuvat ongelmat. Lisäksi IBM toteutti SOAP-toteutuksen Javassa ja SOAP integroitiin Web Services J2EE:hen.

SOAP merkitsi alun perin "Simple Object Access Protocol", mutta tämä lyhenne poistettiin standardin versiossa 1.2. Versiosta 1.2 tuli W3C :n suositus 24. kesäkuuta 2003. Lyhenne sekoitetaan joskus SOA :han , joka tarkoittaa palvelukeskeistä arkkitehtuuria, mutta lyhenteet eivät liity toisiinsa.

Kun SOAP esiteltiin ensimmäisen kerran, siitä tuli monimutkaisemman WSDL- (Web Services Description Language)- ja UDDI- (Universal Description Discovery and Integration) -verkkopalveluiden joukon perusta. Nämä palvelut, erityisesti UDDI, ovat osoittautuneet paljon vähemmän kiinnostaviksi, mutta niiden ymmärtäminen antaa täydellisemmän käsityksen SOAP:n odotetusta roolista verrattuna siihen, miten verkkopalveluita tällä hetkellä kehitetään.

Viestin rakenne

SOAP-sanoma on tavallinen XML-dokumentti, jonka rakenne on määritelty protokollamäärityksessä. Tämä rakenne koostuu seuraavista osista:

  • Kirjekuori (pakollinen) : rakenteen juuri, se on osa, joka tunnistaa SOAP-sanoman sellaisenaan.
  • Otsikko : tämä osa on laajennusmekanismi, koska se mahdollistaa tiedon lähettämisen siitä, miten viesti tulisi käsitellä. Se on työkalu, jonka avulla viestit voidaan lähettää sovelluksille kätevimmällä tavalla. "Header"-elementti puolestaan ​​koostuu "Header Blocks" -lohkoista, jotka rajaavat otsikon tarvitsemat tietoyksiköt.
  • Runko (pakollinen) : Sisältää kutsuun ja vastaukseen liittyvät tiedot.
  • Vika : lohko, joka sisältää tietoja virheistä, jotka ovat ilmenneet sanoman käsittelyn ja lähettämisen aikana "SOAP-lähettäjältä" "Ultimate SOAP Receiverille".

Tämän asiakirjan seuraavissa osissa tämä rakenne voidaan nähdä erityisillä esimerkeillä.

Käsittelymalli

SOAP-käsittelymalli määritellään hajautetuksi järjestelmäksi, johon eri solmut puuttuvat. Perusskenaariossa SOAP-solmut kommunikoivat toisen kanssa ottamalla SOAP-lähettäjänä ja toisen kanssa SOAP-vastaanottajan roolin . Silti spesifikaatio määrittelee erityyppiset solmut sen mukaan, minkä roolin ne ottavat viestin lähettämisessä:

  • SOAP Sender : solmu, joka lähettää SOAP-viestin.
  • SOAP Receiver : solmu, joka hyväksyy viestin.
  • SOAP-sanomapolku : Solmujoukko, jonka kautta SOAP-sanoman on kuljettava, mukaan lukien ensimmäinen solmu, nolla tai useampi välisolmu ja lopullinen SOAP-vastaanotin.
  • Alkuperäinen SOAP-lähettäjä : "lähettäjä", joka lähettää viestin ja joka on sen polun aloituspiste, jota viesti seuraa.
  • SOAP-välittäjä : Välittäjä toimii sekä SOAP-vastaanottajana että SOAP-lähettäjänä, vastaanottaen viestin ensin ja välittäen sen sitten polun seuraavaan solmuun.
  • Ultimate SOAP-vastaanotin : SOAP-viestin lopullinen kohde, se on vastuussa sen käsittelystä. On huomioitava, että viesti ei välttämättä tavoita lopullista vastaanottajaa välittäjien ongelmien vuoksi, jotka aiheuttavat sen katoamisen.

SOAP-solmu voi toimia yhdellä tai useammalla roolilla, joista jokainen määritellään URI:lla, joka tunnetaan roolin nimellä. Solmun omaksumat roolit ovat muuttumattomia viestin lähettämisen aikana ottaen huomioon yksittäisen viestin käsittelyn spesifikaatiot. Kuten mainittiin, sovellus voi luoda monimutkaisempia viestintäprotokollia ylemmiksi kerroksiksi SOAP:n päälle, jolloin se pystyy määrittelemään omat roolinsa tarpeidensa täyttämiseksi.

SOAP-spesifikaatio määrittelee säännöt niiden käsittelylle ja määrittelee sarjan vaiheita, joita protokollatoteutusten on noudatettava. Nämä vaiheet löytyvät W3C - spesifikaatioiden osiosta 2.6 .

SOAP sähköpostitse

Sovelluskehittäjät voivat nykyään käyttää Internetin sähköpostiinfrastruktuuria SOAP-viestien lähettämiseen joko tekstisähköpostiviesteinä tai liitteinä. Alla olevat esimerkit osoittavat yhden tavan lähettää SOAP-sanomia, ja niitä tulee pitää tavallisena tapana tehdä se. SOAP-version 1.2 tekniset tiedot eivät määrittele tällaista linkkiä. On kuitenkin olemassa ei-normatiivinen W3C-huomautus [SOAP Email Binding], joka kuvaa SOAP-sidontaa sähköpostiin. Sen päätarkoituksena on alkaa demonstroida yleisen sidoskehyksen soveltamista SOAP-protokollan kanssa.

Esimerkki näyttää esimerkin 1 matkavarauspyyntöviestin, joka kuljetetaan sähköpostiviestinä lähettävän käyttäjäagentin ja vastaanottavan käyttäjäagentin välillä. Se tarkoittaa, että vastaanottavalla solmulla on kyky ymmärtää SOAP:ia, joten sähköpostiviesti lähetetään käsiteltäväksi. (Oletetaan, että lähettävä solmu pystyy käsittelemään myös SOAP-virheitä, joita se saattaa vastaanottaa vastauksessa, tai korreloida siihen vastauksena vastaanotettuja SOAP-viestejä).

Esimerkki
Lähettäjä: [email protected]
Vastaanottaja: [email protected]
Aihe: Matka LA
Päivämäärä: to, 29. marraskuuta 2001 13:20:00 EST
Viestin tunnus: <[email protected]>
Sisältötyyppi: sovellus/saippua+xml

<?xml version='1.0' ?> 
<env:Envelope  xmlns:env= "http://www.w3.org/2003/05/soap-envelope" >  
  <env:Header> 
    <m:reserve  xmlns:m = "[[http://www.example.org]]"  
               env:role= "http://www.w3.org/2003/05/soap-envelope/role/next" 
               env:mustUnderstand= "true" > 
      <m:reference> uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d </m:reference> 
      <m:dateYTime> 2001-11-29T13:20:00.000-05:00 YTime> </ m:date> 
    :varaus> 
    <n:matkustaja  xmlns:n= "http://omayritys.esimerkki.fi/työntekijät" 
                env:role= "http://www.w3.org/2003/05/saippuakirje/rooli/seuraava " 
                env:mustUnderstand= "true" > 
      <n:name> Åke Jógvan Øyvind </n:name> 
    </n:passenger > 
  </env:Header> 
  <env:Body> 
    <p:matkasuunnitelma  xmlns:p= "http ://companytravel.example.org/booking/trip" > 
      <p: out> 
        <p:out> New York </p:out> 
        <p:arrival> Los Angeles </p:arrival> 
        <p:dateOut> 14.12.2001 </p: FechaSalida > 
        <p:horaSalida> myöhään iltapäivällä </p:horaSalida> 
        <p:preferenceSeat> käytävä </p:preferenceSeat> 
      </p:ida> 
      <p:return> 
        <p: departure> Los Angeles </p:departure> 
        <p:arrival> New York </p:arrival> 
        <p:exitdate> 20.12.2001 < /p:exitdate> 
        <p:exittime> puolivälissä aamulla </p:exittime> 
        <p :seatpreference  /> 
      </p:return> 
    </p:itinerary> 
    <q:accommodation  xmlns:q= "http://companytravel.example.org/booking/hotels" > 
      <q:preference> ei mitään </q:preference> 
    </q:accommodation> 
  </ env:Body> 
</env:Envelope> SOAP-viesti esimerkistä 1 kuljetettu SMTP-viestinä

Esimerkkiotsikko on sähköpostiviestien vakiomuodossa [ RFC 2822 ] .

Vaikka sähköposti on yksisuuntaista viestien vaihtoa, eikä toimitustakuuta anneta, infrastruktuurit, kuten Simple Mail Transport Protocol ( SMTP ) -spesifikaatio, tarjoavat toimitusilmoitusmekanismin, jota SMTP:n tapauksessa kutsutaan toimitustilailmoitukseksi (Delivery Status Notification). DSN) ja MDN (Message Disposition Notification). Nämä ilmoitukset ovat sähköpostiviestien muodossa, joka lähetetään sähköpostiviestin otsikossa määritettyyn sähköpostiosoitteeseen. Sovellukset sekä sähköpostin loppukäyttäjät voivat käyttää näitä mekanismeja sähköpostin lähetyksen tilan ilmoittamiseen, mutta nämä olisivat mahdollisia ilmoituksia SMTP-tasolla. Sovelluskehittäjän on ymmärrettävä täysin näiden toimitusilmoitusten ominaisuudet ja rajoitukset, tai hän voi olettaa, että viesti on toimitettu onnistuneesti, vaikka sitä ei ehkä ole ollutkaan.

SMTP-toimituksen tilaviestit erotetaan viestien käsittelystä SOAP-kerroksessa. Tuloksena saadut SOAP-vastaukset SOAP-tietoihin palautetaan uudella sähköpostiviestillä, jossa voi olla tai ei ole linkkiä alkuperäiseen pyyntösanomaan SMTP-tasolla. Otsikon In-reply-to: [In-reply-to] käyttö [ RFC 2822 ]:n mukaan voi saavuttaa SMTP-tason kartoituksen, mutta se ei välttämättä tarkoita kartoitusta SOAP-tasolla.

SOAP viestiesimerkkejä

Esimerkkinä näytetään tapa, jolla asiakas pyytää tietoja tuotteesta verkkopalveluntarjoajalta: 

<soap:Envelope  xmlns:soap= "http://schemas.xmlsoap.org/soap/envelope/" > 
   <soap:Body> 
     <getProductDetails  xmlns= "http://warehouse.example.com/ws" > 
       <productId > 827635 </productId> 
     </getProductDetails> 
   </soap:Body> 
</soap:Envelope>

Ja tämä olisi palveluntarjoajan vastaus: 

<soap:Envelope  xmlns:soap= "http://schemas.xmlsoap.org/soap/envelope/" > 
   <soap:Body> 
     <getProductDetailsResponse  xmlns= "http://warehouse.example.com/ws" > 
       <getProductDetailsResult > 
         <productName> Toptimate 3-osainen setti </productName> 
         <productId> 827635 </productId> 
         <description> 3-osainen matkalaukkusarja. Musta polyesteri. </description> 
         <price> 96,50 </price> 
         <inStock> true </inStock> 
       </getProductDetailsResult> 
     </getProductDetailsResponse> 
   </soap:Body> 
 </soap:Envelope>

Vaikka HTTP ei ollut ainoa mahdollinen vaihtoehto, se valittiin siirtoprotokollaksi sen etujen vuoksi esimerkiksi palomuurien käsittelyyn. Muut protokollat, kuten GIOP/IIOP tai DCOM (käytetään CORBA:ssa, RMI:ssä ja DCOM:ssa), yleensä torjuvat nämä palomuurit.

Edut ja haitat

Edut

  • XML:n käytön ansiosta se mahdollistaa useiden kielten etäproseduurien kutsumisen, joten se tarjoaa erinomaisen yhteentoimivuuden.
  • Käyttämällä HTTP :n kautta tapahtuvaa viestintää se on helposti skaalautuva, sen lisäksi, että palomuurit sallivat sen lähes aina.
  • Se voidaan toteuttaa millä tahansa kielellä ja käyttää millä tahansa alustalla.
  • Sitä voi käyttää anonyymi käyttäjä ja todennus.
  • Se voidaan lähettää millä tahansa siirtoprotokollalla, joka pystyy lähettämään tekstiä, tyypillisesti HTTP- tai SMTP -protokollaa .

Haitat

  • Koska XML:ää käytetään viestien välittämiseen, SOAP on huomattavasti hitaampi kuin muut väliohjelmistot, kuten CORBA , koska binaaridata koodataan tekstiksi. Tämän heikkouden torjumiseksi sulautetun binäärikoodin sisältävän XML:n tapauksessa kehitettiin optimoitu viestinvälitysmenetelmä.
  • Se riippuu WSDL :stä (Web Services Description Language).
  • Toisin kuin Java, PHP tai Python, tietyt kielet eivät tarjoa riittävää tukea niiden käytölle integroinnin tai IDE -tuen tasolla .

Käyttötapaukset

Yleisin tapa käyttää SOAP-protokollaa on SOAP-lähettäjällä ja lopullisella SOAP-vastaanottajalla varustettu pyyntö-vastauskuvio , jota käytetään, kun SOAP-viestit on ennalta määritetty ja haluat vain lähettää pyynnön ja tarkistaa sen palautusarvon.

Usein tämä kuvio ei kuitenkaan riitä, ja solmujen välille on luotava moninkertainen viestien vaihto. W3C määrittelee kaksi SOAP-viestinvaihtotyyppiä keskustelun muodostamiseksi:

  • Keskusteluviestien vaihto : mahdollistaa pyynnön tietojen uudelleenmäärittelyn. Nämä vaihdot voivat päätyä käyttäytymään edestakaisin viestien mallina.
  • Calls to Remote Procedures : se mahdollistaa etätoimintojen toiminnallisuuden kapseloinnin käyttämällä XML:n laajennettavuuden ja toiminnallisuuden etuja, tästä syystä spesifikaatiossa on määritelty yhtenäinen esitys RPC-kutsujen ja -vastausten suorittamiseksi SOAP-sanomien kautta.

Joskus on tarpeen käyttää välittäjiä SOAP-viestinnässä, SOAP 1.2 -spesifikaatio määrittelee kaksi tyyppiä:

  • Uudelleenohjausvälittäjä : Tämä on SOAP-solmu, joka uudelleenohjaa SOAP-sanoman toiseen SOAP-solmuun kohdesolmun vastaanottaman otsikkolohkon määrityksen tai käytössä olevan sanomamallin mukaan.
  • Aktiivinen välittäjä - Suorittaa SOAP-sanoman lisäkäsittelyn ennen sen uudelleenohjausta käyttämättä viestin otsikossa tai käytössä olevassa viestimallissa kuvattuja ehtoja.

SOAP-verkkopalvelun käyttöönotto

Kaikki verkkojärjestelmien kehittämisessä laajalti käytetyt kielet toteuttavat tai sisältävät jonkinlaista tukea sekä SOAP-verkkopalveluiden että niitä kuluttavien asiakkaiden käyttöönotolle. Protokollan perustasolla toteuttavien kirjastojen lisäksi löydämme muitakin, jotka toteuttavat erilaisia ​​käyttöskenaarioita ja luovat yksinkertaisempia käyttöliittymiä, mikä yksinkertaistaa ohjelmointia.

Nämä kirjastot, joita käytetään yhdessä verkkojärjestelmän kehityskehysten kanssa, virtaviivaistavat sekä verkkopalvelun että sen asiakkaiden kehitysprosessia, varsinkin jos luodaan WSDL-tiedosto, joka välittää palvelun ominaisuudet asiakkaille.

  • JAVA : sen vakiokirjastossa on konkreettisia toteutuksia, joita tuetaan virallisesti . Löydämme myös kolmannen osapuolen kirjastoja, jotka, kuten mainittiin, auttavat kehittäjää yksinkertaistamalla käyttöliittymiä ja toteuttamalla yleisimmät käyttötapaukset. On huomattava, että yleisimmin käytetyt kehitysympäristöt tarjoavat tukea SOAP-verkkopalveluiden luomiselle, jotka muun muassa generoivat automaattisesti WSDL-tiedoston ja mahdollistavat API:n ja sen sisältämien kutsujen visuaalisen suunnittelun. Mitä tulee käytettävään palvelimeen, tyypillisiä Java-vaihtoehtoja voidaan harkita: Tomcat, Glassfish jne. Siitä huolimatta palvelimen valinnalla voi olla joitain etuja, esimerkiksi Glassfish luo yksinkertaisen verkkoliittymän palvelun eri kutsujen testaamiseen. Lisäksi useimmat työkalut mahdollistavat palveluasiakkaan luomisen automaattisesti WSDL-tiedostostaan .
  • PHP : Tarjoaa tukea ja tukikirjastoja ottamalla käyttöön SOAP-laajennuksen palvelimella. On kehitetty suuri määrä kolmannen osapuolen kirjastoja , jotka yhdistettynä MVC-kehysten käyttöön yksinkertaistavat rajapintoja ja toteuttavat yleisimmät käyttöskenaariot. Yleisiä ovat myös asiakassovellukset tietyille julkisille verkkopalveluille.
  • Python - Ei tarjoa tukea vakiokirjastoissaan, mutta on olemassa suuri määrä kolmannen osapuolen paketteja, jotka mahdollistavat SOAP-verkkopalveluiden ja niiden asiakkaiden käyttöönoton. Pythonin verkkopalvelukehityksen saralla vallitsee Django Frameworkin käyttö, joka voidaan yhdistää mihin tahansa SOAP-toteutuksiin.
  • .NET : Frameworkissa on Java-kaltaisia ​​työkaluja visuaalista palvelusuunnittelua ja automaattista WSDL-luomista varten. Se tukee myös asiakkaiden luomista palvelun määritelmätiedostosta. .NET:lle näkyvä kehitysympäristö on Visual Studio. Mitä tulee kirjastoihin, huomaamme, että .NET-ekosysteemi tarjoaa useita vaihtoehtoja eri kielillä, vaikka Microsoftin nykyinen sitoutuminen verkkokehitykseen on sen .NET MVC Framework . On huomattava, että Microsoft loi Windows Communication Foundation -muodon, joka on malli WSDL:n kaltaisten ja täydentävien palvelukeskeisten järjestelmien luomiseen.

Katso myös

Viitteet

W3C suositukset

Artikkelit

Ulkoiset linkit

Haettu osoitteesta « https://es.wikipedia.org/w/index.php?title=Simple_Object_Access_Protocol&oldid=136277209 »