Ho capito che l'interfaccia locale è progettata per i client nella stessa istanza JVM del contenitore e l'interfaccia remota è progettata per i client che risiedono all'esterno della JVM del contenitore EJB. Che ne dici del client di applicazioni Web che non risiede (o è pacchettizzato) nello stesso indirizzo, ma si trova sullo stesso server Java EE?EJB3 Interfacce locali e remote
È possibile accedere ai fagioli con annotazione solo se sono nella stessa applicazione. @Local Un file .war distribuito separatamente da un EJB .ear (o altro .war o altro .jar) è un'applicazione diversa, anche se distribuita nella stessa istanza del server delle applicazioni.
Non c'è quindi alcun garanzia che il codice nel tuo .war può chiamare @Local EJB fagioli che sono definiti nel .ear.
Tuttavia, in pratica in quasi tutti i server di applicazioni questo funziona.
C'è una richiesta di EJB 3.2 specifica per supportare ufficialmente chiamate tra applicazioni locali: http://java.net/jira/browse/EJB_SPEC-22
Mi sento un po 'triste di essere l'unico a votare questa funzione ... Tutti - sentiti libero di aderire e fai semplicemente clic su "vota" su questa richiesta JIRA ;-) –
Potrebbe essere piuttosto difficile avere il 100% di lavoro chiamate cross-application (cross ClassLoader!). Lascia che ClassLoader 1 abbia la classe A e ClassLoader 2 abbia la classe A (un'altra copia). Passare l'oggetto A tramite l'interfaccia locale causerà ClassCastException perché ci sono due copie della stessa classe. Un EAR ha il suo ClassLoader a volte isolato. –
Sì, l'isolamento di caricamento della classe potrebbe essere il problema qui. Funzionerebbe ancora per le classi dal JDK e possibilmente per le classi (dell'interfaccia) dell'AS (a seconda di come l'AS ne esegue la modularizzazione). Molti utenti probabilmente non capiranno questa limitazione e potrebbe diventare uno dei nuovi rompicapo di Java EE. –
Si utilizzano le interfacce remote, ma si effettua una ricerca utilizzando JNDI (è così che lo farei), in questo modo si trova l'istanza dell'EJB nel server e può essere utilizzata nell'applicazione Web.
Sebbene sia ancora necessario un contenitore con le interfacce EJB nel progetto di applicazione Web.
EDIT e sono d'accordo con JB Nizet, perché vorresti che la GUERRA non fosse l'EAR?
Si consiglia di distribuirlo separatamente a causa di shenigigans di caricamento della classe. –
Le interfacce remote possono essere richiamate tra le applicazioni, da qualsiasi punto all'interno del server delle applicazioni e dall'esterno, anche da altri host.
Supponiamo quindi che sia necessaria l'interfaccia remota (@Remote). In EJB 3.1 è possibile utilizzare l'iniezione delle dipendenze.
Le interfacce locali devono essere utilizzate nella comunicazione all'interno della stessa applicazione . Non significa necessariamente JVM.
Il punto è: anche all'interno della stessa istanza JVM, sullo stesso server, due diverse applicazioni non possono comunicare utilizzando interfacce locali (che significa visualizzazioni locali e senza interfaccia).
Se si dispone di un componente Web (WAR) e di un componente aziendale (EJB-JAR) che si trova nella stessa applicazione, la soluzione più intuitiva e immediata consiste nel raggrupparli in un EAR o in una GUERRA (dal Java EE 6).
Sì, ma questo è tutto solo teoria. In pratica hai una grande applicazione con più WAR (ad es.applicazione del portale partner, cliente e amministrazione), chiamando lo stesso EJB. Per motivi di implementazione/riduzione dei tempi di inattività, è consigliabile raggruppare questi WAR separatamente, come fanno molte persone. – bozo
D'accordo - Anche a me non piace questa idea e l'ingombrante approccio EAR, ma è la soluzione suggerita ufficialmente. –
Non farmi iniziare su persone JEE. Il tutto è un progetto di sicurezza del lavoro. Lo abbiamo usato in progetti complessi per anni, e devo dire che eravamo 10 volte più produttivi in PHP. Ma al giorno d'oggi il PHP è "non cool" con varie persone di certificazione, e devi avere un certificato per vendere la carta igienica oggi, quindi dobbiamo tutti soffrire di bullsh * t talmente gonfio che non fa nulla di buono. Mi ricorda l'F-35. ;) – bozo
perché non si mettere la webapp nello stesso orecchio? Il punto di un EAR è precisamente quello di contenere sia le parti web che EJB di un'applicazione. –
Cosa intendi per 'lo stesso server J2EE'? È distribuito sulla stessa istanza, nello stesso dominio? – jFrenetic
EAR viene gestito e distribuito separatamente e altri WAR desiderano utilizzare alcuni metodi di business dal residente dell'ejb nell'EAR. Il server J2EE significa che verranno distribuiti nella stessa istanza. – Thurein