MokaByte Numero 12 - Ottobre 1997

 
JMAPI: Network 
Management con Java
di
Andrea Sappia
Analizziamo alcune tecnologie per la gestione di rete basata su Web, concentrando maggiormente l'attenzione sulle Java Management API 

 





Il Web-based network management prevede l'utilizzo di server e browser HTTP per "gestire i dispositivi di rete", cioè per fornire informazioni statiche, dinamiche ed interattive relative alla gestione dei dispositivi e delle applicazioni che sono presenti sulla rete.



 
 

Il World Wide Web (WWW) si è imposto come nuovo paradigma per l’accesso e la presentazione dell’informazione, diventando il metodo preferito per accedere ai dati comuni delle reti locali. L’aspetto dell’informazione semplice e graficamente accattivante e la facilità di collegamento delle risorse di informazione tra loro inerenti ha portato il web browser su quasi ogni desktop connesso alla rete. La realtà odierna vede il desktop come mezzo di navigazione all’interno della rete ed il web browser è diventato l’interfaccia per la consultazione dei dati comuni. I dati per la gestione e la configurazione della rete e dei suoi dispositivi non sono altro che un ulteriore insieme di informazioni comuni che stanno diventando accessibili tramite il web.
 

Gestione della rete basata su web

Negli anni ’80 praticamente tutti i dispositivi di rete avevano una porta a cui era possibile collegare terminali VT100; la maggior parte di essi implementavano anche uno stack TCP per permettere l’accesso remoto alla console. Negli anni ’90 il web browser ha sostituito il terminale VT100. Infatti molte compagnie utilizzano web site interni per presentare lo stato della rete e informazioni riguardo le prestazioni ad un "pubblico" molto ampio, mentre prima questi dati erano dominio di poche persone (gli amministratori della rete e dei sistemi) le quali si occupavano di realizzare report che poi venivano diffusi presso gli utenti della rete.

Proprio per questi motivi l’interesse verso lo sviluppo di software di gestione basato su Web è molto cresciuto negli ultimi tempi; a dimostrazione di ciò è sufficiente citare alcune compagnie che hanno rilasciato o stanno sviluppando pacchetti di questo tipo: Hewlett-Packard, 3Com, Tektronix, Cisco Systems sono solo alcuni dei nomi più noti. In particolare HP ha rilasciato una versione web-based del suo già noto JetAdmin, il software di gestione dei dispositivi di rete quali stampanti o scanner; Web JetAdmin (così è stato chiamato questo pacchetto) è disponibile free sulla rete.

Gli approcci basati su web sono molto più economici e permettono un accesso semplificato alle informazioni rispetto a quello offerto dalle piattaforme di gestione standard. È sufficiente pensare al costo che può avere una workstation Unix sulla quale venga installato un sistema di gestione commerciale (sia dal punto di vista dell’acquisto che della manutenzione); per questo motivo molti produttori di applicazioni di gestione stanno cercando di adattare il più velocemente possibile il loro software all’utilizzo tramite web.

Analizziamo ora in breve alcune proposte presentate da gruppi di lavoro o singole compagnie per realizzare la gestione tramite web, per poi soffermarci maggiormente sulle Java Management API (JMAPI) recentemente rilasciate da Sun.

 
HTTP-based SNMP Network Management

La gestione delle risorse della rete per mezzo del protocollo HTTP rende necessaria la presenza di un’applicazione in grado di utilizzare sia il protocollo HTTP che il protocollo SNMP (Simple Network Management Protocol).

A tale fine è possibile seguire due strade differenti:

    estendere i server HTTP standard con applicazioni CGI (Common Gateway Interface);
    creare un'applicazione proxy che permetta di inoltrare richieste SNMP utilizzando il protocollo HTTP.
 La prima soluzione presenta alcuni vantaggi in quanto relativamente semplice da implementare. Il server HTTP infatti tratta il protocollo HTTP in modo trasparente; le applicazioni di gestione della rete basate su un'interfaccia a caratteri possono facilmente essere trasformate in uno stile adatto per pagine Web poiché è semplice arricchire l'output testuale con tag HTML.

La seconda soluzione invece richiede l'implementazione del protocollo HTTP ma offre prestazioni migliori. Infatti i server HTTP di solito offrono interfacce standard come le CGI che permettono l'esecuzione di applicazioni esterne quando viene richiamato un determinato URL (Uniform Resource Locator). Poiché l’esecuzione di una applicazione richiede l’utilizzo di alcune risorse di sistema, le prestazioni degradano in modo proporzionale alla complessità della applicazione CGI che deve essere eseguita.

Inoltre questa seconda soluzione permette agli eventi di rete di essere trattati senza la necessità di dipendere da un'altra applicazione: infatti il proxy può ricevere gli eventi di rete e registrarli, mentre nel caso di una soluzione basata sull'interfaccia CGI, un’applicazione esterna deve ricevere l'evento di rete che poi verrà recuperato tramite un'applicazione CGI. Queste ultime, infatti, non vanno in esecuzione finché non sono richieste dal browser Web.

In ogni caso, qualunque sia il metodo scelto, è necessario stabilire una corrispondenza tra le operazioni di gestione e gli URL, in modo che il browser Web possa richiedere le informazioni di cui ha bisogno.

La soluzione proposta in un Internet Draft dall’IBM potrebbe essere quella di strutturare l’URL nel seguente modo:

 

http://<host>/<protocol>/<operation>/<context>?<parameters>
 
 
dove i 5 elementi dell’URL (che può essere interpretato da qualsiasi server HTTP) sono così definiti:

 

    <host> identifica l'host su cui è installato il server HTTP;
    <protocol> specifica il protocollo utilizzato (SNMP);
    <operation> indica l'operazione di gestione che deve essere eseguita;
    <context> specifica il contesto da usare;
    <parameters> contiene i parametri dell'operazione.

Supponendo di utilizzare appunto il protocollo SNMP avremo:

 

<protocol>: SNMP

<operation>: GET, GETNEXT, SET, TRAP, WALK

<context>: identificatore dell'oggetto che specifica l'attributo MIB

<parameters>: valori addizionali dipendenti dall'operazione che deve essere eseguita

Ad esempio, una possibile richiesta potrebbe essere:

 

http://daisy.esng.dibe.unige.it/SNMP/GET/sysDescr.0?Host=hp720.dibe.unige.it&Community=public
 
Web Based Enterprise Management Standard Effort

Chiaramente Microsoft, Intel e Cisco Systems non sono rimaste inattive e insieme a BMC Software e Compaq hanno proposto uno standard che permetterà agli amministratori di utilizzare i browser Web per la gestione di sistemi, reti e applicazioni. Lo standard WBEM (Web Based Enterprise Management) è aperto a tutta la comunità di costruttori di hardware, ai realizzatori di software e a tutti coloro che si occupano di internetworking. È stato progettato per integrare gli standard preesistenti (Desktop Management Interface per i desktop ed i server, Simple Network Management Protocol per la gestione delle reti, Hypertext Transfer Protocol per la comunicazione su Internet) in un’architettura che possa essere gestita utilizzando solamente un Web browser.

La particolarità di questo effort sta nel fatto che nessuna delle compagnie che lo sponsorizzano è proprietaria dello standard e, anzi, i primi promotori hanno favorito una larga partecipazione industriale per favorire la maggiore diffusione dello standard stesso e perciò accelerare lo sviluppo di applicazioni innovative per la gestione di sistemi e reti.

Lo standard WBEM ha i seguenti vantaggi:

 

Lo standard prevede l’utilizzo di nuove tecnologie legate alla gestione per permettere la modellizzazione dei dati, la loro manipolazione e trasmissione che sono state presentate al comitato IETF (Internet Engineering Task Force) il quale si occupa della standardizzazione degli standard legati ad Internet:

 

Le Java Management API

Parliamo ora finalmente di un ulteriore sistema di gestione interamente basato sul linguaggio di programmazione Java (che in realtà, anche se indirettamente, era già stato coinvolto in precedenza). Sun ha recentemente rilasciato le Java Management API (JMAPI), una raccolta di classi che estendono il linguaggio Java permettendo ai programmatori di sviluppare facilmente applicazioni per la gestione di reti, sistemi e servizi di rete.

Le JMAPI possono essere utilizzate tramite qualsiasi web browser che supporti il Java Development Kit 1.0.2 e le Java Remote Method Invocation (RMI).

Combinando l’utilizzo di Java e delle Java Management API i programmatori che hanno necessità di sviluppare soluzioni per il network management possono ottenere alcuni vantaggi che vanno dall’indipendenza dalle piattaforme (caratteristica principale di qualsiasi programma in Java) alla facilità d’integrazione sia dell’interfaccia grafica che della definizione di oggetti.

Tutti i sistemi di gestione distribuita esistenti si basano sulla presenza di agenti (installati sui dispositivi che devono essere gestiti) che chiaramente sono legati alla versione del software o dell’hardware per cui implementano l’interfaccia di gestione; ogniqualvolta venga aggiunta una particolare caratteristica l’agente deve essere sostituito. Le Java Management API risolvono in modo molto semplice questo problema effettuando un download dinamico delle classi e delle librerie native appropriate su richiesta e direttamente sul dispositivo che deve essere gestito.

Sebbene anche le JMAPI siano dotate di interfacce verso gli agenti SNMP e quindi supportino interamente la gestione basata su questo protocollo, si può dire che si discostino nettamente dagli altri sistemi di gestione, in quanto sono in grado di effettuare le operazioni di gestione servendosi solamente di Java. Chiaramente questo implica sempre la presenza della Virtual Machine sia sul dispositivo gestito che sul sistema utilizzato per la gestione.

 
L’architettura delle JMAPI
La caratteristica fondamentale della Java Management API è la scalabilità verso molti ambienti differenti che viene realizzata tramite due accorgimenti: il componente che permette di gestire un dispositivo è molto piccolo e gli agenti necessari alle operazioni di gestione vengono scaricati ed eseguiti in maniera sicura.

L’architettura di JMAPI prevede tre componenti principali: un Java Enabled Web Browser, detto anche Browser User Interface (BUI), un Admin Runtime Module (ARM) e le Appliances (vedi figura 1).

 


Figura 1: Configurazione JMAPI che prevede un solo Web browser capace di utilizzare Java e due Admin Runtime Modules

 

Il BUI è chiaramente il mezzo attraverso cui vengono inviate le richieste di gestione; queste operazioni possono essere lanciate sia tramite il browser (in maniera interattiva), sia utilizzando un’applicazione a sé stante che può avere un’interfaccia grafica o a linea di comando.

L’ARM è il meccanismo che fornisce alle applicazioni gli oggetti necessari alla gestione, infatti comprende le interfacce verso gli agenti SNMP, i dati gestiti, la connessione ai database (JDBC) e un server HTTP.

Infine le Appliances non sono altro che i dispositivi da gestire; variano dal semplice terminale Java (Java station) fino al Web server o al DNS server. Poiché ognuno di questi dispositivi realizza differenti funzioni per la loro gestione è necessario utilizzare l’ARM e devono avere installato al loro interno un agente JMAPI. Infatti la strategia adottata da JMAPI è di portare la gestione vicino ai dispositivi stessi servendosi di un dynamic downloading degli agenti.

Analizziamo ora più nel dettaglio gli elementi che compongono JMAPI. Si tratta di un sistema intrinsecamente distribuito, perciò uno sviluppatore deve necessariamente sviulppare i componenti relativi a ciascuno dei tre elementi che abbiamo descritto. Quindi devono essere creati applet Java utilizzando le classi rese disponibili dall’Admin View Module (AVM) e dall’Admin Runtime Module (ARM). Inoltre sull’ARM devono essere implementati i cosiddetti agent objects, cioè gli agenti che vengono inviati sui dispositivi da gestire (appliances). In figura 2 vengono visualizzati tutti gli elementi finora descritti e le relazioni che esistono fra loro.
 


Figura 2: Gli elementi e le interfacce che compongono JMAPI

 

Gli elementi che compongono JMAPI utilizzano la Remote Method Invocation (RMI) per effettuare la comunicazione tra macchine differenti, infatti essi richiedono ai processi lanciati su host differenti la capacità di comunicare tra loro.

Il BUI è, come abbiamo già visto, il componente che permette all’amministratore di rete di eseguire processi di configurazione o monitoraggio sui dispositivi. È formato dai seguenti elementi: Admin View Module (AVM), Managed Object Interfaces e Java Enabled Web Browser.

L’AVM è formato da alcune classi che consentono di sviluppare in modo semplice e veloce le interfacce utente e alcune funzionalità dell’applicazione. L’AVM è basata completamente sull’Abstract Window Toolkit (AWT) di Java e perciò totalmente portabile ed indipendente dal sistema grafico utilizzato. Le classi appartenenti all’AVM sono suddivise in tre differenti pacchetti (vedi figura 3) per permettere al programmatore di decidere facilmente quale livello di funzionalità introdurre nel proprio applet. Brevemente diciamo che i tre pacchetti sono: l’AVM Help che fornisce un ambiente di help generalizzato, l’AVM Base che estende le classi dell’AWT per implementare un modello di interfaccia basato sullo stile di navigazione degli ipertesti presenti abitualmente su Web e l’AVM Integration che si pone come unico scopo quello di fornire un’integrazione tra le classi appartenenti all’AVM Base e le Managed Object Interfaces.
 


Figura 3: Il modello di un applet JMAPI

 

Le Managed Object Interfaces si occupano invece della vera e propria gestione remota dei dispositivi e per realizzare questo compito utilizzano le RMI. I Managed Objects vengono usati per creare delle astrazioni dei dispositivi presenti nella rete e derivano dalla classe ManagedObject. Ad esempio per creare una nuova istanza di una classe particolare di oggetti da gestire viene invocato il metodo MOFactory.newObj() che provoca la creazione di una shell dell’oggetto (che può così essere gestito attraverso l’applet) da parte della Managed Object Factory (di cui parleremo più avanti).

L’ARM è l’host che fornisce tre servizi molto importanti: HTTP Server, Managed Object Factory e Database Interface.

Un Web Browser può inviare una richiesta tramite il protocollo HTTP, in forma di URL, per richiamare la pagina iniziale e caricarla. In pratica viene caricata la "home page" del sistema di gestione basata su JMAPI che deve contenere un applet tag che specifichi la prima applet da lanciare per effettuare la gestione e due param tag che identifichi l’host e la porta necessarie alla connessione con il processo chiamato object factory.

Quindi se un utente richiama la seguente URL per mezzo di un Web browser:

 

http://daisy.esng.dibe.unige.it/jmapi/main.html
 
 
il file main.html dovrà almeno contenere queste poche righe:

 

<applet code = MainApplet.class width = 280 height = 280>

<param name = host value = jmapi>

<param name = port value = 4242>

</applet>
 
 

Un secondo servizio molto importante dell’ARM è il Managed Object Factory, un processo che viene lanciato sul server di gestione: le sue interfacce permettono ai vari client di creare nuove istanze degli oggetti o di caricare insiemi di oggetti dal database e sono fornite dalla classe sunw.admin.arm.rmi.MOFactory. Gli oggetti gestiti sono oggetti remoti (RMI) che vengono creati e mantenuti dal Managed Object Factory.

Per effettuare una connessione ad un Managed Object Factory sul server JMAPI è necessario conoscere il nome della macchina su cui è in esecuzione il server e il numero della porta del registry service RMI (cioè nel nostro caso rispettivamente "jmapi" e "4242"). L’applet deve richiamare il metodo:

 

MOFactory.initialize(host, port)

In questo modo viene stabilita una connessione permettendo ai metodi della classe MOFactory di recuperare gli oggetti dal database presente sul server o di istanziare nuovi oggetti.

Un applet JMAPI si serve di tre interfacce per accedere alle istanze degli oggetti gestiti:

 

ManagedObject.addObject()

ManagedObject.deleteObject()

ManagedObject.modifyObject()

Questi metodi realizzano alcune operazioni di fondamentale importanza quali predisporre un transaction context per eseguire le operazioni, predisporre il database ad eventuali aggiornamenti, invocare il metodo perform*Actions() (dove * sta per Add, Delete o Modify) che effettua le operazioni di gestione sui dispositivi, eseguire gli aggiornamenti del database ed infine chiudere il transaction context.

Tutte le istanze di oggetti gestiti ereditano i metodi addObject(), deleteObject() e modifyObject() dalla classe ManagedObject. Questi metodi sono dichiarati come "finali" nella classe ManagedObject e perciò non possono essere ridefiniti dalle sottoclassi.

JMAPI fornisce anche le interfacce per la connessione ad un database che viene utilizzato per memorizzare le definizioni delle classi e gli oggetti gestiti. In questo modo JMAPI risolve alcuni dei problemi fondamentali della gestione di reti molto estese, quali la sicurezza dei dati (il database può fornire i mezzi per definire le autorizzazioni di accesso ai dati e l’autenticazione degli utenti), la gestione delle transazioni, una struttura per la comunicazione ed un ottimizzazione delle prestazioni.
 

Conclusioni

Abbiamo esaminato alcune delle tecnologie per la gestione dei dispositivi di rete che si basano sull’utilizzo del WWW per ottenere un’interfaccia semplice ed immediata che permetta a chiunque di accedere ai dati relativi, ad esempio, alle prestazioni della rete.

Nel caso delle proposte di IBM ("HTTP-based SNMP Network Management") o di Microsoft-Intel ("Web Based Enterprise Management Standard Effort") abbiamo a che fare con tecnologie ancora in fase di studio e perfezionamento e che, quindi, devono essere attentamente esaminate prima di un’eventuale utilizzo stabile.

Per quanto riguarda invece le Java Management API ci troviamo di fronte ad un oggetto quasi totalmente diverso che ha i classici vantaggi più volte sottolineati da Sun (portabilità del software, eliminazione dei problemi legati all’aggiornamento e alla distribuzione del software, sicurezza dei dati e indipendenza dai protocolli) ma che, proprio per il fatto di utilizzare il linguaggio Java, rende obbligatoria la presenza della Virtual Machine sia sul lato server che sul lato client, escludendo in questo modo tutti i dispositivi di costruzione meno recente.

In ogni caso dato che un così grande numero di compagnie si sta interessando all’argomento (con notevole impegno di risorse) è lecito pensare che in futuro le piattaforme di gestione avranno solamente interfacce utente "Web-based". 
 
 
 

 

MokaByte rivista web su Java

MokaByte ricerca nuovi collaboratori
Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@mokabyte.it