Che cos'è un bean, e cosa fa?

Ho cercato di imparare cosa EJBsono i bean, cosa significa che le loro istanze sono gestite in un pool, blah blah. Davvero non riesco a capirli bene.

Puoi spiegarmi cosa sono realmente (praticamente per un programmatore Java)? Cosa fanno? Quali sono i loro scopi? Perché li usano davvero? (Perché non attenersi POJO?) Forse un'applicazione di esempio?

Si prega di fare riferimento solo alle informazioni aggiornate, cioè EJB 3.1. Le informazioni datate su EJB possono essere fuorvianti.

Per i principianti di apprendimento EJB, tenere presente quanto segue:

Gli EJB si basano su oggetti distribuiti , si riferiscono a parti di software in esecuzione su più macchine (virtuali o fisiche) collegate da una rete .

Perché li usano davvero? (Perché non limitarsi a POJO?)

Se hai bisogno di un componente che accede al database o acceda ad altre risorse di connettività / directory o sia acceduto da più client o sia inteso come un servizio SOA, oggi gli EJB sono generalmente "più grandi, più forti, più veloci (o almeno più scalabili) e più semplice "dei POJO. Sono molto utili per servire un gran numero di utenti sul Web o sulla rete aziendale e in qualche modo meno utili per le piccole app all'interno di un dipartimento.

1. Riutilizzo / condivisione della logica tra più applicazioni / client con accoppiamento libero.
   Gli EJB possono essere impacchettati nei loro barattoli, distribuiti ed invocati da molti luoghi. Sono componenti comuni. È vero, i POJO possono essere (attentamente!) Progettati come librerie e confezionati come barattoli. Ma gli EJB supportano l'accesso alla rete sia locale che remota, anche tramite interfaccia java locale, RMI trasparente, messaggio asincrono JMS e servizio web SOAP / REST, salvando dalle dipendenze jar taglia e incolla con distribuzioni multiple (incoerenti?).
   Sono molto utili per la creazione di servizi SOA. Se utilizzati per l'accesso locale, sono POJO (con l'aggiunta di servizi di container gratuiti). L'atto di progettare uno strato EJB separato promuove un'attenzione extra per massimizzare l'incapsulamento, l'accoppiamento e la coesione lenti e promuove un'interfaccia pulita (facciata), proteggendo i chiamanti da complessi modelli di elaborazione e dati.

2. Scalabilità e affidabilità Se si applica un numero enorme di richieste da vari messaggi / processi / thread di chiamata, vengono prima distribuite tra le istanze EJB disponibili nel pool e quindi messe in coda. Ciò significa che se il numero di richieste in entrata al secondo è maggiore di quello che il server è in grado di gestire, si degrada con garbo: ci sono sempre alcune richieste elaborate in modo efficiente e le richieste in eccesso vengono fatte attendere. Non raggiungiamo il "crollo" del server - in cui TUTTE le richieste subiscono simultaneamente tempi di risposta terribili, inoltre il server tenta di accedere a più risorse di quante ne possano gestire l'hardware e il sistema operativo e quindi gli arresti anomali. Gli EJB possono essere distribuiti su livelli separati che possono essere raggruppati: ciò garantisce affidabilità tramite failover da un server all'altro, inoltre è possibile aggiungere hardware per ridimensionare linearmente.

3. Gestione della concorrenza. Il contenitore garantisce che le istanze EJB siano automaticamente accessibili in modo sicuro (in serie) da più client. Il contenitore gestisce il pool EJB, il pool di thread, la coda di invocazione ed esegue automaticamente il blocco della scrittura a livello di metodo (impostazione predefinita) o il blocco della lettura (tramite @Lock (READ)). Ciò protegge i dati dalla corruzione attraverso scontri simultanei di scrittura / scrittura e aiuta i dati a essere letti in modo coerente prevenendo gli scontri di lettura-scrittura.
   Ciò è utile soprattutto per i bean di sessione @Singleton, in cui il bean sta manipolando e condividendo lo stato comune tra i chiamanti dei client. Questo può essere facilmente superato per configurare manualmente o controllare a livello di programmazione scenari avanzati per l'esecuzione simultanea di codice e l'accesso ai dati.

4. Gestione automatizzata delle transazioni.
   Non eseguire alcuna operazione e tutti i metodi EJB vengono eseguiti in una transazione JTA. Se si accede a un database tramite JPA o JDBC, questo viene automaticamente incluso nella transazione. Lo stesso vale per le invocazioni JMS e JCA. Specificare @TransactionAttribute (someTransactionMode) prima di un metodo per specificare se / come quel particolare metodo partecipa nella transazione JTA, ignorando la modalità predefinita: "Obbligatorio".

5. Accesso molto semplice a risorse / dipendenze tramite iniezione.
   Il contenitore cercherà le risorse e imposterà i riferimenti delle risorse come campi di istanza nel bean: come connessioni JDBC memorizzate JNDI, connessioni / argomenti / code JMS, altri bean, transazioni JTA, contesti di persistenza del gestore entità JPA, unità di persistenza della fabbrica gestore entità JPA e Risorse dell'adattatore JCA. ad es. per impostare un riferimento a un altro bean, una transazione JTA e un gestore entità JPA e una fabbrica e una coda di connessione JMS:

   @Stateless
   public class MyAccountsBean {
   
       @EJB SomeOtherBeanClass someOtherBean;
       @Resource UserTransaction jtaTx;
       @PersistenceContext(unitName="AccountsPU") EntityManager em;
       @Resource QueueConnectionFactory accountsJMSfactory;
       @Resource Queue accountPaymentDestinationQueue;
   
       public List<Account> processAccounts(DepartmentId id) {
           // Use all of above instance variables with no additional setup.
           // They automatically partake in a (server coordinated) JTA transaction
       }
   }
   

   Un Servlet può chiamare questo bean localmente, semplicemente dichiarando una variabile di istanza:

   @EJB MyAccountsBean accountsBean;    
   

   e poi solo chiamando i suoi 'metodi come desiderato.

6. Interazione intelligente con JPA. Per impostazione predefinita, EntityManager iniettato come sopra utilizza un contesto di persistenza nell'ambito della transazione. Questo è perfetto per i bean di sessione senza stato. Quando viene chiamato un metodo EJB (senza stato), all'interno della nuova transazione viene creato un nuovo contesto di persistenza, tutte le istanze dell'oggetto entità recuperate / scritte nel DB sono visibili solo all'interno di tale chiamata di metodo e sono isolate da altri metodi. Ma se con il metodo vengono chiamati altri bean senza stato, il contenitore si propaga e condivide lo stesso PC, quindi le stesse entità vengono automaticamente condivise in modo coerente attraverso il PC nella stessa transazione.
   Se viene dichiarato un bean di sessione @Stateful, si ottiene pari affinità intelligente con JPA dichiarando entityManager come ambito esteso: @PersistentContent (unitName = "AccountsPU, type = EXTENDED). Questo esiste per la durata della sessione bean, attraverso più chiamate e transazioni di bean, memorizzando nella cache copie in memoria di entità DB precedentemente recuperate / scritte in modo che non debbano essere recuperate di nuovo.

7. Gestione del ciclo di vita. Il ciclo di vita dei bean è gestito dal container. Se necessario, crea istanze EJB, cancella e inizializza lo stato del bean di sessione stateful, passiva e attiva e chiama i metodi di callback del ciclo di vita, in modo che il codice EJB possa partecipare alle operazioni del ciclo di vita per acquisire e rilasciare risorse o eseguire altri comportamenti di inizializzazione e spegnimento. Cattura inoltre tutte le eccezioni, le registra, ripristina le transazioni come richiesto e genera nuove eccezioni EJB o @ApplicationExceptions come richiesto.

8. Gestione della sicurezza. Il controllo dell'accesso basato sui ruoli agli EJB può essere configurato tramite una semplice annotazione o impostazione XML. Il server passa automaticamente i dettagli dell'utente autenticato insieme a ciascuna chiamata come contesto di sicurezza (entità chiamante e ruolo). Assicura che tutte le regole RBAC vengano applicate automaticamente in modo che i metodi non possano essere chiamati illegalmente dal ruolo sbagliato. Consente agli EJB di accedere facilmente ai dettagli utente / ruolo per ulteriori controlli programmatici. Consente di collegare un'ulteriore elaborazione di sicurezza (o persino strumenti IAM) al contenitore in modo standard.

9. Standardizzazione e portabilità. Le implementazioni EJB sono conformi agli standard EE Java e alle convenzioni di codifica, promuovendo la qualità e la facilità di comprensione e manutenzione. Promuove inoltre la portabilità del codice ai nuovi server di app dei fornitori, garantendo che tutti supportino le stesse caratteristiche e comportamenti standard e scoraggiando gli sviluppatori dall'adottare accidentalmente le
   caratteristiche dei fornitori non portatili proprietari .

10. The Real Kicker: Semplicità. Tutto quanto sopra può essere fatto con un codice molto semplificato - utilizzando le impostazioni predefinite per gli EJB in Java EE 6 o aggiungendo alcune annotazioni. La codifica delle funzionalità di resistenza aziendale / industriale nei propri POJO sarebbe molto più voluminosa, complessa e soggetta a errori. Una volta che inizi a programmare con gli EJB, sono piuttosto facili da sviluppare e offrono una serie di vantaggi "free ride".

Nelle specifiche EJB originali di 10 anni fa, gli EJB rappresentavano una seccatura per la produttività. Erano gonfiati, avevano bisogno di molti artefatti di codice e configurazione e fornivano circa i 2/3 dei vantaggi di cui sopra. La maggior parte dei progetti Web non li ha effettivamente utilizzati. Ma questo è cambiato in modo significativo con 10 anni di modifiche, revisioni, miglioramenti funzionali e sviluppo del flusso di sviluppo. In Java EE 6 forniscono la massima resistenza industriale e semplicità d'uso.

Cosa non va ?? :-) :-)

Un bean è un componente Java, contenente la logica aziendale, che viene distribuito in un contenitore e che beneficia dei servizi tecnici forniti dal contenitore, generalmente in modo dichiarativo, grazie alle annotazioni:

• gestione delle transazioni: una transazione può essere avviata automaticamente prima che un metodo dell'EJB venga richiamato e che venga eseguito il commit o il rollback una volta restituito questo metodo. Questo contesto transazionale viene propagato alle chiamate ad altri bean.
• gestione della sicurezza: è possibile verificare che il chiamante abbia i ruoli necessari per eseguire il metodo.
• iniezione di dipendenza: altri bean, o risorse come un gestore di entità JPA, un'origine dati JDBC, ecc. possono essere iniettati nel bean.
• concorrenza: il contenitore si assicura che solo un thread alla volta invochi un metodo dell'istanza EJB.
• distribuzione: alcuni EJB possono essere chiamati in remoto, da un'altra JVM.
• failover e bilanciamento del carico: i client remoti dei tuoi bean possono automaticamente reindirizzare la loro chiamata a un altro server, se necessario.
• gestione delle risorse: i bean stateful possono essere automaticamente passivati ​​su disco per limitare il consumo di memoria del server.
• ... Probabilmente ho dimenticato alcuni punti.

Spero che questo dal documento Oracle possa aiutare qualcuno come me a comprendere l'argomento di EJB in modo semplice.

Che cos'è un bean enterprise? Scritto nel linguaggio di programmazione Java, un bean enterprise è un componente lato server che incapsula la logica aziendale di un'applicazione. La logica aziendale è il codice che soddisfa lo scopo dell'applicazione. In un'applicazione di controllo dell'inventario, ad esempio, i bean enterprise potrebbero implementare la logica aziendale in metodi chiamati checkInventoryLevel e orderProduct. Invocando questi metodi, i clienti possono accedere ai servizi di inventario forniti dall'applicazione.

Vantaggi dei bean enterprise Per diversi motivi, i bean enterprise semplificano lo sviluppo di applicazioni distribuite di grandi dimensioni. Innanzitutto, poiché il contenitore EJB fornisce servizi a livello di sistema ai bean enterprise, lo sviluppatore di bean può concentrarsi sulla risoluzione dei problemi aziendali. Il contenitore EJB, anziché lo sviluppatore di bean, è responsabile di servizi a livello di sistema come la gestione delle transazioni e l'autorizzazione di sicurezza.

In secondo luogo, poiché i bean anziché i client contengono la logica di business dell'applicazione, lo sviluppatore del client può concentrarsi sulla presentazione del client. Lo sviluppatore del client non deve codificare le routine che implementano le regole di business o l'accesso ai database. Di conseguenza, i client sono più sottili, un vantaggio particolarmente importante per i client che girano su dispositivi di piccole dimensioni.

Terzo, poiché i bean enterprise sono componenti portatili, l'assemblatore di applicazioni può creare nuove applicazioni da bean esistenti. Queste applicazioni possono essere eseguite su qualsiasi server Java EE conforme purché utilizzino le API standard.

Quando utilizzare bean enterprise È consigliabile utilizzare bean enterprise se l'applicazione presenta uno dei requisiti seguenti:

L'applicazione deve essere scalabile. Per soddisfare un numero crescente di utenti, potrebbe essere necessario distribuire i componenti di un'applicazione su più macchine. Non solo i bean enterprise di un'applicazione possono essere eseguiti su macchine diverse, ma anche la loro posizione rimarrà trasparente per i client.

Le transazioni devono garantire l'integrità dei dati. I bean enterprise supportano le transazioni, i meccanismi che gestiscono l'accesso simultaneo agli oggetti condivisi.

L'applicazione avrà una varietà di client. Con solo poche righe di codice, i client remoti possono individuare facilmente i bean enterprise. Questi client possono essere magri, vari e numerosi.

La domanda che mi interessa di più è come e dove posso usarli. Per capirlo, dobbiamo prima vedere quali tipi di EJB esistono. Ci sono 2 grandi categorie:

1. Fagioli di sessione
2. Fagioli guidati da messaggi

Consideriamo i fagioli di sessione. Sono di 3 tipi:

1. Stateful : questi componenti mantengono lo stato e sono specifici per un client su più richieste. Vedi come una sessione. L'utilizzo immediato a cui questi possono essere sottoposti sono i carrelli del negozio o altri tipi di sessioni (sessione di accesso e così via)
2. Stateless : sono componenti autonomi che non persistono le informazioni tra le richieste, ma sono univoci per l'utente. Uso immediato che viene in mente - Classi di servizio nel livello di servizio . Immagina OrderService. Un altro grande uso di questi è quello di esporre i servizi web. Ancora una volta, questo deve essere nel livello Servizio o completamente separato.
3. Singleton : questi sono i bean esistenti per applicazione e vengono creati una volta e possono essere riutilizzati / accessibili più volte. Immediatamente Configurationviene in mente il componente: dove è possibile archiviare le configurazioni a livello di applicazione e accedervi quando è necessario da qualsiasi luogo.

Ora il resto delle capacità o funzionalità può essere utilizzato su più livelli in tali situazioni:

• Sicurezza : è possibile verificare le autorizzazioni con un'annotazione sul metodo chiamato. Questo può accadere sia nel livello di servizio che nel controller, se lo si desidera.
• Gestione delle transazioni : questo è il candidato ovvio nel livello Servizio o livello Persistenza
• Iniezione delle dipendenze : verrà nuovamente utilizzata ovunque

Un grande uso nei tempi moderni sono i cosiddetti microservizi e architetture orientate ai servizi. È possibile impacchettare alcuni componenti di business logic come EJB e distribuirli all'interno dell'organizzazione, per essere utilizzati da più client (per client qui intendo altre applicazioni back-end).

E così via. Ora il grande svantaggio è che si diventa molto dipendenti dal contenitore EJB e sebbene sia possibile passare da 2 implementazioni di riferimento, non si sarà in grado di passare a qualcosa di più leggero, ad esempio Tomcat. Ma perché dovresti voler sacrificare tutti i benefici?