SOA Governance e Monitoraggio di servizi basato su ESB
â˘
2 gefällt mirâ˘540 views
Plugin per il monitoraggio dei servizi eseguiti on top dell'Enterprise Service Bus eXistBUS
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ăhnlich wie SOA Governance e Monitoraggio di servizi basato su ESB
Ăhnlich wie SOA Governance e Monitoraggio di servizi basato su ESB (20)
SOA Governance e Monitoraggio di servizi basato su ESB
- 1. Candidato: Massimiliano Mattetti SOA Governance e Monitoraggio di Servizi basato su ESB Relatore: Chiar.mo Prof. Ing. Paolo Bellavista Correlatori: Chiar.mo Prof. Ing. Antonio Corradi Dott. Ing. Fabrizio Grisoli A.A. 2010/2011 UniversitĂ degli Studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Tesi di Laurea in Sistemi Distribuiti M
- 2. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Sommario ⢠Introduzione alla Service-Oriented Architecture (SOA) ⢠La SOA Governance ⢠LâEnterprise Service Bus eXistBus ⢠La console di monitoraggio ⢠Risultati dei test ⢠Conclusioni 2
- 3. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Cosâè la SOA? Paradigma architetturale basato sui concetti di: ⢠Servizio ďInsieme di componenti software che implementa una funzionalità ⢠Disaccoppiamento (loosely-coupled) ďCondizione di dipendenza ridotta o assente fra diversi componenti di un sistema distribuito ⢠Alta interoperabilitĂ ďCapacitĂ di sistemi diversi di comunicare fra loro 3
- 4. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Servizio Ă unâastrazione logica delle funzionalitĂ offerte da sistemi fisici 4 Sistemi Fisici Processo di Business
- 5. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Servizio Un Servizio viene formalizzato mediante la definizione di: 1. Unâinterfaccia che ne descrive le funzionalitĂ 2. Un contratto che ne definisce le responsabilitĂ verso chi lo utilizza 5
- 6. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 Università degli studi di Bologna Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Disaccoppiamento Il disaccoppiamento è un elemento fondamentale per aumentare la flessibilità , la scalabilità e la tolleranza ai guasti delle infrastrutture IT. 1. Flessibilità intermediario per la comunicazione fra client e server 2. Scalabilità controllo distribuito 3. Tolleranza ai guasti isolamento dei sistemi 6
- 7. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Alta InteroperabilitĂ 7 Nelle architetture IT enterprise câè la necessitĂ di far comunicare fra loro sistemi altamente eterogenei (applicazioni J2EE, .Net, legacy, DBMS, sistemi di messaging, ecc.) Approccio Punto-Punto Approccio Indiretto
- 8. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 Università degli studi di Bologna Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica La EAI prima della SOA 8 Col tempo presenta: ⢠alti costi di mantenimento ⢠rigidità (applicazioni tightly-coupled) ⢠prestazioni insoddisfacenti (scarsa scalabilità )
- 9. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Enterprise Service Bus 1. Architettura altamente distribuita 2. Gestisce la comunicazione fra i sistemi 3. Garantisce il completo disaccoppiamento ed isolamento dei sistemi 9
- 10. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 Università degli studi di Bologna Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Funzionalità ESB Funzionalità base: ⢠Fornire la connettività ⢠Trasformazione dei messaggi ⢠Routing ⢠Sicurezza Funzionalità accessorie: ⢠Gestione dei servizi (registry + repository) ⢠Monitoraggio e logging ⢠Orchestrazione 10
- 11. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica SOA Governance La Service-Oriented Architecture è oggi il modello architetturale di riferimento per le soluzioni IT aziendali grazie ai benefici promessi in termini di: ⢠Agilità ⢠Flessibilità ⢠Riduzione dei costi Tuttavia questi benefici possono non essere raggiunti se allâadozione della SOA non fa seguito lâapplicazione di una strategia di governo efficace. Tale strategia prende il nome di SOA Governance e definisce tutte le iniziative, sia organizzative che tecnologiche, che devono essere attuate al fine di garantire il successo della SOA. 11
- 12. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Ciclo di vita della SOA Governance 12 Output: - Ruoli e ResponsabilitĂ - Processi - Architettura Input: - Requisiti della Business Unit - Best Practices - Modello organizzativo della SOA - Strategia Aziendale - Evoluzioni Tecnologiche Operations Strategy & Policy Architecture & Lifecycle Usage and Reuse GuideLines SLA and expected Performaces Coordination inside and outside the Coorporation Products and Standards GuideLines Distributed Requirements Coordination Quality assurance Service lifecycle/ provisioning Support and helpdesk Products Configuration Monitoring of SLA System management Budgetting & Prioritization
- 13. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Strategy & Policy 13 Usage and Reuse GuideLines SLA and expected Performaces Coordination inside and outside the Coorporation Budgetting & Prioritization Nelle prime quattro fasi della SOA Governance vengono definiti: 1. Le linee guida per la gestione dei servizi 2. I contratti di Service Level Agreement 3. Il modello di finanziamento dei servizi 4. Le politiche che rafforzano la cooperazione fra i soggetti interessati dalla SOA
- 14. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Architecture & Lifecycle 14 Products and Standards GuideLines Distributed Requirements Coordination Quality assurance Service lifecycle/ provisioning Nelle successive quattro fasi vengono definiti: 1. Gli standard che devono essere utilizzati per lâimplementazione della SOA 2. Le linee guida per una gestione efficace dei requisiti 3. I test che devono essere effettuati al fine di garantire la qualitĂ dei servizi 4. Come gestire il ciclo di vita dei servizi
- 15. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 Università degli studi di Bologna Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Operations 15 Support and helpdesk Products Configuration Monitoring of SLA System management Le ultime quattro fasi della SOA Governance definiscono infine: 1. Chi è il responsabile di un servizio 2. Come effettuare le operazioni di gestione dei servizi a run-time 3. Come configurare i servizi 4. Le metriche che devono essere controllate nella fase di monitoraggio
- 16. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 Università degli studi di Bologna Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Reply Reply è una società di Consulenza, System Integration, Application Management e Business Process Outsourcing. Fondata nel 1997 a Torino, ha sedi in tre nazioni europee ed ha seguito nel corso del tempo una crescita costante sia in termini di fatturato che in numero di dipendenti. 16 Torino Milano Roma Parma Treviso Gßtersloh Dßsseldorf Hamburg Frankfurt Munich Londra
- 17. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica eXistBus eXistBUS è un framework di Enterprise Service Bus (ESB) basato su tecnologia industry standard open (J2EE, XML, Web Services) e modello architetturale SOA, che permette di implementare unâarchitettura di integrazione distribuita orientata ai servizi di business aziendali. ⢠Abilita unâintegrazione âloosely-coupledâ tra sistemi aziendali (intranet) ed extra- aziendali (extranet) utilizzando le piĂš disparate tecnologie e paradigmi di comunicazione (JMS, RMI, SOAP, HTTP, âŚ) ⢠Sfrutta le potenzialitĂ e le funzionalitĂ di gestione delle risorse (ScalabilitĂ , TransazionalitĂ , Alta DisponibilitĂ , Sicurezza) del container J2EE allâinterno del quale viene eseguito ⢠à basato su unâarchitettura a plug-in che permette di estenderne le funzionalitĂ in maniera semplice e rapida ⢠Permette di definire flussi operativi multi-step (workflow) che implementano processi di business aziendale 17
- 18. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Lâarchitettura di eXistBus 18 ⢠Core features â General purpose workflow/routing per la costruzione di workflow complessi che coinvolgono piĂš di due sistemi â Supporto transazioni globali (XA) â Data transformation â Data Crypting/decripting â Data compression â Data aggregation â Statistics â High configurability â EstendibilitĂ tramite plugin â Advanced log facilities ⢠Connectivity â RMI, JMS, JCA, SAP, JDBC, SOAP/HTTP(S) â Le tecnologie in inbound possono essere utilizzate direttamente dalle applicazioni client â Virtual Middleware per lâastrazione dalle tecnologie outbound â Pluggability ⢠Consoles â Econ: editing e gestione configurazione â Workbench: amministrazione e test â Visualizzazione statistiche e produzione report â Accesso sottoposto ad autenticazione â Access control list ⢠Web Services â Definizione delle interfacce dei servizi di business â Generazione automatica dei WSDL â WSDL disponibili on-line per le applicazioni client â Registrazione dei servizi su un UDDI registry esterno od interno â Supporto per protocolli criptati â Access control list per lâaccesso ai servizi
- 19. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 Università degli studi di Bologna Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica I plug-in di eXistBus Un plug-in è un componente software che estende le funzionalità di eXistBus permettendogli di: ⢠interagire con i sistemi esterni (DBMS, code JMS, Web Service, sistemi legacy, ecc.) ⢠effettuare operazioni sui messaggi (validazioni XML, trasformazioni XSLT, estrazione dei dati tramite espressioni XPath, ecc.) La configurazione di un plug-in, come per ogni altro componente in eXistBus, è XML-based. Tra i plug-in ed il core di eXistBus viene frapposto un layer di astrazione detto Virtual Middleware che consente di separare la logica di business dei servizi dalla loro reale implementazione. 19
- 20. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Il Virtual Middleware Il Virtual Middleware non è altro che una gerarchia di interfacce. 20 ⢠Un plug-in deve implementare una delle tre sotto-interfacce di Operation ⢠Lâoperazione effettuata dal plug-in è completamente trasparente al core di eXistBus
- 21. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Il progetto della console di monitoraggio Requisiti Utente: 1. Monitorare i messaggi che eXistBus scambia con i sistemi esterni, sia client che server 2. Consentire lâaccesso ai dati di monitoraggio via Web 21
- 22. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Problematiche 1) Che granularitĂ deve avere il monitoraggio? 22
- 23. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Problematiche (2) 2) Come applicare il monitoraggio ai processi di business? Intercettori: ⢠Sono particolari plug-in di eXistBus che vengono richiamati dallâESB prima o dopo lâinvocazione di un servizio ⢠Hanno accesso ai dati in ingresso o in uscita da un servizio ⢠Possono essere applicati ad un processo di business esistente senza che sia necessario modificarne il workflow 23
- 24. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Intercettori 24
- 25. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Problematiche (3) 3) Come gestire gli errori di esecuzione dei servizi? Il comportamento di default di eXistBus era quello di terminare lâesecuzione del flusso in caso di errore nellâinvocazione di un servizio. Soluzione: modificare il core di eXistBus in modo che il plug-in di monitoraggio applicato allâoutput del servizio possa intercettare lâeccezione restituita prima che il flusso venga terminato. 25
- 26. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Test di carico Tre processi di business di test: 1. Test_CallDB_CallEmail_CallFileWriter: esegue un test su un campo del messaggio contenente la richiesta di servizio ricevuta. In base al valore assunto da questo campo viene: ďEffettuata una query su un database ďInviata unâemail contente il corpo del messaggio ďMemorizzato il corpo del messaggio in un file 2. Test_TrasformazioneXSL_ChiamataWebService: viene applicata una trasformazione XSLT al contenuto del messaggio di ingresso ed il risultato viene poi utilizzato come parametro per lâinvocazione di un Web Service 3. Test_All_System: invoca in cascata i sistemi utilizzati negli altri due processi di business Il test di carico ha previsto lâinvocazione parallela dei 3 processi di business configurati con e senza lâutilizzo del plug-in di monitoraggio. 26
- 27. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Risultati senza il plug-in di monitoraggio 27 Test T.R.M. (ms) Test1 15,3 Test2 23,6 Test3 36,0 Tempo di risposta (ms) Invocazioni dei processi di business Test3 Test1 Test2
- 28. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Risultati con il plug-in di monitoraggio 28 Test T.R.M. (ms) Test1 56,7 Test2 62,7 Test3 87,0 ~ đ ~ đ ~ đ Tempo di risposta (ms) Invocazioni dei processi di business Test3 Test1 Test2
- 29. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica La Web Console 29
- 30. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica La Web Console 30
- 31. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica La Web Console 31
- 32. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Conclusioni ⢠La soluzione di monitoraggio realizzata soddisfa in pieno i requisiti espressi dal cliente sia in termini di funzionalitĂ che di flessibilitĂ di utilizzo ⢠I risultati dei test indicano come il plug-in di monitoraggio riesca ad operare correttamente anche quando il sistema è sottoposto a carichi di lavoro elevati ⢠Unâestensione del lavoro svolto in questa testi potrebbe consistere nellâimplementazione di altre due funzionalitĂ richieste dal cliente: ďRilevare eventuali utilizzi anomali delle risorse di sistema (ram in uso, connessioni TCP attive, livello di utilizzo della CPU, ecc.) da parte dei processi di business ďUtilizzare i dati di monitoraggio per eseguire dei test di non regressione 32
- 33. Massimiliano Mattetti - SOA Governance e Monitoraggio di Servizi basato su ESB Tesi di Laurea - A.A. 2010/2011 UniversitĂ degli studi di Bologna FacoltĂ di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Grazie per lâattenzione 33
Hinweis der Redaktion
- ... ed il titolo della tesi che presento è SOA Governance e Monitoraggio di Servizi basato su Enterprise Service Bus. Questo lavoro di tesi è stato svolto in azienda. In particolare ho effettuato un periodo di stage presso la società Sytel Roma appartenente al gruppo Reply.
- Inizierò con una breve descrizione dei concetti alla base della Service-Oriented Architecture, per poi passare ad analizzare cosâè e che scopo ha la SOA Governance. Introdurrò lâEnterprise Service Bus eXistBus e descriverò il progetto della console di monitoraggio che ho sviluppato per questo ESB. Infine illustrerò i risultati dei test effettuati su questa soluzione di monitoraggio e le conclusioni a cui sono giunto.
- Analizzando le iterazioni fra i diversi sistemi fisici è possibile identificare operazioni logiche ad un piĂš alto livello di astrazione. Queste operazioni corrispondono al concetto di servizio e possono essere utilizzate come unâunitĂ atomica per il design e lâimplementazione di un processo di business.
- La flessibilitĂ si ottiene utilizzando un intermediario per la comunicazione fra client e server, cosĂŹ è infatti possibile effettuare operazioni come il load balancing o il failover in maniera trasparente per il cliente. La scalabilità è frutto del controllo distribuito in quanto un controllo centralizzato rappresenta un collo di bottiglia per le performance dei sistemi distribuiti. Ed infine la tolleranza ai guasti viene garantita tramite lâisolamento dei sistemi, in questo modo il guasto di un sistema non pregiudica lâoperativitĂ degli altri.
- Le architetture IT enterprise sono solitamente composte da sistemi altamente eterogenei. Per consentire la comunicazione fra questi sistemi è possibile seguire due tipi di approcci, uno è lâapproccio punto-punto in cui ogni sistema instaura una connessione diretta con gli altri, ciò comporta però un accoppiamento stretto tra i sistemi e la necessitĂ di predisporre, nel caso peggiore, un numero di adattatori di protocollo pari al numero di connessioni. Oppure, unâaltra possibile soluzione prevede lâutilizzo di un approccio indiretto in cui un intermediario gestisce la comunicazione fra i sistemi. In questo caso non câè un accoppiamento stretto fra gli interlocutori e per ciascun sistema è necessario predisporre un solo adattatore che gli consenta di comunicare con lâintermediario.
- Seguendo lâapproccio punto-punto ciò che si ottiene è unâarchitettura detta casuale. Questo tipo di rete è il risultato della composizione delle diverse soluzioni adottate nel corso degli anni.
- Oggi la soluzione architetturale di riferimento per la SOA è senza dubbio lâEnterprise Service Bus. Ha unâarchitettura altamente distribuita, funge da intermediario per la comunicazione fra i sistemi della rete e ne garantisce il completo disaccoppiamento ed isolamento.
- Le funzionalitĂ base dellâESB sono quelle di fornire la connettivitĂ ai sistemi, effettuare trasformazione dei messaggi da un formato all'altro, effettuare il routing dei messaggi e garantire la sicurezza della comunicazione. Inoltre molto spesso i vendor di questi sistemi forniscono funzionalitĂ accessorie per la gestione dei servizi attraverso tool come registry e repository, per il monitoraggio e il logging e per lâorchestrazione ovvero la possibilitĂ di comporre i servizi in processi di business.
- Una delle principali attivitĂ svolte durante il periodo di stage è stata quella di approfondire la tematica della SOA Governance sia tramite lo studio della letteratura inerente questo argomento, sia attraverso il confronto diretto con personale Reply avente anni di esperienza in materia. La SOA Governance può essere vista come un insieme di fasi che si susseguono in un ciclo senza soluzione di continuitĂ . Questo ciclo riceve in ingresso i Requisiti della Business Unit, le Best Practice, il Modello organizzativo della SOA, la Strategia Aziendale e le Evoluzioni Tecnologiche e fornisce in output i ruoli con le relative responsabilitĂ , i processi che devono essere applicati e le scelte architetturali che devono essere attuate per lâimplementazione della SOA. Andrò adesso a descrivere brevemente le varie fasi di questo ciclo.
- Le prime quattro fasi che ricadono nella categoria cosĂŹ detta di strategy e policy definiscono i principi che guidano lâazienda nella gestione dei servizi. Ad esempio una linea guida fondamentale è quella che stabilisce di verificare se è possibile riutilizzare un servizio esistente prima di crearne uno nuovo. Vengono definiti i contratti di Service Level Agreement, il modello di finanziamento dei servizi e le politiche che rafforzano la cooperazione fra i soggetti interessati dalla SOA.
- Nelle successive quattro fasi vengono definiti gli standard che devono essere utilizzati per lâimplementazione della SOA, le linee guida per una gestione efficace dei requisiti, i test che devono essere effettuati al fine di garantire la qualitĂ dei servizi e come gestire il ciclo di vita dei servizi.
- Come è possibile intuire dal termine Operations, le ultime quattro fasi interessano aspetti operativi della SOA. In particolare vengono definiti i soggetti responsabili di un servizio, come debbano essere effettuate le operazioni di gestione dei servizi a run-time, come questi debbano essere configurati e le metriche che devono essere monitorate a run-time per verificare il rispetto dei livelli di performance stabiliti nei contratti di SLA.
- Come ho detto allâinizio la mia attivitĂ di tesi ha previsto un periodo di stage presso una delle societĂ del gruppo Reply. Reply è unâazienda di consulenza âŚ
- eXistBUS è un framework di Enterprise Service Bus (ESB) realizzato da Reply. Ă basato su standard industriali aperti, utilizza le piĂš disparate tecnologie e paradigmi di comunicazione, sfrutta le funzionalitĂ del container J2EE allâinterno del quale viene eseguito, è basato su unâarchitettura a plug-in che permette di estenderne le funzionalitĂ e consente di definire dei workflow che implementano processi di business aziendale.
- In questa immagine che mostrata lâarchitettura di eXistBus è possibile vedere i diversi protocolli di comunicazione che questo supporta come RMI, JMS, SOAP, le core features come la possibilitĂ di cifrare e decifrare i dati, di trasformarli e di comprimerli. Le console che vengono messe a disposizione per la sua configurazione. E le funzionalitĂ accessorie specifiche per la gestione dei Web Services come ad esempio la generazione automatica dei WSDL ossia dei file che descrivono lâinterfaccia di un Web Service e ne consentono lâinvocazione.
- Il Virtual Middleware non è altro che una gerarchia di interfacce. Un plug-in deve implementare una delle tre sotto-interfacce di Operation e lâoperazione effettuata dal plug-in è completamente trasparente al core di eXistBus in quanto questo si limita ad invocare il metodo perform che contiene la logica di business.
- Conoscere le caratteristiche di eXistBus è un requisito necessario per poter proseguire nella descrizione del lavoro svolto. Oltre allâattivitĂ di ricerca sullo stato dellâarte della SOA Governance durante il periodo di stage ho avuto modo di confrontarmi con una reale problematica di SOA Governance qual è il monitoraggio dei servizi. In particolare questo problema è stato esternato da Poste Italiane che è uno dei principali clienti di Reply. Poste Italiane ha in dotazione lâESB eXistBus e aveva la necessitĂ di monitorare i messaggi che questo scambia con i sistemi esterni, sia client che server, inoltre i dati raccolti dal monitoraggio dovevano essere resi accessibili via Web. A partire da questi requisiti ho realizzato un plug-in di eXistBus che ne estende le funzionalitĂ consentendogli di tenere traccia dei messaggi che vengono scambiati con i sistemi esterni.
- La prima problematica che si è presentata è stata quella di stabilire quale granularitĂ doveva avere il monitoraggio ossia se è necessario monitorare parti di un flusso, i singoli nodi o i singoli servizi. Dato che il cliente richiedeva di controllare le iterazioni con i sistemi esterni, la scelta progettuale che ho fatto è stata quella di applicare il monitoraggio a livello di singoli servizi. Ad esempio nel caso del processo di business mostrato in questa immagine che recupera delle informazioni da un database, le elabora ed in basse al risultato termina il processo o invia unâemail di notifica, il monitoraggio verrebbe applicato ai tre nodi evidenziati.
- La seconda problematica è stata quella di stabilire come applicare il monitoraggio ai processi di business. In questo caso la scelta che ho fatto è stata quella di implementare il sistema di monitoraggio come un intercettore. Gli intercettori sono particolari plug-in di eXistBus che vengono richiamati dallâESB prima o dopo lâinvocazione di un servizio, hanno accesso ai dati in ingresso o in uscita dal sevizio al quale vengono applicati ed inoltre possono essere aggiunti ad un processo di business esistente senza che sia necessario modificarne il flusso di esecuzione. Lâintercettore che ho realizzato estende lâinterfaccia CallOperation del Virtual Middleware e memorizza i dati in ingresso o in uscita al servizio al quale viene applicato in un database.
- Riprendendo lâesempio precedente, è quindi possibili applicare il monitoraggio sia ai dati di input che a quelli di output dei servizi ed inoltre il cliente è libero di scegliere in quali punti del flusso applicare il monitoraggio e in quali no, ad esempio può scegliere di non memorizzare il contenuto dellâemail.
- Il cliente richiedeva inoltre di tenere traccia anche di eventuali errori che si verificassero durante lâesecuzione di un servizio. Il comportamento di default di eXistBus in questi casi era tuttavia quello di terminare lâesecuzione del flusso senza neanche invocare gli eventuali intercettori che seguono il servizio. Per soddisfare il requisito del cliente ho dovuto quindi mettere mano al codice del core di eXistBus e modificarlo in modo che in caso di errore nellâesecuzione di un servizio venga comunque richiamato il plug-in di monitoraggio applicato allâoutput, prima di terminare il flusso.
- Per testare il plug-in sono stati configurati 3 processi di business. Il primo processo esegue un test su un campo del messaggio contenente la richiesta di servizio ed in base al valore assunto da questo campo effettua o una query su un db o invia unâemail contenente il corpo del messaggio oppure memorizza il contenuto del messaggio in un file. Il secondo processo applica una trasformazione XSLT al contenuto del messaggio in ingresso ed il risultato viene utilizzato come parametro per lâinvocazione di un Web Service. Infine lâultimo processo di business invoca in cascata i sistemi utilizzati dagli altri due processi. Il test di carico ha previsto lâinvocazione parallela di questi 3 processi in due scenari. Nel primo la loro configurazione non prevede lâutilizzo del plug-in di monitoraggio, mentre nel secondo si.
- Questo grafico mostra i tempi di risposta delle invocazioni dei tre processi di business configurati senza lâutilizzo del plug-in di monitoraggio, mentre nella tabella a destra vengono riportati i tempi di risposta medi ottenuti per ciascun processo di business.
- Questâaltro grafico mostra invece lâandamento dei tempi di risposta nel caso in cui i tre processi di business utilizzino il plug-in di monitoraggio. Il sistema non ha avuto problemi nel gestire il carico ulteriore generato dal plug-in di monitoraggio e tutte le invocazioni sono andate a buon fine. Si potrebbero avere delle perplessitĂ sul fatto che ci sia stato un aumento consistente dei tempi di esecuzione, tuttavia ciò è dovuto principalmente al fatto che questi processi eseguono operazioni non particolarmente complesse. Ă possibile vedere infatti, dalla tabella a destra, come allâaumentare della complessitĂ del processo di business lâimpatto del monitoraggio tenda ad essere meno evidente ed è ipotizzabile che con processi di business reali, che hanno solitamente un peso computazionale maggiore di quelli utilizzati per i test, lâoverhead generato dal monitoraggio sia se non trascurabile, sicuramente meno rilevante. (se serve esempio Alitalia)
- Questa è lâinterfaccia web che consente lâacceso ai dati di monitoraggio. Ă molto semplice ed è stata realizzata seguendo le indicazioni del cliente. In una tabella vengono mostrati i messaggi scambiati dai tre processi di business,
- e tramite appositi controlli è possibile effettuare delle ricerche su questi dati.
- Le righe in rosso mostrano eventuali errori che si sono verificati durante lâesecuzione di un servizio. Posizionando il cursore del mouse sulla relativa cella viene mostrata la descrizione dellâerrore che si è verificato.
- In conclusione posso dire che la soluzione di monitoraggio realizzata soddisfa in pieno i requisiti espressi dal cliente sia in termini di funzionalitĂ che di flessibilitĂ di utilizzo. I risultati dei test indicano come il plug-in di monitoraggio riesca ad operare correttamente anche quando il sistema è sottoposto a carichi di lavoro elevati. Infine una possibile estensione del lavoro che ho svolto per questa testi potrebbe essere quello in realizzare altre due funzionalitĂ accessorie richieste dal cliente. Una riguarda la possibilitĂ di rilevare eventuali utilizzi anomali delle risorse di sistema da parte dei processi di business, ad esempio dovrebbe essere possibile rilevare che lâutilizzo della cpu ha raggiunto i massimi livelli durante lâesecuzione concorrente di due processi di business, magari perchĂŠ questi vanno in deadlock accedendo ad una risorsa. Lâaltra funzionalitĂ riguarda la possibilitĂ di utilizzare i dati di monitoraggio per eseguire dei test di non regressione, in pratica deve essere possibile rieseguire una richiesta di servizio e verificare che la nuova esecuzione coincida con quella monitorata.