Integrazione con sistemi informativi esterni (guida per le software house)
Nella seguente sezione viene resa disponibile una guida su come integrare i propri sistemi informativi con il Sistema Informativo Nazionale della Farmacosorveglianza.
Le tecnologie adottate
Viene fornita una panoramica generale, che vuole essere solo una guida introduttiva e non una trattazione esaustiva, sulle tecnologie e metodologie generali previste per l'integrazione dei sistemi informativi esterni con il Sistema Informativo Nazionale della Farmacosorveglianza.
JSON
JSON (Javascript Object Notation) è un formato ormai standard di interscambio dei dati, basato sulla struttura degli oggetti e degli array in JavaScript e viene usato come alternativa a XML/XSLT.
JSON è un formato di testo completamente indipendente dal linguaggio di programmazione, facile da leggere e scrivere per le persone, mentre per le macchine risulta facile da generare e analizzarne la sintassi.
JSON si basa su un sottoinsieme del Linguaggio di Programmazione JavaScript, Standard ECMA-262 Terza Edizione - Dicembre 1999. JSON quindi non è stato creato nel senso letterale del termine, poichè la notazione letterale degli oggetti è una delle caratteristiche già presenti nel linguaggio JavaScript. Si può dire che JSON sia stato riscoperto come formato per lo scambio dati specialmente nella programmazione in AJAX.
Il seguente esempio rappresenta i dati dell'anagrafica di una persona in formato JSON:
{
"name": "Mario",
"surname": "Rossi",
"active": true,
"favoriteNumber": 42,
"birthday": {
"day": 1,
"month": 1,
"year": 2000
},
"languages": ["it", "en"]
}Maggiori informazioni al seguente indirizzo: https://www.json.org
SOAP vs REST
Allo stato attuale esistono due approcci alla creazione di Web Service:
un approccio è basato sul protocollo standard SOAP (Simple Object Access Protocol), per lo scambio di messaggi per l’invocazione di servizi remoti;
un secondo approccio è basato sulla descrizione di risorse, sul modo di individuarle nel Web e sul modo di trasferirle da una macchina all’altra (approccio che prende il nome di REST - REpresentational State Transfer).
La prima evidente differenza tra i due tipi di Web Service è la visione del Web proposta come piattaforma di elaborazione. REST propone una visione del Web incentrata sul concetto di risorsa mentre i SOAP Web Service mettono in risalto il concetto di servizio:
- un Web Service RESTful è custode di un insieme di risorse sulle quali un client può chiedere le operazioni canoniche del protocollo HTTP;
- un Web Service basato su SOAP espone un insieme di metodi richiamabili da remoto da parte di un client.
Formalmente, REST definisce un insieme di principi architetturali per la progettazione di un sistema. Rappresenta uno stile architetturale che vede il Web come una piattaforma per l’elaborazione distribuita. L’approccio REST si basa sui seguenti principi:
- Identificazione delle risorse;
- Utilizzo esplicito dei metodi HTTP;
- Risorse autodescrittive;
- Collegamenti tra risorse;
- Comunicazione senza stato.
L’approccio dei SOAP Web service ha mutuato un’architettura applicativa denominata SOA, Service Oriented Architecture, a cui si è recentemente contrapposta l’architettura ROA,Resource Oriented Architecture, ispirata ai principi REST.
Il protocollo SOAP (Simple Object Access Protocol) definisce una struttura dati per lo scambio di messaggi tra applicazioni, riproponendo in un certo senso parte di quello che il protocollo HTTP faceva già. SOAP utilizza HTTP come protocollo di trasporto, ma non è limitato nè vincolato ad esso, dal momento che può benissimo usare altri protocolli di trasporto.
A differenza di HTTP, però, le specifiche di SOAP non affrontano argomenti come la sicurezza o l’indirizzamento, per i quali sono stati definiti standard a parte, nello specifico WS-Security e WS-Addressing.
Quindi SOAP non sfrutta a pieno il protocollo HTTP, utilizzandolo come semplice protocollo di trasporto. REST invece sfrutta HTTP per quello che è, un protocollo di livello applicativo, e ne utilizza a pieno le potenzialità.
REST non prevede esplicitamente nessuna modalità per descrivere come interagire con una risorsa. Le operazioni sono implicite nel protocollo HTTP. Qualcosa di analogo a WSDL è WADL, Web Application Definition Language, un’applicazione XML per definire risorse, operazioni ed eccezioni previsti da un Web Service di tipo REST.
Negli ultimi anni l’approccio REST è venuto alla ribalta come metodo per la realizzazione di Web Service altamente efficienti e scalabili ed ha al suo attivo un significativo numero di applicazioni. Il motivo è semplice: dal momento che il Web ha tutto quello che serve per essere considerata una piattaforma di elaborazione distribuita secondo i principi REST, non sono necessarie altre sovrastrutture per realizzare quello che è il Web programmabile.
L’approccio REST è attualmente lo standard "de-facto" per la realizzazione di Web Service altamente efficienti e scalabili.
SERVIZI REST
I Web service consentono di far interagire due applicazioni indipendentemente dal sistema operativo su cui girano e dal linguaggio di programmazione utilizzato. L'approccio ai Web service adottato per il Sistema Informativo Nazionale della Farmacosorveglianza è l'approccio REST (Representational State Transfer).
REST definisce un insieme di principi architetturali per la progettazione di un sistema: rappresenta uno stile architetturale, cioè non si riferisce ad un sistema concreto e ben definito nè si tratta di uno standard stabilito da un organismo di standardizzazione.
In sintesi, nella visione RESTful un Web service non definisce una funzione richiamabile da remoto ma mette a disposizione delle risorse su cui è possibile effettuare le classiche operazioni CRUD sfruttando i metodi del protocollo HTTP. Una risorsa è generalmente un’istanza di una classe che viene inviata al client dopo averla serializzata. Ciascuna risorsa è rintracciabile sul Web tramite uno specifico URI. La gestione dei metodi HTTP applicabili alle risorse è affidata ai Controller, un tipo di classe i cui metodi implementano le richieste giunte all’applicazione via HTTP.
Le caratteristiche principali di REST sono:
- le risorse sono sempre identificate da un URI univoco;
- il client ha la possibilità di negoziare il formato dei dati che si attende come risposta:
- XML,
- JSON.
Affinchè un servizio sia considerato di tipo RESTful è anche necessario avere le seguenti caratteristiche:
- le azioni effettuate sulle risorse sono veicolate attraverso i verbi HTTP:
- GET,
- POST,
- PUT/PATCH,
- DELETE;
In sostanza, un client richiede l’esecuzione di un metodo HTTP, ad esempio GET, su una risorsa identificata da un URI. Il server, interpretando l’URI, individua il controller associato alla risorsa e, in base allo specifico metodo HTTP ed ai parametri specificati dal client, invoca il metodo corrispondente.
Il risultato dell’esecuzione del metodo è una risorsa e/o un codice di stato HTTP. Se viene restituita una risorsa, questa viene serializzata in base al formato richiesto dal client tramite l’intestazione HTTP Accept.
Nell'implementazione dei servizi REST adottata per il Sistema Informativo della Farmacovigilanza, si è adottata una soluzione REST (e non RESTfull) che prevede l'utilizzo del solo metodo GET. Tale scelta tecnica è stata fatta per garantire compatibilità con tutte le possibili configurazioni e blocchi per la sicurezza di Firewall, Web Application Firewall, ecc.
Maggiori informazioni su REST ai seguenti indirizzi:
Esempio invocazione servizio REST
URL del servizio REST
Il servizio REST JSON è esposto al seguente URL (endpoint):
<url_server>/autorizzazione/detenzione/ws/insert/ (dove <url_server> varia in base all'ambiente: test o produzione)
Header
L’invocazione del servizio WEB REST deve avere i seguenti headers:
Sicurezza
Vengono di seguito descritti i protocolli e tecnologie adottate per garantire la sicurezza delle API esposte come servizi WEB dal Sistema Informativo Nazionale della Farmacosorveglianza.
Protocollo di autenticazione in ambiente di test
Un aspetto importante di REST è la gestione della sicurezza: le risorse esposte via Web devono essere accessibili e manipolabili soltanto dagli utenti autorizzati. In altre parole, si ha bisogno di un meccanismo per gestire l’autenticazione degli utenti e l’autorizzazione all’accesso delle risorse. Dal momento che le API di tipo RESTful si ispirano all’adozione di HTTP come protocollo centrale, l’approccio migliore da adottare nell’implementazione di un meccanismo di autenticazione è la HTTP Basic Authentication. Esso si basa essenzialmente nell’invio di nome utente e password con ogni richiesta HTTP. Dal momento, però, che le credenziali vengono inviate in chiaro, è opportuno che esse viaggino all’interno di un canale sicuro HTTPS, cioè HTTP over SSL/TLS.
In ambiente di test è possibile invocare i servizi REST sfruttando il meccanismo di Basic Authentication. Nell'invocazione del servizio REST va quindi aggiunto anche il seguente header:
1 Authorization:Basic <BASE_64_DI "USERNAME:PASSWORD">
Protocollo di autenticazione in ambiente di produzione
L'accesso alle API di servizi web esposte dal Sistema Informativo Nazionale della farmacosorveglianza è protetto utilizzando access tokens. Più in particolare l'infrastruttura dei servizi esposti dal Sistema Informativo Nazionale della Farmacosorveglianza, relativamente alla parte di autenticazione e autorizzazione, è stata realizzata basandosi sul framework OAuth2, definito nell’rfc6749 (https://tools.ietf.org/html/rfc6749).
OAuth2
I dettagli tecnici del framework OAuth2 possono essere recuperati dai seguenti link:
Accedere alle API utilizzando Access Tokens - OAuth2
Per invocare i servizi tramite OAuth2 è necessario:
1. ottenere un access token (come da rfc6749); nel seguente documento è specificato come richiedere gli access token OAuth2:
2. utilizzare l'access token appena ottenuto per invocare il servizio (come indicato nell'rfc6750); per riassumere, basta inserire il token tra come request header in questo modo:
Authorization: Bearer <<<access token>>>