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 laccesso e la presentazione dellinformazione, diventando il metodo preferito per accedere ai dati comuni delle reti locali. Laspetto dellinformazione 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 allinterno della rete ed il web browser è diventato linterfaccia 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 laccesso 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 linteresse 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 dellacquisto che della manutenzione); per questo motivo molti produttori di applicazioni di gestione stanno cercando di adattare il più velocemente possibile il loro software allutilizzo 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 unapplicazione in grado di utilizzare sia il protocollo HTTP che il protocollo SNMP (Simple Network Management Protocol).
A tale fine è possibile seguire due strade differenti:
1. 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é lesecuzione di una applicazione richiede lutilizzo 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, unapplicazione 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 dallIBM potrebbe essere quella di strutturare lURL nel seguente modo:
http://\<host\>/\<protocol\>/\<operation\>/\<context\>?\<parameters\>
dove i 5 elementi dellURL (che può essere interpretato da qualsiasi server HTTP) sono così definiti:
1. \<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 unarchitettura 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:
- scalabilità: lo standard permette ai system administrator di conoscere e sviluppare una sola interfaccia per monitorare e gestire sia i dispositivi di rete sia i mainframe o le workstation;
- unica versione del software per piattaforme di gestione differenti;
- diminuzione dei costi dovuti allinstallazione e configurazione.
Lo standard prevede lutilizzo 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:
- Hypermedia Management Schema (HMMS): un modello estensibile dei dati che rappresenta lambiente gestito;
- Hypermedia Management Protocol (HMMP). un protocollo di comunicazione che incorpora lHMMS e si basa sullHTTP;
- HyperMedia Object Manager (HMOM): una definizione generica per indicare applicazioni di gestione che riuniscono i dati di gestione e utilizzano uno o più protocolli per presentare sul browser una rappresentazione uniforme utilizzando lHTML. HMOM può essere realizzato servendosi delle piattaforme esistenti quali Java, ActiveX, CGI, CORBA.
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 lutilizzo 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 dallindipendenza dalle piattaforme (caratteristica principale di qualsiasi programma in Java) alla facilità dintegrazione sia dellinterfaccia 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 dellhardware per cui implementano linterfaccia di gestione; ogniqualvolta venga aggiunta una particolare caratteristica lagente 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.
Larchitettura 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.
Larchitettura 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).
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 unapplicazione a sé stante che può avere uninterfaccia grafica o a linea di comando.
LARM è 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 lARM 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 dallAdmin View Module (AVM) e dallAdmin Runtime Module (ARM). Inoltre sullARM 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.
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 allamministratore 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.
LAVM è formato da alcune classi che consentono di sviluppare in modo semplice e veloce le interfacce utente e alcune funzionalità dellapplicazione. LAVM è basata completamente sullAbstract Window Toolkit (AWT) di Java e perciò totalmente portabile ed indipendente dal sistema grafico utilizzato. Le classi appartenenti allAVM 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: lAVM Help che fornisce un ambiente di help generalizzato, lAVM Base che estende le classi dellAWT per implementare un modello di interfaccia basato sullo stile di navigazione degli ipertesti presenti abitualmente su Web e lAVM Integration che si pone come unico scopo quello di fornire unintegrazione tra le classi appartenenti allAVM Base e le Managed Object Interfaces.
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 delloggetto (che può così essere gestito attraverso lapplet) da parte della Managed Object Factory (di cui parleremo più avanti).
LARM è lhost 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 lhost 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 dellARM è 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"). Lapplet 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 lautenticazione 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 sullutilizzo del WWW per ottenere uninterfaccia 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 uneventuale 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 allaggiornamento 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 allargomento (con notevole impegno di risorse) è lecito pensare che in futuro le piattaforme di gestione avranno solamente interfacce utente "Web-based".