Service Composition Analysis Progetto Reti di Calcolatori-LS prof. A.Corradi tutor S.Monti Piattaforma di gestione ed analisi statistica di workflow in ambiente J2EE a cura di: Gentili Paolo - Gigante Paolo - Simone Michele
2 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
PARTE 1 Visione d'insieme di tutto il progetto
4 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
5 Architettura richiesta Tre moduli principali Persistenza su DB Utilizzo della J2EE EJB Entity beans Jboss-SEAM e JSF Presentazione di dati grezzi statistiche
6 Architettura progettata Layer di Middleware WFMEM Astrazione Workflow Ambiente multi-engine Sistema Distribuito – Motori distribuiti
PARTE 2 Il sottosistema di ANALISI/PERSISTENZA
8 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
9 Architettura Logica
10 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
11 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
12 Implementazione in Ambiente J2EE/JBOSS Il problema serviceRegistry come stateful singleton La soluzione JMX ed Mbeans Service MBean Altre soluzioni var statiche stato sul DB vantaggi e svantaggi
13 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
14 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
15 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
FINE