12. DNA - JINI : CONFRONTO DELLE DUE TECNOLOGIE

Come conclusione del lavoro è opportuno effettuare un confronto tra le piattaforme di Middleware analizzate nel trattato (JINI e DNA), comprese quelle solamente accennate (CORBA e DCOM). Esse rappredentano le quattro tecnologie di middleware più conosciute al momento sul mercato, ossia JINI proposto da SUN Microsystems, CORBA proposto da OMG (anche se alcuni potrebbero obiettare che CORBA più che essere un prodotto vero e proprio potrebbe essere considerato solo come un set di specifiche), DCOM e la sua evoluzione in DNA proposti invece da Microsoft.
Quella che si vuole fare non è un'analisi ed un confronto dettagliato della struttura e delle funzionalità dei quattro (trattate in parte nei capitoli precedenti), ma solo presentarne le caratteristiche fondamentali, in modo da evidenziare le principali differenze, differenze che rendono queste quattro tecnologie non del tutto equivalenti ed indirizzate verso particolari problematiche.
Se consideriamo infatti DCOM e CORBA, nati più o meno nello stesso periodo, possiamo vedere che mentre il primo è molto legato all'ambiente Microsoft proprietario della tecnologia, in CORBA vi è una indipendenza della piattaforma e non vi sono particolari richieste per quanto riguarda il sistema operativo. Questa scelta è dettata dal fatto che il gruppo OMG ha voluto realizzare un prodotto rivolto soprattutto alla standardizzazione dei sistemi informativi, ove l'eterogeneità degli elementi e l'impossibilità di far colloquiare gli stessi può creare sicuramente un buon numero di problemi.
Questa necessità di armonizzare ambienti tanto differenti (si pensi ad esempio alla possibilità di far cooperare un database non relazionale con un programma scritto in COBOL) ha portato alla creazione di una piattaforma completamente indipendente sia dall'hardware che dal sistema operativo,piattaforma che serva da riferimento a tutti gli elementi presenti nel sistema e che faccia da interlocutore per eventuali comunicazioni tra gli stessi.
L'unico vincolo posto ad un elemento che vuole integrarsi con un ambiente CORBA (elemento che verrà poi gestito come un oggetto anche se in origine non era pensato come tale) è quello di presentare un'interfaccia verso l'ambiente scritta in un modo standard (utilizzando l'IDL ossa Interface Definition Language) riconoscibile dallo stesso e che presenterà i metodi e gli oggetti forniti dall'elemento. DCOM da parte sua non ha tutta la flessibilità che caratterizza CORBA per quanto riguarda la piattaforma di supporto sia perché è stata sviluppata da una casa produttrice, Microsoft, che non aveva interesse a sviluppare un middleware per ambienti diversi da quelli proprietari, sia perché la filosofia che sta alla base di DCOM è leggermente diversa da quella di CORBA. DCOM infatti non si pone la problematica di far colloquiare elementi diversi ma si limita a mettere a disposizione un ambiente capace di nascondere tutta una serie di problemi ai vari applicativi scritti in un linguaggio standard C++ o Java quale ad esempio l'allocazione delle risorse. Questa limitazione, che mal si accompagna alla problematica di cercare di rendere interoperabile un sistema preesistente, ha dal canto suo il vantaggio di rendere il prodotto Microsoft maggiormente performante dal punto di vista della capacità elaborativa, dato che vengono eliminate una serie di traduzioni tipiche dell'approccio CORBA.
Alternativamente a DCOM, la Sun Microsystem ha presentato il proprio prodotto JINI, che sostanzialmente può essere visto come l'estensione in ambiente distribuito del linguaggio di programmazione Java enfatizzandone le caratteristiche di mobilità del codice. Con assoluta indipendenza della piattaforma sottostanze (l'unica richiesta è quella della presenza di una JVM).
Jini offre un'infrastruttura ed un modello di programmazione ad un utente che vuole creare un unico e dinamico sistema distribuito.
Anche se, come nei casi precedenti il fine ultimo è quello di fornire un ambiente in cui l'attivazione d'oggetti è indipendente dalla localizzazione spaziale degli stessi, le applicazioni naturali per questo tipo di sistema distribuito sono diverse da quelle presentate per i due esempi precedenti. Tali applicazioni possono andare dall'ambito del commercio elettronico, alla domotica, al controllo industriale nel caso si parli di sistemi embedded mobili ed alla robotica (nel caso si voglia affrontarla in un modo omogeneo), problematiche che mal si prestano all'uso sia del prodotto Microsoft che dell'ambiente presentato da ORB.
DNA, infine, che è l'evoluzione naturale della piattaforma DCOM vuole essere la risposta a CORBA (visto che CORBA aveva il grande vantaggio di poter inglobare anche prodotti Microsoft). Esso ha le stesse caratteristiche a grandi linee e quindi le stesse modalità di utilizzo ma ha il grande svantaggio che richiede piattaforme Microsoft (anche se oggi con la grande diffusione di tali prodotti lo svantaggio risulta comunque ridotto). Parlando di DCOM e DNA non si può quindi parlare di interoperabilità.
E' da notare in ultimo che vi è la possibilità tramite opportune interfacce di poter far comunicare questi sistemi tra di loro; tale scelta è dettata sicuramente dal fatto che uno sviluppo indipendente sicuramente alla lunga taglierebbe fuori dal mercato (anche se un discorso diverso va fatto per Jini che si pone su nicchie di mercato che difficilmente potrebbero essere coperte dagli altri middleware presentati) dando però la possibilità di far colloquiare middleware diversi per poterne sfruttare al meglio le relative caratteristiche.
Da un punto di vista più tecnico, Jini e Dna possono venire confrontati analizzandoli da più punti di vista:

12.1 Autonomia
Autonomia è la capacità di una applicazione distribuita di governare e controllare le sue risorse critiche, ovvero quelle risorse necessarie al funzionamento affidabile ed indipendente dell'applicazione (connessioni a database, transazioni, connessione a mainframe, ecc.).
Le applicazioni non autonome hanno un controllo minimo o nullo sulle proprie risorse critiche, ovvero i client hanno l'accesso diretto sulle risorse. l risultati sono comportamenti inaspettati ed indesiderati, come l'aggiornamento parziale di dati condivisi o l'esaurimento delle risorse, e quindi una compromissione della stabilità della applicazione.
Windows DNA, tramite il modello 3-tier, offre un controllo totale sulle risorse critiche, quindi i client non accedono mai direttamente alle risorse, ma effettuano richieste di ben precisi servizi business che richiedono a loro volta l'accesso a risorse critiche.
Autonomia è quindi conseguenza del modello 3-tier, al quale si deve la stabilità delle applicazioni.
Essendo Jini un particolare Middleware che che consente di realizzare sistemi distribuiti operanti su JVM, dipenderà dal progettista del sistema decidere il grado di autonomia del sistema. Per Jini autonomia è quindi una scelta progettuale.

12.2 Affidabilità
L'affidabilità è la capacità di una applicazione di restituire risultati accurati. In un ambiente distribuito e multiutente, garantire l'affidabilità delle operazioni non è di poco conto. Microsoft, con COM+ (che ingloba la tecnologia COM e MTS) fornisce uno strumento per rendere affidabili le transazioni, e in altre parole, per garantire le proprietà ACID delle transazioni. Quindi, affidabilità in Windows DNA è sinonimo di MTS.
Jini, per sua natura, non si occupa di affidabilità in un contesto distribuito. Esso fornisce la materia prima per poter realizzare una qualche transazione distribuita, però, come anche per l'autonomia, lascia al progettista il compito di preoccuparsi di tutto ciò che consegue alla realizzazione di un sistema distribuito.
Si evidenzia quindi una prima grande differenza tra i due sistemi di Middleware: DNA è stato progettato per consentire una semplice progettazione e realizzazione di sistemi distribuiti su rete, fornendo servizi per il controllo e la gestione del sistema realizzato.
Jini rimane invece molto più a basso livello, ovvero fornisce servizi per far cooperare oggetti distribuiti su rete di calcolatori, tramite JVM, ma non si occupa assolutamente di tutta l'infrastruttura necessaria ad un funzionamento ottimale del sistema da realizzare. Esso viene lasciato al progettista, il quale ha ampie possibilità di realizzare tali infrastrutture, anche se non gli vengono fornite direttamente dal sistema di Middleware.
Da questa fondamentale differenza tra i due sistemi, ne deriva l'utilizzo differente che fino ad ora ne viene fatto: DNA è rivolto principalmente come supporto verso la realizzazione di sistemi distribuiti in tecnologia Microsoft, mentre Jini è più rivolto verso applicazioni quali la domotica o il commercio elettronico in qualsiasi tecnologia che supporti una JVM.
Questo è il motivo per il quale in DNA ritroviamo infrastrutture e soluzioni per problemi di scalabilità e disponibilità delle risorse, cosa che in Jini non viene affrontata. Infatti, la forza di Jini è la semplice condizione della presenza di una JVM su cui realizzare una qualsiasi applicazione distribuita tramite i meccanismi di RMI.

12.3 Performance
Il meccanismo proposto da Microsoft per ottenere la scalabilità di un sistema distribuito è l'utilizzo di front-end server replicati con un meccanismo di distribuzione delle richieste, ad esempio tramite opportune configurazioni del DNS (Domain Name Server) che consentano di accedere ai servizi della applicazione in modo bilanciato, utilizzando tutte le repliche disponibili dei front-end system.




Un altro modo proposto da Microsoft è quello di utilizzare la replicazione sia dei front-end che dei back-end system, in modo da ottenere un bilanciamento del carico esteso a tutte le parti della applicazione.


Inoltre, Microsoft propone anche dei meccanismo per accedere anche ad informazioni contenute nella rete interna aziendale, e quindi al massimo livello di sicurezza. Tali meccanismi, supportati da una ovvia infrastruttura di security, possono essere sincroni o asincroni, tramite l'utilizzo di MSMQ.
In conclusione, l'architettura 3-tiers o in generale n-tiers, consente al progettista di un sistema distribuito ampio margine di scelte progettuali, a seconda dei punti di forza che vuole conferire alla sua applicazione. Per capirci meglio, un applicazione distribuita che consente l'accesso a migliaia di utenti giornalmente, con la possibilità di raggiungere informazioni contenute al livello della rete aziendale più interna, che utilizza meccanismi di replicazione e bilanciamento del carico, sarà sicuramente performante, ma non avrà sicuramente la sicurezza come punto di forza.
Come al solito, sarà compito del progettista quello di cercare un compromesso tra le qualità che vorrà conferire alla applicazione che vuole realizzare.
Per quanto riguarda Jini e la performance dei sistemi distribuiti realizzati su di essa, il problema si sposta principalmente sulla performance della Java Virtual Machine. Chiunque abbia navigato su Web e abbia acceduto ad una Java Web Page, avrà osservato i limiti di velocità di risposta della JVM. Ovviamente la colpa può essere data alla lentezza delle reti Italiane, ma ad oggi rimane comunque un problema della tecnologia Java distribuita su rete. Inoltre, la presenza del Garbage Collector, non rende la JVM uno dei sistemi di Middleware più performanti, disponibili sul mercato.

12.4 Interoperabilità
L'interoperabilità è la capacità di un sistema di essere adattabile a qualsiasi piattaforma commerciale in modo da poter essere realizzato indipendentemente dalla piattaforma che poi lo ospiterà.
Anche se sono disponibili versioni della infrastruttura COM anche su sistemi non-Windows, rimane indubbiamente il punto debole della tecnologia Microsoft.
COM è alla base di qualsiasi meccanismo di Windows DNA e offre un potente ambiente di sviluppo per applicazioni distribuite. Ma COM è di origine fortemente proprietaria.
Non si può affermare che i sistemi Microsoft siano interoperabili e piattaforma-indipendenti.
Per quanto riguarda Jini, è sicuramente uno dei suoi punti di forza. Ormai le Java Virtual Machine sono una tecnologia disponibile su tutti i principali sistemi operativi in commercio. Questo è stato reso possibile dal grosso successo che ha avuto Java come metodo di accesso e di realizzazione di pagine Web. Chiunque voglia accedere ad Internet senza problemi, deve possedere una JVM. In risposta ad una domanda estremamente crescente verso gli accessi ad Internet, i maggiori sistemi operativi in commercio non sono potuti rimanere indifferenti.
Esiste una ovvia restrizione: il legame con Java è molto forte.
Uno gli aspetti fondamentali di Jini è proprio il modello di programmazione per lo sviluppo di nuovi servizi. I servizi devono avere un'interfaccia scritta con il linguaggio Java nella quale definiscono le operazioni che intendono fornire al sistema stesso (e' da notare che un pezzo di codice di programma Java sarà scaricato direttamente dal client per pter utilizzare il servizio).
Una apertura verso altri linguaggi sarebbe sicuramente apprezzabile, ma vista la politica ben definita che la SUN ha deciso di adottare sarà sicuramente un sogno che non potrà essere realizzato. E' da apprezzare comunque il fatto che vi è una assoluta trasparenza dal lato cliente del servizio; infatti per il cliente non vi è distinzione tra servizi che sono implementati da un oggetto sulla macchina locale, servizi che sono implementati da oggetti su macchine remote, servizi che devono essere scaricati nello spazio di lavoro locale e servizi implementati in Hardware. Tutti questi servizi appariranno disponibili sulla rete come oggetti scritti nel linguaggio di programmazione java, e nel caso vengano mantenute le medesime funzionalità, una implementazione può essere comodamente essere sostituita da un'altra di un altro tipo senza che il cliente del servizio debba essere informato.

12.5 Sicurezza
La sicurezza di un sistema provvede a fornire una adeguata protezione verso la confidenzialità, la privatezza, l'integrità e la disponibilità dell'informazione.
La tecnologia Microsoft di sicurezza utilizza domini di sicurezza multipli, in cui i sistemi sono posti a seconda delle loro necessità di sicurezza. Ogni dominio viene protetto poi da un meccanismo in grado di filtrare le informazioni che provengono dalla rete, i firewall.
I tre principali domini, ognuno separato da un firewall, sono:

La situazione è ben rappresentata dalla seguente figura.


Rispetto ai sistemi tradizionali, operanti su Intranet aziendali o su reti LAN, le applicazioni Web hanno una porta sul mondo aperta in ogni momento del loro funzionamento: la rete Internet. Sono necessari quindi meccanismi di certificazione e autenticazione di chi accede ai servizi dell'applicazione, servizi di protezione della consistenza e dell'integrità dei dati che viaggiano da e verso l'applicazione, e servizi di garanzia di provenienza del codice che viene caricato ed eseguito sull'applicazione, a livello di front-end system (pensare ai controlli ActiveX).
Un modo per facilitare questi obiettivi è utilizzare una partizione del sistema in domini di sicurezza, ovvero regioni in cui la sicurezza è garantita ad un certo livello.
Sistemi complessi possono scegliere una suddivisione multipla, assegnando svariati livelli di sicurezza ad ogni parte del sistema. Suddivisioni più ragionevoli ed utilizzate per normali sistemi Web si fondano sulla proposta raffigurata sopra, e cioè tre regioni di sicurezza.
I domini hanno la possibilità di essere mutuamente esclusivi oppure sovrapposti. Il secondo caso è molto utile in situazioni in cui ho dati di sicurezza elevata mantenuti da sistemi di sicurezza blanda. Necessito di controlli addizionali come ad esempio tecniche di crittografia.
I firewall sono meccanismi per controllare il flusso dei dati tra due parti di una rete poste a differenti livelli di sicurezza. Possono operare su singoli pacchetti IP, consentendo quindi a specifici indirizzi IP di comunicarsi, oppure possono focalizzarsi a livello applicativo, analizzando l'informazione giunta e decidendo di conseguenza se è accettabile o no.
La sicurezza di un sistema è un obiettivo difficile da raggiungere pienamente. La suddivisione in domini di sicurezza e l'utilizzo dei firewall è solo un meccanismo proposto per ottenere un certo livello di sicurezza, ma non è sicuramente sufficiente ad assicurarsi una completa protezione da intrusi ed accessi pericolosi al sistema.
Il problema della sicurezza riguardo al controllo sugli accessi e alla privatezza delle comunicazioni può essere comunque risolto con una certa infrastruttura costruita sulla base della applicazione distribuita, tramite meccanismi di dominio, firewall, crittografia, e gli stessi meccanismi di basso livello messi a disposizione da DCOM.
Il problema sostanziale relativo alla sicurezza Microsoft, riguarda l'ultima generazione delle sue tecnologie: i controlli ActiveX.
Dal punto di vista della potenza computazionale e della facilità di utilizzo sono una utilissima ed efficace tecnologia per realizzare applicazioni distribuite. Dal punto di vista della sicurezza e del controllo che può avere su di loro un sistema che li esegua tramite un semplicissimo Web browser, sono pessimi. Microsoft, a tal proposito, non si è posta neanche l'obiettivo di rimediare al problema. L'unico sforzo è stato realizzare dei meccanismi che riescano a garantire la provenienza del codice, ma che assolutamente non si preoccupano del vero problema, e cioè di cosa fa e come controllare il codice ActiveX.
Tutto questo rende fondamentale la parte progettuale dei sistemi di sicurezza di un sistema basato sul paradigma Windows DNA.
Il risultato è sicuramente un aumento dei tempi di progetto di un sistema distribuito, che Microsoft definisce minimali, e potrebbe anche essere una riduzione delle prestazioni del sistema, dovute al sovraccarico della infrastruttura di sicurezza realizzata sulla base della applicazione distribuita.
Il modello di sicurezza per la tecnologia Jini è costruito sulle nozioni gemelle di principal e di action control list. I servizi messi a disposizione da Jini sono accessibili da parte di particolari entità, i principal, i quali generalmente fanno risalire ad un particolare utente del sistema. I servizi stessi possono richiedere l'accesso ad altri servizi basandosi sull'identità dell'oggetto che implementa il servizio. Se l'accesso ad un servizio è concesso dipende dal contenuto di una particolare lista detta access control list che è associata all'oggetto.
Come nei casi precedenti, risalta nuovamente la differenza fondamentale tra Jini e DNA: DNA, anche se non in modo completo, fornisce un supporto completo alle problematiche di sicurezza, Jini invece fornisce l'infrastruttura basa necessaria per poter realizzare un controllo della sicurezza per un sistema distribuito su rete.

ficatore del servizio associato al servizio stesso. Un servizio di lookup è sempre registrato all'interno di se stesso sotto questo serviceID, e se un servizio di lookup è configurato per registrarsi con altri service lookup si registrerà con lo stesso identificatore. L'ultimo metodo, il metodo getGroups indica l'insieme dei gruppi dei quali il servizio di lookup corrente fa parte.