oscat.rete.toscana.itoscat.rete.toscana.it/docman/view.php/250/864/RT_Semplificazione... · Web...

REGIONE TOSCANA

Progettazione, Realizzazione e Manutenzione di Prodotti Software per l'innovazione e la semplificazione nella

Pubblica Amministrazione Toscana

Specifiche Tecniche Architettura Software

TAI SRLTECNOLOGIEE APPLICAZIONIINFORMATICHE

CONTROLLO DEL DOCUMENTO

Rif. Documento T.A.I. 20110321CR05Numero di Versione 1.3Data del Documento 03 Agosto 2011Autori Redatto da Christian Simonelli, Francesco Fornasari

Revisionato daApprovato da Eugenio Mattei

Revisioni 1.0 del 21.03.2011 Versione Iniziale1.1 del 11.05.2011 Riorganizzazione documento e contributi segnalati da

Walter Volpi1.2 del 01/06/2011 Integrazione dei paragrafi su help contestuale, reportistica

e logging1.3 del 10/08/2011 Precisazioni relative a capitolo Alfresco

Trattazione caso reale d’uso per realizzazione sistema a cartelle documentali condivise

Pag. 2 di 59


SOMMARIO1 Introduzione...............................................................................................................................6

1.1 Sommario.............................................................................................................................6

1.2 Acronimi...............................................................................................................................6

1.3 Pattern Enterprise di Riferimento........................................................................................7

2 Architettura Generale del sistema..............................................................................................8

2.1 Componente Orchestratore...............................................................................................11

2.1.1 Motore BPM - Workflow............................................................................................12

2.1.2 Motore basato su Regole – Rule Engine.....................................................................14

2.1.3 Enterprise Integration Engine.....................................................................................15

2.1.4 Console di gestione e amministrazione dei processi..................................................18

2.2 Componente Applicazione.................................................................................................22

2.2.1 Liferay Portal.............................................................................................................. 23

2.2.2 Liferay Social Office.....................................................................................................23

2.2.3 Alfresco.......................................................................................................................24

2.2.4 Integrazione Liferay Portal – Alfresco.........................................................................25

2.2.5 Modellazione sistema a cartelle documentali condivise............................................34

2.2.6 Sistema Trasversale di Firma......................................................................................41

2.2.7 Protocollo Informatico................................................................................................41

2.2.8 Architettura nuove applicazioni..................................................................................41

2.2.9 Sicurezza.....................................................................................................................49

2.2.10 Help contestuale.........................................................................................................50

2.2.11 Reportistica.................................................................................................................52

2.2.12 Gestione dei log..........................................................................................................53

3 Organizzazione e modalità di lavoro.........................................................................................55

Pag. 3 di 59


INDICE DELLE FIGUREFigura 1: Architettura Software Generale...........................................................................................9Figura 2: Interazioni tra i diversi livelli architetturali........................................................................11Figura 3: Ciclo di vita di un processo................................................................................................12Figura 4: Componenti disponibili all’interno dell’editor BPMN di Eclipse........................................13Figura 5: Editor BPMN visuale di Eclipse..........................................................................................13Figura 6: Editor BPMN visuale basato su Web..................................................................................14Figura 7: Editor per la creazione di rule............................................................................................15Figura 8: Pattern Service Proxy.........................................................................................................16Figura 9: Pattern Service Wrapper...................................................................................................17Figura 10: Esempio di Evento Asincrono basato su rule...................................................................17Figura 11: Integrazione in BPMN 2.0 di un evento...........................................................................18Figura 12: Definizione di Knowledge Bases......................................................................................19Figura 13: Editor Regole................................................................................................................... 19Figura 14: Definizione di Endpoints Camel.......................................................................................20Figura 15: Gestione Routes.............................................................................................................. 20Figura 16: Messaggi inviati sul Bus di Camel e non ancora consumati.............................................20Figura 17: Interfaccia Web JBPM per la gestione delle istanze di processo.....................................21Figura 18: Esempio di Task Assegnato all’utente..............................................................................22Figura 19: Architettura Generale - Livello Applicazioni Web............................................................22Figura 20: Repository Alfresco - Struttura Document Libray Liferay................................................28Figura 21: Form per inserimento documentale in Liferay................................................................29Figura 22: Liferay-Alfresco SSO.........................................................................................................30Figura 23: Alfresco Document Library Portlet Repository................................................................31Figura 24: Afresco Share Portlet - gestione metadati.......................................................................31Figura 25: Gestione permessi nodi Alfresco da Liferay.....................................................................32Figura 26: Gestione aspetti nodi Alfresco da Liferay........................................................................32Figura 27: Modifica nodo documentale Alfresco attraverso Liferay.................................................33Figura 28: Schema funzionale integrazione Alfresco Share Portlets.................................................33Figura 29: Frammento di Organigramma di RT................................................................................35Figura 30: Liferay Organizzazioni Inserimento..................................................................................35Figura 31: Frammento Organigramma RT in Liferay.........................................................................36Figura 32: Document Library dell’organizzazione.............................................................................36Figura 33: Azioni sull’Organizzazione...............................................................................................37Figura 34: Frammento Organigramma RT in Alfresco......................................................................39Figura 35: Creazione folder documentale........................................................................................39Figura 36: Impostazione dei permessi sulla folder documentale.....................................................40Figura 37: Gestione permessi folder documentali per gruppi disgiunti............................................40Figura 38: Architettura di dettaglio Componente Applicazione.......................................................42Figura 39: Invocazione Servizio Orchestrato Sincrono.....................................................................44Figura 40: Invocazione Servizio Orchestrato Asincrono...................................................................44

Pag. 4 di 59


Figura 41: Creazione template per help on-line...............................................................................51Figura 42: Configurazione template per help on-line.......................................................................52

INDICE DELLE TABELLETabella 1: Acronimi.............................................................................................................................7

Tabella 2: Pattern Enterprise di Riferimento......................................................................................8

Pag. 5 di 59


1 INTRODUZIONE Facendo riferimento all’offerta tecnica in risposta al bando di gara, il presente documento si pone l’obiettivo di analizzare con un maggiore livello di dettaglio l’architettura generale (aperta e modulare) proposta per la realizzazione ed il dispiegamento delle diverse soluzioni applicative oggetto di gara.

Come già ampiamente spiegato in offerta tecnica, è stato scelto di proporre una architettura software di riferimento valida per tutte le soluzione applicative previste in gara, che includa tutte le componenti che possono essere messe a fattor comune per più applicazioni.

Attraverso l’adozione di standard open source e pattern enterprise già collaudati, l’architettura generale, descritta nei prossimi capitoli, permetterà di implementare in maniera uniforme, secondo un approccio integrato, i processi aziendali e le singole applicazioni oggetto dei processi stessi.

1.1 Sommario

L’organizzazione del documento è la seguente: Il Cap. 2 contiene la descrizione dell’architettura generale del sistema costituita dal

componente orchestratore e dal componente applicazione.A sua volta il capitolo è suddiviso nella parte di descrizione tecnica del componente orchestratore (§ 2.1) e del componente applicazione (§ 2.2).

Il Cap. 3 contiene la descrizione del flusso organizzativo e delle modalità operative attraverso le quali sarà implementato il flusso stesso.

1.2 Acronimi

Nel resto del documento si fa uso degli acronimi che seguono.

Sigla AcronimoARPA Autenticazione Ruoli Profili ApplicazioniBPEL Business Process Execution LanguageBPM Business Process ManagementCART Infrastruttura di Cooperazione Applicativa di Regione ToscanaCIFS Common Internet File SystemCMIS Content Management Interoperability ServicesEAI Enterprise Application IntegrationESB Enterprise Service BusGUI Graphical User Interface

Pag. 6 di 59


J2EE Java 2 Enterprise EditionJNDI Java Naming Directory InterfaceJSP Java Server PageMVC Model View ControllerORM Object Relational MapperQR Quick Response (QR Codes)RDBMS Relational Data Base Management SystemREST Representational Transfer StateRT Regione ToscanaSOA Service Oriented Architecture

Tabella 1: Acronimi

1.3 Pattern Enterprise di Riferimento

Saranno utilizzati i seguenti pattern enterprise di riferimento (fonte wikipedia):

Sigla AcronimoActive Record Include a data access object within a domain entityApplication Façade Centralize and aggregate behavior to provide a uniform service layerCapture Transaction Details Create database objects, such as triggers and shadow tables, to record changes to all

tables belonging to the transactionChain of Responsibility Avoid coupling the sender of a request to its receiver by allowing more than one

object to handle the requestCoarse Grained Lock Lock a set of related objects with a single lockCommand Encapsulate request processing in a separate command object with a common

execution interfaceData Mapper Implement a mapping layer between objects and the database structure that is used

to move data from one structure to another while keeping them independentData-driven Workflow A workflow that contains tasks whose sequence is determined by the values of data in

the workflow or the systemDomain Model A set of business objects that represents the entities in a domain and the relationships

between themEntity Translator An object that transforms message data types to business types for requests, and

reverses the transformation for responsesHuman Workflow A workflow that involves tasks performed manually by humansImplicit Lock Use framework code to acquire locks on behalf of code that accesses shared

resourcesOptimistic Offline Lock Ensure that changes made by one session do not conflict with changes made by

another sessionPessimistic Offline Lock Prevent conflicts by forcing a transaction to obtain a lock on data before using itQuery Object An object that represents a database queryRepository An in-memory representation of a data source that works with domain entitiesRow Data Gateway An object that acts as a gateway to a single record in a data sourceSequential Workflow A workflow that contains tasks that follow a sequence, where one task is initiated

after completion of the preceding task

Pag. 7 di 59


State-driven Workflow A workflow that contains tasks whose sequence is determined by the state of the system

Table Data Gateway An object that acts as a gateway to a table or view in a data source and centralizes all of the select, insert, update, and delete queries

Table Module A single component that handles the business logic for all rows in a database table or view

Transaction Script Organize the business logic for each transaction in a single procedure, making calls directly to the database or through a thin database wrapper

Tabella 2: Pattern Enterprise di Riferimento

2 ARCHITETTURA GENERALE DEL SISTEMA

Negli ultimi anni, nell’ambito dello sviluppo software in ambiente J2EE, si è osservato il fiorire di una nuova generazione di framework, ambienti e strumenti di supporto allo sviluppo ed al dispiegamento delle web application, di cui si intende fare un uso pervasivo.

L’architettura proposta prevede infatti l’utilizzo di un nutrito insieme di librerie e framework, allo stato dell’arte della tecnologia, la cui integrazione permette di perseguire e raggiungere l’obiettivo della facilità di sviluppo, manutenzione e riuso delle applicazioni.

Come evidenziato nei paragrafi seguenti, l’architettura sarà orientata ai servizi (SOA), e lo sviluppo applicativo farà leva su un ambiente di generazione semi-automatica del software e delle interfacce che includerà:

un potente motore di workflow per la gestione flessibile e riconfigurabile di tutti i flussi applicativi;

uno standard di programmazione basato su pattern enterprise e framework open source; un ambiente di produzione e generazione automatica delle form di interfaccia utente di

ultima generazione (Rich Internet Applications); un sistema di indirizzamento innovativo basato su QR codes; strumenti di supporto, integrati tramite interfacce aperte, per la memorizzazione, la

gestione documentale, l’information retrieval; l’integrazione configurabile (senza scrittura di software aggiuntivo) con l’infrastruttura

ARPA.

Pag. 8 di 59


L’architettura di riferimento è schematizzata nella figura seguente:

Figura 1: Architettura Software Generale

L’architettura software di riferimento, basata sull’approccio SOA, risulta particolarmente adatta a supportare l'uso di servizi Web per garantire l'interoperabilità tra diversi sistemi così da consentire l'utilizzo delle singole applicazioni come componenti del processo di business e soddisfare le richieste degli utenti in modo integrato e trasparente.

In generale, un’architettura di questo tipo tratta le applicazioni di business come un insieme di servizi che erogano funzionalità sulla base delle esigenze aziendali; indipendentemente dalla tecnologia di implementazione, ciò che caratterizza una SOA è la logica dei servizi indipendenti, che possono essere chiamati per svolgere il loro lavoro in una modalità standard, senza che il singolo servizio abbia a priori informazioni sull’applicazione che lo chiamerà.

Questo tipo di soluzione, particolarmente adatta per la modellazione di sistemi preesistenti ed eterogenei composti da processi di business e applicazioni di supporto, è basata sull’utilizzo di

Pag. 9 di 59


sistemi evoluti di integrazione (EAI) che fanno uso di middleware standard di comunicazione (ESB) in grado di disaccoppiare le applicazioni client dai servizi; nel nostro caso l’applicazione client è il motore di workflow (Workflow Engine).

In Figura 1 sono stati quindi messi in risalto i 2 componenti principali dell’architettura di riferimento che saranno ulteriormente dettagliati in seguito:

componente applicazione, ovvero una generica applicazione web, progettata secondo un approccio multitier, in grado di esporre servizi web di integrazione;

componente orchestratore, ovvero un processo di business più ad alto livello che ha il compito di gestire (orchestrare) il flusso logico di operazioni tra le diverse applicazioni in gioco.

I processi di business vengono orchestrati attraverso un motore di workflow avanzato che fa uso di Enterprise Integration Framework ed Enterprise Event-Driven per la comunicazione con i servizi periferici e il loro cambiamento di stato.

Pag. 10 di 59


2.1 Componente Orchestratore

Il paragrafo ha come obiettivo quello di descrivere come verrà realizzato il componente orchestratore il cui compito è quello di gestire gli stati di un determinato processo organizzativo attraverso l’interazione con risorse esterne (applicazioni, fonte dati, servizi) e persone.

Siccome i processi organizzativi possono essere diversificati e soggetti a cambiamenti è necessario realizzare un’architettura modulare ed estendibile. Di seguito sono mostrate le interazioni tra i diversi livelli architetturali.

Business Process Layer

Component & Service Layer

Application Layer

Figura 2: Interazioni tra i diversi livelli architetturali

In particolare l’orchestratore sarà composto dai seguenti componenti architetturali:

Un motore BPM (Business Process Management) per la gestione dei processi organizzativi.

Un motore basato su regole ( rule engine ) per rendere il workflow il più automatizzato possibile

Un Enterprise Integration Engine che permetta l’interazione tra Workflow e risorse esterne

Console di gestione e amministrazione dei processi

Pag. 11 di 59

Enterprise Integration Enterprise Event-DrivenSecurity Invocation Service


Un servizio di sicurezza per permettere alle applicazioni di verificare se le richieste ricevute sono state generate dall’orchestratore.

I prodotti opensource utilizzati nell’implementazione dei componenti architetturali appena descritti saranno Jboss JBPM, Jboss Drools, Spring, Spring Integration, Apache Camel (che fa uso di Apache CXF, ecc.).

2.1.1 Motore BPM - Workflow

Il punto cardine dell’orchestratore è il workflow (che si basa sul paradigma architetturale BPM) che descrive i processi come insieme di attività collegate da vincoli di precedenza e punti di sincronizzazione. Questo comprende:

Modello dei Processi (un insieme di task e un insieme di connettori che specificano l’ordine in cui i task sono eseguiti)

Modello dei dati (definisce: variabili, documento, form grafiche)

Modello dell’Organizzazione (per specifica degli attori ed autorizzazioni) Un processo è caratterizzato da un insieme di attività collegate tra loro per fornire un certo output a partire da input definiti. L’output può essere un prodotto o un servizio e viene utilizzato da determinati client o utilizzatori. Il processo nella sua esecuzione può richiedere l’interazione con diverse fonti di informazione.

Uno schema generale di processo è:

Figura 3: Ciclo di vita di un processo

La definizione di un processo si basa su di un’analisi accurata del modello organizzativo e di un adattamento di esso ad uno di più semplice realizzazione. Il risultato di questa attività dovrebbe permettere l’identificazione di Eventi (inizio, interruzione e terminazione del processo), le Azioni e i Punti di Decisione (che possono dar luogo a differenti prosecuzioni del processo).

I processi verranno realizzati ed eseguiti (istanza del processo) utilizzando la suite Jboss JBPM che offre anche un ambiente di sviluppo ed un framework di riferimento per la gestione dell’intero ciclo di vita di un processo. Per quanto riguarda la stesura del processo esiste un linguaggio

Pag. 12 di 59

ProcessoInput da Attivatori Output per Destinatari


standard (utilizzato anche in JBPM) chiamato BPMN 2.0 che mette a disposizione una serie di costrutti che permettono la definizione di processi.

Figura 4: Componenti disponibili all’interno dell’editor BPMN di Eclipse

JBPM mette a disposizione due editor visuali, uno standalone (come plugin di Eclipse) ed uno web per permettere la definizione processi BPMN 2.0.

Figura 5: Editor BPMN visuale di Eclipse

Pag. 13 di 59


Figura 6: Editor BPMN visuale basato su Web

Sono disponibili diversi modelli di rappresentazione per i processi ma, in questo tipo di architettura è preferibile utilizzarne uno “System Oriented” (con il minor numero possibile di interazioni umane) basati su un’interazione forte con sistemi SOA eterogenei distribuiti.

2.1.2 Motore basato su Regole – Rule Engine

Un altro paradigma utilizzato per la definizione della logica di business è quello basato su regole (rule). Questo può essere utilizzato insieme a strumenti di Workflow disaccoppiando la logica di processo da quella non funzionale, permettendo di adattare più rapidamente il sistema in seguito a cambiamenti alle politiche di business.

Esempi nei quali un motore di “rule engine” può essere utilizzato all’interno di un Workflow

Decidere quale processo istanziare

Nell’esecuzione di Punti di Decisione

Utilizzabili per l’assegnamento di Human Task

Etc

Pag. 14 di 59


Figura 7: Editor per la creazione di rule

2.1.3 Enterprise Integration Engine

Un aspetto rilevante durante l’esecuzione di un processo è come consentire l’interazione con risorse esterne (CART, applicazioni Custom, ecc).

In generale una risorsa esterna è una applicazione che offre servizi; l’orchestratore per accedere a tali servizi deve conoscerne le modalità (protocollo, Url di Accesso, credenziali, ecc) con cui utilizzarlo.

Per semplificare la definizione e la gestione dei processi di business è necessario spostare l’informazione sulle modalità di accesso alle risorse a livello di servizio.

Questo è possibile integrando all’interno dell’orchestratore framework per la gestione di “Enterprise Integration Service” (EIS) che fornisce un middleware di comunicazione per consentire il disaccoppiamento delle applicazioni client dai servizi.

Il sistema EIS è quindi utilizzabile dal solo orchestratore, così come lo sono i metodi di conversione utilizzati, che saranno specifici e studiati ad hoc dei processi che li utilizzeranno.

I framework utilizzabili per questo tipo di attività sono Spring Integration ed Apache Camel che, oltre a fornire un ambiente dichiarativo di sviluppo basato sul pattern “Inversion of Control”, forniscono una serie di adapter già pronti per essere utilizzati.

Pag. 15 di 59


Un Integration Service ha quindi lo scopo di:

Fornire un'interfaccia a servizi di applicazioni già esistenti, esponendo come un servizio un qualcosa che servizio non è.

Utilizzare al suo interno API specifiche della tipologia della risorsa EIS.

Nascondere al consumer la tipologia e la topologia dell'EIS.

Aggregare più funzionalità esistenti al fine di esporre un servizio con la giusta granularità.

Effettuare il mapping tra il data model della risorsa EIS e il business model disaccoppiando il service consumer dalla specificità della risorsa.

Possibilità di gestione e configurazione dei servizi disponibili.

I framework che implementano questo tipo di architettura, attenendosi alle specifiche del pattern “Service Proxy” oltre disaccoppiare l’accesso ai servizi di business dai client, forniscono un servizio di localizzazione ed utilizzo per l’utilizzo dei servizio di business.

Questo porta i seguenti vantaggi:

fornire un'interfaccia uniforme ai client.

ridurre l'accoppiamento tra service consumer e service provider.

nascondere, centralizzare e gestire le problematiche di reperimento (lookup / discovery) e utilizzo dei servizi.

nascondere le particolarità tecnologiche della specifica comunicazione con l'EIS

centralizzare le modifiche derivanti da variazione dei servizi di business in una sola classe

garantire la possibilità di trasformare eccezioni tecnologiche (es: java.rmi.RemoteException, javax.xml.rpc.ServiceException, ...) in eccezioni applicative

Figura 8: Pattern Service Proxy

Pag. 16 di 59


Le nuove applicazioni integrate con l’orchestratore, a meno di eccezioni particolari, definiranno tutte un’interfaccia standard predefinita; in questo caso del sistema EIS vengono utilizzate le specifiche del pattern “Service Wrapper”, un meccanismo che ne consenta l’utilizzo all’interno dell’orchestratore.

Figura 9: Pattern Service Wrapper

Il gestore di eventi permette la ricezione di eventi esterni in modo asincrono consentendo al processo di gestire tale situazione. Gli eventi, nella maggior parte dei casi, devono essere gestiti in modo trasversale al processo stesso e, per questo, il motore di rule engine di Jboss Drools è la soluzione ideale.

Gli eventi gestiti dall’orchestratore in generale saranno di due tipi:

Evento per segnalare l’inizio di un processo

Evento di task asincrono esterno (come approvazione e attesa evento esterno) a seguito di una richiesta proveniente dall’orchestratore; in questo caso l’evento esterno dovrà contenere l’identificativo univoco della richiesta precedentemente ricevuta dall’orchestratore.

rule "Sound the alarm"when $f : FireDetected( ) not( SprinklerActivated( ) )then // sound the alarmend

Figura 10: Esempio di Evento Asincrono basato su rule

Pag. 17 di 59


Figura 11: Integrazione in BPMN 2.0 di un evento

2.1.4 Console di gestione e amministrazione dei processi

La console di amministrazione offre una serie di servizi che permettono la gestione del ciclo di vita dei processi.

Il ciclo di vita si può riassumere in 3 fasi:

Implementazione dei componenti che determinano una definizione di processo. Configurazione dei Servizi esterni utilizzati Istanziazione e Storicizzazione del Processo (Start)

2.1.4.1 Gestione dei processi

I componenti che descrivono un processo (chiamata Knowledge Base) sono: Workfow e SubFlow Domain Model (Oggetti utilizzati dai vari stati del processo) RuleFlow (Regole utilizzate all’interno degli stati del Workflow) Form per Eventuali User Task Classi Java che implementano specifici oggetti di dominio

L’orchestratore sarà dotato di un repository per la storicizzazione delle Knowledge Bases e di una applicazione Web che fornirà un’interfaccia amministrativa per permettere, in modo grafico, la definizione di Processi (Figura 12), Regole (Figura 13), Casi di Test, etc.

Pag. 18 di 59


Figura 12: Definizione di Knowledge Bases

Figura 13: Editor Regole

2.1.4.2 Configurazione Servizi Esterni

L’interazione con i servizi esterni deve essere configurata ed amministrata utilizzando i costrutti del framework Camel. In particolare l’editor permetterà la definizione di Endpoints (Figura 14) e Routes (Figura 15) e la visualizzazione dei messaggi non ancora consumati (Figura 16).

Pag. 19 di 59


Figura 14: Definizione di Endpoints Camel

Figura 15: Gestione Routes

Figura 16: Messaggi inviati sul Bus di Camel e non ancora consumati

2.1.4.3 Gestione istanze di Processo

L’effettiva esecuzione di una definizione di processo si ha nel momento in cui viene istanziato dal motore di Workflow.

I compiti del motore di WorkFlow sono:

Reperire la Knowledge Base da repository ed istanziare la definizione di processo Eseguire i Task e le regole definite nel Processo Mantenere persistenti Variabili e Stati dell’istanza di Processo Storicizzare i processi terminati.

Le funzionalità più importanti dell’interfaccia per la gestione dei Processi abbiamo:

Pag. 20 di 59


Possibilità di istanziare una definizione di processo Visualizzazione grafica (Figura 17) stato e variabili dell’istanza Gestione degli approvatori

Figura 17: Interfaccia Web JBPM per la gestione delle istanze di processo

Malgrado l’architettura “System Oriented” tenda a limitare l’interazione uomo macchina all’interno del processo, è possibile definire “User Task” da assegnare ad utenti o un sottoinsieme di esso. Questo tipo di soluzione di norma si utilizza quando:

E’ necessario definire degli approvatori per l’esecuzione di una azione

L’azione non può essere eseguita da un software. (Esempio il sistema manda una mail al gestore della risorsa “Telefoni Aziendali” chiedendo di consegnarne uno al dipendente che ne ha fatto richiesta. Una volta consegnato il gestore indicherà al sistema di aver eseguito il task)

Non è possibile (o troppo complicato) interagire con una specifica risorsa e quindi si richiede ad uno specifico utente o gruppo di utenti di farlo e segnalarne l’avvenuta esecuzione.

Pag. 21 di 59


Figura 18: Esempio di Task Assegnato all’utente

2.2 Componente Applicazione

Le applicazioni sono componenti software che realizzano un insieme di funzionalità; in sistemi distribuiti è necessario che ogni applicazione possa usufruire dei servizi messi a disposizione da altre applicazioni.

Mentre la modalità con cui una singola applicazione interagisce con un servizio è specifica della singola implementazione, l’orchestratore, nell’esecuzione dei flussi di business, comunicherà con le applicazioni realizzate utilizzando un protocollo standard di comunicazione basato su Webservice o Rest.

Figura 19: Architettura Generale - Livello Applicazioni Web

Pag. 22 di 59


In Figura 19 viene ripresa l’architettura software generale del sistema mettendo in evidenza il livello delle applicazioni web, in essa sono rappresentate alcune delle principali applicazioni previste.

2.2.1 Liferay Portal

Liferay Portal è un portale open-source nato per fornire una vista consolidata delle applicazioni più disparate all’interno di un framework integrato che costituisce appunto il portale dell’organizzazione.

Liferay Portal ha raggiunto una larghissima diffusione tra aziende e organizzazioni di tutte le dimensioni e, pur essendo distribuito secondo i dettami dell’open-source, supporta un vasto insieme di funzionalità che lo rendono assolutamente confrontabile con le soluzioni di mercato più costose.

Allo stesso tempo, una comunità di utilizzatori estremamente diffusa e attiva garantisce l’affidabilità del prodotto, nonché la sua continua evoluzione ed aggiornamento.

Liferay si è affermato negli ultimi anni come il principale Portal Server Open Source JSR 168-compliant: è conforme alla specifiche Service Oriented Architecture (SOA) per una robusta integrazione applicativa.

Le applicazioni sviluppate su Liferay beneficiano di tutte le garanzie e possibilità tipiche di un portal server enterprise: Multi-Tier, Limitless Clustering, High Avaibility, Page Caching, ecc.

Nell'architettura generale proposta Liferay Portal è un componente fondamentale e verrà preso in considerazione al momento di avviare lo sviluppo di una nuova applicazione web, allo scopo di capire se sia opportuno sviluppare l'applicazione come portlet di Liferay oppure no. In generale saranno valutate le caratteristiche funzionali dell'applicazione e se queste sono tali da beneficiare dei componenti già forniti da Liferay allora l'applicazione sarà realizzata come portlet: se ad esempio l'applicazione richiede una pesante gestione dei permessi di accesso in funzione del profilo degli utenti allora sarà opportuno appoggiarsi ai meccanismi di profilazione di Liferay e ai plugin di integrazione con ARPA già sviluppati.

2.2.2 Liferay Social Office

Liferay Social Office (LSO) è di fatto una particolare implementazione di un portale basato su Liferay Portal, caratterizzato dai seguenti aspetti predominanti:

Definizione e gestione di aree di lavoro (siti) composte da gruppi di utenti, ciascuno dei quali in possesso di determinati diritti sulle risorse gestite all’interno del sito.

Pag. 23 di 59


Redazione in forma collaborativa di documenti condivisi.

Utilizzo di tipici strumenti di community che migliorano la produttività del gruppo di lavoro fornendo informazioni utili al contesto, facilmente consultabili e continuamente aggiornabili dai membri del gruppo stesso.

Liferay Social Office offre quindi la possibilità di superare i limiti imposti dalle tradizionali comunicazioni tra utenti focalizzando l’attenzione su una metodologia collaborativa e basata sull’esperienza del lavorare in team.

2.2.3 Alfresco

Alfresco è la soluzione Open Source leader di mercato per l'Enterprise Content Management.

Il prodotto può essere utilizzato sia in ambiente MS Windows che su sistemi Unix-like. La sua architettura è progettata per garantire un’elevata modularità e scalabilità di prestazioni: include un repository documentale, un’infrastruttura di web portal, un sistema di CMS, un motore di ricerca ed indicizzazione basato su Lucene ed è integrato con il workflow jBPM.

Caratteristiche principali:

Document Management, Records Management, Web Content Management, Knowledge Management e Image Management mediante l’utilizzo dell’applicazione web Alfresco Explorer.

Strumenti per il lavoro collaborativo mediante l’applicazione web Alfresco Share

Nell’ambito dell’architettura generale descritta, si propone l’adozione di Alfresco come repository documentale (in termini archivistici, fungere archivio corrente) da di riferimento per tutti i documenti di lavoro di Regione Toscana.

Alfresco conterrà tutte le versioni ufficiali dei documenti gestiti da Regione Toscana: tra questi, anche i documenti prodotti dalle applicazioni coinvolte nei processi organizzativi.

Dal punto di vista dell’integrazione nell’architettura SOA, Alfresco potrà essere alimentato dalle applicazioni esterne attraverso l'invio di dati in formato XML, trasformati in Alfresco in documenti Word attraverso l'applicazione di file template.

Alfresco, come del resto molte altre applicazioni del genere, consente l'utilizzo di template, ovvero di documenti che possono essere applicati ad altri oggetti (altri documenti presenti nel repository) per produrre altri documenti. In questo senso i template sono i tipici file di stile che, applicati ad

Pag. 24 di 59


un documento sorgente, attraverso un algoritmo di trasformazione generano un output in un altro formato specifico. Un esempio in Alfresco sono i FreeMarker e XSLT template file.

E' quindi possibile produrre un documento a partire da una coppia di file "Template" + "Data Model", dove il data model è tipicamente un file di testo in formato HTML o XML.

Allo scopo di rendere il più semplice possibile la redazione di un template sarà consentito all'utente di progettare template in formato RTF utilizzando opportuni TAG di controllo e formattazione. L'utente potrà quindi utilizzare direttamente un file RTF (invece di un template FreeMarker) creato attraverso OpenOffice e laddove necessario potrà utilizzare la sintassi di FreeMarker per la sostituzione in fase di trasformazione dei TAG con il contenuto del file xml dei dati.

L’utente quindi non dovrà conoscere lo standard RTF ma solo la sintassi dei costrutti principali di FreeMarker per il caricamento, in fase di trasformazione, dei dati esportati dalle varie applicazioni in formato XML.

Il file RTF prodotto da OpenOffice, prima di essere reso disponibile alla trasformazione, dovrà comunque superare una fase di post-processing per la sostituzione di alcuni tag, attività che sarà automatizzata.

Il sistema Alfresco può, inoltre, essere utilizzato come repository di documenti gestiti da applicazioni (portlet) esposte nei portali di riferimento (per esempio Liferay Portal). In altre parole, utilizzando le modalità di comunicazione a servizi WS, REST o CMIS è possibile che le portlet comunichino direttamente con Alfresco, creando nuovi nodi documentali o arricchendo i metadati dei nodi documentali già presenti.

2.2.4 Integrazione Liferay Portal – Alfresco

Come abbiamo visto, Liferay Portal e relativa versione Social rappresentano lo stato dell’arte dei portali open-source ed offrono un supporto abbastanza completo della gestione documentale. D’altra parte Alfresco è l’Enterprise Content Management open-source per eccellenza, con un supporto documentale sia a livello funzionale che tecnico superiore a quanto offerto da Liferay.

In letteratura, la definizione di portale data nelle ultime specifiche Java Portlet 2.x è la seguente:“A portal is a web based application that –commonly- provides personalization, authentication, content aggregation from different sources and hosts the presentation layer of information systems. Aggregation is the action of integrating content from different sources within a web page. A portal may have sophisticated personalization features to provide customized content to users. Portal pages may have different set of portlets creating content for different users.”

Pag. 25 di 59


Mentre la definizione di ECMS è:“Enterprise Content Management is about helping us capture and manage our information better. It’s about helping us work together by providing simple tools to share what we know and what we’ve done and written and to communicate with one another. It also helps make sure that we’re in compliance with the rules that govern our organization by providing a secure central location to store electronic and paper files so we keep what we need to keep and get rid of what we don’t need to keep.”

Liferay è quindi orientato ad affrontare le problematiche tipiche degli ambienti di portale e la sua scalabilità ha sempre rappresentato il punto chiave per la scelta applicativa negli ambienti business. Le funzionalità sociali e collaborative sono da considerarsi abbastanza complete e potenti.

D’altro canto, la parte di gestione documentale, pur essendo un’ottima componente per un ambiente di portale di fascia enterprise, non può essere considerata al pari di quella di Alfresco, che invece offre un motore documentale completo, efficiente e su cui è possibile applicare personalizzazioni, estensioni funzionali, nuovi data-type e workflow dinamici. Ma, rispetto a Liferay, non è al pari nelle funzionalità collaborative e di profilazione dei ruoli/permessi sulle risorse applicative.

A livello di interfaccia web Liferay appare molto più usabile e intuitivo; inoltre è prevista e supportata la progettazione di temi grafici. Alfresco non ha la stessa libertà grafica e l’interfaccia appare pensata più per il motore documentale che per un ambito generico.

Appare quindi evidente che Liferay debba essere scelto come soluzione di portale e, nei casi in cui sia necessario avere un supporto documentale qualitativamente migliore, pensare di integrare il motore documentale di Alfresco all’interno di Liferay (successivamente verranno mostrate le modalità di integrazione), oppure sviluppare Liferay-Portlet in grado di gestire e sfruttare i servizi esposti da Alfresco tramite approccio REST o SOAP.

Pensiamo per esempio alla modellazione di permessi e ruoli, una delle componenti chiave e di maggiore utilizzo, su Liferay può essere fatto comodamente tutto tramite interfaccia web, usufruendo di una serie di meccanismi dinamici che ne permettono anche l’estendibilità. In Alfresco questo non è possibile ed è necessario andare ad agire su un opportuno file di modellazione, nel formato XML, che necessità di un certo effort per lo studio e non è alla portata dell’utente medio.

Il processo di integrazione tra Liferay ed Alfresco può essere eseguito secondo diverse modalità a seconda dei risultati che si vogliono ottenere.

Le modalità di integrazione sono essenzialmente le seguenti:

Pag. 26 di 59

Eugenio, 08/08/2011,

Citare la fonte


Integrazione attraverso Liferay CMIS, tale funzionalità è presente nelle versioni di Liferay Portal 6.x.

Installazione di Alfresco Share Portlets come applicazioni disponibili all’interno di Liferay Portal o Liferay Social Office.

Sviluppo di applicazioni/portlet ad-hoc che vadano ad invocare i servizi esposti da Alfresco ECMS per la gestione documentale in modalità web-services e/o REST.

2.2.4.1 Lifray CMIS

Liferay Portal dalla versione 6.x e successive offre una serie di servizi di interoperabilità pensati esclusivamente per l’uso con i CMS. CMIS è uno standard creato per esporre un set di servizi web al fine di condividere contenuti informativi attraverso diversi repository documentali. Lo standard è stato proposto, sulla base delle specifiche JSR-170, e creato da un consorzio formato da Alfresco, Day Software, Dennis Hamilton, EMC, IBM, Microsoft, Open Text, Oracle e SAP.Liferay può quindi essere configurato in modo da sfruttare la componente CMIS per l’integrazione con Alfresco. Il processo di configurazione è molto semplice e prevede la valorizzazione di alcune proprietà applicative, in modo da configurare e pilotare il repository documentale utilizzato dalla portlet Document Library di Liferay.

La Document Library andrà quindi ad effettuare operazioni di gestione dei documenti invocando i servizi CMIS esposti da Alfresco; la portlet lavora su uno specifico nodo configurabile, per esempio “Liferay Home”, del repository documentale di Alfresco, e dove verranno create alberature con nomenclature e struttura tipiche della gestione documentale di Liferay, vedi Figura 20.

Pag. 27 di 59

Eugenio, 03/08/2011,

Domanda che nasce dalla mia ignoranza: web services o WebScript? O entrambi?


Figura 20: Repository Alfresco - Struttura Document Libray Liferay

E’ quindi pensabile di utilizzare, nel processo documentale, la portlet di Document Library di Liferay per la gestione di uno specifico workflow di lavoro, ma andando a memorizzare i documenti nel repository di Alfresco, di modo che su questi possano essere applicate eventuali regole del motore di Alfresco, definite sullo specifico repository.

Nel caso sia necessario arricchire le informazioni standard documentali (e quindi i metadati) gestite tramite Liferay è possibile utilizzare il meccanismo dei “Custom Fields”, previsto dalle versioni di Liferay 6.x.

Tali Custom Fields possono essere di varie tipologie: Stringa Numerici Testuali Data Enumerazione di valori

Per esempio, se si volesse esprimere il fatto che un documento possa essere firmato digitalmente, si dovrà creare il metadato “Firma Digitale”, di tipo booleano, e la form standard prevista da Liferay per l’inserimento di un nuovo documento verrà mostrata come in Figura 21.E’ possibile, inoltre, profilare ogni custom field introdotto in modo che possa essere visualizzato solo da utenti con un certo ruolo.

Pag. 28 di 59


Figura 21: Form per inserimento documentale in Liferay

2.2.4.2 Alfresco Share Portlet

Nella distribuzione di Alfresco 3.4.d viene fornita una suite di portlet JSR-168 standard certificate per l’esecuzione in ambiente Liferay Portal. Queste portlet possono essere facilmente installate come applicazioni aggiuntive di portale e offrono meccanismi di autenticazione SSO verso Alfresco Repository, permettendo di sfruttare direttamente tutte le funzionalità di gestione documentale normalmente disponibili attraverso l’applicazione Alfresco Share.

Attraverso l’Alfresco Document Library portlet è possibile usufruire di tutte le funzionalità di Alfresco Share Document Library compreso:

Creazione di cartelle documentali Upload e download documentale Controllo di versione Commenti e tagging

Pag. 29 di 59


Accesso e modifica dei metadati associati ai nodi documentali L’avvio di specifici workflow Navigazione ad albero del repository documentale Preview dei documenti direttamente nel portale Liferay

La configurazione dei meccanismi di SSO, per l’accesso diretto da Liferay al repository di Alfresco attraverso le credenziali dell’utente loggato in Liferay, è descritta in modo chiaro nelle guide di Alfresco, e non presenta particolari problematiche applicative.

La configurazione dei meccanismi di SSO, per l’accesso diretto da Liferay al repository di Alfresco attraverso le credenziali dell’utente loggato in Liferay, è descritta in modo chiaro nelle guide di Alfresco, e non presenta particolari problematiche applicative.

Figura 22: Liferay-Alfresco SSO

L’esecuzione delle portlet nelle pagine di Liferay Portal appare priva di anomalie e l’interfaccia delle portlet è disegnata in modo chiaro e pulito.

Pag. 30 di 59


Figura 23: Alfresco Document Library Portlet Repository

Nella figura successiva viene mostrato come dall’integrazione offerta dalle Share Portlets sia possibile gestire gli aspetti, i metadati e i permessi di un particolare nodo del repository di Alfresco.

Figura 24: Afresco Share Portlet - gestione metadati

Pag. 31 di 59


Figura 25: Gestione permessi nodi Alfresco da Liferay

Figura 26: Gestione aspetti nodi Alfresco da Liferay

Per ogni documento caricato nel repository documentale Alfresco, se l’utente ha i diritti di accedere alla risorsa documentale, sarà possibile attraverso Liferay SSO e la portlet Alfresco Document Library modificare dettagliatamente il contenuto del nodo documentale, vedi Figura 27.

Pag. 32 di 59


Figura 27: Modifica nodo documentale Alfresco attraverso Liferay

Il processo di gestione documentale attraverso questa modalità di integrazione può essere riassunto in questo schema funzionale.

Pag. 33 di 59

Figura 28: Schema funzionale integrazione Alfresco Share Portlets

Repository Documentale

Liferay

Alfresco Share Portlets

Alfresco

ServerRESTful


2.2.4.3

2.2.4.4 Considerazioni

Date queste modalità di integrazione, gli scenari applicativi che si possono modellare sono molteplici e si possono basare su entrambe le integrazioni presentate nei paragrafi precedenti.Supponiamo, infatti, di voler utilizzare Liferay Portal per la gestione di un sotto-flusso di lavoro documentale. Bene, attraverso l’integrazione CMIS possiamo, pur rimanendo nella gestione documentale Liferay, inserire i contenuti nel motore di Alfresco. Dall’altra parte, se si ha la necessità di arricchire i contenuti inseriti tramite la Document Library di Liferay con ulteriori metadati, sarà possibile utilizzare Alfresco Navigator oppure regole automatiche o flussi di lavoro definiti in Alfresco. In sostanza, in questo caso, i due prodotti sono entità completamente distinte; integrazione così detta “debole”.

Altro scenario, potrebbe essere quello in cui viene utilizzata esclusivamente la modalità Share Portlets. Quindi, in Liferay non vengono di fatto memorizzate informazioni dei contenuti documentali, ma gestite attraverso le funzionalità esposte dalle Afresco Share Portlets, agendo direttamente, attraverso i servizi RESTful esposti da Alfresco, sul repository documentale. Ovviamente, grazie ai meccanismi di SSO che di fatto rendono possibile l’interoperabilità dell’utente tra Liferay e Alfresco, sarà possibile utilizzare il sistema rouli/permessi di entrambi i prodotti. Questo scenario rappresenta il caso di integrazione “forte”.

2.2.5 Modellazione sistema a cartelle documentali condivise

In questo paragrafo, analizziamo una proposta completa per l’implementazione di un flusso di lavoro documentale in Regione Toscana, utilizzando combinazioni di sistemi Liferay e Alfresco, che permetta di realizzare un sistema a cartelle documentali condivise. A seconda dell’infrastruttura tecnologica disponibile, è possibile utilizzare alcuni approcci, tra loro completamente disgiunti.

2.2.5.1 Cartelle documentali condivise sistema Liferay + Alfresco

Attraverso l’integrazione basata su protocollo CMIS possiamo, pur rimanendo nella gestione documentale Liferay, inserire i contenuti nel sistema documentale di Alfresco. Dall’altra parte, se si ha la necessità di arricchire i contenuti inseriti tramite la Document Library di Liferay con ulteriori metadati, sarà possibile utilizzare Alfresco Navigator oppure regole automatiche o flussi di lavoro definiti in Alfresco. In sostanza, i due prodotti sono entità completamente distinte.

Ricreando opportunamente l’albero dell’organigramma di Regione Toscana attraverso l’uso delle Organizzazioni di Lifeary sarà possibile profilare istanze di portlet Document Library in modo che solo gli utenti appartenenti ad una certa organizzazione possano andare in lettura e modifica dei contenuti documentali memorizzati in una certa cartella documentale.

Pag. 34 di 59


Per esempio, un frammento di organigramma del tipo:

Figura 29: Frammento di Organigramma di RT

In Figura 1, mostriamo la funzionalità di Liferay per la creazione delle organizzazioni.

Si può modellare nel seguente modo:1) Creazione Organizzazione Radice “Direzione Generale – Organizzazione e Risorse”

Pag. 35 di 59

Direzione GeneraleOrganizzazione e Risorse

ACOOrganizzazione Personale

Sistemi informativi

ACORisorse Finanziarie

SettoreInfrastrutture e Tecnologie

SettoreSistemi Informativi e Servizi


Figura 30: Liferay Organizzazioni Inserimento

2) Creazione Sotto-Organizzazioni figlie: “Organizzazione Personale Sistemi Informativi” e “Risorse Finanziarie”

3) Creazione Organizzazioni “Infrastrutture e Tecnologie” e “Sistemi Informativi e Servizi” figlie delle organizzazioni create al punto 2)

Pag. 36 di 59


L’alberatura appena creata verrà mostrata da Liferay nel seguente modo:

Figura 31: Frammento Organigramma RT in Liferay

Per ogni organizzazione creata è possibile utilizzare l’azione di aggiunta utente per definire quali utenti appartengono ad una certa organizzazione. Dopo aver profilato l’appartenenza degli utenti alle organizzazioni, è necessario creare una pagina di portale all’interno dell’organizzazione per poter inserire l’istanza della document library relativa all’organizzazione.

Figura 32: Document Library dell’organizzazione

Solo gli utenti appartenenti alla data organizzazione potranno condividere documenti all’interno della document library.

Pag. 37 di 59


Data la struttura modellata utilizzando le organizzazioni, non è possibile permettere all’utente che appartiene al settore “Infrastrutture e Tecnologie” l’accesso ai documenti appartenenti al settore “Sistemi Informativi e Servizi”. In altre parole, in termini di Liferay, la visibilità documentale tra organizzazione disgiunte non è permessa.

Ulteriori politiche di permessi a “grana fine” possono essere in ogni caso date sulla singola folder documentale, per far in modo che alcuni membri dell’organizzazione possano solo leggere i documenti ed altri solo modificarli, utilizzando la funzionalità “Team” di Liferay che permette di creare dei gruppi di lavoro per la specifica organizzazione.

Figura 33: Azioni sull’Organizzazione

A livello di Alfresco questo è trasparente ed indipendente; sarà completamente compito della componente Liferay occuparsi di gestire la profilazione degli utenti, utilizzando Alfresco solamente come repository. Ovviamente in Alfresco dovrà essere creato un utente, per esempio liferay, con diritti di lettura e scrittura nell’alberatura che ospiterà i nodi documentali gestiti dalla Document Library di Liferay.

Pag. 38 di 59


A livello di Liferay dovrà essere configurato l’aggancio CMIS tra Liferay ed Alfresco. Tale aggancio prevede la semplice valorizzazione di alcune proprietà contenute nel file di configurazione che viene analizzato da Liferay in fase di avvio:

cmis.credentials.username=liferaycmis.credentials.password=passwordcmis.repository.url=http://localhost:8080/alfresco/service/api/cmiscmis.repository.version=1.0cmis.system.root.dir=Liferay Homedl.hook.impl=com.liferay.documentlibrary.util.CMISHook

Vantaggi Svantaggi1) Utilizzo sistema di profilazione risorse e

ruoli di Liferay.2) Facilità di integrazione.3) Richiesto livello di competenze

sistemistiche basso.4) Nessuna modifica applicativa né a Liferay

né ad Alfresco.

1) Necessaria pre-strutturazione delle organizzazioni, assegnamento e profilazione utenti.

2) Alfresco viene usato solo come repository documentale.

3) La gestione documentale segue le regole imposte dalla portlet Document Library di Liferay.

4) Training per formazione avanzata sull’uso del portale Liferay.

Tabella 3: Vantaggi – Svantaggi soluzione Liferay+Alfresco

2.2.5.2 Cartelle documentali condivise sistema CIFS + Alfresco

Nel caso in cui, nell’architettura di Regione Toscana, fosse disponibile un sistema di profilazione basato su permessi ad approccio file system, quindi con riferimento al protocollo CIFS, sarebbe possibile agganciare direttamente Alfresco, agendo su opportuni file di configurazione del prodotto.Utilizzando questo approccio, il generico dipendente di Regione Toscana avrebbe la possibilità di memorizzare e gestire i contenuti memorizzati fisicamente in Alfresco, allo stesso modo delle cartelle condivise gestite da sistema operativo, visualizzate attraverso l’icona standard dell’unità di rete. Si andrebbe, quindi, ad evitare l’utilizzo diretto da parte dell’utente dell’interfaccia applicativa di Alfresco.L’approccio non esclude, ovviamente, l’utilizzo dell’interfaccia applicativa di Alfresco per la gestione avanzata dei nodi documentali da parte di un amministratore di sistema, per rispondere a particolari esigenze o applicare logiche particolari.

Il sistema così configurato, rispetto allo scenario modellato nel paragrafo 2.2.5.1, avrebbe il vantaggio di una notevole minor complessità di messa in esercizio. Infatti, si andrebbero ad evitare gli sforzi spesi sia per la puntuale e avanzata profilazione degli utenti all’interno delle

Pag. 39 di 59


organizzazioni create nel portale Liferay, sia la fase di training necessaria ai dipendenti di Regione Toscana al fine di utilizzare correttamente gli strumenti messi a disposizione dal portale Liferay.

Vantaggi Svantaggi1) Nessun training necessario.2) Utilizzo trasparente di Alfresco.3) Integrazione diretta con la postazione di

lavoro dell’utente finale.4) Nessuna pre-strutturazione delle folder

documentali.

1) Richiesto livello di competenze sistemistiche alto per configurazione Alfresco.

Tabella 4: Vantaggi – Svantaggi soluzione CIFS+Alfresco

2.2.5.3 Cartelle documentali condivise sistema Alfresco

E’ possibile modellare lo scenario utilizzando direttamente Alfresco e il suo modello rigido di profilazione degli utenti sulle cartelle documentali.

Il modello dei permessi di Alfresco permette di poter agire sulle cartelle documentali create da altri e sui contenuti memorizzati a seconda di alcune modalità pre-definite:

Consumer: accesso in sola lettura. Editor: accesso in sola lettura e modifica. Contributor: accesso in lettura/modifica sui nodi documentali creati da altri, accesso

completo sui nodi documentali propri. Collaborator: accesso completo alla cartella documentale ma senza la possibilità di

permettere ad altri utenti l’accesso alla cartella documentale. Coordinator: amministratore della cartella documentale.

In Alfresco, quindi sarà necessaria una fase di importazione degli utenti dipendenti di Regione Toscana, per poter permettere l’accesso al sistema documentale, e la successiva creazione di gruppi, sotto-gruppi e assegnazione degli utenti, al fine di ricreare l’organigramma di Regione Toscana.

Pag. 40 di 59


Figura 34: Frammento Organigramma RT in Alfresco

A questo punto, si devono creare le folder documentali che conterranno i documenti dei vari livelli organizzativi nel repository documentale.

Figura 35: Creazione folder documentale

E puntualmente, per ogni folder, si devono andare a profilare i gruppi o i singoli utenti in modo da applicare la profilazione permessa dal modello di Alfresco.

Figura 36: Impostazione dei permessi sulla folder documentale

Pag. 41 di 59


In Figura 36 mostriamo un esempio di assegnazione dei permessi per la cartella “Direzione Generale”, al gruppo “Direzione Generale”. Al gruppo possono essere assegnate le modalità di accesso alla folder documentale visualizzate nel menù a tendina “Ruolo” e già descritte.Quindi tutti gli utenti al tale gruppo avranno accesso alla folder documentale in base al ruolo selezionato per il gruppo. Non è possibile in Alfresco discriminare che un utente particolare appartenente al dato gruppo abbia un ruolo diverso sulla data cartella documentale, perché tutti gli utenti ereditano i ruoli dati al gruppo di appartenenza e questa relazione di ereditarietà ha precedenza sul ruolo impostato sul singolo utente.

Inoltre è importante sottolineare che tutti i sotto-gruppi dell’alberatura la cui radice è “Direzione Generale” hanno accesso alla relativa folder documentale con lo stesso ruolo impostato per il gruppo “Direzione Generale”.

Per quanto riguarda gruppi disgiunti, l’utente che appartiene al gruppo “Sistemi Informativi e Servizi” non avrà accesso diretto alla folder documentale del gruppo “Infrastrutture e Tecnologie”. Nel caso si voglia dare l’accesso alla folder documentale, sarà sufficiente selezionare il gruppo Sistemi Informativi e Servizi” ed il ruolo desiderato per la folder documentale del gruppo “Infrastrutture e Tecnologie”.

Figura 37: Gestione permessi folder documentali per gruppi disgiunti

Ovviamente questo approccio prevede che vengano spese forze per effettuare sessioni di traning all’utilizzo del sistema Alfresco da parte dei dipendenti di Regione Toscana e di quelli che si dovranno occupare della corretta profilazione dei gruppi e delle cartelle documentali. Inoltre, rispetto all’utilizzo del sistema Liferay+Alfresco si va a perdere quella libertà di profilazione a grana fine dei permessi sulle singole risorse documentali.

Pag. 42 di 59


Vantaggi Svantaggi1) Utilizzo completo delle funzionalità

documentali offerte da Alfresco.2) Nessuna integrazione con Liferay

necessaria.3) Nessuna competenza avanzata sistemistica

richiesta.

1) Rigidità e limitazioni del modello dei permessi di Alfresco.

2) Necessaria pre-strutturazione delle folder documentali.

3) Training avanzato sull’uso del sistema Alfresco.

Tabella 5: Vantaggi – Svantaggi soluzione Alfresco

2.2.5.4 Cartelle documentali condivise sistema Organo + Alfresco

In Regione Toscana sarà reso disponibile il sistema Organo, che tra le varie funzionalità permette l’interrogazione tramite invocazioni web-services al fine di recuperare informazioni di rilevo sull’organigramma strutturale di Regione Toscana.

E’ percorribile, quindi, lo scenario in cui in fase di autenticazione al sistema Alfresco tramite SSO ARPA, vengano effettuati dei controlli per capire a quali strutture l’utente che si sta autenticando appartiene e quindi applicare le opportune politiche di gestione dei permessi sulla folder documentale legata alla propria struttura di appartenenza, oppure (pensando al caso del direttore generale) sulle folder legate ad altre strutture.Secondo questa modalità di realizzazione, deve essere prevista una fase iniziale di creazione massiva delle folder documentali relative alle varie strutture e la profilazione degli utenti su tali folder documentali dovrà essere implementata per via applicativa al momento dell’autenticazione ad Alfresco, tramite l’interazione con il sistema Organo.

In questo scenario, agli utenti dipendenti di Regione Toscana dovrà essere erogata una fase iniziale di traning all’uso di Alfresco per quanto riguarda la sola gestione documentale, omettendo del tutto la gestione dei permessi (realizzata in automatico dal sistema stesso).

Pag. 43 di 59


Vantaggi Svantaggi1) Profilazione automatica eseguita dal

sistema sulle cartelle documentali.2) Autenticazione al sistema Alfresco tramite

SSO ARPA.3) Nessuna integrazione con Liferay

necessaria.

1) Necessario sviluppo applicativo ad-hoc.2) Necessaria pre-strutturazione delle folder

documentali.3) Necessario traning base sull’utilizzo di

Alfresco.4) Rigidità e limitazioni del modello dei permessi

di Alfresco.Tabella 6: Vantaggi – Svantaggi soluzione Organo+Alfresco

2.2.6 Sistema Trasversale di Firma

Un altro componente fondamentale dell'architettura generale è il Sistema Trasversale di Firma attraverso il quale sarà possibile firmare digitalmente tutti i documenti per i quali ne sia prevista la necessità nell'ambito dei processi organizzativi di Regione Toscana. Il Sistema Trasversale di Firma si integrerà con l'architettura generale del sistema attraverso l'utilizzo dei web service disponibili.

2.2.7 Protocollo Informatico

Un altro componente cardine dell'architettura generale è il software di Protocollo attraverso il quale avvengono tutte le comunicazioni, in ingresso e in uscita, con i soggetti esterni a Regione Toscana.

Il Sistema di Protocollo Informatico mette attualmente a disposizione uno strato di backend interrogabile attraverso web service e quindi nativamente integrabile nell'architettura SOA proposta.

2.2.8 Architettura nuove applicazioni

Le nuove applicazioni saranno progettate utilizzando una strutturazione su più livelli (multitier) per consentire, come è ormai noto, il disaccoppiamento delle funzionalità rendendo più celere l'implementazione e la ricerca degli errori; la modifica di un livello non influenzerà assolutamente i livelli intermedi, con un evidente vantaggio rispetto alle applicazioni su un solo livello logico.

Pag. 44 di 59


Figura 38: Architettura di dettaglio Componente Applicazione

I livelli dell’architettura saranno così articolati:

Persistent Layer

Business Layer

Presentation Layer

Integration Layer

Il livello di persistenza (Persistent Layer) rappresenta in maniera definitiva il modo in cui i dati vengono memorizzati su un supporto fisico persistente. Non importa se la memorizzazione avviene su un database, sul file system o seguendo altre logiche. L'importante sarà predisporre delle funzioni standard utilizzabili dal livello di business. Si tratterà di operazioni di lettura o scrittura precedute (eventualmente) da una forma di autenticazione.

Pag. 45 di 59


Il livello Business (Business Layer) è quello che realmente determina la potenzialità del sistema. In esso è predisposta la logica applicativa affinché determinate funzioni vengano portate a compimento. Il suo utilizzo avviene dal livello di presentazione, al quale deve restituire delle informazioni consone alla particolare funzione richiesta. In alcuni casi, la logica applicativa funziona da sé, in altri (più spesso), ha necessità di utilizzare dei dati presenti in un database recuperandoli dal livello sottostante, quello di persistenza. La progettazione di questo livello è quella probabilmente più importante, nel senso che essa rappresenta in maniera definitiva le funzioni del sistema web, e quindi il loro utilizzo dall'utente finale. La modifica di questo livello non determina cambiamenti nei livelli adiacenti.

Le funzionalità che il livello presentazione (Presentation Layer) deve offrire sono molto vicine al classico HTML. Infatti, la sua funzione è quella di predisporre la corretta visualizzazione delle pagine web, in base a ciò che è espresso nel livello funzionale, quello che elabora i contenuti dinamici da presentare all'utente finale. La progettazione di questo livello dipende dalle funzioni che devono essere implementate dal sistema web. Il fatto di essere indipendente dal resto del sistema consente una sua progettazione che tenga conto di elementi propri di questo contesto, che sono di natura prettamente grafica e di design. Sarà altresì semplice modificare l'interfaccia grafica, in quanto, tale modifica non influenzerà il funzionamento della logica applicativa sottostante, né tantomeno, quella di persistenza.

Nel caso in cui l’applicazione abbia la necessità di esporre alcuni servizi nei confronti di componenti esterni (anche l’orchestratore) è necessario realizzare e configurare un livello di integrazione (Integration Layer).

Per esporre un servizio verso l’esterno è necessario:

Definire con quale protocollo di trasporto vengono esposti i servizi

Definire il sottoinsieme di servizi da esporre

Dove necessario implementare dei Wrapper per mappare i messaggi ricevuti dai servizi esterni in invocazioni verso il Business Layer

Stabilire (se richiesto) i metodi che permettano di verificare che il componente esterno abbia i diritti per eseguire l’operazione.

Se l’applicazione dovesse essere integrata all’interno del sistema di orchestrazione dovrà esporre un servizio standard (vedi Figura 9) per permettere la comunicazione bidirezionale con l’istanza di processo appropriata. Per evitare che componenti terzi possano invocare i servizi standard esposti per l’orchestratore, saranno implementati dei moduli pluggabili come filtri web o SoapHandler Jaxws che vadano a verificare che il chiamante sia abilitato ad effettuare la chiamata.

Pag. 46 di 59


Figura 39: Invocazione Servizio Orchestrato Sincrono

sd Invocazione Serv izio Orchestrato Asincro...

ApplicazioneOrchestratore

WorkflowHandler EIS SecurityInterceptor ApplicazioneSecurityInvocationService

callRemoteService()

signalInitCall()

callRemoteService()

isCallTrusted()

result()

doCallService()

signalEvent(InstanceId)

signalEvent(InstanceId)

Figura 40: Invocazione Servizio Orchestrato Asincrono

Inoltre, per permettere a sistemi di monitoraggio di verificare il corretto funzionamento degli applicativi, verrà esposto un servizio basato su jmx.

L’architettura mostrata in Figura 38 mostra tutti i componenti software che entrano oppure possono entrare in gioco nella realizzazione di applicazione SOA e Web Based. Esistono diversi

Pag. 47 di 59


Framework che già realizzano parte dei componenti elencati oppure offrono delle facility per implementarne altri; tra questi segnaliamo Spring.

2.2.8.1 Persistent Layer

Spring permette di interagire in modo semplice e sicuro con tecnologie di persistenza come JDBC, JPA, Hibernate, JDO, LDAP mettendo a disposizione classi, annotazioni e configurazioni Xml.

A questo livello, oltre a trarre i vantaggi derivanti dall’uso del pattern “Inversion of Control” il sistema prevede una gestione unificata dei messaggi di errore e delle transazioni indipendenti da tipologia di database utilizzato ed eventuale sistema di persistenza. Sono inoltre disponibili una serie di CallBack che si occupano di aprire e chiudere connessioni o sessioni persistenti in modo del tutto trasparente allo sviluppatore.

Per avere tutto ciò basta utilizzare l’annotazione @Repository:

@Repositorypublic class AccountRepositoryImpl implements AccountRepository {

// class body here...

}

Esempio di Model:

public class Account {

@NotNull@Size(min=1, max=25)private String name;

@DateTimeFormat(style="S-")@Futureprivate Date renewalDate = new Date(new Date().getTime() + 31536000000L);

// getters and setters here...

}

2.2.8.2 Business Layer

Anche nella gestione del livello di Business Spring può essere d’aiuto.

Gli esempi che seguono dimostrano che in architetture non particolarmente complicate non è necessario utilizzare modelli di business diversi da quelli utilizzati per la persistenza. Tutto a vantaggio della semplicità implementativa. Il modulo Spring security permette la verifica dei grant

Pag. 48 di 59


sui model object (ad esempio permessi di creazione, modifica, eliminazione di un account) in modo centralizzato e architetturalmente molto elegante.

@Servicepublic class AccountServiceImpl implements AccountService {

@Autowired private accountRepository accountRepository; @Transactional(readOnly = true) public Account getById(long id) { return this.accountRepository.getById(id); } @Transactional public Account create(Account account) {

//Eventuali altre invocazioni altri repository o controllo accessi return this.accountRepository.create(account); }}

In caso di applicazioni semplici dove viene utilizzato un solo tipo di repository come Jpa è possibile integrare il Business Layer con il Persistent Layer come in questo caso:

@Servicepublic class JpaAccountService implements AccountService {

@PersistenceContext private EntityManager entityManager;

@Transactional(readOnly = true) public Account getById(long id) { return this.entityManager.find(Account.class, id); }

@Transactional public Account create (Account account) { this.entityManager.persist(account); return account; }}

2.2.8.3 Presentation Layer e Integration Layer

Il livello di presentazione e di integrazione SOA permettono entrambi l’interazione con componenti esterne.

Per quanto riguarda l’integrazione sono disponibili una moltitudine di possibiità che permettono di esportare servizi anche senza scrivere righe di codice.

Pag. 49 di 59

Esempio esportazione Rmi:

<bean class="org.springframework.remoting.rmi.RmiServiceExporter">  <property name="serviceName" value="AccountService"/> <property name="service" ref="accountService"/> <property name="serviceInterface" value="it.toscana.regione.service.AccountService"/>  <property name="registryPort" value="1199"/></bean>

Esempio esportazione http:

<bean name="/AccountServiceHttp" class="org.springframework.remoting.caucho.HessianServiceExporter"> <property name="service" ref="accountService"/> <property name="serviceInterface" value="it.toscana.regione.service.AccountService"/></bean>

Esportazione WebService:

<simple:server id="accountServiceWsdl" serviceClass="it.toscana.regione.service.AccountService" address="/accountService"> <simple:serviceBean> <bean ref="accountService" /> </simple:serviceBean> </simple:server>

Esempio webservice con annotazioni:

@WebService(serviceName="AccountService")public class AccountServiceEndPoint implements AccountService {

@Autowired private AccountService accountService; @WebMethod public Account getById(long id) { return this.accountService.getById(id); } @WebMethod public Account create(Account account) {

return this.accountService.create(account); }}

Oltre a supportare diversi framework MVC per lo sviluppo di applicazioni Web come Struts, JSF, WebWork, Spring è anche una implementazione completa dell’MVC sia per servlet che per portlet.

Il framework è fortemente configurabile attraverso interfacce e può utilizzare numerose tecnologie di view comprese JSP, Velocity, Tiles, iText, Ajax, ecc.

Pag. 50 di 59


@Controller@RequestMapping(value="/account")public class AccountController { @Autowired

private AccountService accountService;

@RequestMapping(method=RequestMethod.GET)public String getCreateForm(Model model) {

model.addAttribute(new Account());return "account/createForm";

}

@RequestMapping(method=RequestMethod.POST)public String create(@Valid Account account, BindingResult result) {

if (result.hasErrors()) {return "account/createForm";

}accountService.create(account);return "redirect:/account/" + account.getId();

}

@RequestMapping(value="{id}", method=RequestMethod.GET)public String getView(@PathVariable Long id, Model model) {

Account account = accountService.getById(id);if (account == null) {

throw new ResourceNotFoundException(id);}model.addAttribute(account);return "account/view";

}

}

Pag. 51 di 59


2.2.9 Sicurezza

Le applicazioni devono essere progettate in modo da garantire, ai diversi attori (persone fisiche, agenti informatici), l’accesso alle sole informazioni per le quali hanno diritto. In generale l’attore di una applicazione è un soggetto che ha assegnati uno o più casi d’uso. Le modalità di accesso ed autenticazione possono essere diverse da soggetto a soggetto.

Le applicazioni devono garantire più livelli di controllo nel seguente ordine:

Controllo degli Accessi Controllo sugli Oggetti di Dominio

2.2.9.1 Controllo degli Accessi

L’applicazione deve avere gli strumenti per capire quando un soggetto è attore dell’applicazione.

Per attori che accedono via browser il controllo degli accessi viene effettuato dal sistema Arpa che viene installato come filtro dell’applicazione. Per applicazioni Portlet la verifica viene effettuata dal portale che a sua volta utilizza Arpa.

La sicurezza delle comunicazioni tra Orchestratore ed Applicazione è garantita dall’utilizzo del componente SecurityInvocationService e dal Security Interceptor (vedi Figura 39 e Figura 40) posto a protezione del servizio standard (vedi Figura 9) esposto dall’applicazione.

2.2.9.2 Controllo sugli Oggetti di Dominio

Il controllo degli Oggetti di Dominio viene eseguito dopo che il soggetto è stato riconosciuto come attore dell’applicazione e serve per garantire l’accesso alle sole informazioni sulle quali ha un qualche diritto.

Il sistema di controllo si basa sul modello RBAC (Role-based access control) che permette l’associazione della coppia Ruolo-Permesso (grant) al singolo Oggetto di Dominio. Un attore ha il permesso di eseguire l’operazione su un determinato oggetto solo se tra i ruoli a lui assegnati ne esiste almeno uno che soddisfi tale associazione.

Per applicazione realizzate come Portlet di Liferay è disponibile un componente del portale che permette la definizione e la verifica dei grant su oggetti di Dominio definiti all’interno del contesto della portlet.

Pag. 52 di 59


Per applicazioni che non utilizzano Liferay è disponibile il modulo di spring security che permette di proteggere invocazioni ai servizi di Business semplicemente annotando il metodo. Di seguito è mostrato un esempio di servizio di utilizza le annotazioni di spring security.

@Servicepublic class JpaAccountService implements AccountService {

@PersistenceContext private EntityManager entityManager;

@PostFilter("hasPermission(filterObject, 'read') or hasPermission(filterObject, 'admin')")

@Transactional(readOnly = true) public Account getById(long id) { return this.entityManager.find(Account.class, id); } @PreAuthorize("hasRole('ROLE_USER')") @Transactional public Account create (Account account) { this.entityManager.persist(account); return account; }

}

2.2.10 Help contestuale

Da sempre l’esecuzione di applicazioni web, che siano basate sulla semplice compilazione di form o su azioni più complesse, è un'operazione potenzialmente perniciosa e dall'incerto risultato per la media degli utenti non sufficientemente smaliziati. Molte considerazioni in tema di accessibilità sono state espresse a riguardo, analizzando il problema sotto differenti aspetti e ricavandone indicazioni differenti: utilizzo di termini convenzionali, posizionamento omogeneo dei vari oggetti, ricorso ad elementi grafici oggettivamente significativi. Documentare in maniera adeguata l’applicazione può contribuire ad abbassare il senso di difficoltà provato dall'utente, fornendo informazioni specifiche, prestando però attenzione a non appesantire eccessivamente la pagina a livello di impatto visivo.

Con "help contestuale" si intende la capacità di trasmettere istruzioni direttamente legate alla pagina in cui l’utente ha richiesto aiuto cliccando su un link o su un’icona oppure passando il mouse sopra una certa porzione della pagina.

Utilizzando il meccanismo dei “tooltip” e sfruttando le potenzialità del modello di collaborazione Wiki è possibile realizzare un sistema di help contestuale che soccorra l'utente, il tutto rispettando appieno i principi fondamentali di accessibilità e implementando codice non intrusivo, al fine di rispettare la separazione che deve verificarsi tra struttura e comportamento del documento.

Pag. 53 di 59


Liferay Portal Server implementa un sistema di wiki robusto e potente, comparabile a prodotti standalone. Ogni gruppo può condividere una propria Wiki con propri e differenziati insiemi di autorizzazioni. Ogni utente con i diritti necessari può contribuire alla crescita del repository di conoscenza condiviso. I contenuti vengoni inseriti semplicemente con un editor WISWYG, le pagine possono essere raggruppate in gerarchie e taggate con sistemi a vocabolario multiplo (taxonomy e/o folksonomy).

La “Wiki Portlet” risulta quindi appropriata per gestire contenuti di interesse specifici per l’applicazione. La progettazione del’help sarà basata sulla scelta da una lista di Page Template configurati precedentemente; la pagina sarà quindi costruita automaticamente utilizzando il layout e le portlet configurate nel template. La figura seguente mostra l’interfaccia di creazione di un nuovo Page Template per il Wiki.

Figura 41: Creazione template per help on-line

Selezionando il link “Open Page Template” è possibile accedere alla sezione di configurazione del template in cui si hanno a disposizione le funzionalità tipiche di Liferay per il design di una pagina, ovvero la gestione del layout, l’aggiunta di portlet, ecc.Nella figura seguente è riportato un esempio di Page Template per la costruzione di una pagina tipica di Wiki.

Pag. 54 di 59


Figura 42: Configurazione template per help on-line

2.2.11 Reportistica

L’integrazione di funzionalità di reportistica all’interno delle applicazioni può arricchire l’applicazione in modo sostanziale, fornendo le informazioni di analisi e di sintesi necessarie per la efficace gestione di una attività. La produzione di report professionali non può però essere demandata allo sviluppo di software scritto “in casa”, ma deve basarsi su soluzioni stabili e flessibili in grado di offrire tutte le funzionalità che possono di volta in volta rendersi necessarie.

La scelta di standard “de facto” da adottare nell’ambito che ci riguarda si basa sulla individuazione di tre livelli distinti di reportistica a cui si associano applicazioni diverse, utilizzate a seconda del tipo di risultato desiderato. In particolare:

Per la generazione di semplici report tabellari in formato Excel, CSV o PDF si utilizza “DisplayTag” che permette di mostrare i dati di un elenco distribuiti su più pagine: dato un elenco di oggetti gestisce la visualizzazione delle colonne, l’ordinamento, la paginazione, il raggruppamento e la decorazione di una tabella in stile XHTML personalizzabile.

Per report complessi che implicano la generazione dinamica di report a partire da dati recuperati da fonti di varia natura (per esempio database) e la loro visualizzazione, stampa o salvataggio su file di tipo PDF, HTML, XLS, CSV o XML si utilizza “JasperReports” che prevede la realizzazione di tutte le funzionalità tipiche di un software di reportistica:

formattazione di ogni elemento di un testo (font, allineamento, spaziatura, colore, etc.)

definizione di parti standard predefinite (header, footer, sommario, etc.) gestione di raggruppamenti valutazione di espressioni campi calcolati gestione di subreport

Pag. 55 di 59

Alessandro Mensini, 01/06/2011,

Da valutare l’utilizzo di FreeMarker


inserimento di immagini stampa salvataggio dell'output su file di diverso formato

Per report che coinvolgono Alfresco e implicano la trasformazione di file XML in documenti HTML, RTF o PDF si utilizza “FreeMarker” che può essere usato per generare qualunque genere di testo: HTML, XML, RTF, ecc.

2.2.12 Gestione dei log

L'attività di logging consiste nel registrare automaticamente eventi che vengono generati da un’applicazione in modo da fornire una traccia che permetta di ricostruire e diagnosticare eventuali problemi. In questo contesto ci interessa sottolineare l’esigenza di stabilire uno standard che venga seguito dalle applicazioni in modo da permettere una generazione omogenea dei dati che possono quindi essere utilizzati agevolmente con lo stesso software di notifica e monitoraggio dei log.

Premesso che la soluzione tecnica da adottare è da scegliere fra Log4j e il package java.util.logging (eventualmente astratti da SLF), una prima lista delle informazioni che possono comporre le voci di un log è la seguente:

l’indicatore di data e ora il sistema di origine l’applicazione che ha generato il log il testo che descrive l’evento altri parametri caratteristici dell’applicazione

Di particolare rilevanza potrebbe essere la raccolta di un’ampia gamma di eventi di sicurezza che possono includere tentativi di accesso con account errati, accessi negati a file, database e programmi oltre che voci generate dagli utenti.

2.2.12.1 Log Management per gli Amministratori di Sistema

Il Garante per la protezione dei dati personali ha stabilito che tutte le aziende - private e pubbliche - dovranno registrare e conservare i dati relativi agli accessi degli Amministratori di Sistema ai sistemi da loro gestiti, al fine di agevolare la "verifica sulla loro attività da parte di chi ha la titolarità delle banche dati e dei sistemi informatici" (Gazzetta Ufficiale n. 300, 24 Dicembre 2008).

La normativa in pratica richiede che ogni azienda, dopo aver individuato i sistemi (dispositivi di rete, database, apparati di sicurezza e sistemi software complessi) che contengono i dati più critici (personali e sensibili) ed averne nominato gli amministratori, debba dotarsi di un sistema di Log Management in grado di tracciare gli accessi degli operatori ai dispositivi ed alle applicazioni che gestiscono. Questo sistema dovrà conservare i dati in maniera sicura per un periodo minimo di sei mesi e dovrà essere consultabile dall'azienda e dalle autorità.

Pag. 56 di 59

Alessandro Mensini, 01/06/2011,

Da chiarire e approfondire


Una lista, forse incompleta, delle attività necessarie al corretto adempimento della normativa è data di seguito:

Individuazione dei sistemi da monitorare Individuazione univoca degli amministratori di sistema e creazione di utenze collegate alla

persona fisica Aggiornamento del DPS (Documento Programmatico sulla Sicurezza) Eventuale implementazione di un sistema di “strong authentication” che garantisce all’ente

e all’amministratore una maggiore sicurezza poiché viene garantito che le credenziali utilizzate per accedere ad un sistema corrispondono effettivamente alla persona fisica

Raccolta dei Log dai sistemi conformemente alla normativa e con strumenti riconosciuti a livello internazionale

Pag. 57 di 59


3 ORGANIZZAZIONE E MODALITÀ DI LAVORO

L’attività di progettazione e implementazione di un generico processo organizzativo riveste un ruolo fondamentale nell’ambito del progetto della semplificazione e coinvolge diversi attori caratterizzati da differenti profili professionali e competenze tecniche; ogni processo organizzativo a sua volta può essere altrettanto variegato e può coinvolgere applicazioni e servizi differenti a seconda dello specifico scenario di riferimento.

Per questo motivo il sistema sarà caratterizzato da un flusso organizzativo che permetta, al referente dell’ente di poter definire / progettare ad un livello sufficiente alto il processo organizzativo utilizzando lo strumento di disegno del workflow descritto in precedenza opportunamente semplificato nelle funzionalità disponibili, e al fornitore di procedere con il perfezionamento del workflow e l’implementazione delle specifiche tecniche di basso livello.

Il referente dell’ente, nella fase di progettazione del processo organizzativo, avrà la possibilità di inserire nel workflow i servizi coinvolti (funzionalità di applicazioni web esistenti), attingendo ad un elenco di servizi disponibili popolato a partire da tutti quelli censiti attraverso gli strumenti di configurazione del sistema, e di collegare tali servizi attraverso archi che mappano le transizioni di stato del processo.

Una volta progettato il processo ad alto livello, il fornitore di turno si occuperà di specializzare il workflow con un maggiore livello di dettaglio nella configurazione, nella definizione delle regole e nello sviluppo delle singole funzionalità.

Di seguito proponiamo un’ipotesi di scomposizione in fasi degli aspetti appena descritti, dall’individuazione del processo organizzativo alla sua implementazione:

1. Individuazione del processo organizzativoa. Attori: ente (figura amministrativa)b. Input: esigenza aziendalec. Strumenti: carta e pennad. Output: requisiti ad alto livello del p.o. da definire.

2. Definizionea. Attori: ente (figura tecnica)b. Input: requisiti alto livelloc. Strumenti: Form Builder, Editor web BPMNd. Output: specifiche per modello dei dati e GUI, workflow (descrizione del flusso e

individuazione dei servizi occorrenti)

3. Analisi/Progettazionea. Attori: ente, fornitoreb. Input: requisiti alto livello, specifiche per modello dei dati e GUI, workflow c. Strumenti: Drools, Editor BPMN, jBPM,

Pag. 58 di 59


d. Output: requisiti basso livello, specifiche tecniche, workflow (definizione dettagliata dei processi, della pianificazione e schedulazione delle attività, del flusso di controllo e delle regole necessarie)

4. Implementazionea. Attori: fornitoreb. Input: Specifiche tecniche, workflowc. Strumenti: Jbpm, Framework MVC, Framework Integrazione, Liferay, Alfresco, Framework

Orm, Reporting Tools, eccd. Output: processo organizzativo automatizzato, documentazione

Pag. 59 di 59

oscat.rete.toscana.itoscat.rete.toscana.it/docman/view.php/250/864/RT_Semplificazione... · Web...

Documents

Transcript of oscat.rete.toscana.itoscat.rete.toscana.it/docman/view.php/250/864/RT_Semplificazione... · Web...