Cats_01

Tijekom prošlih godina, Web je napravio veliku revoluciju načina korištenja informacijske tehnologije, i kao rezultat, naš način rada je kompletno promijenjen.

Posao interneta sada mora da se suoči sa dvije rastuće potrebe: zadovoljavanje novih zahtjeva (uglavnom zbog rasta 'apetita' klijenata) i integracije različitih informacijskih sustava. Očito je da korisnici danas žele sve više i više od raznih servisa. Oni žele da servisi rade za njih, da im uštede vrijeme i novac, i rješavaju probleme. Nakon statičkog Web-a, došao je dinamički a sad se razvija interaktivni Web (ili ).

Trenutačni problem uključuje integraciju i koordinaciju svih ovih servisa. Komponente koje se trebaju integrirati su često različitog tipa, dok nedostaje alata i konvencija koje bi sve to omogućile. Rješenje počiva u jednostavnom, protokolu: protokolu poput SOAP-a (Simple Object Access Protocol). Zaista, SOAP je dizajniran sa ovim problemima u vidu: oslanjajući se na standarde, nudi način da programi komuniciraju bez obzira na sustav koji koriste. Prva implementacija SOAP-a je bazirana na HTTP-u i XML-u.

Ideja o stvaranju ovakvog bogatog inter-aplikacijskog sustava je relativno nova. Među najšire primjenjivanim Remote Procedure Calls (RPC), može se navesti Microsoftov DCOM ili Object Managment Group-ov IIOP (Internet Inter-ORB Protocol). Kada se međutim govori o komunikaciji među samim servisima/metodama putem interneta, navedeni protokoli otkrivaju svoja ograničenja (ovo je uglavnom zbog kompleksnosti implementacije istih, te aplikacija koji ih koriste). Internet ne može garantirati o kijentu/serveru koji postoji sa odgovarajuće strane veze - ono može samo garantirati o upotrijebljenom HTTP protokolu kao komunikacijskog medija. Uviđamo dakle, značaj HTTP-a kao komunikacijskog protokola među Web servisima.

SOAP su prvenstveno stvorili Microsoft, DevelopMentor, te Userland Software nakon čega je razvoj proslijeđen Internet Engineering Task Force-u (IETF), koji su ga eventualno dovršili i predstavili službenu specifikaciju. Osnovnu specifikaciju završio je u proljeću 1998 Dave Winer iz UserLand Software-a. Njegova XML-RPC specifikacija, na kojemu se SOAP temelji, gotovo je identična originalnoj specifikaciji. Sa SOAP-om 1.1, IBM i Lotus pridružili su se DevelopMentor-u, Microsoft-u i Userland Software-u, i to sa ovećom grupom partnera: 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 and Zveno Pty. Ltd. Ovo mnoštvo IT poduzeća očigledan je dokaz da SOAP ima potencijal stvarno obećavajućeg protokola

Sadržaj

3. Što to SOAP ima, što drugi nemaju?

SOAP pruža rješenje za spajanje Web strana i aplikacija, kako bi stvorili . Autori specifikacije odlučili su da SOAP bude sustav niže razine. Jasno su se izjasnili da ne žele definirati kompletnu distribuciju.

Različiti sustavi, poput Windows-a i UNIX-a, često koegzistiraju unutar poduzeća. Često se može činiti jako teškim prilagoditi projekte tako, da temelje svoj informacijski sustav na jednoj jedinstvenoj tehnologiji. Da bi omogućili RPC komunikaciju između različitih sustava, sve što je potrebno je komunikacija temeljena na uzajamno razumljivim jezicima i protokolima: HTTP i XML. Kako ove različite sredine često mogu komunicirati preko HTTP-a, SOAP pruža način komunikacije među nekompatibilnim sustavima, uz minimalni razvoj tehnologije.

Čitavi ovaj princip, koji uključuje jasno razlikovanje između prijenosa informacija u smislu njegovog prezentiranja (HTML) i samih informacija (XML), pruža mogućnost filtriranja informacija kako prije, tako i nakon njegovog prikaza odn. čitanja. Za ovo je uglavnom odgovoran sam XML (njegova cjelokupna struktura), ali i send struktura SOAP poruka, u kojima se parametri poruke navode u zaglavlju XML dokumenta. Određeni oprez se pri tome zahtjeva, budući da HTTP i SOAP zaglavlja nemaju iste uloge: prvi služi za prijenos informacije do odredišta, dok je uloga drugoga u definiranju onoga tko obrađuje informacije i na koji način.

U svojoj najnovijoj inačici (1.1), SOAP dodaje jasna pravila za podršku novijim protokolima kao SMTP i FTP, što ga čini općenitijim protokolom za razmjenu informacija. Također uvodi i pojam intermediaries (posrednika - zaustavljanja (stops) između SOAP poziva i endpointa koji ne utječu na sadržaj poruke, korisno za usmjeravanje poruka/informacija). Na ovaj način, SOAP poruka može slati dijelove informacija koji dolaze do svog odredišta putem lanca posrednika. Informacije koji se odnose na razne posrednike i podatci koji su njima posvećeni nalaze se u zaglavlju SOAP poruke, dok se informacije u samom tijelu (body) SOAP poruke proslijeđuju krajnjem korisniku.

U danom trenutku, interoperabilnost nije uvijek 100% izvediva. Postojeće implementacije naime, ne zadovoljavaju traženu pouzdanost. Onaj tko želi iskoristiti SOAP u projektu morat će to učiniti sa oprezom. Još će proteći neko vrijeme prije nego li se implementacije SOAP-a optimiziraju i osposobe mogućnošću pružanja usluge gateway-ameđu raznim jezicima. Međutim, jedan rijetki događaj vrijedan spomena je W3C-ova izjava o stvaranju grupe sa ciljem standardizacije protokola temeljenih na XML-u (posebice SOAP), te da se rezultati očekuju unutar slijedećih godinu dana. U dodatku navedenome, OMG postavlja sebi zadatak unaprijeđivanja CORBE u smislu kompatabilnosti sa navedenim komunikacijskim protokolom

SOAP-ova mogućnost obilaženja vatrozida bez poteškošća moglo bi dovesti do problema. Vatrozidovi općenito osiguravaju sigurnost putem autoriziranja ili blokiranja poziva na određenim portovima. Praćenje HTTP protoka informacija moglo bi postati još složenije budući da sigurnosna rješenja ne samo da moraju zaključiti o formatu poruke unutar dane mreže, već i njihov sadržaj. Da bi se ovo ostvarilo, nove naredbe (tagovi, verbs) se predstavljaju u novijim proširenim inačicama HTTP protokola. Naredbe poput M-POST, stvorene su kako bi pojednostavnili administraciju vatrozida i proxy-a.

SOAP je jednostavan specifikacijski protokol upotebljavan za pozivanje metoda na serverima, komponentama i objektima kako bi pružio uslugu razmjene informacija u decentraliziranom i distribuiranom okruženju. Ovaj protokol, temeljen na XML-u, prenešen HTTP-om, može se rastaviti na tri funkcionalne cijeline:

Struktura SOAP omotnice (envelope) definira općenitu strukturu koja izražava sadržaj, izvršnog organa (misli se na entitet koji eventualno izvršava kod, ako ovakav kod uopće postoji...), te obaveznu/neobaveznu prirodu same poruke.
SOAP-ova pravila kodiranja definiraju mehanizam koji se može upotrijebiti za razmjenu instanci aplikacijski-definiranih tipova podataka.
SOAP-ov RPC (Remote Protocol Call) definira konvenciju koja se može upotrijebiti za predstavljanje inih poziva procedura i njihovih odgovora.

XML dio svake SOAP poruke sadrži određene tag-ove i atribute. Ono se sastoji od:

SOAP omotnice: ovo je prvi element u XML dokumentu koji predstavlja poruku.
SOAP zaglavlje (proizvoljno): ovo je generički mehanizam koji dodaje izvjesne karakteristike SOAP poruci. SOAP definira nekoliko atributa koji se mogu upotrijebiti za donošenje zaključka o tome tko procesira karakteristike, te da li je ovaj postupak obavezan ili nije.
SOAP tijelo: ovo je spremnik za obaveznu informaciju koja se proslijeđuje krajnjem korisniku.

Omotnica je prvi dio SOAP poruka i ona je obavezna. Sadrži ime elementa (Omotnice), nakon čega slijedi tzv. namespace koji definira upotrijebljenu verziju SOAP-a, te opcionalni encodingStyle atribut koji pokazuje na link gdje se definiraju struktura (tipa stablo), te pravila za kodiranje. Omotnica je prikazana kako slijedi:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="
http://schemas.xml.org/soap/envelope/" SOAP-ENV
:encodingStyle="http://schemas.xml.org/soap/
encoding/"/> . </SOAP:Envelope>

Namespaces se upotrebljavaju kako bi pružili kontekst i garantirali jednoznačnost elemenata opisanih na ovaj način.

Ovo je proizvoljni dio SOAP poruke sadržan u SOAP omotnici. Ono nosi informacije posrednicima, te se sastoji od jednog ili više unosa/podataka, koji uključuju lokalno ime, puno ime, namespace, dva atributa koji određuju odredište unosa, te tzv. mustUnderstand koji upućuje na proizvoljnu prirodu/narav procesa. SOAP aplikacija mora sadržavati valjani SOAP namespace za sve elemente i atribute definiranih u generiranoj poruci. Ovo je URI koji upućuje na opis informacija u poruci kako bi osigurao jedinstvenost same poruke. DTD-ovi se nikada ne upotrebljavaju.

Informacije koje obrađuje krajnji korisnik (endpoint) nalaze se upravo u tijelu SOAP poruke. Ono može sadržavati niz entiteta koji se nalaze u korijenu (root-u) tijela poruke.

<SOAP-ENV:Body>
<m:NewCustomer xmlns:m="Some-URI">
<Name>Dumser</Name>
<Surname>Johann</Surname>
<City>Cambridge</City>
<ZipCode>01800</ZipCode>
<State>MA</State>
<Country>USA</Country>
</m:NewCustomer>
</SOAP-ENV:Body>

HTTP zaglavlje nalazi se neposredno prije SOAP poruke. HTTP protokol šalje POST zahtjev putem mreže. Linije ovog koda opisane su kako slijedi:

U prvom retku, send metoda, URI zahtjev, te sama verzija protokola su definirani:

Slijedeća tri reda upotrebljavaju se za definiranje MIME formata za prikaz poruke, HTTP kodiranje, te duljinu same poruke.

Nakon ovoga, dodaju se metode kao npr. SOAPAction (SOAPMethodName) koji određuju namjenu HTTP zahtjeva. Identifier koji slijedi znak # mora odgovarati imenu prvog tag-a u tijelu SOAP poruke.

Dolje se nalazi primjer zahtjeva za SOAP porukom, nakon čega slijedi slikovito objašnjenje istog.

POST /EventManager HTTP/1.1
Host: www.techmetrix.com
Content-Type: text/xml;
charset="utf-8"

Content-Length: 60 SOAPAction="http://www.techmetrix.com/Event
#New Customer"

<SOAP-ENV:Envelope xmlns:SOAP-ENV=" http://schemas.xml.org/soap/envelope/"
SOAP-ENV :encodingStyle="http://schemas.xml.org/soap/
encoding/"/> <SOAP-ENV:Header>
<t:Name
xmlns:t="www.techmetrix.com/EventManager"
SOAP-ENV :actor="http://schemas.xml.org/soap/actor /next/" SOAP-ENV :mustUnderstand="1"> Dumser
</t:Name >
</SOAP-ENV:Header>
<SOAP:Body> <m:NewCustomer xmlns:m="www.techmetrix.com/Event"> <Entreprise>SQLI</Entreprise>
<Address>Paris</Address> </m:NewCustomer> </SOAP:Body>
</SOAP:Envelope>

Uzmimo za primjer dijalog među uređajem koji izvršava upitnik i uređaja koji ispunjava isti. Procedura koja se pri tome izvršava objašnjena je kako slijedi:

1) Uređaj 1 izvršava naredbu koja stvara akciju na odgovarajućem aplikacijskom serveru.

2) Ova naredba generira proces unutar aplikacije, a rezultat se javlja u sučelju aplikacije.

3) Poruka se prevodi u XML format (putem implementacije...), nakon čega se šalje Web serveru.

4) XML parser provjerava dosljednost XML dokumenta i šalje SOAP poruku putem HTTP protokola.

5) XML parser provjerava valjanost poruke pomoću HTTP i XML zaglavlja, te ga prihvaća ili odbija.

6) Poruka se zatim preusmjerava odgovarajućem aplikacijskom serveru i prevodi putem implementacije, tako da zadatak postaje značajan za implementaciju. SOAP aplikacija koja prima SOAP poruku mora postupiti kako slijedi kako bi prevela poruku:

Identificirati dijelove SOAP poruke koji odgovaraju aplikaciji.
Provjeriti da su svi obvezni dijelovi podržani aplikacijom ili u suprotnom odbacuju/zanemaruju poruku.
Izbacuje sve dijelove prije prijenosa poruke ukoliko aplikacija nije endpoint.

8) Povrat informacije odvija se na isti način: implementacija, pa slanje putem HTTP -a.

9) Rezultat ove akcije može variriati: prikaz u browseru, razne akcije, pristup bazi podataka, i slično.

Iako na začetku svoga razvoja, te je malo postojećih implementacija, SOAP je po svojoj sintaksi jednostavan, što je jako važno za uspjeh novonastalih standarda. Također, SOAP nudi i jednostavnost implementacije u postojeće protokole i programske jezike, što je također velika prednost. Konačno, SOAP je izuzetno obećavajući standard, te ga valja uzeti u obzir kao rješenje u interakciji heterogenih sustava.