1www.doqui.it

PROGETTO GESTIONE DOCUMENTALE

INDEX - Architettura del sistemaVersione 1

2www.doqui.it

INDICE

1. Introduzione 4

1.1 Scopo del documento 4

1.2 Riferimenti 4

2. Obiettivi della soluzione 5

2.1 Modelli di riferimento 5

2.2 Scelte e motivazioni 6

2.3 Scenario Open Source 7

2.3.1 Contesto 7

2.3.2 Funzionalità 9

2.3.3 Architettura 11

3. Scenari del progetto 12

3.1 Applicazioni 13

3.1.1 Acta 13

3.1.2 Cedolini on-line 15

3.2 Strumenti 16

3.2.1 Index 16

3.3 Modello SOA 19

3.3.1 Cedolini Document Management 19

4. Visione d’insieme delle componenti 21

4.1 Macro architettura 21

4.1.1 Interazione del sistema con l’esterno 21

4.1.2 Architettura 22

4.2 Stack architetturale completo 23

4.2.1 Architettura logica 23

4.2.2 Architettura fisica 26

4.2.3 ECMEngine 28

4.3 Servizi applicativi 31

4.3.1 ECM Engine Services 31

5. Pattern, framework utilizzati 33

5.1 Pattern DAO 33

5.2 Pattern Business Delegate 34

5.3 Framework C.S.I. 35

5.4 Framework SvcFlow 36

5.5 ECM Application - WDK 37

6. Glossario dei termini 40

3www.doqui.it

INDICE DELLE FIGURE

Figura 2.1-1: Architettura logica ECM platform 6

Figura 2.3-1: Scenari DoQui 12

Figura 3.1-1: Architettura applicativa - scenario Acta 14

Figura 3.1-2: Architettura applicativa - scenario Cedolini 15

Figura 3.2-1: Architettura applicativa ECM Web Console 18

Figura 3.3-1: Cedolini DM modifica stato cedolini 19

Figura 3.3-2: Cedolini DM modifica metadati check-out 19

Figura 3.3-3: Cedolini DM modifica metadati check-in 20

Figura 4.1-1: Index contesto di funzionamento 21

Figura 4.1-2: Index diagramma architetturale 22

Figura 4.2-1: Index tecnologie utilizzate 23

Figura 4.2-2: Index architettura di deployment 26

Figura 4.2-3: Index architettura hardware 27

Figura 4.2-4: ECM Engine splitting dei contenuti 28

Figura 4.2-5: ECM Engine – configurazione mono-repository 29

Figura 4.2-6: ECM Engine – configurazione multi-repository 29

Figura 4.2-7: Index Business Component 30

Figura 5.1-1: Pattern DAO 33

Figura 5.2-1: Pattern Business Delegate (modello dati) 34

Figura 5.2-2: Pattern Business Delegate (sequence diagram) 34

Figura 5.3-1: C.S.I. protocolli supportati 35

Figura 5.4-1: SvcFlow invocazione di metodi di classi locali 36

Figura 5.4-2: SvcFlow architettura logica 36

4www.doqui.it

1. Introduzione

1.1 Scopo del documento

Questo documento fornisce una visione complessiva dell’architettura del sistema Index ovvero della piattaforma del progetto di gestione documentale indicato nella restante parte del documento come DoQui.La piattaforma Index vede la sua origine all’interno di DoQui, progetto che si pone come ulteriore obiettivo la realizzazione di un prodotto informatico per la gestione documentale in grado di assolvere agli obblighi di legge degli Enti pubblici. Tale prodotto, riferito nel seguito del documento come Acta, costituisce la principale fonte di requisiti per Index.

Il documento illustra le caratteristiche architetturali di Index seguendo il percorso decisionale che ha portato all’attuale soluzione, quindi gli obiettivi della soluzione, gli scenari applicativi e infine la vision.

1.2 Riferimenti

● [1] Alfresco Software™: The Open Source Alternative for Enterprise Content Management (www.alfresco.com)

● [2] AIIM - The Enterprise Content Management Association1, Solving the ECM puzzle

● [3] Rete Nazionale: caratteristiche e principi di cooperazione applicativa, Specifiche SPCoop ● [4] DoQui Acta- Quadro di sintesi dei requisiti funzionali (http://www.doqui.it)

● [5] Java Specification Requests,”JSR 170: Content Repository for Java™ technology API”, JSR-170

● [6] Moreq - Model requirements for the management of electronic records (http://ec.europa.eu/transparency/archival_policy/moreq/index_en.htm)

1 Inizialmente conosciuta come Association for Information and Image Management

5www.doqui.it

2. Obiettivi della soluzione

2.1 Modelli di riferimento

Il sistema Index si configura come un sistema di document management (DM) trasversale e funzionale alle esigenze delle applicazioni di Enterprise Content Management (ECM) dell’Ente. Secondo il modello adottato dall’AIIM in [2] le aree funzionali di competenza del sistema sono:

• Collaboration In questa area si collocano gli strumenti di lavoro collaborativo che permettono a più

utenti di lavorare sul medesimo contenuto in un ambiente comune.• Records Management Strumenti per la gestione del ciclo di vita dei singoli contenuti informativi (record) di

un’organizzazione dalla loro creazione, cattura e gestione sino alla definitiva dismissione. Un record non è necessariamente un documento, tutti i documenti sono record potenziali ma non è vero il viceversa. Un record è essenziale per il business, i documenti sono contenitori di informazioni di lavoro; i records sono documenti di validità palese.

• Document Management Strumenti che controllano e organizzano i documenti di tutta un’organizzazione, fra

questi: cattura di contenuti e documenti, workflow di autorizzazione/creazione, repository documentali, sistemi di recupero delle informazioni.

In parallelo alla definizione delle aree funzionali di competenza del sistema si è anche definita un’architettura logica di una generica ECM platform da utilizzare nel selezionare i framework disponibili sul mercato. In questo modo, individuati i sottosistemi di cui si necessita si ha a disposizione un modello di riferimento per classificare quanto si sta analizzando.

L’architettura logica di riferimento è riportata nel diagramma di Figura 2.1-1; nel sistema si individuano tre layer distinti:

• Content Repository Layer È lo Store del sistema responsabile per la memorizzazione degli oggetti documentali e

dei relativi servizi di gestione. Interagisce con lo storage HW di qualsiasi tipo. Sono di responsabilità del layer Query language, Security management, Versioning

policy, Generazione di eventi, Content model; tutti i servizi offerti (Library Services) sono realizzati su di un’implementazione conforme allo standard Java Content Repository JSR-170 [5].

• Domain Layer È lo strato di software responsabile per fornire la business logic necessaria a costruire

le applicazioni ECM-oriented di Collaboration, Records Management, Document Management.

Per le caratteristiche comuni a queste applicazioni possiamo individuare una parte di business logic riutilizzabile (Document Management Engine) e una specifica dell’applicazione di ECM rilasciata, per esempio il Records Management Engine di Acta.

• Presentation Layer È lo strato di software responsabile della presentation (User Interface) della business

logic del domain layer. Sono di responsabilità del layer la visualizzazione di documenti, la funzione della navigazione e le interazioni degli users.

Anche in questo caso per le peculiarità delle applicazioni di ECM rilasciate possiamo individuare una parte di presentation riutilizzabile (Web Development Kit) e una specifica.

Nei layer sono presenti sia componenti di piattaforma che applicative. Nel content repository layer si trovano solo componenti di piattaforma perché a questo livello le specificità del business non intervengono ancora, bensì sono gli standard "open" di accesso al repository che guidano, insieme alla necessità di modellare contenuti dei diversi domini applicativi. I library services

6www.doqui.it

sono generici e coprono le esigenze di search, version control, check in/out, retrieval, audit/trail, ma devono essere orchestrati per arrivare a essere utilizzabili in un’applicazione ECM oriented.

Nel domain layer si trovano sia componenti di piattaforma che applicative, è il livello che contiene la business logic specifica del dominio applicativo. In alcuni casi le piattaforme offrono business logic per domini applicativi specifici come il records management o il document management per mezzo di content model generici ma estensibili. Nel caso del dominio applicativo di Acta il records management che soddisfa i DOD 5015.2 Requirements, che è possibile trovare in piattaforme sia open-source che commerciali, non è utilizzabile perché altri sono i requisiti della legislazione italiana; pertanto tale componente viene classificato come applicativo. Per le caratteristiche di dipendenza dal business di questo livello, i servizi esportati possono essere orchestrati in logica SOA come application services.

Nel presentation layer si trovano principalmente componenti applicative mentre quelle di piattaforma sono limitate al riuso di componenti grafiche (widget). A livello di user interface della ECM Application la GUI out-of-the-box della piattaforma non si presta a essere riutilizzata, ma requisiti come accessibilità, integrazione in portali, layout, etc. richiedono sviluppi ad hoc. Web Development kit e riuso di visual design patterns sono oggetti riconducibili a componenti di piattaforma.L’architettura logica descritta trova riscontro in piattaforme di ECM riconducibili, in logica SOA, a una packaged application.

Per Index e Acta invece è stato usato il modello SOA; pertanto sono gli orchestration, application e data services i livelli a cui occorrerà andare a posizionare i servizi del repository e del domain layer.

2.2 Scelte e motivazioni

Regione Piemonte, Città di Torino e Provincia di Torino hanno deciso di sviluppare una piattaforma di gestione documentale condivisa a supporto dei propri procedimenti amministrativi. Per volontà degli Enti stessi, l’iniziativa ha caratteristiche innovative nell’approccio di sviluppo dello strumento informatico, basandosi sui moderni concetti dell’open-source, stimolando il tessuto produttivo locale, con l’obiettivo di produrre una ricaduta positiva per le aziende del territorio di produzione del software e di fornitura di servizi informatici. La logica che si persegue è quella

Figura 2.1-1: Architettura logica ECM platform

7www.doqui.it

di costruire una soluzione che sia disponibile e partecipata anche dalle imprese ICT, al fine di costruire una comunità che, condividendo il progetto, sviluppi intorno a questa iniziativa un modello di business che veda come mercato potenziale sia la Pubblica Amministrazione, non solo piemontese, ma anche comparti del mercato privato che necessitano di soluzioni informatiche nell’ambito della gestione documentale.L’iniziativa, con questi obiettivi non tutti strettamente informatici a ricaduta interna, viene riferita come DoQui, mentre la piattaforma Index si inquadra nell’ambito dei sistemi di gestione, archiviazione e condivisione di documenti informatici, prodotti da cartacei dematerializzati o digitali in origine, in sintonia e in linea con la legislazione vigente, prima fra tutte il “Codice della Pubblica Amministrazione Digitale”.

Il carattere innovativo dell’iniziativa sta nella creazione di una comunità open-source che realizzi la piattaforma, la gestisca, mantenga e sviluppi un mercato pubblico e privato intorno a questa soluzione. Con tale obiettivo si intende perseguire in maniera evidente la valorizzazione delle competenze del territorio dal punto di vista della diffusione della conoscenza sul funzionamento dei sistemi della Pubblica Amministrazione. Si vogliono inoltre valorizzare quelle competenze accademiche, metodologiche e tecnologiche che, partendo dalle necessità degli Enti, sono in grado di produrre una soluzione che abbia un concreto spazio di mercato e che promuova il distretto delle aziende ICT piemontese su un mercato più ampio.

I requisiti funzionali della piattaforma sono quindi dettati in larga misura, nella prima fase, per sviluppare una soluzione informatica in grado di assolvere alle necessità gestionali dell’Archivio ufficiale dell’Ente pubblico, in termini di gestione della classificazione, del titolario, delle regole di distribuzione della documentazione, interna agli uffici e nei confronti dell’esterno, di politiche di memorizzazione e conservazione (archivio corrente e di deposito), ovviamente in relazione alla normativa vigente in materia.Invece i requisiti non funzionali della piattaforma sono:

• piattaforma tecnologica di classe “enterprise”, basata su paradigmi SOA (service oriented architecture), standard industriali e componenti standard;

• alta modularità architetturale e funzionale, in modo da garantire un adeguato livello di flessibilità e configurabilità;

• capacità di carico dell’ordine di milioni di documenti e centinaia di utenti concorrenti (migliaia di utenti nominali);

• scalabilità, verso l’alto e verso il basso, in termini di richieste di risorse elaborative per una soluzione complessa e minimale, in modo da essere calata in contesti di grandi e piccole dimensioni;

• piattaforma di esecuzione basata su middleware interamente open-source (application server, DB server, sistema operativo, ecc.), linguaggio di programmazione Java e adeguata a essere ospitata all’interno di application server J2EE;

• funzioni di sicurezza applicativa (autenticazione e autorizzazione);• funzioni di ILM (Information Lifecycle Management) dei contenuti.

2.3 Scenario Open Source

2.3.1 ContestoIl requisito del progetto DoQui che impone lo sviluppo di una piattaforma in logica open-source ha richiesto l’esecuzione di un’attività di analisi degli OSS (open-source software) di componente applicativa per selezionare un progetto su cui fondare lo sviluppo di Index.Tale attività è iniziata nella primavera del 2005 quando, nel panorama delle numerose soluzioni open-source disponibili, si è iniziata a intravedere la nascita di progetti specifici per l’ECM/DMS.All’epoca vennero individuati i seguenti prodotti:

• DSpace: software open-source per la gestione di oggetti digitali sviluppato dal Massachussetts Institute of Technology (MIT) insieme a Hewlett-Packard;

• FedoraCommons: software open-source per la gestione di contenuti digitali sviluppato dalla University of Virginia Library insieme a Cornell University;

• xinco DMS™: software open-source per il document management sviluppato inizialmente

8www.doqui.it

da Alexander Manes della University of Cooperative Education, Heidenheim, Germany;• Sakai: software open-source sviluppato inizialmente dalla University of Michigan e

Indiana University e avente funzioni di Content Management.I progetti analizzati andavano da un DSpace™, attivo nell’area delle risorse digitali bibliotecarie, ad un Fedora con ambizioni simili ma di concezione più recente, a sistemi embrionali di DMS quale xinco DMS™. Altri prodotti si presentavano come DMS ma erogavano servizi in settori diversi, per esempio Sakai per l’e-Learning, altri il Web Content Management.

Ciò che ha impresso una svolta ai progetti open ma anche ai sistemi commerciali di ECM è stato lo standard "Content Repository API for Java Technology (JCR)", JSR-170 ([5]), che si è posto l’obiettivo di definire un’interfaccia standard a un content repository per piattaforme J2SE/J2EE™.Questo standard, approvato il 31/05/2005 da parte del J2SE/EE executive committee, è a oggi in corso di ulteriore sviluppo con la versione 2.0 delle API (30/10/2006 primo draft). Il progetto Jackrabbit, dell’Apache Software Foundation, ha fornito un’implementazione open di un content repository JCR compatibile e da marzo 2006 Jackrabbit è un top-level-project (TLP) di Apache.Contestualmente al completamento della release 1.0 di Jackrabbit si è assistito al proliferare sia di implementazioni open di content repository JCR che di progetti open di ECM/DMS, fra i quali:

• Jeceira: implementazione open-source di un content repository JCR;• JLibrary: DMS per uso personale ed enteprise in modalità client-server basato sul

content repository JCR di Jackrabbit.Questi progetti, nonostante il rilevante salto tecnologico, potevano ancora essere considerati alla stregua dei precedenti Fedora, xinco e Sakai; ciò che ha radicalmente modificato il contesto di riferimento è stato da un lato la convergenza di prodotti commerciali verso il JCR standard (EMC-Documentum, FileNet, OpenText), e dall’altro la comparsa di progetti open e non con contenuti decisamente interessanti e che andavano oltre i DMS visti sino a quel momento.I prodotti oggetto di interesse sono stati i seguenti:

• Magnolia: sistema di enterprise content management a supporto di un enterprise portal. È disponibile una community edition per l’ECM, mentre solo l’enterprise edition prevede tutte le funzionalità di portale e content management;

• Day: sistema di content management commerciale e concorrenziale ai più noti prodotti commerciali (Documentum, FileNet, …). È stato costruito sul JCR standard dalla società che ne ha promosso lo sviluppo e ha fornito il primo Technology Compatibility Kit (codice sorgente java) da cui sono derivate le successive implementazioni di content repository JCR compliant;

• Alfresco Software™: sistema di enterprise content management disponibile con licenza open-source con contenuti funzionali e tecnologici di estremo interesse tali da permettere la realizzazione di applicazioni di gestione dei documenti nelle aree del Workflow, Web Content Management, Web Portal, Collaboration, Document Management e Records Management;

• Nuxeo ed eXoPlatform®: sistemi di enterprise content management disponibili con licenza open-source e contenuti funzionali simili a quelli di Al fresco, ma soprattutto che condividono con quest’ultimo framework e pattern di sviluppo.

Tutti questi prodotti, a differenza di quelli precedenti, hanno presentato immediatamente le caratteristiche di un sistema di ECM completo funzionalmente e al passo con la tecnologia attuale.

È seppur vero che i limiti individuati a suo tempo nei prodotti open-source rimangono tali e vengono a ridursi solo in prodotti con vocazione commerciale, vedi Day. Questi limiti sono, per esempio, l’assenza di tool di configurazione per il building & deployment di applicazioni o di tool di amministrazione con funzionalità proprie di amministrazione e configurazione del repository documentale. A oggi è disponibile essenzialmente la gestione degli utenti, dei gruppi e dei permessi di accesso, import ed export dei contenuti e metadati, interrogazione della configurazione.

Quindi debbono ancora essere visti come framework da cui partire per arrivare a un servizio

9www.doqui.it

applicativo, seppur complesso e trasversale, come la gestione dell’archivio della PA, da essere assimilato a una piattaforma (pila costituita da architettura di software e hardware, sistema operativo, ecc..).Alla luce di queste considerazioni i prodotti che sono stati selezionati per un’analisi approfondita sono DSpace, Alfresco Software™, Nuxeo, ed eXoPlatform®. DSpace è stato selezionato per le caratteristiche di solidità della community e del prodotto presente sullo scenario da anni, imentree Alfresco Software™, Nuxeo, ed eXoPlatform® sono stati selezionati per le caratteristiche innovative, omogeneità di realizzazione, comparabilità e posizionamento sul mercato.

I risultati del lavoro di analisi effettuato permettono di affermare che esistono indubbiamente almeno 3 prodotti open-source di ECM (Alfresco Software™, Nuxeo, ed eXoPlatform®) ben assestati in termini di funzionalità per poter affrontare la realizzazione di applicazioni di content management complesse a livello enterprise. I prodotti si differenziano dai principali ISV presenti sul mercato da anni per essere innanzitutto un framework da cui partire e non una piattaforma su cui approdare.Di fronte a un set di servizi del content repository ben definiti e disponibili su tutte le soluzioni si trovano delle funzionalità di gestione dei contenuti più o meno complete che sono state guidate nel loro sviluppo dalle esigenze degli utenti a cui per primi la community, o l’azienda, si è rivolta. Possiamo quindi dire che tali funzionalità sono in alcuni casi addirittura sbilanciate rispetto a una distribuzione che risulta più omogenea nei prodotti di mercato: per esempio sbilanciamento verso il portale di Nuxeo e eXoPlatform®.Effettuare un confronto quantitativo (misurabile) fra le soluzioni al solo livello funzionale è perciò difficile e forse poco utile: possiamo comunque dire che il modello AIIM viene in aiuto nella classificazione di queste funzionalità. In altre parole, è meglio prendere l’utile da tutti che solo da qualcuno. È possibile effettuare un confronto quantitativo (si/no) delle interfacce di servizio in termini di aderenza agli standard e possibilità di scelta, oppure dell’adattabilità agli application server open; si tratta solo di dedicarvi il tempo necessario.Invece è difficile confrontare le diverse soluzioni in termini di framework di sviluppo utilizzati, pattern, tecnologie diverse di cui fanno uso; possiamo dire che questi aspetti interferiscono al più con i prerequisiti formativi dei futuri developer, ma non dicono nulla sulla qualità del prodotto. Questi aspetti intervengono invece sulle possibilità di sviluppo ulteriore della soluzione in quanto è seppur vero che potrebbero rendere infattibile qualche soluzione (per esempio non è possibile esportare Web Services, si deve realizzare un'implementazione ad hoc).Circoscritta quindi la scelta ai 3 OSS di ECM, la selezione dell’OSS da utilizzare per lo sviluppo di Index è stata effettuata sulla base delle peculiarità dello stesso che sarebbero state maggiormente sfruttate nello scenario principale di utilizzo del sistema. Ebbene l’OSS Alfresco Software™ è risultato essere quello che presentava il Content Repository più performante, sia per la varietà di protocolli di accesso che per i servizi di lavorazione, aggregazione e ricerca dei contenuti. Nell’effettuare questa scelta si è considerato meno prioritario il Presentation Layer e quindi gli OSS che hanno investito per lo più in quest’area riutilizzando un JCR repository di altri progetti come Jackrabbit.

2.3.2 FunzionalitàIl grado di copertura funzionale di Alfresco Software™ è decisamente elevato: per quasi ognuna delle funzioni individuate dall’AIIM si trovano soluzioni disponibili già a livello di user-interface out-of-the-box. Esaminiamole in dettaglio.

Sono presenti funzionalità per la cattura di contenuti creati sia applicativamente che manualmente. Per i contenuti creati manualmente sono disponibili a partire dalla release 1.4 soluzioni di imaging. A causa della mancanza di soluzioni open nel settore, Alfresco si è rivolto a componenti commerciali di terze parti, fra queste:

• Kofax Release Script: si tratta di un plug-in per Kofax, sviluppato da Aarden Ringcroft, responsabile per il mapping e il trasferimento di informazioni catturate con Kofax nel repository di Alfresco Software™. In questo modo sono disponibili funzioni di digitalizzazione (imaging) e riconoscimento di caratteri (OCR), il processo di trasferimento è indicato come "release".

10www.doqui.it

• Intelliant OCR: l’OCR di Intelliant è stato integrato out-of-the-box in Alfresco Software™: si tratta di una command-line application.

Per i contenuti creati applicativamente non si individuano specifici plug-in ovvero soluzioni di integrazione con prodotti commerciali o meno.Relativamente alle funzionalità di indexing, categorization, aggregation e input designs coinvolte prima che il contenuto sia disponibile per consultazione nel repository documentale in Alfresco Software™ individuiamo:

• Rule Based Action e Content Transformations per indexing, categorization, e aggregation;

• Web Client Configuration per l’input designs.I processi richiesti possono essere attuati attraverso l’esecuzione di eseguibili (content transformer eseguibili a run-time), custom action (implementati attraverso action executor), o l’esecuzione di script scritti in JavaScript 1.5.

Per la gestione, Alfresco Software™ offre funzionalità avanzate di movimentazione dei contenuti all’interno dell’organizzazione. Queste funzionalità si espletano nella piattaforma attraverso i seguenti sottosistemi:

• Collaboration Alfresco Software™ andrà a fornire direttamente o integrare a partire dalla release

1.4 le tecnologie di collaborazione quali e-mail team, wikis, blogs, discussion threads, instant messaging.

• ECM Platform Alfresco Software™ nasce come una piattaforma che permette non solo di aggiungere

nuovi aspects nel lato server, ma anche di aggiungere nuovi plug-in di user interface components nell’interfaccia Web. In questo modo diventa una piattaforma abilitante all’erogazione di servizi content-oriented e quindi va a semplificare lo sviluppo di applicazioni nelle aree di imaging, collaboration, publishing e records management.

• Records Management Alfresco Software™ offre un modulo di records management come estensione del

sottosistema di ECM che soddisfa i DOD 5015.2 Requirements.• Web Content Management Le funzionalità di WCM sono disponibili a partire dalla release 1.4: l’obiettivo è creare

un ambiente unificato per la gestione a livello enterprise sia del Document Management che del Web Content Management. Questo obiettivo potrà essere raggiunto estendendo le funzionalità attuali come aggiungendone di nuove.

• Workflow Le funzionalità di workflow disponibili in Alfresco Software™ nascono per fornire

supporto ai processi user-oriented che sono gestiti all’interno del contesto di un content repository, quali per esempio review, approve, translation e publish.

Nella visione della community che immagina sarà ancora il BPEL a fornire supporto per il process management a livello enterprise, dove il content management rappresenta una parte del processo: possiamo dire che il Content Management Process è l’obiettivo di Alfresco Software™ mentre il Content Integration Process non sarà contemplato.

Per il campo di applicazione di Index il sottosistema di Alfresco Software™ di maggior interesse è quello di ECM Platform (Document Management).Per erogare funzionalità avanzate di memorizzazione il content management system del prodotto utilizza:

- un database per la memorizzazione dei meta-dati;- un file system per la memorizzazione dei contenuti.

Sono anche ritenute utili le funzionalità di Content Transformations che possono essere utilizzate per attivare la trasformazione di contenuti da e verso i formati più comunemente utilizzate nell’ambito di destinazione della piattaforma (PDF, TIFF, JPEG, XML, PKCS #7…), mentre le Rule Based Actions possono attivare l’apposizione della firma digitale a un contenuto.

11www.doqui.it

Invece le funzionalità del sottosistema di WCM possono essere utilizzate per la pubblicazione di contenuti su Internet, Extranet, Intranet oppure la pubblicazione di contenuti XML.

Alfresco Software™ non offre funzionalità di conservazione e quindi non è possibile utilizzare content storage quali CAS e dischi ottici; è però possibile effettuare processi di riversamento su questi storage device.Analogamente, Alfresco Software™ non offre funzionalità specifiche dedicate al delivery di contenuti, mentre è possibile utilizzare funzionalità generiche per attivare le tecnologie interessate, ovvero trasformazione, sicurezza e distribuzione.

2.3.3 ArchitetturaNell’architettura di Alfresco Software™ (release 1.4 e 2.1) si possono individuare le seguenti componenti:

• Meccanismi di storage & retrieval: Embedded Container, RDBMS, Repository service, Search service

• Interfacce del Repository: CIFS, JSR-170, WebDav, FTP• Servizi e comportamenti costruiti sul repository: Content Type System, Pluggable

Services & Aspects, Workflow, Actions, Access Control, ecc… Tutte queste componenti sono il Content Management Framework (CMF) del prodotto

dal quale è costruita la UI out-of-the-box, che può essere estesa da chi vuole sviluppare nuovi servizi applicativi

• Interfacce applicative: JSR-223 (JavaScript), Java, JCR e JCR RMI API, Web Services per BPEL, .NET, PHP Ruby

• Web Client: Portlet, Interfaccia Web nativa, componenti JSFGli Alfresco Software™ Foundation Services sono i servizi da cui sono derivate tutte le interfacce applicative e sono così composti:

• Node Service per gestire i meta-dati (nodi)• Content Service per gestire i contenuti• Search Service per eseguire le ricerche

Nello schema Alfresco Software™ Foundation Services (Fonte Alfresco Developers) sono indicate le relazioni fra le tecnologie utilizzate per costruire i servizi.Le tecnologie di memorizzazione adottate sono quelle su cui è possibile utilizzare il file system, quindi sostanzialmente lo storage magnetico (NAS, SAN, RAID); sono invece disponibili due query languages Xpath (JCR Xpath) e Lucene (Google like).

Nel diagramma Alfresco Software™ API (Fonte Alfresco Developers) si individuano le relazioni fra Services e interfacce applicative nelle diverse tecnologie.A livello di content domain (business use cases del CMF) il repository rende disponibile le seguenti funzionalità:

• Content Transformation• Meta-data extraction• Templating• Classification• Versioning• Locking• Content Modelling• Image Manipulation• Workflow • Import & Export• Permissions• Audit Trail

12www.doqui.it

3. Scenari del progetto

Il progetto DoQui risponde ai requisiti del paragrafo 2.2. Gli scenari di fruibilità della piattaforma Index, nel comparto pubblico e in quello privato, sono declinati in:

• applicazioni • strumenti

Nel seguito si descrivono le funzionalità delle applicazioni e l’area di competenza secondo il modello di riferimento del paragrafo 2.1 e gli strumenti di Index che sono stati definiti a supporto.Nella rimanente parte del documento si fa riferimento ad Alfresco Software™2 come Open Source ECM Software (OSECM).OSECM Software è il nucleo utilizzato per lo sviluppo di Index.

Figura 2.3-1: Scenari DoQui

13www.doqui.it

2 Alfresco Software is a trademark of Alfresco Software Ltd. in the United States, the European Union and other countries.

3.1 Applicazioni

Vengono di seguito illustrati due casi esemplificativi di applicazioni basate su Index.Nel primo caso (Acta, applicativo per la gestione archivio ufficiale di un Ente) viene descritto un tipico sistema di ERMS, nel secondo (Cedolino on-line, applicativo per il rilascio dwl cedolino stipendio elettronico) un esempio di pubblicazione di contenuti. 3.1.1 ActaL’applicazione DoQui Acta [4] declina lo scenario di utilizzo della piattaforma Index nel sistema di gestione documentale dell’Ente. Con i suoi moduli Acta fornisce agli utenti funzionalità avanzate di gestione della documentazione elettronica e non.Riferendosi alle tassonomie tipiche dell’ECM, l’applicazione Acta e la piattaforma Index costituiscono il sistema di ERMS (Elettronic Records Management System) dell’Ente pubblico.

In questo scenario nelle aree funzionali di competenza del sistema di gestione documentale, secondo il modello AIIM, individuiamo i seguenti strumenti di lavoro o moduli applicativi:

• Collaboration Acta richiede la messa a disposizione degli utenti di strumenti di lavoro collaborativo

quali le funzionalità di workflow documentale del modulo di gestione contenuti; fra queste funzionalità si individuano:

- associazione dei documenti a cicli di vita predefiniti quali firma e visto; caratteristica di questi flussi è la possibilità data all’utente di coinvolgere altri utenti a propria discrezione

- gestione dello smistamento- gestione degli avvisi

Gli oggetti documentali appartengono a due categorie distinte:- i documenti fixed-content con validità “giuridica”, prodotti e fruiti dalle applicazioni

del sistema informativo dell’Ente- i documenti, sia fixed-content che variable-content, che non hanno dignità di

essere considerati “ufficiali”, ma che possiedono notevole valore da un punto di vista informativo o archivistico

• Records Management Le richieste di RM di Acta sono quelle dei moduli di gestione archivio e gestione

strutture archivio; sono le funzionalità richieste da questi moduli che governano la progettazione di library services ad hoc rispetto a quelli altrimenti disponibili nell’OSECM Software.

• Document Management Le richieste di DM di Acta sono quelle dei moduli di gestione contenuti, gestione

archivio, gestione strutture archivio e ricerche e statistiche; sono le funzionalità richieste da questi moduli che governano la progettazione di molti library services di Index. Acta richiede di gestire due archivi, l’archivio corrente e l’archivio di deposito, e il passaggio dei documenti e delle strutture aggregative tra i due archivi. Non è gestito l’archivio di storico.

I due archivi sono sostanzialmente due repository separati che però riflettono la stessa organizzazione documentale (lo stesso titolario), ma solo in parte le stesse funzioni. Diversi sono invece i volumi trattati dai due repository: l’archivio di deposito è destinato a crescere nel tempo con volumi attesi di almeno un milione di documenti/anno, mentre l’archivio corrente è destinato ad assestarsi su un valore costante e vede nella migrazione dei documenti in deposito il fattore di riduzione della crescita.

14www.doqui.it

Acta rappresenta lo scenario primario di utilizzo della piattaforma Index come sistema di gestione documentale con funzioni di ERMS, che offre funzionalità ai sistemi fruitori attraverso servizi applicativi specifici e/o specializzati (content repository server), eventualmente orchestrati da processi di integrazione governati da uno strumento di integrazione applicativa.Nella Figura 3.1-1 viene riportata l’architettura applicativa che segue da quanto esaminato; inoltre è evidenziato come Index si posiziona nel modello e quale ruolo va a ricoprire.

La piattaforma Index svolge il ruolo di content repository server per i contenuti non strutturati di Acta, documenti fixed-content e variable-content organizzati secondo archivio corrente e di deposito.

Invece Acta Servizi fornisce la business logic specifica del dominio applicativo, che in questo caso è il Records Management.

In analogia alla Figura 2.1-1 possiamo parlare di:• Acta Servizi come Records Management Engine • Index come Document Management Engine • Acta Client ed Acta Orchestrazione come ECM Application.

Figura 3.1-1: Architettura applicativa - scenario Acta

15www.doqui.it

3.1.2 Cedolini on-lineL’applicazione denominata “Cedolini on-line” declina lo scenario di utilizzo della piattaforma Index nel sistema di gestione documentale dell’Ente per la pubblicazione di contenuti.

Cedolini on-line (di seguito Cedolini), con i suoi moduli applicativi, si propone come sistema per la sostituzione dei cedolini cartacei con i cedolini on-line e normativamente fa riferimento al decreto del 12 gennaio 2006, “Autorizzazione all’invio per via telematica, all’indirizzo di posta elettronica assegnato a ciascun dipendente, del cedolino per il pagamento delle competenze stipendiali del personale di cui all’articolo 1, del decreto legislativo 12 febbraio 1993, n. 39, (Gazzetta Ufficiale n. 60 del 13-03-2006)”.

Cedolini intercetta all’interno del flusso di generazione degli stipendi, prodotto dai sistemi del personale, i file per la produzione dei cedolini in formato cartaceo, elaborati per produrre cedolini elettronici (file PDF) e memorizzati in Index con i metadati di pertinenza. Facendo uso dei library services di Index, la business logic di Cedolini permette a un operatore del servizio di gestire il ciclo di vita del documento, quindi autorizzare il cedolino alla pubblicazione, notificare il dipendente dell’avvenuta pubblicazione on-line, annullare o eliminare il cedolino.Nella Figura 3.1-2 viene riportata l’architettura applicativa con evidenziato il ruolo di Index.

Figura 3.1-2: Architettura applicativa - scenario Cedolini

16www.doqui.it

3.2 Strumenti

3.2.1 IndexLa piattaforma Index va a configurarsi come uno degli strumenti a supporto delle applicazioni del progetto DoQui e in qualità di ECM platform le componenti del sistema vanno a collocarsi nei tre layer distinti individuati in Figura 2.1-1; abbiamo quindi:

• Content Repository Layer A questo livello si colloca la componente di Index ECM Engine responsabile di fornire i

library services di Document Management del sistema

• Domain Layer A questo livello si collocano le componenti di Index con logica di business di

gestione dei contenuti specifica del dominio delle applicazioni. La roadmap di Index 2008 individuerà le componenti con cui andare a costruire il layer

• Presentation Layer Ad oggi Index non prevede una GUI out-of-the-box di ECM, pertanto le componenti

disponibili a questo livello sono user interfaces di amministrazione del sistema. Sono state individuate una Web Console e una Administration Console che saranno oggetto di prossimo sviluppo.

Nel seguito si descrive ogni singola componente.

3.2.1.1 ECM EngineLa componente ECM Engine è il Document Management Engine di Index, realizzato a partire dal nucleo dell’OSECM Software. Lo scenario architetturale di utilizzo dell’OSS è quello del Repository Server che per esigenze di High Availability e Load Balancing deve essere configurabile come Clustered Repository Server, pertanto gli interventi effettuati sul core dell’OSECM sono rivolti proprio in questa direzione.

La scalabilità orizzontale dell’ECM Engine è indirizzata sia a livello delle performance (scalabilità del carico) che dei volumi (numero di documenti gestiti su repository fisico), mentre la scalabilità verticale è indirizzata con la suddivisione in tier distinti dei layer data, business logic e presentation dell’OSECM Software di partenza.

L’ECM Engine organizza i contenuti in un JCR Repository, componente rivolta allo storage di dati e contenuti attraverso strumenti di gestione della persistenza quali Data Base e File Systems. I servizi di accesso ai contenuti che il repository pubblica sono compliant con lo standard riferimento "Content Repository API for Java Technology", JCR appunto.

Nell’OSECM Software l’organizzazione dei contenuti nel repository segue quanto esposto dalla specifica JSR-170 ma con sensibili differenze: sostanzialmente nel progetto open-source troviamo una risposta, del tutto specifica dell’implementazione, al problema della definizione di node types "applicativi". Anche in Jackrabbit si trova una risposta del tutto specifica alla stessa questione.

A seguito dell’implementazione "proprietaria" che l’OSECM fa del repository, ne derivano anche dei servizi di accesso altrettanto proprietari. Gli Alfresco Software™ Foundation Services sono i servizi da cui sono derivate tutte le interfacce applicative; questi servizi sono così composti:

- Node Service per gestire i meta-dati (nodi)- Content Service per gestire i contenuti- Search Service per eseguire le ricerche

Pertanto all’interfaccia di servizio del JCR Repository sono resi disponibili gli Alfresco Software™ Foundation Services, e su questi servizi sono costruiti gli ECM Engine Services; questi ultimi rappresentano le interfacce applicative del repository e si distinguono in Repository Protocols

17www.doqui.it

(CIFS, WebDAV, FTP, Open Search) e Repository APIs (JSR-170, Web Services, JSR-168, ECM Engine Services).

Definita l’interfaccia di servizio di ECM Engine, il suo ruolo di gestore della persistenza richiede funzionalità specifiche di memorizzazione di contenuti in sorgenti fisiche distinte. Un documento è composto da un file di contenuto (il file sorgente nella sua forma nativa) e dagli attributi del documento (metadati o proprietà) che descrivono i contenuti e le relazioni tra questi contenuti e altri oggetti presenti nel repository. ECM Engine organizza i file di contenuto in una struttura di directory su un file system, mentre i metadati del documento sono memorizzati in tabelle di database relazionale.

Per soddisfare esigenze di affidabilità delle ECM Application l’engine offre servizi per memorizzare contenuti nella forma di oggetti su sistemi di storage dedicati (per esempio di tipo CAS o supporti magneto ottici in alternativa a storage SAN/NAS) e replicare un sottoinsieme di metadati sullo storage per esigenze di long-term preservation (conservazione dei documenti).

Oltre ai file di contenuto e agli attributi che li descrivono, il content repository include un set di indici testuali creati dal motore di indicizzazione. Questi indici, che consentono la ricerca basata sui contenuti del repository, vengono memorizzati su file system.

Sulla base di quanto detto il livello di persistenza del JCR Repository può essere suddiviso in due ulteriori strati denominati:

• Livello oggetti (Object-Based Layer) È il livello che si occupa della memorizzazione dei record applicativi nell’RDBMS

sottostante• Livello contenuti (Bitstream Layer) È il livello responsabile della memorizzazione dei contenuti e quindi funge da interfaccia

verso i dispositivi di storage sottostanti. ECM Engine è in grado nativamente di dialogare con dispositivi di storage per mezzo di file system API, ma non si esclude di poter soddisfare esigenze di memorizzazione che richiedono API proprietarie.

Infine riprendendo quanto indicato in 2.1, secondo cui Index e le sue componenti devono essere riutilizzabili in logica SOA, occorre ricordare che sino all’avvento dei Web Services i prodotti di ECM (commerciali e non) erano architetture auto referenziali che ospitavano funzionalità pacchettizzate accessibili per mezzo di API proprietarie altamente specializzate. La capacità di consumare e/o esporre servizi via Web Services ha rappresentato una prima, seppur timida, evoluzione di tali prodotti; in questo caso client custom potevano accedere a servizi generici (coarse-grained) dell’ECM server, mentre la ECM Application out-of-the-box forniva ancora servizi più ricchi perché faceva uso delle API specializzate (fine-grained).

Lo scenario dell’OSECM Software con cui Index si è confrontato è riconducibile a questa evoluzione di medio termine. Affinchè Index potesse offrire gli strumenti necessari a uno sviluppo dell’ECM in logica SOA è stato necessario abbandonare il paradigma delle funzionalità pacchettizzate per abbracciare quello dei servizi riusabili ed estensibili. Pertanto gli ECM Engine Services raccolgono operazioni elementari e poco accoppiate (middle-sized), quindi ricomponibili e orchestrabili, annullando pertanto la differenza fra ECM Application out-of-the-box e client custom.

Esempi di utilizzo del modello SOA nelle ECM Application del progetto DoQui sono riportati nel paragrafo 3.3, utilizzando Cedolini come scenario di riferimento.

18www.doqui.it

3.2.1.2 ECM Web ConsoleLa componente ECM Engine in qualità di Document Management System richiede un'applicazione Web con funzionalità a supporto delle attività di manutenzione dati del content repository. La ECM Web Console offre funzionalità di:

• creazione/modifica utenti, gruppi di utenti, folder• creazione/modifica contenuti, loro proprietà, relazioni• browsing del content repository di basso livello (oggetti JCR)• verifica di integrità referenziale del content repository

L’applicazione in oggetto utilizza i servizi messi a disposizione da Index attraverso un tier di orchestrazione dei servizi di ECM Engine; nella Figura 3.2-1 viene riportata l’architettura applicativa dell’applicazione:

Gli utenti a cui l’applicazione è dedicata svolgono attività di assistenza applicativa agli utenti destinatari delle ECM Application; per conto di questi sono offerti servizi di amministrazione della piattaforma e di manutenzione dati del content repository. Il taglio architetturale di tale componente che si configura come uno strumento di Index è analogo a quello degli scenari Acta e Cedolini con i layer previsti dal modello.La tecnologia utilizzata per la UI di Web Console è basata sul WDK (Web Development Kit) di Index come da paragrafo 5.5.

3.2.1.3 ECM Administration ConsoleLa ECM Administration Console si affianca alla Web Console per le attività di manutenzione della componente ECM Engine. La ECM Administration Console offrirà funzionalità di manutenzione della piattaforma vicine alle esigenze degli utenti sistemisti, come accesso ai log, configurazione dei livelli di log, monitoring dello stato dei servizi, operazioni da effettuare in condizioni di fermo servizio del content repository come dump/restore, check di integrità.

Figura 3.2-1: Architettura applicativa ECM Web Console

19www.doqui.it

3.3 Modello SOA

3.3.1 Cedolini Document ManagementL’applicazione del modello SOA in Cedolini on-line è descritto nei tre casi d’uso che seguono, dove Cedolini Orchestrazione fornisce servizi di Document Management al client orchestrando gli ECM Engine Services.

• Cambiamento massivo dello stato dei cedolini Il client richiama il servizio che, sulla base dei parametri di invocazione, individua

un insieme di nodi su cui operare la modifica del “metadato” stato; per ogni nodo individuato dalla query viene richiamata l’operazione di aggiornamento metadati.

• Recupero dei metadati di un cedolino per la modifica. Il client richiama il servizio indicando il nodo su cui operare, e la componente di

orchestrazione richiama in sequenza le operazioni di check-out del nodo e quella di recupero metadati.

Figura 3.3-1: Cedolini DM modifica stato cedolini

Figura 3.3-2: Cedolini DM modifica metadati check-out

20www.doqui.it

• Conferma modifica metadati di un cedolino Il client richiama il servizio con i metadati modificati, e la componente di orchestrazione

richiama in sequenza le operazioni di aggiornamento e check-in del nodo.

Figura 3.3-3: Cedolini DM modifica metadati check-in

21www.doqui.it

4. Visione d’insieme delle componenti

Il paragrafo fornisce una visione complessiva delle componenti architetturali della piattaforma Index. Per la descrizione dell’architettura si parte da una vista ad alto livello che verrà successivamente dettagliata fino a descrivere la singola componente.A seguito dell’implementazione "proprietaria" che l’OSECM fa del repository ne derivano anche dei servizi di accesso altrettanto proprietari: gli Alfresco SoftwareTM Foundation Services dai quali sono derivate tutte le interfacce operative. Nella rimanente parte del documento si riferisce ad Alfresco SoftwareTM Foundation Services come OSECM Services.

4.1 Macro architettura

4.1.1 Interazione del sistema con l’esternoLe applicazioni del progetto DoQui forniscono ad utenti della Pubblica Amministrazione e non, strumenti di lavoro appartenenti alle aree funzionali individuate nel modello di riferimento del paragrafo 2.1, si tratta di funzionalità di enterprise content management declinate attraverso una serie di servizi per la memorizzazione, ricerca e gestione di contenuti. Il diagramma seguente descrive un possibile contesto di funzionamento della piattaforma Index.

Figura 4.1-1: Index contesto di funzionamento

22www.doqui.it

4.1.2 ArchitetturaLa piattaforma Index fa uso dei servizi offerti dall’OSECM framework per le funzioni di base.Il diagramma architetturale seguente descrive una visione ad alto livello della piattaforma con le componenti dei tre layer individuati in Figura 2.1-1.

Il database viene utilizzato per la memorizzazione della struttura gerarchica e dei metadati descrittivi degli oggetti gestiti dall’ECM Engine (cartelle, documenti…) secondo il modello interno dell’OSECM Software. Non si memorizzano i documenti sul database ma su un file system separato. Sul DB si mantengono solamente dei link fra i metadati descrittivi del documento e la sua locazione fisica sul file system.

Le funzionalità di base per la categorizzazione e memorizzazione dei documenti (e tutte le funzioni accessorie a basso livello per la loro gestione) sono fornite dagli OSECM Services. Tramite la creazione di Servizi Infrastrutturali e di Servizi Custom ad hoc, come, ad esempio, le funzioni di “Firma Digitale”, si estendono gli OSECM Services con le nuove funzionalità richieste dalle ECM Application.

Gli Engine sono piattaforme e motori utilizzati dai servizi. Essi sono assimilabili a servizi infrastrutturali e, nel resto di questo documento, verranno considerati come tali.

Non si consente l’accesso diretto, da parte delle ECM Application, agli OSECM Services, l’esportazione di questi servizi, verso le altre applicazioni, avviene tramite la creazione di un layer di servizi infrastrutturali (ECM Engine Services, riferiti nel seguito come ECM Services). La componente ECM Services, incapsulando al suo interno gli OSECM Services e i Custom Services, fornisce i servizi infrastrutturali della componente ECM Engine.

Le ECM Application possono accedere all’ECM Engine solo tramite gli ECM Services.

Tramite la componente ECM Web Console si forniscono agli utenti abilitati, le funzioni di amministrazione e gestione dell’ECM Engine e quindi della piattaforma.

Figura 4.1-2: Index diagramma architetturale

23www.doqui.it

4.2 Stack architetturale completo

4.2.1 Architettura logicaLe tecnologie utilizzate per l’implementazione delle componenti della piattaforma Index sono tutte open-source, nel seguente schema è rappresentato lo stack delle tecnologie utilizzate:

La memorizzazione dei documenti è affidata a degli storage server di rete (NAS) e/o ai Content Addressable Storage (CAS). Questi ultimi, rispetto ai NAS standard, sono specifici per la memorizzazione di contenuti fixed content, sia multimediali sia di testo, e si caratterizzano per offrire garanzie di conservazione e riduzione delle ridondanze che da soli gli storage NAS non possono offrire.

La memorizzazione dei metadati inerenti i documenti e la categorizzazione gerarchica degli stessi avviene tramite l’utilizzo del DBMS open-source MySQL. Questo strumento è ormai consolidato e presente livelli di affidabilità e prestazioni paragonabili con i principali DBMS commerciali.

Entrambe le componenti Custom Services e OSCM Services per poter funzionare utilizzano i seguenti strumenti e librerie:

• Quartz Si tratta di uno scheduler in grado di eseguire, ad istanti prestabiliti, dei job Java e che

può essere integrato con tutte le tecnologie Java Enterprise. I suoi punti di forza sono la semplicità di configurazione (affine al crontab dei sistemi Unix), la persistenza dei trigger e dei job che possono essere salvati in modo trasparente su un database, la possibilità di mettere in cluster più istanze dello schedulatore, la presenza di un’interfaccia a plug-in che consente l’estensione dello strumento e la possibilità di eseguire un monitoraggio in tempo reale sullo stato di ogni job e sul risultato dell’esecuzione degli stessi.

• Lucene Si tratta di un motore di ricerca full-text interamente scritto in Java. Viene utilizzato

per eseguire le ricerche su metadati e testi associati ai documenti. Presenta una vasta collezione di interfacce in grado di fornire meccanismi di ricerca eterogenei quali la ricerca full-text (la modalità standard dei motori di ricerca Web), l’indicizzazione dei contenuti e la creazione dei file testuali contenenti gli indici, il recupero della locazione degli oggetti restituiti come risultato di una ricerca, etc..

Figura 4.2-1: Index tecnologie utilizzate

24www.doqui.it

• Hibernate È una libreria che permette di rendere persistenti oggetti Java su database relazionali e

di effettuare queries relazionali ottenendo oggetti Java. Appartiene alla categoria degli ORM (Object Relational Mappers) che si occupano, in generale, di mappare il mondo dei databases relazionali con il mondo object-oriented e viceversa. È ormai diventato lo strumento di riferimento per implementare la persistenza delle informazioni tramite Enterprise Java Beans.

• Log4j È una libreria che consente di implementare, in una qualsiasi applicazione Java, un

motore per la gestione dei log che tracciano il funzionamento dell’applicazione stessa. Il fattore probabilmente più importante di Log4j è la capacità di configurare e modificare dinamicamente il comportamento del sistema di log semplicemente modificando un file di configurazione esterno all’applicazione, senza la necessità di riscrivere o ricompilare il codice.

• JCR Il JCR (Java Content Repository) è una libreria Java che consente di implementare e

gestire contenuti secondo lo standard JSR-170. Tramite di queste librerie è possibile specificare il content model del repository e di associare ad ogni oggetto memorizzato nel sistema di content management i relativi metadati. L’utilizzo delle JCR API consente di implementare un repository in grado di comunicare e interfacciarsi con tutti gli strumenti che utilizzano questo standard.

• Cryptix È una libreria che consente di implementare, in un’applicazione Java, operazioni

di crittografia e decrittografia utilizzando sia algoritmi di crittografia simmetrica che asimmetrica

L’accesso al database, da parte dei servizi infrastrutturali avviene tramite l’utilizzo del persistence framework Hibernate che si appoggia alle librerie JDBC (Java Database Connectivity) e JNDI (Java Naming & Directory Interface).

Per l’esecuzione degli ECM Services, dopo attente valutazioni, sui principali strumenti open-source, si è deciso di utilizzare l’application server JBoss (release 4.05 e successive) per le sue caratteristiche di :

• affidabilità;• sicurezza;• aderenza alle specifiche Java Enterprise;• semplicità di gestione;• semplicità di deploy delle applicazioni.

Gli ECM Services sono implementati tramite l’utilizzo di Enterprise Java Bean (EJB) in modo tale da fornire un modello a componenti riutilizzabili che sia il più possibile indipendente dall’application server utilizzato. Per l’esecuzione delle componenti EJB si deve utilizzare un application server conforme alle specifiche Java Enterprise. L’application server scelto garantisce questa compatibilità.

Tramite l’utilizzo di opportuni adapter si possono esporre i servizi, implementati come EJB, tramite tecnologie differenti. Inizialmente i servizi saranno esposti tramite il protocollo C.S.I. (Cooperative Services Infrastructure) che consente di aprire una connessione di rete fra una porta di comunicazione sull’applicazione servente (porta applicativa) e una sull’applicazione chiamante (porta delegata).

È anche prevista l’esposizione dei servizi sul protocollo standard HTTP/SOAP di interoperabilità dei Web services. La necessità di esporre servizi con tecnologie differenti è dettata dalle esigenze

25www.doqui.it

della client application che deve richiamare i servizi dell’ECM Engine e dalla necessità di fornire alla comunità open-source uno o più standard di comunicazione universalmente riconosciuti (es. Web services). Per semplificare il richiamo da parte della client application dei servizi esposti dall’ECM Engine, viene rilasciata una opportuna libreria di interfacciamento che consente il richiamo dei servizi tramite l’utilizzo del pattern Business Delegate.

L’implementazione della componente Web services avviene tramite l’utilizzo del framework AXIS. Tale framework consente una facile implementazione delle interfacce dei servizi e la serializzazione/deserializzazione dei messaggi XML da e verso i datatype di Java.

Il layer degli ECM Application Services Orchestration compone fra loro le chiamate agli ECM Service con lo scopo di implementare servizi di granularità più alta. L’orchestrazione dei servizi avviene tramite la stesura di un workflow, definito in un file XML che verrà eseguito dal framework SvcFlow. Tale framework implementa un semplice motore di workflow basato sulle librerie open-source OSWorkflow di OpenSymphony3.

L’esposizione dei servizi di orchestrazione avviene anch’essa con i protocolli C.S.I. e HTTP/SOAP. Il layer di comunicazione HTTP/SOAP è implementato tramite le componenti AXIS per l’implementazione dello stack SOAP e il Web server Apache per l’implementazione del canale HTTP. Per l’esecuzione di AXIS è necessaria la presenza di un servlet engine standard, in questo progetto si utilizza Apache Tomcat.

Le ECM Application (applicazioni verticali) vengono implementate utilizzando il pattern MVC (model-view-controller) che consente la separazione della logica applicativa in tre layer distinti:

• il layer di presentation logic, che si occupa dell'interazione con l'utente e della generazione della user interface;

• il layer di control logic, che si occupa di controllare il flusso delle operazioni e di eseguire l'elaborazione delle informazioni;

• il layer di data access logic, che si occupa di fornite le funzioni per accedere al database e agli altri sottosistemi applicativi.

Il framework utilizzato per l’implementazione del pattern MVC è Apache Struts. Il vantaggio principale di questo framework è dato dalla semplicità di configurazione, definita all’interno di file XML, della logica di controllo e dell’interazione fra i layer. In alternativa a Struts può essere utilizzato il framework Spring.

Per consentire all’utente finale una maggiore interattività con l’applicazione e per fornire alle applicazioni un look & feel più piacevole ed ergonomico, le applicazioni utilizzeranno le tecnologie AJAX (Asyncronous JavaScript and XML). Il framework grafico utilizzato per l’implementazione di un’interfaccia AJAX è rappresentato dalle RichFaces di JBoss.

Le applicazioni verticali verrano eseguite all’interno dell’application server JBoss.

3 DoQui ECM Applications include software developed by the OpenSymphony Group (http://www.opensymphony.com/).

26www.doqui.it

4.2.2 ArchitetturafisicaLa Figura 4.2-2 rappresenta l’architettura di deploy consigliata per tutte le iniziative al momento disponibili per il prodotto Index.Il deploy suddivide in ambienti separati le applicazioni web (ecmwebconsole) e i servizi orchestranti e applicativi.Nello schema sottostante, si vuole evidenziale la possibilità di scalare l’applicazione istallando le istanze di jboss su server distinti. Nel caso in cui non sia possibile disporre di server distinti per le varie istanze di Jboss è possibile raggrupparle fra loro su una o più macchine fisiche.

Figura 4.2-2: Index architettura di deployment

27www.doqui.it

Per aumentare la scalabilità del sistema è possibile mettere in cluster i singoli application server (Jboss Cluster). I singoli cluster possono essere formati da due o più application server.

Il bilanciamento delle chiamate eseguite dall’utente all’http server avviene tramite il modulo mod_jk di apache. Alla prima richiesta l’utente viene rimappato su uno catena di application server che rimarrà inalterata per tutta la durata della sessione applicativa dell’utente. Solo nel caso di fault di n application server, tale catena viene modificata, in modo da sostituire la macchina in fault con una attiva appartenente allo stesso cluster.

Figura 4.2-3: Index architettura hardware

28www.doqui.it

Componenti funzionali

4.2.3 ECM Engine4.2.3.1 AuditAl fine di garantire il rispetto delle linee guida per l’implementazione di applicazioni in standard SOA, i servizi esposti dall’ECM Engine devono essere servizi riusabili. A tal fine è necessario che all’interno della base dati dell’ECM Engine non si memorizzino dati non di proprietà. Le funzioni di audit implementabili all’interno dell’ECM Engine saranno quindi relative al tracciamento delle sole funzionalità esposte da esso. Non sarà possibile fare gestire all’ECM Engine gli audit ai servizi di orchestrazione implementati dalle ECM Appication. Se esse hanno la necessità di gestire degli audit a livello di servizi di orchestrazione, questi saranno a carico delle singole applicazioni.

4.2.3.2 Gestione di folder virtualiDai test condotti sulle versioni preliminari dell’ECM Engine si è notato un decadimento prestazionale quando il numero di documenti memorizzato in una folder supera le 20000 unità. Esistono dei casi reali che necessitano di memorizzare centinaia di migliaia di documenti all’interno della stessa folder. Per ovviare a questo problema è stato creato un meccanismo per la gestione di folder virtuali. In tal modo, una folder, viene vista dall’utente come un’entità unica con al suo interno centinaia di migliaia di documenti differenti. Fisicamente tale folder viene suddivisa in più folder distinte ognuna delle quali contenente un numero massimo di documenti definibile a build time.

Il meccanismo di gestione delle folder virtuali è completamente trasparente: sia lo sviluppatore delle ECM Application che utilizzano l’ECM Engine, sia agli utenti delle stesse, vedranno solamente la folder virtuale e non avranno nessuna indicazione sul fatto che questa sia suddivisa in due o più folder fisiche. Sono i servizi esposti dall’ECM Engine che provvedono, data in input la folder virtuale, ad indirizzare i comandi sulla folder fisica corrispondente. Ad esempio, quando si esegue una ricerca su una folder virtuale, l’ECM Engine esegue la ricerca su tutte le folder fisiche ad essa corrispondenti e restituisce all’utente l’unione dei risultati di tutte le sottoricerche eseguite.

Figura 4.2-4: ECM Engine splitting dei contenuti

29www.doqui.it

4.2.3.3 Gestione del multirepositoryIn alcuni casi, una ECM Application che utilizza l’ECM Engine, può avere la necessità di gestire più di un repository. Un esempio può essere quello di ACTA dove è necessario avere un repository contenente l’archivio corrente dei contenuti e un secondo repository conenente l’archivio di deposito. Si rende quindi necessario fornire un meccanismo per la gestione della scalabilità orizzontale dei sistema. In fase di istallazione è possibile decidere se si vuole istallare l’ECM Engine in configurazione mono o multi-repository. Nella configurazione mono-repository, ogni istanza dell’ECM Engine dispone di un solo database e di un solo file system: repository differenti hanno ECM Engine differenti. Se una ECM Application deve accedere a repository differenti, l’indirizzamento delle richieste verso un determinato repository è a carico dell’applicazione che deve agganciare l’opportuno ECM Engine (duplicazione del codice di accesso ai repository)

Nella configurazione multi-repository, l’ECM engine può accedere a più coppie database-file system, ognuna delle quali corrisponde ad un repository differente. L’ECM Engine può automaticamente indirizzare i comandi su uno o più repository ad esso associati. In tal caso, se un’ECM Application deve accedere a più repository, non deve preoccuparsi di agganciare ECM Engine differenti. Viene agganciato un unico ECM Engine al quale viene specificato il repository su cui operare.

Figura 4.2-5: ECM Engine – configurazione mono-repository

Figura 4.2-6: ECM Engine – configurazione multi-repository

30www.doqui.it

4.2.3.4 Business ComponentNella piattaforma Index di Figura 4.1-2 l’attenzione è concentrata sugli ECM Engine Services ovvero i library services di Document Management, questi servizi operano sui contenuti memorizzati nello Store del sistema riferito come content repository di Index o JCR Repository.

Pertanto le operazioni ideate hanno sempre come source e target oggetti già stanziati nel repository, in questo modo il repository (lo Store del sistema di ECM) può soddisfare i requisiti di affidabilità, scalabilità e performance richiesti. Le logiche di business più specifiche della gestione dei contenuti (Manage dei contenuti) vengono perciò considerate esterne a questi servizi perché pregiudicano il riuso di Index aumentando la granularità dei servizi (da grana fine a grana medio grossa).

Per accrescere le possibilità di utilizzo delle componenti della piattaforma ci si è posti l’obiettivo di affiancare agli ECM Engine Services componenti che possano far proprie le logiche di business ricorrenti delle ECM Applications rimuovendo così i limiti intrinseci all’ECM Engine. In questo modo le ECM Applications possono trarre vantaggio dall’avere accesso ad un insieme di servizi più ricchi degli attuali library services ed orchestrabili in logica SOA con questi servizi.

Perciò sono in corso di definizione componenti applicative “trasversali” installabili separatamente dalle altre componenti di Index, che possano pubblicare servizi attraverso il protocollo C.S.I. (PA/PD), protocollo jnp (protocollo proprietario di JBoss) piuttosto che attraverso Web Services (Axis, HTTP) ed essere utilizzate all’interno di un’architettura a servizi come indicato nella Figura 4.2-7.

In figura è illustrato il caso del business component DROID (vedi par. successivo), i cui servizi saranno acceduti dalla componente Acta Orchestrazione. I servizi di DROID possono essere acceduti anche da servizi o da applicazioni Web installate su altri application server o altre istanza di JBoss.

Figura 4.2-7: Index Business Component

31www.doqui.it

4.2.3.5 DROIDLo standard MoReq [6] richiede la valorizzazione dei metadati file_format e file_format_version secondo quanto stabilito dal PRONOM technical registry e disponibile sul sito del TNA (The National Archives, UK government records and information management). In sostanza si tratta di utilizzare una libreria software rilasciata dal progetto DROID (Digital Record Object Identification) di PRONOM che fa questo lavoro sulla base di quanto disponibile in un public registry gestito da PRONOM stesso.

La valutazione empirica della tipologia di documento avviene ricercando delle firme (signature) all’interno del file che consentono la sua individuazione in modo univoco e contestualmente alla presenza di informazioni esterne (quali l’estensione del file) per migliorare la qualità del riconoscimento.

I servizi possono essere utilizzati da Acta o da un altro client che debba fornire indicazioni all’utente sul formato di un file da archiviare in termini di riferimenti a versioni precedenti e successive del formato, descrizione, MIME types, codifica, creatore, ecc.. Il dato più importante rimane comunque il PRONOM Persistent Unique Identifier (PUID) che identifica il formato al livello più specifico possibile di granularità e di cui TNA garantisce univocità, persistenza ed un’ambiguità nel tempo.

4.3 Servizi applicativi

4.3.1 ECM Engine ServicesLe funzionalità esposte dagli ECM Services sono raggruppate in tre servizi distinti e complementari fra loro:

• Management Servizio che espone le funzionalità di gestione degli oggetti da memorizzare quali

“Inserimento contenuti”, “Modifica dati”, “Creazione oggetti archivistici”. Particolare attenzione deve essere posta alle funzionalità di check-in/check-out che consentono la gestione dei change sui contenuti.

• Search Servizio che espone le funzionalità per la ricerca dei contenuti memorizzati nei repository

documentali quali “Ricerca globale”, “RicercaXPATH”, “Ricerca delle associazioni di oggetti”, “Ricerca puntuale sui nodi”

• Back-office Servizio che espone le funzionalità necessarie alla creazione degli utenti e dei gruppi

necessarie per eseguire il match fra le utenze gestite dalle client application con quelle gestite dalla componente di sicurezza interna dell’ECM Engine.

Le operazioni esposte dagli ECM Services sono richiamate dalle client application tramite la creazione di opportuni servizi di orchestrazione.

4.3.1.1 Management FeaturesPer management si intende gestione dei contenuti e delle strutture aggregative gestite da un JCR Repository.Le funzionalità esposte da tale servizio sono quelle ipoteticamente utilizzate da un’applicazione per le funzionalità CUD (create/update/delete):

• creazione contenuti;• creazione strutture aggregative;• inserimento di contenuti in strutture aggregative;• modifica di metadati;• modifica contenuti;• lettura contenuti;• lettura e navigazione strutture aggregative;

32www.doqui.it

• eliminazione di contenuti;• eliminazione di strutture aggregative;• copia di contenuti;• copia di strutture aggregative;

Nello stesso servizio di management sono presenti funzionalità di gestione di checkin/chekout dei contenuti necessari per la gestione del versioning delle modifiche dei contenuti e dei metadati ad essi associati.

• check-in sui contenuti;• check-out sui contenuti;• revert sui contenuti.

Sono presenti esposizione di servizi per l’estrazione di dati inseriti dal servizio di audit trail della componente ecmengine.

Sono pubblicati servizi di archiviazione di contenuti. Con archiviazione si intende spostamento da archivio corrente ad archivio di deposito:

• spostamento di strutture aggregative;• spostamento di contenuti.

Sono pubblicati servizi di gestione di contenuti criptati:• inserimento di contenuti criptati;• cripting dei dati attraverso algoritmi gestiti dalla libreria cryptix;• controllo di contenuti criptati.

Sono pubblicati servizi di workflow (un workflow approvativo):• inizio/fine di un workflow approvativi;• approvazione e scarto di un contenuto sul workflow approvativo.

Sono pubblicati un servizio di trasformazione di contenuti

4.3.1.2 Search FeaturesLe funzionalità esposte possono essere riassunte con quelle della lettera R (research) di un verticale di tipologia CRUD:

• ricerca per metadati (es. tutti i contenuti);• ricerca full text;• ricerca per query arbitrarie (specificate dal fruitore);• ricerca per path (es. tutti i contenuti al di sotto di un folder);• ricerca puntuale per identificativo del nodo (getUid, nodeExists).

4.3.1.3BackofficeFeaturesLe principali operazioni esposte dal servizio di backoffice sono quelle che verranno utilizzate dall’interfaccia di amministrazione implemementata dalle componenti ecmwebconsolesrv per l’orchestrazione di tali servizi e ecmwebconsole per la pubblicazione web di tali funzionalità:

• gestione utenti (creazione/modifica/eliminazione utenti);• gestione gruppi (creazione/modifica/eliminazione gruppi).

Funzionalità di dati riguardanti utenti/gruppi:• lista utenti;• lista gruppi.

Funzionalità gestione delle ACL (access control list):• gestione ACL su un nodo (creazione/modifica/eliminazione ACL);• gestione ereditarietà delle ACL.

33www.doqui.it

Funzionalità di controllo sull’integrità del repository come ad esempio la presenza di nodi non più referenziati da altri nodi.

Funzionalità di pubblicazione di caratteristiche del sistema su cui è stata dispiegata la piattaforma ECM engine.

5. Pattern, framework utilizzati

5.1 Pattern DAO

Al fine di disaccoppiare la logica di business implementata nei servizi dalla logica di accesso ai dati si utilizza il pattern DAO. Il disaccoppiamento si ottiene spostando la logica di accesso ai dati dai componenti di business ad una classe DAO. In tal modo si rendono gli EJB indipendenti dalla tecnologia utilizzata per la gestione della persistenza dei dati.

L'idea del pattern DAO si basa sulla possibilità di concentrare il codice per l'accesso al sistema di persistenza in una classe che si occupa di gestire la logica di accesso ai dati. Ad esempio nel caso di un accesso a DBMS si inserisce nel DAO tutto il codice per effettuare operazioni sulla base dati, nascondendo l’implementazione del JDBC.

In generale, il funzionamento del pattern DAO è descritto dal seguente sequence diagram:

Figura 5.1-1: Pattern DAO

34www.doqui.it

5.2 Pattern Business Delegate

Si utilizza questo pattern per disaccoppiare l'accesso ai servizi di business dai client, nascondendo e centralizzando le operazioni di localizzazione e utilizzo del servizio di business. L’utilizzo del pattern Business Delegate ha i seguenti vantaggi:

• fornisce un'interfaccia di richiamo univoca alle client application;• riduce l'accoppiamento tra presentation tier e business tier;• nasconde, centralizza e gestisce le problematiche di reperimento (lookup + create) e

utilizzo dei componenti di business;• centralizza le modifiche derivanti dalla variazione dei servizi di business in una sola classe;• riduce il numero di interazioni remote fra le componenti connesse in rete, con

conseguente miglioramento delle prestazioni;• garantisce la possibilità di trasformare eccezioni tecnologiche (es: java.rmi.

RemoteException) in eccezioni applicative;• consente l’utilizzo di meccanismi di caching.

L’applicazione del pattern richiede l’implementazione di una classe Java che ha il compito di interfacciare gli oggetti di business disaccoppiando la loro implementazione dalle classi che ne eseguono il richiamo. Il modello dati (minimale) è descritto dal seguente diagramma:

Il funzionamento base del pattern Business Delegate è descritto dal seguente sequence diagram:

Figura 5.2-1: Pattern Business Delegate (modello dati)

Figura 5.2-2: Pattern Business Delegate (sequence diagram)

35www.doqui.it

5.3 Framework C.S.I.

Il framework C.S.I. (Cooperative Services Infrastructure), conosciuta pure come PA/PD, è un insieme di standard, protocolli e librerie atti a consentire la comunicazione e l’interscambio di informazioni fra servizi e applicazioni realizzate con tecnologie eterogenee ed eseguite su sistemi informativi eterogenei. Il framework implementa le linee guida rilasciate dal CNIPA per la realizzazione di applicazioni in cooperazione applicativa [3] e fa uso di protocolli standard.La disponibilità di adattatori appositamente sviluppati su piattaforme eterogenee consente di interoperare con differenti tecnologie non legate a Java quali PHP, Perl, ASP.

L’evoluzione del connettore ha permesso di introdurre la comunicazione asincrona e di centralizzare aspetti infrastrutturali comuni: tracing, sicurezza, monitoraggio, protocolli aggiuntivi.

Le caratteristiche del framework sono le seguenti:• descrivere l’interfaccia esposta dalla porta applicativa in un formalismo indipendente

dal linguaggio di programmazione utilizzato (tag XML);• esporre servizi tramite l’apertura di una porta di comunicazione su socket TCP/IP (porta

applicativa);• richiamo dei servizi e notifica delle risposte tramite l’utilizzo di una porta delegata;• protezione del canale di comunicazione;• utilizzo di diversi protocolli di messaging incapsulati all’interno del protocollo PA/PD (ad

esempio è possibile incapsulare dei messaggi SOAP all’interno di trasmissioni PA/PD);• creazione automatica dei proxy di interfacciamento ai servizi per i principali linguaggi di

programmazione (Java, Visual Basic, .NET) a partire dalla descrizione dell’interfaccia;• possibilità di richiamare servizi sia in modalità sincrona che asincrona.

I protocolli supportati da C.S.I. sono i seguenti:

Figura 5.3-1: C.S.I. protocolli supportati

36www.doqui.it

5.4 Framework SvcFlow

SvcFlow è una libreria che consente di implementare servizi di orchestrazione tramite la composizione di servizi applicativi e infrastrutturali. La realizzazione di un servizio di orchestazione avviene implementando un workflow che ne descrive le azioni (action), i passi (step) e le funzioni (function). Come base per l’implementazione del motore di esecuzione dei workflow si è fatto uso della componente open source OSWorkflow realizzata da OpenSymphony opportunamente adattata per consentire il richiamo di servizi tramite l’infrastruttura C.S.I. Il workflow viene descritto in un file XML secondo il formalismo definito da OSWorkflow.

I servizi di orchestrazione richiameranno i servizi applicativi e infrastrutturali tramite l’implementazione locale di un handler di interfacciamento. L’handler ha lo scopo di disaccoppiare i servizi richiamati dall’applicazione fruitrice e consente, in caso di necessità, si sostituire un servizio con un altro equivalente senza dover modificare le funzioni interne della stessa (se si mantiene la stessa interfaccia fra l’handler e l’applicazione). É pure possibile invocare metodi di classi locali.

L’handler si occuperà pure di eseguire un binding dinamico con il servizio disaccoppiando lo stesso dalla sua locazione fisica.I pattern di workflow forniti da SvcFlow comprendono:

• esecuzione sequenziale di più step,• esecuzione ciclica di una porzione del workflow,• esecuzione di test condizionali per selezionare rami differenti del workflow.

I servizi di orchestrazione vengono implementati come EJB Sessione Stateless ed esporranno a loro volta una o più operazioni che saranno accessibili alle applicazioni tramite il protocollo PA/PD.

Figura 5.4-1: SvcFlow invocazione di metodi di classi locali

Figura 5.4-2: SvcFlow architettura logica

37www.doqui.it

Il blocco OSW Engine costituisce il motore centrale del servizio di orchestrazione in quanto esegue il workflow che gli viene passato in input, processando gli step ed eseguendo le funzioni, le azioni e le condizioni contenute al suo interno, ed intercetta le eventuali eccezioni restituite. Il descrittore di workflow contiene anche la definizione degli handler da utilizzare e del file di porta delegata del servizio che l’handler dovrà invocare. Ogni handler gestisce la chiamata ad un servizio, appoggiandosi al ServiceManager per leggere il file di porta delegata del servizio ed instanziare la porta delegata stessa.Ad ogni servizio orchestrato è associato un descrittore XML di workflow.I Servizi di Orchestrazione risultano quindi essere sequenze di esecuzione condizionata esposti come servizi i cui nodi sono interfacce verso Servizi Applicativi. I nodi della sequenza condizionata sono implementati e visti come Java Client (Handler) rispetto ai servizi applicativi.La possibilità è quella di avere una doppia esposizione dei servizi di Orchestrazione sia tramite PA/PD che come Web services tramite Front Adapter. 5.5 ECM Application - WDK

Sulla base dei layer individuati in Figura 2.1-1 il WDK (Web Development Kit) di Index è costituito da componenti dinamici Web 2.0 e da Visual Design Patterns specifici per le ECM Application ed accessibili così da poter essere riutilizzati nel contesto PA.I componenti dinamici di cui si compone il kit ad oggi sono:

Data TableLa DataTable è un widget che permette di visualizzare i dati secondo una struttura a griglia costituita da righe e colonne, le principali caratteristiche sono:• colonne con dimensioni differenti fra loro e celle con dimensioni indicate in percentuale o

con valore assoluto in pixel;• righe visualizzabili con 2 colori alternativamente, un colore per le righe pari e l’altro per le

dispari;• stile di ciascuna cella configurabile applicativamente, per esempio in termini di foreground

color e di background color;• differente immagine per ciascuna riga configurabile applicativamente;ù• possibilità di inserire all’interno di ogni singola cella button, radio button, check box, icone,

input box, TextTooltip e Calendar;• possibilità di associare alle celle un menu contestuale a comparsa, attivabile al passaggio

del mouse o cliccando sulla cella con il tasto sinistro;• header e di un footer raggruppabili su una o più colonne al cui interno è possibile inserire

del testo;• le celle che contengono testo possono essere espanse in fase di esecuzione (Toggle

Panel).

Sono inoltre disponibili funzionalità di paginazione (bottone avanti, bottone indietro, link numbers, bottone prima pagina, bottone ultima pagina, avanzamento di n pagine alla volta), ordinamento di dati su una specifica colonna, autoselezione per mezzo di check box e combo box.

TreeIl Tree è un widget strutturato con oggetti di tipo nodo dove ogni nodo è collegato ad altri nodi attraverso uno o più rami, un nodo può essere un nodo finale detto foglia o un nodo non finale che contiene al suo interno altri nodi. Le principali caratteristiche sono:• nessuna limitazione sul numero di ramificazioni e di livelli;• ogni nodo non foglia del Tree ha sul lato a sinistra un simbolo personalizzabile che indica se

il nodo è espanso (di default “+”) o collassato (di default “-“);• ad ogni nodo possono essere associati componenti dinamici, link ed eventi;• le icone associate al nodo espanso, nodo collassato, nodo foglia possono essere

graficamente personalizzate;• ogni nodo ha una descrizione sul lato destro dell’icona che lo rappresenta dove al suo

fianco è possibile inserire check box e input box;

38www.doqui.it

• un nodo del Tree può essere spostato da un ramo all’altro del Tree oppure in aree della pagina abilitate mediante Drag&Drop;

• al passaggio del mouse sopra un nodo del Tree è possibile associare un TextTooltip sul cui testo è possibile eseguire la funzionalità di copia-incolla.

SimpleSuggestionBoxIl SimpleSuggestionBox è un widget realizzato tramite un campo di input associati al quale compaiono i possibili suggerimenti e valori proponibili sulla base del testo attualmente inserito. Il funzionamento si innesca a partire dalla i-esima lettera inserita dove i può variare da 1 ad un numero definito e configurabile.

Le voci visualizzate all’interno dell’area di testo vengono presentate in un elenco da cui è possibile selezionare una delle proposte presenti autocompletando l’inserimento in corso.

StructuredSuggestionBoxLa struttura e il comportamento del widget è uguale a quella della SimpleSuggestionBox; a differenza di questo però in fase di visualizzazione viene presentato un elenco che contiene le voci da suggerire con al fianco informazioni aggiuntive organizzate in colonne.

CollapsiblePanelÈ un widget che consente di inserire parti della pagina o altri widget dinamici (vedi Tree) all’interno di un’area con contenuti dinamicamente sovrapponibili e alternativi. Alla prima visualizzazione del CollapsiblePanel compare uno solo degli elementi sovrapposti (elemento in primo piano), mentre per gli altri elementi è presente solo una barra del titolo tramite la quale è possibile mettere in primo piano la relativa area.

All’interno dell’area attualmente visualizzata compaiono automaticamente le barre di scrolling sia orizzontali che verticali.

TextTooltipIl TextTooltip è un’area di testo su più righe a comparsa definibile sulle celle di una DataTable, su una label o su un’immagine di una pagina Web. Le principali caratteristiche sono:• il testo contenuto al suo interno va a capo automaticamente una volta che raggiunge il

bordo destro che delimita l’area del TextTooltip;• il testo contenuto all’interno del TextTooltip può avere dimensioni e stili personalizzabili ed

essere su più righe;• è possibile attivare il TextTooltip tramite il passaggio del mouse su una label o su

un’immagine oppure tramite click del tasto sinistro del mouse;• è possibile selezionare il contenuto del TextTooltip con il mouse ed effettuare il copia e

incolla della selezione.

CalendarÈ un widget composto da un campo di input e da un’icona cliccando sulla quale appare dinamicamente un calendario contenente pulsanti di navigazione, visualizzazione della data selezionata e la griglia dei giorni del mese. I giorni del mese corrente sono disposti per colonne, la prima colonna contiene un numero che indica l’i-esima settimana dell’anno considerato.Il calendario presenta una “(x)” di chiusura della finestra e una label “today” che automaticamente visualizza la data corrente. I pulsanti di navigazione sono:• bottone avanti: permette di andare nel mese successivo rispetto a quello correntemente

visualizzato,• bottone indietro: permette di andare nel mese precedente rispetto a quello correntemente

visualizzato,• bottone avanti 12: permette di andare 12 mesi in avanti rispetto a quello correntemente

visualizzato,• bottone indietro 12: permette di andare 12 mesi indietro rispetto a quello correntemente

visualizzato.

39www.doqui.it

Drag&DropSono inoltre disponibili funzionalità di Drag&Drop di un nodo del Tree verso la DataTable e di un elemento della DataTable verso un nodo del Tree.

Ad un singolo evento di Drop è associabile un solo tipo di azione, per poter gestire modalità differenti contemporaneamente è necessario inserire più aree/icone da cui fare Drag.

Due icone distinte su un elemento del Tree da cui fare Drag impongono due Drop distinti sulla DataTable in termini di azioni associate e viceversa.

Per ogni widget sono state valutate le condizioni di utilizzo con JavaScript disabilitati per essere compliant con le direttive di accessibilità della PA, inoltre si è verificato che all’interno dei browser Microsoft® Internet Explorer e FireFox i widgets siano generati correttamente senza causare errori.

La tecnologia utilizzata per l’implementazione dei componenti dinamici è RichFaces di JBoss, si tratta di una libreria di componenti per JSF (Java Server Faces) corredato di un framework avanzato per integrare semplicemente funzionalità AJAX nello sviluppo di applicazioni enterprise. I componenti di RichFaces sono forniti pronti all’uso per lo sviluppo di applicazioni Web che possono fornire in breve tempo un’interazione innovativa all’utente rispetto a quella di un’applicazione JSF tradizionale.

RichFaces è completamente integrato nel ciclo di vita di JSF, la propria Core library crea funzionalità AJAX in pagine esistenti senza richiedere la scrittura di codice JavaScript o la sostituzione di componenti esistenti, questo per mezzo di programmazione dichiarativa con comandi AJAX e JavaScript autogenerati.RichFaces differisce da altri approcci ad AJAX per essere orientato alla pagina anziché orientato al componente come per i toolkit tradizionali, in questo modo è possibile definire un evento nella pagina che invoca una particolare richiesta ad AJAX così da rendere possibile definire aree della pagina che debbono essere sincronizzate con il JSF Component Tree dopo che la richiesta AJAX è stata processata sul server.

Il diagramma RichFaces request processing flow (Fonte JBoss Labs: Basic concepts of the RichFaces Framework) mostra il flusso di lavorazione della richiesta.

40www.doqui.it

6. Glossario dei termini

Termine Descrizione

Acta È la componente applicativa che rende disponibili le funzioni informa-tizzate per la gestione documentale (anche elettronica) delle pubbli-che amministrazioni piemontesi, che si basa sulla piattaforma tecno-logica Index

Index È il motore di gestione dei contenuti digitali, basato su un modello in-frastrutturale SOA che rende disponibili servizi di “document manage-ment” riferiti alle più estese soluzioni industriali di “enterprise content management” quali:

• check-in e check-out;• visualizzazione;• accesso (sicurezza e politiche di accesso e protezione);• gestione del versioning;• supporto alla firma digitale e marcatura temporale;• indicizzazione e ricerca (su metadati e “full text retrieval”);• collaboration con funzioni di workflow documentale;• funzioni di trasformazione di formati.

DM Document Management - Tecnologia che consente la gestire un docu-mento, dalla creazione (se è un documento interno) o dall'acquisizio-ne (se è un documento esterno cartaceo), alle modifiche, all'utilizzo, alle copie effettuate, all'archiviazione. Gestisce pure i workflow del ciclo di vita dei documenti e il versioning degli stessi.

DMS Document Management System – sistema informatico per la gestione del document management.

ECM Enterprise Content Management – Gestione dei contenuti a livello aziendale. Comprende sia procedure software che task umani. Per consentire il corretto svolgimento dei suoi compiti di appoggia al DM.

AIIM Enterprise Content Management Association – è l’associazione no profit per eccellenza che si occupa di content management. Opera a livello internazionale ed è indipendente dai vendor.

DOD The Department of Defense (DoD) standard

OSS Open Source Software - Software gratuito rilasciato con tutti i sor-genti in modo che qualsiasi programmatore vi possa apportare delle modifiche a condizione di ridistribuirlo con il codice sorgente. Le mo-dalità di utilizzo e di rilascio del software sono dipendenti dalla licenza open source utilizzata. La licenza più comune è la GPL.

ILM Information Lifecycle Management - comprende le politiche, i pro-cessi, le pratiche e gli strumenti utilizzati per allineare il valore eco-nomico di una informazione con la più appropriata e conveniente infrastruttura di Information and Communications Technology dal momento in cui l'informazione è concepita fino alla sua finale disposi-zione.

ISV Independent Software Vendor – Termine di business che inidca le aziende specializzate nella produzione e nella vendita del software.

41www.doqui.it

OCR Optical Character Recognition - I sistemi di Optical Character Reco-gnition (riconoscimento ottico dei caratteri detti anche OCR) sono programmi dedicati alla conversione di un immagine contenente testo in testo modificabile con un normale programma di videoscrittura. Solitamente le immagini sono acquisite mediante uno scanner.

OSECM Open Source Enterprise Content Management

DROID Digital Record Object Identification – software sviluppato da National Archives che contente di implementare un riconoscimento batch dei formati dei file. Per ridurre i falsi positivi, oltre ad utilizzare le esten-sioni dei file come base per il riconoscimento, ne analizza il contenu-to per ricercare firme specifiche che identificano in modo univoco il formato.

DAO Data Access Objects – termine utilizzato inizialmente per identificare la tecnologia Microsoft di accesso ai dati, si è successivamente evo-luto per indicare meccanismi standard e pattern per lo sviluppo delle componenti di accesso ai database.

CNIPA Il Centro Nazionale per l'Informatica nella Pubblica Amministrazio-ne, è un ente pubblico italiano che opera presso la Presidenza del Consiglio dei Ministri per l'attuazione delle politiche del Ministro per l'Innovazione e le tecnologie, dotato di autonomia tecnica, funzionale, amministrativa, contabile e finanziaria e con indipendenza di giudizio.

WDK Web Development Kit – framework che semplifica lo sviluppo di appli-cazioni web tramite la fornitura di componenti sofware preconfeziona-te per l’implementazione dei controlli standard di una user interface quali tabelle, treeview, text box, button.