MokaByte Numero 02 - Novembre 1996
Java Forum
di
Daniela Ruggeri 
 reportage dal forum organizzato da Infomedia tenutosi a Milano lo scorso mese.

 



 
 
Il 25 settembre si è tenuto nell'hotel Ramada di Milano un forum su java organizzato da Edizioni Infomedia S.r.l.. Ospiti di questo forum sono stati i rappresentanti delle seguenti società : 
 
 
 
SUN MICROSYSTEMS. Società madre del linguaggio Java, e creatrice del browser Hotjava, e dell'ambiente di sviluppo Java Workshop interamente scritto in Java
MICROSOFT. Ha presentato vari prodotti tra cui il Visual J++ l'ambiente di sviluppo di Java, Internet Explorer 3.0 browser che include java, per navigare sotto Internet e Active X i cui Active X object possono essere utilizzati direttamente dai programmi java fornendo così un ponte di collegamento tra java e gli altri linguaggi di programmazione.
BORLAND. Società creatrice dell'ambiente di sviluppo Borland Latte.
SYMANTEC. Società creatrice degli ambienti di sviluppo Symantec Café e Visual Café.
SYBASE. Fornitrice dei driver per jdbc del noto database.
IBM. Società che sta investendo in questo linguaggio. Tra le ultime realizzazioni c'è la creazione del pacchetto jdk java per Windows 3.1, e l'inclusione delle librerie java anche nel nuovo sistema operativo Merlin.
COMPUTER ASSOCIATES. 
PARCPLACE DIGITALK. Società creatrice dell'ambiente di sviluppo visuale Pars for Java.
In questa giornata è stata fatta una panoramica sul linguaggio Java e sulle sue possibilità future. 
Si e' iniziato con l'illustrazione generale del linguaggio java e sui motivi che l'ha reso popolare che riassumiamo un po' per uniformità di discorso e un po' perché c'è sempre qualcuno che non ha ancora approfondito questo linguaggio, ce ne scusino i più esperti :
E' indipendente dalla piattaforma

Il suo codice in bytecode non ha bisogno di essere ricompilato nel passaggio da una piattaforma all'altra.

Nella tecnologia Client/Server, java è il primo linguaggio il cui codice bytecode ha la caratteristica di essere trasferito dal server al client per essere trasformato in eseguibile ed eseguito direttamente sul Client, con sgravio di lavoro per il Server. Inoltre, qualora ce ne fosse la necessità, assieme al codice java possono essere trasferiti anche pezzi di software per far funzionare determinate utilità (per esempio driver audio per far ascoltare suoni).

E' l'unico linguaggio fornito di una sorta di "controllore" (Java Virtual Machine) che tra i vari compiti ha quello di preoccuparsi della sicurezza dei dati che viaggiano sulla rete.

Non supporta l'aritmetica dei puntatori impedendo la modifica dinamica dei puntatori e e costringendo quindi il programmatore a definire sempre in anticipo le dimensioni degli array. In questo modo si impedisce che gli indici se ne vadano in giro per la memoria finendo nelle aree di sistema.

E' fornita di routines di "Garbage Collection" che si preoccupano di liberare dalla memoria le variabili che sono state definite e che il programmatore si è "dimenticato" di rilasciare (succede molto più spesso di quello che si crede anche se il programmatore è bravo) quando queste non servono più.

Poi si è passato a descrivere le funzionalità generali del linguaggio descrivendo la struttura di java consistente nella realizzazione della Java Virtual Machine, che è una macchina immaginaria emulata nel software di una macchina reale. Il codice della Java Virtual Machine è memorizzato in files di estensione .class, che sono raggruppate in insiemi di pacchetti (package di API) divisi per stesse funzionalità. Sono questi package che vengono forniti per ogni piattaforma e che hanno la stessa struttura nel passaggio da una piattaforma all'altra (ovviamente il codice interno di ogni metodo appartenente ad ogni classe, può cambiare a secondo della particolare piattaforma, ma ripeto non cambia la struttura classe/metodi).
La descrizione successiva ha riguardato le API dei package con particolare riferimento al package AWT (Abstract Window Toolkit), riguardante la gestione di oggetti contenuti in una finestra (bottoni, testi, ecc.).
Subito dopo la sessione ha continuato affrontando argomenti che riguardano il futuro Java:
Il package JDBC (Java DataBase Connectivity) API che supporta a basso livello le funzionalità SQL base. A partire da ciò sarà possibile realizzare lo sviluppo ad alto livello di accessi ai DB e lo sviluppo di APIs. Accanto a questo package e' stato presentato anche il package riguardante il ponte JDBC-ODBC che permette di realizzare connessioni a qualsiasi database utilizzi i driver ODBC della INTERSOLV utilizzati anche dalla Microsoft. Tipicamente la connessione al database avviene tramite un comando del tipo :

jdbc: <identifier>

o

jdbc:<subprotocol>:<identifier>

Per esempio nel seguente pezzo di codice java che utilizza il ponte JDBC-ODBC il campo subprotocol è uguale a odbc e il campo identifier è uguale a sales che è la fonte di dati ODBC alla quale è associato il driver ODBC: 

Connection conn = DriverManager.getConnection("jdbc:odbc:sales"); Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("SELECT Name, Sales FROM Customers"); while (rs.next()) { String name = rs.getString("Name"); int sales = rs.getInt("Sales");

Come si può notare una volta effettuata la connessione al database, si può procedere con la creazione di Query e con l'esecuzione delle stesse mediante istruzioni del tutto familiari a chi ha già avuto a che vare con operazioni SQL . L'unica cosa che cambia è ovviamente la sintassi dei comandi. Ultimamente la Symantec ha creato il pacchetto dbANYWHERE che si basa su di una tecnologia che permette di accedere ai dati da applicazioni o applet java sotto Internet o Intranet ; questa tecnologia si appoggia alla programmazione con le API JDBC. dbANYWHERE include ciò che è necessario per accedere ai database, le librerie JDBC e i drivers per Oracle, Sybase, SQL Server, Microsoft SQL Server oltre ai driver ODBC per Sybase SQL, Anywhere(Watcom), MS Access e InterSolv ODBC Driver pack : inoltre nel pacchetto è presente un programma per testare i vari accessi ai database tramite JDBC, dove è possibile effettuare la connessione al database ed eseguire istruzioni SQL interattivamente. 

I package JavaIDL (Language-neutral Interface Definition Language) e JavaRMI (Java Remote Method Invocation) che consistono in pacchetti API riguardanti la comunicazione Client/Server e insieme costituiscono la Java Enterprise. Il package JavaIDL fornisce soluzioni eterogenee per far comunicare applicazioni java con applicazioni non java ; esso permette di accedere a servizi di rete scritti in vari linguaggi e per diverse piattaforme. Tramite questo package un oggetto remoto residente su un server viene riconosciuto dal client come un oggetto IDL e trattato come se risiedesse localmente (l'oggetto viene trattato in un processo residente su client chiamato STUB al quale viene delegato il compito di comunicare con il processo SKELETON residente su server, dove esiste fisicamente l'oggetto). Il package JavaRMI invece fornisce soluzioni per far comunicare 2 differenti Java Virtual Machine. Mediante questo package possono essere invocati metodi da oggetti che si trovano su macchine virtuali differenti, non c'è bisogno di definire delle nuove inferfacce, viene passato e ritornato qualsiasi oggetto Java, e le classi vengono caricate dinamicamente al momento che servono.

Il package di API chiamato JEEVES, che è un http web server configurabile dinamicamente ed estensibile dinamicamente. Esso attiva i cosiddetti servlets che sono oggetti Java che estendono le funzionalità dei servers come HTTP o Web servers. Un documento HTML rilasciato da un Web server è statico. Un servlet invece viene eseguito ad ogni richiesta in modo che si possono ottenere informazioni dinamiche. Per esempio supponiamo che un browser generi una richiesta al server di un documento che contiene informazioni dinamiche. Il server esamina la richiesta e la assegna ad un particolare servlet. Quindi invoca il servlet che crea il documento con il suo contenuto dinamico e lo restituisce al client. I servlets possono fare di più che semplicemente ritornare documenti. Una volta che la connessione HTTP è aperta client e servlet possono parlare mediante un protocollo attraverso la connessione. I servlets sono simili agli applets che realizzano processi server. La differenza sta nel fatto che sono oggetti interfacciabili senza un'interfaccia utente. I servlets possono vivere a lungo e non devono essere creati ad ogni richiesta perché possono essere caricati la prima volta che vengono chiamati e rimanere attivi un certo tempo, al fine di esaudire altre richieste. C'è a questo punto da riassumere i motivi del perché la necessità di un server scritto con la logica dei servlets. Quando i server Web e HTTP divennero popolari fu creato lo standard Common Gateway Interface (CGI) per interfacciare applicazioni esterne con server WEB. Una applicazione CGI può essere scritta in qualsiasi linguaggio, per esempio C e PERL. CGI usa variabili di ambiente e spedisce parametri alle applicazioni (per esempio QUERY_STRING e PATH_INFO). I due principali inconvenienti nell'uso delle CGI sono che non hanno una buona prestazione (viene creato un nuovo processo ad ogni richiesta) e sono dipendenti dalla piattaforma. Anche l'interazione tra due scripts CGI che girano sullo stesso server è complessa. FastCGI è un'estensione di CGI che usa processi persistenti per far girare applicazioni esterne, in modo che non è necessario creare un processo ad ogni richiesta.. Ma ancora la comunicazione tra il server e i processi dell'applicazione può essere bassa perché i processi sono differenti. Per risolvere il problema della prestazione furono create delle API scritte in C. I moduli C girano nel processo server. Alcune di queste API sono per esempio NSAPI, ISAPI. L'inconveniente di questo approccio sono la dipendenza dalla piattaforma, la complessità e la mancanza di sicurezza. I servlets risolvono i problemi citati ed è abbastanza facile scrivere dei servlets che supportano applicazioni scritte usando gli approcci sopra descritti. Per esempio si può scrivere un FastCGIServlet che intercetta una richiesta e comunica con l'applicazione usando il protocollo FastCGI. Alcuni servlet disponibili nel package Jeeves :

File Servlet. Questo servlet include un meccanismo di caching per velocizzare i tempi di risposta a frequenti accessi ai files. Inoltre esso riconosce i file che devono essere analizzati dalla parte server, li include e li passa al SSInclude Servlet. 

SSInclude Servlet. Questo servlet include files (files con estensione .html), e invoca qualsiasi servlet contenuto nel file HTML, il quale viene ritornato al richiedente. La sintassi HTML per i servlet inclusi è: <SERVLET CODE="MyPackage.MyServletClass" NAME_1="VALUE_1" ... NAME_N="VALUE_N">

dove NAME_1 ... NAME_N è il nome dei parametri da spedire al servlet e VALUE_1 ... VALUE_N sono i corrispondenti valori. I parametri vengono passati in una tabella hash.

Invoker Servlet. Lo scopo di questo servlet è quello di invocare altri servlets richiedendoli nominando esplicitamente il nome, cioè : http://<server-host-name>/servlet/<servlet-name>. 

Admin Servlet. Questo servlet facilita l'amministrazione di server Jeeves attraverso un'interfaccia GUI. 

CgiServlet. Questo servlet agisce come un gateway per l'interfaccia CGI 1.1. Esso permette di utilizzare gli standard CGI 1.1. e operare sotto Jeeves. 

Il problema della sicurezza investe innanzi tutto la sicurezza del linguaggio da riassumere nei 2 punti salienti

- Protezione dai virus sulla rete - Protezione da danni accidentali 

Questa sicurezza viene assicurata a tre livelli : 

Il linguaggio Java. 

Ribadiamo ancora i concetti già noti. Non supporta l'aritmetica dei puntatori, ma implementa array veri e propri invece di elenchi di puntatori collegati consentendo di effettuare dei controlli sui limiti della memoria, evitando pericolose violazioni generate da dati errati o sospetti . 

E' provvista di routines di Garbage Collection con il compito di rimuovere automaticamente dalla memoria tutte le classi e variabili non più usate. 

Effettua controlli sui limiti degli array sollevando eccezioni di errori in caso un indice superi tali limiti. 

Il codice da caricare. 

Si effettuano controlli sulla firma dei metodi, controlli per vedere se esistono sempre uscite dai loop, controlli per vedere se le eccezioni siano correttamente assegnate e controlli sulle sottoclassi e classi finali. 

I Security Managers 

Mediante la gestione dei Security Manager, ciascuna applicazione (come Hotjava) può decidere una propria politica di sicurezza circa : 

- Se e quali files possono essere acceduti - Se e quali aree del File System possono essere accedute - Le risorse da assegnare al sistema Client.

In pratica scrivere un Security Manager significa implementare i metodi della classe java.lang.SecurityManager secondo i limiti all'ambiente di esecuzione (il processo prende il nome di "Sandbox"), decisi in seguito alla definizione della politica di sicurezza. Il Security Manager contiene un certo numero di metodi che possono essere richiamati per testare certi tipi di azioni (per esempio vedere se è permesso caricare delle librerie dinamiche, eseguire dei comandi di sistema, accedere in lettura e/o scrittura a file locali, ecc.) e decidere se queste azioni sono permesse o no. Esempio :

public boolean mkdir(String path) throws IOException { SecurityManager security = System.getSecurityManager();

if (security != null) { security.checkWrite(path); } return mkdir0(); }

In questo esempio il metodo pubblico mkdir testa se esiste un sistema di SecurityManager . Se esiste, richiama il metodo checkWrite per vedere se è possibile scrivere il tal file; se il test fallisce viene attivata l'eccezione IOException.

Tutto questo è quello che è disponibile fino ad oggi. Prossimamente saranno disponibili altri livelli di sicurezza che entreranno a far parte di un nuovo package Security API:

- Firme digitali sul codice. Realizzato associando al codice chiavi private (proprietarie) e pubbliche, mediante la definizione di una politica di sicurezza derivata da insieme di asserzioni (es. "Il codice che è stato realizzato dalla tal società è sicuro") ognuna delle quali associate ad un permesso (es. "Può accedere ai file della directory c:/java/bin" da cui segue la politica "Il codice che è stato realizzato dalla tal società può accedere ai file della directory c:/java/bin").

- Crittografia. Che permette la codifica e la decodifica di documenti mediante generazione, tramite una chiave privata, di codice crittografato. 

Il nuovo pacchetto JDK Java 1.1. la cui uscita è prevista entro il mese di novembre 1996, che conterrà già il software di cui si è parlato sopra. In particolare :

JAR Files. JAR (Java Archive) è un file con formato indipendente dalla piattaforma che aggrega più files in uno. Più applets Java e i loro necessari componenti (files .class, immagini e suoni) possono essere uniti insieme in un file JAR e successivamente scaricati da un browser in una singola transazione HTTP, migliorando notevolmente la velocità di trasferimento. Il formato JAR supporta anche la compressione riducendo così la grandezza del file, migliorando ancora il tempo di trasferimento. Inoltre l'autore dell'applet può apportare una firma digitale individuale alle sue entries nel file JAR per autenticare la loro origine. Questo formato è completamente compatibile con il codice delle applet che si riferiscono a versioni precedenti ed è completamente estensibile, essendo stato scritto in java. 

Sicurezza. La Java Security API è disegnata per permettere agli sviluppatori di incorporare sia le funzionalità di sicurezza a basso livello che quelle ad alto nelle applicazioni java. Questo include la crittografia, la gestione delle chiavi e il controllo degli accessi. La prima release del Java Security in JDK 1.1 conterrà un sottoinsieme di queste funzionalità. JDK 1.1 fornirà il supporto per firmare le classi e gli altri dati (come immagini e suoni). 

Aggiunte al package AWT. Le aggiunte puntano a risolvere alcune deficienze di AWT e includono un ricco insieme di metodi per lo sviluppo su larga scala di interfacce GUI, API per le stampe, una più facile e veloce gestione delle funzioni di scrolling, popup menus, clipboard (copy/paste), cursori nei componenti, aggiunte sulla gestione delle immagini e modelli e un più flessibile supporto per i font. Inoltre la versione Windows (Win32) version di AWT è stata completamente riscritta per aumentare la velocità, qualità e consistenza con le altre piattaforme. Un sottoinsieme di queste aggiunte è già stato prodotto con il nome di JavaBeans. 

Aggiunte al package gestore di rete. Modifiche alle classi del pacchetto java.net circa le socket. Con JDK 1.1, Socket e ServerSocket non sono final, e quindi possono essere estese a nuovi classi mediante la clausola extend. Nuove sottoclassi di SocketException sono state aggiunte per la gestione di eccezioni in fase di stampa e per gli errori di rete. La classe MulticastSocket è stata spostata da sun.net a java.net. Sono anche stati corretti gli errori che sembravano essere presenti nel pacchetto precedente. 

Remote Method Invocation. Remote Method Invocation (RMI) abilita gli oggetti Java che hanno i metodi invocati in codice Java che sta girando in un altra macchina virtuale, inclusi quelli che girano su altri computers. I riferimenti a questi oggetti remoti possono essere passati come parametri in calls RMI. . JDBC. Java Database Connectivity come si è detto sopra è una interfaccia standard di accessi SQL a database, fornendo uniformi accessi ad un largo numero di database realzionali.. Esso viene anche implementato da una libreria chiamata "ponte ODBC" che garantisce gli accessi anche a database con driver ODBC. 

Java IDL. Il Java IDL connette clients Java a server su rete usando la standard IDL Interface Definition language. Il sistema Java IDL permette di definire interfacce remote nel linguaggio IDL in modo che un client Java possa invocare un oggetto che risiede su un server remoto. Similmente esso permette anche ad un server Java di definire oggetti che possono essere trasparentemente invocati da un IDL clients. 

Nuova Interfaccia per la scrittura di metodi nativi. Il primo obbiettivo è la piena compatibilità binaria delle librerie di metodi nativi attraverso tutte le implementazioni di macchine virtuali java su una data piattaforma. 

Il forum si è concluso con una tavola rotonda tra i rappresentanti delle società ospiti i quali hanno dichiarato il loro impegno ad appoggiare la tecnologia java, ritenendo che pur non guadagnando direttamente da essa in quanto completamente freeware, grazie ad essa e alla diffusione del fenomeno Internet il mercato che si era assopito si è risvegliato, rivelando una grossa possibilita' di guadagni sia per loro che per i singoli sviluppatori. 

Ci auguriamo che nel futuro ci siano altri forum Java organizzati da Infomedia o da altre società, a prezzi contenuti come è stato questo, per dar modo di intervenire anche a quegli sviluppatori che non dispongono di molto denaro. 

 
 
Daniela Ruggeri e' laureata in Matematica e lavora dal 1982 nel campo dell'informatica. Attualmente ricopre la qualifica di Analista di Procedure Applicative presso una società di informatica. Ha scritto un articolo su java situato all'indirizzo http://www.blunet.it/discussioni/

Può essere contattata tramite la redazione o direttamente all'indirizzo drggnla@flashnet.it 

 
MokaByte rivista web su Java

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