Newsgroup: it.comp.java
Titolo: Java Management eXtensions: che esperienze avete?

Uhm, non so se è il forum giusto, ma dopotutto è l'unico... Spero ci sia
qualcuno interessato a questi argomenti!
Nella mia azienda scriviamo una quantità abbastanza considerevole di
software che fa da motore per una serie di servizi finanziari offerti via
web: benché i primi anni di sviluppo abbiano portato alla costruzione di un
sistema "abbastanza" stabile, le esigenze di controllo che abbiamo al giorno
d'oggi hanno reso necessario implementare dei sistemi di amministrazione
molto più avanzati di quelli che c'erano prima.
In effetti, il sistema precedente non offriva praticamente funzionalità di
amministrazione a runtime, se non per alcune limitatissime operazioni:
questo perché "ingenuamente" ci si è sempre detti che "un sistema che
funziona bene deve avere il minor bisogno possibile di intervento". Benché
questo possa essere vero (ma è invece opinabile da molti punti di vista), ci
si rende sempre più conto della grandissima quantità di operazioni che
potrebbero essere utili nell'operatività quotidiana: operazioni di
riconfigurazione (dalla modifica di un parametro al riavvio di parti del
sistema senza dover fare ripartire tutto), soprattutto, ma anche operazioni
che intervengono direttamente presso gli utenti (come la possibilità di far
loro comparire un messaggio "custom" in particolari momenti della giornata,
o funzionalità molto più avanzate che arrivano fino all'invocazione di
procedure remote dal nostro server all'applet client degli utenti).
Dopo un po' di ricerche ci è apparso evidente che Lo Strumento per
effettuare questo tipo di implementazioni è JMX: oltre al fatto che è uno
standard, che non è male, ci è parso che avesse un altro vantaggio evidente:
è uno standard SEMPLICE, e questa è una quasi-sicura garanzia di successo,
quando accoppiata ad un livello di funzionalità adeguato. E in effetti
sempre più progetti stanno adottando JMX non solo come infrastruttura di
gestione, ma addirittura come collante architetturale tra i componenti
(JBoss docet): e allora arrivano JRun 4, Tomcat, Resin 3, Weblogic,
Websphere, ecc.: tutti in qualche modo gestibili via JMX.
E in effetti i risultati si vedono subito: in pochi giorni, grazie
all'intervento di una serie di tool eccezionali (Caucho Resin come
application server di sviluppo, IntelliJ IDEA come IDE, XDoclet per
supportare la creazione dei vari file richiesti da JMX, MX4J come server JMX
e MC4J - XtremeJ come client) siamo riusciti a mettere in piedi le prime
funzionalità di management, che hanno subito lasciato piacevolmente di
stucco i nostri amministratori di sistema (che da un giorno all'altro si son
visti comparire, come dicono loro, "una console di amministrazione come
quella di windows": era Eclipse con il plugin xtremej...). Ed il bello è che
è stato necessario fare davvero pochissimo! Per aggiungere la possibilità di
controllare via JMX il metodo di una classe preesistente, è sufficiente
aggiungere un tag @jmx.managed-operation nel suo javadoc, e un tag
@jmx.managed-bean sul javadoc della classe: poco dopo (c'è di mezzo un
ctrl-alt-g per far partire un task di ANT da dentro ad IDEA che genera i
file JMX, e un po' di tempo per lasciare che Resin ricompili tutto il
necessario) ci si ritrova un pulsantino per lanciare quel metodo dalla
console di amministrazione! Stessa cosa con gli attributi, con in più il
fatto che si può dire ai client di fare automaticamente dei grafici,
"campionando" periodicamente il valore di quegli attributi.
Questo ci ha dato un senso di potere sconfinato, e siamo subito partiti a
testa bassa nel creare una struttura di management per tutta l'applicazione.
Dopo un po' ci siamo resi conto di una cosa che probabilmente altri hanno
già considerato in passato: si finisce per creare una struttura "parallela"
di classi e-o interfacce e del codice che fa da collante tra loro, quasi
duplicando il codice che già normalmente "collega" i componenti. Esempio:
abbiamo un componente "ConnectionSet" che fa il round-robin su un insieme di
oggetti Connection. E' naturale creare un MBean per gestire il connectionset
e uno per ogni oggetto connection: ma per fare questo, o meglio, per rendere
gli oggetti connection "navigabili" a partire dall'oggetto connectionset
nella console JMX, si deve scrivere del codice che gestisce la relazione di
contenimento, e duplica (con il server JMX di mezzo) il codice che già c'è
(oggetti connection inseriti in una ArrayList del connectionset, ecc.). Non
stupisce, che progetti come JBoss abbiano finito per fare di JMX il collante
architetturale del server stesso!
Ora, nascono una serie di interrogativi:
1) è davvero opportuno "affidarsi" a JMX per collegare i componenti? il
lookup è un po' laborioso, l'iterazione pure, ma con un po' di lavoro si
ottengono degli "helper" che semplificano tutto.
2) ok: se abbiamo un connectionset che contiene 10 connessioni ai server di
back-end è naturale gestire tutto con JMX. Ma se abbiamo 4895 oggetti
"subscription" (uno per ogni titolo di mercato che è possibile acquistare
con il nostro sistema) che facciamo? Li esportiamo tutti con il server JMX?
E come si fa a navigarci sopra dentro al software client? E' un incubo! E,
ancora, implementazioni open source come MX4J sono abbastanza scalabili, per
gestire questo genere di situazioni?
3) qualcuno ha esperienza di tool - implementazioni - soluzioni in genere
che sfruttano JMX?

 implementazioni - soluzioni in genere che sfruttano JMX?
Su questo, l'unica esperienza pratica che ho e' con JBoss, e finora non ho 
avuto problemi.
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

Non sono purtroppo qualificato sull'argomento per rispondere, ma Simone Bordet
(sviluppatore italiano nel progetto JBoss) che partecipa al JUG Torino ne sa sicuramente
moooolto di piu (da indiscrezioni so che forse presentera' un panel proprio su JMX alla
prossima Java Conference). Ti consiglio quindi di girare la palla anche a lui: se ti e'
possibile coinvolgilo nella discussione sul NG.
Ciao,
    Bruno.
---
| Bruno Bossola 
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola
|
| Membro del JUG Torino - 
http://www.jugtorino.it
| 

 avuto problemi.
Sto coinvolgendo anche le mailing list di mx4j, si vedrà qual è la loro
posizione al riguardo.

 possibile coinvolgilo nella discussione sul NG.
Ah, in effetti ho postato più o meno la stessa domanda sulla lista di mx4j,
in cui credo che Bordet sia un committer (se non addirittura uno degli
architetti principali), quindi (sebbene in inglese :) ) dovrebbe essere
coinvolto nella discussione!

 prossima Java Conference). 
Non essere indiscreto, Bruno
uL


Non lo dirņ a nessuno!