2.3. SOAP¶

Il protocollo SOAP (Simple Object Access Protocol) è stato sviluppato per superare le limitazioni imposte dai protocolli precedenti per l’interazione distribuita basata su oggetti (CORBA, Java/RMI, DCOM) relative alla distribuzione a livello Internet delle macchine interessate ed ai vincoli imposti dal punto di vista delle tecnologie di implementazione.

La versione corrente della specifica “SOAP è la 1.2 del 27 Aprile 2007 <https://www.w3.org/TR/soap12-part1/>`_ [45]. La specifica definisce due stili di comunicazione (communication modes):

• quello basato su chiamata a procedura (RPC-like),
• e quello basato su scambio di documenti (document style).

In combinazione ad essi, il protocollo definisce delle modalità di scambio dell’informazione:

• interazioni one-way (dal client al server),
• interazioni request/response,
• invio di notifiche (interazione one-way dal server al client)
• e solicit/response (interazione request/response in cui la request è inviata dal server).

Le ultime due modalità sono poco utilizzate in pratica e fuori dai profili di interoperabilità standard, quindi il loro utilizzo è vietato.

Il protocollo SOAP definisce tre componenti fondamentali:

• una envelope (letteralmente «busta da lettere») che definisce la struttura del messaggio e come processarlo;
• un insieme di regole di codifica per esprimere istanze di tipi di dato definiti a livello applicativo;
• una convenzione per rappresentare lo stile di interazione RPC.

La definizione del protocollo è pensata per essere indipendente dal protocollo sottostante. In particolare, SOAP può operare (tramite i cosiddetti binding) su diversi protocolli di trasporto inclusi HTTP, SMTP, TCP, UDP o JMS. Sebbene implementazioni sono state proposte per ognuno di questi casi (in special modo JMS per interazioni asincrone), il mercato ha premiato principalmente soluzioni sincrone basate su HTTP.

Una delle caratteristiche che contraddistinguono il protocollo SOAP è la sua estensibilità. In particolare si indica con WS-* lo stack di estensioni costruite su SOAP, molte delle quali hanno avuto grande successo in termini di implementazioni disponibili. Queste estensioni permettono di avere su SOAP una serie di funzionalità che su altri protocolli devono essere costruite ad-hoc. Lo svantaggio di questa soluzione è che il protocollo introduce un overhead di processamento che fa preferire altre soluzioni in determinati contesti.

Tra le estensioni supportate dai framework più diffusi abbiamo:

• WS-Addressing è un modo standard per includere informazioni circa l’instradamento dei messaggi (ad es., l’interfaccia di servizio a cui inviare la risposta o da contattare in caso di errore).
• WS-Security è la specifica che descrive le politiche di sicurezza implementate a livello applicativo dalle interfacce di servizio. In particolare, WS-Security include meccanismi per autenticazione e autorizzazione, confidenzialità, integrità e firma digitale.
• WS-Trust è una estensione a WS-Security che permette di richiedere, rinnovare e validare token di sicurezza. Permette inoltre di verificare la relazione di mutua fiducia su un canale sicuro.
• WS-Federation è una estensione che permette a differenti domini di sicurezza di scambiare informazioni circa identità, attributi di autorizzazione ed autenticazione.
• WS-ReliableMessaging permette di consegnare in maniera affidabile (ad es., nell’ordine corretto) messaggi SOAP in presenza di problemi di rete e di inattività di componenti software e di sistema.
• WS-AtomicTransaction è una estensione che permette di ottenere la proprietà tutto o niente per un gruppo di operazioni. Essa definisce tre protocolli (completamento, two-phase commit volatile e two-phase commit durevole) che sono implementati dal framework
• WS-Coordination.
• WS-Choreography è la specifica per la definizione di coreografie. Una coreografia specifica i passi relativi allo scambio di messaggi tra diversi soggetti che si integrano.
• WS-BPEL è la specifica per la definizione di orchestrazioni.
• WS-Coordination è un framework estensibile per il coordinamento di web service (corrispondenti alle interfacce di servizio). In particolare esso spiega come implementare (e quindi è preso a riferimento dalle varie implementazioni dello stack WS-*) i protocolli di coordinamento inclusi quelli descritti da WS-AtomicTransaction.

La specifica delle interfacce di servizio SOAP è effettuata tramite Web Services Description Language - WSDL [46]. Oltre ad indicare le funzionalità offerte dall’interfaccia di servizio dal punto di vista funzionale, esso permette anche di definire le caratteristiche non funzionali tramite le estensioni WS-Policy [47] che permettono di specificare le varie componenti della QoS.