MokaByte Numero 06 - Marzo 1997
		ActiveX vs Java
	di Giovanni Puliti

Active X è sicuramente la novità del momento, ed anche se è stata progettata con obiettivi più generici, presenta grandi margini di sviluppo anche nel settore dello sviluppo di applicazioni Client Server in Internet. In questo articolo non verrà riportata in maniera completa la teoria su cui si basa la nuova tecnologia di Microsoft, in parte perché si renderebbe necessario spendere un lungo fiume di parole, in parte perché buona parte degli aspetti di ActiveX esulano dalla programmazione WEB e quindi dalla linea editoriale di MokaByte. Ho pensato quindi di tralasciare questa parte, concentrando l'attenzione su due aspetti molto interessanti per tutti i Javisti: come si possa realizzare una applicazione WEB con ActiveX e quali sono i punti di contatto fra questi due protagonisti del futuro.
Invito tutti coloro che avessero necessità di approfondire ActiveX in maniera più completa, di consultare le classiche referenze web o cartacee, fra cui la serie di articoli pubblicati ultimamente da Infomedia sulla proprie riviste Computer Programming, VBJournal, DEV e Login.
 

Il Visual Basic 5.0 Come prima cosa partiamo da quello che è stato la causa di questo articolo, e cioè il Visual Basic: chi ha avuto modo di provarlo anche per realizzare piccole applicazioni, si sarà reso conto della facilità e velocità con cui si lavora con questo famoso tool: non è questa una osservazione banale, in quanto grazie a questo aspetto Microsoft ha perlomeno vinto una prima battaglia: quella della facilità nello sviluppare applicazioni WEB. Questo gap verrà in poco tempo colmato quando i già ottimi strumenti di sviluppo visuale per Java attualmente disponibili (es Visual Cafe di Symantec) o prossimi venturi (es. il potentissimo OJBuilder di Borland), raggiungeranno la maturità tecnologica.  Client Server L'esecuzione di una applicazione ActiveX si basa, manco a dirlo, su una architettura Client Server, che ormai sta' diventando lo standard imperante.  Un oggetto ActiveX può essere utilizzato solo in un contenitore col quale colloquia durante tutto il suo ciclo di vita, a partire dalla definizioni dei suoi attributi alla modalità operativa. Un contenitore Active X può essere scelto fra una serie svariata di oggetti, a seconda del tipo di applicazione che si intende realizzare: può essere un form in una applicazione EXE, un contenitore Active X, una applicazione o una DLL Active X e anche fra le altra cose un browser abilitato a gestire questo tipo di oggetti. Attualmente Internet Explorer 3.0 ovviamente supporta gli Active X, mentre chi utilizza Netscape 3.0 al momento deve per forza utilizzare alcuni plug-in si cui alcuni prodotti da terze parti di Netscape Corporation, e che verranno incorporati nella prossima versione di questo browser. Vediamo quindi cosa succede quando il nostro programma di navigazione carica una pagina che contiene un oggetto Active X.

Come inserire un oggetto ActiveX in una Pagina HTML Il codice HTML che si deve scrivere per inserire in una pagina WEB un oggetto ActiveX è molto semplice; si tratta di inserie un tag apposito come quando si deve inserie un applet. Ricordo che al momento solo IE 3.01 di Microsoft supporta già di fabbrica tale tecnologia. Il codice da scrivere è una cosa del tipo <OBJECT ID="oggetto" WIDTH= xx WEIGTH=xx> <PARAM NAME="param VALUE="valore">  <PARAM NAME="param VALUE="valore">  <PARAM NAME="param VALUE="valore">  ..............  <PARAM NAME="nome_param VALUE="valore">  </OBJECT>    Come si vede è tutto molto simile a quanto si deve fare per inserire un applet Java.  Il tag <OBJECT> è stato introdotto dal consorzio W3C al fine di unificare il tag Applet introdotto da Sun, il tag EMBED, ed il tag IMG. Ricordo che al momento Netscape non riconosce gli oggetti ActiveX se non attraverso plug-in appositi come ad esempio DocAptive o ScriptAptve.  Un problema ulteriore è derivante dal fatto che nonostante i plug-in, il tag <OBJECT> </OBJECT> non viene riconosciuto da Netscape, il quale usa <EMBED> per tutti gli oggetti incapsualti. Per creare pagine portabili su ogni browser si può usare il trucco di incapsulare <EMBED> dentro <OBJECT> in modo che anche Netscape non abbia problemi. Alcuni editor HTML che preparano il tutto supportano già questa duplice modalità Attenzione a mettere i valori WIDTH e WEIGTH diversi da zero perché Netscape da problemi a riguardo.

Per poter essere eseguito l'oggetto ActiveX viene inserito nella pagina html con un tag particolare (vedi scheda): il browser segue la procedura standard di interrogazione del server http per la visualizzazione del documento ipertestuale, e quando trova il riferimento all'oggetto estraneo, invia una richiesta di servizio al server ActiveX che risiede sulla stessa macchina. Questo secondo tipo di server utilizza per evadere la richiesta la Active Page, contenuta in un normale file di testo, dove è possibile trovare le specifiche dell'oggetto e come questo deve essere gestito.
Una delle successive operazioni che vengono svolte sulla base di quanto scritto nella Active Page, e' il lancio di una specie di setup al volo che installa nel filesystem del computer su cui gira il client (il browser) tutto il software necessario per poter visualizzare il controllo Active X all'interno della pagina html. Il setup on fly esegue una serie di accurati controlli per verificare se eventualmente sulla macchina client non esistano già le risorse necessarie inviando solo quei files assenti od obsoleti rispetto alla versione necessaria per far funzionare il tutto (si presti attenzione a questo passaggio).
A questo punto l'applicazione viene eseguita all'interno della finestra del browser come accade con una normale applet Java alla quale i nostri lettori sicuramente sono abituati.

Ho volutamente saltato un passo intermedio fondamentale in tutta questa procedura, quella riguardo la sicurezza perché ho affrontato questo problema nel proseguo dell'articolo: reputo questo punto fondamentale nella lotta con Java.
Questa breve introduzione a quello che accade dietro una semplice visualizzazione di una pagina html animata seconda la ricetta Microsoft, ci fa subito capire che in realtà le cose non sono poi così semplici e che uno degli inconvenienti principali e' un aumento del traffico in rete. Proprio per gestire questo problema il server WEB di Microsoft già disponibile da qualche tempo, l'Internet Server 3.0, implementa complesse funzionalità di gestione del traffico sempre in una logica Client Server, al fine di ridurre il volume di bit in transito in rete.

Controllo della Sicurezza in ActiveX

Vediamo quindi in dettaglio come viene risolto il problema della sicurezza in questo sistema. La procedura di caricamento dell'applicazione precede uno step intermedio in cui il security manager effettua i controlli necessari per stabilire se l'applicazione é sicura per la macchina client che lo deve eseguire. Per sicurezza si intende lo stesso concetto che viene usato nella teoria del linguaggio Java e la JVM. Per chi fosse nuovo a tali concetti ricorderò che una applicazione che dentro una pagina html viene realmente eseguita sulla macchina su cui gira il browser, per cui non deve eseguire operazioni illecite, o addirittura disastrose, come la formattazione del disco, o pasticciare con gli indirizzi della memoria. Il security manager si limita a verificare se l'applicazione ha il cosidetto marchio di garanzia, ovvero una specie di sigillo elettronico col quale si attesta la sicurezza dell'applicazione. Tale marchio viene rilasciato da società designate a questo compito che dopo aver approfonditamente controllato il codice e le operazione eseguite ne certifica l'eventuale sicurezza.
Il livello di sicurezza con cui il security manager opera è impostabile dall'utente nella finestra di dialogo del browser. (vedi fig)

A questo punto il lettore che segue da vicino Java si chiederà il perché di un sistema tanto macchinoso soprattutto pensando a come la sicurezza viene garantita in Java: per capire il perché di questa differenza bisogna fare un passo indietro considerando quali sono stati i punti di partenza delle rispettive tecnologie.
Java è un progetto nuovo realizzato partendo da zero facendo però tesoro delle esperienze precedenti, come C/C++.
Il progetto Java si è sviluppato avendo bene in mente dove si voleva arrivare percorrendo una strada diritta evitando di implementare certe caratteristiche che già notoriamente portano a terribili complicazioni; si prenda ad esempio l'ereditarietà multipla del C++ che in Java non è presente proprio per evitare l'insorgere di incongruenze. Altro passo fondamentale nel percorso che ha portato a Java, è stato l'evitare di implementare ogni tipo di riferimento ai puntatori di memoria proprio per evitare azzardati accessi ad aree di memoria sia che essi siano voluti o meno. In definitiva con Java si è risolto il problema della sicurezza eliminando tutto ciò che avrebbe potuto essere usato in maniera indebita.
Una applicazione Java è quindi per forza di cose sicura, e se anche qualcuno riuscisse a trovare qualche escamotage per ingannare il compilatore, la JVM rappresenta un ostacolo insormontabile per un programma cattivo.

Per quanto riguarda invece il versante Microsoft le cose sono completamente differenti non potendo fare affidamento su una politica per così dire di restrizioni : Active X é una tecnologia aperta alla risoluzione di ogni tipo di problemi, e quindi si deve poter permettere la massima flessibilità e potenza al programmatore. Se ci si pensa bene anche in Visual Basic dove non esistono i puntatori, è possibile eseguire chiamate a basso livello tramite le API o anche molto più semplicemente danneggiare il file system con chiamate a comandi di sistema.
Si capisce quindi come il meccanismo della certificazione sia l'unico utilizzabile ed anzi può essere visto come un prezzo da pagare per avere a disposizione tutta la libertà di cui si ha bisogno.

Il meccanismo di certificazione oltre al setup on fly che è analizzato in profondità in seguito, stando alla situazione attuale del mondo dell'informatica, specie quella italiana, sia un grave impedimento alla diffusione di massa di ActiveX, visto che il suo diretto concorrente anche se meno flessibile e general purpose rende le cose molto più semplici.
Non reputo che il mondo degli sviluppatori comuni sia infatti eccessivamente favorevole a pagare per la propria certificazione: non sottovaluterei il problema di ingolfamenti burocratici e tempi di attesa, specie se si mettesse di mezzo un qualche ente preposto del nostro paese.
Certo non bisogna dimenticare chi ha dato la luce a questa nuova tecnologia, ed il signor Bill Gates (o come lo chiamano ormai i navigatori italiani "Guglielmo Cancelli") ha al momento la possibilità di influenzare in maniera pesante il mondo dell'informatica mondiale.
Un altro aspetto che secondo me potrebbe frenare almeno per i primi tempi il successo di Active X, é quello legato al cosidetto setup on fly. In realtà l'idea non è nuova ed in fondo abbastanza simile a quella di Sun che con i propri NC (vedi MB di xXXX) ha già da tempo pensato a trasferire il sistema PC in rete. Allo stato delle cose vedo molto difficile il successo di una soluzione ibrida come quella che attualmente è per forza di cose, mentre vedo maggiori possibilità di successo, dal punto di vista tecnologico, dell'affermarsi di una architettura completamente network oriented.
Proprio per questo motivo gli Zero Administration Computer di cui ci ha parlato Giudici nel numero di XXXX di MokaByte, sono stati pensati infatti per essere usati con la presenza di una infrastruttura già esistente e praticamente utilizzabile. Al momento sappiamo invece che queste tecnologie necessitano di larghissime bande di comunicazione per poter essere veramente competitive, e quindi solo nel futuro saranno utilizzabili in modo realistico.

Il setup al volo

Altro punto caldo è il meccanismo del setup on fly col quale si può scaricare in maniera del tutto automatica e trasparente per l'utente, "solo" il software (files) necessario per eseguire l'applicazione ActiveX. durante tale procedimento sulla macchina client vengono scaricati i file che mancano, o che se presenti sono di una versione più vecchia rispetto a quella necessaria.
Questo se da un lato ci permette di avere sempre l'ultima versione aggiornata di una certa DLL, comporta il rischio non tanto remoto di dar luogo a gravi incompatibilità col software già installato sulla macchina client che per così dire subisce il setup via rete: molto spesso infatti ad ognuno di noi è capitato di bloccare un certo applicativo perché faceva uso di una DLL che seppur vecchia faceva bene il suo lavoro, e che è stata rimpiazzata durante la fase di setup (da drive) di un nuovissimo e potentissimo pacchetto. Chiunque lavori con Windows sa quanto sia frequente questo problema, e sa benissimo che anche se banale può dar luogo a problemi non indifferenti. C'é da dire che Microsoft sta investendo grosse energie per rimediare a questo problema, cercando di garantire al proprio software la compatibilità all'indietro, e per dar vita ad un meccanismo di versioning efficace. C'è da scommettere che in un futuro non lontano ci riesca, ma prima che tutto il mondo degli sviluppatori voglia o possa adeguarsi a questa politica, penso che ne passerà di acqua sotto i ponti e/o di bit dentro le fibre ottiche......

Questi aspetti sono solo alcuni di uno scenario molto più complesso in cui sicuramente giocano altri fattori oltre a quello tecnologico. Sappiamo benissimo tutti come il mondo dell'informatica degli ultimi anni abbia visto il successo non del tecnologicamente migliore ma del più astuto e veloce ad adeguarsi ai nuovi scenari che si sono di volta in volta prospettati (vedi Microsoft). Forse ora le cose stanno prendendo un corso diverso e forse il futuro ci riserva una situazione più democratica in cui fra Java ed ActiveX il popolo sceglierà quello che effettivamente riesce a risolvere meglio i problemi reali. Per tutto ciò non credo proprio che si possa fare al momento nessuna previsione, ma anzi l'unica cosa che penso sia utile è seguire gli sviluppi attendendo che le acque si calmino.

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