2012-11-27 16 views
8

Sto lavorando a un progetto in cui è necessario creare diversi moduli "standalone" che si collegano a un database. Questi moduli sono principalmente processi aziendali in background, quindi non molto frontend. Tranne che per un modulo Web che mostra i dati e consente le funzioni CRUD di base. Per questo stiamo progettando di utilizzare le seguenti tecniche:Java EE vs Standalone

  • JPA2 (utilizzando l'implementazione hibernate-APP)
  • CDI (attuazione primavera utilizzando)
  • JSF2 + primefaces (per il nostro modulo web)

Il piano iniziale era quello di creare un file jar (con un metodo principale) per modulo e installarlo come servizio (windows) tramite un service wrapper. Per il nostro modulo web useremo Glassfish o JBoss per eseguirlo. Tuttavia, ultimamente Java EE ci è venuto in mente. Potremmo eseguire tutti i nostri moduli in un contenitore Java EE come Glassfish o JBoss, non solo il nostro modulo web. Alcune domande per il caso che andiamo per Java EE:

  1. Posso/dovremmo ancora utilizzare CDI con molla? O dovremmo passare a EJB3?
  2. Quali sono le conseguenze per JPA quando lo utilizziamo da un contenitore anziché da moduli standalone? C'è qualche differenza?
  3. Poiché la maggior parte dei nostri moduli non sono correlati al Web, ha ancora senso eseguirli in un contenitore Java EE?

risposta

3

Altri hanno segnalato alcuni professionisti, quindi ecco alcuni aspetti positivi se si distribuisce il processo in background nella stessa jvm dell'applicazione web.

  • Avviare e arrestare il server che esegue il modulo Web significa avviare e interrompere i processi in background, questo potrebbe non essere un problema per voi.
  • Si sta condividendo l'heap con tutte e tre le applicazioni se i processi in background consumano molta memoria o CPU che potrebbero avere un impatto sull'app Web o se l'app Web consuma molte risorse che potrebbero influire sui processi in background.
  • Potrebbe essere necessario distribuire l'app Web in modo che sia accessibile su Internet, ma i processi in background potrebbero essere felici di funzionare senza alcun accesso alla rete. Quindi, perché esporre i processi in background a Internet, se non è necessario.
  • Quando si aggiorna il server delle applicazioni, i framework o la configurazione, ciò significa tre cose da testare, se i processi in background sono in esecuzione da soli, è possibile aggiornarli in un ciclo di rilascio separato dall'app Web.
  • È più semplice sviluppare e testare il codice all'esterno del contenitore. Esecuzione dei processi in background all'interno del contenitore significa un ambiente di sviluppo più complesso per i processi in background, devi attendere l'avvio del server, iniziare in base alle risorse del contenitore che devi quindi prendere in esame i test unitari ... ecc.

JPA è lo stesso all'interno e all'esterno del contenitore. L'unica differenza è come si ottiene un EntityManager, questo può essere configurato con Spring per essere uguale sia dentro che fuori dal contenitore. CDI dovrebbe essere eseguibile all'esterno del contenitore.

Le principali aree di differenza saranno le transazioni con il db, ad esempio utilizzando le transazioni Spring e le transazioni ejb.

Aggiornamento: Per rispondere alla tua domanda formare il commento: in JPA l'EntityManager non è thread-safe così in un server Java EE ci sarà un gestore di entità per unità di persistenza per thread. La creazione e la chiusura del gestore di entità sono gestite automaticamente dal server dell'app. Ogni gestore di entità ha una cache al suo interno. È possibile configurare una cache di secondo livello che si estenda su più gestori di entità. Quando si esegue all'esterno del contenitore, è necessario gestire autonomamente il numero di gestori di entità JPA, in base al numero di thread nel processo in background e ai limiti di transazione che si desidera avere. Se guardi un libro chiamato "Pro JPA2" c'è una sezione che parla dei dettagli di correre dentro o fuori dal container.

Nella mia applicazione non ho un processo in background ma ogni classe che ha bisogno di un gestore di entità viene iniettata semplicemente usando @PersistenceContext EntityManager em; e la primavera si occupa di far funzionare tutto all'interno e all'esterno del contenitore. Spring 3.1 ha una funzionalità chiamata profili che rende banale avere lo stesso codice eseguito all'interno del nostro contenitore esterno senza modificare una singola riga di codice.Non sono un utente CDI quindi non so se CDI ha un equivalente della funzione dei profili di primavera 3.1.

+0

Grazie per avermi mostrato anche i contro! A proposito di entitymanager, con JEE, non avremmo solo 1 istanza rispetto a standalone dove avremmo 1 istanza per JVM (/ modulo)? Questo avrebbe influenzato il caching dell'ibernazione? –

+0

nel caso qualcuno lo prendesse sul serio, nota che quasi tutti i contro spariscono se si usano semplicemente due contenitori diversi, uno per il lotto uno per il web. in effetti, usa un contenitore per ciascuna delle cose. i vantaggi di avere un contenitore standard uniforme con CDI, JPA, che non sono enormi. per quanto riguarda la produttività dello sviluppo, eclipse può fornire un simile inversione di tendenza anche con i contenitori java ee. l'unica modifica necessaria sarebbe quella di disattivare i listener HTTP per il contenitore batch. basta dire no alla primavera o qualcosa di non standard - java ee 7 è stato approvato e ottieni un sacco di chicche. – necromancer

+0

@RobeEleckers inoltre un contenitore è essenzialmente una jvm, quindi se si disattiva semplicemente i listener di rete si sta eseguendo un processo java batch. – necromancer

1

Ha senso per l'esecuzione in un server di applicazioni piuttosto che un programma Java standalone per le ragioni comuni come

1) È possibile utilizzare CDI con la molla dal EJB3 si basa anche sul concetto di simile. 2) Non c'è alcuna differenza per quanto riguarda JPA, tranne che se è necessario aggiungere più volume all'applicazione in un secondo momento, è possibile aggiungere il carico aggiungendo più macchine che eseguono la stessa applicazione - Tuttavia, si noti che questo è un non - una quantità irrisoria di lavoro e quindi dipende dal requisito aziendale per effettuare la scelta 3) I server di applicazioni conquistano app standalone per i motivi di sicurezza, affidabilità, gestione e scalabilità intrinseche rispetto alle applicazioni java standalone.

3

Se tutti i moduli (batch + tempo reale) si riferiscono a un prodotto, raggrupparli insieme rappresenta un buon approccio. Quindi ecco il mio suggerimento

  1. Raggruppa tutti i moduli in un unico orecchio.
  2. Utilizzare Java EE 6 e liberarsi della primavera. CDI è pensato per essere utilizzato in Java EE. Per il tipo di operazioni in batch, provare a utilizzare Asynchronous EJBs o MDB.

risposte alle vostre domande specifiche

  • può/deve ancora usare CDI con la molla? O dovremmo passare a EJB3?

CDI può essere utilizzato anche senza EJB. In ogni caso sbarazzati della primavera in quanto non vedo un valore aggiunto per il tuo progetto semplice.

  • Quali sono le conseguenze per JPA quando lo utilizziamo da un contenitore anziché da moduli standalone? C'è qualche differenza?

Non c'è differenza, tranne il fatto che è possibile ottenere il DataSource da JNDI.

  • Poiché la maggior parte dei nostri moduli non sono correlati al Web, ha ancora senso eseguirli in un contenitore Java EE?

Sì, ha senso raggruppare insieme gli aspetti batch e in tempo reale di un singolo prodotto, purché non si verifichino problemi di prestazioni.

+0

è possibile utilizzare il CDI in un'app java standalone? – amphibient

+0

non hai davvero spiegato il motivo per cui "ha senso raggruppare insieme aspetti in batch e in tempo reale di un singolo prodotto fino a quando non si notano problemi di prestazioni", ovvero quali sono i vantaggi associati al livello aggiuntivo di complessità di eseguirlo all'interno di un app server anziché standalone. – amphibient

+0

@foampile I moduli correlati spesso dipendono dallo stesso set di moduli principali. Quindi ha senso raggrupparli insieme. Non sono sicuro di quale sia la complessità in esecuzione in un appserver? Gli MDB sono pensati per l'elaborazione asincrona e vengono eseguiti nel contesto dell'appserver. –