Come strutturare un sistema Java EE? Come viene definito il termine applicazione e quindi il contenuto di una EAR?

Question

Sono in procinto di progettare un sistema di compilazione e la struttura di directory per un sistema software di grandi dimensioni sviluppato con Java EE 5. Il sistema di compilazione verrà implementato utilizzando ant.

Abbiamo diversi servizi diversi, che sono raggruppati tematicamente. Ogni servizio offre un servizio Web o EJB. Ogni servizio viene eseguito su un cluster di server applicazioni dedicato. Pertanto, abbiamo più cluster e alcuni di questi cluster possono essere raggruppati logicamente per argomenti.

Ho letto definizioni ed esempi generici, ma sono ancora confuso sulla terminologia Java EE:

• Che cos'è un'applicazione Java EE? E quindi, qual è il contenuto di un file EAR?
• Che cos'è un progetto Java EE? (il termine viene utilizzato da Netbeans e nelle Convenzioni di progetto delle linee guida sui progetti Java per le applicazioni aziendali)

Devo mettere tutti i file EJB e WAR-module-package-files in una singola EAR, in modo che questa singola EAR contenga il nostro sistema completo?

O metto ogni gruppo di servizi in una EAR, nonostante il fatto che questi servizi siano raggruppati solo logicamente ma non tecnicamente?

O assemblare un EAR separato per ciascun servizio, ovvero il più delle volte contenente solo un singolo file jar EJB e talvolta EJB e un file WAR?

O rifiuto il concetto di applicazioni e semplicemente costruisco file EJB e WAR, in modo da avere esattamente un file di distribuzione per ciascun cluster di server delle applicazioni?

Suppongo che la mia domanda principale sia: quali sono i vantaggi del confezionamento dei file EAR?

Per come la vedo al momento, c'è solo la necessità di file EAR-EJB e WAR e inoltre il concetto di sottoprogetto nidificato nel sistema ant-build e la struttura di directory della nostra fonte?

Modifica: grazie mille per le risposte! Mi sembra che un'applicazione inserita in un orecchio sia un sottosistema piuttosto atomico. Quindi suppongo che avrò una struttura di sottoprogetto nidificata (solo logica, visibile solo al sistema di compilazione e nella struttura di directory del sorgente) e una quantità piuttosto grande di EAR, ognuna di quelle che contengono principalmente solo un ejb-jar e / o modulo di guerra e implementazione di un singolo servizio (che viene distribuito su un singolo cluster di server delle applicazioni).

Answer 1

Penso che ciò che decidi di inserire in ciascuna EAR sia regolato da questioni organizzative e tecniche.

Penso che il ruolo tecnico più importante di una EAR sia la radice di un classloader in un ambiente di runtime. Ciò significa normalmente che è possibile distribuire diverse versioni delle librerie e le proprie classi in diverse EAR. Ciò significa che è necessario mantenere il percorso di classe radice del contenitore abbastanza vuoto (o come fornito dal fornitore del contenitore), poiché potrebbe consentire a un contenitore fisico di servire più applicazioni utilizzando librerie eventualmente in conflitto. Questa è un'ottima notizia se stai sviluppando un numero di applicazioni diverse utilizzando una base di codice comune. Puoi avere un numero di progetti che si distribuiscono nella stessa farm di server senza incasinare l'un l'altro.

Normalmente non si distribuirà mai un'unità di software più piccola dell'EAR. Ogni EAR può essere più o meno completamente autonomo. Normalmente permetterei al contenuto di questi di selezionare nuovamente ciò che l'organizzazione proprietaria considera applicazioni o sottosistemi. Di solito è possibile impacchettare gli stessi componenti in più EAR.

Answer 2

Molte domande qui.

I progetti Java EE sono distribuzioni EAR o WAR che utilizzano la tecnologia Java EE. Se si dispone di una GUERRA con accesso JSP e JDBC di un database relazionale, si tratta di un progetto Java EE. L'intento originale era che i file EAR fossero "enterprise", e questo significava EJB. Un file EAR contiene EJB, WAR, JAR, l'intera enchilada.

Pensare in termini di servizi è un po 'diverso. Penso che la distribuzione meriti un'attenta considerazione, perché i componenti impacchettati insieme devono essere abbattuti e rimossi se è necessario eseguire qualsiasi manutenzione.

Quindi pensa attentamente a come impacchetti i tuoi servizi. Non è una risposta generale totale o nulla, IMO. Dovresti vedere cosa stanno facendo i tuoi servizi e come potrebbero essere usati insieme per decidere come dovrebbero essere impacchettati e distribuiti.

Answer 3

Entrambe le considerazioni logiche e organizzative entrano in gioco. Ogni EAR conterrebbe tutti i pezzi che sono correlati per una particolare capacità. Possiamo sempre presumere che ogni EAR sia autonomo e possa essere distribuito su uno o più contenitori. L'approccio tipico che ho sempre seguito è che ogni EAR contenga uno o più vasetti e guerre. Ogni war o jar contiene alcuni componenti chiave o set di componenti correlati. L'EAR rappresenta un'applicazione Enterprise che contiene i componenti e le app Web per l'applicazione. Un esempio è un sistema di elaborazione dei pagamenti in cui sono stato coinvolto. L'EAR conteneva tutto il necessario per eseguire il sistema di elaborazione dei pagamenti. Ciò includeva mezza dozzina di vasetti e 3 guerre. Ogni vaso rappresentava alcune funzionalità o raggruppamenti logici di funzionalità. Ogni guerra rappresentava un'app Web. Un esempio della composizione del vaso:

• un barattolo per funzionalità di base
• un barattolo per ejbs
• un barattolo per i nostri pezzi di matematica finanziaria avanzata
• un barattolo per i nostri pezzi di sicurezza eccetera. Avere più barattoli è stato dettato dal fatto che persone diverse hanno sviluppato pezzi diversi in modo da lavorare in diversi progetti Eclipse e combinarli tutti secondo necessità. Non ci sono regole rigide e veloci, qualunque cosa funzioni per la tua squadra e situazione.