Spring MVC con JBoss vs Tomcat - Vantaggi/Esercizio

Question

Ok. Questa è di nuovo una questione di pratica industriale.

• Tomcat = Web container
• JBoss, WebLogic, ecc = Application Server che hanno Web contenitore all'interno (per JBoss, Tomcat suo biforcuta)

Primavera non ha bisogno di Application Server come JBoss. Se usiamo servizi aziendali come JMS, ecc possiamo usare sistemi indipendenti come RabbitMQ, ApacheMQ, ecc

1. domanda è perché le persone usano ancora JBoss e altre applicazioni Serve per puramente primavera applicazioni basate?
2. Quali sono i vantaggi che Spring può utilizzare utilizzando Application Server? Ti piace il pooling degli oggetti? Quali vantaggi specifici offre Application Server? Come sono configurati?
3. Se non per la molla, per quali altri scopi vengono utilizzati i server di applicazione per Spring/Hibernate, stack ecc.? (Casi di utilizzo)

Answer 1

In realtà, direi che l'ascolto di JMS è probabilmente la migliore ragione per un server delle applicazioni. Un broker di messaggi autonomo non risolve il problema poiché è ancora necessario un componente in ascolto per i messaggi. Il modo migliore per farlo è utilizzare un MDB. In teoria puoi usare Springs MessageListenerContainer. Tuttavia questo ha diversi svantaggi come JMS supporta solo il blocco delle letture e Spring quindi ha bisogno di far ruotare i propri thread che non è completamente supportato (anche in Tomcat) e può rompere transazioni, sicurezza, naming (JNDI) e caricamento della classe (che a sua volta può rompersi remoting). Un adattatore di risorse JCA è libero di fare tutto ciò che desidera, tra cui la rotazione di thread tramite WorkManager. Probabilmente viene utilizzato un database oltre a JMS (o un'altra destinazione), a quel punto sono necessarie le transazioni XA e JTA, in altre parole un server applicazioni. Sì, puoi applicare una patch a questo in un contenitore servlet, ma questo punto diventa indistinguibile da un server delle applicazioni.

IMHO la ragione principale contro i server delle applicazioni è che ci vogliono anni dopo che una specifica è stata pubblicata (che a sua volta richiede anni) fino a quando severs implementa le specifiche e ha eliminato i bug peggiori. Solo ora, proprio prima che EE 7 stia per essere pubblicato, abbiamo i server EE 6 che iniziano ad apparire che non sono totalmente pieni di bug. Diventa comico al punto che alcuni fornitori non correggono più bug nella loro linea EE 6 perché sono già occupati con la linea EE 7 in arrivo.

Modifica

lunga spiegazione dell'ultimo paragrafo:

Java EE in un sacco di posti si basa su ciò che è chiamato informazioni contestuali. Informazioni che non sono passate esplicitamente come argomento dal server/contenitore all'applicazione ma implicitamente "lì". Ad esempio l'utente corrente per i controlli di sicurezza. La transazione o la connessione corrente. L'attuale applicazione per cercare classi per caricare pigramente codice o deserializzare oggetti. Oppure il componente corrente (servlet, EJB, ...) per effettuare le ricerche JNDI. Tutte queste informazioni si trovano nei locali dei thread che il server/contenitore imposta prima di chiamare un componente (servlet, EJB, ...). Se si creano i propri thread, il server/contenitore non li conosce e tutte le funzionalità basate su queste informazioni non funzionano più. Potresti farla franca semplicemente non usando nessuna di queste caratteristiche nei thread che hai generato.

Alcuni link

http://www.oracle.com/technetwork/java/restrictions-142267.html#threads http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html#spring-4

Se controlliamo le specifiche Servlet 3.0 troviamo:

2.3.3.3 elaborazione asincrona

Java Enterprise Edition presenta come Sezione 15.2 .2, "Ambiente dell'applicazione Web" a pagina 15-174 e Sezione 15.3.1, "Propagazione di Secu Identità di rità nelle chiamate EJBTM "a pagina 15-176 sono disponibili solo per i thread che eseguono la richiesta iniziale o quando la richiesta viene inviata al contenitore tramite il metodo AsyncContext.dispatch. Le funzionalità di Java Enterprise Edition potrebbero essere disponibili per altri thread che operano direttamente sull'oggetto di risposta tramite il metodo AsyncContext.start (Runnable).

Riguarda l'elaborazione asincrona, ma le stesse restrizioni si applicano ai thread personalizzati.

public void start (Runnable r) - Questo metodo consente al contenitore di inviare un thread, possibilmente da un pool di thread gestito, per eseguire il Runnable specificato. Il contenitore può propagare informazioni contestuali appropriate al Runnable.

Ancora, elaborazione asincrona ma le stesse restrizioni si applicano ai thread personalizzati.

15.2.2 Web Application Environment

Questo tipo di contenitore di servlet dovrebbe sostenere questo comportamento quando eseguite su thread creati dallo sviluppatore, ma non sono attualmente tenuti a farlo. Tale requisito sarà aggiunto nella prossima versione di questa specifica. Si avvisano gli sviluppatori che, in base a questa capacità, i thread creati dall'applicazione non sono consigliati, in quanto non è portabile.

Non portatile significa che può essere presente in un server ma non in un altro.

Quando si desidera fare ricevere messaggi con JMS al di fuori di un MDB è possibile utilizzare quattro metodi in javax.jms.MessageConsumer:

• #receiveNoWait() possibile per questo in un thread del contenitore, non bloccare, ma è come sbirciare . Se non è presente alcun messaggio, restituisce semplicemente null. Questo non è molto adatto per ascoltare i messaggi.
• #receive(long) puoi farlo in un thread contenitore, esso blocca. In genere non si desidera bloccare le attese in un thread contenitore. Ancora una volta non molto adatto per l'ascolto di messaggi.
• #receive(), questo blocco può durare indefinitamente. Ancora una volta non molto adatto per l'ascolto di messaggi.
• #setMessageListener() questo è ciò che si desidera, ottenere una richiamata quando arriva un messaggio. Tuttavia, a meno che la libreria non possa collegarsi al server delle applicazioni, questo non sarà un thread contenitore. Gli hook nel server delle applicazioni sono disponibili solo tramite JCA agli adattatori di risorse.

Quindi sì, può funzionare, ma non è garantito e ci sono molte cose che potrebbero rompersi.

Answer 2

Stiamo usando JBoss nel corso Tomcat per le origini dati JNDI e mettere in comune .. E lo rende così il programmatore non c'è bisogno di sapere nulla di database, ma il suo nome JNDI

Answer 3

Hai ragione che don' Ho davvero bisogno di un vero application server (implementando tutte le specifiche Java EE) per usare Spring. Il motivo principale per cui le persone non usano app Java EE autentiche come JBoss è che poi sono stati lenti come # $ @ #% sui tempi di avvio a freddo, rendendo lo sviluppo un problema (la distribuzione a caldo ancora non funziona così bene).

Vedete ci sono due campi:

• Java EE
• Spring Framework.

Uno dei campi crede nel processo spec/commissione e l'altro crede nel benevolo dittatore/processo OSS organico. Entrambi hanno persone con i loro "programmi".

Probabilmente non otterrete una risposta imparziale molto buona come questi two camps are much like the Emacs vs VIM war.

rispondere alle vostre domande w/un bias primavera

1. Perché in teoria acquista il tuo meno vendor lock-in (anche se ho scoperto che questo è il contrario).
2. Il maggior vantaggio di Spring è AspectJ AOP. Di gran lunga.
3. Immagino di vedere la risposta di Philippe.

(inizio sproloquio)

Dal @PhilippeMarschall difeso Java EE devo dire che ho fatto la Tomcat + RabbitMQ + percorso primavera e funziona abbastanza bene. La discussione @PhilippeMarschall è valida se si desidera un JTA + JMS corretto, ma con l'installazione corretta con Spram AMQP e un buon database transazionale come Postgresql, questo è meno di un problema. Inoltre, non è corretto riguardo alle transazioni della coda dei messaggi che non sono collegate/sincronizzate alle transazioni della piattaforma, poiché Spring supporta questo (e IMHO molto più elegantemente con @Transactional AOP). Anche AMQP è semplicemente superiore a JMS.

(fine sproloquio)