Povijest stvaranja

Pojavom osobnih računala javila se i potreba za njihovim kombiniranjem. U početku su postojale jednostavne kabelske veze, zatim su se pojavili mrežni protokoli koji su ujedinjavali računala koja rade na istom OS-u; razvojem tehnologije nestala je potreba za jednim OS-om na svim računalima i postalo je moguće kombinirati računala s različitim OS-ima. Internet je promijenio brzinu kretanja na putu ujedinjenja.

Ali ni danas nisu riješeni svi problemi integracije; nažalost, nije postojao jedinstveni protokol za komunikaciju između internetskih aplikacija i usluga. Kako bi riješile ovaj problem, tvrtke kao što su Microsoft, DevelopMentor, UserLand Software, IBM i Lotus Development udružile su se i kao rezultat njihovih zajedničkih aktivnosti nastao je Simple Object Access Protocol - jednostavan protokol za pristup objektu koji opisuje standard za udaljenu proceduru poziva baziranih na XML jeziku (Extensible Markup Language – proširivi označni jezik). SOAP je osmišljen kako bi uvelike pojednostavio razvoj višejezičnih aplikacija i alata za poslovnu integraciju. Početak je napravljen sa SOAP-om 1.0, koji je za rad zahtijevao HTTP protokol.

Nakon pojave početne verzije SOAP-a, nastale, kao što je već navedeno, zajedničkim naporima Microsofta, DevelopMentora i UserLanda, IBM i Lotus su se uključili u razvoj proizvoda. Kao rezultat toga, specifikacija je prošla kroz značajnu reviziju kako bi bolje odgovarala integraciji heterogenih okruženja. Glavna razlika između sljedeće verzije SOAP-a 1.1 i početne verzije bio je prijelaz s Microsoftovih XML-podataka na XML shemu. Osim toga, u novoj verziji specifikacija više ne ovisi o transportnim protokolima. SOAP 1.0 zahtijevao je HTTP protokol, dok za SOAP 1.1 vrsta prijenosa nije bitna: možete koristiti e-poštu ili veze za prosljeđivanje poruka. Tvrtke koje su već usvojile SOAP 1.0 našle su se vezane uz Microsoftovu nestandardnu ​​tehnologiju. Međutim, brojni obećavajući proizvodi ove korporacije, uključujući BizTalk Server i SQL Server 7.0, također se oslanjaju na XML-podatke. Pojavom verzije 1.1 širi se krug pobornika SOAP protokola

Izvorna verzija SOAP-a 1.1 predana IETF Internet Technical Task Force temeljila se na tehnologiji XML-podataka koju je predložio Microsoft u siječnju 1998. Međutim, tijekom procesa pregleda standarda W3C, temeljna struktura je zamijenjena XML shemom. Konzorcij World Wide Weba zamoljen je da razmotri SOAP 1.1 kao potencijalni standard.

Najnovija verzija specifikacije Simple Object Access Protocol (SOAP) dostupna je na web poslužitelju koji služi članovima MSDN™ Developer Program (http://msdn.microsoft.com/). SOAP je otvoreni protokol temeljen na standardima koji definira, temeljen na XML-u (Extensible Markup Language), uobičajeni format za komunikaciju između bilo koje internetske aplikacije i usluge. Ova verzija proširuje SOAP-ove mogućnosti za asinkronu komunikaciju kako bi uključila podršku ne samo za HTTP, već i za internetske protokole kao što su SMTP, FTP i TCP/IP. Najnovija verzija SOAP specifikacije dobila je široku podršku tvrtki kao što su ActiveState Tool Corp., Ariba Inc., BORN Information Services Inc., Commerce One Inc., Compaq Computer Corp., DevelopMentor Inc., Extensibility Inc., IBM, IONA Technologies PLC, Intel Corp., Lotus Development Corp., ObjectSpace Inc., Rogue Wave Software Inc., Scriptics Corp., Secret Labs AB, UserLand Software i Zveno Pty. doo SOAP specifikacija pruža zajednički mehanizam za integriranje usluga preko Interneta i/ili intraneta, bez obzira na operativni sustav, objektni model ili programski jezik koji se koristi. Na temelju internetskih standarda XML i HTTP, SOAP omogućuje bilo kojoj novoj ili postojećoj aplikaciji međusobnu komunikaciju. Web stranice koje podržavaju SOAP mogu postati web usluge kojima se pristupa čisto programski i ne zahtijevaju ljudsku intervenciju. Jedinstvena infrastruktura koja omogućuje izravnu interakciju između aplikacija okrenutih prema Internetu otvara nove mogućnosti za integraciju usluga i uređaja—bez obzira gdje se na Internetu nalaze.

Web usluge i SOAP

Web usluge i SOAP dizajnirani su za rješavanje problema međuplatformske komunikacije aplikacija. Ovaj će vam članak pomoći da steknete uvid u te nove obećavajuće tehnologije.

Što je SOAP

Trenutno korištene tehnologije za daljinsko pozivanje metoda (DCOM, CORBA/IIOP i RMI) prilično je teško konfigurirati i organizirati interakciju. To za sobom povlači probleme u radu i funkcioniranju distribuiranih sustava (sigurnosni problemi, transport kroz firewall, itd.). Postojeći problemi uspješno su riješeni stvaranjem SOAP-a (Simple Object Access Protocol), jednostavnog protokola temeljenog na XML-u za razmjenu poruka u distribuiranim okruženjima (WWW). Dizajniran je za izradu web usluga i metoda pozivanja na daljinu. SOAP se može koristiti s različitim transportnim protokolima, uključujući HTTP, SMTP itd.

Što su web usluge

Web usluge su funkcionalnosti i podaci izloženi za korištenje vanjskim aplikacijama koje su u interakciji s uslugama putem standardnih protokola i formata podataka. Web usluge potpuno su neovisne o implementacijskom jeziku i platformi. Tehnologija web usluga kamen je temeljac Microsoftovog .NET programskog modela. Kako bih demonstrirao mogućnosti SOAP-a, upotrijebio sam nedavno objavljenu implementaciju SOAP Toolkit verzije 2.0 od Microsofta. Treba napomenuti da se trenutna verzija Toolkita znatno razlikuje od prethodne (Microsoft SOAP Toolkit za Visual Studio 6.0) i od beta verzije SOAP Toolkit 2.0.

Mehanizam interakcije između klijenta i poslužitelja

1. Klijentska aplikacija instancira objekt SOAPClient
2. SOAPClient čita datoteke opisa metoda web servisa (WSDL i Web Services Meta Language - WSML). Te se datoteke također mogu pohraniti na klijentu.
3. Klijentska aplikacija, koristeći mogućnosti kasnog vezanja SOAPClient objekta, poziva servisnu metodu. SOAPClient generira paket zahtjeva (SOAP Envelope) i šalje ga poslužitelju. Može se koristiti bilo koji transportni protokol, ali obično se koristi HTTP.
4. Paket uzima poslužiteljsku aplikaciju slušatelja (može biti ISAPI aplikacija ili ASP stranica), stvara objekt SOAPServer i prosljeđuje mu paket zahtjeva
5. SOAPServer čita opis web usluge, učitava opis i paket zahtjeva u XML DOM stabla
6. SOAPServer poziva metodu objekta/aplikacije koja implementira uslugu
7. Rezultate izvršenja metode ili opis pogreške objekt SOAPServer pretvara u paket odgovora i šalje klijentu
8. Objekt SOAPClient analizira primljeni paket i klijentskoj aplikaciji vraća rezultate usluge ili opis greške koja se dogodila.

WSDL datoteka je XML dokument koji opisuje metode koje nudi web usluga. Također parametri metoda, njihove vrste, nazivi i lokacija Slušatelja usluge. SOAP Toolkit čarobnjak automatski generira ovaj dokument.

SOAP Envelope (Package) - XML ​​dokument koji sadrži zahtjev/odgovor za izvršavanje metode. Najprikladnije ga je smatrati poštanskom omotnicom u kojoj se nalaze podaci. Envelope oznaka mora biti korijenski element paketa. Element Header nije obavezan, ali element Body mora biti prisutan i biti izravni dijete elementa Envelope. Ako se dogodi pogreška u izvršavanju metode, poslužitelj generira paket koji sadrži element Fault u oznaci Body, koji sadrži detaljan opis pogreške. Ako koristite sučelja visoke razine SOAPClient, SOAPServer, tada ne morate ulaziti u zamršenost formata paketa, ali po želji možete koristiti sučelja niske razine ili čak ručno izraditi paket.

SOAP Toolkit objektni model omogućuje rad s API objektima niske razine:

• SoapConnector - Omogućuje rad s transportnim protokolom za razmjenu SOAP paketa
• SoapConnectorFactory - Omogućuje metodu za stvaranje konektora za transportni protokol naveden u WSDL datoteci (oznaka)
• SoapReader - čita SOAP poruke i gradi XML DOM stabla
• SoapSerializer - Sadrži metode za stvaranje SOAP poruke
• IsoapTypeMapper, SoapTypeMapperFactory - sučelja koja vam omogućuju rad sa složenim tipovima podataka

Korištenjem API objekata visoke razine možete prenositi samo podatke jednostavnih tipova (int, srting, float ...), ali specifikacija SOAP 1.1 omogućuje rad sa složenijim tipovima podataka, kao što su nizovi, strukture, popisi i njihovi kombinacije. Za rad s takvim tipovima morate koristiti sučelja IsoapTypeMapper i SoapTypeMapperFactory.

Lirski dio.

Zamislite da ste implementirali ili implementirate određeni sustav koji bi trebao biti dostupan izvana. one. postoji određeni poslužitelj s kojim trebate komunicirati. Na primjer web poslužitelj.

Ovaj poslužitelj može obavljati mnoge radnje, raditi s bazom podataka, izvršavati neke zahtjeve trećih strana prema drugim poslužiteljima, raditi neke izračune itd. živjeti i eventualno se razvijati prema scenariju koji mu je poznat (tj. prema scenariju programera). Čovjeku nije zanimljivo komunicirati s takvim poslužiteljem, jer možda neće moći/želiti pružiti lijepe stranice sa slikama i drugim sadržajem prilagođenim korisniku. Napisan je i radi tako da radi i daje podatke kada se to od njega traži, bez brige da je čovjeku čitljiv, klijent će se s njim sam pozabaviti.

Drugi sustavi, pristupajući ovom poslužitelju, već mogu raspolagati podacima primljenim s ovog poslužitelja prema vlastitom nahođenju - obrađivati, akumulirati, izdavati svojim klijentima itd.

Pa, jedna od opcija za komunikaciju s takvim poslužiteljima je SOAP. SOAP xml protokol razmjene poruka.

Praktični dio.

Web usluga (ovo je naziv onoga što poslužitelj pruža i što klijenti koriste) omogućuje komunikaciju s poslužiteljem jasno strukturiranim porukama. Činjenica je da web servis ne prihvaća nikakve podatke. Web servis će odgovoriti pogreškom na svaku poruku koja nije u skladu s pravilima. Greška će, usput, također biti u xml obliku s jasnom strukturom (što nije točno za tekst poruke).

WSDL (Jezik za opis web usluga). Pravila po kojima se sastavljaju poruke za web servis također su opisana pomoću xml-a i također imaju jasnu strukturu. one. Ako web usluga pruža mogućnost pozivanja metode, ona mora omogućiti klijentima da znaju koji se parametri koriste za ovu metodu. Ako web-usluga očekuje niz za Method1 kao parametar, a niz bi trebao imati naziv Param1, ta će pravila biti navedena u opisu web-usluge.

Ne samo jednostavni tipovi, već i objekti i zbirke objekata mogu se proslijediti kao parametri. Opis objekta svodi se na opis svake komponente objekta. Ako se objekt sastoji od više polja, tada se opisuje svako polje, njegov tip, naziv (koje su moguće vrijednosti). Polja mogu biti i složenog tipa, i tako sve dok se opis tipova ne završi jednostavnim - string, boolean, broj, datum... Međutim, neki specifični tipovi mogu se pokazati jednostavnim, važno je da klijenti može razumjeti koje vrijednosti mogu sadržavati.

Za klijente je dovoljno znati url web servisa; wsdl će uvijek biti u blizini, iz kojeg možete dobiti ideju o metodama i njihovim parametrima koje ovaj web servis pruža.

Koje su prednosti svih ovih zvona i zviždaljki:

• U većini sustava opis metoda i vrsta događa se automatski. one. programer na poslužitelju samo treba reći da se ova metoda može pozvati putem web servisa, a wsdl opis će se automatski generirati.

Opis, koji ima jasnu strukturu, čitljiv je svakom klijentu sapuna. one. bez obzira o kojoj se web usluzi radi, klijent će razumjeti koje podatke web usluga prima. Koristeći ovaj opis, klijent može izgraditi vlastitu unutarnju strukturu klasa objekata, tzv. vezanje" i. Kao rezultat toga, programer koji koristi web uslugu mora napisati nešto poput (pseudokoda):

NewUser:=TSoapUser.Create("Vasya","Pupkin","admin"); sapun.DodajKorisnika(NoviKorisnik);

• Automatska provjera valjanosti.

  • xml provjera valjanosti. xml mora biti dobro oblikovan. Neispravan xml - odmah greška klijentu, neka sam to riješi.
  • provjera valjanosti sheme. xml mora imati određenu strukturu. xml ne odgovara shemi - odmah greška klijentu, neka on to sredi.
  • Provjeru podataka provodi poslužitelj sapuna tako da vrste podataka i ograničenja odgovaraju opisu.
• Autorizacija i autentifikacija mogu se implementirati korištenjem zasebne metode. izvorno. ili pomoću http autorizacije.
• Web usluge mogu raditi i preko soap protokola i preko http-a, odnosno putem get zahtjeva. To jest, ako su parametri jednostavni podaci (bez strukture), tada možete jednostavno pozvati uobičajeni get www.site.com/users.asmx/GetUser?Name=Vasia ili post. Međutim, to nije svugdje i ne uvijek.
• ... vidi na Wikipediji

Postoji i mnogo nedostataka:

• Nerazumno velika veličina poruke. Pa, ovdje je sama priroda xml-a takva da je format suvišan, što više oznaka, to više beskorisnih informacija. Plus sapun dodaje svoju suvišnost. Za intranet sustave pitanje prometa je manje akutno nego za internet, pa je sapun za lokalne mreže traženiji, posebice Sharepoint ima soap web uslugu s kojom možete uspješno komunicirati (i s nekim ograničenjima).
• Automatsko mijenjanje opisa web usluge može pokvariti sve klijente. Pa to je tako za svaki sustav, ako nije podržana povratna kompatibilnost sa starim metodama, sve će pasti...
• Nije minus, nego mana. Svi pozivi metoda moraju biti atomski. Na primjer, kada radimo s bazom podataka, možemo započeti transakciju, izvršiti nekoliko upita, zatim se vratiti ili izvršiti. U sapunu nema transakcija. Jedan zahtjev, jedan odgovor, razgovor je gotov.
• Suočavanje s opisom onoga što je na strani poslužitelja (je li sve ispravno opisano?) i onoga što je na klijentu (što mi je ovdje opisano?) može biti prilično teško. Bilo je nekoliko puta kada sam morao razumjeti klijentsku stranu i uvjeravati serverskog programera da su njegovi podaci netočno opisani, ali on to uopće nije mogao razumjeti, jer automatsko generiranje i ne bi trebao, to je stvar softvera . A pogreška je, naravno, bila u kodu metode; programer je jednostavno nije vidio.
• Praksa pokazuje da su programeri web servisa užasno daleko od ljudi koji te web servise koriste. Kao odgovor na bilo koji zahtjev (važeći izvana), može doći nerazumljiva pogreška "Pogreška 5. Sve je loše". Sve ovisi o savjesti programera :)
• Sigurno se još nečega ne sjećam...

Kao primjer, postoji otvoreni web servis belavia:

• http://86.57.245.235/TimeTable/Service.asmx - ulazna točka, postoji i tekstualni opis metoda za programere trećih strana.
• http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl opis metoda i vrsta primljenih i vraćenih podataka.
• http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - opis konkretne metode s primjerom tipa xml zahtjeva i xml odgovora.

Možete ručno izraditi i poslati zahtjev poput:

POST /TimeTable/Service.asmx HTTP/1.1 Host: 86.57.245.235 Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://webservices.belavia.by/GetAirportsList" ru

doći će odgovor:

HTTP/1.1 200 OK Datum: Pon, 30. rujna 2013. 00:06:44 GMT Poslužitelj: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Verzija: 4.0.30319 Cache-Control: privatno, maks. -age=0 Content-Type: text/xml; charset=utf-8 Dužina sadržaja: 2940

PS Prethodno je otvorena Aeroflotova web usluga, ali nakon što je 1C dodao podršku za sapun u 8ku, hrpa 1C beta testera uspješno ju je instalirala. Sada se tu nešto promijenilo (ne znam adresu, možete pogledati ako vas zanima).
ZZY Odricanje od odgovornosti. Govorio je na svakodnevnoj razini. Možeš šutirati.

Što je SOAP?

SOAP je kratica za Simple Object Access Protocol. Nadam se da ćete se nakon čitanja članka samo pitati: "Kakvo je ovo čudno ime?"

SOAP u svom trenutnom obliku je metoda udaljenog poziva procedure (RPC) preko mreže. (Da, također se koristi za prijenos dokumenata kao XML, ali to ćemo za sada izostaviti.)

Hajdemo shvatiti. Zamislite da imate uslugu koja vraća kotaciju dionica za određeni ticker (simbol dionice). Šalje podatke web stranici Nasdaq i generira željeni rezultat na temelju vraćenog HTML-a. Dalje, kako biste drugim programerima omogućili korištenje unutar svojih aplikacija, napravite komponentu od ove usluge koja pronalazi informacije o ponudama putem Interneta. Radi odlično sve dok jednog dana Nasdaq ne promijeni izgled svojih stranica. Morate ponovno razmotriti cijelu logiku komponente i poslati ažuriranja svim programerima koji je koriste. A oni, zauzvrat, trebaju slati ažuriranja svim svojim korisnicima. Ako se to događa više ili manje stalno, možete steći mnogo neprijatelja među svojim kolegama programerima. A s programerima se, kao što znate, ne treba šaliti. Ne želite sutra izvaditi fotografiju svoje omiljene mačke iz uredskog šredera, zar ne?

Što učiniti? Da vidimo... sve što trebate je osigurati jednu funkciju koja će kao ulaz uzeti simbol oznake (upišite string) i vratiti kotaciju dionica (upišite float ili double). Ne bi li bilo lakše dopustiti vašim programerima da nekako pozovu ovu funkciju preko Interneta? odlično! Također novost za mene, postoje COM i Corba i Java koje to rade godinama... što je istina istina je, ali ove metode nisu bez mana. Udaljena COM konfiguracija nije trivijalna. Osim toga, trebate otvoriti toliko portova u vatrozidu da ne možete podnijeti dovoljno piva za administratora sustava. Da, i morat ćete zaboraviti na korisnike svih operativnih sustava osim Windowsa. No korisnici Linuxa također su ponekad zainteresirani za razmjenu.

Iako se čini da nije sve izgubljeno za korisnike Linuxa ako koriste DCOM, više ovdje: http://www.idevresource.com/com/library/res/articles/comonlinux.asp.

Ne mogu puno reći o Corbi i Javi, pa kao vježbu pozivam čitatelje da pronađu nedostatke u tim pristupima.

SOAP je standard koji vam omogućuje da opišete takav udaljeni poziv i oblik u kojem će se rezultat vratiti. Dakle, trebate smjestiti svoju funkciju u aplikaciju kojoj možete pristupiti putem mreže i primati pozive kao SOAP pakete. Zatim potvrđujete unos, pokrećete svoju funkciju i vraćate rezultat u novom SOAP paketu. Cijeli proces može se izvoditi preko HTTP-a, tako da ne morate otvarati hrpu portova na vašem vatrozidu. Je li stvarno jednostavno?

O čemu je ovaj članak?

Ovo je prvi u nizu članaka koje pišemo o SOAP-u u Agni Software-u. U ovom članku pokušat ću vam dati ideju o tome što je SOAP i kako napisati aplikaciju koja komunicira sa SOAP poslužiteljem.

Sapun i XML

Ako vam se SOAP i dalje čini jednostavnim, dodajmo XML. Sada, umjesto naziva funkcije i parametara, dobivamo prilično složenu XML omotnicu, kao da je osmišljena da vas zbuni. Ali nemojte žuriti da se uplašite. Postoji više od toga i morate vidjeti cijelu sliku da biste cijenili složenost SOAP-a.
Ako ne znate što je XML, prvo pročitajte moj članak o XML-u ovdje: http://www.agnisoft.com/white_papers/xml_delphi.asp.

Svi SOAP paketi su u XML formatu. Što to znači? Da vidimo. Pogledajte ovu funkciju (Pascal):
funkcija GetStockQuote(Simbol: niz) : dvostruko;
Izgleda super, ali problem je što je to Pascal. Kakva je korist od ove jednostavne definicije za Java programera? Ili za nekoga tko radi s VB? Trebamo nešto što će biti razumljivo svima, čak i VB programerima. Dakle, dajte im XML koji sadrži iste informacije (parametre, vrijednosti kotacije dionica, itd.). Stvorite SOAP paket, koji je u biti poziv vašoj funkciji, omotan u XML tako da ga svaka aplikacija na bilo kojoj platformi može razumjeti. Sada da vidimo kako izgleda naš SOAP poziv:
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">


IBM

Informativno, zar ne? SOAP postaje sve lakši pred našim očima. Dobro, šalu na stranu. Sada ću vam pokušati objasniti kako razumjeti ovaj SOAP poziv.

Dekodiranje oznake Prva oznaka koja upada u oči je

. Ova oznaka je vanjski omotač SOAP paketa, koji sadrži nekoliko deklaracija prostora imena koje nas posebno ne zanimaju, ali su vrlo važne za bilo koji programski jezik ili parser. Prostori imena su definirani kako bi se osiguralo da parser razumije sljedeće prefikse kao što su "SOAP-ENV:" ili "xsd:". Sljedeća oznaka – . (Propustili smo oznaku koja nije prikazana ovdje - . Nije u ovom konkretnom primjeru, ali ako želite pročitati više o tome, pogledajte SOAP specifikaciju ovdje: http://www.w3.org/TR/SOAP/). Označiti

zapravo sadrži SOAP poziv. Sljedeća oznaka na popisu je

Napomena o prostorima imena: Prostor imena omogućuje kvalificiranje XML oznake. Ne možete, primjerice, imati dvije varijable s istim imenom u jednoj proceduri, ali ako su u dvije različite procedure, nema problema. Dakle, procedura je imenski prostor, budući da su sva imena u njoj jedinstvena. Isto tako, XML oznake imaju svoj opseg unutar prostora imena, tako da s obzirom na prostor imena i naziv oznake, možete ga jedinstveno identificirati. Definirat ćemo imenski prostor kao URI kako bismo razlikovali naš NS1 od kopija. U gornjem primjeru, NS1 je alias koji ukazuje na urn:xmethods-quotes.

Također obratite pozornost na atribut encodingStyle - ovaj atribut određuje kako se SOAP poziv serijalizira.

Unutar oznake sadrži parametre. U našem najjednostavnijem slučaju imamo samo jedan parametar - tag . Primijetite ovaj redak pored oznake:
xsi:type="xsd:string"
Ovako su otprilike tipovi definirani u XML-u. (Primijetite kako sam pametno upotrijebio riječ "otprilike" kad sam generalizirao tehnologiju koja bi se mogla promijeniti nakon objavljivanja članka.) Što to točno znači: tip definiran u prostoru imena xsi, za koji ćete primijetiti da je definiran u oznaci – xsd: niz. A ovo je, pak, niz, definiran u xsd imenskom prostoru, opet definiran ranije. (Siguran sam da bi odvjetnici bili oduševljeni svim ovim).

Unutar oznake Označeno je "IBM". Ovo je vrijednost parametra simbola funkcije GetStockQuote.

Pa, na kraju, kao pristojni ljudi, zatvorili smo sve oznake.

Tako smo otkrili SOAP paket koji definira poziv prema SOAP poslužitelju. A SOAP poslužitelj, koristeći XML parsere, crveni gumb i svemirsku stanicu MIR, dekodira ovaj poziv i utvrđuje da vam je potrebna burzovna ponuda. Odmah pronalazi pravi citat i vraća vam ga u ovom obliku:
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>


34.5


Nakon odmotavanja SOAP omotnice, kidanja vrpci i šuškanja omota, saznajemo da je cijena dionice IBM-a 34,5.

Većina komercijalnih poslužitelja vratila bi puno više informacija, primjerice u kojoj valuti i po kojoj cijeni je kupljena zadnja dionica. A cijena dionice, možda bi bila točnija.

Na taj način znamo što SOAP poslužitelj očekuje i što će vratiti. Dakle, KAKO šaljete ove informacije? Možete koristiti bilo koji prijevoz. Najzastupljeniji je HTTP. Neću ulaziti u detalje o HTTP-u, za one koji ne znaju, to je ono što vaš preglednik koristi za komunikaciju sa stranicama koje posjećujete.

Potreban HTTP zahtjev izgledat će otprilike ovako:
POST /StockQuote HTTP/1.1
Domaćin: www.stockquoteserver.com

Sadržaj-duljina: nnnn
SOAPAction: "Some-URI"

Paket zahtjeva sapuna ovdje... Jedina druga stvar vrijedna pažnje je zaglavlje SOAPAction. Ovo zaglavlje označava svrhu zahtjeva i obavezno je. Svaki SOAP poslužitelj može imati neograničen broj funkcija i može koristiti zaglavlje SOAPAction za određivanje koja se funkcija poziva. Vatrozidi i multiplekseri također mogu filtrirati sadržaj na temelju ovog zaglavlja.

SOAP odgovor s HTTP poslužitelja izgledat će ovako:
HTTP/1.1 200 OK
Vrsta sadržaja: tekst/xml; charset="utf-8"
Sadržaj-duljina: nnnn

Soap Response paket ovdje... Zašto HTTP? Prvo, mrežni administratori neće morati otvarati gomilu zasebnih priključaka za SOAP pozive... web poslužitelj može s lakoćom upravljati pozivima jer Port 80 obično je otvoren svima za primanje dolaznih zahtjeva. Još jedna prednost je proširivost web poslužitelja korištenjem CGI, ISAPI i drugih izvornih modula. Ova proširivost vam omogućuje da napišete modul koji obrađuje SOAP zahtjeve bez utjecaja na drugi web sadržaj.

To je to

Nadam se da je ovaj članak pomogao baciti malo svjetla na SOAP. Ako ste još ovdje i želite pročitati više o ovoj temi, posjetite web stranicu autora: http://www.agnisoft.com/soap

Jednostavni protokol za pristup objektu (SOAP) je protokol temeljen na XML-u koji definira pravila za prijenos poruka putem Interneta između različitih aplikacijskih sustava. Uglavnom se koristi za udaljene pozive procedura. SOAP je izvorno dizajniran da funkcionira "iznad" HTTP-a (kako bi se pojednostavila integracija SOAP-a u web aplikacije), ali sada se mogu koristiti i drugi transportni protokoli, poput SMTP.

Recimo da stvarate uslugu pristupa aplikaciji na Internetu; potrošači stupaju u interakciju s ovom uslugom dajući joj informacije. Vaši poslužitelji obrađuju podatke i vraćaju rezultate potrošačima. Koji je najbolji način za održavanje komunikacije sa sustavom?

Možete stvoriti prilagođenu aplikaciju klijent-poslužitelj i zahtijevati od korisnika da koriste prilagođeni klijentski program za pristup vašoj usluzi. Ali ako ste ozbiljni u namjeri da se nađete u internetskom poslu, morat ćete kreirati klijenta koji radi na svim mogućim klijentskim platformama - Windows, Macintosh, Unix, Linux, itd. Drugim riječima, morat ćete napisati mnogo različitih klijenata .

Što mislite o korištenju weba? Ovo rješenje je, naravno, sasvim prihvatljivo, ali je usko vezano uz implementaciju preglednika, a opet ćete morati stvoriti infrastrukturu za slanje i primanje dolaznih i odlaznih informacija, kao i formatirati i pakirati podatke za takvu razmjenu. Možete odabrati Java ili ActiveX za implementaciju složenih aplikacija, ali tada će neki korisnici odbiti vaše usluge zbog jasno prenapuhanih zahtjeva za propusnost i neadekvatne sigurnosti.

Sve što je potrebno je jednostavan protokol koji pojednostavljuje pakiranje podataka aplikacije i prenosi ih preko weba pomoću XML-a prilagođenog sadržaju. Na taj način osigurava da i pošiljatelj i primatelj mogu jednostavno protumačiti sadržaj bilo koje poruke. U isto vrijeme, zahvaljujući korištenju HTTP Web protokola kao prijenosa, bit će moguće eliminirati potrebu za smanjenjem razine zaštite vatrozidom.

Dobro opisani Simple Object Access Protocol (SOAP) je jednostavan "glue" protokol koji omogućuje hostovima daljinsko pozivanje aplikacijskih objekata i vraćanje rezultata. SOAP nudi minimalni skup uvjeta koji omogućuju aplikaciji prosljeđivanje poruka: klijent može poslati poruku za pozivanje programskog objekta, a poslužitelj može vratiti rezultate tog poziva.

SOAP je prilično jednostavan: poruke su XML dokumenti koji sadrže SOAP naredbe. Iako se SOAP teoretski može povezati s bilo kojim transportnim protokolom za aplikacije, obično se koristi u kombinaciji s HTTP-om.

Kennard Scribner, jedan od autora knjige Razumijevanje SOAP-a: mjerodavno rješenje(Macmillan USA, 2000), kaže da SOAP radi pretvaranjem informacija potrebnih za pozivanje metode (kao što su vrijednosti argumenata i identifikatori transakcije) u XML format.

Podaci se enkapsuliraju u HTTP ili neki drugi transportni protokol i šalju do primatelja, a to je obično poslužitelj. Ovaj poslužitelj izvlači SOAP podatke iz paketa, izvodi potrebnu obradu i vraća rezultate kao SOAP odgovor.

Scribner je primijetio da SOAP djeluje kao protokol za poziv udaljene procedure, slično protokolu Remote Method Invocation u Javi ili General Inter-ORB Protocolu u CORBA-i.

Budući da se HTTP i XML koriste praktički posvuda, čini se da je SOAP najskalabilniji protokol za pozivanje daljinskih procedura koji je dosad izgrađen, rekao je Scribner. SOAP nije dizajniran da djeluje kao cjelovita objektna arhitektura.

SOAP ne zamjenjuje protokol Remote Method Invocation u Javi, Distributed Component Object Model i CORBA; nudi pravila koja svaki od ovih modela može koristiti. SOAP nije potpuno rješenje. Ne podržava aktivaciju ili zaštitu objekta. Prema Scribneru, SOAP programeri "vjeruju da će korisnici sami dodati ovaj kod" tako što će ga izgraditi na vrhu SOAP-a, umjesto da ga čine dijelom samog protokola.

Na slici je prikazan primjer preuzet iz specifikacije SOAP 1.1 u kojem host zahtijeva uslugu ponude za cijenu određene dionice. SOAP zahtjev ugrađen je u HTTP POST, a tijelo zahtjeva navodi vrstu zahtjeva i parametar - simbol dionice. Odgovor također pruža XML objekt enkapsuliran u HTTP odgovoru s jednom povratnom vrijednošću (34,5 u ovom slučaju).

Značajke SOAP-a

Sa SOAP-om, programeri mogu kreirati web usluge jednako brzo kao što mogu pisati SOAP poruke za pozivanje programa za postojeće aplikacije, a zatim dodati te aplikacije na jednostavne web stranice. No osim toga, programeri imaju mogućnost koristiti SOAP pozive u namjenskim aplikacijama i stvarati aplikacije koje se mogu prenijeti na tuđe web-stranice, čime se izbjegava dugotrajan i skup razvojni proces.

Prema Marku Stiveru, drugom autoru knjige Understanding SOAP, to je upravo cilj kojem Microsoft teži sa svojom obećavajućom .Net platformom. “Ovdje SOAP blista. Programerima daje stvarno sjajan način za stvaranje aplikacija bez brige o mogućim nekompatibilnostima,” kaže on.

SOAP primjer

Sljedeći primjer ilustrira SOAP zahtjev pod nazivom GetLastTradePrice, koji klijentu omogućuje slanje zahtjeva za najnovijim kotacijama za određenu dionicu.

POST/StockQuote HTTP/1.1
Domaćin: stockquoteserver.com
Vrsta sadržaja: tekst/xml; charset="utf-8"
Duljina sadržaja: nnnn
SOAPAkcija:"Some-URI"

Prvih pet redaka (dio HTTP zaglavlja) navodi vrstu poruke (POST), host, vrstu korisnih podataka i duljinu korisnih podataka, a zaglavlje SOAPAction navodi svrhu SOAP zahtjeva. Sama SOAP poruka je XML dokument s prvo SOAP omotnicom, zatim XML elementom koji specificira SOAP imenski prostor i atribute, ako postoje. SOAP omotnica može sadržavati zaglavlje (ali ne u ovom slučaju) nakon kojeg slijedi SOAP tijelo. U našem primjeru tijelo sadrži zahtjev GetLastTradePrice i simbol dionice za koju se traže najnovije ponude. Odgovor na ovo pitanje mogao bi izgledati ovako:

HTTP/1.1 200 OK
Vrsta sadržaja: tekst/xml; charset="utf-8"
Duljina sadržaja: nnnn

Opet, prva tri retka dio su HTTP zaglavlja; Sama SOAP poruka sastoji se od omotnice koja sadrži odgovor na originalni zahtjev, s oznakom GetLastTradePriceResponse, i uključuje povratnu vrijednost, u našem slučaju 34.5.