Uniface e i Web Services, 1. parte – Generalità

Il W3C definisce un “web service” come “un modulo software disegnato per supportare l’interoperabilità e l’interazione tra macchine collegate in rete”.
I Web Services sono univocamente il fulcro delle possibili integrazioni tra ambienti applicativi eterogenei per piattaforma, sistema, linguaggio ma le tecnologie utilizzate si differenziano; negli anni aziende diverse, leader di mercato, hanno  sfortunatamente avuto idee diverse su quale potesse essere la soluzione ideale per garantire interoperabilità ed interazione in rete. Questo fatto ha generato sostanzialmente due tipi diversi di Web Services:
1 – basati sulla specifica SOAP
2 – in linea con i criteri REST
La specifica SOAP è di poco più anziana dei criteri REST (SOAP 1.0 del 1998, mentre 2000 Tesi di laurea di Roy Fielding per REST) ma mentre SOAP è stato adottato da subito su larga scala, REST ha ricevuto una notevole spinta solo negli ultimi anni, in base al suo ampio utilizzo dovuto alla semplicità dei criteri che lo caratterizzano, in linea con le tecnologie comunemente in uso. Va chiarito che REST NON è una specifica formale ma una serie di criteri oggetto di raccomandazione a supporto di una architettura software per la gestione di dati in ambiente ipertestuale.

Un minimo di approfondimento su entrambi i tipi di Web Services:
SOAP = acronimo per Simple Object Access Protocol: può operare su differenti protocolli di rete, ma HTTP è il più comunemente utilizzato per il trasporto, anzi è l’unico ad essere stato standardizzato dal W3C. La busta SOAP si basa su XML e la sua struttura segue la classica configurazione Head-Body, analoga ad HTML. Il segmento opzionale Header contiene meta-informazioni come quelle che riguardano il routing, la sicurezza, le transazioni e parametri per l’Orchestration. Il segmento obbligatorio Body trasporta il contenuto informativo che talora viene detto carico utile (payload). Questo deve seguire uno schema definito dal linguaggio “XML Schema”. SOAP può essere utilizzato in due modi diversi:
– il client controlla in un Service Registry l’oggetto d’interesse e sviluppa il messaggio secondo i parametri contenuti nel Service Registry.
– il client conosce a priori i parametri e non necessita di consultare il service registry. All’interno del body del messaggio si inseriscono i dati scritti nel formato concordato.

REST = acronimo per REpresentational State Transfer: Web services di tipo REST permettono di richiedere ad un sistema l’accesso a determinate risorse ricevendo in cambio una rappresentazione testuale delle medesime attraverso l’uso di un predefinito ed uniforme insieme di operazioni “stateless”. Le risorse sono identificate attraverso un URI (Uniform Resource Identifier) mentre le operazioni che si utilizzano sono quelle tipiche del protocollo HTTP (HTTP verbs): GET, POST, PUT, DELETE, OPTIONS. La rappresentazione testuale della risorsa ricevuta in risposta può essere strutturata in modi diversi, ad esempio: XML, HTML, JSON o addirittura semplice testo; JSON è il formato che più ha preso piede nel corso del tempo. Un sistema che voglia essere pienamente compatibile con una architettura REST dovrebbe comprendere ed implementare in modo rispettoso le seguenti caratteristiche:
– modello client-server: separazione netta delle competenze, client = interfaccia, server = accesso funzionale alle informazioni.
– dialogo di tipo stateless: ciascuna richiesta da un qualunque client contiene tutte le informazioni necessarie e lo stato della sessione è totalmente gestito lato client. Lo stato della sessione può essere trasferito al server e, se necessario, mantenuto persistente per il tempo necessario a gestire la transizione allo stato successivo.
– risposte cacheable: ogni tipo di dialogo web deve essere definito “cacheable” o “non cacheable”; i servizi REST dovrebbero sempre essere gestibili in cache dai nodi sui quali transitano.
– sistema a livelli: ogni client non deve riconoscere se è collegato al server vero e proprio o ad un suo intermediario; gli intermediari diversi possono essere implementati al fine di poterli  specializzare su funzioni diverse (sicurezza, gestione dei carichi e conseguente scalabilità, ecc)
– “code on demand”: alcuni server possono, anche su base temporanea, estendere, anche in modo specifico, le funzionalità di un client attraverso il trasferimento di codice eseguibile.
– interfaccia uniforme: è fondamentale nella definizione di qualsiasi insieme di servizi REST; dovrebbero SEMPRE essere soddisfatte le seguenti linee guida:
. Identificazione delle risorse: specifiche risorse sono identificate nella richiesta, per esempio utilizzando direttamente URI di riferimento. L’identificazione delle risorse da richiedere è concettualmente separata dalla loro rappresentazione restituita al richiedente. Ad esempio: il server può inviare informazioni dal suo database come HTML, XML o JSON, la cui struttura nulla ha a che vedere con quella interna del server.
.. Manipulazione delle risorse mediante la loro rappresentazione: quando un client riceve la reppresentazione di una risorsa, inclusi eventuali metadati, ottiene sufficienti informazioni per modificare o cancellare la risorsa.
… Messaggi auto-descrittivi: ciascun messaggio include sufficienti informazioni per permetterne la completa gestione del suo contenuto. Ad esempio: quale parser va invocato per riconoscere il contenuto potrebbe essere specificato con un “Internet media type” (conosciuto anche come MIME type).
…. Hypermedia come motore degli stati applicativi (HATEOAS): avendo avuto accesso una applicazione REST inizialmente a un URI, il client REST dovrebbe essere in grado di avere sufficenti informazioni, per essere in grado di utilizzare i (hyper)link ricevuti per accedere a tutte le ulteriori possibili azioni o risorse necessarie. Mano a mano che il dialogo tra server e client prosegue il server restituisce ulteriori (hyper)links che abilitano il client all’esplorazione dell’ecosistema applicativo disponibile sul server.

Entrambi i protocolli si basano su trasporto mediante HTTP ed entrambi sono correntemente supportati da Uniface:
– SOAP con il driver SOP: inizialmente in versione 1.0, ora in versione 2.0.
– REST sin da Uniface7 con la costruzione di componenti Web che restituiscono un contenuto coerente con i criteri elencati.
Nella seconda parte vedremo dei semplici esempi di come si implementano o come si fruisce di “web services” con Uniface con entrambi i protocolli.

Comments are closed.