2 Proof of Concept Orchestratore - OSCAT

REGIONE TOSCANA
Progettazione, Realizzazione e
Manutenzione di Prodotti Software per
l'innovazione e la semplificazione nella
Pubblica Amministrazione Toscana
Specifiche Tecniche Applicazione Proof Of Concept Orchestratore
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
CONTROLLO DEL DOCUMENTO
Rif. Documento T.A.I.
Numero di Versione
Data del Documento
Autori
20110704CS01
1.3
9 novembre 2011
Redatto da
Revisionato da
Approvato da
Christian Simonelli, Francesco Fornasari, Valerio Grossi
Alessandro Mensini
Eugenio Mattei
Revisioni
1.0 del 20.06.2011
1.1 del 04.07.2011
1.2 del 12.08.2011
1.3 del 09.11.2011
Versione Iniziale
Vari aggiustamenti a testo e figura
Inserimento scenario applicativo Protocollo, STF e Alfresco
Architettura scenario applicativo Protocollo, STF e Alfresco
582818540
Pag. 2 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
SOMMARIO
1
2
Introduzione ................................................................................................................................. 5
1.1
Acronimi ................................................................................................................................ 6
1.2
Pattern Enterprise di Riferimento ......................................................................................... 6
Proof of Concept Orchestratore .................................................................................................. 8
2.1
Processo “Crea Identità” ....................................................................................................... 8
2.2
Processo flusso documentale ................................................................................................ 9
2.3
Architettura software .......................................................................................................... 12
582818540
Pag. 3 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
INDICE DELLE FIGURE
Figura 1: Interazioni tra i diversi livelli architetturali processo “Crea Identità” nel modello
semplificato .......................................................................................................................................... 9
Figura 2: Interazioni tra i diversi livelli architetturali processo “Flusso Documentale” nel modello
semplificato ........................................................................................................................................ 12
Figura 3 : Componenti Software Architettura Semplificata .............................................................. 13
Figura 4: Istanziazione Definizione di Processo ................................................................................. 14
Figura 5: Invocazione servizio asincrono ........................................................................................... 14
Figura 6: Struttura logica di funzionamento ...................................................................................... 15
INDICE DELLE TABELLE
Tabella 1: Acronimi .............................................................................................................................. 6
Tabella 2: Pattern Enterprise di Riferimento ....................................................................................... 7
582818540
Pag. 4 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
1
INTRODUZIONE
L’architettura di riferimento per il progetto della Semplificazione è descritta nel documento
“Progettazione, Realizzazione e Manutenzione di Prodotti Software per l'innovazione e la
semplificazione nella Pubblica Amministrazione Toscana - Specifiche Tecniche Architettura
Software” [rif. 1], la cui versione corrente è la 1.2 dell’11/05/11. L’articolata infrastruttura
software ivi definita non solo definisce componenti e pattern di riferimento per lo sviluppo dei
diversi moduli del progetto “Semplificazione”, ma si propone come modello di riferimento
generale per lo sviluppo dei sistemi informativi basati su architettura SOA di Regione Toscana.
Il presente documento contiene le specifiche tecniche per una semplice applicazione di prova, che
verrà sviluppata col duplice obiettivo di:
 Costituire una “proof-of-concept” per l’architettura di riferimento;
 Fornire, attraverso la disponibilità dei sorgenti sulla piattaforma regionale OSCAT, un
esempio di realizzazione completo e riusabile, a disposizione di tutti gli sviluppatori di
moduli applicativi che si debbano integrare nell’architettura.
Ovviamente l’applicazione “POC” sarà del tutto scarna dal punto di vista funzionale, ma
completa sotto il profilo dell’utilizzo dei principali moduli dell’infrastruttura.
582818540
Pag. 5 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
1.1
Acronimi
Nel resto del documento si fa uso degli acronimi che seguono.
Sigla
ARPA
BPEL
BPM
CART
EAI
ESB
GUI
J2EE
JNDI
JSP
MVC
ORM
QR
RDBMS
REST
RT
SOA
1.2
Acronimo
Autenticazione Ruoli Profili Applicazioni
Business Process Execution Language
Business Process Management
Infrastruttura di Cooperazione Applicativa di Regione Toscana
Enterprise Application Integration
Enterprise Service Bus
Graphical User Interface
Java 2 Enterprise Edition
Java Naming Directory Interface
Java Server Page
Model View Controller
Object Relational Mapper
Quick Response (QR Codes)
Relational Data Base Management System
Representational state transfer
Regione Toscana
Service Oriented Architecture
Tabella 1: Acronimi
Pattern Enterprise di Riferimento
Saranno utilizzati i seguenti pattern enterprise di riferimento (fonte wikipedia):
Sigla
Acronimo
Active Record
Include a data access object within a domain entity
Application Façade
Centralize and aggregate behavior to provide a uniform service layer
Capture Transaction Details
Create database objects, such as triggers and shadow tables, to record changes to all
tables belonging to the transaction
Chain of Responsibility
Avoid coupling the sender of a request to its receiver by allowing more than one
object to handle the request
Coarse Grained Lock
Lock a set of related objects with a single lock
Command
Encapsulate request processing in a separate command object with a common
execution interface
Data Mapper
Implement a mapping layer between objects and the database structure that is used
to move data from one structure to another while keeping them independent
Data-driven Workflow
A workflow that contains tasks whose sequence is determined by the values of data in
the workflow or the system
Domain Model
A set of business objects that represents the entities in a domain and the
582818540
Pag. 6 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
relationships between them
Entity Translator
An object that transforms message data types to business types for requests, and
reverses the transformation for responses
Human Workflow
A workflow that involves tasks performed manually by humans
Implicit Lock
Use framework code to acquire locks on behalf of code that accesses shared
resources
Optimistic Offline Lock
Ensure that changes made by one session do not conflict with changes made by
another session
Pessimistic Offline Lock
Prevent conflicts by forcing a transaction to obtain a lock on data before using it
Query Object
An object that represents a database query
Repository
An in-memory representation of a data source that works with domain entities
Row Data Gateway
An object that acts as a gateway to a single record in a data source
Sequential Workflow
A workflow that contains tasks that follow a sequence, where one task is initiated
after completion of the preceding task
State-driven Workflow
A workflow that contains tasks whose sequence is determined by the state of the
system
Table Data Gateway
An object that acts as a gateway to a table or view in a data source and centralizes all
of the select, insert, update, and delete queries
Table Module
A single component that handles the business logic for all rows in a database table or
view
Transaction Script
Organize the business logic for each transaction in a single procedure, making calls
directly to the database or through a thin database wrapper
Tabella 2: Pattern Enterprise di Riferimento
582818540
Pag. 7 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
2
PROOF OF CONCEPT ORCHESTRATORE
Il paragrafo ha come obiettivo quello di descrivere come verrà realizzato il componente
“orchestratore-test” il cui compito è quello di fornire un sistema di esempio che implementi i
componenti base descritti nel documento “SpecificheTecniche” e che permettano l’esecuzione di
due casi d’uso di esempio.
2.1
Processo “Crea Identità”
Verrà implementato un processo organizzativo simulato “Crea Identità”: dal punto di vista
funzionale il risultato finale del processo è l’inserimento di un’utenza all’interno dei sistemi
informativi aziendali, che si esplica attraverso la creazione di un account di e-mail e una utenza sul
portale Intranet. Come già indicato, l’obiettivo è quello di mostrare come avvengono le interazioni
tra orchestratore ed applicazioni esterne.
Il processo potrà essere istanziato, utilizzando la Jbpm Console, da un operatore appartenente al
gruppo HR.
Il processo eseguirà i seguenti task:
1) Richiesta all’operatore: per mezzo di Form appositamente sviluppato, dei dati anagrafici
dell’identità da Creare (questo task serve a verificare le caratteristiche di gestione di
istanze di processo, anche attraverso human task, di JBPM);
2) Generazione indirizzo email: invocando una applicazione esterna realizzata secondo le
linee guida del cap. 2 di [rif. 1];
3) Creazione dell’utente su Portale Liferay: utilizzando l’indirizzo email precedente creato
(questo task permette di verificare l’integrazione tra orchestratore e applicazione preesistente che offre servizi);
4) Verifica: attraverso regole di eventuali errori nella azione dell’utente (esempio account già
esistente) ed invio mail di notifica opportuna agli utenti appartenenti al gruppo HR: questo
task permette di verificare le funzionalità del rule engine descritto nel cap. 2.1.2 di [rif. 1].
582818540
Pag. 8 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
Business
Process Layer
Component &
Service Layer
Application
Layer
Enterprise Integration
Enterprise Event-Driven
Liferay
Simulatore
Email
Figura 1: Interazioni tra i diversi livelli architetturali processo “Crea Identità” nel modello
semplificato
2.2 Processo flusso documentale
Lo scenario modella un esempio di flusso documentale che coinvolga sistemi informativi
eterogenei in uso in Regione Toscana:
 Alfresco
 Protocollo Informatico (PI)
 Sistema Trasversale di Firma (STF)
Dal punto di vista funzionale, il processo si occuperà di inserire un documento all’interno del
repository documentale Alfresco, di recuperare il documento da Alfresco e di sottometterlo prima
al sistema di PI e successivamente all’STF.
I passi funzionali che si andranno a fare saranno i seguenti:
1) Inserimento del documento in Alfresco: tramite form appositamente sviluppato si andrà a
caricare il documento in Alfresco e quindi a creare l’effettivo nodo documentale nel
repository, utilizzando i servizi esposti dal repository documentale. In risposta Alfresco,
manderà al processo il riferimento al nodo documentale appena creato e che verrà
utilizzato dal processo per recuperare il documento da Alfresco.
2) Creazione del protocollo: il documento caricato in Alfresco verrà mandato
dall’orchestratore al sistema di protocollo (invocazione del servizio ProtocolInsert).
L’invocazione del servizio di protocollo prevede la presenza di alcuni campi obbligatori,
582818540
Pag. 9 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
3)
4)
5)
6)
pertanto l’orchestratore inserirà staticamente delle informazioni costruite ad-hoc per la
dimostrazione.
La risposta del sistema di protocollo (denominata ProtocolloResponse) contiene un record
informativo che riporta gli estremi della registrazione inserita e l’identificativo della
registrazione.
Aggiornamento del nodo documentale in Alfresco: la risposta ottenuta dal sistema di
protocollo, verrà analizzata e servirà per valorizzare i metadati standard previsti da
Alfresco; in altre parole, le informazioni andranno ad aggiornare il campo standard
“descrizione” del nodo documentale.
Non si prevede a questo livello l’estensione del modello dati di Alfresco per una
rappresentazione più corretta delle informazioni ottenute dal sistema di protocollo.
Firma del documento: verranno invocati i servizi esposti dall’STF per applicare la firma al
documento utilizzando l’interfaccia DSS-Interface che maschera la complessità
dell’interazione tra il processo chiamante e l’STF. Sarà cura dell’orchestratore applicare un
certificato di firma; in altre parole, non si prevede di utilizzare l’applet di firma interagendo
con l’utente ed il suo certificato di firma.
Una volta firmato il documento, l’STF restituirà all’orchestratore un identificativo della
transazione di firma.
Recupero documento firmato: tramite l’identificativo della transazione di firma,
l’orchestratore richiama i servizi STF per ottenere le informazioni necessarie che riportano
il risultato dell’operazione di firma ed il riferimento al documento firmato. Il riferimento
verrà utilizzato dal processo per richiedere all’STF il documento firmato.
Upload del documento firmato in Alfresco: una volta ottenuto il documento firmato
dall’STF, l’orchestratore invocherà i servizi di Alfresco per la creazione del nuovo nodo
documentale che conterrà il documento firmato.
582818540
Pag. 10 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
Il processo di orchestrazione prevede quindi l’invocazione dei servizi esposti dai vari sistemi, in
modalità REST o SOAP, per l’implementazione del flusso documentale.
Business
Process Layer
582818540
Pag. 11 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
Component &
Service Layer
Application
Layer
Enterprise Integration
Alfresco
PI
Enterprise Event-Driven
STF
Figura 2: Interazioni tra i diversi livelli architetturali processo “Flusso Documentale” nel modello
semplificato
2.3 Architettura software
Il componente orchestratore-test integrerà al suo interno i seguenti componenti software (Figura
3):
 Drools Guvnor come repository delle definizioni di processo
 jBPMRuntime come motore BPM (Business Process Management) per la gestione dei
processi organizzativi.
 Drools Runtime (rule engine) come motore di regole all’interno di jBPM
 Camel come motore di Enterprise Integration Engine che permetta l’interazione tra
Workflow e risorse esterne
582818540
Pag. 12 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
Figura 3 : Componenti Software Architettura Semplificata
Per spiegare meglio come avvengono le interazioni tra i diversi componenti verranno analizzate le
operazioni che vengono svolte dalla definizione all’esecuzione di un processo di test.
Le applicazioni esterne da integrare verranno inserite e configurate all’intento del sistema EIS
(Camel) utilizzando gli strumenti standard che il prodotto mette a disposizione. Saranno realizzati
componenti custom in modo da permettere la comunicazione tra Camel e jBPM (modalità
asincrona) e tra Camel e Applicazioni. Ad ogni applicazione esterna integrata (Endpoint) in Camel
verrà assegnato un nome univoco associato che verrà utilizzato, nella definizione di un Task del
Workflow, per identificare chi sarà il destinatario della comunicazione.
Una volta definito il processo “Crea Identità”, (utilizzando eclipse) la definizione viene deployata
all’interno del Repository di definizioni (Guvnor), allo stesso modo per il processo di esempio
flusso documentale.
L’utente per istanziare la definizione di processo devo collegarsi alla jBPM Console e selezionare la
definizione “Crea Identità”. I componenti software utilizzati in questa fase sono mostrati in Figura
4.
582818540
Pag. 13 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
Figura 4: Istanziazione Definizione di Processo
Per i task di workflow che hanno bisogno di comunicare con risorse integrate all’interno del
sistema EIS sarà reso disponibile un Handler che consenta la comunicazione con una qualunque
risorsa esterna semplicemente configurando in modo appropriato il nome dell’endpoint da
utilizzare. Lato EIS (Camel) verrà realizzato un Dispatcher che permetta l’inoltro del messaggio
all’endpoint corretto e, dopo l’invocazione dei servizio, metta a disposizione del Workflow i
risultati ottenuti (Figura 5).
Figura 5: Invocazione servizio asincrono
582818540
Pag. 14 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
Per i task che richiedono un’interazione umana (Human Task) verranno realizzate delle Form
specifiche di inserimento dati da integrare all’interno della definizione di processo.
L’applicazione di test verrà rilasciata sotto forma di macchina virtuale già configurata per il
funzionamento del processo di test.
Nella macchina virtuale consegnata, i componenti di Regione Toscana (Sistema di Protocollo e
Sistema Trasversale di Firma) saranno emulati in invocazione mediante opportuni stub. In altre
parole, si andrà a ricreare l’invocazione prevista dai servizi originali, per essere richiamata
dall’orchestratore, ma non verranno eseguite le operazioni che i servizi esposti in Regione Toscana
avrebbero normalmente fatto.
WF
WFi
xi
Drools
guvnor
KB
JBPM
server
Orchestratore
Y(xi)
alfresco
xi
Camel
Y(xi)
firma
JBPM
Console
protocollo
Figura 6: Struttura logica di funzionamento
La Figura 6 riporta la struttura logica del funzionamento della POC_DUE. Per semplicità vengono
evidenziate solo le componenti principali ed il loro ruolo all’interno dell’infrastruttura. Di seguito
vengono descritti in dettaglio i passi principali, dalla definizione all’esecuzione di un workflow:
1. Il passo iniziale prevede la definizione di un workflow (WF). Lo sviluppo può avvenire
attraverso l’uso di designer visuali. Una volta definito il processo, quest’ultimo deve
essere compilato e salvato nella knowledge base (KB) utilizzando Drools Guvnor. La
KB funge da punto di congiunzione tra la definizione del processo e la sua
esecuzione attraverso il workflow engine di jbpm. I processi descritti in questo
documento sono stati sviluppati utilizzando il plug-in per Eclipse incluso nel
pacchetto scaricabile del sito di jbpm (http://www.jboss.org/jbpm). Un tool di
design visuale per processi di business che supporta BPMN2 è incluso anche nella
suite Drools Guvnor.
2. JBPM server è in grado di caricare il processo (e tutte le risorse ad esso associate) ed
istanziarlo (WFi) attraverso la KB di Guvnor. L’interazione tramite l’utente finale e il
582818540
Pag. 15 di 16
TAI SRL
TECNOLOGIE
E APPLICAZIONI
INFORMATICHE
JBPM server avviene tramite la JBPM console. Quest’ultima permette l’esecuzione
del processo e il completamento dei vari task assegnati ad uno specifico user.
3. Una volta istanziato il processo, il workflow engine si occupa dell’esecuzione dei
singoli task inclusi nel flusso. In particolare, dato un task xi che richiede l’utilizzo di
servizi esterni, viene invocato l’Orchestratore. Quest’ultimo serve da tramite tra la
richiesta generica fatta da JBPM server al Orchestratore ed il servizio effettivo
richiesto dal task. È l’Orchestratore che si occupa quindi di invocare Camel con
l’oggetto ricevuto da JBPM server, arricchito da opportune informazioni per
tracciare il risultato.
4. Ricevuto l’oggetto dall’orchestratore è Camel che si occupa di instradare il
messaggio di richiesta alla giusta applicazione e/o servizio. Una volta completato il
task l’applicazione tornerà indietro il risultato Y(xi) a Camel. Successivamente,
attraverso l’orchestratore il risultato ottenuto verrà restituito a JBPM server che
procederà nell’esecuzione dell’eventuale passo successivo previsto in WFi.
5. La componente Orchestratore rappresenta quindi il nodo centrale per permettere la
l’esecuzione del workflow, prevede un interfaccia specifica per JBPM server e
Camel, ed una componente comune che si occupa del passaggio dei parametri tra le
due applicazione in entrambe le direzioni.
582818540
Pag. 16 di 16