La crescente diffusione degli ambienti Soa dotati di servizi basati sull'integrazione di applicazioni distribuite e composite ha reso più critici e complicati il monitoring, la gestione e il reporting di tali applicazioni e il service performance management.
Ci sono differenze significative nell'efficacia fra l'amministrazione basata sull'experience dell'utente finale e tutto ciò che va sotto il nome di monitoring end-to-end o runtime.
Come misurare il performance management
All'inizio, era pratica comune dedurre le performance e la disponibilità dell'applicazione controllando le prestazioni dell'infrastruttura. Il passo successivo fu di effettuare controlli e creare report in base alla qualità del lavoro dell'utente finale (tracking e reporting dei tempi di risposta, per esempio) assieme ai tentativi di correlare questi tempi con tutte le informazioni disponibili sulle prestazioni dell'infrastruttura.
Con la transizione delle strutture delle applicazioni verso un insieme dinamico di componenti le predette tecniche risultano sempre meno utili. Monitorando semplicemente i tempi di risposta non si riesce a creare un corretto report dei reali livelli di servizio e quindi non si ha un significativo aiuto nell'identificazione del problema e nella sua risoluzione. Queste tecniche permettono di ottenere un segnale d'allarme quando lo Sla non viene rispettato, ma non possono fornire dati sufficientemente dettagliati per aspetti operativi sempre più critici.
Questo dipende dal fatto che l'implementazione del monitoraggio focalizzato sull'utente finale non fornisce:
- Sufficienti informazioni per localizzare il problema;
- Sufficienti informazioni per effettuare l'analisi;
- Una vista proattiva degli eventi (si ha soltanto una visione a posteriori al problema).
Come risultato si ha un'insoddisfazione dei clienti e una disillusione nell'approccio ai benefici che può comportare la Soa.
Un metodo per risolvere i problemi consisteva nel chiedere alle operation di scegliere, acquistare, integrare e configurare un certo numero di tool indipendenti per acquisire i dati supplementari per avere un controllo proattivo. Al di là di questo, rimane da capire come affrontare la questione di localizzare il problema in un server specifico o in un determinato task runtime.
Il reporting delle performance runtime
Ci sono prodotti destinati al monitoring e il reporting delle performance runtime, fra questi citiamo Wily Intrascope di CA, Intersperse di Tidal software e Application Performance Management di Symantec Questi sono stati progettati per:
- Fornire informazioni sufficienti per localizzare il problema;
- Individuare il problema non soltanto in un server ma spesso in specifiche componenti o risorse all'interno di tale server;
- Permettere l'analisi correlata dei sintomi per identificare la soluzione;
- Fornire un alerting proattivo sulla base dell'analisi dei trend delle risorse utilizzate e delle prestazioni dei componenti.
Non esiste una soluzione perfetta perché il numero di funzionalità dei tool e il livello di integrazione richiesti variano da fornitore a fornitore. Per esempio, tracciare le prestazioni di un particolare aspetto di un processo di business o un'interazione con l'utente finale a livello di componente da server a server o da server a database di back-end può essere utile soltanto se usate lo stesso tipo di server in ogni punto del percorso..
Altri prodotti, come QuickVision 7 di ClearApp, forniscono una traccia che si sgancia dal sistema e segue le performance delle interazioni con l'utente dal front end ai server EJB di back-end. Prodotti ancora differenti, come le recenti versioni di Intershere di Tidal Software, permettono di eseguire tracciature attraverso sistemi più sofisticati, come quelli che includono portali e componenti, e anche tramite motori di Bpm, quale WebLogic Integration, e attraverso i livelli di messaging, come un JMS.
Conclusioni
La capacità di monitoring e management attraverso "silos" funzionali e tecnologici diventerà sempre più critica con il proliferare delle Soa. Le organizzazioni che otterranno la giusta combinazione trarranno grandi vantaggi dalle Service Oriented Architecture. Un risultato del tutto differente avranno quelle realtà che invece vedono nelle Soa semplicemente un'altra "moda" del mondo del computing.
Ecco alcuni punti da tenere presente per evitare di essere nel gruppo degli ultimi:
- Informatevi circa il runtime e il monitoring end-to-end in modo da essere preparati a gestire proattivamente i deployment delle SOA sin dall'inizio.
- Valutate tutti gli livelli, i server e i protocolli che supportate per evitare di dover poi comprare costosi e difficili add-on che necessitano framework di integrazione.
- Cercate tool in grado di soddisfare le esigenze di un intero team di supporto delle Sia, compreso lo staff operativo e gli amministratori dell'infrastruttura della Soa, così come gli sviluppatori che devono tradurre le logiche di business.
- Ogni soluzione scelta dovrebbe essere progettata per un facile deployment e non dovrebbe essere invasiva.
