Modello attività



Scaricare 1.14 Mb.
Pagina1/3
21.12.2017
Dimensione del file1.14 Mb.
  1   2   3





Descrizione Sistemi informativi regionali: Infrastruttura e servizi trasversali

ALLEGATO C09




Regione Basilicata

Ufficio S. I. R. S.

Descrizione Sistemi informativi regionali: Infrastruttura e servizi trasversali

CONTROLLO DEL DOCUMENTO


Approvazioni




Data

Autore




Redatto da:

27/03/2012

Dott. Maurizio Argoneto

Approvato da:




Dott. Nicola Petrizzi

Variazioni

Versione prec.

Data

Autore

Paragrafi modificati

1.1

16/05/2012

Dott. Maurizio Argoneto




Distribuzione




Copia n°

Destinatario

Locazione



















Dott. Nicola Petrizzi

Regione Basilicata

Indice

Introduzione 5

Servizi trasversali di sistema 7

Servizi trasversali a consumo 29

Ambienti Middleware 38

Ambienti DBMS e File System 41

Infrastrutture messe a disposizione dal Centro Tecnico Regionale 45

Best Practice 47



Introduzione


Il presente documento ha lo scopo di fornire una descrizione esaustiva e completa delle componenti che riguardano il software, le best practice e gli ambienti di erogazione utilizzati dai SISTEMI INFORMATIVI. Tali componenti sono trasversali ai SISTEMI INFORMATIVI e offrono una serie di funzionalità come “built-in” ai software applicativi. Di particolare interesse risultano essere tutte quelle componenti che riguardano l’ambiente di erogazione e che possono essere riassunte in tre macro categorie: ambiente middleware, strato di gestione della persistenza e strato di gestione dei file.

Di seguito riportiamo un’immagine esemplificativa del concetto di Infrastruttura e di servizi trasversali a disposizione dei SISTEMI INFORMATIVI.





1.2 Definizioni ed Acronimi


Lista e descrizione delle definizioni e degli acronimi.

Acronimo

Significato







AA

Attribute Authority

IMS

Identity Management System

ESB

Enterprise Service Bus

IBASHO

IMS della Regione Basilicata

BPS

Business Process Server

AA

Attribute Authority



Servizi trasversali di sistema


Nell’ambito dell’erogazione dei servizi informativi, molto importante è la dimensione attribuita ai sistemi che posseggono una dimensione trasversale, e che sono cioè di utilità a tutti i sistemi che necessitano di specifici servizi. È infatti molto importante definire gli aspetti che riguardano l’erogazione dei servizi “a disposizione” di tutti i Sistemi Informativi. Molti di questi servizi trasversali hanno una connotazione ed un’importanza strategica molto rilevante, pertanto si procederà ad un’esaustiva descrizione di tali componenti cercando di prospettarne anche le applicazioni e l’importanza strategica della loro adozione.

2.1 IMS Identity Management System: Ibasho


Il sistema di Single Sign On (SSO) permette all’utente di accedere a più applicazioni e risorse web attraverso un singolo punto di accesso, inserendo una sola volta le credenziali. Tale sistema è un servizio fondamentale nell’ente che ha fatto molti sforzi per consentire e sostenere la facilità di accesso e la semplificazione per l’utente finale ad accedere ai servizi web erogati e cogliere l’altro ambizioso obiettivo che è quello di elevarne il livello di sicurezza. I principali fattori che portano ad un livello di sicurezza elevato sono l’esistenza di un unico punto di accesso e la riduzione del numero di password che devono essere memorizzate dagli utenti.

Si parla di sistema basato su Single Sign On (SSO) quando le richieste di autenticazione non vengono gestite direttamente dalle singole applicazioni web ma vengono inoltrate ad un sistema di autenticazione che ha precedentemente certificato le credenziali dell’utente connesso. In questo modo l’utente ha la possibilità di muoversi tra le applicazioni web senza avere la necessità di reinserire nuovamente le credenziali per l’accesso ai diversi servizi offerti.

Il nodo cruciale del sistema in analisi è: “senza avere la necessità di reinserire nuovamente le credenziali all’utente”.

L’obiettivo principale del Single Sign On è proprio quello di rendere i processi relativi all’autenticazione trasparenti all’utente finale creando allo stesso tempo un sistema facilmente gestibile per gli amministratori. L’utente deve rendersi conto di lavorare in un sistema sicuro, ma non deve assolutamente vivere la sicurezza come un onere aggiuntivo.

Il Single Sign On (SSO) è quindi un sistema specializzato che permette ad un utente di autenticarsi una sola volta per poi accedere a tutte le risorse informatiche che sono abilitate attraverso questo sistema di autenticazione. SSO si pone diversi obiettivi il primo dei quali, più gradito agli utenti, è la semplificazione della gestione degli accessi ai vari servizi con l’effettiva digitazione di una sola password per accedere a tutti i servizi. Utilizzando politiche di sicurezza comuni per diversi servizi SSO si tenderà quindi a semplificare la gestione delle politiche di sicurezza con una definizione più chiara e meno rischi di falle nei sistemi.
Vantaggi dell’adozione del sistema di SSO all’interno dell’ente

L’utilizzo del sistema di Single Sign On offre i seguenti vantaggi:



  • Riduzione del tempo speso dagli utenti durante le diverse fasi di autenticazione dei vari servizi in quanto il processo automatizzato non interrompe il lavoro dell’utente con ulteriori richieste di username e password;

  • Maggiore sicurezza dovuta alla necessità di non memorizzare un insieme di password diverse e quindi con la probabilità che la password scelta sia più robusta.

  • Con la gestione comune dei dati di profilazione utente diventano più semplici e rapide le operazioni da parte degli amministratori del sistema (es. rimuovere/aggiungere utenti oppure abilitarli ai diversi servizi).

  • Maggiore sicurezza in quanto la gestione cooperativa degli utenti permette di avere una integrità della base dati utenti implicita, evitando quindi problemi di inconsistenza come potrebbero avvenire in più sistemi che replicano i dati degli utenti.

  • Semplificare l’accesso alle applicazioni;

  • Tutti gli applicativi condividono un unico punto di accesso dal quale mutuano le politiche di sicurezza e la regolamentazione delle strategie di accesso e di autorizzazione definite dall’ente;

  • Monitorare gli accessi ai servizi;



Ruoli e rilascio delle credenziali di accesso

Fondamentale per permettere l’accesso, ai servizi dispositivi da parte dei Cittadini, è la necessità di accertare l'identità di un utente. Si tratta di un problema solo in parte tecnologico che è invece legato fortemente ad un processo. La distribuzione delle smart-card CIE/CNS rappresenta una possibile soluzione al problema ma va comunque considerata anche un'alternativa, da usare per quegli utenti per cui non è prevista in tempi brevi l'assegnazione di una carta. L'uso di un PIN, per rafforzare ulteriormente l'autenticazione con login e password, può essere una soluzione. L'accesso ai servizi più delicati, in genere quelli dispositivi e/o che prevedono forme di pagamento, sarà possibile solo se l'utente possiede questo ruolo e se naturalmente il processo di autenticazione con login/password/PIN è andato a buon fine. Il processo di rilascio del PIN garantisce:



  • l'unicità del PIN per tutti i servizi che richiedono identità forte

  • la garanzia di identificare in modo certo l'utente a cui è stato rilasciato il PIN.

Il modo più sicuro per garantire l'identificazione è la distribuzione tramite pubblico ufficiale (es. tramite l'URP o l'Anagrafe del Comune di Residenza o tramite un ufficio Regionale) di un codice PIN alfanumerico di 8 caratteri.
Dettagli tecnici d’integrazione

In questa implementazione dell’ IMS si è scelto di abbracciare lo standard SAML 2.0 per la gestione del Web Single Sign-On (SSO). Tre sono i profili (per usare la terminologia SAML) che sono stati attualmente implementati i seguenti:



  • Web Browser SSO Profile;

  • Single Logout Profile;

  • Assertion Query/Request Profile: che permette di interrogare l'IdMS per ottenere informazioni (attributi) su un utente.

E due sono i profili di Binding:

  • Http Redirect Binding;

  • Http Post Binding.

N
el linguaggio SAML si identificano l'Identity Provider, che certifica l'identità di un utente, e i Service Providers, ovvero i siti web a cui un utente vuole accedere per ottenere un servizio. Gli scenari di accesso sono di due tipi: SP-initiated e IP-initiated. Il primo caso, il più frequente, si ha quando un utente accede direttamente al SP per richiedere un servizio. Nel secondo caso invece l'utente accede prima all'IP, si autentica, e da qui accede ad uno dei vari SP disponibili. Descriviamo nel dettaglio il primo caso.



  • Al passo 1 l'utente accede al SP. Il SP si accorge (secondo una sua logica personale, indipendente da SAML) che l'utente non si è autenticato.

  • (passo 2) Genera allora una ridirezione HTTP (HTTP Status 302 o 303) al servizio di login dell'IP secondo le specifiche SAML. In particolare sarà specificata la richiesta di autenticazione (AuthnRequest) e verrà indicata la URL di ritorno (attributo RelayState).

  • (passo 3) L'utente si autentica all'IP secondo varie logiche (ad esempio invio login/password su sessione HTTPS). L'IP, riconosciuto l'utente, produce (specifiche SAML) una pagina che contiene un form HTTP con associata un'azione POST verso il SP.

  • (passo 4) L'utente accede al SP, che verifica la Response SAML ricevuta via POST e fa accedere l'utente.



Autorizzazione ai servizi
XACML eXtensible Access Control Markup Language è un linguaggio di Policy, utilizzato per descrivere i requisiti generali del controllo degli accessi a risorse distribuite (xmlns:xacml=“urn:oasis:names:tc:xacml:2.0:policy:schema:os”). Un linguaggio per gestire gli accessi a risorse, che permette di sapere quando una data azione su di una risorsa può essere compiuta o meno e di interpretarne un eventuale risultato. Ecco un esempio di funzionamento del Policy Engine di Ibasho:





PEP

E’ quell’entità di sistema che effettua il controllo sugli accessi, facendo richieste di decisione e facendo rispettare le decisioni di autorizzazione. Livello logico che protegge la risorsa richiesta (posta su file system distribuito o web server che sia)



PIP

E’ l’entità di sistema che ha la funzione di archivio dei valori dei vari attributi di risorsa, azione o ambiente. Esso fornisce i valori degli attributi al context handler.



PDP

E’ l’entità di sistema che valuta le policy applicabili e produce la decisione di autorizzazione per l’esecuzione dell’azione sulla risorsa richiesta. Quando un utente cerca di accedere ad una risorsa, il PEP ne definisce gli attributi ed assegna al PDP il compito di decidere se autorizzare o meno la richiesta. La decisione è presa in base alla descrizione degli attributi dell’utente.



Context Handler

E’ l’entità di sistema che converte la richiesta dal suo formato nativo al formato canonico XACML e viceversa e che permette la comunicazione tra tutte le altre componenti del sistema.


Integrazione dei sistemi con Ibasho

L’integrazione dei sistemi web con il sistema di autenticazione e autorizzazione, adottato dalla Regione Basilicata, ha un impatto minimo con la struttura dell’applicazione stessa. Ci sono alcune caratteristiche di base che devono essere rispettate affinchè l’applicazione possa integrarsi all’IMS:



  • Le applicazioni devono essere sviluppate con tecnologia Java come definito dalle specifiche tecniche e standard dell’ufficio SIRS;

  • Devono poter essere raggiungibili tramite nome di dominio (es. http://nomeapplicazione.dominio);

Per l’integrazione devono essere eseguiti i seguenti step:

  • Registrazione del servizio tramite console di amministrazione di Ibasho:

    • Registrazione del SP(Service Provider);

    • Definizione di un file che descriva le politiche di autorizzazione all’accesso della risorsa attraverso linguaggio descrittivo XACML 2.0.

  • Inclusione del Filtro di Ibasho nell’applicazione web Java:

    • Inclusione di un JAR nelle librerie dell’applicazione;

    • Modifica del web.xml con le specifiche del filtro;

    • Sviluppo di una Classe Java che implementi l’interfaccia del LogIn di Ibasho al fine di autenticare l’utente nella base dati locale al servizio.


Integrazione di applicazioni non-Java
Come già accennato esistono delle casistiche particolari in cui il componente Guard sviluppato in Java per il progetto Ibasho non si può inserire all’interno della web application che offre i servizi che devono essere integrati nel sistema SSO. Queste problematiche si possono riassumere con i seguenti casi:

  • Incompatibilità delle librerie con l’ambiente di distribuzione: si sono verificati diversi casi in cui il server contiene una versione dell’ambiente Java troppo datato o le librerie adottate da Ibasho entrano in conflitto con quelle del server.

  • Incompatibilità dell’ambiente di sviluppo: in questo caso non è questione di librerie Java ma di tecnologie e linguaggi di programmazione diversificati come ad esempio applicazioni scritte in .NET oppure in php.

  • Impossibilità di effettuare le chiamate interne tra i server: in questo filone ricadono le situazioni che vedono i server posti su reti diverse tra le quali si interpongo dei firewall o altre strutture che impediscono le comunicazioni tra le chiamate interne delle componenti Guanxi.

  • Impossibilità di modifica alle applicazioni preesistenti: questo avviene solitamente quando si chiede di modificare le web application sviluppate da altre aziende che non intendono modificare le librerie all’interno dei loro prodotti. In questo caso si cerca di offrire un componente software più leggero per l’integrazione con il sistema di single Sign On che non preveda l’utilizzo di librerie aggiuntive al di fuori di quelle J2EE standard.

Integrazione con sicurezza DEBOLE (WRAPPER)

L’idea di fondo della soluzione adottata è la creazione di una applicazione dedicata al Tunneling delle richieste di autenticazione. Questo significa che l’applicazione che definiremo client demanderà il processo di autenticazione utente ad una diversa applicazione che definiremo tunneling attraverso una apposita richiesta http. Questa applicazione tunneling ritornerà quindi l’elenco dei dati di profilazione utente alla applicazione client. Questa soluzione è orientata ad un’integrazione delle applicazioni tramite una sorta di wrapper che effettuerà una redirect, dopo l’autenticazione con l’IMS, all’applicazione da proteggere attraverso l’invocazione di una FORM POST in HTTPS. In questo scenario è fondamentale definire delle politiche di sicurezza aggiuntive a quelle offerte dal framework di SingleSignOn, come un filtro sugli indirizzi IP “certificati/attendibili” dai quali ricevere connessioni etc. La segretezza del canale di comunicazione che si instaura tra l’applicazione web del servizio e l’applicazione di tunneling viene garantita dall’utilizzo del Secure Sockets Layer attraverso chiamate con protocollo https.


Integrazione con sicurezza FORTE (SP di Shibboleth 2.0)

Questo è lo scenario più comune e tendenzialmente quello che nel medio lungo periodo sarà quello più utilizzato. È infatti possibile integrare con il sistema di autenticazione un qualunque Service Provider sviluppato con Shibboleth 2.0.

Questa soluzione permette di integrare qualsiasi Web server che gira su qualsiasi piattaforma e/o sistema operativo e permette quindi di integrare anche applicazioni sviluppate con tecnologie molto differenti (PHP, .NET etc).

Il nostro Idp è in grado quindi di rispondere a tutte le chiamate e le interrogazioni fatte tramite asserzioni SAML 2.0 su protocollo HTTPS sia in configurazione HTTP Redirect e http Post Binding. Le istruzioni ed il software per l’installazione di un service provider così descritto sono reperibili al seguente indirizzo: https://spaces.internet2.edu/display/SHIB2/Installation

Di seguito vengono forniti i metadati per la configurazione dei vostri ServiceProvider già configurati per il funzionamento con l’IMS.

Unica personalizzazione consiste nella definizione e configurazione degli attributi generati dall’IDP che desiderate siano visibili (in Session) nella vostra web application e il setting della variabile EntityID che sarà quella che vi verrà fornita in seguito alla registrazione del SP presso l’ Idp della Regione Basilicata.

Per la configurazione del vostro SP si rimanda alla documentazione ufficiale di Shibboleth 2.0 https://spaces.internet2.edu/display/SHIB2/Home.

2.2 Attribute Authority


L’AA è una componente fondamentale del sistema di identificazione e di accesso ai Sistemi Informativi della Regione Basilicata che hanno una restrizione di accesso, attraverso la definizione di un’opportuna policy XACML, per i Dipendenti Regionali. L’architettura generale del sistema prevede infatti un CORE di dati che arrivano tramite WS dal sistema del Personale e da altri sistemi periferici, che contribuiscono sempre all’alimentazione dei dati del personale. Grazie all’AA si è potuto quindi uniformare, oltre che la struttura del personale “dipendente” della regione, anche gli aspetti relativi all’organigramma secondo le specifiche definite nell’ambito dell’IPA Nazionale. I dati utili al DB Unico sono resi disponibili tramite opportuni WS esposti su ESB:

autoshape 5

autoshape 4

Tutti i sistemi che sono interessati all’aggregazione del dato comunicano e si scambiano i dati in tempo reale e le modifiche sulle posizioni organizzative, che fino ad ora venivano aggiornate a mano e in modo asincrono su tutti gli applicativi Legacy, ora invece sono trasmesse in automatico ai diversi applicativi solo al momento dell’accesso allo stesso da parte dell’utente identificato dall’IMS e di cui si è trovato riscontro nell’AA appunto. Di seguito un’immagine che descrive il processo di trasferimento delle informazioni dell’ architettura complessiva del sistema di gestione dei dati al quale dovranno partecipare per le aree di competenza i seguenti sotto sistemi:



  • Active directory dell’account di rete del dipendente regionale;

  • Account di posta elettronica istituzionale;

  • Carta multi servizi: firma digitale e carta multi servizi;

Il sistema ora in esercizio offre i seguenti vantaggi:



  • Unica struttura di aggregazione delle informazioni che riguardano il dipendente regionale;

  • Unica visione dei dati organizzativi dell’ente con tutte le informazioni a corredo come la mail, il numero di telefono fruibile per tutti i servizi di consultazione tramite WS;

  • Un sistema integrato con l’IMS per la richiesta e l’abilitazione all’accesso degli applicativi gestionali dell’ente (già registrati nell’IMS);

  • Un unico processo di registrazione/gestione degli account dei dipendenti regionali (interni ed esterni);

Lo scopo principale al quale assolve tale strumento è quello di rendere disponibile all’IMS i dati aggiornati dei Dipendenti Regionali, al fine di passare dati aggiornati alle applicazioni che, registrate nell’IMS, hanno bisogno dei dati specifici dei dipendenti regionali al fine di garantirne l’accesso e l’abilitazione:

Per poter amministrare questo enorme patrimonio di dati sono state rese disponibili tutte le interfacce necessarie per poter gestire ed amministrare tale sistema. Le interfacce sono di due tipi: interfaccia web per amministratori, interfaccia WS per sistemi che devono lavorare sui dati e sulla loro consultazione.



Web Amministrazione

La console di amministrazione offre la possibilità di poter amministrare ogni livello dello schema riportato sopra e quindi amministrare i dati di:



  • Amministrazione;

  • AOO, i Dipartimenti dell’ente;

  • UO, gli uffici dell’ente collegati in modo bidirezionale con le AOO;

  • Il Personale, direttamente gestito dall’ufficio Risorse Umane, che garantisce un collegamento bidirezionale con l’ufficio che a sua volta è collegato con il dipartimento (AOO);

  • I servizi che sono strettamente collegati alla persona e in qualche modo sono anche relativi alla posizione organizzativa attuale del Dipendente. Questo si rende necessario perché l’abilitazione all’accesso dei gestionali può e deve variare in funzione del ruolo e più in particolare della posizione organizzativa che la persona occupa all’interno dell’ente, con la possibilità da parte dell’amministratore di poter, all’abilitazione di un utente ad un servizio, inviare una mail direttamente al GSA.

Interfacce WS

Le interfacce WS sono indispensabili per mettere gli applicativi esterni in grado di poter operare sul DB Unico. In questa prima fase si prospetta un unico scenario d’interazione che riguarda il sistema di gestione del Personale in uso presso l’Ufficio Risorse umane della Presidenza della Giunta, il quale è l’unico deputato alla manutenzione dei dati dei dipendenti e delle variazioni nella struttura organizzativa.



Le interfacce WS sono disponibili per la consultazione, previa autorizzazione dell’Ufficio SIRS, sull’ESB, le cui specifiche, riferimenti sono riportate nel paragrafo 2.7 ESB Enterprise Service Bus.



2.3 Catalogo del software


Il catalogo dei servizi è una vista, ad uso interno, dei dati memorizzati sull’IMS e che includono tutte le informazioni dei Sistemi informativi presenti in regione. È possibile visualizzare nel catalogo generale tutte le informazioni pubbliche più tutte le informazioni utili alla gestione e alla manutenzione dei servizi. La visione d’insieme sulla problematica relativa all’erogazione dei servizi è complessa in quanto vede coinvolti, a diverso titolo, molti attori con aspettative ed esigenze molto diverse tra loro. Il principio fondante è quindi quello di un catalogo unico dei servizi della Regione Basilicata che sfrutti e metta a fattor comune alcune iniziative già strutturate e già in uso presso l’ente. In particolare la Console di gestione dell’IMS mappa i dati dei servizi integrati e protetti da autenticazione forte. Questo concetto di servizio è ampliato al fine di rendere disponibile la “tracciatura” di tutti i servizi, anche quelli che attualmente non risultano integrati con l’IMS regionale. In questo modo, estendendo i dati e ampliando lo spettro delle tipologie di servizi da gestire, saremo in grado di gestire tutti i servizi e di sfruttare le logiche implementate di accesso consentito agli “amministratori tecnici”. Nel catalogo regionale confluiscono tutti i sistemi informativi attualmente in produzione e ad oggi è l’unico canale che certifica l’identità del software e le politiche di accesso ed autorizzazione ad esso. Tutte le imprese che collaborano con la PA, come verrà profusamente descritto nei prossimi paragrafi, hanno l’obbligo di depositare a catalogo tutte le informazioni relative al servizio che si apprestano ad erogare sull’infrastruttura regionale.

http://catalogo.regione.basilicata.it/ (indirizzo e servizio visibile solo all’interno della rete Intranet regionale)


2.4 ALMS Auditing and Logging Management System


Il sistema di web analytics in uso presso la Regione Basilicata offre servizi interessanti come i rapporti sul sito e/o l’applicazione web in termini di numero di visitatori, pagerank, i referrel esterni, le parole chiave cercate e popolari, elencati in vari modi come grafico a barre, grafici a torta, semplice scritte testuali.  Inoltre, in pieno stile WEB 2.0, permette di costruire plugin ed estensioni. Il sistema, definito come ALMS (Auditing & Logging Management System) offre diverse modalità di comunicazione tra cui un’interfaccia WebServices. L’idea che di questo progetto è quella di provvedere all’implementazione di opportuni adapter atti ad integrare i flussi di archiviazione e gestione della documentazione con il sistema di logging in uso presso l’ente, in modo da consentire una tracciatura, sul sistema già in uso, di tutte le movimentazioni in ingresso ed in uscita verso il sistema di archiviazione sostitutiva. Questo approccio consentirà di avere e di poter consultare, sull’abituale console dell’ALMS, tutti i dati statistici di utilizzo anche delle integrazioni tra i sistemi applicativi. Questo consentirebbe all’ente di tenere traccia e monitorare tutto quello che avviene anche tra i sistemi dove sono i Service Provider a scatenare le azioni e non un utente che interagisce con una Web Application, riconducendo il tutto ad oggetti infrastrutturali già presenti. Questa dello User Tracking è una funzionalità preziosissima del sistema, che ha lo scopo di "accorgersi" in maniera implicita di alcune azioni dell'utente e registrare le informazioni relative nel profilo dell'utente stesso. Questo ci consentirà di aumentare la conoscenza sugli utenti che accedono ai sistemi dell’ente, sia a fini statistici e sia anche per rendere più efficaci eventuali azioni mirate di comunicazione.

http://alms.regione.basilicata.it/

(indirizzo e servizio visibile solo all’interno della rete Intranet regionale)




2.5 SVN Subversioning


SVN è il repository messo a disposizione dell’ente per la conservazione dei sorgenti e delle distribuzione del software messo a catalogo. Subversion (noto anche come svn) è un sistema di controllo versione per gestire il lavoro collaborativo di più persone in contemporanea sullo stesso progetto. Anche se Subversion è utilizzato prevalentemente da programmatori, le sue caratteristiche lo rendono utile anche per gestire file di tipo diverso come documentazione e persino file binari e distribuzioni in generale. Il più importante concetto di SVN è quello del repository che rappresenta l’archivio di dati centralizzato gestito direttamente da Subversion. Questo non è altro che la copia centralizzata alla quale inviare i file modificati e dalla quale scaricare le versioni più aggiornate dei file. Per lavorare sui file si utilizza il client SVN per creare una working copy locale. Tale copia è quella su cui vengono effettuate le vere e proprie modifiche, che poi verranno caricate sul server. La creazione di una nuova copia di lavoro locale è detta checkout. E’ importante sottolineare che tale operazione non blocca nessun file sul server. L’operazione inversa, e cioè il caricamento delle modifiche sul server è detta invece commit ed è proprio durante questa operazione che viene effettuato il controllo di versione da parte di Subversion indicando quali file sono stati modificati e se vi sono eventuali conflitti su questi file. Ogni aggiornamento inviato al repository genera una nuova revisione incrementando di 1 il numero di versione. Infine, per aggiornare una copia locale già esistente deve essere eseguita l’operazione di update.

Molti sistemi di controllo dei sorgenti adottano la tecnica Lock-Modify-Unlock: ogni volta che qualcuno vuole modificare un file deve prelevarlo e gli altri programmatori non hanno più alcuna possibilità di accesso al file finchè il primo utente completi le modifiche e riconsegni il file. Subversion adotta invece la soluzione Copy-Modify-Merge: i file non vengono bloccati dal primo che li apre, ma rimangono disponibili per chiunque e al momento del commit tenta di unire le diverse modifiche, controllando la presenza di eventuali conflitti. Detto ciò è importante sottolineare che Subversion non è un semplice sistema di archiviazione e distribuzione. Il suo obiettivo principale è quello di gestire i cambiamenti nel tempo, conservando una copia di ciascuna versione e dandoci la possibilità di tracciare chi e quando ha introdotto certe modifiche. L’account e le abilitazioni all’utilizzo di tale servizio sono da richiedersi esplicitamente all’ufficio SIRS.



http://svn.regione.basilicata.it/

(indirizzo e servizio visibile solo all’interno della rete Intranet regionale)



2.6 Catalogo dei Servizi Web


Governance Registry permette di gestire problematiche di accessibilità, mantenere una libreria di tutti i servizi esistenti e permettere agli utenti di condividere informazioni sui servizi. In un’architettura SOA (Service Oriented Architecture) il registry-repository è lo strumento deputato a:

  • censire e catalogare servizi (catalogo di chi offre cosa, con quali interfacce e dove)

  • mantenere i documenti delineati dal SOA Reference Model di Oasis (descrizioni delle funzioni, degli effetti, policy, contratti, ecc.)

  • gestire il ciclo di vita dei servizi (dalla definizione alla produzione, versioni comprese)

Mentre la prima funzionalità è propria della “parte registry“, le altre sono richieste alla “parte repository“. Avvalendosi, però, dei tModels (definibili in breve come etichette legate a valori, URI o altri tModels), è possibile “implementare” quello che si richiede ad un repository (se pur con delle limitazioni). Il prezzo da pagare è la complessità, mitigabile da interfacce utente (utilizzabili solo da umani) o API (che hanno però il difetto di essere proprietarie e di riportare al problema di partenza).

Il registry-repository non può e non deve essere uno strumento isolato dal resto: per il governo, per il riuso, per il rigore del flusso di lavoro (la progettazione, ad esempio, deve poter contare sul registry-repository per sapere cosa già esiste e cosa manca, l’IDE utilizzato per “sviluppare” le composizioni, le orchestrazioni ed i processi deve potersi integrare, ecc.). L’integrazione con le BestPractice e le politiche di accesso alle informazioni serve a collocarlo nel flusso di lavoro, favorendone (potremmo dire imponendone) l’utilizzo; il flusso di lavoro e l’utilizzo contribuiscono al governo della SOA a livello regionale(la governance).



2.9 Portale dei Servizi


Il portale dei Servizi è il punto nel quale si troveranno catalogati, nel modo definito dalla Governance di progetto, tutti i servizi disponibili. Per servizio intendiamo un processo, applicazione informatizzata che abbia uno scenario d’interazione definito e circoscritto ad una problematica nota della PA. Questo portale ospiterà quindi le risultanti degli sforzi che nascono da progetti dell’ente relativamente all’erogazione di servizi al Cittadino, inteso come utilizzatore finale del servizio a prescindere dal livello di profilazione con il quale esso viene riconosciuto. Un cittadino infatti, se opportunamente riconosciuto, potrà agire sia da Cittadino privato, che da Ente o da Imprese. Altro obiettivo del portale è quello espressamente informativo, grazie al quale suggerire informazioni e servizi in tempo reale sui servizi attivi, quelli che saranno attivati e lasciando uno spazio anche al suggerimento e alle proposte del cittadino utilizzando canali collaudati quali i portali istituzionali, le email, i questionari e i feedback in generale. (Rif. CRM)
http://servizi.basilicatanet.it/

2.7 ESB Enterprise Service Bus


La realizzazione della SOA basata sui WS porta alla creazione di molte comunicazioni punto-a-punto, rendendo spesso l’intera infrastruttura difficile da manutenere a fronte di cambiamenti nei servizi stessi. Infatti, in questo modello, se cambia anche solo il protocollo per accedere ad un servizio è necessario modificare tutti i componenti che dipendono da quel servizio. Per questo motivo, più un’organizzazione abbraccia il paradigma SOA più sentirà la necessità di un’infrastruttura che, da un lato, renda uniforme l’accesso ai servizi, e, dall’altro, possa essere impiegata per utilizzi più sofisticati dei servizi stessi. Gli Enterprise Service Bus hanno inoltre il grande compito di uniformare l’accesso ai servizi, in particolare soluzioni middleware pre-esistenti e sistemi legacy: gli ESB, infatti, rendono accessibili tutti gli applicativi in modo assolutamente omogeneo e coerente con il modello basato sui WS. Mediante l’introduzione di un ESB, tutte le comunicazioni fra i servizi vengono effettuate attraverso di esso in modo assolutamente trasparente agli stessi servizi: è addirittura possibile trasformare i messaggi prima che questi vengano effettivamente consegnati, con- sentendo una normalizzazione utile durante l’intera esecuzione dei processi di business. Questa caratteristica è di primaria importanza, poiché in questo modo è possibile evitare la propagazione dal produttore al consumatore di eventuali modifiche: ad esempio, se cambiasse il formato dei messaggi in ingresso ad un servizio, basterebbe introdurre, all’interno dell’ESB, una trasformazione dal vecchio al nuovo formato. Un Enterprise Service Bus (ESB) è un’infrastruttura software che fornisce servizi di supporto ad architetture SOA complesse. Con la locuzione inglese di Service-Oriented Architecture viene indicata un’architettura software atta a supportare l’uso di servizi per soddisfare le richieste degli utenti così da consentire l’utilizzo delle singole applicazioni come componenti del processo di business. (fonte: Wikipedia). La soluzione, chiamata WSO2 ESB, è un software lato server progettato per essere integrato in svariate applicazioni. Il suo compito è quello di tradurre differenti protocolli e convertire differenti formati XML. Il prodotto è basato su Synapse, un ESB open source sviluppato dalla Apache Foundation in stretta collaborazione proprio con alcuni dipendenti della stessa WSO2. Il nuovo ESB permette di aggiungere maggiori funzionalità a Synapse come ad esempio una console di amministrazione basata su web, un registro e un repository.

http://esb.regione.basilicata.it/

(indirizzo e servizio visibile solo all’interno della rete Intranet regionale)


2.8 BPS Business Process Server


La Regione Basilicata dispone di un Business Process Server (BPS), utilizzato già con successo per le integrazioni tra i sistemi e l’Attirbute Authority Regionale. IL BPS è un server che esegue flussi scritti in linguaggio BPEL. BPEL costituisce infatti il linguaggio standard per la Process Orchestration e rappresenta sicuramente uno dei componenti fondamentali per realizzare delle Service Oriented Architecture: esso, infatti, permette l’integrazione e la cooperazione di diverse componenti, generando così dei servizi web dal valore aggiunto che mantengono le caratteristiche di modularità e scalabilità. Nel programma di lavoro proposto in questo progetto l’idea è quella di definire un insieme di workflow operativi, generati da attività atomiche e sapientemente invocati da un unico gestore logico esterno. L’approccio è quello per cui il controllo del workflow viene mantenuto da un solo gestore logico, che interagisce, anche per processi di lunga durata, con altri servizi, interni od esterni. In questo particolare contesto la definizione di un workflow si traduce nella definizione del flusso di lavoro che effettua operazioni passando da un task all’altro, gestendo stati e risultati; d’altro canto, la definizione di un processo orchestrato significa introdurre un elemento centrale nel processo, che possiede il controllo del flusso che circola tra i servizi, che quindi possono essere assimilati ai task dello stesso workflow.
Il linguaggio BPEL è stato riconosciuto come standard per l’orchestrazione di servizi web, quindi per la definizione dei processi di business: esso, infatti, mette a disposizione diverse funzioni per l’elaborazione dei dati ricevuti dai web service partner del processo, e, tramite funzioni X-Path, esegue operazioni anche complesse su di essi. 
In figura 2 viene riportato uno schema generale di processo BPEL.

L’interesse destato dal business process è dovuto alla necessità da parte delle organizzazioni di riutilizzare lavori precedentemente redatti, ridurre i tempi morti, aumentare le capacità di notifica e provvedere alla standardizzazione delle procedure. Rispetto ai tradizionali linguaggi di programmazione i sistemi di workflow mettono a disposizione degli strumenti con un maggior livello di astrazione così che la gestione dei dati e la gestione dei processi possono essere considerati due moduli separati che aumentano la flessibilità nello sviluppo di applicazioni. Infatti i cambiamenti, quale l’introduzione di nuove attività di un processo, non richiedono la riscrittura integrale delle applicazioni, le quali possono essere modificate velocemente. Da tutto questo si può dedurre che un sistema di workflow è una piattaforma di servizi che consente di descrivere, gestire ed eseguire un processo in termini di attività, relazioni tra attività e ruoli, di coordinare l’interazione tra le attività e i dati del processo con gli strumenti e le altre applicazioni operanti su diverse piattaforme software e hardware, riutilizzare lavori precedenti, integrare sistemi di BackOffice e ridurre i tempi morti aumentando invece la diffusione dei messeggi e delle informazioni. La maggior parte dei workflow progettati si basano su due tipi di architetture: una prevede un’interfaccia tra i task tramite messaggi , l’altra l’introduzione di un gestore che tenga traccia delle evoluzioni di ogni istanza del processo, aumentando in tal modo il livello di flessibilità nello sviluppo delle applicazioni.

Il workflow basato su BPEL si pone l’obiettivo di automatizzare e monitorare l’elaborazione di pratiche complesse scatenate dall’invocazione e/o la ricezione di messaggi dal dominio di cooperazione applicativa che si basano sul modello di porta di dominio. Negli ultimi anni la gestione dei processi ha costituito uno dei argomenti più interessanti su cui si concentrano gli sforzi di molte aziende ed organismi di standardizzazione. Riuscire a definire uno standard con cui descrivere un processo aziendale costituisce un enorme passo avanti in termini di flessibilità e ritorno degli investimenti. Infatti se da un lato i web services sono visti come un elemento chiave per integrare i sistemi Legacy, dall’altro e’ necessario disporre di strumenti e standard che permettano di descrivere il processo per poter intervenire in modo più semplice e flessibile alle richieste di cambiamento. Lo standard OASIS definisce l’orchestrazione di processo in termini di interazioni tra servizi web.

Con il termine Orchestrazione si fa riferimento all’esecuzione di un processo che può interagire con Web Services interni o esterni. L’orchestrazione definisce le interazioni dei Web Services a livello di messaggi, la logica di processo e l’ordine delle interazioni. Queste interazioni possono coinvolgere molte applicazioni e/o organizzazioni definendo un processo transazionale. L’orchestrazione è sempre controllata da una sola organizzazione.

La Regione Basilicata ha scelto di puntare sulla tecnologia BPEL per realizzare l’orchestrazione di processo.
BPEL (l' acronimo sta per Business Process Execution Language) è un linguaggio basato sull' XML costruito per descrivere formalmente i processi in modo da permettere una suddivisione dei compiti tra attori diversi attraverso una combinazione di Web services. Ciascun processo, definito attraverso una interfaccia grafica semplice ed intuitiva può essere posto in esecuzione nel rispetto dei vincoli e dei ruoli definiti, avendo la garanzia di una sua completa tracciabilità. Il Workflow è elemento fondamentale per l’interazione e la cooperazione applicativa e specialmente per le pratiche che richiedono una notifica o una propagazione dei messaggi in più contesti applicativi. Il servizio di workflow BPEL si interfaccerà alle porte di dominio (nelle varie configurazioni), alla posta certificata ed al servizio di protocollo. Ricorrere ad uno standard di integrazione J2EE-like e ad un mercato di Componenti standard preconfezionati, pluggabili nell'infrastruttura di integrazione potrebbe consentire la riduzione dei tempi e dei costi di sviluppo dell'integrazione indirizzando soluzioni standard, scalabili e portabili. Infatti, si potrebbe consentire il deploy e l'aggregazione di componenti sviluppati da diversi vendor all'interno di questi ambienti di integrazione. Questo permette di scegliere il miglior componente per la specifica situazione (best of breed) d'integrazione all'interno di una infrastruttura standard di integrazione. Questo aiuterebbe significativamente ad aumentare l'interoperabilità tra i sistemi d'integrazione, la flessibilità ed il riuso per diminuire conseguentemente la complessità tipici delle attuali soluzioni d'integrazione. Quindi un passo significativo adottando una soluzione di integrazione basata su standard consente la drastica riduzione del vendor lock-in che "attanaglia" da sempre le suite d'integrazione.

A tendere potremmo quindi avere una situazione nella quale un insieme di flussi BPEL sono esposti su un ESB e invocati tramite opportune chiamate d'interazione a seguito di eventi “scatenanti” azioni complesse. Questo approccio consentirebbe di avere una separazione degli strati funzionali/logici tra la rappresentazione utente delle funzioni di business e la logica interna di ogni singolo SISTEMI INFORMATIVI, adottando pertanto un approccio SOA like.



http://bps.regione.basilicata.it/

(indirizzo e servizio visibile solo all’interno della rete Intranet regionale)


2.10 Kaistar – Wizard CMS


Il Wizard CMS Kaistar è una applicazione web capace di gestire in maniera automatica e trasparente la creazione e la configurazione di una web application basata sul CMS Kaistar. Tutto il processo prevede:

  • La creazione del database di riferimento e il rispettivo utente;

  • La creazione della CDA e della CMA;

  • Il deploy della webapp all'interno di un Apache Tomcat;

  • La creazione del virtual-host all'interno di Apache Httpd Server nella forma cms.nomedominio.it/contextapplicazione.

Il Wizard è stato strutturato in modo da poter gestire delle istanze di Kaistar arbitrarie, create tramite un’interfaccia grafica che consente di vedere tutte le istanze create, la data di pubblicazione etc. il sistema risponde sotto un URI pubblicato sotto il seguente dominio: http://cms.regione.Basilicata.it.




Condividi con i tuoi amici:
  1   2   3


©astratto.info 2019
invia messaggio

    Pagina principale