Port domeniu

Portul de domeniu are scopul de a se asigura că schimbul electronic de informații între administrațiile publice are aceleași caracteristici ca și cel tradițional (hârtie, semnătură, protocol, fax ...). În acest fel, administrația care trimite informațiile electronic către altul va avea garanția că destinatarul (și nu alții) le-a primit, precum și destinatarul va putea trata informațiile electronice primite cu o demnitate egală cu cea pe care o primește astăzi. cu metode tradiționale, considerate până în prezent singurul probator în sensul procedurii administrative. Acest lucru trebuie să fie posibil indiferent de modul în care este realizat portul domeniului (furnizor, limbi, tehnologie ...), deoarece interfața sa a fost definită.

Anexa 2 (Rețeaua națională: caracteristici și principii de cooperare în aplicații) emisă de Departamentul pentru inovație și tehnologii definește principalele orientări pentru administrațiile care doresc să creeze servicii online prin interacțiunea cu sistemele de informații ale altor administrații. În aceste indicații, poarta domeniului constituie elementul tehnologic care realizează cooperarea. Fiecare port de domeniu conceptual acționează ca un proxy pentru accesarea resurselor aplicației situate în același domeniu.

Conceptul de Dominion

Domeniul este definit ca setul de resurse - inclusiv proceduri, date și servicii - și politici ale unei organizații date. Domeniul este, de asemenea, granița responsabilității unei organizații, în special în ceea ce privește politicile legate de sistemul său de informații.

Scopul arhitecturii cooperatiste este de a permite integrarea obiectelor informaționale (proceduri și date) și a politicilor din diferite domenii, favorizând comunicarea între entități omogene, garantând autonomia administrațiilor individuale și lăsând nemodificate activele lor informaționale.

Poarta Dominionului

Interoperabilitatea între administrații trebuie să se dezvolte prin porturi de domeniu, pe baza standardelor definite la nivel național în așa fel încât:

sunt identificate serviciile și datele pe care fiecare administrație decide să le pună la dispoziție în rețea;
politicile de securitate, acces și control al calității și corectitudinea serviciilor furnizate, stabilite de administrația furnizorului, sunt respectate pentru fiecare serviciu afișat.

Portul de domeniu face parte din modelul organizațional al sistemului de conectivitate publică și cooperare (SPC) și, ca atare, își găsește în mod natural locul în proiectarea conceptuală, mai degrabă decât în cel logic sau fizic. În special, la nivel conceptual există un singur port pentru fiecare domeniu, care reprezintă suma tuturor aparatelor însărcinate cu accesarea resurselor domeniului.

Sistemele informatice care, prin ușa domeniului, trec cu vederea SPC pot aparține diferitelor categorii:

un sistem monolitic sau, în orice caz, care funcționează pe un singur nod într-o administrație mică;
un sistem distribuit pe mai multe noduri conectate la o rețea locală într-o administrație mai mare;
o rețea de zonă (de exemplu, agregarea municipalităților, comunităților montane, rețelei provinciale sau regionale), la care sunt conectate sistemele informatice ale diferitelor administrații.

Cooperarea pentru aplicații

Portul de domeniu permite fiecărui PA care își expune serviciile altor PA-uri să comunice cu ușurință cu aceștia prin partajarea și adoptarea acelorași protocoale (unde „protocoalele” sunt utilizate în sens larg). Fiecare entitate poate acționa atât ca furnizor , cât și ca consumator al unui serviciu dat. Prin urmare, este ușor de înțeles că PDD este o componentă pe două fețe: cea externă trebuie să adere la un set de standarde pentru a permite interoperabilitatea cu PDD-urile altor PA, în timp ce cea internă este dependentă de resursele interne ale instituției. „Cooperarea aplicațiilor” (logica care permite interacțiunii diferitelor aplicații și infrastructuri) prevede că fiecare port de domeniu este împărțit logic într-o componentă de cooperare și integrare : primul, orientat spre exteriorul PDD, este responsabil de comunicațiile dintre domeniu Porturi, în timp ce al doilea interacționează cu logica și arhitectura infrastructurii pe care trebuie să o servească. În funcție de faptul dacă un anumit PDD joacă rolul de furnizor sau consumator, acesta se numește, respectiv, Port de aplicație sau Port delegat . Comunicațiile au loc întotdeauna între porturile delegate și porturile de aplicații.

Paradigmele comunicării

Paradigmele cooperării cu aplicațiile care trebuie să fie acceptate de porturile de domeniu pot fi urmărite în două tipuri principale: cererea de serviciu și comunicarea evenimentului.

Solicitarea de serviciu constă în solicitarea unui domeniu pentru un serviciu furnizat de un domeniu de servire și este la rândul său împărțită în „Interogare” (dacă solicitarea nu implică modificări ale vreunui obiect al domeniului de servire) și „Tranzacție”, în cazul în care cererea produce o variație permanentă a unui obiect al aplicației domeniului de servire.

Un eveniment , pe de altă parte, este schimbarea valorii unui obiect aplicație într-un domeniu sursă, care are, de asemenea, semnificație pentru alte domenii numite destinatari. Notificarea evenimentului nu necesită un răspuns de la destinatari.

Pe baza tipului de cerere, apar următoarele două scenarii de cooperare:

Cooperare pentru solicitare de servicii

Solicitarea de serviciu constă într-un mesaj produs de o aplicație a unui domeniu client și direcționat către o aplicație a unui domeniu de servire. Mesajul declanșează executarea unei aplicații de domeniu de servire care, pe baza informațiilor conținute în mesaj, execută o procedură și trimite un răspuns destinat aplicației client. Răspunsul este o indicație sigură că aplicația de difuzare a implementat cererea și că aceasta a avut succes / nereușită. Din punctul de vedere al interacțiunii administrative, cererea de serviciu este întotdeauna sincronă. Cererea de service poate fi de două tipuri:

interogare: cerere de serviciu care vizează obținerea de informații din domeniul de servire, dar care nu modifică niciun obiect al aplicației din același domeniu de servire;
tranzacție: cerere de serviciu destinată să producă o modificare permanentă a unei aplicații obiect a domeniului de servire.

Fiecare entitate poate acționa atât ca „furnizor”, cât și ca „consumator” al unui serviciu dat. Portul de domeniu care invocă cererea de serviciu trebuie să contacteze mai întâi catalogul de servicii pentru a obține detaliile tehnice și interfețele necesare comunicării. Deci, să vedem o schemă a succesiunii schimburilor din punctul de vedere al unei administrații care dorește să utilizeze un anumit serviciu de informații expus de un alt organism:

Administrația A are nevoie de un serviciu din partea administrației B și caută în Catalogul de servicii dacă B este capabil să îl furnizeze;
Catalogul de servicii oferă un link care conține descrierea administrației B și adresa de internet (o adresă URL) la care pot fi trimise cereri de utilizare a serviciului căutat. Administrația B a publicat, de fapt, specificațiile pentru utilizarea serviciului său în Catalogul de servicii.
Portul de domeniu al lui A examinează formatul cerut de B pentru a formula cererea de serviciu. Din informațiile introduse în structura de descriere a serviciului, A este capabil să compună o cerere de serviciu și să descifreze în mod adecvat răspunsul oferit de B.

Cooperare pentru evenimente

Comunicarea unui eveniment constă în trimiterea unui mesaj de către o aplicație pentru a informa alte aplicații ale unuia sau mai multor domenii destinatar despre schimbarea informațiilor referitoare la un obiect aplicație sau despre crearea unui nou obiect aplicație. Mesajul trimis conține și informații, noi sau modificate, care descriu evenimentul în sine. Interacțiunea dintre interlocutori are loc indirect, mediată de o infrastructură de servicii (numită Publish and Subscribe) care oferă servicii pentru publicarea unui eveniment și abonarea la evenimentele în sine. În acest scenariu, de exemplu, o municipalitate, ca răspuns la o cerere de schimbare a reședinței de către un cetățean, publică evenimentul Schimbare de reședință, împreună cu toate datele referitoare la acesta, pe sistemul Publicare și Abonare. Acesta din urmă are grijă să îl notifice apoi, într-un mod adecvat, tuturor administrațiilor care au semnat anterior acel eveniment specific.

Profiluri de colaborare

În termeni generali, se presupune că fiecare colaborare a aplicației implică schimbul unei perechi de mesaje: o cerere trimisă de la un port de domeniu urmată de un răspuns de la un alt port de domeniu. Colaborările sunt avute în vedere prin schimbul de mesaje în mod sincron și asincron. Prin convenție, sincronismul este văzut din punctul de vedere al ușii la care începe fiecare episod de colaborare:

într-un schimb sincron, portul domeniului client trimite cererea sa de aplicație și așteaptă răspunsul portului domeniului de servire;
într-un schimb asincron, răspunsul portului domeniului de servire poate fi trimis mai târziu și, prin urmare, portul domeniului client nu așteaptă.

Alegerea modului sincron sau asincron poate depinde de aspecte legate de latența procedurilor administrative (de exemplu, necesitatea intervenției umane pentru a aplica semnătura digitală a unui funcționar public). Cu toate acestea, în principiu, această alegere poate depinde și de alegeri exclusiv tehnologice.

Pachetul de guvernare electronică

Pentru a schimba mesajele aplicației între porturile de domeniu, se folosește plicul e- Guvernare (e-Gov), care este definiția formatului de codificare și a conținutului mesajelor SOAP, utilizate pentru a implementa, sub formă de servicii Web, serviciile expuse de către Porturi de aplicații ale administrațiilor. Formatul pachetului de guvernare electronică a fost definit de Centrul tehnic al rețelei unitare a AP (în prezent DigitPA) în documentele orientative pentru a sprijini implementarea proiectelor de guvernare electronică. Fiecare mesaj schimbat între porturile de domeniu este format din două părți principale:

o parte din plic, care conține informațiile referitoare la expeditor, destinatar (destinat ca porturi de domeniu), serviciul solicitat și profilul de colaborare utilizat; acest plic este în general gestionat de componentele de colaborare ale porturilor domeniului și, prin urmare, trebuie să fie cât mai general posibil;
o parte din conținutul aplicației, reprezentată de informațiile reale furnizate pentru acel tip de serviciu și schimb (de exemplu, datele de identificare personală ale unei cereri de informații personale).

Instrumentul utilizat pentru a defini un format de date partajat de toate administrațiile, indiferent de sistemele și bazele de date „moștenite”, este XML . SOAP, pe de altă parte, este utilizat ca standard pentru transmiterea informațiilor codificate cu XML pe internet, utilizând protocolul HTTP . În general, tipul de structură care trebuie utilizat pentru plic și conținut depinde de tipul mesajului și de nevoile de reglementare. În acest sens, conform legislației actuale, pot fi definite trei tipuri de mesaje:

mesaje care nu necesită utilizarea unei semnături digitale;
mesaje care necesită utilizarea unei semnături digitale ca singură garanție a originii informațiilor (în conformitate cu Decretul prezidențial 445/2000);
mesaje care necesită semnătura digitală a unui oficial public.

Trebuie remarcat faptul că mesajele de tip 1) și 2) se pretează procesării complet automatizate, în timp ce mesajele de tip 3 necesită de obicei intervenția manuală a semnăturii de către un oficial public. Documentele legale pot fi semnate digital ca atașamente binare PKCS # 7 (pe baza circularei AIPA CR / 24); alt conținut XML poate fi semnat digital pentru a oferi dovada provenienței sale. O semnătură opțională poate fi inclusă în antet utilizând standardele XML SOAP Security și XML Signature și ar putea fi, de exemplu, utilizată pentru a garanta sursa de origine a informațiilor (articolul 43 din Decretul prezidențial 445/2000). Alegerea structurilor specifice pentru pachetul de e-guvernare care urmează să fie utilizate la schimbul de mesaje constituie o parte integrantă a definiției preliminare a serviciilor și nu poate constitui o variantă care trebuie negociată pentru fiecare schimb. Din punct de vedere administrativ, structura XML SOAP încorporează, de asemenea, rolul semnăturii IT în format XML al mesajului, deoarece raportează datele minime ale înregistrării protocolului. Structura XML SOAP poate fi, de asemenea, inclusă într-o structură MIME pentru a atașa unul sau mai multe documente de aplicație la mesaj, conform standardului SOAP XML cu atașamente.

Legislație de referință

Mai jos este o listă de documente de referință legate de componenta portului de domeniu:

Liniile directoare pentru rețeaua națională (18 ianuarie 2001);
Anexa tehnică a rețelei naționale (18 ianuarie 2001);
Decretul prezidențial din 28 decembrie 2000 nr. 445: Text consolidat al dispozițiilor legislative și de reglementare privind documentația administrativă; ridică implicit necesitatea unei interacțiuni IT puternice între AP pentru a îndeplini cerințele legale;
DPCM 31/10/2000 și circulara AIPA CR / 28 din 7/5/2001 reglementează metodele de interconectare între diferite sisteme de protocol IT și integrarea acestora cu e-mail și semnătură digitală. În special, legislația prevede posibilitatea prelucrării automate a informațiilor schimbate între diferite sisteme de protocol;
DPCM 8/2/1999: „Reguli tehnice pentru formarea, transmiterea, conservarea, duplicarea, reproducerea și validarea, chiar temporală, a documentelor electronice”; reglementează, printre altele, procedurile tehnice pentru aplicarea și verificarea semnăturii digitale;
Circulara AIPA CR / 24 din 19 iunie 2000: stabilește orientările fundamentale pentru interoperabilitatea sistemelor bazate pe semnătura digitală. Printre altele, această circulară stabilește formatul de referință pentru certificatele X.509, care raportează cheile publice de abonament și informațiile importante despre abonat și formatul documentelor digitale semnate, cu referire la specificația publică PKCS # 7.

Principalele site-uri de referință

Ministrul inovației și tehnologiilor , pe innovation.gov.it .
DigitPA - Organismul Național pentru Digitalizarea Administrației Publice , pe digitpa.gov.it .
OpenSource Domain Port Development , pe openspcoop.org .

Elemente conexe

E-guvernare