2.1.1 Introducere
SOAP este un protocol "lightweight", XML-based pentru schimb de informatii intr-un sistem distribuit, decentralizat. Este o varianta a RPC (Remote Procedure Call).Protocolul consta din trei parti:
. Un "envelope" (infasurator) care defineste ce contine mesajul si cum trebuie prelucrat
. Un set de reguli de codificare care exprima instante de tipuri de date definite de aplicatie.
. Conventii pentru reprezentarea apelurilor de metode remote si raspunsurile la acestea
SOAP teoretic poate fi folosit in combinatie cu o gama larga de protocoale, dar singurele reguli descrise in specificatii sant cum se foloseste protocolul in combinatie cu HTTP si HTTP Extension Framework. SOAP foloseste protocolul HTTP, conexiunile HTTP, majoritatea companiilor au serverele Web configurate pe portul standard 80 pentru conexiunile HTTP, deci protocolul poate sa fie folosit fara schimbari complexe in firewall-urile retelelor, schimbari care pentru multe alte protocoale ar fi necesare.
2.1.2 Structura mesajului SOAP
Mesajele SOAP sint codificate in documente XML care este alcatuit dintr-un infasurator (SOAP envelope, obligatoriu), un header (SOAP header, optional) si un body (SOAP body, obligatoriu). De exemplu:
Obligatoriu primul element dintr-un mesaj SOAP este envelope- ul (asemanator cu plicul unei scrisori). Ofera informatii despre informatiile codificate in SOAP payload, contine informatii despre sursa mesajului, recipientul mesajului si detalii despre mesaj in sine. De exemplu, header- ul envelope- ului poate specifica exact cum mesajul trebuie sa fie procesat. Asta inseamna ca, inainte ca aplicatia sa proceseze mesajul poate afla informatii despre mesaj, includind daca aplicatia trebuie sa proceseze mesajul sau nu.
Diferit de apeluri RPC standard, unde mesajul trebuie sa fie prelucrat total ca sa aflam daca el trebuie procesat de noi sau numai trimis mai departe, header-ul SOAP poate indica daca mesajul trebuie procesat sau trimis mai departe, fara ca payload-ul sa fie parsat. Corpul mesajului contine numele metodei accesat si parametrii metodei. Exista o asemanare intre SOAP si DCOM, care poate serializa obiecte si sa-l trimita altor aplicatii unde obiectele sint deserializate si prelucrate.
2.1.3 SOAP request
Documentul SOAP este organizat intr-un nod radacina (envelope), header si body.Sectiunea body contine informatiile specifice metodei. Elementele documentului XML se mapeaza la spatii de nume XML. SOAP-ENV se mapeaza la spatiul de nume http://schemas.xmlsoap.org/soap/envelope , xsi se mapeaza la https://www.w3.org/1999/-XMLSchema-instance , xsd se mapeaza la https://www.w3.org/1999/-XMLSchema . Acestea sunt spatiile de nume standard pentru fiecare documente SOAP.
Numele intefetei (i.e., Hello) se refera la spatiul de nume, nsl. Impreuna cu valoarea parametrului, si tipul acesteia este trimis la server. Elementul radacina envelope are un atribut, encodingstyle: http://schemas.xmlsoap.org/soap/encoding/. Aceasta valoarea informeaza serverul de codificarea utilizata pentru serializarea metodei, necesar pentru server ca sa deserializeze metoda cu succes.
2.1.4 SOAP Response
Similar cu mesajul request. Elementul body contine valoare returnate de metoda apelata, care in acest exemple este mesajul "Hello" personalizat.
Formatul documentelor este flexibil, de exemplu stilul de codificare (encodingStyle) nu este fixat, se poate schimba daca partile comunicante se inteleg asupra unui stil comun.
2.1.5 SOAP intr-o aplicatie Peer2Peer
Intr-o aplicatie peer2peer clientul si serverul SOAP trebuie sa fie aceeasi. Daca folosim SOAP intr-un mediu peer2peer este impractical ca sa folosim un web server complex ca si Apache, este mai util ca sa folosim un server mai mic scris special pentru a procesa mesaje SOAP. O alta problema apare in privinta group management-ului, trebuie implementat un presence server care sa registreze sau deregistereze nodul SOAP in reteua peer2peer.
Nodul este responsabil pentru inregistrarea sa in presence service, fiecare nod poate cere lista utilizatorilor inregistrati la serviciu. O problema apare cand un nod pica si ramane inregistrat la presence service, si ceilalti incearca sa se conecteze la el. Asta inseamna ca avem nevoie si de un serviciu de inlaturare a nodurilor neprezente, nodurile trebuie sa poate notifica presence server ca un nod a picat.
Arhitectura prezentata precedent are imbunatatiri vizibile fata de modelul client-server, pentru ca orice nod poate interactiona cu orice alt nod, dar totusi avem notiunea de server care ramane "single point of failure".
2.1.6 Evaluare SOAP
. Eficienta
SOAP, desi mai potrivit pentru aplicatia noastra ca si modelul client server, tot se bazeaza pe arhitectura request/reply, ceea ce inseamna ca daca mai multe noduri vreau sa comunice cu acelasi nod in acelasi timp, un numar mare de conexiuni trebuie deschise. Ca sa fie posibil comunicarea in grup, un nod care vre sa comunice cu toate nodurile pe grup, trebuie sa deschida cate o conexiune la fiecare nod, deci solutia nu este scalabila pentru grupuri mari.
. Conectivitate la retea
Fiindca SOAP foloseste protocolul HTTP ca si mechanism de transport, si majoritatea firewallurilor permit conexiuni HTTP, aplicatia este capabil sa comunice peste orice retea. Este posibil ca SOAP sa fie folosit in mod peer2peer, acesta impune insa ca firewall-ul sa permita ca la utilizator sa se ruleze un server web/SOAP.
. Controlul schimbului de informatii
Se imbunatateste fata de modelul client-server, permite mai multa interactiune intre noduri, ficare dintre ele poate sa-si asume rolul de prezentator.
