2010-01-21 12 views
8

Sto cercando di capire dove parte della mia logica di applicazione dovrebbe andare nella mia applicazione Java EE. Sono nuovo di Java EE e sto cercando di caricare un sacco di dati non strutturati da un database legacy e di costruire un modello di oggetto pulito per l'utilizzo da parte della mia applicazione. Dalle mie indagini vedo che le app Java EE hanno 2 componenti, componenti Enterprise Bean e Web Application. Questa parte della mia applicazione sarà responsabile del caricamento dei dati, della costruzione del modello dell'oggetto e dell'invio di messaggi tramite JMS in base allo stato corrente dei dati alle parti interessate. I dati verranno aggiornati tramite la sincronizzazione con il database e dai messaggi ricevuti tramite JMS da applicazioni Java remote.Logica applicazione Java EE/Glassfish

È un EJB il luogo corretto per questo tipo di funzionalità? Come posso avviare l'inizializzazione del mio modello di oggetto (metodo principale equivalente Java App)? Qual è la migliore pratica per creare un evento a tempo per rivedere il modello a oggetti e inviare messaggi tramite JMS?

Ho letto un numero di articoli su Java EE, Glassfish, EJB ... ma ancora non sento di avere una visione chiara di dove dovrei scrivere questa funzionalità. Gli esempi che ho visto di EJB tendono ad essere intorno a chiamate di metodo dirette sui bean dalle applicazioni client.

Al momento ritengo che un'applicazione Java possa svolgere il lavoro ma stiamo cercando di utilizzare RMI e i client Web in futuro.

risposta

7

Java EE è tradizionalmente utilizzato per lo stile architettonico client/server. La logica aziendale viene implementata nei bean di sessione EJB, che vengono solitamente richiamati da una richiesta Web, un messaggio JMS o una chiamata remota RIO-IIOP.

È un EJB la posizione corretta per questo tipo di funzionalità ?

La logica va nel bean. Ma ci sono diversi tipi di EJB.

Come posso iniziare l'inizializzazione di mio modello di oggetti (metodo principale Java App equivalente)?

Non esiste un metodo main. Ma ci sono ancora alcuni modi per eseguire alcune elaborazioni corrispondenti alla distribuzione dell'applicazione e/o alla distribuzione. Puoi guardare ServletContextListener, Glassfish lifecycle module (non-standard) o forse i fagioli Singleton appena introdotti e l'annotazione @Startup.

Qual è la migliore pratica per la creazione di un evento programmato di rivedere il modello a oggetti e inviare messaggi tramite JMS?

È possibile creare un EJB Timer che verrà chiamato periodicamente. Se hai bisogno di caricare il modello una volta in memoria, ti suggerisco di guardare anche i fagioli Singleton. Con EJB 3.0, il problema era come fare il start the timer automatically, ma penso che abbiano migliorato questo in EJB 3.1 ei timer possono essere started automatically by the application server quando l'applicazione viene distribuita usando l'annotazione @Scheduled. Quindi potrebbe in qualche modo fornire un punto di partenza desiderato come richiesto nella domanda precedente.

È possibile inviare messaggi JMS da qualsiasi bean. JMS un sistema esterno proprio come il database. Il messaggio JMS viene ricevuto usando un tipo speciale di EJB chiamato Message-driven bean (MDB).

L'applicazione non sarà un'applicazione client-server di database EJB Web tradizionale, ma dovrebbe essere possibile con Java EE, che è in definitiva un modello molto flessibile.

2

Come hai detto, gli esempi tendono a coinvolgere l'invocazione diretta. Nella mia esperienza, non sono solo gli esempi. Nessuna delle app Java EE * 1 che ho visto utilizza un grafico a oggetti di lunga durata come descrivi, ma in genere operano su un singolo record (+ figli/correlato) in risposta a una richiesta web, una chiamata al servizio web o un messaggio JMS .

Le vostre esigenze rompono lo stampo e Java EE potrebbe non essere la soluzione migliore. Al valore nominale, il tipo di codice che descrivi appartiene al contenitore EJB, ma a quel contenitore manca un buon contesto di lunga vita per ancorare il tuo grafo di oggetti. Il contenitore Web ha un tale contesto, ma manca di strutture per i timer e la gestione dei messaggi e così via. Il costo dell'abbandono di J2EE e l'uso di una semplice applicazione Java, invece, ovviamente vanno a discapito delle funzionalità del server delle applicazioni per l'amministrazione, la distribuzione e il monitoraggio.

Una buona scelta potrebbe essere quella di tornare a ciò che ha reso il Spring Framework grande. Non so se hai familiarità con la storia di J2EE, ma l'improvvisa, enorme popolarità di Spring Framework e di Hibernate è stata essenzialmente una ribellione della community contro il contenitore EJB, versioni 1.x/2.x. Ciò che la Spring WebApplicationContext ti ha dato era un robusto back-end transazionale per un'applicazione web, sfruttando MDB e JTA, ignorando al contempo il maggior numero possibile di EJB Container * 2 (e semplificando enormemente i test unitari nel processo). Puoi adottare questo approccio e creare la tua applicazione come un singolo file WAR e avviare i servizi di back-end con Spring.

Un'alternativa interessante è quella di abbandonare del tutto il server di applicazioni Java EE e creare la propria applicazione sopra il framework OSGi. Questo è l'approccio della "normale applicazione Java", con il runtime OSGi che fornisce la console di amministrazione e le funzionalità di distribuzione a caldo che avresti dovuto eseguire separatamente. I bit mancanti dell'infrastruttura sono il timer (utilizzare Quartz) ei bean basati sui messaggi (utilizzare direttamente l'API JMS). Un'applicazione OSGi finisce per assomigliare un po 'al kernel Linux e al processo di avvio, con servizi distribuiti e avviati in base ai livelli di esecuzione. Afferra Apache Felix e dai un'occhiata.

Non hai menzionato la scala. Se il grafico dell'oggetto è enorme, esaminare tecnologie come GigaSpaces o Coherence.

** 1) Sun ha preso il '2' fuori l'acronimo con l'introduzione di EJB3 *

** 2) 2.x Entity EJB erano la parte peggiore. EJB 3 può essere visto come un "se non puoi batterli, unisciti a loro" per standardizzare Hibernate. *

+0

> '" se non puoi batterli, unisciti a loro "sforzo per standardizzare Hibernate' - In realtà un modello simile a quello di Hibernate era originariamente considerato per EJB 1. Sfortunatamente i pochi ingegneri dell'epoca che erano a favore di quello perso ai loro amici che insistevano sugli Entity Beans che alla fine arrivarono in EJB 1. Ironia della sorte, i primi bean di EJB 1 sono stati implementati sotto il cofano da TopLink, il progetto era Hibernate era la versione open source economica di (Hibernate divenne famoso per questo , ma non ha inventato il modello, TopLink era MOLTO prima) –

+0

Sì, lo so, ho avuto il dispiacere di lavorare con il server delle applicazioni pre-WebLogic di Oracle, Orion. TopLink e l'oscuramento automatico della password nei file XML sono state le uniche parti valide. TopLink nasce infatti nel mondo SmallTalk. Non ho mai usato SmallTalk da solo, ma ho fatto manutenzione su un'applicazione Java 1.1.8 scritta da un gruppo di laureati SmallTalk. Ad oggi è il miglior codice Java orientato agli oggetti che abbia mai visto.SmallTalk ha creato l'eccellenza. – Barend