INTRODUZIONE A J2EE 1.4 E AI SERVIZI WEB ENTERPRISE

Transcript

1 01-CAP01_ok :52 Pagina 1 Parte prima INTRODUZIONE A J2EE 1.4 E AI SERVIZI WEB ENTERPRISE

2 01-CAP01_ok :52 Pagina 2

3 01-CAP01_ok :52 Pagina 3 Capitolo 1 Le ragioni di tanto interesse 1.1 Enterprise in J2EE 1.2 J2EE in aiuto 1.3 Riepilogo La versione 1.4 della piattaforma Java 2 Enterprise Edition (J2EE) è la versione più significativa di J2EE da quando questa tecnologia innovativa venne introdotta da Sun Microsystems nel La tecnologia J2EE si è considerevolmente evoluta negli anni e costituisce attualmente lo standard de-facto per lo sviluppo di applicazioni aziendali e sistemi di elaborazione in generale. Realizzata su solidissime basi, J2EE 1.4 aggiunge ricche funzionalità e caratteristiche di orientamento enterprise alla piattaforma Java 2 Standard Edition (J2SE), la quale già rivoluzionò le tecnologie di sviluppo del software svariati anni or sono. J2EE 1.4 vanta numerose ed entusiasmanti nuove tecnologie che non erano presenti nelle versioni precedenti, tra le quali il supporto completo per XML (extensible Markup Language) e per i servizi Web. 1.1 Enterprise in J2EE J2EE è una piattaforma di sviluppo e deployment ( messa in opera ) di applicazioni distribuite multilivello con una forte orientazione enterprise ( aziendale ). Come illustrato nella Figura 1.1, J2EE aggiunge numerosi livelli di funzionalità al di sopra della piattaforma J2SE, la quale è invece orientata allo sviluppo e al deployment di applicazioni desktop tradizionali.

4 01-CAP01_ok :52 Pagina 4 4 CAPITOLO 1 Piattaforma Java 2, Enterprise Edition Enterprise JavaBeans Transazioni Autorizzazione J2EE Servlets JavaServer Pages Messaging Posta Gestione Ecc. Connector Piattaforma J2EE CONTAINER Piattaforma Java2, Standard Edition Applicazioni, Applet, JavaBean J2SE Swing/AWT Networking Directory Access Input/Output Database Sicurezza CORBA XML Math IDL etc. Runtime J2SE/Macchina Virtuale Piattaforma generica sottostante a J2EE Linux Unix Windows Macintosh etc... Hardware: scheda madre, CPU, RAM, memoria di massa ecc. Figura 1.1 J2EE aggiunge numerosi strati con funzionalità di livello enterprise al di sopra della piattaforma J2SE. Definizione del termine enterprise Il termine enterprise identifica tradizionalmente una generica impresa o azienda, dal piccolo negozietto a conduzione familiare fino alla multinazionale. In un accezione più generale comunque, il termine descrive un organizzazione che opera secondo un determinato insieme di regole (le cosiddette regole business nel contesto di un azienda tradizionale). Scuole, organizzazioni senza scopo di lucro, gruppi ecclesiastici e altre entità sono incluse tra le tipologie di imprese non tradizionali per le quali si possono comunque sviluppare delle applicazioni J2EE. Le applicazioni J2EE sono semplicemente dei programmi software specifici per una data organizzazione, che forniscono funzionalità particolari per supportare alcuni dei processi generali che ne regolano l operatività. Un impresa commerciale, per esempio, potrebbe utilizzare J2EE per creare un applicazione per la gestione automatica degli ordini di acquisto, mentre una scuola potrebbe utilizzare J2EE per sviluppare un sistema per la gestione delle valutazioni e delle relative certificazioni. Organizzazioni senza fini di lucro e organizzazioni confessionali potrebbero utilizzare J2EE per sviluppare applicazioni per incoraggiare e gestire le donazioni. Cliniche od ospedali potrebbero sviluppare dei sistemi per la gestione delle cartelle cliniche dei propri pazienti. In ogni caso, i processi ope-

5 01-CAP01_ok :52 Pagina 5 LE RAGIONI DI TANTO INTERESSE 5 rativi specifici di ogni organizzazione vengono riflessi, almeno parzialmente, nelle particolari applicazioni di tipo enterprise. La piattaforma J2EE gestisce l infrastruttura software e supporta i servizi Web che consentono agli sviluppatori di creare applicazioni enterprise sicure, distribuite e interoperabili. J2EE, tramite la sua architettura multilivello distribuita e basata sulle componenti, facilita lo sviluppo di applicazioni particolarmente scalabili, costituite da elementi fisicamente distribuiti nelle reti. Come si potrà notare nel seguito, questa metodologia di sviluppo di applicazioni, oltre a consentire un elevato grado di scalabilità dell applicazione stessa, permette anche un organizzazione flessibile del processo di sviluppo software tramite un organizzazione naturale in squadre di lavoro. L espressione applicazione enterprise è praticamente sinonimo di applicazione distribuita, dato che sostanzialmente qualsiasi applicazione di rilievo sviluppata per un azienda, in un modo o nell altro, è distribuita in rete. In altre parole, applicazione enterprise è semplicemente un altro modo per indicare le applicazioni distribuite multilivello che sono appunto distribuite su livelli differenti dell infrastruttura di rete dell organizzazione (si veda la Figura 1.2). Una distinzione importante fra applicazioni enterprise e altri tipi di applicazioni distribuite è costituita dal fatto che le applicazioni enterprise normalmente coinvolgono e mettono in relazione vari dipartimenti e unità operazionali dell organizzazione nella quale vengono utilizzate. Lato Client (Front-end) Cellulare Lato Server (Livello intermedio) Lato Server (Back-end) Browser Server di logica business Database Server Sistema legacy EIS Server Applicazione Java Applet Java Server Web Sistema EIS Server EIS Server di database Chiosco Palmare Figura 1.2 Le applicazioni enterprise sono tipicamente applicazioni distribuite multilivello costituite da programmi che vengono eseguiti su differenti computer interconnessi tramite una rete.

6 01-CAP01_ok :52 Pagina 6 6 CAPITOLO 1 Architetture multilivello J2EE è fondata su un architettura multilivello nella quale le varie componenti che compongono un applicazione vengono logicamente separate e distribuite su diversi livelli o strati dell ambiente di elaborazione di rete. Queste architetture sono anche indicate come architetture n-tiered. In altri termini, i livelli rappresentano strati o livelli logici di funzionalità: le applicazioni multilivello raggruppano logicamente le componenti di un applicazione secondo le funzioni che esse eseguono nel contesto dell architettura globale. È importante notare che i vari livelli di un applicazione multilivello rappresentano un raggruppamento logico delle funzionalità e non un raggruppamento fisico. Le componenti che costituiscono un applicazione J2EE, per esempio, possono essere distribuite (raggruppate o organizzate) logicamente nei livelli client, Web, business e EIS, i quali sono distribuiti fisicamente in molteplici sistemi di elaborazione, come illustrato nelle Figure 1.2 e 1.3. Le applicazioni enterprise sono complesse. L idea di sviluppare e mantenere queste applicazioni può incutere timore a causa della loro complessità e del fatto che esse tendono a operare in ambienti eterogenei. Le applicazioni enterprise consistono tipicamente in numerosi programmi software o componenti che sono distribuiti per essere quindi eseguiti su hardware differenti. Questo hardware può spaziare dai mainframe di alta gamma, ai mini calcolatori o alle workstation di media gamma, fino ai PC desktop di bassa gamma. Le componenti che costituiscono queste applicazioni sono spesso scritte con linguaggi di programmazione differenti e non è insolito che comunichino tra di loro tramite molteplici protocolli. Le componenti che costituiscono un applicazione enterprise possono essere distribuite su reti locali (LAN), reti geografiche (WAN) o addirittura su Internet. Le applicazioni enterprise create con J2EE, per esempio, possono essere fisicamente distribuite su di un qualunque numero di sistemi di elaborazione e topologie di rete, caratteristica che le rende molto affidabili e facilmente scalabili. NOTA Sebbene le applicazioni enterprise siano complesse, soprattutto quando confrontate con applicazioni desktop isolate tradizionali, esse non sono altro che un insieme di programmi software che interagiscono fra di loro tramite una rete. Le applicazioni distribuite multilivello non rappresentano nulla di nuovo: è da decenni che si sviluppano applicazioni i cui elementi costituenti vengono eseguiti su differenti computer interconnessi tramite reti. La novità è costituita invece dalla crescente tendenza a realizzare queste applicazioni utilizzando complesse piattaforme di sviluppo distribuite, o framework, basate su standard Internet e Web aperti e interoperabili. La piattaforma J2EE, per esempio, è una soluzione completa che gli sviluppatori possono utilizzare per realizzare e distribuire le componenti software in ogni livello richiesto da un applicazione enterprise. Come tale, J2EE può essere utilizzata per sviluppare un ampia varietà di client front-end, middleware che supporta la connettività Web e la logica business di un organizzazione e soluzioni integrate di database di back-end o di sistemi informativi aziendali, o EIS (Enterprise Information System). J2EE fornisce anche un supporto completo per

7 01-CAP01_ok :52 Pagina 7 LE RAGIONI DI TANTO INTERESSE 7 un ampia varietà di standard aperti Web e Internet, tra i quali HTML (HyperText Markup Language), XML (extensible Markup Language), HTTP (HyperText Transfer Protocol) e SOAP (Simple Object Access Protocol). NOTA La piattaforma J2EE è una soluzione completa end-to-end (ovvero lato client e lato server) per sviluppare qualunque tipo di applicazione multilivello distribuita. Nel contesto di J2EE si sarebbe potuto perfettamente utilizzare il termine organization (organizzazione) al posto di enterprise. Enterprise tende comunque a evocare immagini mentali (e forse addirittura degli episodi di Star Trek) più entusiasmanti. La complessità dello sviluppo di applicazioni enterprise Non è affatto banale sviluppare applicazioni enterprise. Come minimo si tratta infatti di un impresa complessa e impegnativa. Nella peggiore delle ipotesi, la sola prospettiva di un progetto di sviluppo di applicazioni enterprise potrebbe dissuadere programmatori o interi gruppi di sviluppo dall affrontarlo. Nel contesto attuale in cui la maggior parte dei progetti di sviluppo software supera il budget disponibile, oltrepassa i tempi di completamento previsti o non supporta le funzionalità inizialmente richieste (a volte, addirittura, non riescono nemmeno a completare la fase di sviluppo), non sorprende che la complessità aggiuntiva e il costo globale dei progetti enterprise possano rappresentare un affare rischioso. Gli sviluppatori di applicazioni enterprise devono affrontare molteplici difficoltà, ma J2EE è stato espressamente progettato per fronteggiare ciascuna di esse. Nei prossimi paragrafi si descriveranno innanzitutto le difficoltà principali con le quali gli sviluppatori di applicazioni enterprise si devono confrontare e si analizzeranno successivamente le strategie con cui J2EE risolve tali problemi. Le quattro S : Stabilità, Scalabilità, Semplicità e Sicurezza Le applicazioni enterprise sono tipicamente critiche ( mission-critical ) per l operatività di un organizzazione. Le organizzazioni evitano di essere coinvolte in queste problematiche senza validissime ragioni. Nella maggior parte dei casi la ragione per sviluppare un applicazione enterprise è semplice: supportare il raggiungimento degli obiettivi dell organizzazione stessa. In breve: le applicazioni enterprise sono realizzate per supportare o migliorare l operatività o il raggiungimento degli obiettivi dell organizzazione. Esse possono migliorare la sua competitività, semplificare le sue operazioni, contribuire a far risparmiare o guadagnare denaro o supportare o migliorare la sua missione in mille altri modi. Le applicazioni efficaci devono soddisfare le quattro S : stabilità, scalabilità, sicurezza e semplicità. I paragrafi seguenti forniscono una descrizione di ciascun termine. NOTA Come si potrà notare nei capitoli seguenti, il termine applicazione J2EE si riferisce a una qualunque unità di funzionalità J2EE deployable : comprende quindi moduli singoli, gruppi di moduli e applicazioni distribuite com-

8 01-CAP01_ok :52 Pagina 8 8 CAPITOLO 1 plete composte da un qualsiasi numero di moduli. Modulo, a sua volta, si riferisce a un unità software che consiste di una o più componenti J2EE, mentre il termine componente indica una classe Java che rappresenta un unità autocontenuta di funzionalità. Sebbene le componenti J2EE non siano altro che classi Java, esse differiscono dalle classi tradizionali in tre aspetti fondamentali: le componenti J2EE devono essere assemblate in applicazioni, devono essere controllate prima di essere distribuite per verificare che siano ben formate e conformi alle specifiche J2EE e vengono eseguite e gestite dall interno di un container J2EE. Questi container forniscono alle componenti l accesso a servizi specifici e standardizzati. Stabilità La stabilità è la proprietà di un applicazione che si dice stabile quando si comporta come previsto senza bloccarsi, senza subire crash e senza esibire quelle caratteristiche comunemente associate con prodotti incompleti, scorretti e appunto instabili. La stabilità è particolarmente importante in applicazioni mission-critical che hanno un impatto diretto o indiretto sulla vita umana, quali applicazioni mediche o aeronautiche. Le applicazioni instabili possono influenzare negativamente un organizzazione utilizzando risorse eccessive e sprecando denaro per l addizionale assistenza tecnica richiesta o nel tentativo di evitare cattiva pubblicità derivante da sistemi malfunzionanti. Le applicazioni particolarmente instabili possono facilmente allontanare i potenziali clienti o possono facilmente fornire buone ragioni ai clienti esistenti per considerare soluzioni alternative. Sebbene sia importante, la stabilità non è facilmente conseguibile. Alcuni esperti sostengono che anche i programmatori più competenti introducono almeno un bug o un errore logico ogni dieci linee di codice che scrivono. Questo valore può risultare ancora più alto nel caso di applicazioni distribuite a causa della complessità addizionale nello sviluppo di questo tipo di applicazioni. Sebbene sia impossibile verificare tali statistiche, è ben noto il fatto che sia inevitabile introdurre errori durante il processo di sviluppo del software. Si può certamente migliorare la stabilità generale di un applicazione eliminandone i bug e gli errori di programmazione che si sono potuti individuare, sebbene non si tratti di un compito senza difficoltà: molti problemi nel codice rimangono sconosciuti e vengono evidenziati solo dopo il deployment delle applicazioni, durante il loro utilizzo in condizioni reali di stress. Scalabilità La scalabilità è l attitudine di un applicazione a poter essere facilmente ampliata, soddisfacendo eventuali incrementi di carico nelle richieste. La scalabilità è fortemente legata alla availability ( disponibilità ), che indica quanto spesso o a che livello un applicazione sia disponibile. Nel caso in cui un applicazione avesse una scalabilità limitata, potrebbe risultare non disponibile in condizioni di carico particolarmente gravose. Questa situazione potrebbe verificarsi, per esempio, quando esistono troppi utenti che interagiscono con l applicazione nello stesso istante sovraccaricando varie componenti dell applicazione. Se l applicazione avesse un elevata scalabilità e fosse quindi in grado di adattarsi dinamicamente all incremento del carico, essa sarebbe prontamente disponibile anche in condizioni di carico elevato. La scalabilità, come la stabilità, non si ottiene per magia: essa deve

9 01-CAP01_ok :52 Pagina 9 LE RAGIONI DI TANTO INTERESSE 9 essere esplicitamente realizzata nell applicazione a livello di codice così come a livello di piattaforma. Infatti, se l ambiente di esecuzione runtime dell applicazione non fosse scalabile, l applicazione stessa potrebbe non essere in grado di soddisfare pienamente un aumento del carico di richieste. Le applicazioni enterprise, in particolare, presentano vari punti di strozzamento che possono costituire dei colli di bottiglia per la scalabilità. Gli sviluppatori non devono considerare solamente la scalabilità di ogni componente eseguibile dell applicazione: essi devono anche preoccuparsi degli aspetti di scalabilità che coinvolgono la rete e ogni altro livello nell architettura dell applicazione distribuita. Sicurezza La sicurezza è il grado di protezione o vulnerabilità di un applicazione da utilizzazioni non autorizzate. Sebbene l attenzione alle questioni di sicurezza sia gradualmente aumentata nell ultima decade, essa è divenuta una questione centrale nell intero settore IT (Information Technology) dall 11 Settembre Quel giorno negli Stati Uniti la questione della sicurezza nazionale venne elevata al massimo livello di importanza, causando un immediato effetto collaterale nel settore industriale tecnologico e ovunque nel mondo. La vulnerabilità nella sicurezza delle applicazioni che poteva essere precedentemente considerata un rischio accettabile, considerati il tempo e il costo necessari per ridurla, è oggi una questione di estrema importanza per molte organizzazioni e individui. Di conseguenza, sempre più frequentemente il tempo e gli sforzi necessari per affrontare adeguatamente la sicurezza vengono allocati nelle fasi iniziali dello sviluppo software, come appropriato. Invece di prestare solamente un attenzione distratta alle questioni di sicurezza, quando la soluzione principale consisteva nel rilasciare correzioni ogniqualvolta venivano scoperte delle lacune di sicurezza in campo, molte organizzazioni fanno ora della sicurezza una delle priorità principali fin dall inizio. Così facendo, esse aumentano certamente i costi di sviluppo e i tempi di consegna. Sul lungo termine però, questi investimenti iniziali generano ritorni considerevoli, aumentando la soddisfazione e la confidenza dei clienti e riducendo nel medesimo tempo il supporto tecnico e lo sforzo per sviluppi ad-hoc che sarebbero altrimenti necessari per un software più vulnerabile. Quando il software è solido e sicuro non sono necessari il personale e le risorse addizionali per gestire le linee telefoniche dell assistenza tecnica, le chiamate per calmare i clienti innervositi e lo sviluppo di correzioni del software. Semplicità La semplicità di un applicazione dipende dal grado di semplicità della stessa sia dalla prospettiva degli utenti finali che dalla prospettiva dei programmatori che la sviluppano e ne effettuano la manutenzione. Per gli utenti finali, la semplicità di un applicazione dipende fondamentalmente dall interfaccia utente con la quale interagiscono e in misura minore dalla varietà di interfacce a loro disposizione. Se un applicazione è semplice, facile da utilizzare e ha l ulteriore vantaggio di essere accessibile da una varietà di configurazioni utente (per esempio, tramite un browser Web generico, l interfaccia di un applicazione specifica o un palmare wireless), gli utenti saranno più inclini ad adottarla. Nella prospettiva dello sviluppatore software invece, il grado di semplicità dipende dalla possibilità di sviluppare o migliorare

10 01-CAP01_ok :52 Pagina CAPITOLO 1 facilmente ed efficientemente l applicazione, mantenendone la stabilità, la scalabilità e la sicurezza globali. Semplicità nello sviluppo dell applicazione si traduce alla fine in produttività del programmatore: i programmatori possono fare di più in meno tempo e con meno sforzo. Questo è particolarmente importante nel caso di applicazioni enterprise. A causa della loro complessità intrinseca, qualunque misura orientata a semplificare il processo di sviluppo può essere estremamente proficua in termini di produttività dei programmatori e del loro benessere psicologico. Più risulta facile e veloce per i programmatori sviluppare e distribuire applicazioni complesse, più i programmatori saranno soddisfatti del proprio lavoro, cosa che genera un ritorno economico al datore di lavoro in termini di elevata produttività e ridotto turnover del personale. NOTA Le quattro S rappresentano la stabilità, la scalabilità, la sicurezza e la semplicità. L acronimo SSSS, coniato dall autore nel contesto di una rete e relativa piattaforma digitale di intrattenimento emergente (Web3DWeb, disponibile a: descrive i quattro requisiti più significativi che dovrebbero orientare qualsiasi applicazione software distribuita. Applicazioni enterprise che non fossero stabili, scalabili, sicure e semplici da utilizzare ed estendere avrebbero quasi certamente una vita utile più breve di quella di cui potrebbero altrimenti godere. L incremento della produttività dei programmatori Mai come ora le organizzazioni sono state costrette a fare di più con meno. Esse devono poter ottenere sempre di più dallo staff di sviluppo software esistente (o addirittura in contrazione), dovendo soddisfare le esigenze dei propri clienti operando in un contesto di concorrenza sempre crescente. A causa dei budget ridotti, dei licenziamenti e della concorrenza minacciosa, i programmatori stanno lavorando più freneticamente che mai per poter presentare dei prodotti sul mercato con la tempistica richiesta e in linea con i costi preventivati. La richiesta di produttività ai programmatori è attualmente elevatissima. I programmatori che non sono in grado di soddisfare o superare gli standard richiesti possono essere facilmente rimpiazzati con programmatori di grande esperienza, cosa che risultava impossibile solo pochi anni addietro. Nel passato i programmatori non dovevano sforzarsi più di tanto per trovare opportunità interessanti e ben remunerate in nuove e stimolanti aziende, ed era quindi facile cambiare frequentemente impiego. Attualmente la situazione è molto differente. Con tanti programmatori esperti in cerca di lavoro, le organizzazioni che possono permettersi nuove assunzioni sono in grado di trovare e ritenere facilmente personale qualificato. Le organizzazioni che non possono permettersi il lusso di assumere nuovi sviluppatori devono massimizzare le potenzialità dei programmatori esistenti (o a volte addirittura in contrazione), cosa che valorizza i programmatori particolarmente produttivi. Quindi: cos è che rende un programmatore produttivo? I fattori più importanti, naturalmente, sono la capacità e l esperienza. Se un programmatore non ha esperienza nel dominio in cui deve lavorare e non è in

11 01-CAP01_ok :52 Pagina 11 LE RAGIONI DI TANTO INTERESSE 11 grado di apprendere velocemente le nuove tecnologie richieste, si può dire addio alla produttività. Presupponendo che un programmatore sia qualificato per affrontare il lavoro per il quale viene assunto, è necessario considerare altri fattori che consentono di raggiungere o meno un elevato livello di produttività. Uno dei fattori più importanti è l aderenza dell organizzazione (e dei suoi programmatori) a un modello di programmazione unificato. In questo modello le componenti software sono sviluppate, controllate, distribuite e mantenute in modo uniforme e consistente e, possibilmente, si utilizza una famiglia standardizzata di tool per automatizzare e snellire il processo. Un modello di programmazione unificato è particolarmente importante quando si considera che le applicazioni software distribuite possono essere create impiegando una varietà di tecnologie sorprendentemente ampia. I front-end possono essere facilmente costituiti da pagine Web che utilizzano una combinazione di HTML, XHTML, XML, una varietà di linguaggi di script come JavaScript, Jscript, VBScript e altri, plug-in come Flash o QuickTime e altro ancora. Queste tecnologie lato client possono essere supportate sul lato server utilizzando programmi e script CGI (Common Gateway Interface), mentre il livello intermedio dell applicazione potrebbe catturare la logica business sotto forma di programmi scritti in linguaggi quali C, C++, C#, Java e altri. Si aggiungano a tutto questo le tecnologie dei database back-end e i relativi linguaggi di interrogazione (come SQL, XQuery e così via) per completare il quadro della situazione. Senza un singolo modello unificato di programmazione, i programmatori verrebbero facilmente travolti dalla complessità che ne deriverebbe. Tale modello invece, chiarisce come sviluppare le applicazioni distribuite consentendo anche una ripartizione ben organizzata del carico di lavoro: ciascun programmatore conosce esattamente il suo ruolo nel contesto generale, cosa che consente di incrementare la produttività a ogni livello. Oltre a seguire un singolo modello di programmazione unificato, come quello introdotto con J2EE, risulta molto più produttivo stabilire e seguire degli standard anziché reinventare la ruota con soluzioni ad-hoc o adottare soluzioni proprietary. Fornendo agli sviluppatori una modalità standard con la quale accedere ai vari servizi supportati dall applicazione che si sta realizzando, ciascuno di essi adotta la medesima (provata) soluzione evitando di inventare alternative proprie. Questo a sua volta può condurre allo sviluppo di una collezione di codice standard che ciascun programmatore può utilizzare, ottenendo i vantaggi delle tanto declamate promesse del software riutilizzabile. Assemblare le applicazioni con codice riutilizzabile contribuisce ulteriormente a incrementare la produttività dei programmatori. La produttività può essere spesso incrementata tramite l adozione di standard aperti evitando le soluzioni proprietary o l uso di standard meno conosciuti. Gli standard, definendo con precisione le regole esatte o i processi necessari per eseguire determinati compiti od operazioni, facilitano l interoperabilità dei prodotti (gli standard definiscono per esempio i formati per l interscambio di contenuti); inoltre semplificano e rendono il lavoro del programmatore meno ambiguo. Spesso sono disponibili delle implementazioni gratuite o a basso costo per la

12 01-CAP01_ok :52 Pagina CAPITOLO 1 maggior parte degli standard diffusi: si tratta di codice dal quale i programmatori possono trarre vantaggio evitando di doverne scrivere altro di proprio pugno. In aggiunta, gli standard aperti aiutano a evitare l eventualità di legarsi permanentemente a un particolare vendor, la cosiddetta situazione di vendor lock-in. Questo può avvenire quando le applicazioni divengono strettamente dipendenti dalle implementazioni, dai prodotti o dai servizi forniti o posseduti in esclusiva da un vendor o da un ristrettissimo gruppo di vendor. Al contrario, gli standard aperti sono normalmente supportati da un ampio numero di vendor riducendo quindi il rischio di vendor lock-in, rispetto all uso di soluzioni proprietary. Gli standard aperti favoriscono la neutralità dei vendor perché possono essere implementati da chiunque; essi portano tipicamente ad avere un ampio spettro di scelte possibili in termini di implementazioni e di piattaforme. Le applicazioni basate su standard aperti sono frequentemente anche molto portabili: possono essere eseguite su un ampia gamma di computer e piattaforme con uno sforzo di porting minimo o nullo. È questo il caso di J2EE che definisce una piattaforma di sviluppo di applicazioni distribuite basata su standard aperti quali Java, XML, HTTP, SOAP e altri ancora. Nessuna magia Sebbene J2EE contribuisca enormemente all aumento della produttività dei programmatori, non si tratta di una bacchetta magica. Lo sviluppo di applicazioni enterprise è un processo intrinsecamente complesso e laborioso. Sviluppare queste applicazioni con J2EE non è un impresa semplice o banale, nonostante i numerosi vantaggi della piattaforma. I programmatori che affrontano J2EE per la prima volta, in particolare, troveranno che l apprendimento è nel migliore dei casi lento o eventualmente addirittura di una difficoltà insostenibile, a seconda del loro background e della loro esperienza con Java. Fortunatamente esistono dei tool di sviluppo che possono facilitare e velocizzare il processo di apprendimento di J2EE. I tool di sviluppo professionali per J2EE sono essenziali sia ai nuovi sviluppatori J2EE che a coloro che ne abbiano già esperienza. Essi incapsulano gran parte della complessità dietro un interfaccia grafica facile da utilizzare e automatizzano i compiti ripetitivi, noiosi e propensi agli errori. Gli ottimi tool di sviluppo J2EE schermano i neofiti di J2EE dalla complessità e dai compiti sottostanti che i programmatori dovrebbero altrimenti direttamente ed esplicitamente fronteggiare. Questi tool, inoltre, consentono comunque agli sviluppatori J2EE più esperti di immergersi nel codice a un livello più basso, a seconda delle necessità. Sfortunatamente, occorre molto tempo prima che siano disponibili delle piattaforme e dei tool di sviluppo in seguito al rilascio di una revisione fondamentale di J2EE. Perfino ora, in seguito alla finalizzazione delle specifiche della piattaforma J2EE 1.4, molti vendor di prodotti J2EE stanno solamente incominciando a fornire prodotti e tool J2EE 1.3. Addirittura, mentre questo libro viene scritto, non esiste ancora alcun vendor che fornisca un implementazione completa della piattaforma J2EE 1.3. Gli sviluppatori devono assemblare più prodotti di vari vendor per costruire un implementazione completa della piattaforma J2EE 1.3 nel caso (insolito) in cui l applicazione dovesse realmente utilizzare ogni parte della piattaforma. Se la storia insegna, occorrerà un certo tempo prima che giungano sul mercato dei prodotti commerciali J2EE 1.4, sebbene questo non significhi affatto che si debba attendere. Volendo, è già possibile realizzare e distribuire applicazioni J2EE 1.4. Sun fornisce gratui-

13 01-CAP01_ok :52 Pagina 13 LE RAGIONI DI TANTO INTERESSE 13 tamente un ambiente di sviluppo J2EE 1.4, l SDK J2EE 1.4 (Software Development Kit), che include il codice sorgente di vari esempi: esso può essere utilizzato per iniziare a lavorare con J2EE 1.4 oggi stesso. Sebbene il prodotto gratuito SDK J2EE 1.4 non sia un prodotto commerciale perfettamente finalizzato, è più che sufficiente per iniziare a lavorare. Per maggiori dettagli, si visiti il sito Sun di J2EE a: Dato che J2EE definisce un insieme di funzionalità e servizi ricco e standardizzato, la parte più pesante e complessa del lavoro degli sviluppatori è già stata compiuta. I programmatori J2EE, non dovendo codificare le funzionalità di basso livello normalmente richieste dalla maggior parte delle applicazioni enterprise, possono così concentrarsi sulle peculiari caratteristiche organizzative o aziendali specifiche alla particolare applicazione. Consentire ai programmatori di concentrarsi sugli aspetti di più alto livello dell applicazione da sviluppare è un altro fattore che contribuisce ad aumentare la loro produttività generale. Esistono vari altri fattori che contribuiscono alla produttività dei programmatori, come l uso di convenzioni di codifica standardizzate a livello di azienda, la separazione della presentazione dell applicazione dalla sua logica, l adozione di processi di verifica strutturati e altro ancora. Il livello di produttività che possono raggiungere i programmatori dipende quindi da un vasto assortimento di fattori correlati. Fortunatamente, le piattaforme complete e robuste per lo sviluppo di applicazioni come J2EE contribuiscono notevolmente a incrementare la produttività dei programmatori in tutti gli stadi del processo di sviluppo di applicazioni enterprise. Il supporto per applicazioni EIS e sistemi legacy Qualunque piattaforma di sviluppo di applicazioni enterprise degna del suo nome fornisce supporto per l integrazione con (o addirittura l estensione di) applicazioni EIS (Enterprise Information System) esistenti e sistemi legacy più datati. Le applicazioni EIS forniscono i servizi informativi a livello aziendale. Esse memorizzano e supportano l elaborazione delle informazioni chiave dell organizzazione, costituendo quindi la sua infrastruttura informativa chiave. I vari sistemi informativi supportati da un applicazione EIS sono ben definiti e potrebbero essere accessibili ai client attraverso interfacce locali, remote o entrambe. Applicazioni per la gestione delle risorse umane, sistemi ERP (Enterprise Resource Planning) per la pianificazione delle risorse d impresa, applicazioni CRM (Customer Relationship Management) per la gestione delle relazioni con i clienti, mainframe con sistemi di elaborazione delle transazioni e sistemi con database legacy, sono tutti esempi di ambienti EIS che gli sviluppatori delle applicazioni enterprise attuali devono essere in grado di poter integrare, estendere o addirittura esporre come servizi Web. I sistemi legacy, sebbene raramente rilevanti nel caso di nuove aziende, costituiscono spesso l ossatura di organizzazioni già esistenti e più vecchie. Con il termine legacy ci si riferisce alle applicazioni EIS meno recenti, sebbene spesso i

14 01-CAP01_ok :52 Pagina CAPITOLO 1 due termini siano utilizzati in modo equivalente. Nel caso in cui si voglia fare una distinzione esplicita sulla base dell anzianità dei sistemi, il termine legacy indica i sistemi più vecchi (e probabilmente sorpassati) che costituiscono l infrastruttura informatica dell organizzazione. I sistemi legacy non possono più essere considerati tecnologicamente avanzati, ma rimangono di vitale importanza sebbene solitamente non siano sufficientemente flessibili per continuare a evolvere con l organizzazione. Quando le moderne applicazioni enterprise (come quelle create con J2EE) consentono di integrare ed estendere i sistemi EIS di un organizzazione, siano esse recenti o legacy, si possono ottenere enormi vantaggi. Invece di richiedere che tali sistemi siano riscritti a partire da zero, o di forzare l organizzazione a considerare la possibilità di abbandonarli a favore di soluzioni più recenti, le piattaforme di sviluppo di applicazioni enterprise come J2EE supportano con determinazione i sistemi enterprise già esistenti. Così facendo, si offre l opportunità agli sviluppatori delle applicazioni enterprise di fondere il passato con il presente riutilizzando (e potenzialmente estendendo) le funzionalità dei sistemi informativi esistenti. L integrazione con sistemi EIS e legacy è stato storicamente uno degli aspetti più difficili e frequenti nello sviluppo delle moderne applicazioni enterprise. Dato che molti sistemi EIS e legacy sono composti da una varietà di tecnologie (come CICS, IMS, SAP R/3, Siebel, i2 e così via) e soluzioni ad-hoc, la loro integrazione in nuove applicazioni enterprise è un compito sostanzialmente manuale. Per facilitare questo compito piuttosto noioso e per ridurre le possibilità di introduzione di errori da parte dei programmatori, le piattaforme come J2EE forniscono spesso un framework adattatore (adapter) o connettore (connector) che può essere utilizzato dai programmatori per integrare i sistemi legacy. Dato che l integrazione con i sistemi informativi esistenti è un requisito estremamente diffuso per le applicazioni enterprise, è molto probabile che gli adapter o i connector per i prodotti più diffusi siano già stati scritti (non è infrequente l esistenza di mercati software esclusivamente dedicati a questo tipo di particolari componenti). A volte, quando un particolare adapter o connector richiesto non è già disponibile, lo si deve appositamente codificare. In ogni caso, gli adapter o connector possono essere sviluppati impiegando un framework appositamente previsto (come quello supportato in J2EE) per fornire alle applicazioni enterprise l accesso ai sistemi informativi esistenti. 1.2 J2EE in aiuto Quando si considera l elevato numero di tentativi e peripezie associate allo sviluppo delle moderne applicazioni enterprise, si potrebbe essere tentati di concludere che esso comporta troppi rischi e sforzi per renderlo conveniente. Sebbene questo possa essere vero in certi casi, J2EE offre una piattaforma relativamente matura che concorre largamente a rendere il lavoro un relativo piacere anziché un insopportabile sofferenza.

15 01-CAP01_ok :52 Pagina 15 LE RAGIONI DI TANTO INTERESSE 15 I paragrafi seguenti introducono le principali caratteristiche e i vantaggi derivanti dall utilizzo di J2EE per realizzare applicazioni enterprise, offrendo una vista ad alto livello di alcune delle funzionalità chiave che verranno discusse più dettagliatamente nel seguito di questo stesso capitolo e nel resto del libro. Un architettura basata sulle componenti semplice e coerente J2EE supporta un modello semplificato di sviluppo di applicazioni basate su componenti nel quale le applicazioni enterprise sono assemblate con componenti software riutilizzabili scritte nel linguaggio di programmazione Java. Dato che J2EE si basa su J2SE (si ricordi che J2EE è in effetti una famiglia di funzionalità enterprise aggiunte alla piattaforma Java 2 Standard Edition), le applicazioni J2EE mantengono pienamente la promessa di portabilità di Java Scrivi una volta sola, esegui ovunque. Un applicazione J2EE realizzata in modo appropriato, quindi, potrà essere eseguita su qualunque server applicativo compatibile con J2EE, molti dei quali sono liberamente o commercialmente disponibili (si veda la Tabella 1.1 al termine di questo capitolo per un elenco di alcuni dei numerosi application server J2EE disponibili). NOTA Sebbene l architettura J2EE consenta di scrivere applicazioni enterprise portabili su differenti piattaforme, è abbastanza facile sviluppare applicazioni J2EE non portabili se non vi si presta la dovuta attenzione. Come si potrà vedere nei capitoli successivi, il programma Java BluePrints for Enterprise di Sun fornisce suggerimenti, configurazioni, codice e consigli per aiutare i programmatori J2EE a sviluppare applicazioni portabili. L architettura di J2EE è basata sulle componenti: le applicazioni J2EE consistono quindi di componenti software auto-contenute che vengono assemblate per ottenere un applicazione enterprise distribuita. Le varie componenti di cui è costituita un applicazione J2EE sono distribuite o messe in opera nella rete, dove vengono eseguite su computer differenti. Ognuna di esse risiede nel particolare livello dell ambiente di elaborazione di rete che corrisponde alle sue funzioni nell applicazione. J2EE supporta esplicitamente quattro livelli: (1) per le funzionalità client, (2) per il supporto Web, (3) per la logica business e (4) per l integrazione di EIS (come l accesso a un database legacy). Le componenti di presentazione o front-end che interagiscono con l utente finale sono localizzate logicamente nei livelli client, mentre quelle che forniscono funzionalità di accesso o di memorizzazione sono considerate parte del livello EIS back-end. Il livello intermedio che si trova logicamente fra i livelli frontend e back-end, d altro canto, supporta due sottolivelli. Il livello intermedio potrebbe consistere in un livello Web per le componenti che forniscono funzionalità basate su Internet e protocolli Web (come HTTP, HTML e XML) e un livello business costituito dalle componenti che catturano la logica business dell organizzazione. Alternativamente, i livelli Web e business

16 01-CAP01_ok :52 Pagina CAPITOLO 1 potrebbero essere partizionati logicamente in livelli totalmente distinti, ciascuno nel proprio: si otterrebbe in questo caso l architettura delle applicazioni distribuite a quattro livelli supportata da J2EE. Come illustrato nella Figura 1.3 (e spiegato dettagliatamente nel Capitolo 2), J2EE è un architettura flessibile che non costringe gli sviluppatori a utilizzare un numero di livelli prefissato e non specifica alcun partizionamento fisico per questi raggruppamenti logici. Sebbene J2EE supporti esplicitamente quattro livelli distinti (client, Web, business e EIS), questi livelli possono essere fisicamente distribuiti in più ambienti runtime per soddisfare al meglio le esigenze dell applicazione. Livello clienti Livello server Livello clienti Livello server Server Web Server Web Modello classico di applicazione client-server a due livelli Applicazione a tre livelli Server di logica business Livello clienti Livello Web Livello EIS Server Web Livello business L architettura multilivello di J2EE è molto flessibile nel partizionamento logico e fisico dei livelli. Applicazione a quattro livelli Figura 1.3 Le componenti J2EE possono essere partizionate logicamente in uno dei quattro livelli distinti: client, Web, business e EIS. Le applicazioni che hanno dei requisiti runtime modesti potrebbero eseguire i livelli Web e business (eventualmente anche il livello EIS) su un singolo computer, mentre potrebbe invece essere conveniente partizionare fisicamente applicazioni più esigenti con un computer (o cluster di computer) per ciascun livello.

17 01-CAP01_ok :52 Pagina 17 LE RAGIONI DI TANTO INTERESSE 17 RIMANDI L espressione applicazione distribuita multilivello si riferisce a un applicazione software le cui parti sono distribuite o messe in opera su più livelli di elaborazione di una rete. Nel Capitolo 2 si vedrà con precisione come J2EE supporti le applicazioni distribuite multilivello e come le componenti software auto-contenute vengano assemblate per formare le applicazioni complete. L architettura semplice e coerente basata sulle componenti utilizzata da J2EE aumenta la produttività dei programmatori in vari modi. Nei paragrafi seguenti vengono descritte le strategie più significative con le quali l approccio basato sulle componenti di J2EE consente di incrementare la produttività generale nello sviluppo di applicazioni enterprise. Promuove l impiego di codice riutilizzabile L approccio basato su componenti di J2EE forza la codifica delle funzionalità di un applicazione nella forma di componenti software auto-contenute aventi interfacce ben definite. Le componenti J2EE vengono assemblate fra di loro per formare delle applicazioni complete, consentendo così agli sviluppatori di comporre queste unità di funzionalità riutilizzabili in modo modulare a seconda delle esigenze. J2EE propone così agli sviluppatori un approccio tipo Lego relativamente semplice e molto produttivo per realizzare sofisticate applicazioni distribuite, nel quale le funzionalità dell applicazione sono praticamente composte inserendo i moduli opportuni. Facilita la manutenzione e l estensione Le componenti sono unità di funzionalità di programma auto-contenute che operano indipendentemente le une dalle altre. Le architetture basate su componenti generano applicazioni modulari che sono relativamente semplici da mantenere, aggiornare ed estendere. Nei modelli basati sulle componenti, le varie funzioni di un applicazione vengono partizionate in componenti software discrete e autonome. Gli sviluppatori possono assemblare rapidamente le applicazioni con le componenti opportune a seconda delle particolari funzionalità richieste. Data l unicità di ciascuna applicazione enterprise, questo flessibile processo di composizione fornisce agli sviluppatori varie tecniche per realizzare e configurare le proprie applicazioni a seconda dei loro requisiti, quali per esempio: il particolare client che verrà utilizzato dall utente finale, le considerazioni relative alla sicurezza, i requisiti relativi ai database e alle transazioni, le esigenze di scalabilità e così via. Supporta il packaging e il deployment delle componenti Grazie alla natura flessibile ed espandibile del modello a componenti di J2EE, i programmatori traggono beneficio dall elevata produttività perfino nelle fasi successive allo sviluppo principale, quando si effettua il packaging e il deployment del lavoro svolto. Invece di forzare delle regole rigide per il packaging e il deployment delle componenti, J2EE è intenzionalmente flessibile e lascia agli sviluppatori la libertà di creare le soluzioni che meglio soddisfano le loro esigenze specifiche. Come risultato, il packaging e il deployment delle componenti può essere effettua-

18 01-CAP01_ok :52 Pagina CAPITOLO 1 to singolarmente, collettivamente con librerie di componenti o globalmente nella forma di applicazioni. Inoltre, molte delle operazioni coinvolte nel packaging e nel deployment di un applicazione possono essere completamente automatizzate da appositi tool. Automatizzando questi compiti ripetitivi e noiosi, i programmatori possono dedicare il proprio tempo ad attività più produttive. Questo permette anche ai programmatori con competenze tecniche più limitate di effettuare il packaging e il deployment di applicazioni. NOTA Gli strumenti o tool di deployment aiutano a ridurre le possibilità di errori nella fase di deployment eliminando la necessità di installare e configurare individualmente le componenti per ciascuna macchina o cluster (i tool di deployment possono automatizzare il deployment di applicazioni in ambienti di tipo cluster). Permette la configurazione del comportamento nella fase di deployment È possibile configurare il comportamento dell applicazione nella fase di deployment perché le componenti J2EE possono contare sulla disponibilità a runtime dei servizi standard e possono interagire dinamicamente con le altre componenti tramite interfacce ben definite. Il comportamento dell applicazione può quindi essere definito da programma tramite un opportuno codice contenuto nella componente o in modo dichiarativo tramite istruzioni statiche (dichiarazioni) nei file del descrittore di deployment. I descrittori di deployment sono file XML utilizzati per comunicare le esigenze delle componenti di un applicazione a un tool di deployment, il quale controlla la configurazione runtime dell applicazione. I descrittori di deployment non sono codificati nell applicazione ma sono invece dichiarativi e dinamici (ovvero le istruzioni nel descrittore di deployment sono caricate e applicate a runtime). Essi consentono quindi la configurazione estremamente flessibile del comportamento di un applicazione, quali la gestione delle transazioni, i controlli di sicurezza, il pooling delle risorse e la gestione dello stato. Prevede esplicitamente dei ruoli (mansioni) specifici Le componenti sono delle unità di funzionalità software che possono essere assemblate in librerie o in applicazioni complete, cosa che favorisce una divisione precisa dei compiti: ciascun programmatore coinvolto ha quindi un ruolo specifico nel processo globale di sviluppo. Per esempio, gli autori dei contenuti Web possono dedicarsi alle componenti lato client mentre gli sviluppatori del database possono creare componenti che corrispondono alle proprie competenze. Nel frattempo, gli esperti del particolare dominio dell applicazione possono sviluppare le componenti che catturano la specifica logica business richiesta dall applicazione, mentre un altro sviluppatore (o gruppo di sviluppatori) si può occupare degli aspetti di packaging e deployment. In una situazione ideale, ciascuna persona coinvolta occupa il ruolo che meglio corrisponde alle proprie competenze e ai propri interessi personali, cosa che spesso consente di raggiungere i livelli di produttività individuale e di gruppo più elevati.

19 01-CAP01_ok :52 Pagina 19 LE RAGIONI DI TANTO INTERESSE 19 NOTA Le specifiche J2EE definiscono formalmente alcune mansioni, quali il fornitore delle componenti dell applicazione, lo sviluppatore delle componenti Web, lo sviluppatore del client, l assemblatore dell applicazione e il responsabile del deployment e dell amministrazione dell applicazione. Nel seguito di questo capitolo si analizzano in maggior dettaglio le mansioni previste da J2EE, che comportano una precisa divisione dei compiti che può contribuire ad aumentare la produttività individuale e di gruppo. Supporto built-in per la scalabilità e la sicurezza La scalabilità e la sicurezza sono requisiti praticamente irrinunciabili di qualunque applicazione enterprise. Applicazioni che non possono evolvere dinamicamente per adattarsi alle variazioni del carico e del pattern di utilizzazione degli utenti non possono essere adatte per applicazioni mission-critical o per organizzazioni particolarmente competitive. Indipendentemente dalla scalabilità, un applicazione vulnerabile in termini di sicurezza costituisce una seria minaccia per l organizzazione e può risultare nel lungo termine molto più costosa del tempo e del denaro risparmiati inizialmente. Per esempio vi può essere il rischio di vite umane nel caso di applicazioni mediche o aeronautiche compromesse. Anche in situazioni meno critiche le applicazioni enterprise devono comunque impedire l uso non autorizzato per proteggere l integrità dell organizzazione. ATTENZIONE Sebbene l impiego di applicazioni Java non sia previsto dove esiste il rischio di vite umane (le condizioni della licenza di Java proibiscono esplicitamente l uso della tecnologia nei sistemi medici e aeronautici, per esempio), la scalabilità e la sicurezza intrinseca di J2EE ne fanno un ottima scelta per applicazioni enterprise più tradizionali, dove mission-critical non comporti la perdita potenziale di vite umane. La scalabilità e la sicurezza sono talmente importanti che J2EE fornisce un supporto built-in per entrambe. Le componenti J2EE sono sempre eseguite nel contesto di un container che semplifica e automatizza lo scaling ( adattamento delle dimensioni ) delle applicazioni distribuite senza richiedere alcuno sforzo da parte del programmatore. Grazie alle caratteristiche di scalabilità intrinseca dei container J2EE non è necessario sviluppare del codice specifico per ogni applicazione dato che le capacità di scalabilità fondamentali sono automaticamente già disponibili a livello di piattaforma. Questo comporta anche un elevato grado di availability ( disponibilità ) delle applicazioni, sulle quali si può fare affidamento per supportare e raggiungere gli obiettivi dell organizzazione ventiquattr ore su ventiquattro. Analogamente, la piattaforma J2EE supporta un modello di sicurezza built-in che gestisce la sicurezza dell accesso ai servizi applicativi. J2EE supporta la sicurezza da programma, che consente agli sviluppatori di codificare esplicitamente i

20 01-CAP01_ok :52 Pagina CAPITOLO 1 controlli di autenticazione degli utenti e i controlli di accesso nelle componenti, e la sicurezza dichiarativa role-based che può essere specificata all atto del deployment di un applicazione. Mentre i controlli di sicurezza da programma possono verificare gli accessi all applicazione su base individuale, la sicurezza role-based permette a gruppi di individui di condividere i medesimi privilegi di accesso. Supportando direttamente sia i controlli di sicurezza in fase di sviluppo che in fase di deployment, J2EE offre molta flessibilità agli sviluppatori nell area della sicurezza. Grazie al supporto di J2EE per la gestione dei privilegi di accesso su base individuale e di gruppo (role-based), gli sviluppatori possono sfruttare la soluzione che meglio soddisfa le esigenze dell organizzazione con uno sforzo minimo. Sviluppato su basi stabili e affidabili J2EE è stata progettata fin dall inizio come piattaforma stabile e affidabile, dato il suo esplicito orientamento enterprise. La stabilità della piattaforma J2EE è in gran parte dovuta alle solide basi offerte dalla piattaforma J2SE sottostante e dal linguaggio di programmazione Java con il quale è realizzata. Quando Java fece la sua prima apparizione una decina di anni fa, introdusse la possibilità di sviluppare contenuti stabili e sicuri per il (nuovo, a quei tempi) World Wide Web. Grazie a Java si poterono inserire piccoli programmi direttamente nelle pagine Web standard. Le applet offrirono agli sviluppatori Web un modo stabile e sicuro per creare contenuti eseguibili e interattivi. Le applet eseguite nelle pagine Web dovevano rimanere confinate all interno di un ambiente di sicurezza controllato, il cosiddetto modello di sicurezza sandbox fornito dal browser, il quale impediva loro l accesso ad alcune parti del sistema di elaborazione dell utente. Le applet Java, le applicazioni, le componenti e tutte le altre forme di programmi Java traggono beneficio dal fatto che Java è un linguaggio fortemente tipizzato che non supporta il casting implicito, ovvero la conversione automatica fra tipi di dati differenti. Non esiste ambiguità nell utilizzo dei tipi dati in Java: i programmi devono dichiarare esplicitamente i tipi di dati che utilizzano e devono dichiarare esplicitamente il casting quando convertono fra un tipo e un altro. Java inoltre non supporta i puntatori, il cui utilizzo scorretto è spesso colpevole della corruzione dei dati e degli sconfinamenti di memoria tipici dei programmi scritti in linguaggi che supportano i puntatori (come C e C++). Java controlla anche i limiti degli array a runtime per garantire che gli indici e gli accessi che eccedono la capacità degli array possano essere intercettati e gestiti dal programma. Oltre alle caratteristiche di progettazione alla base della stabilità dei programmi Java, anche le caratteristiche del suo runtime contribuiscono a rendere questi programmi particolarmente affidabili. A differenza dei programmi tradizionali che consistono in codice nativo in linguaggio macchina eseguito direttamente nel particolare tipo di computer per il quale sono stati compilati, i programmi Java consistono in codice bytecode indipendente dalla specifica architettura hardware, eseguito nella macchina virtuale Java, o (JVM Java Virtual Machine). A runtime, le JVM convertono dinamicamente il bytecode nel codice