ARIT - produzione

  • Full Screen
  • Wide Screen
  • Narrow Screen
  • Increase font size
  • Default font size
  • Decrease font size
Aree Tematiche > E-government > ICAR - Interoperabilità e Cooperazione tra le Regioni - Standard e tecnologia di riferimento

ICAR - Interoperabilità e Cooperazione tra le Regioni - Standard e tecnologia di riferimento

Email Stampa PDF
Indice
ICAR - Interoperabilità e Cooperazione tra le Regioni
A cosa serve
Normativa
Contesto
Servizi agli EELL
Perchè ICAR
Come implementare una PdD certificata
Standard e tecnologie
Infrastruttura di base
NICA
Porta di Dominio
Gestore Eventi
Tracciatura e monitoraggio
Bibliografia
Tutte le pagine

Con i termini interoperabilità e cooperazione applicativa ci si riferisce ad una specifica capacità di due o più sistemi informativi connessi in rete, ovvero la capacita che essi devono avere, affinché l’applicazione, operante in ciascun sistema, sia in grado di disporre automaticamente, per le proprie finalità applicative, dei dati che sono producibili e/o acquisibili solo attraverso il processo elaborativo delle applicazioni operanti negli altri sistemi informativi.

Interoperabilità applicativa

In particolare, l‘interoperabilità attiene alla capacità di due o più sistemi informativi di scambiarsi informazioni e di attivare, a suddetto scopo, processi elaborativi nelle rispettive applicazioni. Ciascun sistema informativo può differenziarsi in genere dall’altro per le scelte implementative (e.g. linguaggio di programmazione e formato dei dati). In tal caso, un approccio che può garantire interoperabilità è ad esempio l’adozione di uno stesso formato di interscambio dei dati e di un protocollo di comunicazione condiviso. La cooperazione applicativa attiene alla capacità di uno o più sistemi informativi di avvalersi, ciascuno nella propria logica applicativa, dell’interscambio automatico di informazioni con gli altri sistemi, per le proprie finalità applicative. In altre parole, un’applicazione nel corso del suo processo elaborativo può far così uso di un’informazione elaborata da un’altra applicazione: ad esempio un applicativo sanitario può richiedere i dati anagrafici al programma di anagrafe civile del Comune di residenza del cittadino.

Cooperazione applicativa

La cooperazione applicativa costituisce l’elemento centrale per il collegamento delle infrastrutture dati in modalità distribuita. Tale meccanismo definisce le modalità di interscambio tra Enti e consente il trasferimento delle informazioni tra le diverse strutture. Nello specifico il progetto prevede uno schema di cooperazione sia a livello regionale che a livello nazionale (Comuni, Province, ASL, Università, Comunità Montane, Enti regionali, ecc...) in modalità conforme a quanto previsto nelle linee guida e-government elaborate dal DigitPA.

La cooperazione applicativa in rete ha luogo quando ciò avviene in modo automatico. L’interoperabilità è, quindi, un prerequisito essenziale per la cooperazione applicativa. Le soluzioni per tali scopi mirano all’integrazione di nuove funzionalità, che mantengono comunque quelle autonomamente operanti nelle applicazioni già esistenti, con il pieno riuso dei relativi sistemi informativi. L’integrazione comporta l’attivazione di infrastrutture principalmente di tipo logico per l’interoperabilità, nonché l’estensione delle funzioni dell’applicazione esistente per il trattamento dei dati oggetto di scambio con le applicazioni operanti negli altri sistemi informativi, secondo le specifiche finalità della cooperazione applicativa.

Le soluzioni per tale integrazione devono ammettere altresì l’eterogeneità delle caratteristiche tecniche e funzionali delle applicazioni già esistenti e dei relativi sistemi informativi. L‘integrazione di servizi eterogenei tra Enti distanti tra loro necessita della concertazione di protocolli e standard fortemente condivisi e l’aderenza a strategie architetturali che garantiscano la interoperabilità tra i numerosi ed eterogenei soggetti coinvolti. Infatti, poiché ciascun Ente dispone di un proprio sistema informativo, le informazioni risultano fortemente frammentate e distribuite tra i differenti Enti ed anche all’interno di esse tra le diverse strutture. Inoltre, i documenti ed i dati sono strutturati, conservati e trasmessi secondo formati, modalità, sistemi di interconnessione e protocolli differenti nelle varie situazioni.

L’erogazione di servizi integrati, fra gli obiettivi del piano di azione di e-government, implica l’integrazione tra i servizi di diverse Amministrazioni mediante la realizzazione dell’interoperabilità dei sistemi informatici delle Amministrazioni stesse. Esiste un’estrema eterogeneità dei sistemi di cooperazione applicativa attualmente in uso nei progetti in essere presso le Regioni italiane. Tale eterogeneità, che deriva da necessità locali e da differenze nelle temporalità dei progetti, necessita di una standardizzazione che consenta la diffusione delle informazioni tra sistemi diversi in modo trasparente. L’infrastruttura di cooperazione ha come obiettivo la possibilità di far cooperare sistemi informativi diversi preservandone la propria indipendenza ed autonomia. Il modello è quello federativo dove, al contrario del modello gerarchico, tutti i sistemi sono paritetici e non vi sono sistemi centralizzati che ne accorpano le funzionalità, vi sono eventualmente servizi centralizzati di supporto alla cooperazione.

Questa soluzione si basa su principi quali la non intrusività, la scalabilità, la flessibilità e la standardizzazione. La non intrusività va intesa come la possibilità di far dialogare tra di loro sistemi applicativi diversi, senza alterarne il funzionamento di base. Ciò è possibile se ciascun sistema continua a funzionare come in precedenza solo con l’aggiunta di funzionalità specifiche necessarie alla cooperazione applicativa. Tali funzionalità, sfruttando le funzioni proprie del sistema, siano queste trasversali o applicative, consentono di realizzare servizi erogabili verso l’esterno con modalità e standard predefiniti.

La libertà di interconnettere nuovi sistemi o di modificare il quadro globale delle interconnessioni deve essere supportata da un’estrema flessibilità dell’infrastruttura a livello gestionale. Per questo motivo, l’infrastruttura di cooperazione avrà strumenti di configurazione e monitoraggio tali da consentire una gestione semplice ed efficace dei servizi, dei sistemi e delle interconnessioni tra di essi. La flessibilità dell’infrastruttura ne consentirà una gestione dinamica, tale da garantire la continuità del servizio.

L’elemento che consente ai sistemi di interoperare è il processo di standardizzazione delle interazioni, standardizzazione rispetto alla quale tutti i sistemi si devono poter adeguare in modo indipendente. La standardizzazione riguarda più aspetti del sistema e deve essere definita in ogni sua componente. Nel caso dell’interoperabilità tramite servizi ed eventi, la standardizzazione riguarda, oltre i protocolli di comunicazione e invocazione remota, il messaggio ed il relativo processo di gestione in termini di: struttura, formalizzazione, codifica, workflow e servizio applicativo.

Un concetto importante, espresso dalle specifiche tecniche per la cooperazione applicativa sulla Rete Nazionale, è rappresentato dal Dominio. Esso è definito come l’insieme delle risorse (in particolare le procedure, i dati e i servizi) e delle politiche di una determinata organizzazione. Il Dominio è anche definito come il confine di responsabilità di un’organizzazione. Secondo questo modello, la comunicazione avviene tra entità omogenee (i domini appunto) e lo scopo dell’architettura cooperativa è abilitare l’integrazione degli oggetti informativi (procedure e dati) e delle politiche di domini diversi.

L’elemento fondamentale è rappresentato dalla definizione delle modalità in base alle quali un dominio servente esporta i propri servizi ed un dominio cliente vi accede. L’interoperabilità fra Amministrazioni dovrà svilupparsi sulla base di standard in modo tale che:

- siano identificati i servizi ed i dati che ogni amministrazione deciderà di rendere disponibili sulla rete;

- siano rispettati, per ogni servizio esposto, le politiche di sicurezza e di accesso e di controllo di qualità e correttezza dei servizi erogati.

In questo modo si ottiene uno schema estremamente preciso in termini di suddivisione tra aree e responsabilità connesse. L’elemento tecnologico centrale per la cooperazione applicativa è rappresentato dalla Porta di Dominio. Da un punto di vista fisico, essa può essere considerata un componente infrastrutturale della Rete, un “proxy” per l’accesso alle risorse applicative.

Dal punto di vista dell’architettura applicativa, può anche essere considerata come un adattatore, che consente a sistemi informatici esistenti, o comunque realizzati in base alle esigenze del dominio specifico, di affacciarsi sulla Rete e partecipare all’interscambio telematico delle informazioni. In particolare, può trattarsi di:

- un sistema monolitico, o comunque operante su un singolo nodo presso una struttura di piccole dimensioni;

- un sistema distribuito su più nodi collegati in rete locale presso una struttura di dimensioni maggiori;

- una rete di area, alla quale sono collegati i sistemi informatici di strutture anche diverse o di una singola struttura.

Nell’ambito della definizione degli standard per la cooperazione applicativa, uno degli aspetti che deve essere normalizzato è quello dei profili di collaborazione, cioè degli schemi di interscambio di messaggi tra porte di dominio. Le collaborazioni principali prevedono l’adozione di modalità sincrone e asincrone di scambio dei messaggi. Le modalità sincrona e asincrona sono intese relativamente allo scambio di una coppia di messaggi, uno in andata e l’altro in ritorno. In uno scambio sincrono, la porta delegata che invia la richiesta di servizio, a seguito dell’invio del messaggio di andata, rimane in attesa del messaggio di ritorno. Viceversa, in uno scambio asincrono, i due messaggi di andata e di ritorno vengono scambiati senza che una delle due parti rimanga in attesa.

La scelta della modalità sincrona o asincrona può anche dipendere da aspetti legati alla latenza amministrativa delle procedure: ad esempio la necessità di intervento umano, ad esempio per l’apposizione della firma digitale di un pubblico ufficiale.

In generale, il servizio rappresenta la modalità più diretta di collaborazione tra due sistemi. Una richiesta, sottoposta da un sistema ad un altro, scatena in quest’ultimo l’esecuzione di un processo applicativo il cui risultato viene restituito sotto forma di risposta. Il servizio è tipicamente un tipo di collaborazione sincrona ma, se viene scomposto in due fasi differite nel tempo, vi è la sottomissione della richiesta e ricezione della risposta, che, dunque, può realizzare anche una collaborazione asincrona.

Il colloquio si basa sullo scambio di messaggi. L’elemento fondamentale che li caratterizza per la cooperazione applicativa è la completa e preliminare definizione del contenuto e del formato di codifica. I messaggi tra le porte di dominio sono, infatti, parte integrante di uno scambio tra applicazioni e non tra operatori umani. Di conseguenza, il contenuto di questi messaggi deve essere totalmente interpretabile in modo automatico.

Fissato lo standard tecnologico che si basa sul SOAP (Simple Object Access Protocol), l’elemento principale di un messaggio è rappresentato da una struttura XML SOAP composta da due parti:

- l’intestazione (XML SOAP Header) contiene i dati relativi al messaggio ed in particolare contiene l’identificativo del messaggio;

- la descrizione (XML SOAP Body) riporta l’indicazione del tipo di documenti informatici allegati e del relativo formato di codifica, in alternativa la ricevuta di ritorno nel caso di un servizio di notifica.

La struttura XML SOAP è inclusa in una struttura MIME allo scopo di allegare al messaggio uno o più documenti applicativi, in base allo standard XML SOAP with attachments. Una firma opzionale può essere inclusa nell’intestazione utilizzando gli standard XML SOAP Encryption e XML Signature. Nel caso di documenti informatici firmati, per la rilevanza legale si adotta il formato il PKCS#7 in base della circolare AIPA CR/24. Tali documenti saranno, fino a tale aggiornamento, inclusi sotto forma di allegato. La scelta delle strutture specifiche per la busta di e-government da utilizzare nello scambio dei messaggi costituisce una parte integrante della definizione preliminare dei servizi e non può costituire una variante da negoziarsi per ciascuno scambio.

La soluzione di adottare un’unica modalità, sia essa sincrona o asincrona, su tutto il territorio nazionale non è percorribile in virtù delle differenti realtà esistenti la cui conversione alla modalità prescelta comporterebbe degli impatti molto rilevanti in termini di tempi e di costi. D’altra parte, anche la soluzione che ogni Ente si doti delle strutture tecnico-organizzative per la realizzazione di entrambe le modalità di colloquio risulta onerosa e inutilmente ridondante. Di conseguenza è preferibile dotare il sistema di gestione del canale di interscambio e di cooperazione di un insieme di servizi di cooperazione applicativa che garantiscano il colloquio tra gli enti indipendentemente dalla modalità prescelta da ciascuno di essi.

L’adozione di un linguaggio comune prevede la scelta e l’utilizzo di standard per la rappresentazione dei dati (XML, SOAP, etc.) e dei servizi applicativi (LDAP, UDDI, WSDL, etc...), oltre alla loro definizione univoca in termini sintattici e semantici. Il formato di scambio dovrà essere quello definito dal bando dei progetti di e-Gov.

Lo strumento tecnologico per memorizzare i documenti che definiscono sintassi e semantica dei dati è individuabile in un Repository XML, mentre, per quelli che definiscono la sintassi e la semantica dei servizi, si individua un Registro dei Servizi (LDAP o UDDI). Il sistema di gestione del canale di interscambio e cooperazione mette a disposizione i servizi per l’accesso controllato alla consultazione e alla modifica, del Repository XML e del Registro dei Servizi, ferma restando la possibilità di avere una struttura federata di tali “contenitori” di informazioni.

La logica di business e le strutture dei registri dovranno essere sviluppati in accordo alle specifiche ebXML 3.0. Il modello informativo dei metadati dovrà essere aderente all’ebRIM, opportunamente verticalizzato per il dominio sanitario italiano. Il gestore eventi dovrà implementare l’interfaccia WS-BrokeredNotification, appartenente alla famiglia di specifiche WS-Notification, in modo che ogni peer od utente potrà interagire con uno qualsiasi di loro, garantendo, così, che l’intero sistema si comporti come un unico broker logico.

Standard per la sicurezza nell’interscambio delle informazioni

La sicurezza è l’insieme delle misure atte a garantire la disponibilità, la integrità e la riservatezza delle informazioni gestite. E’ un concetto fondamentale in un contesto di sistemi distribuiti che trattano dati sensibili come quelli presenti nelle basi dati delle Pubbliche Amministrazioni. Lo standard WS-Security è un protocollo di comunicazione che si applica ad architetture SOA che utilizzano il paradigma dei Web Services per l’interoperabilità applicativa. Esso stabilisce il grado di confidenzialità e le regole per verificare l’integrità delle informazioni scambiate attraverso web- services.

Uno degli aspetti fondamentali di WSS e l’uso del concetto di Security Token. Un SecurityToken è simile ad una carta d’identità o meglio ad un pass che deve essere mostrato per usufruire di un determinato WS. WS-Security è lo standard definito da OASIS che descrive gli enhancements introdotti in SOAP al fine di soddisfare i requisiti di integrità, riservatezza ed autenticazione dei messaggi. WS-Security utilizza XML-Signature per fornire l'integrità e l'autenticazione del messaggio ed XML-Encryption per la riservatezza. La specifica offre una serie di meccanismi (profili) per associare security tokens all’interno dei messaggi. I token di sicurezza previsti sono di tipo Username (UsernameToken Profile), certificati digitali X.509v3 (X.509 Token Profile), asserzioni SAML 2.0 (SAML Token Profile) per lo scambio dei dati di autenticazione ed autorizzazione tra domini di sicurezza; per l’interscambio di tali certificati tra Web Services si deve tenere in considerazione lo standard Web Services Security X.509 Certificate Token Profile. La versione utilizzata dal framework corrisponde alla specifica Web Service Security - SOAP Message Security 1.0. Il tipo di token impiegato nell’ambito della cooperazione applicativa dovrà essere la SAML assertion ver. 2.0, dichiarazione di autorizzazione espressa mediante un particolare linguaggio utilizzato, SAML, appunto, che definisce le regole e la sintassi per lo scambio di informazioni e per l’autenticazione sicura tra applicazioni. Le asserzioni SAML sono allegate al messaggio SOAP usando lo standard WSSecurity all’interno di un header.

Un sistema di Single Sign On permette l’autenticazione unica dell’attore/utente al sistema per la fruizione di una moltitudine di risorse informatiche per le quali è autorizzato. Il concetto alla base è quello di consentire ad un utente di accedere ad un sistema software complesso e consistente di più applicazioni, attraverso una unica procedura di controllo dell’accesso. Nel caso di accesso al sistema via web, ci si interfaccia una sistema che ha il compito di verificare le credenziali degli attori che saranno, in tal modo, soggette a validazione e autenticazione prima che sia effettuato l’accesso e la fruizione dei servizi.

XACML (eXtensible Access Control Markup Language) è un altro standard, basato su XML e definito dal consorzio OASIS, che ha lo scopo di dichiarare e stabilire le politiche, le regole, le condizioni, gli attori cui essi si riferiscono la sintassi e la semantica di un linguaggio per regolare l’accesso ad un sistema informativo. Tra i principali linguaggi esistenti per la definizione di politiche di controllo di accesso, XACML si distingue per il fatto di essere stato definito come standard, versatile all’impiego in svariati campi applicativi e non è invece legato, come spesso

accade per altre soluzioni, ad uno specifico contesto. Il linguaggio XACML definisce, come SAML, un protocollo di richiesta/risposta, ove le richieste indicano la volontà di accedere a particolari servizi. A livello comunicativo le interconnessioni sicure sono realizzate in tecnologia VPN (Virtual private network), cioè attraverso collegamenti in rete con le stesse caratteristiche di una connessione diretta (sicurezza, velocità) ma effettuati su reti condivise (internet). Questo tipo di connessione si stabilisce grazie alla tecnica del tunneling che consiste nel creare un canale privato tra il pc client ed il server in una rete privata o pubblica il tutto attraverso l'uso di un protocollo di comunicazione apposito il PPTP (Point to Point Tunnelling Protocol). A loro volta le reti interne di un medesimo Ente sono organizzate in VLAN (Virtual LAN) e assegnate ai diversi servizi. La realizzazione delle varie sottoreti tramite VLAN separate garantisce il massimo livello di sicurezza e di separazione fra le LAN sicure e quella insicura, ed allo stesso tempo da la possibilità di differenziare le prestazioni di rete a seconda delle esigenze dei diversi segmenti garantendo caratteristiche di scalabilità e costi ottimali.

Un ulteriore livello di sicurezza all’architettura è fornito dall’utilizzo del protocollo HTTPS, che consente di applicare al protocollo di trasferimento ipertesti (HTTP) l’algoritmo di autenticazione/crittografia asimmetrica Secure Sockets Layer (SSL): esso consente di creare un canale di interscambio cifrato tra client e server per mezzo dello scambio di certificati attraverso la rete Internet, che, una volta instaurato, consente di utilizzare al suo interno il protocollo HTTP per la comunicazione.

SPCoop, il Sistema Pubblico di Connettività

Il Sistema Pubblico di Connettività (SPC) ed il Sistema Pubblico di Cooperazione (SPCoop) forniscono l’infrastruttura comune per l’interconnessione, fino al livello applicativo, delle Amministrazioni Pubbliche, centrali e locali. Scopo dell'architettura cooperativa è di abilitare l'integrazione degli oggetti informativi (procedure e dati) e delle politiche di diversi domini, favorendo la comunicazione tra entità omogenee, garantendo autonomia alle singole amministrazioni e lasciando inalterato il loro patrimonio informativo.

Il principio di base è quello di sviluppare un’architettura organizzativa atta a garantire la natura federata, policentrica e non gerarchica del sistema. Fornire un insieme di servizi di connettività condivisi dalle Pubbliche Amministrazioni garantisce l'interazione della PA centrale e locale con tutti gli altri soggetti connessi a internet, nonché con le reti di altri enti, promuovendo l'erogazione di servizi di qualità per cittadini e imprese.

Alla base di tale architettura vi e la Porta di Dominio. Essa ha lo scopo di assicurare che lo scambio elettronico di informazioni tra le Pubbliche Amministrazioni abbia le stesse caratteristiche di quello tradizionale: l’Amministrazione che invia le informazioni in modo elettronico ad un’altra e garantita del fatto che la destinataria, e non altri, le abbia ricevute, così come la ricevente può trattare le informazioni elettroniche ottenute con pari dignità di quelle che oggi riceve con i metodi tradizionali, considerati fino ad ora gli unici probanti ai fini del procedimento amministrativo. Ciò e reso possibile indipendentemente da come viene realizzata la porta di dominio (fornitore, linguaggi, tecnologia,...) in quanto la sua interfaccia è stata definita e condivisa tra i diversi domini.

Le Porte devono interagire con i servizi applicativi esposti dalle singole Amministrazioni e colloquiare tra loro secondo gli standard definiti nell’ambito dell’SPCoop in maniera paritetica.

Per attuare tale disegno occorre che tutti gli attori (Amministrazioni centrali e locali, enti ed aziende) condividano le specifiche, gli standard e le modalità di realizzazione e gestione dei complessi elementi infrastrutturali comuni che disaccoppiano i sistemi (eventualmente legacy) delle amministrazioni ed implementano i servizi che abilitano la cooperazione applicativa tra sistemi.

Per scambiare messaggi applicativi fra Porte di Dominio si utilizza la busta di e-Government che è la definizione del formato di codifica e del contenuto dei messaggi SOAP utilizzati per implementare, sotto forma di Web services, i servizi esposti dalle Porte Applicative delle Amministrazioni Pubbliche. Lo strumento utilizzato per definire un formato dei dati condiviso tra tutte le Amministrazioni, a prescindere dai sistemi legacy e dalle basi dati, e XML. SOAP è invece utilizzato come standard per veicolare le informazioni codificate con XML sulla rete Internet mediante il protocollo HTTP. In generale, il tipo di struttura da utilizzarsi per busta e contenuto dipende dal tipo di messaggio e dalle esigenze di carattere normativo. In ambito sanitario si utilizzano esclusivamente messaggi che richiedono l'apposizione della firma digitale per garantire la fonte di provenienza delle informazioni.

SOA e Web Service

Una SOA (Service Oriented Architecture), è un‘architettura software, fortemente orientata al riuso e alla integrazione, che prevede la esposizione della logica applicativa sotto forma di servizi accoppiati tra loro in modo “debole”. A livello implementativo la tecnologia utilizzata per lo sviluppo dei servizi non è determinante: l‘idea di base è quella di racchiudere le funzionalità all’interno di interfacce che, nascondendo i dettagli tecnico/implementativi, sono esposte secondo modalità e forme documentate in modo standard e messe a disposizione su un apposito catalogo.

Si tratta di una filosofia progettuale particolarmente adatta a contesti applicativi distribuiti caratterizzati da marcata eterogeneità e complessità, forte dinamismo e elevato grado di interazione tra le diverse componenti, quale può essere il dominio applicativo sanitario. In esso infatti, è presente una molteplicità di attori che, a seconda delle specifiche situazioni, creano o utilizzano le informazioni, ed interagiscono tra loro secondo modalità non del tutto prevedibili a priori. Inoltre, molti Enti/strutture coinvolte dispongono già di un patrimonio informativo e applicativo (legacy) che costituisce un bene rilevante, sia dal punto di vista economico (in quanto frutto di consistenti investimenti), sia da quello tecnologico: tale patrimonio richiede da un lato di essere preservato e dall’altro di essere messo in condizione di interagire con gli omologhi di altri enti, qualunque siano le piattaforme applicative sulle quali sono stati realizzati.

Una delle tecnologie maggiormente utilizzate per la realizzazione di architetture orientate ai servizi è quella dei Web Services, una specifica di protocolli e standard utilizzata per realizzare comunicazioni tra applicazioni di diversa natura interconnessi ad una medesima rete per garantirne l’interoperabilità. I Web Services sono pensati per realizzare dei blocchi funzionali indipendenti che, nel complesso, possano costituire un ambiente applicativo. Essi godono di alcune proprietà che li rendono particolarmente adatti per essere impiegati all’interno delle SOA. Una di queste proprietà è la completa autonomia che caratterizza ciascun servizio rispetto agli altri: ogni servizio è responsabile di un proprio dominio, con conseguente formazione di unità funzionali ben delineate e blandamente collegate tra loro mediante la aderenza ad uno standard di comunicazione. In virtù della indipendenza di cui i servizi godono, la logica applicativa che ciascun servizio incapsula non deve conformarsi a nessuna piattaforma particolare. Affinché essi possano offrire un'interfaccia software, sono descritti in un formato automaticamente elaborabile quale, ad esempio, il Web Services Description Language, utilizzando la quale altri sistemi possono interagire con il Web

Service stesso attivando le operazioni descritte nell'interfaccia tramite appositi "messaggi" inclusi in una "busta", in particolare la SOAP: tali messaggi sono, solitamente, trasportati tramite il protocollo HTTP e formattati secondo lo standard XML. Essi godono di alcune proprietà che li rendono particolarmente adatti per essere impiegati all’interno delle SOA. In virtù della indipendenza di cui i servizi godono, la logica applicativa che ciascun servizio incapsula, non deve conformarsi a nessuna piattaforma particolare. Proprio grazie all'utilizzo di standard basati su XML, tramite un'architettura SOA, applicazioni software scritte in diversi linguaggi di programmazione ed implementate su diverse piattaforme hardware possono, quindi, essere utilizzate tramite le interfacce che queste "espongono" pubblicamente e mediante l'utilizzo delle funzioni che sono in grado di effettuare (i "servizi" che mettono a disposizione) per lo scambio di informazioni e l'effettuazione di operazioni complesse sia su reti aziendali, come su Internet.

Tutti i dati scambiati sono formattati mediante tag XML in modo che gli stessi possano essere utilizzati ad entrambi i capi delle connessioni; il messaggio può essere codificato conformemente allo standard SOAP. L'interfaccia pubblica di un Web Service viene descritta tramite WSDL, un linguaggio basato su XML usato per la creazione di "documenti" descrittivi delle modalità di interfacciamento ed utilizzo del Web Service. La centralizzazione della descrizione e della localizzazione dei Web Service in un registro comune permette la ricerca ed il reperimento in maniera veloce dei Web Service disponibili in rete; a tale scopo viene attualmente utilizzato il protocollo UDDI.

I Web service hanno, inoltre, guadagnato consensi visto che, come protocollo di trasporto, possono utilizzare HTTP over TCP sulla porta 80; tale porta è, normalmente, una delle poche (se non l'unica) lasciata aperta dai sistemi firewall al traffico di entrata ed uscita dall'esterno verso i sistemi aziendali e ciò in quanto su tale porta transita il traffico HTTP dei web browser: ciò consente l'utilizzo dei Web Service senza modifiche sulle configurazioni di sicurezza dell’Amministrazione, un aspetto che, se da un lato è positivo, solleva preoccupazioni concernenti la sicurezza, motivo per cui si rendono necessari meccanismi di autenticazione dei Web Services stessi.

 



Non viene fatto uso di cookie per le informazioni di carattere personale, né vengono utilizzati cookie persistenti di alcun tipo ovvero sistemi per il tracciamento utenti. Se vuoi consultare la cookie policy clicca sul link. Chiudendo questo banner, scorrendo questa pagina, cliccando su un link o proseguendo la navigazione in altra maniera, acconsenti all'uso dei cookie. Consulta la nostra pagina sulla privacy.

Accetto cookie da questo sito.