Preferisco Spring + Hibernate invece di EJB 3?

I framework EJB 3+ sono in realtà piuttosto buoni in quanto sono venuti insieme a JPA come risposta per i framework di persistenza configurati con annotazioni, così come CDI che consente l'iniezione delle dipendenze configurata per l'annotazione. Inoltre, aggiungi sopra quella saldatura. La primavera invece sta recuperando il gioco con la configurazione attraverso l'annotazione.

Con ciò detto il backlack storico contro EJB1 e 2 non dovrebbe essere scontato. Non solo non sono riusciti a risolvere i problemi con la scrittura di applicazioni aziendali, ma in modo spettacolare non sono riusciti. È stato un fallimento completo da parte dei progettisti ottenere un impulso sui veri problemi che devono affrontare gli sviluppatori di applicazioni Web e aziendali e, a loro volta, fornire le soluzioni di cui hanno effettivamente bisogno.

Aggiungete oltre a ciò la sfiducia che ci sono alcune serie scosse e instabilità con l'attuale direzione di Java in questo momento e la mancanza di fiducia negli attuali amministratori e proprietari della vecchia Sun JVM, in Oracle. Molte persone non credono che Oracle migliorerà su Java e guiderà la direzione e c'è anche il timore che Apache Software Foundation possa semplicemente gettare la spugna. Sempre più persone stanno cercando OpenJDK per il futuro di Java, ma non è proprio dove deve essere adottato per l'adozione aziendale.

Alcuni vedono tutto questo come l'odore della morte come applicazioni aziendali sono le ragioni principali per cui Java è stato storicamente il linguaggio di programmazione n. 1 al mondo per tutto il tempo che ha. Questo è il motivo per cui Microsoft ha guadagnato così tanto terreno rispetto a Java con le tecnologie .NET.

Gli sviluppatori di applicazioni Java non enterprise si stanno rivolgendo sempre più verso OpenJDK e altri framework open source per aiutare a costruire le loro soluzioni e alcuni non guardano mai indietro. Si potrebbe dire che si tratta di un caso di troppo poco tempo per riportare JEE in prima linea nella legittimità, anche se tecnicamente il JEE è in grado di sopportare la stessa applicazione Spring.

L'EJB ha un sacco di bagagli. Parte di quel bagaglio deriva dal fatto che è stato preso di mira dal pubblico sbagliato. L'altra parte è stata che le prime due versioni erano completamente disgustose.

Se si guardano le versioni EJB originali, il progetto era che uno sviluppatore EJB poteva creare una soluzione pacchettizzata che poteva essere utilizzata all'interno di qualsiasi contenitore EJB compatibile. Per un negozio interno, questo livello di astrazione non era necessario. Era una soluzione perfetta per creare un mercato fiorente per i fornitori di componenti EJB di terze parti. Tuttavia, i venditori di Container erano troppo zelanti nel loro marketing e stavano facendo tonnellate vendendo il loro prodotto come una soluzione praticabile per lo sviluppo di ogni giorno. Ciò equivale a creare tutto il codice dell'applicazione come componenti COM +.

Per saperne di più sulle specifiche originali J2EE, la maggior parte dei fornitori coinvolti aveva server CORBA e desiderava sfruttare questi prodotti in futuro. La specifica EJB è stata costruita tramite il protocollo IIOP (in realtà Java RMI che era un sottile strato su IIOP). Il CORBA era già stato respinto a causa della sua complessità, e l'EJB era solo CORBA travestito, quindi portò con sé molti dei problemi che CORBA aveva. In realtà, le astrazioni di EJB hanno reso più difficile lavorare di quanto non sarebbe stata una pura implementazione di CORBA.

Una volta che la gomma ha colpito il pavimento, la gente si è resa conto che le prestazioni con EJB erano atroci. Poiché ogni chiamata è una chiamata remota e la difficoltà di avviare correttamente l'applicazione per iniziare, le persone cercano rapidamente alternative. Hibernate e Spring in esecuzione in un contenitore JSP sono diventati la soluzione.

EJB 3 "ha adottato" questo approccio. Ma è ancora un compromesso generico che non offre molti vantaggi. Non esiste ancora un mercato dei componenti EJB di terze parti, quindi non c'è davvero alcun senso usare un contenitore EJB per costruire la soluzione.

Per farla breve. Sebbene EJB 3 sia un miglioramento vasto rispetto alle prime due iterazioni, non offre ancora benefici sufficienti per superare i costi.