Una guida per principianti a Enterprise JavaBeans

Enterprise JavaBeans (EJB) ha generato un grande entusiasmo dall'annuncio del marzo 1998 della versione 1.0 della specifica Enterprise JavaBeans. Aziende come Oracle, Borland, Tandem, Symantec, Sybase e Visigenic, tra molte altre, hanno annunciato e / o fornito prodotti che aderiscono alle specifiche EJB. Questo mese daremo uno sguardo di alto livello a cos'è esattamente Enterprise JavaBeans. Esamineremo in che modo EJB differisce dal modello a componenti JavaBeans originale e discuteremo perché EJB ha generato un così enorme interesse.

Ma prima, un avviso: questo mese non esamineremo il codice sorgente o gli argomenti sulle procedure. Questo articolo non è un tutorial; piuttosto è una panoramica architettonica. EJB copre un vasto territorio e, senza prima aver compreso i concetti di base coinvolti, frammenti di codice e trucchi di programmazione sono privi di significato. Se c'è interesse da parte dei lettori di JavaWorld , gli articoli futuri potrebbero riguardare le specifiche dell'utilizzo dell'API Enterprise JavaBeans per creare i propri Enterprise JavaBeans.

Per capire perché EJB è così attraente per gli sviluppatori, abbiamo bisogno di un background storico. Per prima cosa, esamineremo la cronologia dei sistemi client / server e lo stato attuale delle cose. Quindi, discuteremo le varie parti di un sistema EJB: componenti EJB - che risiedono su un contenitore EJB in esecuzione all'interno di un server EJB - e oggetti EJB, che il client utilizza come una sorta di "controllo remoto" dei componenti EJB . Esamineremo i due tipi di EJB: sessione e oggetti entità . Leggerai anche di casa e telecomandointerfacce, che creano istanze EJB e forniscono l'accesso ai metodi di business di EJB, rispettivamente. Alla fine dell'articolo, avrai un'idea di come creare server estensibili utilizzando Enterprise JavaBeans. Ma prima, uno sguardo indietro nel tempo.

Cronologia client / server

Storia antica

All'inizio c'era il computer mainframe. Ed è stato bello. (O almeno così è stato, comunque.) Lo stato dell'arte nell'elaborazione delle informazioni negli anni '60 consisteva principalmente in macchine grandi e costose utilizzate dalle grandi organizzazioni per supportare le loro operazioni aziendali quotidiane. I minicomputer e la condivisione del tempo negli anni '70 hanno aumentato l'accessibilità della potenza di calcolo, ma le informazioni e l'elaborazione erano ancora centralizzate su singole macchine. I primi personal computer negli anni '80 hanno rapidamente ingombrato il panorama aziendale con migliaia di minuscole isole di informazioni, tutte instancabilmente sfornando rapporti di qualità variabile, perdendo dati critici quando si sono bloccati e diventando rapidamente incoerenti tra loro.

Client / server in soccorso

L'architettura client / server è una delle soluzioni più comuni all'enigma di come gestire la necessità sia di un controllo centralizzato dei dati che di una diffusa accessibilità dei dati. Nei sistemi client / server, le informazioni sono mantenute relativamente centralizzate (o sono partizionate e / o replicate tra server distribuiti), il che facilita il controllo e la coerenza dei dati, pur fornendo l'accesso ai dati di cui gli utenti hanno bisogno.

I sistemi client-server sono ora comunemente composti da vari numeri di livelli. Il vecchio mainframe standard o sistema di timesharing, in cui l'interfaccia utente viene eseguita sullo stesso computer del database e delle applicazioni aziendali, è noto come livello singolo. Tali sistemi sono relativamente facili da gestire e la coerenza dei dati è semplice perché i dati sono archiviati in un unico posto. Sfortunatamente, i sistemi a livello singolo hanno una scalabilità limitata e sono soggetti a rischi di disponibilità (se un computer è inattivo, l'intera azienda si interrompe), in particolare se è coinvolta la comunicazione.

I primi sistemi client / server erano a due livelli, in cui l'interfaccia utente veniva eseguita sul client e il database viveva sul server. Tali sistemi sono ancora comuni. Un tipo di server a due livelli da giardino esegue la maggior parte della logica aziendale sul client, aggiornando i dati condivisi inviando flussi di SQL al server. Questa è una soluzione flessibile, poiché la conversazione client / server avviene a livello della lingua del database del server. In un tale sistema, un client progettato in modo appropriato può essere modificato per riflettere nuove regole e condizioni aziendali senza modificare il server, purché il server abbia accesso allo schema del database (tabelle, viste e così via) necessario per eseguire le transazioni. Il server in un tale sistema a due livelli è chiamato server di database, come mostrato di seguito.

I server di database hanno però alcune responsabilità. Spesso l'SQL per una particolare funzione aziendale (ad esempio, l'aggiunta di un articolo a un ordine) è identico, ad eccezione dei dati che vengono aggiornati o inseriti, da una chiamata all'altra. Un server di database finisce per analizzare e rianalizzare SQL quasi identico per ciascuna funzione aziendale. Ad esempio, è probabile che tutte le istruzioni SQL per l'aggiunta di un articolo a un ordine siano molto simili, così come le istruzioni SQL per trovare un cliente nel database. Il tempo impiegato da questa analisi sarebbe meglio speso per l'elaborazione dei dati. (Ci sono rimedi a questo problema, incluse cache di analisi SQL e procedure memorizzate.) Un altro problema che si presenta è il controllo delle versioni dei client e del database allo stesso tempo: tutte le macchine devono spegnersi per gli aggiornamenti,e i client o server che restano indietro nella versione del software in genere non sono utilizzabili fino a quando non vengono aggiornati.

Server delle applicazioni

Un'architettura del server di applicazioni (vedere l'immagine successiva) è un'alternativa popolare all'architettura di un server di database perché risolve alcuni dei problemi dei server di database.

Un ambiente server di database di solito esegue metodi aziendali sul client e utilizza il server principalmente per la persistenza e il rispetto dell'integrità dei dati. In un server delle applicazioni, i metodi aziendali vengono eseguiti sul server e il client richiede che il server esegua questi metodi. In questo scenario, il client e il server in genere utilizzeranno un protocollo che rappresenta una conversazione a livello di transazioni aziendali, invece che a livello di tabelle e righe. Tali server delle applicazioni spesso hanno prestazioni migliori rispetto alle controparti del database, ma soffrono comunque di problemi di controllo delle versioni.

Sia il database che i sistemi applicativi possono essere migliorati aggiungendo ulteriori livelli all'architettura. I cosiddetti sistemi a tre livelli collocano un componente intermedio tra il client e il server. Un intero settore, il middleware, è nato per far fronte alle responsabilità dei sistemi a due livelli. Un monitor per l'elaborazione delle transazioni,un tipo di middleware, riceve flussi di richieste da molti client e può bilanciare il carico tra più server, fornire il failover quando un server si guasta e gestire le transazioni per conto di un client. Altri tipi di middleware forniscono la traduzione del protocollo di comunicazione, consolidano le richieste e le risposte tra client e più server eterogenei (questo è particolarmente popolare quando si tratta di sistemi legacy nella reingegnerizzazione dei processi aziendali) e / o forniscono la misurazione dei servizi e le informazioni sul traffico di rete.

Più livelli offrono una flessibilità e interoperabilità che ha portato a sistemi con più di questi tre livelli di servizio. Ad esempio, i sistemi a più livelli sono generalizzazioni di sistemi a tre livelli, ogni livello di software fornisce un diverso livello di servizio ai livelli sopra e sotto di esso. La prospettiva a più livelli considera la rete come un pool di servizi distribuiti, piuttosto che semplicemente il mezzo per un client per accedere a un singolo server.

Poiché i linguaggi e le tecniche orientati agli oggetti sono diventati di moda, i sistemi client / server si sono spostati sempre più verso l'orientamento agli oggetti. CORBA (Common Object Request Broker Architecture) è un'architettura che consente agli oggetti all'interno delle applicazioni, anche agli oggetti scritti in linguaggi diversi, di essere eseguiti su macchine separate, a seconda delle esigenze di una determinata applicazione. Le applicazioni scritte anni fa possono essere pacchettizzate come servizi CORBA e interagire con i nuovi sistemi. Enterprise JavaBeans, progettato per essere compatibile con CORBA, è un'altra voce nell'anello del server delle applicazioni orientato agli oggetti.

Lo scopo di questo articolo non è fornire un tutorial sui sistemi client / server, ma è stato necessario fornire alcune informazioni di base per definire il contesto. Ora diamo un'occhiata a cosa ha da offrire EJB.

Enterprise JavaBeans e server delle applicazioni estensibili

Ora che abbiamo esaminato un po 'di storia e abbiamo capito cosa sono i server delle applicazioni, diamo un'occhiata a Enterprise JavaBeans e vediamo cosa offre in quel contesto.

L'idea di base alla base di Enterprise JavaBeans è fornire una struttura per componenti che possono essere "collegati" a un server, estendendo così le funzionalità di quel server. Enterprise JavaBeans è simile ai JavaBeans originali solo in quanto utilizza concetti simili. La tecnologia EJB non è regolata dalla specifica JavaBeans Component, ma dalla specifica Enterprise JavaBeans completamente diversa (e massiccia) . (Vedere Risorse per i dettagli su questa specifica.) La specifica EJB richiama i vari giocatori nel sistema client / server EJB, descrive come EJB interagisce con il client e con i sistemi esistenti, enuncia la compatibilità di EJB con CORBA e definisce le responsabilità per i vari componenti del sistema.

Obiettivi Enterprise JavaBeans

La specifica EJB cerca di raggiungere diversi obiettivi contemporaneamente:

  • EJB è progettato per semplificare la creazione di applicazioni per gli sviluppatori, liberandoli dai dettagli di sistema di basso livello relativi alla gestione di transazioni, thread, bilanciamento del carico e così via. Gli sviluppatori di applicazioni possono concentrarsi sulla logica di business e lasciare i dettagli della gestione dell'elaborazione dei dati al framework. Per applicazioni specializzate, tuttavia, è sempre possibile andare "sotto il cofano" e personalizzare questi servizi di livello inferiore.

  • La specifica EJB definisce le strutture principali del framework EJB, quindi definisce in modo specifico i contratti tra di esse. Le responsabilità del client, del server e dei singoli componenti sono chiaramente indicate. (Esamineremo quali sono queste strutture tra un momento.) Uno sviluppatore che crea un componente Enterprise JavaBean ha un ruolo molto diverso da qualcuno che crea un server conforme a EJB e la specifica descrive le responsabilità di ciascuno.

  • EJB mira a essere il modo standard per la creazione di applicazioni client / server nel linguaggio Java. Proprio come i JavaBeans originali (o componenti Delphi, o qualsiasi altra cosa) di diversi fornitori possono essere combinati per produrre un client personalizzato, i componenti del server EJB di diversi fornitori possono essere combinati per produrre un server personalizzato. I componenti EJB, essendo classi Java, verranno ovviamente eseguiti su qualsiasi server conforme a EJB senza ricompilazione. Questo è un vantaggio che le soluzioni specifiche per piattaforma non possono sperare di offrire.

  • Infine, EJB è compatibile e utilizza altre API Java, può interagire con app non Java ed è compatibile con CORBA.

Come funziona un sistema client / server EJB

Per capire come funziona un sistema client / server EJB, è necessario comprendere le parti di base di un sistema EJB: il componente EJB, il contenitore EJB e l'oggetto EJB.

Il componente Enterprise JavaBeans

Un Enterprise JavaBean è un componente, proprio come un JavaBean tradizionale. Enterprise JavaBeans vengono eseguiti all'interno di un contenitore EJB, che a sua volta viene eseguito all'interno di un server EJB. Qualsiasi server che può ospitare un contenitore EJB e fornirgli i servizi necessari può essere un server EJB. (Ciò significa che molti server esistenti possono essere estesi per essere server EJB, e in effetti molti fornitori hanno raggiunto questo obiettivo o hanno annunciato l'intenzione di farlo)

Un componente EJB è il tipo di classe EJB che molto probabilmente verrà considerato un "Enterprise JavaBean". È una classe Java, scritta da uno sviluppatore EJB, che implementa la logica di business. Tutte le altre classi nel sistema EJB supportano l'accesso client o forniscono servizi (come la persistenza e così via) alle classi dei componenti EJB.

Il contenitore Enterprise JavaBeans

Il contenitore EJB è dove "risiede" il componente EJB. Il contenitore EJB fornisce servizi come gestione di transazioni e risorse, controllo delle versioni, scalabilità, mobilità, persistenza e sicurezza ai componenti EJB che contiene. Poiché il contenitore EJB gestisce tutte queste funzioni, lo sviluppatore del componente EJB può concentrarsi sulle regole di business e lasciare al contenitore la manipolazione del database e altri dettagli così fini. Ad esempio, se un singolo componente EJB decide che la transazione corrente deve essere interrotta, dice semplicemente al suo contenitore (in un modo definito dalle specifiche EJB, e il contenitore è responsabile dell'esecuzione di tutti i rollback o di qualsiasi cosa sia necessaria per annullare un transazione in corso. In genere esistono più istanze del componente EJB all'interno di un singolo contenitore EJB.

L'oggetto EJB e l'interfaccia remota

I programmi client eseguono metodi su EJB remoti tramite un oggetto EJB. L'oggetto EJB implementa l '"interfaccia remota" del componente EJB sul server. L'interfaccia remota rappresenta i metodi "aziendali" del componente EJB. L'interfaccia remota svolge il lavoro effettivo e utile di un oggetto EJB, come la creazione di un modulo d'ordine o il rinvio di un paziente a uno specialista. Discuteremo l'interfaccia remota in modo più dettagliato di seguito.