Lo stato del middleware dell'applicazione Java, parte 1

Il client / server è morto. Questo è il ronzio ora che le nuove tecnologie basate su Internet stanno fiorendo. Ma queste nuove tecnologie sono semplicemente la naturale evoluzione degli approcci precedenti, implementate con protocolli più recenti e più aperti e progettate per fornire maggiore scalabilità, gestibilità e diversità.

L'entità di questa evoluzione è sbalorditiva. La maggior parte dei principali fornitori di client / server ha modernizzato i propri prodotti e ora indirizza i propri investimenti di marketing verso tecnologie a tre livelli. Nella maggior parte dei casi, i prodotti più recenti sono incentrati su Java e sul protocollo Internet. Ad esempio, ho identificato almeno 46 prodotti middleware Java all'ultimo conteggio. Due anni fa sarebbe stato difficile trovare la metà di quel numero.

Questo è il primo di una serie di articoli in due parti dedicati alla spiegazione del middleware Java generico nelle sue forme attuali. In questo primo articolo, esaminerò le caratteristiche dei prodotti attuali e spiegherò perché queste funzionalità sono importanti. Nella seconda parte, Anil Hemrajani esaminerà Enterprise JavaBeans (EJB) e mostrerà come l'attuale generazione di prodotti middleware Java si relaziona e supporta questo importante standard di componenti.

sfondo

Prima di tutto, definiamo il middleware Java.Il termine comprende i server delle applicazioni come BEA WebLogic, prodotti di messaggistica come ActiveWorks di Active Software e SpiritWAVE di Push Technologies e prodotti ibridi che si basano su una legacy DBMS e aggiungono funzionalità di esecuzione di oggetti Java basate su server. Avrei potuto concentrarmi su un segmento più ristretto, come i server applicativi, ma sarebbe stato ingiusto nei confronti dei molti prodotti che non rientrano precisamente in questa categoria ma che tuttavia dovrebbero essere considerati per applicazioni multilivello. Inoltre, anche tra i server delle applicazioni esiste un ampio spettro, inclusi quelli che sono principalmente server servlet e quelli basati su ORB o OODB. Tracciare un confine tra tutti questi prodotti si rivela sempre più difficile. La caratteristica unificante, tuttavia,è che tutti tentano di risolvere il problema della distribuzione di applicazioni su più livelli utilizzando le tecnologie Java e Internet.

Il business case per utilizzare Java nel middleware è convincente; tra i vantaggi offerti dal middleware Java ci sono i seguenti:

  • La capacità di Internet di interconnettere economicamente uffici e organizzazioni

  • La necessità per le organizzazioni di cooperare condividendo dati e processi aziendali

  • La volontà di consolidare i servizi generici e la gestione di questi servizi

  • Il desiderio di fornire una gestione centralizzata delle applicazioni, inclusi avvio, arresto, manutenzione, ripristino, bilanciamento del carico e monitoraggio

  • Il desiderio di utilizzare servizi e protocolli aperti

  • Il desiderio di ridistribuire la logica aziendale a piacimento e non vincolato dall'infrastruttura; ciò richiede l'utilizzo di API e protocolli aperti, ampiamente supportati dalla maggior parte dei prodotti di infrastruttura

  • La necessità di supportare applicazioni cooperative ad architettura mista

  • Il desiderio di spostare le decisioni sull'infrastruttura di rete e di servizio fuori dallo spazio applicativo, in modo che i gestori di sistema possano prendere decisioni sull'infrastruttura senza essere ostacolati da applicazioni che dipendono da protocolli o funzionalità proprietari

  • Il desiderio di ridurre la diversità e il livello di competenze del personale di programmazione necessarie e ridurre al minimo la necessità di competenze avanzate nella costruzione di strumenti all'interno dei progetti

  • Il desiderio di sfruttare la competenza orientata agli oggetti estendendola al regno dei server, da cui prodotti server orientati agli oggetti più recenti e ponti relazionali da oggetto

L'obiettivo del middleware è centralizzare l'infrastruttura software e la sua distribuzione. Client / server nasce da un'era di integrazione all'interno di un unico reparto. Le organizzazioni ora tentano comunemente l'integrazione oltre i confini dipartimentali, anche da un'organizzazione all'altra. Internet, che attira le aziende con la sua capacità di fungere da rete globale che consente a reparti e partner di interconnettersi in modo efficiente e rapido, ha generato la domanda di questa integrazione.

Java fornisce una lingua franca per interconnettere facilmente dati e applicazioni oltre i confini dell'organizzazione: in un ambiente globale distribuito, in cui non hai il controllo sulle scelte tecnologiche che i tuoi partner possono fare, le aziende intelligenti scelgono standard aperti e indipendenti dalla piattaforma. Le aziende non possono prevedere chi diventerà loro clienti, partner o sussidiarie due anni dopo, quindi non è sempre possibile pianificare un'infrastruttura comune con i propri partner. In questa situazione incerta, la decisione migliore potrebbe essere quella di utilizzare le tecnologie più universali e adattabili possibili.

Java ti consente di ridurre il numero di linguaggi di programmazione e piattaforme che il tuo personale deve comprendere. Perché? Perché Java è ora distribuito in contesti diversi come browser Internet, procedure memorizzate all'interno di database, oggetti aziendali all'interno di prodotti middleware e applicazioni lato client.

All'età di tre anni, tuttavia, la tecnologia Java è ancora piuttosto immatura, e questo è vero per i prodotti discussi in questo articolo. D'altra parte, ora potremmo essere in un'era in cui i prodotti non raggiungono mai veramente la maturità, perché le tecnologie sottostanti su cui si basano cambiano così rapidamente. In effetti, ho riscontrato problemi significativi praticamente con ogni prodotto middleware che ho utilizzato, inclusi prodotti apparentemente maturi che sono stati sul mercato per alcuni anni e sono usciti recentemente con nuove significative funzionalità. Il punto è che, nel momento in cui un fornitore riesce a risolvere i problemi, sono state aggiunte nuove funzionalità. Il ciclo per l'aggiunta di nuove funzionalità è ora molto più breve di quanto non sia mai stato, quindi i prodotti non hanno abbastanza tempo per diventare stabili prima di includere il prossimo set di funzionalità principali.Questo potrebbe essere qualcosa a cui dobbiamo abituarci e apprendere i punti di forza e di debolezza dei prodotti che scegliamo è una parte importante di qualsiasi ciclo di progettazione e prototipo dell'applicazione.

Obiettivi per il middleware

Lo standard del componente middleware EJB è stato sviluppato con i seguenti obiettivi:

  • Per fornire l'interoperabilità dei componenti. I bean enterprise sviluppati con strumenti diversi lavoreranno insieme. Inoltre, i bean sviluppati con strumenti diversi verranno eseguiti in qualsiasi ambiente EJB.

  • Fornire un modello di programmazione facile da usare mantenendo l'accesso alle API di basso livello.

  • Per affrontare i problemi del ciclo di vita, inclusi sviluppo, distribuzione e runtime.

  • Fornire compatibilità con le piattaforme esistenti, che consente di estendere i prodotti esistenti per fornire supporto per EJB.

  • Per mantenere la compatibilità con altre API Java.

  • Per fornire l'interoperabilità tra EJB e applicazioni non Java.

  • Per essere compatibile con CORBA.

L'obiettivo dello standard EJB è quindi la creazione di uno standard di interoperabilità per il middleware Java, proteggendo i programmatori dal dover affrontare molti dei problemi difficili che sorgono durante lo sviluppo di applicazioni distribuite. Ciò consente agli sviluppatori di software di concentrarsi sulla logica aziendale invece di scrivere sofisticate infrastrutture e strumenti interni. Di conseguenza, le aziende possono investire la maggior parte delle proprie risorse educative nella formazione del personale nei processi aziendali, che in genere è ciò che fornisce il maggior profitto.

All'elenco sopra, aggiungo i seguenti obiettivi aggiuntivi per il middleware Java di classe enterprise. Queste funzionalità del prodotto sono necessarie a lungo termine per eseguire e mantenere con successo un ambiente basato su middleware:

  • Dovrebbe ospitare l'interconnessione di più unità aziendali, aziende e clienti in un'infrastruttura distribuita senza compromettere la sicurezza o creare caos

  • Dovrebbe consentire meccanismi di controllo dell'accesso flessibili ma affidabili per garantire che i dati dei partner commerciali siano accessibili solo nei modi previsti e solo dalle parti designate

  • Dovrebbe consentire agli amministratori di sistema di gestire un ambiente di elaborazione distribuito contenente un gran numero di componenti della logica di business in modo uniforme, senza dover comprendere o applicare procedure univoche a componenti particolari

  • dovrebbe consentire agli amministratori di sistema di effettuare selezioni dei componenti dell'infrastruttura senza influire sulle applicazioni e di ottimizzare e ridimensionare tali componenti e disporre di un mezzo uniforme e generico per misurare le prestazioni e le esigenze di risorse di tutte le applicazioni

  • Dovrebbe consentire il riposizionamento dei componenti aziendali tra client e server senza influire sulle architetture di entrambi

  • Dovrebbe fornire un meccanismo di sicurezza che consenta a determinati utenti di aggiungere nuovi componenti, senza dover dare all'amministratore del server l'accesso a tutti i componenti e le fonti di dati (questa è una grande opportunità per capacità a valore aggiunto, poiché è fondamentale per le applicazioni extranet e di partnership )

Componenti e funzionalità delle piattaforme middleware Java

La categoria in più rapida crescita del middleware Java oggi è probabilmente quella dei server delle applicazioni. Tuttavia, è essenziale realizzare l'ampia varietà di server delle applicazioni (e altri tipi di prodotti middleware) esistenti. Le differenze tra le categorie di prodotti middleware Java oggi sono rappresentate non da una linea ma da un vasto continuum middleware. Discuterò ora le funzionalità del middleware Java, sulla base dei miei confronti di lavoro, che comprendono tutte le classi di prodotti middleware Java che conosco.

Modelli di oggetti, componenti e contenitori

I componenti dell'applicazione devono aderire a un modello di distribuzione runtime, che specifica come il componente comunica con il suo ambiente; (possibilmente) come viene installato, avviato, arrestato e chiamato; e come accede a servizi importanti per il suo ambiente. I più diffusi modelli di runtime e contenitori dei componenti server basati su Java includono RMI, EJB, CORBA, DCOM, servlet, JSP (Java Server Pages) e procedure memorizzate Java. Inoltre, i modelli dei componenti possono essere espressi in una varietà di linguaggi sottostanti, inclusi Java, IDL, C ++ e molti altri.

C'è una sovrapposizione con vari modelli di componenti. Ad esempio, RMI è un modello a componenti banali con funzionalità di base per l'attivazione e la posizione degli oggetti ed è principalmente uno standard di chiamata remota, mentre EJB sfrutta RMI e specifica RMI come modello di chiamata dell'oggetto principale. EJB supporta anche CORBA. In effetti, nessuno di questi modelli è esclusivo e molti server di applicazioni Java supportano la maggior parte o tutti i modelli sopra.

Molti server middleware Java eseguono più istanze di oggetti di business (che il mondo CORBA ora chiama servant) all'interno di una singola macchina virtuale Java (JVM). La protezione dai tipi del linguaggio Java consente a un singolo processo JVM di soddisfare le richieste di più client e utilizzare strutture di dati del programma e programmi di caricamento classi per mantenere separati i dati dei client. Finché i servant non impiegano i propri metodi nativi, non è possibile per un servant arrestare altri servant se si blocca (a meno che non incontri un bug nella stessa JVM) o accedere a dati privati ​​di altre classi . Un server di oggetti progettato correttamente proteggerà i suoi oggetti privati ​​e impedirà agli oggetti errati di accedere a ciò che appartiene ad altri oggetti.

Tuttavia, i dati dichiarati statici in una classe Java possono essere condivisi tra i client all'interno della stessa JVM se i client utilizzano lo stesso programma di caricamento classi, quindi è necessario definire le regole per stabilire quando una JVM separata (o l'equivalente di una JVM separata che utilizza la memoria- tecniche di partizionamento) o un programma di caricamento classi separato è necessario per fornire a un client il proprio spazio dati statico. Tali regole sono state specificate per gli applet, ma non per altri ambienti di esecuzione. Il server Web Java di Sun utilizza una singola JVM per tutti i servlet e uno spazio dei nomi di classe separato per i servlet con una base di codice diversa. EJB aggira il problema vietando i dati statici non definitivi.

Le prestazioni possono essere migliorate se gli oggetti vengono disattivati ​​o passivati ​​quando non sono in uso, liberando risorse come le connessioni al database. Per questo motivo, molti server passivano e riattivano gli oggetti in base alle esigenze. Allo stesso modo, alcuni prodotti mantengono gli oggetti creati di frequente in un pool o in una cache in uno stato inizializzato e pronti per l'uso immediato. Il contenitore di oggetti deve gestire la passivazione e la riattivazione, nonché le risorse in pool interessate dalla passivazione.

Compatibilità EJB (versione)

Il modello EJB sta già diventando universalmente supportato. Quasi tutti i fornitori di middleware hanno promesso di supportarlo e molti lo fanno già. Inoltre, l'Object Management Group (OMG) ha incorporato una mappatura a EJB come parte della proposta di specifica del componente CORBA. È difficile immaginare che anche Microsoft, l'unica e risoluta resistenza, alla fine non cederà e fornirà contenitori EJB per DCOM.

Sebbene diversi middleware compatibili con EJB possano distribuire e gestire gli stessi componenti dell'applicazione (purché tali componenti utilizzino solo le funzionalità EJB richieste dallo standard), esiste ancora una grande quantità di variazione tra i server compatibili con EJB. Per prima cosa, la specifica EJB stessa si sta evolvendo. Una domanda importante quando si valutano i prodotti middleware Java, quindi, è: il server supporta l'ultima versione di EJB o supporta solo una versione precedente? Un'altra domanda chiave è: il prodotto è incentrato su EJB o il supporto EJB è incluso solo nelle funzionalità a valore aggiunto del prodotto (e quindi non disponibile quando vengono utilizzati servizi EJB o API)? E infine: quali funzionalità EJB opzionali sono incluse (ad esempio, bean di entità e persistenza gestita dal contenitore)?