Source: https://forum.italia.it/t/lg-interoperabilita-2-1-introduzione-alle-interfacce-di-servizio/3235
Timestamp: 2018-08-20 05:07:29+00:00
Document Index: 126001966

Matched Legal Cases: ['art.10', 'art.1', 'art.64', 'art.64', 'art.12', 'art.7']

[LG-Interoperabilità] 2.1. Introduzione alle interfacce di servizio - Linee Guida Modello di Interoperabilità - .it Forum
[LG-Interoperabilità] 2.1. Introduzione alle interfacce di servizio
docs-italia (Docs Italia) 2018-05-07 15:52:57 UTC #1
ggentili (Giovanni Gentili) 2018-05-14 08:24:48 UTC #2
al par.2.1.1 viene proposta una importante classificazione basata sul consumatore (consumer).
il testo del Batini 2015 rispetto a questa classificazione interno/esterno riporta anche una specifica che non è stata tradotta, ed invece sarebbe importante riportare per chiarezza:
the interest in eGov project regards above all external services, which are supplied to final users. However, since, as we will see, in the context of value aspects tied to production costs and service supply are relevant, it is interesting to conceive internal services that positively influence external service production.
il passo qui sopra chiarisce che sono rilevanti (e di interesse per i progetti) anche i servizi interni, sia che essi siano “autoprodotti” da una PA che fa da fornitore (provider) oppure che essi siano affidati da una PA ad un fornitore privato (che agisce sulla base di un contratto o in via sussidiaria).
i servizi interni sono infatti trascurati, mentre sono essenziali nell’ottica di creare veri ecosistemi di interoperabilità.
sarebbe anche importante citare il concetto di “servizio” del d.lgs. n.279/1997 art.10 comma 5…
…chiarendo che i “servizi esterni” corrispondono ai “servizi finali” del d.lgs. n.279/1997 e che i “servizi interni” corrispondono ai “servizi strumentali” del d.lgs. n.279/1997.
infine, andrebbe forse chiarito che un servizio interno può essere sia quello destinato ai dipendenti/operatori della stessa PA che lo eroga, sia quello a favore di dipendenti/operatori appartenenti ad altre PA (altri organismi pubblici).
ggentili (Giovanni Gentili) 2018-05-14 08:40:07 UTC #3
rispetto a questo passo del par.2.2.1…
…in Batini 2015 è riportato il termine “procedures defined by law” che tradurre con “procedimenti” è molto limitativo.
Sarebbe interessate riprendere/citare la definizione di servizio in CPSV-AP_IT (vedi servizi.gov.it) che è la seguente:
nonchè la definizione presente nella delibera n.88/2010 della CIVIT…
quindi per i servizi abilitanti invece di “procedimenti amministrativi definiti dalla legge” sarebbe meglio tradurre con un generico “obblighi derivanti dalle leggi” e per i servizi facilitanti invece di “un obbligo procedurale” sarebbe meglio tradurre con “una discrezionalità lasciata dalla legge”.
i servizi pubblici derivano sia dall’esercizio di un potere autoritativo (solitamente tramite un “procedimento”) oppure dall’erogazione di una prestazione (di varia natura, tangibile o intangibile).
inoltre dove si dice “che sono più spesso erogati da fornitori privati del mercato dei servizi” andrebbe chiarito che il fornitore (provider) può agire per conto della PA sulla base di un contratto/concessione o in via sussidiaria (per facilitare il servizio della PA, sia come intermediario con un ruolo formale previsto/accordato dalla PA che come facilitatore indipendente dalla PA utilizzando le API di un ecosistema).
ggentili (Giovanni Gentili) 2018-05-14 08:49:29 UTC #4
al par.2.1.2 viene riportata questa definizione di “servizio digitale”…
Un servizio digitale (talvolta anche indicato come electronic service o e-service) è un servizio che viene erogato via Internet o in una rete, la fornitura è essenzialmente automatizzata o comporta solo un intervento umano minimo, ed è impossibile da garantire in assenza di tecnologia informatica
…sarebbe importante chiarire che questa traduzione da Rowley 2006 è da considerarsi del tutto equivalente alla definizione riportata nel CAD, art.1 comma 1 lettera n-quater), ovvero la seguente:
altrimenti si può pensare che parliamo di concetti diversi generando ulteriore confusione rispetto ai concetti di servizio digitale/web/on line/in rete.
ggentili (Giovanni Gentili) 2018-05-14 08:59:12 UTC #5
al par.2.1.3. viene introdotta la distinzione tra “Interfacce semplici e complesse”.
poco sopra, al par.2.1.1., è stata introdotta la distinzione tra “servizio elementare” e “servizio composito” derivata dalla nomenclatura EIF.
forse sarebbe meglio uniformare le dizioni, parlando di “interfacce elementari” e “interfacce composite” (o almeno citarli come sinonimi).
tra l’altro il termine semplice è usato anche per distinguere interfacce “semplici e mission-critical” e usare due volte semplici induce confusione.
al par.2.1.4 si parla anche di “erogatori” del servizio. andrebbe chiarito se si tratta della stessa cose dei “fornitori” del servizio, ovvero sempre del concetto di “provider”. inoltre, quando si parla di “erogatori esterni” si intende un provider che agisce per nome e per conto di una PA? l’uso del termine esterno fa pensare ai “servizi esterni” che non è corretto in quanto un erogatore esterno potrebbe operare anche un servizio interno (per la stessa PA o altre PA)
ggentili (Giovanni Gentili) 2018-05-14 15:02:20 UTC #6
al par.2.1.2 sta scritto…
si utilizza il termine interfaccia di servizio per indicare l’esposizione delle funzionalità applicative che sono necessarie per realizzare un servizio digitale. (…) Un’interfaccia di servizio si compone in generale di varie operazioni, e può essere realizzata come un web service, un’API, una Web API, ecc (…)
…quando si parla di “interfacce di servizio” si intende lo stesso concetto che nel CAD è definito “interfacce applicative” ?
il CAD all’art.64-bis, comma 1-bis, riporta quanto segue:
altra domanda: queste linee guida in consultazione forniranno anche le indicazioni ex art.64-bis, comma 1-bis oppure solo quanto all’art.12 comma 2 del CAD e/o art.7 comma 1?
Roberto_Polli (Roberto Polli) 2018-05-18 12:48:12 UTC #7
e grazie per le tue considerazioni.
Ti chiedo un chiarimento su questo intanto - visto che il resto delle considerazioni sui riferimenti normativi merita un’analisi più attenta.
Le indicazioni delle LG sono utili anche alla progettazione di servizi interni;
Non volevamo limitare l’autonomia nella progettazione dei servizi interni; ad esempio usare un protocollo binario (non interoperabile) per replicare un database tra due datacenter della stessa PA;
Oltre la parte sugli schemi di dato - che vale sicuramente per ogni tipo di servizio - quale altre parti raccomanderesti?
ggentili (Giovanni Gentili) 2018-05-22 12:21:36 UTC #8
se per servizi interni consideriamo la definizione proposta nella bozza di LG…
servizi interni, quando il servizio è dedicato agli utenti interni all’organizzazione erogatrice, sia essa PA che erogatore di servizi privato
…la galassia dei servizi interni è molto ampia. per questo suggerivo di aggiungere alla LG una traduzione di un ulteriore passo presente nel Batini ovvero questo:
Andrebbe infatti chiarito che le LG si applicano (integralmente) anche ai servizi interni (tento una traduzione)…
quando il servizio interno ha valore rilevante in termini di costo di produzione e/o dei destinatari del servizio stesso, rimanendo nell’ottica di concepire servizi interni che influenzano positivamente la produzione dei servizi esterni
Un esempio di rilevanza dei destinatari di un servizio interno si ha quando il servizio ha un utente (umano o macchina) che è dentro una diversa articolazione della stessa PA (ad esempio due direzioni e/o dipartimenti di un ministero che dialogano tra loro via API nell’ambito delle loro competenze/procedimenti… magari sono pure due AOO diverse) oppure dentro una diversa PA (ad esempio il dipendente di un comune che accede al “Registro imprese” nazionale di Infocamere, quindi attori entrambi pubblici ma in organizzazioni diverse).
Seguendo questo principio, le LG non si applicheranno di solito ad una replica di database tra due datacenter… a meno che questo abbia un costo tale da essere considerato rilevante, e quindi da tracciare, oppure nel caso in cui i due datacenter siano di proprietà di PA diverse.
lugce (LUGCE) 2018-06-07 14:25:30 UTC #9
Sebbene alcuni prefissi adottati dal Sistema Internazionale siano applicati anche alla formazione di multipli del byte, non sembrerebbe incontrovertibilmente accertabile la presenza di tale unità tra quelle del SI propriamente detto.
Roberto_Polli (Roberto Polli) 2018-06-07 15:18:17 UTC #10
Nota teorica interessante!
Il Sistema Internazionale contiene un riferimento al Byte ed un rimando ad IEC 60027-2:2005.
Andremo sicuramente a raffinare questa parte: grazie mille!
dante_chiroli (Dante Chiroli) 2018-06-24 17:44:06 UTC #11
Un saluto a tutti e vi prego di voler considerare il presente contributo.
Ritengo che da un punto di vista architetturale la PDD (e non la busta eGov) abbia felicemente assolto negli anni al compito di centralizzare le interazioni A2A machine, assicurando le dovute misure di security, logging e audit.
Tale valenza architetturale dovrebbe essere mantenuta soprattutto in considerazione dell’auspicata maggiore ‘apertura’ sia semantica che sintattica.
Il modello punto-punto applicativo oltre a produrre la replicazione a carico di ciascun applicativo delle suddette funzioni, inibirebbe de-facto la possibilità di orchestrare servizi compositi.
Ritengo pertanto irrinunciabile mantenere la presenza di un middleware di razionalizzazione architetturale (ESB).
Il protocollo SOAP è ancora collocabile sul cosiddetto “plateau of enlightenment” soprattutto per la conseguita maturità e, anche se richiede un poco di lavoro in più per lo sviluppo, è ancora il protocollo più stabile negli scenari A2A machine.
Il protocollo REST, irrinunciabile per l’ambito mobile, forse non riguarda lo scenario A2A e A2B machine.
Potrebbe essere utile un richiamo allo European Interoperability Reference Architecture (EIRA) e alla Digital Service Infrastructure (DSI) con la chiara definizione dei Bulding Block fondanti.
Infine, per assicurare maggiore efficacia comunicativa, suggerirei di aggiungere un capitolo di sintesi sulle indicazioni operative, con riguardo ai diversi scenari in esame ed i relativi integration pattern (standard) a cui riferirsi. Sarebbe utile accennare ai tempi per la dismissione delle PDD.
Roberto_Polli (Roberto Polli) 2018-07-02 11:08:18 UTC #12
purtroppo la PDD non ha avuto i risultati sperati. I costi sostenuti ne hanno limitato l’adozione, ed ha complicato in diversi casi le interazioni tra le amministrazioni.
A livello architetturale, il nuovo modello lascia libertà di scelta sulle soluzioni middleware e suggerisce di usare dei proxy gateway per centralizzare la security, il logging e l’audit. Quando un middleware non ha tutte le informazioni per l’audit/log (eg. end-to-end encryption) va’ comunque valutata la necessità di un audit applicativo.
Nessuno vieta di usare SOAP, ma come altri paesi viene introdotto REST. Da questo ci aspettiamo un migliore service management, ed un maggiore riuso delle interfacce per a2a ed a2c.
Stanno emergendo specifiche per API, anche in ambito UE, eg:
Berlin Group per le API bancarie,
FHIR in ambito sanitario,
ed è fondamentale che l’Italia non resti indietro rispetto ai nuovi scenari che plasmeranno l’EIRA del futuro.
In questi giorni stiamo lavorando sulla parte tecnica: se hai dei contributi e/o best practices su REST/SOAP che vuoi condividere, scrivimi pure: roberto@teamdigitale.governo.it