Linee Guida per la pubblicazione di Servizi in E015 ... Linee Guida per la pubblicazione di Servizi...
45
Linee Guida per la pubblicazione di Servizi in E015 – Digital Ecosystem Versione 1.0 Data di rilascio: 4/10/2012
Transcript of Linee Guida per la pubblicazione di Servizi in E015 ... Linee Guida per la pubblicazione di Servizi...
Linee Guida per la pubblicazione di Servizi in E015 – Digital Ecosystem
Versione 1.0 Data di rilascio: 4/10/2012
2 di 45
Contenuti
1 Introduzione ........................................................................................................................................................................... 4
2 Processo di pubblicazione dei Servizi in “E015 – Digital Ecosystem” ............................................................ 5
3 “Descrittore del Servizio” .................................................................................................................................................. 7
3.1 Aspetti di interoperabilità ....................................................................................................................................... 9
3.1.1 Gli aspetti di interoperabilità all’interno del descrittore del servizio ......................................... 9
3.1.2 Standard tecnologici e Linee Guida per l’interoperabilità ............................................................... 9
3.2 Accesso sicuro ai servizi ........................................................................................................................................ 14
3.2.1 Gli aspetti di sicurezza all’interno del descrittore del servizio ................................................... 14
3.2.2 L’approccio dell’Ecosistema per l’accesso sicuro ai servizi da parte delle applicazioni ... 14
3.2.3 Linee guida tecnologiche per la gestione dell’accesso “restricted” ai servizi (meccanismo di attestazione) ................................................................................................................................................................... 15
3.2.4 Linee guida tecnologiche per la gestione degli aspetti di sicurezza dei servizi.................... 17
3.3 Glossari dei servizi .................................................................................................................................................. 20
3.3.1 Gli aspetti relativi ai glossari all’interno del descrittore del servizio ....................................... 20
3.3.2 Linee Guida per la gestione dei glossari all’interno dell’Ecosistema ........................................ 20
3.4 Aspetti di monitoraggio dei servizi .................................................................................................................. 23
3.4.1 Gli aspetti relativi al monitoraggio all’interno del descrittore del servizio ........................... 23
3.4.2 L’approccio dell’Ecosistema per il monitoraggio dei servizi ........................................................ 23
3.5 Aspetti correlati all’erogazione dei servizi .................................................................................................... 25
3.5.1 Gli aspetti relativi all’erogazione all’interno del descrittore del servizio ............................... 25
3.5.2 Impegni / capacità di erogazione ............................................................................................................ 25
3.5.3 Logiche di remunerazione .......................................................................................................................... 26
3.5.4 Dimensionamento dei flussi informativi .............................................................................................. 27
3.6 Aspetti legati all’azienda erogatrice dei servizi ........................................................................................... 28
3.6.1 Gli aspetti relativi all’azienda all’interno del descrittore del servizio ...................................... 28
3.6.2 Linee Guida per la gestione degli aspetti relativi all’azienda ....................................................... 28
3.6.3 Linee Guida per la pubblicazione sul proprio sito web istituzionale delle informazioni sui servizi di E015 – Digital Ecosystem ........................................................................................................................... 29
3.7 Ciclo di vita dei servizi (“lifecycle”) .................................................................................................................. 30
3.7.1 Gli aspetti relativi al lifecycle all’interno del descrittore del servizio ...................................... 30
3.7.2 Il ciclo di vita dei servizi di E015 – Digital Ecosystem .................................................................... 30
3.8 Policies dei servizi ................................................................................................................................................... 33
3.8.1 Gli aspetti relativi alle policies all’interno del descrittore del servizio .................................... 33
3.8.2 Approccio dell’Ecosistema per la gestione delle policy dei servizi ........................................... 33
4 Verifiche del Technical Management Board per la pubblicazione dei servizi .......................................... 35
3 di 45
4.1 Elementi di verifica da parte del Technical Management Board ......................................................... 35
4.2 Esito del processo di verifica............................................................................................................................... 35
Allegato 1. Descrittore del servizio ................................................................................................................................. 37
Allegato 2. Template e Linee Guida per sezione “E015 – Digital Ecosystem” su proprio sito web istituzionale .......................................................................................................................................................................... 41
Allegato 3. Principali traiettorie di evoluzione delle tecnologie dell’Ecosistema ....................................... 43
Allegato 4. Aspetti di interoperabilità: il caso particolare della Cooperazione Applicativa ................... 45
4 di 45
1 Introduzione
“E015 – Digital Ecosystem” offre ai soggetti aderenti numerose opportunità (sinteticamente riportate nello schema in Figura 1):
a. Mettere a disposizione un servizio. Il soggetto aderente pubblica all’interno dell’Ecosistema un servizio disponibile per la realizzazione di applicazioni End User. Contestualmente alla pubblicazione, il Service Provider stabilisce le condizioni di utilizzo e le opzioni selezionate per la fruizione dei dati e delle funzionalità erogate dal servizio.
b. Mettere a disposizione una applicazione. Il soggetto aderente pubblica all’interno di E015 – Digital Ecosystem una End User Application, realizzata utilizzando alcuni dei servizi resi disponibili da parte di altri soggetti.
c. Mettere a disposizione un servizio di Identity Provider. Il soggetto aderente agisce in qualità di Identity Provider specializzato nella gestione dell’Identità Digitale e pubblica all’interno dell’Ecosistema uno speciale servizio condiviso per la verifica della validità delle credenziali degli utenti finali. La disponibilità di servizi di questo tipo (denominati servizi di IdP) abilita la separazione di ruoli tra chi fornisce funzionalità applicative agli utenti e chi si occupa della gestione dell’identità digitale degli utenti. I servizi di IdP consentono di “agganciare” a E015 – Digital Ecosystem i bacini di utenza da essi gestiti e possono essere utilizzati da parte degli End User Application Provider per l’esternalizzazione delle funzionalità di verifica e gestione delle credenziali utente.
d. Mettere a disposizione un glossario. Il soggetto aderente propone di pubblicare all’interno dell’Ecosistema un glossario condiviso che possa essere utilizzato come schema di classificazione e data model di riferimento da parte di chi sviluppa applicazioni e servizi all’interno di uno o più domini applicativi. Il Technical Management Board ed il Governance Board possono a loro volta decidere di recepire all’interno dell’Ecosistema glossari condivisi ritenuti significativi per maturità e grado di diffusione.
Figura 1 – Opzioni disponibili per i soggetti aderenti all’Ecosistema
Il presente documento indica le modalità operative e le Linee Guida tecnologiche che è necessario seguire al fine di poter pubblicare un servizio all’interno di “E015 – Digital Ecosystem”.
5 di 45
2 Processo di pubblicazione dei Servizi in “E015 – Digital Ecosystem”
La pubblicazione dei servizi all’interno di E015 – Digital Ecosystem si svolge in modo controllato, in accordo a un processo di pubblicazione ben preciso che prevede l’interazione tra il Service Provider e l’Ecosistema stesso.
Tale processo di pubblicazione è raffigurato in Figura 2.
Figura 2 – Processo di pubblicazione dei servizi in E015 – Digital Ecosystem (da sinistra a destra il flusso delle attività che ogni soggetto svolge e la corrispondente sincronizzazione)
Viene riportata nel seguito una descrizione di tutti i passi che caratterizzano il processo di pubblicazione dei servizi all’interno dell’Ecosistema.
Si precisa che le interazioni tra il Service Provider ed E015 – Digital Ecosystem sono supportate da un ambiente di interazione disponibile online attraverso il quale gestire le richieste di pubblicazione dei servizi ed i necessari scambi informativi (incluse eventuali notifiche).
FASE DI PROCESSO DESCRIZIONE
Selezione funzionalità di
interesse da esporre
Il Service Provider identifica le funzionalità di interesse che ritiene opportuno esporre sotto forma di servizi tecnici all’interno di E015 – Digital Ecosystem. Tale valutazione di opportunità viene eseguita dal Service Provider in accordo alle proprie strategie aziendali o al proprio ruolo istituzionale.
Le funzionalità che il Service Provider può decidere di mettere a disposizione sotto forma di servizio all’interno dell’Ecosistema riguardano in generale informazioni o funzionalità specifiche del Service Provider stesso, direttamente o indirettamente correlate al proprio settore di attività.
Sviluppo e configurazione
servizio
I servizi che possono essere pubblicati all’interno di E015 – Digital Ecosystem devono essere realizzati secondo gli standard tecnologici e le Linee Guida riportate nel presente documento. Non sono ammesse eccezioni.
6 di 45
Elaborazione descrittore del servizio
Questa attività ha come scopo principale la compilazione del documento che descrive ogni servizio da pubblicare. Tale documento – che prende il nome di “Descrittore del servizio” (cfr. Allegato 1) – è di fondamentale importanza per l’Ecosistema e riassume le principali informazioni del servizio. Esso consente agli End User Application Provider di valutare l’opportunità di utilizzare il servizio, oltre che verificarne i dettagli di tipo tecnico per svolgere le attività di integrazione.
Invio descrittore del servizio e Richiesta
di esposizione
Il Service Provider invia all’Ecosistema il “Descrittore del Servizio” compilato in ogni sua parte, unitamente ad una richiesta di pubblicazione del servizio stesso; in questo modo il Service Provider si rende disponibile affinché il Technical Management Board possa effettuare le verifiche necessarie per approvare o meno la richiesta di pubblicazione del servizio.
Verifica servizio
Il Technical Management Board prende in carico la richiesta di pubblicazione trasmessa dal Service Provider e procede con le attività di verifica necessarie. I dettagli sulla procedura di verifica del servizio da parte del Technical Management Board sono forniti nel capitolo 4 del presente documento.
Accettazione richiesta di
pubblicazione
Nel caso in cui tutte le verifiche effettuate siano andate a buon fine, il Technical Management Board accetta la richiesta di pubblicazione del servizio inviata da parte del Service Provider.
Il Technical Management Board registra e archivia il descrittore del servizio e inserisce parte delle informazioni in esso contenute all’interno del Registro dei Servizi ufficialmente pubblicati all’interno di E015 – Digital Ecosystem.
Qualora la richiesta di pubblicazione non potesse essere accettata (ad esempio, per motivi di non conformità del servizio con le Linee Guida tecnologiche dell’Ecosistema), il Technical Management Board interagirà con il Service Provider al fine di indirizzare le problematiche riscontrate e favorire in questo modo l’accettazione della richiesta di pubblicazione.
Notifica pubblicazione
servizio
E015 – Digital Ecosystem inoltra al Service Provider la notifica di accettazione della richiesta di pubblicazione.
Da questo momento in poi il Service Provider può utilizzare il riconoscimento ufficiale che certifica l’appartenenza all’Ecosistema.
Il Service Provider è tenuto a dare comunicazione sul proprio sito web istituzionale dell’avvenuta pubblicazione del proprio servizio all’interno dell’Ecosistema, in accordo alle Linee Guida riportate nel paragrafo 3.6.
Esercizio servizio Il Service Provider eroga il servizio in accordo alle Linee Guida dell’Ecosistema e secondo gli impegni verso l’Ecosistema assunti tramite il’ “Descrittore del Servizio”.
Tabella 1 – Descrizione delle fasi del processi di pubblicazione di un servizio
Si precisa che durante tutte le fasi sopra riportate il Technical Management Board è a disposizione dei Service Provider e svolge un ruolo di supporto e di facilitazione al fine di consentire ai soggetti aderenti di poter portare a termine con successo le procedure di pubblicazione del propri servizi.
Si precisa inoltre che tutte le indicazioni e le Linee Guida specifiche per poter portare a termine con successo la procedura di pubblicazione del servizio sono rese disponibili ai Service Provider all’interno dell’ambiente web di interazione con E015 – Digital Ecosystem.
7 di 45
3 “Descrittore del Servizio”
L’elemento cardine per la pubblicazione dei servizi all’interno di E015 – Digital Ecosystem è rappresentato dal “Descrittore del Servizio” (riportato in forma completa nell’Allegato 1).
Il “Descrittore del servizio” indirizza nel suo complesso tematiche di tipo tecnologico – per consentire l’integrazione dei servizi all’interno delle applicazioni –e fornisce numerose informazioni sul servizio, tenendo in considerazione ad esempio anche aspetti di tipo organizzativo e di policies che regolamentano l’utilizzo del servizio stesso.
In Figura 3 sono riportate tutte le dimensioni necessarie per la documentazione dei servizi esposti all’interno dell’Ecosistema, da dettagliare nel documento specifico.
Figura 3 – Dimensioni di interesse per la descrizione dei servizi di E015 – Digital Ecosystem
E’ necessario che ognuna di queste dimensioni sia adeguatamente documentata affinché un “servizio” possa essere pubblicato all’interno dell’Ecosistema.
Di seguito un breve riassunto delle dimensioni di interesse indirizzate dal “Descrittore dei servizio”:
aspetti di interoperabilità (paragrafo 3.1): rientrano in questa categoria tutti gli aspetti di tipo tecnico necessari per poter invocare i servizi pubblicati all’interno dell’Ecosistema ed integrarli all’interno delle applicazioni End User (ad esempio, la documentazione dell’interfaccia del servizio);
accesso sicuro ai servizi (paragrafo 3.2): rientrano in questa categoria tutti gli aspetti tecnologici ed organizzativi necessari per la gestione degli aspetti di sicurezza legati all’erogazione dei servizi (ad esempio, per la restrizione dell’accesso ai servizi ai soli soggetti autorizzati da parte del Service Provider, per mezzo di uno specifico meccanismo in seguito denominato “meccanismo di attestazione”);
glossari dei servizi (paragrafo3.3): aspetti di documentazione legati al modello dei dati gestiti dal servizio (entità, concetti e loro rappresentazione);
8 di 45
aspetti di monitoraggio dei servizi (paragrafo3.4): rientrano in questa categoria tutti gli aspetti necessari affinché E015 – Digital Ecosystem sia in grado di monitorare costantemente la disponibilità dei servizi messi a disposizione da parte dei Service Provider;
aspetti correlati all’erogazione dei servizi (paragrafo3.5): rientrano in questa categoria gli aspetti riguardanti eventuali “Logiche di remunerazione” correlate all’utilizzo dei servizi e gli aspetti di “Qualità” di erogazione dei servizi ;
aspetti legati all’azienda (paragrafo 3.6): rientrano in questa categoria gli aspetti di tipo organizzativo correlati all’erogazione dei servizi (es: referente del servizio verso E015 – Digital Ecosystem) e di comunicazione;
ciclo di vita dei servizi (paragrafo 3.7): questa dimensione di interesse fornisce indicazioni relativamente al periodo nel quale il Service Provider si impegna verso l’Ecosistema a mantenere attivo il proprio servizio;
policies dei servizi (paragrafo 3.8): sezione del descrittore che riporta i termini e le condizioni di utilizzo con cui sono esposti i servi sull’Ecosistema e che ciascun soggetto utilizzatore del servizio si deve impegnare a rispettare nei confronti del Service Provider.
Nei prossimi paragrafi vengono forniti tutti i dettagli e le indicazioni operative per indirizzare ciascuna di queste dimensioni.
9 di 45
3.1 Aspetti di interoperabilità
3.1.1 Gli aspetti di interoperabilità all’interno del descrittore del servizio
Si riportano nella tabella seguente i campi del descrittore del servizio che indirizzano direttamente gli aspetti legati all’interoperabilità dei servizi.
CAMPO DESCRIZIONE
Tecnologia Tecnologia di riferimento con la quale il servizio è stato implementato.
Interfaccia del servizio
Riferimento a uno o più file allegati al descrittore che documentano l'interfaccia del servizio in modo completo per un utilizzatore.
Modello dei dati Riferimento a uno o più file allegati al descrittore che documentano la struttura delle richieste e delle risposte in modo completo per un utilizzatore.
Pattern di interazione
Paradigma di interazione con il servizio.
I valori ammissibili per questo attributo del descrittore sono:
request-response;
publish & subscribe.
Sono riportate nel seguito gli standard tecnologici e le relative linee guida per la gestione degli aspetti di interoperabilità dei servizi di E015 – Digital Ecosystem.
3.1.2 Standard tecnologici e Linee Guida per l’interoperabilità
3.1.2.1 Tecnologie per i servizi SOAP I Web Service SOAP rappresentano un meccanismo consolidato, condiviso e diffuso a supporto delle interazioni applicative ‘machine-to-machine’.
La Web Services Interoperability Organization (WS-I, http://www.oasis-ws-i.org/), ha assunto il compito di definire profili di interoperabilità standard tra Web Service SOAP a diversi livelli. Ciascun profilo raccomanda un insieme “minimo” coerente di specifiche standard non proprietarie per promuovere e realizzare l’interoperabilità tra Web Service SOAP.
Tra i profili WS-I, il WS-I Basic Profile (BP) si occupa in particolare di normare le dimensioni tecnologiche basilari per l’interoperabilità tra Web Services quali la specifica dell’interfaccia, la rappresentazione del modello dei dati, i meccanismi di trasporto e scambio messaggi ecc.
Esistono attualmente diverse versioni del WS-I Basic Profile (v1.0 errata: 25 ottobre 2005, v1.1 final: 10 aprile 2006, v1.2 e v2.0 final: 9 novembre 2010), le più recenti delle quali sono riassunte nella tabella che segue.
Per ciascuna versione del BP la tabella riassume le tecnologie citate, raggruppate per categoria, evidenziando le principali differenze e le novità rispetto alla versione precedente del profilo (in rosso).
10 di 45
WS-I Basic Profile 1.1
•Messaging
•Simple Object Access Protocol (SOAP) 1.1
•RFC2616: Hypertext Transfer Protocol - HTTP/1.1
•RFC2965: HTTP State Management Mechanism
•Service description
•Extensible Markup Language (XML) 1.0 (Second Edition)
•Namespaces in XML 1.0
•XML Schema Part 1: Structures
•XML Schema Part 2: Datatypes
•Web Services Description Language (WSDL) 1.1
•Service Publication and Discovery
•UDDI Version 2.04 API Specification, Dated 19 July 2002
•UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002
•UDDI Version 2 XML Schema
•Security
•RFC2818: HTTP Over TLS
•RFC2246: The TLS Protocol Version 1.0
•The SSL Protocol Version 3.0
•RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
WS-I Basic Profile 1.2
•Messaging
•[idem BP1.1]
•WS-Addressing 1.0 - Core
•WS-Addressing - SOAP Binding (except for sections 2, 3, 5.1.2, 5.2.2 and 6.1)
•WS-Addressing 1.0 - Metadata (except for sections 4.1.1, 4.4.2, 4.4.3 and 5.2)
•SOAP 1.1 Request Optional Response HTTP Binding
•SOAP Message Transmission Optimization Mechanism
•XML-Binary Optimized Packaging
•SOAP 1.1 Binding for MTOM 1.0
•Service Description
•[idem BP 1.1]
•WSDL Corrections
•Errata rispetto a WSDL 1.1
•Service Publication and Discovery
•[idem BP 1.1]
•Security
•[idem BP 1.1]
WS-I Basic Profile 2.0
•Messaging
•SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)
•SOAP Version 1.2 Part 2: Adjuncts (Second Edition)
•RFC2616: Hypertext Transfer Protocol - HTTP/1.1
•RFC2965: HTTP State Management Mechanism
•WS-Addressing 1.0 - Core
•WS-Addressing 1.0 - SOAP Binding (except for sections 4, 5.1.1, 5.2.1 and 6.2)
•WS-Addressing 1.0 - Metadata (except for sections 4.1.1, 4.4.2, 4.4.3 and 5.2)
•SOAP Message Transmission Optimization Mechanism
•XML-Binary Optimized Packaging
•XML Media Types
•Service Description
•[idem BP 1.1 e 1.2]
•WSDL Corrections
•[idem BP 1.2]
•Service Publication and Discovery
•[idem BP 1.1 e 1.2]
•Security
•[idem BP 1.1 e 1.2]
Figura 4 – Versioni del WS-I Basic Profile a confronto
Il punto di riferimento iniziale a supporto dell’interoperabilità dei Web Services SOAP in E015 – Digital Ecosystem è il WS-I Basic Profile versione 1.1.
Inoltre, a corredo o a complemento delle diverse versioni del BP la OASIS WS-I organization ha definito i seguenti profili:
Simple SOAP Binding Profile (v1.0 final: 24 agosto 2004): indica requisiti specifici sulla serializzazione delle buste SOAP e la relativa rappresentazione nei messaggi di richiesta e risposta,
Attachments Profile (v1.0 final: 20 aprile 2006): complementa il BP 1.1 relativamente all’uso di SOAP with Attachments,
Basic Security Profile (v1.0 final errata: 5 luglio 2010, v1.1 final: 24 gennaio 2010): Fornisce requisiti specifici per rappresentare e veicolare le informazioni di sicurezza legate a un Web Service. Le considerazioni relative alla sicurezza dei servizi SOAP sono riportate nella sez. 3.2.4.1.
Le linee guida per la pubblicazione all’interno dell’Ecosistema Digitale Expo di servizi della Pubblica Amministrazione erogati su rete SPCoop è illustrata nell’Allegato 4.
Considerazioni sul modello dei dati
La selezione congiunta di un sottoinsieme di tecnologie standard è un elemento abilitante per l’interoperabilità applicativa, tuttavia è necessario indirizzare altri aspetti legati all’interoperabilità e relativi in particolare alle modalità di utilizzo degli standard tecnologici selezionati.
11 di 45
Da questo punto di vista, un ruolo di particolare importanza riveste il modello dei dati su cui si basano le interfacce dei servizi. In generale, le specifiche dei Web Service non entrano nel merito del modello dei dati di un servizio. Per garantire l’interoperabilità e la qualità dei servizi esposti in E015 – Digital Ecosystem, in aggiunta alle specifiche tecniche occorre introdurre opportune linee guida relative al modello dei dati e in generale all’interfaccia di un servizio.
Uso di XML Schema (http://www.w3.org/XML/Schema)
È opportuno fare riferimento a tipi standard della specifica XML Schema anziché creare tipi “custom” (esempi: ‘xs:date’, ‘xs:duration’, ‘xs:gYear’).
Si sconsiglia di utilizzare tipi generici (es. ‘xs:string’) per rappresentare dati strutturati.
In caso di campi alfanumerici aventi una formattazione specifica, è opportuno restringere l’uso del tipo ‘xs:string’ utilizzando opportuni pattern (esempi: ‘CAP’, ‘codice fiscale’, ‘codice Istat comune’).
Valutare sempre l’uso di tipi già definiti nei Glossari condivisi dell’Ecosistema (esempi: ‘visitatore’, ‘point of interest’, ‘evento’).
WSDL (http://www.w3.org/TR/wsdl) e parametri di input e output
Si sconsiglia di utilizzare tipi “opachi” (per esempio in formato ‘base64binary’) nei parametri di input e output di un servizio: l’uso di tipi non opachi abilita controlli strutturali (validazione rispetto allo schema XML) che possono essere effettuati già a livello di interfaccia anziché essere rimandati a livello applicativo affidandoli alla logica interna di funzionamento del singolo servizio.
Adottare sempre, quando possibile, il Document/Literal Style.
3.1.2.2 Tecnologie per i servizi REST I servizi REST rappresentano una modalità alternativa per la pubblicazione e fruizione di servizi su protocollo HTTP rispetto ai servizi SOAP. REST non impone particolari vincoli sulle tecnologie da adottare, per esempio relativamente alla descrizione dell’interfaccia o al modello dei dati. Tuttavia esistono alcune specifiche che possono essere utilizzate in ambito REST per coprire determinate dimensioni di interoperabilità (es. WADL per la descrizione dell’interfaccia di un servizio).
I servizi REST pubblicati in E015 – Digital Ecosystem devono essere accompagnati da una adeguata documentazione, in particolare per quanto riguarda:
il modello e il formato dei dati,
le operazioni fornite dal servizio.
Per il modello dei dati dei servizi REST si richiede di utilizzare in particolare:
XML Schema (http://www.w3.org/XML/Schema) per i dati in formato XML,
JSON Schema (http://json-schema.org/) per i dati in formato JSON.
Per la pubblicazione e il discovery di servizi REST si può fare riferimento agli standard Atom (http://www.ietf.org/rfc/rfc4287.txt) e RSS (http://www.rssboard.org/rss-specification).
Per realizzare la sicurezza di canale è opportuno utilizzare sempre il protocollo HTTPS. Per ulteriori considerazioni relative alla sicurezza dei servizi REST si veda la sez. 3.2.4.2.
12 di 45
3.1.2.3 Tecnologie per i servizi Publish/Subscribe E015 – Digital Ecosystem intende supportare scenari in cui da una parte vi sono soggetti, per esempio i servizi, che pubblicano notifiche (notify) e dall’altra vi sono altri soggetti, per esempio le applicazioni, che sono interessati a ricevere notifiche per erogare le proprie funzionalità (subscribe).
END USER
APPLICATIONS
LINEE GUIDA e SPECIFICHE TECNICHE per USER APPLICATIONS
LINEE GUIDA e SPECIFICHE TECNICHE per SERVICES
PROCESSI E METODOLOGIE
GOVERNANCE
EXTERNAL
SERVICES
SERVICES
App
Servizio
Broker
P&S
SUBSCRIBE
NOTIFY
Figura 5 – Approccio al publish/subscribe nell’Ecosistema
Nell’ambito dell’Ecosistema è possibile adottare i seguenti due approcci (non mutuamente esclusivi) al Publish/Subscribe:
Notification Dispatcher pubblicato dal singolo Service Provider: in questo caso è il singolo provider del servizio a implementare internamente la logica di subscribe e notify necessaria a supportare il funzionamento del proprio servizio (es. propagazione di informazioni ai soggetti interessati).
Broker Publish/Subscribe esposto da un Service Provider: in questo caso il servizio di sottoscrizione e notifica è fornito come servizio trasversale erogato da un provider di E015 – Digital Ecosystem e messo a disposizione di altri soggetti. Per esempio, può trattarsi di servizi di notifica dedicati destinati a domini verticali o specifiche categorie di eventi.
La tecnologia di riferimento è WS-Notification (http://www.oasis-open.org/committees/wsn/), attuale specifica di riferimento in ambito Web Service SOAP.
Nel caso in cui si intendesse pubblicare all’interno dell’Ecosistema un servizio di tipo Publish&Subscribe è necessario assegnare all’attributo “Pattern di interazione” del descrittore del servizio il valore Publish&Subscribe.
Qualora invece si intendesse pubblicare un servizio sincrono di tipo request-response è necessario assegnare all’attributo “Pattern di interazione” del descrittore del servizio il valore Request-
Response.
3.1.2.4 Tecnologie per gli Open Data
L’attuale tendenza in atto per l’eGovernment è di mettere a disposizione in rete alcune tipologie di dati in modo che siano liberamente accessibili a tutti, senza restrizioni di copyright, brevetti o altre forme di controllo che ne limitino la riproduzione. Gli Open Data attualmente disponibili però sono spesso pubblicati in formati eterogenei, anche proprietari, e senza una adeguata documentazione.
13 di 45
All’interno di E015 – Digital Ecosystem si intende rendere omogenee le modalità di pubblicazione degli Open Data al fine di agevolarne la fruizione. A tal fine, l’esposizione dei dati deve avvenire attraverso una delle tecnologie previste per l’erogazione di servizi, cioè i Web Service SOAP o i servizi REST.
Inoltre, il modello dei dati di tali servizi deve essere il più possibile strutturato, adottando gli opportuni standard già citati in precedenza (XML e XML Schema o JSON e JSON Schema). Il modello dei dati deve poi essere accompagnato da opportuna documentazione e deve referenziare ove possibile i glossari condivisi.
Infine, deve sempre essere adottata una opportuna licenza per l’accesso ai dati, per esempio:
Creative Commons (http://creativecommons.org/licenses/),
Open Data Commons (http://www.opendatacommons.org/licenses/),
Italian Open Data License – IODL (http://www.formez.it/iodl/),
Copyright con termini definiti ad hoc.
È particolarmente importante che la licenza disciplini aspetti quali la proprietà dei dati pubblicati, la possibilità di rielaborare i dati pubblicati, l’obbligo di citare la fonte ecc.
A tendere, si intende seguire il trend evolutivo da Open Data a Open Linked Data (http://linkeddata.org/), ovvero passare da insiemi semplici di dati strutturati pubblicati su Web a collezioni complesse di dati strutturati distribuiti e interconnessi mediante annotazioni semantiche, per esempio mediante RDF (http://www.w3.org/RDF/).
14 di 45
3.2 Accesso sicuro ai servizi
3.2.1 Gli aspetti di sicurezza all’interno del descrittore del servizio
Si riportano nella tabella seguente i campi del descrittore del servizio che indirizzano direttamente gli aspetti legati all’accesso sicuro ai servizi.
CAMPO DESCRIZIONE
Livello di accesso
Indicazione del livello di accesso previsto per il servizio.
I valori ammissibili sono:
Community: per servizi accessibili da parte di qualsiasi applicazione dell’Ecosistema;
restricted: per servizi con accesso limitato alle sole
applicazioni dell’Ecosistema esplicitamente autorizzate
Certificato X.509 Riferimento al certificato X.509 associato al servizio, necessario per abilitare il meccanismo di attestazione dell’appartenenza all’Ecosistema
Aspetti di sicurezza specifici
Riferimento a uno o più file allegati al descrittore che documentano eventuali aspetti di sicurezza specifici che è necessario conoscere per utilizzare correttamente il servizio.
3.2.2 L’approccio dell’Ecosistema per l’accesso sicuro ai servizi da parte delle applicazioni
Nell’ambito di E015 – Digital Ecosystem il Service Provider, per ciascuno dei servizi erogati, deve esplicitare all’interno del descrittore se intende consentire l’accesso a tutte le applicazioni dell’Ecosistema (senza la necessità di una autorizzazione esplicita) oppure se intende restringere l’accesso alle sole applicazioni autorizzate.
E015 – Digital Ecosystem non interviene nella definizione e nell’attuazione delle policy specifiche di accesso ai servizi (in carico ai Service Provider), ma tiene traccia all’interno del descrittore se il servizio è accessibile da parte di tutte le applicazioni dell’Ecosistema oppure se solo da parte di specifiche applicazioni autorizzate.
In particolare all’interno del descrittore, relativamente alla sezione “Accesso al servizio”, sarà possibile selezionare una delle seguenti opzioni per l’attributo “Livello di accesso”:
1. Community. Il servizio è accessibile da parte di tutte le applicazioni dell’Ecosistema senza
la necessità di una autorizzazione esplicita da parte del Service Provider. L’Ecosistema invia al Service Provider una notifica ogni qualvolta un servizio di tipo community viene richiesto da parte di un End User Application Provider. In questo modo E015 – Digital Ecosystem consente al Service Provider di essere a conoscenza di quali siano gli utilizzatori del proprio servizio.
2. Restricted. L’accesso è consentito alle sole applicazioni esplicitamente autorizzate da
parte del Service Provider. In questo caso, l’Ecosistema inoltra ai Service Provider le eventuali richieste di utilizzo ricevute da parte dei soggetti interessati e tiene traccia della risposta specificata da parte dei Service Provider (di tipo “allow” / “deny”). In questo modo, E015 – Digital Ecosystem è in grado di stabilire, ad un dato momento, quali applicazioni sono state esplicitamente autorizzate all’accesso. Il Service Provider ha la possibilità in ogni momento di revocare l’accesso al servizio da parte di una applicazione, ad esempio in seguito alla rilevazione di una violazione dei relativi termini di utilizzo 1.
1 Anche in questo caso, è necessario che il Service provider comunichi all’Ecosistema l’avvenuta revoca dell’accesso.
15 di 45
Il meccanismo attraverso il quale E015 – Digital Ecosystem consente ai Service Provider di gestire la restrizione dell’accesso ai propri servizi a tutte le applicazioni dell’Ecosistema (nel caso di servizi “Community”) o alle sole applicazioni dell’Ecosistema esplicitamente autorizzate (nel caso di servizi “Restricted”) prende il nome di “Meccanismo di attestazione”.
Grazie al meccanismo di attestazione i servizi hanno la possibilità di determinare a quali applicazioni dell’Ecosistema appartengono le invocazioni ricevute.
Da un punto di vista operativo, la gestione dell’accesso sicuro ai servizi impatta su due fasi specifiche del processo di pubblicazione di un servizio:
1. Descrizione del servizio. In fase di compilazione del descrittore il Service Provider assegna all’attributo «Livello di accesso» il valore «Community» o «Restricted». Nel Service Portfolio ogni entry è corredata dal descrittore, all’interno del quale è possibile prendere visione dell’attributo «Livello di accesso» specificato da parte del provider.
2. Richiesta di utilizzo dei servizi. Quando un soggetto richiede di poter utilizzare un servizio per realizzare una applicazione, l’Ecosistema invia al Service Provider una notifica di richiesta di utilizzo. Si possono verificare 2 casi:
o se il livello di accesso è «Community» E015 – Digital Ecosystem considera da subito la richiesta come accettata (l’Ecosistema tiene traccia della relazione di utilizzo instaurata); il Service Provider - oltre a prender visione del soggetto e dell’applicazione utilizzatrice del servizi esposto - abilita il meccanismo di accesso al servizio per la specifica applicazione richiedente, secondo le tempistiche e gli impegni che saranno indicati dal TMB;
o se il livello è «Restricted», il Service Provider notifica all’Ecosistema l’accettazione o meno della richiesta e l’Ecosistema la propaga al soggetto richiedente; il Service Provider si impegna ad evadere le richieste di utilizzo dei propri servizi entro 10 giorni lavorativi dalla data di richiesta; in caso di accettazione, l’Ecosistema tiene traccia della relazione di utilizzo instaurata e il Service Provider abilita il meccanismo di accesso al servizio per la specifica applicazione richiedente, entro 10 giorni lavorativi dalla data di richiesta
In entrambi i casi, il Service Provider dovrà procedere alle attività tecniche di configurazione necessarie per consentire a run-time l’accesso al servizio a tutti i soggetti autorizzati.
Le linee guida tecnologiche per la gestione del meccanismo di attestazione da parte dei Service Provider sono illustrati in dettaglio nel paragrafo 3.2.3.
Il paragrafo 3.2.4 riporta gli standard tecnologici selezionati e le relative linee guida per la gestione degli aspetti di sicurezza legati all’erogazione dei servizi.
3.2.3 Linee guida tecnologiche per la gestione dell’accesso “restricted” ai servizi (meccanismo di attestazione)
Il meccanismo di attestazione si basa sull’utilizzo di certificati X.509 (http://www.itu.int/rec/T-REC-X.509/en), resi disponibili attraverso i registri ufficiali dell’Ecosistema.
Sono riportati nel seguito i passi che il Service Provider deve eseguire al fine di adottare tale meccanismo.
Fase di descrizione e pubblicazione del servizio:
o Il Service Provider crea una coppia di chiavi: una privata e una pubblica inserita in un certificato X.509, ottenendola da una authority esterna o auto generandola.
16 di 45
Il Service Provider referenzia la chiave pubblica (certificato X.509) nel descrittore del proprio servizio (attributo “Certificato X.509”).
o Il Service Provider configura il proprio application server su cui viene eseguito il servizio (ed eventualmente – se necessario – i propri apparati di rete) per l’utilizzo della chiave privata inserendola nel relativo keystore in modo da realizzare un endpoint HTTPS sul quale ricevere le richieste di utilizzo; lo stesso endpoint deve essere configurato per richiedere al client di presentare il proprio certificato.
Fase di gestione delle richieste di utilizzo:
o Una volta ricevuta tramite l’Ecosistema, e approvata, nel caso di servizio «RESTRICTED», una richiesta di utilizzo da parte di un soggetto fruitore, il Service Provider recupera il certificato dell’applicazione. Tale certificato è inviato al Service Provider da parte dell’Ecosistema contestualmente alla richiesta di utilizzo del servizio.
o Il Service Provider inserisce il certificato del soggetto fruitore nel trust-store dell’application server su cui viene eseguito il servizio. La modalità con cui svolgere questa attività dipende dai componenti sistemistici specifici utilizzati dal singolo Service Provider. In generale comunque, dal momento che ad ogni applicazione è associata una certificate chain, si potrà alternativamente:
inserire nel trust-store il certificato foglia della certificate chain; oppure
inserire nel trust store il certificato CA della certificate chain, configurando i propri appliance con regole specifiche per abilitare soltanto lo specifico certificato foglia (ad esempio, effettuando un controllo sul campo CN del certificato foglia associato a tale CA).
Queste due alternative sono del tutto equivalenti dal punto di vista concettuale di gestione del meccanismo di attestazione; il Service Provider può decidere autonomamente quale perseguire in base alle specificità dei propri componenti hw per la gestione delle connessioni SSL.
Fase di erogazione del servizio a runtime
o Una volta ricevuta una richiesta applicativa da parte di una End User Application, l’application server del servizio verifica in automatico che il certificato presentato sia tra quelli presenti nel proprio trust-store / sia firmato da parte di una delle CA presenti nel proprio trust store.
o Se la verifica va a buon fine, l’application server instaura con il fruitore un canale di comunicazione sicuro (SSL/TLS con Client Authentication) e rende disponibile al livello applicativo il certificato del fruitore per consentire l’attuazione delle eventuali politiche di autorizzazione.
I certificati dei servizi, al fine di essere compatibili con E015 – Digital Ecosystem, devono possedere una struttura conforme ai requisiti che seguono:
Durata: >=2 anni.
Basic Constraint: End Entity (quindi non-CA).
Key Usage (critical): Digital Signature e Key Encipherment.
Enhanced Key Usage: Server Authentication, Client Authentication.
Signature Algorithm: almeno sha1RSA per massimizzare la compatibilità con il software esistente (in futuro si potrà passare a sha256RSA).
È consentito l’utilizzo di certificati multi-dominio nel caso si debba utilizzare un singolo certificato per domini/servizi diversi (che rimangono comunque univocamente identificati da certificato+domain name). Questi certificati, denominati certificati ‘SAN’ riportano nel campo Subject Alternative Names
17 di 45
l’elenco dei nomi di dominio per i quali il certificato deve essere considerato valido. Questo elenco viene definito al momento della creazione del certificato X509 indicando l’utilizzo dell’estensione ‘Subject Alternative Name’ e specificato come contenuto del campo Subject Alternative Name la lista di stringhe con l’elenco dei domini da considerare nel formato ‘DNS:<domainName1>, DNS:<domainName2>’ (per maggiori dettagli si veda http://tools.ietf.org/html/rfc2818).
Il Technical Management Board presiede i processi per la gestione del meccanismo di attestazione:
validando i certificati dei servizi all’atto della sottomissione del descrittore per approvazione;
monitorando periodicamente la validità dei certificati pubblicati nei registri dell’Ecosistema e notificando ai Service Provider la necessità di procedere al rinnovo in prossimità delle date di scadenza.
Si precisa che il ruolo di E015 – Digital Ecosystem nella gestione del meccanismo di attestazione non è quello di emettere dei certificati, bensì quello di gestire l’albo ufficiale dei certificati dei servizi. Ciascun soggetto è libero infatti di decidere se acquisire i certificati X.509 da una authority esterna oppure se auto generarli 2.
3.2.4 Linee guida tecnologiche per la gestione degli aspetti di sicurezza dei servizi
Gestire la sicurezza nelle interazioni applicative tra servizi ed applicazioni di E015 – Digital Ecosystem significa:
fornire ai service provider opportuni strumenti per garantire proprietà dell’interazione quali: integrità e confidenzialità dei dati, prova della fonte, non ripudio ecc.,
dare la possibilità ai Service Provider di specificare i requisiti di sicurezza per l’accesso ai servizi erogati nell’Ecosistema.
I principali aspetti da considerare sono:
gli strumenti per realizzare la sicurezza nelle interazioni applicative tra servizi;
gli strumenti per permettere ai service provider di specificare i requisiti di sicurezza dei propri servizi.
3.2.4.1 Sicurezza e servizi SOAP Per quanto riguarda la realizzazione di servizi sicuri, nel contesto dell’Ecosistema si fa riferimento in generale allo stack tecnologico dei Web Service e al WS-I Basic Security Profile 1.1.
2 In generale è auspicabile l’acquisizione dei certificati presso authority esterne; al fine di garantire l’inclusività di un ampio numero di soggetti, E015 – Digital Ecosystem consente comunque l’uso di certificati auto generati.
18 di 45
Figura 6 – Vista d’insieme sul WS-Stack e posizionamento delle tecnologie di sicurezza
In particolare, il WS-I Basic Security Profile 1.1 definito dalla OASIS WS-I Organization (http://www.oasis-ws-i.org/) indica le specifiche tecnologie da utilizzare con riferimento alle dimensioni di interoperabilità relative alla sicurezza e al trasporto in ambito Web Service SOAP.
Figura 7 – WS-I Basic Security Profile 1.1 e tecnologie considerate
19 di 45
Lo standard OASIS WS-Security: SOAP Message Security (http://docs.oasis-open.org/wss/v1.1/) definisce diverse estensioni al protocollo SOAP al fine di garantire la protezione end-to-end dei messaggi scambiati nelle interazioni tra Web Service SOAP. In particolare, i tre principali meccanismi forniti dallo standard sono:
la possibilità di veicolare token di sicurezza come parte di un messaggio SOAP,
la tutela dell’integrità del messaggio SOAP,
la tutela della confidenzialità del messaggio SOAP.
Alla base di WS-Security c’è il concetto di security token: costrutti che possono essere usati all’interno dei messaggi SOAP (in particolare nell’header) per rappresentare e veicolare informazioni (per esempio di identità, oppure relative ai meccanismi di processing da eseguire per validare i token stessi). Lo standard WS-Security permette di usare diversi tipi di token: binari, basati su XML (tra cui rientrano le asserzioni SAML), criptati e altri ancora. Per la protezione di integrità e confidenzialità, WS-Security utilizza standard come XML-Signature e XML-Encription, applicandoli a determinate parti del messaggio SOAP.
In aggiunta al WS-I Basic Security Profile 1.1, per permettere ai service provider di specificare i requisiti di sicurezza dei propri servizi si considerano i seguenti standard:
WS-Policy (http://www.w3.org/TR/ws-policy/) definisce un framework e un modello per rappresentare le policy di sicurezza di un servizio mediante descrizioni machine-readable: una policy può ad esempio descrivere i requisiti di sicurezza (autenticazione, autorizzazione ecc.) che il richiedente deve soddisfare per poter accedere a un servizio, oppure la messa in atto da parte del Service Provider di determinati meccanismi come il tracciamento dei messaggi applicativi. Per esempio, tramite una policy WS-Policy un Web Service può comunicare di essere in grado di accettare asserzioni SAML 2.0. WS-Policy non entra nel merito della rappresentazione delle caratteristiche di un servizio: a tal fine possono essere usate altre specifiche, per esempio WS-SecurityPolicy.
WS-SecurityPolicy (http://www.oasis-open.org/standards#ws-secpol) definisce le modalità di rappresentazione delle specifiche capacità o degli specifici requisiti di sicurezza di un servizio. Per esempio, grazie a WS-SecurityPolicy è possibile scrivere una policy assertion per richiedere la presenza di un determinato elemento nell’header del messaggio SOAP.
I requisiti di sicurezza di un servizio così descritti possono diventare parte integrante del descrittore del servizio.
3.2.4.2 Sicurezza e servizi REST Per i servizi REST in generale non esistono standard specifici per la gestione della sicurezza. Nell’ambito di E015 – Digital Ecosystem è raccomandato l’utilizzo delle strategie e meccanismi di sicurezza comunemente utilizzate per l’accesso a web application (sicurezza di canale con SSL/TLS ecc.). Si potrà valutare a tendere l’utilizzo aggiuntivo di token o protocolli ad hoc (per esempio SAML Token, OAuth ecc.).
20 di 45
3.3 Glossari dei servizi
3.3.1 Gli aspetti relativi ai glossari all’interno del descrittore del servizio
Si riportano nella tabella seguente i campi del descrittore del servizio che indirizzano direttamente gli aspetti legati all’interoperabilità dei servizi.
CAMPO DESCRIZIONE
Usi di glossari condivisi
Riferimento ad eventuali glossari condivisi dell’Ecosistema utilizzati da parte del servizio.
3.3.2 Linee Guida per la gestione dei glossari all’interno dell’Ecosistema
Un primo importante aspetto che indirizza la gestione dei Glossari all’interno dell’Ecosistema riguarda il modello dei dati di un servizio.
Il modello dei dati di un servizio o di una applicazione di E015 – Digital Ecosystem è un elemento fondamentale per l’interoperabilità.
Esso infatti identifica e descrive:
le entità e i concetti utilizzati nell’interazione con entità esterne per l’erogazione di funzionalità,
la rappresentazione di tali entità e concetti (per esempio le modalità di serializzazione in costrutti XML da utilizzare nei messaggi di richiesta e risposta).
Pertanto è opportuno che il modello dei dati dei servizi dell’Ecosistema sia adeguatamente documentato, formalizzato e strutturato:
la documentazione può consistere in una descrizione testuale (eventualmente guidata da un template comune);
la formalizzazione può consistere in una rappresentazione dei concetti mediante opportuni linguaggi di descrizione (diagrammi UML http://www.uml.org/ , E-R ecc.);
la strutturazione è la rappresentazione basata su una specifica tecnologia (per esempio un linguaggio di markup come XML) utilizzata dallo specifico servizio o applicazione.
Se adeguatamente descritti, formalizzati, strutturati e condivisi, i modelli dei dati abilitano il riuso nell’ambito di E015 – Digital Ecosystem; diversi servizi e applicazioni infatti spesso utilizzano nel proprio modello dei dati gli stessi concetti, dunque:
potrebbe essere già disponibile una rappresentazione degli stessi concetti,
rappresentazioni di nuovi concetti potrebbero essere condivise con altri provider dell’Ecosistema.
21 di 45
Concetto Descrizione
Persona …
Evento …
… …
DOCUMENTAZIONE
FORMALIZZAZIONE
Persona
+Nome+DataNascita
Evento
+Luogo+Data
partecipa a
formalizza
RAPPRESENTAZIONE
istanzia
XML Schema
JSON Schema
WS SOAP
WSDL• operation1• operation2
usa
REST Service
…
usa
Figura 8 – Modello dei dati: documentazione, formalizzazione, rappresentazione e utilizzo
L’approccio indicato per E015 – Digital Ecosystem propone e incentiva l’adozione di glossari condivisi per favorire l’interoperabilità e il riuso nella realizzazione dei servizi e delle applicazioni da parte dei soggetti aderenti all’ecosistema, difatti:
i glossari condivisi permettono sia di classificare i servizi che di adottare modelli dei dati comuni,
i glossari condivisi possono rappresentare un patrimonio informativo utilizzabile anche dopo la conclusione dell’evento Expo,
è di interesse il potenziale ruolo degli operatori di dominio e/o delle associazioni di categoria per la definizione e l’evoluzione dei glossari,
è importante promuovere l’inclusione nell’ecosistema di glossari e standard già esistenti in alcuni settori.
Condivisione e riuso di un modello dei dati possono avvenire a diversi “livelli” di specializzazione: i glossari infatti possono coprire concetti generali (tempo, geolocalizzazione ecc.), concetti legati all’evento Expo (“visitatore”, “espositore”, “punto di interesse” ecc.), concetti di specifici domini applicativi (turismo, trasporti, enogastronomia, alberghiero ecc.), concetti specifici di una singola applicazione o di un singolo servizio.
MODELLODATI
CONCETTI GENERALIEs. tempo, geolocalizzazione
CONCETTI LEGATI ALL’EVENTO EXPOEs. “visitatore”, “espositore”, “evento”
CONCETTI DI DOMINIOEs. “visita turistica”, “presidio eccellenze alimentari”
CONCETTI APP / SERVICE SPECIFICEs. …
GLOSSARICONDIVISI
Figura 9 – Possibili livelli di specializzazione di un glossario
22 di 45
Inoltre, i glossari condivisi possono essere più o meno formalizzati: da semplici tag, keyword o vocabolari si può arrivare a tassonomie complete o magari a una vera e propria formalizzazione in ontologie.
In fase di sottomissione di un nuovo servizio da pubblicare all’interno dell’Ecosistema il TMB verificherà l’eventuale presenza di glossari già disponibili e di potenziale interesse per il Service Provider, rispetto ai quali rendere coerente l’interfaccia ad il modello dei dati del servizio stesso.
23 di 45
3.4 Aspetti di monitoraggio dei servizi
3.4.1 Gli aspetti relativi al monitoraggio all’interno del descrittore del servizio
Si riportano nella tabella seguente i campi del descrittore del servizio che indirizzano direttamente gli aspetti legati all’interoperabilità dei servizi.
CAMPO DESCRIZIONE
Endpoint di monitoraggio
Endpoint per il controllo di disponibilità del servizio.
Invocazioni di test per monitoraggio
Formulazione delle invocazioni di test da utilizzare per la verifica di disponibilità del servizio e per la verifica della correttezza delle risposte ottenute.
Frequenza di monitoraggio
Indicazione da parte del Service Provider di una frequenza di monitoraggio compatibile col tipo di servizio erogato per quello specifico dominio.
Messaggi di indisponibilità
Opzionale:
indicazione dei messaggi da mostrare all’utente in caso di indisponibilità, con eventuale fornitura di semilavorati (es: immagini di supporto).
Test suite Opzionale: link alla test suite fornita dal Service Provider all’atto della richiesta di pubblicazione.
Endpoint ambiente di test
Opzionale:
link alla versione di test del servizio.
3.4.2 L’approccio dell’Ecosistema per il monitoraggio dei servizi
In generale è di interesse per l’Ecosistema poter verificare su base continuativa se i servizi sono attivi e come/quanto questi vengono usati da parte delle applicazioni.
Per questo motivo, l’Ecosistema prevede dei meccanismi di base per il monitoraggio continuativo dei servizi pubblicati; in particolare, già a partire dalla versione 1 verrà effettuato un controllo di disponibilità dei servizi.
Al fine di consentire a E015 – Digital Ecosystem di poter effettuare tale controllo, il Service Provider è tenuto a specificare all’interno del descrittore di servizio un endpoint di monitoraggio e ad esprimere una frequenza di monitoraggio compatibile con il tipo di servizio erogato.
Inoltre il Service Provider deve fornire all’interno del descrittore anche delle invocazioni “campione” di test (request e response), le quali saranno utilizzate dall’Ecosistema per la verifica di disponibilità del servizio e per la verifica della correttezza delle risposte ottenute.
L’Ecosistema utilizza l’endpoint di monitoraggio specificato nel descrittore per controllare periodicamente l’effettiva disponibilità del servizio (attraverso un semplice meccanismo di “ping”) e per effettuare delle invocazioni di test sulla base delle invocazioni “campione” specificate dal Service provider all’interno del descrittore.
Il Service Provider può inoltre opzionalmente indicare all’interno del descrittore altri attributi di interesse per la gestione degli aspetti legati al monitoraggio:
“Messaggi di indisponibilità”: tale attributo indica quali messaggi di indisponibilità il Service Provider raccomanda di mostrare da parte delle applicazioni in caso di irraggiungibilità del proprio servizio (es: visualizzazione di un messaggio di cortesia /
24 di 45
visualizzazione di specifiche immagini messe a disposizione da parte del Service Provider stesso).
“Test suite”: contestualmente alla pubblicazione del servizio il Service Provider può fornire una test suite per consentire di effettuare in modo automatico alcuni controlli sul servizio. Il TMB potrà utilizzare tale test suite periodicamente / “on demand” per verificare il corretto funzionamento del servizio.
“Endpoint ambiente di test”: per mezzo di tale attributo il Service Provider specifica, se disponibile, l’endpoint della versione di test del proprio servizio, messo a disposizione degli End User Application Provider per le attività di sviluppo della propria applicazione.
Da un punto di vista operativo, la gestione degli aspetti di monitoraggio dei servizi erogati impatta su due fasi specifiche del processo di pubblicazione e di erogazione del servizio:
1. Descrizione del servizio. In fase di compilazione del descrittore del servizio il Service Provider compila gli attributi: “Endpoint di monitoraggio”, “Invocazioni di test per monitoraggio” e “Frequenza di monitoraggio” (utilizzati dall’Ecosistema per effettuare il controllo di disponibilità e di correttezza delle risposte dei servizi), “Messaggi di indisponibilità” (opzionale), “Test suite” (opzionale) e “Endpoint ambiente di test” (opzionale).
2. Erogazione del servizio. A run-time E015 – Digital Ecosystem effettua periodicamente il controllo di disponibilità dei servizi e verifica la correttezza delle risposte ricevute in seguito alle invocazioni campione specificate nel descrittore. Il monitoraggio è effettuato “ai morsetti esterni” del servizio, poiché indica il livello di disponibilità con cui è percepito il servizio dall’Ecosistema.
Il TMB utilizza i dati di monitoraggio per comprendere il livello di qualità del servizio erogato (in termini di disponibilità), restituire tale informazione al Service Provider nonché diffondere l’andamento del monitoraggio alle applicazioni che utilizzano il servizio esposto.
25 di 45
3.5 Aspetti correlati all’erogazione dei servizi
3.5.1 Gli aspetti relativi all’erogazione all’interno del descrittore del servizio
Si riportano nella tabella seguente i campi del descrittore del servizio che indirizzano direttamente gli aspetti legati all’erogazione dei servizi.
CAMPO DESCRIZIONE
Impegni / capacità di erogazione
Indicazione generale su base volontaria della capacità di erogazione del servizio che il Service Provider indica di poter sostenere nei confronti dell’Ecosistema (secondo una logica best effort).
Logiche di remunerazione
Indicazione della logica di remunerazione connessa all’erogazione del servizio.
I valori ammissibili per questo attributo del descrittore sono:
Free: per servizi che non prevedono alcuna forma di
tariffazione;
a pagamento: per servizi che prevedono il pagamento di
una tariffa legata all’utilizzo
Modelli di tariffazione supportati (attributo specifico da compilare per i soli servizi “a pagamento”)
Indicazione dei modelli supportati per la tariffazione di servizi a pagamento.
Tipologia di QoS supportate (attributo specifico da compilare per i soli servizi “a pagamento”)
Indicazione delle tipologie di service level sulle quali il Service Provider si rende disponibile a stipulare accordi puntuali con specifici utilizzatori del servizio.
Dimensionamento dei flussi informativi
Informazioni circa le dimensioni dei flussi informativi in ingresso e in uscita dal servizio.
Vengono forniti nel seguito ulteriori dettagli in merito a tali attributi del descrittore del servizio
3.5.2 Impegni / capacità di erogazione
E015 – Digital Ecosystem prevede che normalmente i servizi siano erogati secondo una logica di tipo
Best effort; è interesse dei Service Provider erogare verso l’Ecosistema servizi di qualità al
fine di incentivare un ampio utilizzo degli stessi da parte delle applicazioni.
All’interno del descrittore il campo “Impegni / capacità di erogazione” offre al Service Provider la possibilità di comunicare all’Ecosistema, su base volontaria, le disponibilità e gli impegni di massima che esso si rende disponibile a sostenere per l’erogazione del proprio servizio; ad esempio, il Service Provider può dichiarare all’interno del descrittore – relativamente al campo “Impegni / capacità di erogazione” – il numero massimo di invocazioni giornaliere per Applicazione supportate dal proprio servizio. Tali informazioni rappresentano una utile indicazione verso il TMB per favorire l’ottimizzazione dell’utilizzo del servizio da parte delle applicazioni - sempre e comunque in una logica
26 di 45
complessiva di tipo best effort 3 - e per promuovere il miglioramento progressivo nel tempo della qualità delle funzionalità esposte.
3.5.3 Logiche di remunerazione
Ciascun soggetto dell’Ecosistema ha la possibilità di perseguire proprie logiche di remunerazione legate all’erogazione dei servizi. È pertanto possibile che i Service Provider decidano di erogare i propri servizi solo a soggetti con i quali è stato definito un accordo di tipo commerciale.
Al fine di dare evidenza di questa possibilità, i Service Provider devono specificare all’interno del descrittore se i propri servizi sono disponibili a pagamento (attributo “Logiche di remunerazione”). In questo modo, E015 – Digital Ecosystem facilita la stipulazione di accordi commerciali tra le diverse parti.
All’interno del descrittore, relativamente all’attributo “Logiche di remunerazione”, sarà possibile selezionare pertanto una delle seguenti opzioni:
1. Free. Non è prevista alcuna forma di tariffazione; il servizio è erogato gratuitamente ai
soggetti autorizzati ad accedervi.
2. A pagamento. L’accesso al servizio è soggetto a tariffazione.
Nel caso di servizi “a pagamento”, il Service Provider è tenuto a compilare anche i campi del descrittore “Modelli di tariffazione supportati” e “Tipologie di QoS supportate” al fine di indicare gli aspetti di interesse sulla base dei quali la tariffa di erogazione del servizio sarà concordata.
Si precisa che nel caso di servizi “a pagamento” la negoziazione della tariffa tra Service Provider e i soggetti utilizzatori avviene al di fuori dell’Ecosistema.
Qualora il Service Provider desiderasse esporre all’interno dell’Ecosistema due versioni del medesimo servizio, una “free” ed una “a pagamento” - per l’utilizzo della quale è necessario stipulare un accordo di tipo commerciale -, è necessario procedere alla pubblicazione di due servizi distinti, ciascuno dei quali corredato da un proprio descrittore specifico.
Modelli di tariffazione supportati (servizi “a pagamento”) Nel caso di servizi “a pagamento” il Service Provider deve specificare all’interno del descrittore, nel campo “Modelli di tariffazione supportati”, quali sono le modalità previste per il riconoscimento di un corrispettivo economico derivante dall’utilizzo del servizio da parte delle applicazioni.
Esempi di modelli di tariffazione che possono essere specificati all’interno di questo campo sono: pagamento una tantum, pagamento di un abbonamento, pagamento a consumo, pagamento in base alla QoS garantita, …
Tipologie di QoS supportate (servizi “a pagamento”) Nel caso di servizi “a pagamento” per i quali sia previsto un modello di tariffazione basato su garanzie di qualità (QoS), è necessario che il Service Provider compili il campo del descrittore “Tipologie di QoS supportate”.
All’interno di questo campo il Service Provider dichiara le tipologie di service level sulla base delle quali esso è disponibile a definire la tariffa di erogazione del servizio (stipulando in questo modo accordi di tipo commerciale). Esempi di possibili tipologie di service level sono: disponibilità del
3 Si precisa che le dichiarazioni riportate nel campo “Impegni / capacità di erogazione” hanno carattere puramente indicativo e non rappresentano un vincolo per il Service Provider
27 di 45
servizio, response time, volume di traffico per tipologia di transazioni campione, soglie di traffico, fasce orarie di erogazione, ...
3.5.4 Dimensionamento dei flussi informativi
Al fine di consentire ai soggetti utilizzatori di ottimizzare l’utilizzo dei servizi dell’Ecosistema, è data facoltà ai Service Provider di fornire nel campo “Dimensionamento dei flussi informativi” alcune indicazioni circa le dimensioni (ad esempio, in kb) dei flussi informativi in ingresso e in uscita dal servizio in corrispondenza di invocazioni campione rappresentative di un normale utilizzo.
28 di 45
3.6 Aspetti legati all’azienda erogatrice dei servizi
3.6.1 Gli aspetti relativi all’azienda all’interno del descrittore del servizio
Si riportano nella tabella seguente i campi del descrittore del servizio che indirizzano direttamente gli aspetti legati all’azienda erogatrice dei servizi.
CAMPO DESCRIZIONE
Anagrafica del servizio
Attributi di descrizione anagrafica del servizio:
Nome del servizio: nome univoco del servizio all’interno dell’Ecosistema.
Descrizione del servizio: descrizione sintetica in testo libero del servizio, la quale fornisce una presentazione funzionale del servizio.
Versione del descrittore: indicazione della versione del descrittore. Tag per classificazione del servizio: insieme di parole chiave che
consentono di classificare il servizio. Eventuali ulteriori vincoli specifici: eventuali ulteriori vincoli che è
necessario conoscere / rispettare per utilizzare il servizio.
Referente del servizio
Informazioni del referente unico del servizio lato service provider (nome, cognome, e-mail, telefono).
Riferimento al Service Provider
Nome dell’azienda che eroga il servizio.
3.6.2 Linee Guida per la gestione degli aspetti relativi all’azienda
Il descrittore del servizio rappresenta uno strumento fondamentale non solo per documentare gli aspetti di tipo tecnologico legati all’erogazione di un servizio, ma anche per indirizzare tematiche di tipo organizzativo e di relazione tra il Service Provider e l’Ecosistema.
Per questo motivo, all’interno del descrittore devono essere indicati:
i principali attributi di tipo anagrafico del servizio (nome servizio, descrizione, nome service provider, versione, tag per classificazione, …), importanti al fine di consentire una comprensione generale del servizio anche da parte di interlocutori non tecnici;
tali attributi hanno una valenza importante anche a scopo di comunicazione (alcuni attributi di anagrafica del servizio saranno infatti resi visibili pubblicamente sui registri di E015 – Digital Ecosystem anche da parte di soggetti non aderenti all’iniziativa);
in particolare, la descrizione del servizio fornita all’interno del descrittore deve consentire di comprendere al meglio le caratteristiche funzionali del servizio ed il valore potenziale per i soggetti che ne intendono fare uso;
i riferimenti (nome, cognome, e-mail, numero di telefono) del referente del servizio nei confronti dell’Ecosistema. Tale referente deve avere compreso a pieno le logiche di E015 – Digital Ecosystem e deve essere il punto di contatto per il TMB qualora vi fosse la necessità di indirizzare alcune tematiche di interesse legate all’erogazione del servizio. Le informazioni relative al referente del servizio non saranno rese visibili agli End User Application Provider, ma sono da intendersi ad uso esclusivo del TMB.
29 di 45
3.6.3 Linee Guida per la pubblicazione sul proprio sito web istituzionale delle informazioni sui servizi di E015 – Digital Ecosystem
Una volta pubblicato un servizio all’interno dell’Ecosistema, il Service Provider deve prevedere sul proprio sito web istituzionale una sezione dedicata alla descrizione dell’iniziativa di partecipazione all’Ecosistema e alla descrizione dei servizi pubblicati con un link che rimanda al sito web dell’Ecosistema, per il dettaglio delle informazioni dei Servizi pubblicati.
La presenza o meno di tali informazioni all’interno del sito web istituzionale del Service Provider sarà oggetto di verifica da parte del TMB e rappresenterà un aspetto di interesse ai fini dell’accettazione o meno della richiesta di pubblicazione di un nuovo servizio.
Ulteriori indicazioni operative per la realizzazione di questa sezione web sono disponibili all’interno dell’Allegato 2.
30 di 45
3.7 Ciclo di vita dei servizi (“lifecycle”)
3.7.1 Gli aspetti relativi al lifecycle all’interno del descrittore del servizio
Si riportano nella tabella seguente i campi del descrittore del servizio che indirizzano direttamente gli aspetti legati al ciclo di vita dei servizi.
CAMPO DESCRIZIONE
Tempo di vita del servizio
Intervallo temporale per il quale l’erogatore del servizio si impegna a mantenere il servizio disponibile.
Tempo di dismissione del
servizio Durata del periodo transitorio antecedente alla dismissione del servizio.
Versione del servizio
Identificativo della versione del servizio all’interno dell’Ecosistema.
Riferimento ad altre versioni del
servizio
Riferimento ad eventuali altre versioni del servizio pubblicate all’interno dell’Ecosistema. Per ogni riferimento viene fornito un changelog delle diverse versioni.
3.7.2 Il ciclo di vita dei servizi di E015 – Digital Ecosystem
I servizi di E015 – Digital Ecosystem rappresentano dei “building-block” riusabili messi a disposizione degli End User Application provider per le realizzazione delle applicazioni.
Al fine di consentire l’erogazione di applicazioni di qualità è importante che:
il Service Provider si impegni verso l’Ecosistema a mantenere attivi i propri servizi per il periodo temporale dichiarato all’atto della pubblicazione del servizio. In questo modo, chi realizza le applicazioni ha la garanzia del periodo temporale nel corso del quale i servizi utilizzati saranno effettivamente erogati con continuità.
i servizi pubblicati nell’Ecosistema siano il più possibile stabili, non solo da un punto di vista tecnico, ma anche e soprattutto da un punto di vista della continuità del “business”; un servizio nato per esigenze temporanee e che molto probabilmente verrà dismesso nel giro di qualche mese può provocare un significativo impatto sulle applicazioni che ne fanno uso; per questo motivo non potrà essere pubblicato all’interno di E015 – Digital Ecosystem, non essendo considerato “stabile”, ovvero non potendo garantire un significativo orizzonte temporale di erogazione;
Al fine di soddisfare questi importanti requisiti è necessario che tutti i servizi dell’Ecosistema siano erogati in accordo al “lifecycle” riportato in Figura 10 e descritto nel seguito:
Figura 10 – Lifecycle dei servizi di E015 – Digital Ecosystem
31 di 45
1. una volta valutata positivamente l’opportunità di pubblicare un servizio all’interno dell’Ecosistema, il Service Provider compila il descrittore del servizio; all’interno del descrittore il Service Provider specifica due attributi relativi al ciclo di vita del servizio:
a. tempo di vita: periodo nel quale il Service Provider si impegna verso E015 – Digital Ecosystem a mantenere attivo il servizio a beneficio delle applicazioni utilizzatrici 4;
b. tempo di dismissione: lasso temporale successivo al tempo di vita e durante il quale il servizio viene transitoriamente mantenuto attivo in attesa di essere dismesso 5;
2. successivamente alla pubblicazione e all’approvazione del descrittore da parte del TMB, il servizio entra nella fase di “erogazione”, la cui durata temporale è pari a quanto specificato nel campo “tempo di vita” del descrittore. Durante questa fase il Service Provider si impegna a mantenere attivo il proprio servizio con continuità, in modo da consentirne un utilizzo prolungato nel tempo da parte delle applicazioni;
3. una volta esaurito il periodo associato al tempo di vita, il servizio entra nella fase di “dismissione”, la cui durata temporale è pari a quanto dichiarato nel campo “tempo di dismissione” del descrittore. Il tempo di dismissione rappresenta la fase finale del ciclo di vita del servizio, durante la quale il servizio viene mantenuto attivo da parte del Service Provider per poi essere dismesso in forma definitiva. Questa fase consente agli End User Application Provider di poter intervenire sulla proprie applicazioni in modo da far fronte alla ormai prossima indisponibilità del servizio.
Nel momento in cui un servizio entra nella fase di dismissione, l’Ecosistema invia una notifica alle applicazioni utilizzatrici.
Durante questa fase del ciclo di vita E015 – Digital Ecosystem non accetta nuove richieste di utilizzo del servizio da parte degli End User Application Provider;
4. una volta effettivamente esaurito il periodo di dismissione può verificarsi una delle seguenti situazioni:
a. il servizio viene definitivamente dismesso e le applicazioni non ne possono più fare uso;
b. è stata nel frattempo pubblicata una nuova versione del servizio e l’Ecosistema invia alle applicazioni utilizzatrici una notifica nella quale promuove la migrazione verso la nuova versione;
c. il tempo di vita del servizio viene prolungato; l’Ecosistema invia alle applicazioni utilizzatrici una notifica nella quale comunica che il servizio sarà ancora disponibile.
Generalmente non è possibile dismettere un servizio anticipatamente rispetto a quanto dichiarato nel descrittore, ad eccezione dei seguenti casi:
1. il servizio non risulta più in utilizzo da parte di alcuna applicazione (ad esempio, perché tutte le applicazioni utilizzatrici hanno effettuato una migrazione ad una successiva versione);
2. eventuali cause di forza maggiore.
4 Il tempo di vita dovrà avere una durata tale da consentire l’erogazione di applicazioni in grado almeno di traguardare l’evento Expo 2015. 5 Il tempo di dismissione dovrà avere una durata tale da consentire agli End User Application Provider di porre in essere nuove strategie di evoluzione delle applicazioni in funzione della possibile non disponibilità futura del servizio.
32 di 45
Dal momento che i servizi di E015 – Digital Ecosystem possono essere soggetti ad evoluzioni, è necessario prevedere la possibilità da parte del Service Provider di pubblicare molteplici versioni di uno stesso servizio.
Le linee guida per la pubblicazione di una nuova versione del servizio sono le seguenti:
1. le evoluzioni del servizio che comportano modifiche all’interfaccia (signature e/o modello dei dati) determinano la pubblicazione di nuove versioni tra loro indipendenti.
In questo caso:
le nuove versioni di un servizio devono essere erogate tramite un endpoint dedicato e il loro processo di pubblicazione segue il normale iter previsto per la pubblicazione di un nuovo servizio (in particolare, il campo “Riferimento ad altre versioni del servizio” referenzierà le versioni precedenti); tali nuove versioni saranno caratterizzate da un loro specifico “tempo di vita” e “tempo di dismissione”;
le versioni precedenti del servizio continuano ad essere attive e restano a disposizione delle applicazioni secondo gli impegni assunti nel descrittore in fase di pubblicazione del servizio stesso (“tempo di vita” e “tempo di dismissione”), come indicato in Figura 11. È possibile pertanto che più versioni dello stesso servizio, le quali differiscono tra loro a livello di interfaccia e/o modello dei dati, siano attive contemporaneamente;
l’Ecosistema notifica alle applicazioni utilizzatrici la disponibilità di una nuova versione del servizio, promuovendo la migrazione alla versione più recente.
2. Le evoluzioni del servizio che NON comportano modifiche all’interfaccia (ad esempio, che determinano un incremento della qualità dei dati erogati) non necessitano della pubblicazione di una nuova versione indipendente.
In questo caso le modifiche al servizio – previa approvazione da parte del TMB – vengono eseguite direttamente sulla stessa istanza del servizio già pubblicata all’interno dell’Ecosistema (trattandosi infatti di modifiche che lasciano inalterata l’interfaccia e il modello dei dati del servizio, non si prevede alcun impatto sulle applicazioni utilizzatrici).
L’Ecosistema provvede ad inviare delle notifiche ai soggetti utilizzatori, specificando le caratteristiche del servizio oggetto di evoluzione.
Figura 11 – Gestione delle versioni dei servizi all’interno di E015 – Digital Ecosystem
33 di 45
3.8 Policies dei servizi
3.8.1 Gli aspetti relativi alle policies all’interno del descrittore del servizio
Con riferimento al documento dell’Allegato 1 si riportano nella tabella seguente i campi del descrittore del servizio che indirizzano direttamente gli aspetti legati all’interoperabilità dei servizi.
CAMPO DESCRIZIONE
Policy generali di utilizzo
Riferimento al documento contenente le condizioni di utilizzo del servizio valide per tutti i soggetti utilizzatori.
3.8.2 Approccio dell’Ecosistema per la gestione delle policy dei servizi
E015 – Digital Ecosystem prevede che ogni Service Provider stabilisca quali condizioni di utilizzo dei servizi i soggetti debbano impegnarsi a rispettare.
In particolare, è necessario che per ciascuno dei propri servizi pubblicati il Service Provider specifichi
all’interno del descrittore le relative Policy generali di utilizzo.
Tali policy indicano le condizioni di utilizzo del servizio comuni per tutti gli End User Application Provider e devono essere accettate da parte di ogni soggetto utilizzatore che intende utilizzare lo specifico servizio.
Se non rispettate, possono comportare l’inibizione da parte del Service provider dell’accesso al proprio servizio.
In generale i soggetti aderenti godono della massima autonomia nella definizione di dettaglio di queste policy; il TMB fornisce un supporto indicando eventualmente possibili modelli di riferimento o segnalando eventuali situazioni che comportano un potenziale ridotto utilizzo dei servizi esposti.
Esempi di possibili elementi contenuti all’interno delle policy generali / specifiche di utilizzo sono:
Proprietà dei dati erogati dai servizi.
Possibilità di manipolare e/o modificare i dati erogati dai servizi.
Clausole per l’utilizzo e la visualizzazione parziale dei dati erogati dal servizio.
Clausole relative all’aggiornamento delle informazioni (Es: obbligo di mostrare agli utenti l’ora di aggiornamento).
Eventuale riferimento a framework di licensing già esistenti. Ad esempio:
o Creative Commons.
o Italian Open Data License.
o …
Clausole di esonero di responsabilità.
Clausole in merito alla storicizzazione delle informazioni erogate dai servizi.
Eventuale riferimento al codice etico del Service Provider.
Clausole relative alla privacy e alla eventuale gestione di dati sensibili.
Possibilità di visualizzare messaggi di tipo pubblicitario contestualmente alle informazioni erogate dai servizi.
Obbligo di citare il soggetto erogatore delle informazioni:
o semplice citazione testuale;
34 di 45
o utilizzo di un logo.
Clausole relative ad eventuali sospensioni dell’erogazione del servizio.
Altro
In Figura 12 è riportata una schematizzazione esemplificativa relativa a possibili framework di licensing già disponibili che i Service provider potrebbero decidere di referenziare e adottare all’interno delle proprie policy.
Ad esempio:
1. per quanto concerne i contenuti erogati dai servizi (file audio, immagini, video) è possibile utilizzare le licenze Creative Commons; nel caso in cui si volesse adottare un modello di licensing chiuso, i Service Provider possono decidere di proteggere i propri contenuti con diritti di copyright;
2. per quanto concerne i dati messi a disposizione (ad esempio, file corrispondenti a intere banche dati) è possibile utilizzare le licenze Open Data Commons; nel caso in cui si volesse adottare un modello di licensing chiuso, i Service Provider possono decidere di proteggere i propri dati con diritti di copyright;
3. per quanto concerne i servizi, è necessario definire all’interno delle Policy generali e all’interno delle Policy specifiche quali siano i Termini di Servizio previsti.
Figura 12 – Ipotesi di modelli di licensing adottabili all’interno di E015 – Digital Ecosystem
35 di 45
4 Verifiche del Technical Management Board per la pubblicazione dei servizi
Il processo di pubblicazione di un servizio all’interno di E015 – Digital Ecosystem prevede che il Technical Management Board (fino ad ora TMB) effettui le verifiche necessarie a garantire che i servizi pubblicati posseggano tutte le caratteristiche richieste per poter essere validi per l’Ecosistema.
4.1 Elementi di verifica da parte del Technical Management Board
Una volta ricevuta da parte del Service Provider la richiesta di pubblicazione di un servizio, corredata dal descrittore del servizio compilato in ogni sua parte, il Technical Management Board procede ad eseguire le seguenti verifiche:
1. Verifica di completezza del descrittore: tutti gli attributi obbligatori devono essere valorizzati ed adeguatamente documentati.
2. Verifica della correttezza e della coerenza del descrittore: tutti gli attributi devono essere compilati coerentemente con le Linee Guida del presente documento.
3. Verifica di coerenza del servizio con le Linee Guida tecnologiche di E015 – Digital Ecosystem: il servizio deve rispettare tutte le indicazioni tecnologiche fornite in questo documento.
4. Test di invocazione del servizio: il TMB, attraverso opportuni strumenti, effettua delle invocazioni di test, verificando così il funzionamento del servizio e la rispondenza del comportamento effettivo con quanto documentato all’interno del descrittore e della documentazione tecnica ad esso allegata.
NOTA: al fine di consentire al TMB di poter effettuare queste verifiche è necessario che il Service Provider configuri il meccanismo di restrizione dell’accesso al servizio (meccanismo di attestazione) al fine di garantire l’accesso programmatico da parte del TMB. In particolare, il Service Provider dovrà includere all’interno del trust store associato al proprio servizio il certificato client del TMB reso disponibile dall’Ecosistema.
5. Verifica di disponibilità del servizio: il TMB “aggancia” il servizio al componente core di verifica di disponibilità al fine di verificare gli aspetti specifici relativi al monitoraggio.
Sulla base dell’esito di tali verifiche il TMB comunicherà al Service Provider l’accettazione della richiesta di pubblicazione del servizio; in caso di non accettazione della richiesta, il TMB fornirà al Service Provider le indicazioni di “non conformità” al fine di consentire di indirizzare le problematiche riscontrate, rimuovere gli ostacoli riscontrati e favorire in questo modo la successiva pubblicazione del servizio.
4.2 Esito del processo di verifica
Come descritto nel paragrafo precedente, il processo di verifica dei servizi può concludersi positivamente o meno a seconda delle non conformità rilevate dal Technical Management Board in fase di verifica del servizio.
In caso di esito positivo del processo di verifica il Technical Management Board dell’Ecosistema rilascia al Service Provider un resoconto con il dettaglio delle verifiche svolte contenente una attestazione di conformità del Servizio alle Linee Guida per la pubblicazione dei servizi definite nell’Ecosistema e descritte nelle sezioni precedenti. Questa attestazione di conformità formalizza l’accettazione da parte dell’Ecosistema della richiesta di pubblicazione del servizio precedentemente
36 di 45
inviata dal Service Provider e riconosce al soggetto aderente il ruolo di Service Provider dell’Ecosistema.
In caso di esito positivo del processo di pubblicazione, il Technical Management Board include il servizio all’interno del registro ufficiale dei servizi dell’Ecosistema e procede ad integrarlo all’interno dell’ambiente di “preview” del servizio (tale ambiente di “preview” costituisce una particolare sezione del registro dei servizi all’interno della quale viene data una dimostrazione reale - attraverso una interfaccia grafica interattiva – delle funzionalità erogate dal servizio).
Qualora durante la sessione di verifica del servizio fossero rilevate dal Technical Management Board delle non conformità (lievi e comunque non bloccanti) rispetto alle linee guida descritte nei paragrafi precedenti, il report finale riporterà anche una serie di raccomandazioni per le quali il Technical Management Board richiede la definizione di un piano di interventi da parte del Service Provider per superare le non conformità rilevate 6.
In caso di esito negativo del processo di verifica il Technical Management Board fornisce al Service Provider un resoconto con il dettaglio delle verifiche svolte, l’indicazione delle non conformità (bloccanti) che sono state rilevate e, quando possibile, anche raccomandazioni e suggerimenti per indirizzare correttamente le problematiche specifiche riscontrate e facilitare in questo modo il processo di pubblicazione del servizio da parte del Service Provider.
6 La mancata definizione del piano di interventi per le singole raccomandazioni segnalate oppure il mancato rispetto dei tempi indicati nel piano di interventi definito dal Service Provider può costituire motivo di revoca della pubblicazione del servizio all’interno dell’Ecosistema.
37 di 45
ALLEGATO 1. DESCRITTORE DEL SERVIZIO
Si riporta nel seguito la versione integrale del descrittore del servizio.
CAMPO DESCRIZIONE ESEMPIO CARDINALITÀ
Tecnologia Tecnologia di riferimento con la quale il servizio è stato implementato.
“REST”, “WEB SERVICE SOAP”
1
Interfaccia del servizio
Riferimento a uno o più file allegati al descrittore che documentano l'interfaccia del servizio in modo completo per un utilizzatore.
Riferimenti a file esterni. Es. per servizi SOAP: WSDL + documento accompagnatorio. Es. per servizi REST: struttura URL + documento accompagnatorio
1…N
Modello dei dati
Riferimento a uno o più file allegati al descrittore che documentano la struttura delle richieste e delle risposte in modo completo per un utilizzatore.
Riferimenti a file esterni. Es. per servizi SOAP: XML schema utilizzati nei WSDL + documento descrittivo dei tipi semplici e complessi. Es. per servizi REST: riferimenti agli XML schema utilizzati nei tracciati di risposta + documento descrittivo associato
1…N
Pattern di interazione
Paradigma di interazione con il servizio.
I valori ammissibili per questo attributo del descrittore sono:
request-response;
publish &
subscribe.
“REQUEST-RESPONSE”, “PUBLISH & SUBSCRIBE”
1
Livello di accesso
Indicazione del livello di accesso previsto per il servizio.
I valori ammissibili per questo attributo del descrittore sono:
community (per
servizi accessibili da parte di qualsiasi
“COMMUNITY”, “RESTRICTED”
1
38 di 45
applicazione dell’Ecosistema);
restricted (per
servizi con accesso limitato alle sole applicazioni dell’Ecosistema esplicitamente autorizzate).
Certificato X.509
Riferimento al certificato X.509 associato al servizio, necessario per abilitare il meccanismo di attestazione dell’appartenenza all’Ecosistema
Riferimento a file esterno
1
Aspetti di sicurezza specifici
Riferimento a uno o più file allegati al descrittore che documentano eventuali aspetti di sicurezza specifici che è necessario conoscere per utilizzare correttamente il servizio.
Riferimento a file esterni
0…N
Usi di glossari condivisi
Riferimento ad eventuali glossari condivisi dell’Ecosistema utilizzati da parte del servizio.
Riferimento a risorse esterne
0…N
Endpoint di monitoraggio
Endpoint per il controllo di disponibilità del servizio.
URL dell’endpoint 1
Invocazioni di test per monitoraggio
Formulazione delle invocazioni di test da utilizzare per la verifica di disponibilità del servizio e per la verifica della correttezza delle risposte ottenute.
Riferimento a file esterno
1
Frequenza di monitoraggio
Indicazione da parte del Service Provider di una frequenza di monitoraggio compatibile col tipo di servizio erogato per quello specifico dominio.
Es: una invocazione ogni minuto
1
Messaggi di indisponibilità
OPZIONALE:
indicazione dei messaggi da mostrare all’utente in caso di indisponibilità, con eventuale fornitura di semilavorati (es: immagini di supporto).
Riferimento a file esterno
0…1
Test suite OPZIONALE: Riferimento a file 0…1
39 di 45
link alla test suite fornita dal Service Provider all’atto della richiesta di pubblicazione.
esterno
Endpoint ambiente di test
OPZIONALE:
link alla versione di test del servizio.
URL all’endpoint di test del servizio
0…1
Impegni / capacità di erogazione
Indicazione generale su base volontaria della capacità di erogazione del servizio che il Service Provider indica di poter sostenere (secondo una logica best effort).
Es: 20 invocazioni al secondo da parte di ciascuna applicazione dell’Ecosistema
0…1
Dimensionamento dei flussi
informativi
Informazioni circa le dimensioni dei flussi informativi in ingresso e in uscita dal servizio.
Es: 400kb in media per ciascuna response
1
Logiche di remunerazione
Indicazione della logica di remunerazione connessa all’erogazione del servizio.
I valori ammissibili per questo attributo del descrittore sono:
free (per servizi
che non prevedono alcuna forma di tariffazione);
a pagamento
(per servizi che prevedono il pagamento di una tariffa legata all’utilizzo).
“FREE”, “A PAGAMENTO”
1
Modelli di tariffazione supportati
SOLO PER SERVIZI “A PAGAMENTO”: Indicazione dei modelli supportati per la tariffazione di servizi a pagamento.
Es: pagamento una tantum; pagamento di un abbonamento; pagamento a consumo; …
0…1
Tipologia di QoS supportate
SOLO PER SERVIZI “A PAGAMENTO”:
Indicazione delle tipologie di service level sulle quali il Service Provider si rende disponibile a stipulare accordi al di fuori dell’Ecosistema.
Es: response time, volume di traffico per tipologia di transazioni campione, soglie di traffico, …
0…1
Nome del servizio Nome univoco del servizio all’interno dell’Ecosistema.
Es: tempi di attesa mezzi di superficie
1
40 di 45
Descrizione sintetica del
servizio
Descrizione sintetica in testo libero del servizio, la quale fornisce una overview funzionale del servizio (per motivi di comunicazione).
Descrizione in testo libero
1
Versione del descrittore
Indicazione della versione del descrittore.
“PROPOSED”, “FINAL” 1
Tag per classificazione
Insieme di parole chiave che consentono di classificare il servizio.
Es: “orari”, “aeroporti”, …
0…N
Eventuali ulteriori vincoli
specifici
Eventuali ulteriori vincoli che è necessario conoscere / rispettare per utilizzare il servizio.
Riferimento a file esterno / descrizione in testo libero.
0…1
Referente del servizio
Informazioni del referente unico del servizio lato service provider (nome, cognome, e-mail, telefono).
Compilazione in testo libero.
1
Riferimento al Service Provider
Nome dell’azienda che eroga il servizio.
Compilazione in testo libero.
1
Tempo di vita del servizio
Intervallo temporale per il quale l’erogatore del servizio si impegna a mantenere il servizio disponibile.
Es: “servizio disponibile fino al 30/9/2015”
1
Tempo di dismissione del
servizio
Durata del periodo transitorio antecedente alla dismissione del servizio.
Es: “dal 30/9/2015 al 31/3/2016”
1
Versione del servizio
Identificativo della versione del servizio all’interno dell’Ecosistema.
Es: “v1.0” 1
Riferimento ad altre versioni del
servizio
Riferimento ad eventuali altre versioni del servizio pubblicate all’interno dell’Ecosistema. Per ogni riferimento viene fornito un changelog delle diverse versioni.
Riferimento a risorse esterne
0…N
Policy generali di utilizzo
Riferimento al documento contenente le condizioni di utilizzo del servizio valide per tutti i soggetti utilizzatori.
Riferimento a file esterno
1
41 di 45
ALLEGATO 2. TEMPLATE E LINEE GUIDA PER SEZIONE “E015 – DIGITAL
ECOSYSTEM” SU PROPRIO SITO WEB ISTITUZIONALE
Ciascun soggetto aderente a “E015 – Digital Ecosystem” deve prevedere sul proprio sito web istituzionale un’apposita sezione pubblicamente accessibile nella quale comunicare la partecipazione all’iniziativa. Tale sezione dovrà essere denominata “<nome_azienda> e E015 – Digital Ecosystem” (ad esempio: “Mario Rossi SpA e E015 – Digital Ecosystem”) e dovrà contenere il seguente testo 7 : <nome_azienda> partecipa attivamente a “E015 – Digital Ecosystem”.
“E015 – Digital Ecosystem” è un ambiente digitale di cooperazione aperto,
competitivo, non discriminatorio e concorrenziale per lo sviluppo di servizi
integrati offerti ai cittadini tramite la rete internet e rappresenta una
importante opportunità per lo sviluppo del territorio.
L’iniziativa nasce da una collaborazione tra la società Expo 2015 SpA e
Confindustria, CCIAA di Milano, Confcommercio, Assolombarda e Unione del
Commercio con l’obiettivo di favorire l’incontro tra domanda e offerta di beni e
servizi da parte del sistema delle imprese a favore dei cittadini, non solo nel
quadriennio di preparazione e di svolgimento dell’esposizione universale, ma
anche per gli anni successivi.
“E015 – Digital Ecosystem” mette a disposizione di tutti gli operatori economici
che intendono partecipare all’iniziativa gli standard tecnologici, le Linee
Guida, i processi, le regole e gli elementi infrastrutturali abilitanti per
favorire l’interoperabilità dei servizi ICT e la realizzazione di applicazioni
informatiche (multicanale / multidispositivo e/o siti web) che offrono
funzionalità integrate agli utenti finali.
Maggiori dettagli possono essere reperiti all’indirizzo …
[Inserire il link alla Home Page dell’Ecosistema]
Qualora l’azienda contribuisse all’Ecosistema in qualità di End User Application Provider, si richiede di predisporre una breve descrizione in stile “comunicazione web” delle proprie applicazioni realizzate all’interno dell’Ecosistema, introdotta dal seguente testo: <nome_azienda> contribuisce a “E015 – Digital Ecosystem” in qualità di End User
Application Provider avendo realizzato le seguenti applicazioni per l’utente
finale:
[Bla bla bla …]
[…]
Per ogni applicazione si richiede una descrizione generale di alto livello (di poche righe) che comunichi il valore dell’applicazione stessa; la descrizione fornita non deve essere di tipo tecnico, ma di stampo divulgativo e commerciale (il nome attribuito all’applicazione deve essere lo stesso utilizzato nella Scheda Applicazione sottoposta al TMB per la validazione). Le informazioni tecniche di dettaglio relative all’applicazione saranno comunque quelle riportate nella sezione “registro” del portale dell’Ecosistema, da linkare a partire da questa pagina.
7 Qualora, ad esempio per vincoli di spazio, non fosse possibile riportare integralmente il testo proposto, è concesso pubblicarne una sintesi (purché elaborata a partire dal testo originale)
42 di 45
Dopo la descrizione delle applicazioni si raccomanda di inserire il seguente testo:
Le applicazioni sviluppate da <nome_azienda> utilizzano servizi esposti da altri
partecipanti [indicare eventualmente l’elenco dei servizi utilizzati]
all’interno di “E015 – Digital Ecosystem” secondo le policies specifiche fornite
da ogni soggetto.
Tali policies sono riportate nella specifica sezione del Portale
dell’Ecosistema. [Inserire il link al registro dei servizi dell’Ecosistema]
Si richiede di indicare esplicitamente il link al registro dei servizi di “E015 – Digital Ecosystem”, all’interno del quale l’utente del sito web potrà reperire le policies dei servizi.
OPZIONALE NOTA: è facoltà di ciascuna azienda riportare per ogni applicazione eventuali altre informazioni di proprio interesse (ad esempio, Terms&Conditions specifiche di utilizzo legate alla propria applicazione), oppure fornire una descrizione di alto livello dei propri servizi pubblicati all’interno dell’Ecosistema.
ULTERIORI REQUISITI e LINEE GUIDA La sezione del proprio sito web dedicata all’iniziativa deve mostrare il logo ufficiale di
E015 – Digital Ecosystem, in accordo al regolamento d’uso dello stesso.
L’azienda si impegna a mantenere costantemente aggiornate le informazioni
pubblicate sul proprio sito web, ad esempio in caso di realizzazione di una nuova
applicazione.
o Si ricorda che in fase di pubblicazione di una nuova applicazione il Technical
Management Board provvederà anche a verificare il rispetto delle Linee Guida
relative alla pubblicazione delle informazioni sul proprio sito web istituzionale.
ELENCO DEI COLLEGAMENTI ESTERNI CHE DEVONO ESSERE PUBBLICATI SUL PROPRIO SITO WEB Si riporta nel seguito un quadro riassuntivo di tutti i link esterni che devono essere riportati nella sezione del proprio sito web descritta nel presente documento:
COLLEGAMENTO COLLOCAZIONE
Link alla Home Page di “E015 – Digital Ecosystem”
Sezione generale di descrizione della partecipazione all’Ecosistema
Link al registro dei servizi di “E015 – Digital Ecosystem”
Sezione di descrizione delle applicazioni realizzate (relativamente alle policies dei servizi usati dalle applicazioni)
43 di 45
ALLEGATO 3. PRINCIPALI TRAIETTORIE DI EVOLUZIONE DELLE
TECNOLOGIE DELL’ECOSISTEMA
Si riportano nel seguito le principali traiettorie di evoluzione tecnologica identificate per E015 – Digital Ecosystem.
Figura 13 – Roadmap di adozione delle tecnologie di interoperabilità
End User Feedback per End User Application
Feedback per End User Application e Servizi
V1.0 V1.xVersioni
architetturadi riferimento
V2.x…
V3.x
Service/App Portfolio Analysis
Acquisizione statistiche di utilizzo per Servizi
Service/App Portfolio Analysis
Monitoraggio advanced per mezzo di Test suite
Acquisizione statistiche di utilizzo per End User Application
e Servizi
Monitoraggio base End User Application e Servizi (controllo di
disponibilità)
Figura 14 – Roadmap di adozione delle tecnologie a supporto del monitoraggio
44 di 45
Profilo utente “esteso” Certificatori di attributo
federati
V1.0 V1.xVersioni
architetturadi riferimento
V2.x…
V3.x
SP e IdP SAML 2.0
Figura 15 – Roadmap di adozione delle tecnologie a supporto della gestione dell’identità digitale
WS-I Basic Security Profile 1.1 …
V1.0Versioni
architetturadi riferimento
V2.x…
V3.x
Requisiti di sicurezza
descritti nella documentazione
WS-I Basic Security Profile …
V1.x
Requisiti di sicurezza
descritti con WS-Policy
WS Trust, WS Federation
Servizi REST
HTTPS
…
Figura 16 – Roadmap di adozione delle tecnologie a supporto della sicurezza applicativa
CLASSIFICAZIONE:
tassonomie / ontologie
(es. RDF, OWL)
V1.0 V1.xVersioni
architetturadi riferimento
V2.x…
V3.x
CLASSIFICAZIONE:
tag / keyword / vocabolari + descrizioni
MODELLO DATI:
es. XML + XML Schema
+ descrizioni
MODELLO DATI:
es. XML + XML Schema
+ annotazioni sem.
Figura 17 – Roadmap di adozione delle tecnologie a supporto dei glossari
45 di 45
ALLEGATO 4. ASPETTI DI INTEROPERABILITÀ: IL CASO PARTICOLARE
DELLA COOPERAZIONE APPLICATIVA
La Cooperazione Applicativa riguarda esclusivamente le interazioni tra Pubbliche Amministrazioni (PA) su rete SPC, secondo quanto previsto dal Sistema Pubblico di Cooperazione definito da DigitPA (http://www.digitpa.gov.it/).
Per dare la possibilità di pubblicare in E015 – Digital Ecosystem i servizi erogati dalle PA in cooperazione applicativa occorre rendere disponibili come Web Service su Internet i servizi già esposti in SPCoop (Figura 18). Per esempio, dagli Accordi di Servizio si possono estrapolare le descrizioni delle interfacce dei servizi (i WSDL dei soggetti erogatore e fruitore), i relativi modelli dei dati (definiti in opportuni schemi XML) e altra documentazione utile a descrivere il funzionamento del servizio e le modalità di accesso. Ulteriori informazioni eventualmente presenti negli Accordi di Servizio (per esempio i profili di collaborazione) possono diventare parte della descrizione accessoria del nuovo Web Service.
istanza del servizioesposto in Expo come WS
su Internet
INTERNET
istanza del serviziosu rete SPC
RETE SPC Servizio
PdD
Figura 18 – Approccio all’esposizione di servizi SPCoop nell’Ecosistema
Il porting da rete SPC a E015 – Digital Ecosystem su rete Internet dei servizi già erogati in cooperazione applicativa è facilitato dal fatto che le specifiche SPCoop emesse da CNIPA/DigitPA indicano già di aderire alle raccomandazioni WS-I (cfr. “Linee guida all’uso della busta e-Gov” v1.1, 2008), in particolare per quanto riguarda i seguenti profili:
WS-I Basic Profile 1.1;
WS-I Basic Security Profile 1.0;
WS-I Simple SOAP Binding Profile 1.0;
WS-I Attachment Profile 1.0.
Per maggiori informazioni su SPCoop si rimanda alle specifiche e ai documenti tecnico-operativi disponibili sul sito CNIPA/DigitPA (http://archivio.cnipa.gov.it/site/it-IT/Attivit%C3%A0_-_Archivio_storico/Sistema_Pubblico_di_Connettivit%C3%A0_%28SPC%29/Servizi_infrastrutturali_di_interoperabilit%C3%A0,_cooperazione_ed_accesso_%28SICA%29/Documenti_tecnico-operativi/).
