Archivio newsletter

 

Invia ad un amico >>

luglio 2011

In questa edizione

freESBee - La porta di dominio regionale

Linux 3.0, la terza era

IE9, campione di placcaggio antimalware

freESBee - La porta di dominio regionale

Nonostante OpenSPCoop rappresenti di fatto una soluzione di riferimento più che robusta per il dispiegamento dell'architettura SPCoop, ci sono vari elementi che suggeriscono l'opportunità di una implementazione alternativa.
Per cominciare, tutte le implementazioni attualmente disponibili dello standard rappresentano sostanzialmente soluzioni ad hoc. Al di fuori delle specifiche funzionali prodotte dal CNIPA ( essenzialmente un elenco di casi d'uso ) non esiste, attualmente, una concettualizzazione condivisa dell'architettura di una porta di dominio SPCoop.
Da queste considerazioni nasce il progetto freESBee,8 condotto dall'Università degli Studi della Basilicata in collaborazione con l'Ufficio Società Informazione della Regione Basilicata. freESBee è una implementazione open source della specifica SPCoop e ICAR pensata per essere alternativa ma interoperabile con OpenSPCoop. Il punto di partenza nello sviluppo di freESBee è stato la rielaborazione dell'architettura della porta di dominio utilizzando un modello concettuale diffuso nei sistemi di messaggistica: gli Enterprise Integration Patterns.Gli Enterprise Integration Patterns (EIP) sono un'applicazione del concetto noto di design pattern ai sistemi di messaggistica. In sintesi, consentono di descrivere le elaborazioni e i percorsi subiti da un messaggio in termini di componenti elementari come “canale”, “endpoint”, “router”,“message enricher” ecc.

In Figura  è illustrata l'architettura di freESBee in termini di EIP, con particolare riferimento ad un profilo di collaborazione sincrono. Nello scenario rappresentato distinguiamo le funzionalità della porta di dominio che invia il messaggio, a sinistra, da quella che riceve il messaggio, raffigurata a destra.

La porta delegata riceve dal SIL un messaggio che viene intercettato da un componente di tipo interceptor che si occupa di filtrare il messaggio e verificare le autorizzazioni. Se il messaggio SOAP possiede le autorizzazioni necessarie, il messaggio viene arricchito da un componente di tipo enricher, con una serie di informazioni dipendenti dall'accordo di servizio.

A questo punto il messaggio è pronto per essere trasformato in una busta e-gov, conforme alle specifiche SPCoop, dal modulo di imbustamento. Nello specifico, il modulo di imbustamento, prima di creare la busta e-gov, esegue le operazioni elementari relative al tracciamento e alla correlazione del messaggio.
Dal lato erogatore, invece, la porta applicativa riceve il messaggio in forma di busta e-gov che,

attraversando il modulo di sbustamento, subisce una trasformazione inversa rispetto a quella vista nella fase di imbustamento. A questo punto il messaggio può essere consegnato al servizio corrispondente che si preoccuperà di analizzare la richiesta ed elaborare la risposta.
In appendice sono disponibili tutti i diagrammi dei pattern relativi a freESBee. Per una descrizione più dettagliata dei singoli componenti rimandiamo al sito http://freesbee.unibas.it.
Sulla base di questa architettura, freESBee è stato implementato utilizzando la libreria Apache Camel, una delle principali implementazioni degli EIP. E' possibile configurare freESBee non solo come porta di dominio, ma anche come NICA. In questo caso freESBee sarà in grado di effettuare le operazioni di routing dei messaggi ricevuti dalle porte di dominio sottostanti.

Rizzi Luigi

Allegati

profilo [jpg]