Progetto Reti di Calcolatori-LS
prof. A.Corradi
tutor S.Monti
Service Composition Analysis
Piattaforma di gestione ed analisi statistica di workflow in ambiente J2EE
a cura di:
Gentili Paolo - Gigante Paolo - Simone Michele
Outline
PARTE1: Visione d'insieme di tutto il progetto
Introduzione & Background
Architettura richiesta
Architettura elaborata
PARTE2: Il sottosistema di analisi e persistenza
Caratteristiche generali
Architettura logica
Funzionamento della parte di analisi
Implementazione in ambiente J2EE/JBOSS
Replicazione e Scalabilità: considerazioni
Deployment
Future Work & Conclusioni
2
PARTE 1
Visione d'insieme
di tutto il progetto
Introduzione
Cosa deve fare
gestione workflow:
ricerca workflow disponibili
messa in esecuzione
analisi statistica
presentazione via web
Backgruond
Business Processes
motore JBPM – linguaggi JPDL/BPEL
J2EE/JBOSS
4
Architettura richiesta
Tre moduli principali
Persistenza su DB
Utilizzo della J2EE
EJB
Entity beans
Jboss-SEAM e JSF
Presentazione di
dati grezzi
statistiche
5
Architettura progettata
Layer di Middleware WFMEM
Astrazione Workflow
Ambiente multi-engine
Sistema Distribuito – Motori distribuiti
6
PARTE 2
Il sottosistema di
ANALISI/PERSISTENZA
Caratteristiche
Graph Oriented Design vs Graph Oriented Analysis
statistiche sui nodi
statistiche sui flussi
statistiche sulla composizione
Visione Statica vs Visione Dinamica
statistiche di istanza
statistiche di processo
On-Demand Analysis vs Real-Time Analysis
analisi proattiva
continuo impiego di risorse
intrusione sul processo
Interazione con l'esterno
JMS per la ricezione delle informazioni grezze
EJB Facade verso invocazioni remote
8
Architettura Logica
9
La parte di analisi: L' Analyzer
CASO1: RICHIESTA DI STATISTICHE
Controllo presenza statistiche nel repository
se presenti le ritorna al client
se non presenti
recupera la lista dei services attivi dal ServiceRegistry
invoca il metodo analyze su tutti i services attivi
ogni service memorizza i risultati su db e su repository
le statistiche vengono ritornate al client
CASO2: RICHIESTA DI INFORMAZIONI GREZZE
invocazione del metodo apposito dell'InfoManager
le informazioni grezze vengono ritornate al client
ALTRI CASI D'UTILIZZO
richiesta Services attivi da remoto
attivazione nuovi servizi da remoto
10
La parte di analisi: Considerazioni
Il modulo deve conoscere solo l'ubicazione del db
invocato sia da WFMEM che da WebConsole
Registrazione dinamica di nuovi StatService
Invocazione del metodo installNewService del
ServiceRegistry
Registrazione e mapping automatico dell'entity-bean
Persistenza su DB anche delle statistiche
Aumento efficienza
flag update per statistiche di processo
Recovery da guasti
StatsServices “in cascata” o più in generale “dipendenti” da
Entity-Bean calcolati da altri services
11
Implementazione in Ambiente J2EE/JBOSS
Il problema
In fo Ma n a g e r
( s e s s io n EJB)
S t a t is t ic s
Re p o s it o ry
( s e s s io n EJB)
An a ly z e r
(s e s s io n EJB)
EJB
s e s s io n
s co p e
serviceRegistry
come stateful
singleton
La soluzione
In fo Re c e iv e r
( Me s s a g e D riv e n EJB)
Ap p lica tion
En t it y Ma n a g e r
(Mb e a n S e rv ic e )
JMS Qu e u e
DB
S e rv ic e s
Re g is t ry
(Mb e a n S e rv ic e )
Scop e
(s in g le t on )
JMX ed Mbeans
Service MBean
Altre soluzioni
var statiche
stato sul DB
vantaggi e
svantaggi
12
Deployment
analysis.jar
implementazioni EJBs e MBEANs
datasource file: analysis-ds.xml
contiene l'informazione dell'ubicazione del DB
supporto per i DBMS mysql e hypersonic
sca-common.jar
interfacce remote e classi visibili dall'esterno
entity-bean per trasporto di info grezze e statistche
Eventuali Plug-in contenenti
Implementazione Java dello StatService
Entity-bean calcolato dallo StatService
MBean per registrazione dello StatService
datasource file: plugin-ds.xml
13
Replicazione e Scalabilità: Considerazioni
Più moduli analysis.jar possono coesisitere su più nodi
DB come “Shared Memory” dove recuperare statistiche
già calcolate
Service Registry
attualmente un registry per ogni modulo di analysis.jar
non c'è coordinazione sull'allocazione degli StatServices
Possibile soluzione (Future Work)
coordinatore di StatServices
regola l'attivazione di servizi in ogni ServiceRegistry
il modulo WebConsole conosce solo il coordinatore
14
Conclusioni e Future Work
Conclusioni
Estendibilità
Analisi customizzabile e flessibile
Future Work
Coordinatore degli StatServices
Fault Tolerance
testing su JBOSS clustered
Dipendenza fra Services
Asincronicità fra Analzer e calcolo statistico
Repository come Poll Object
Apertura alla possibilità di fornire analisi real-time
Configurazione via XML
abilitazione scrittura delle statistiche su db
15
FINE