EJB - quando utilizzare interfacce remote e / o locali?

Sono molto nuovo di Java EE e sto cercando di capire il concetto di interfacce locali e interfacce remote. Mi è stato detto che uno dei grandi vantaggi di Java EE è che è facile da ridimensionare (il che credo significhi che è possibile distribuire componenti diversi su server diversi). È qui che entrano in gioco le interfacce Remote e Local? Dovresti utilizzare le interfacce remote se ti aspetti che l'applicazione abbia componenti diversi su server diversi? E utilizzare le interfacce locali se l'applicazione risiederà su un solo server?

Se i miei presupposti sopra sono corretti, come sceglieresti se utilizzare le interfacce locali o remote per una nuova applicazione, dove non sei sicuro di quale sia il volume del traffico? Inizia utilizzando le interfacce locali e passa gradualmente alle interfacce remote dove applicabile?

Grazie per eventuali chiarimenti e suggerimenti.

Sono molto nuovo di Java EE e sto cercando di capire il concetto di interfacce locali e interfacce remote.

Nelle versioni iniziali della specifica EJB, gli EJB venivano "assunti" come componenti remoti e l'unico modo per invocarli era effettuare una chiamata remota, usando la semantica RMI e tutto il sovraccarico che implica (una chiamata di rete e la serializzazione degli oggetti per ogni metodo di chiamata). I clienti EJB dovevano pagare questa penalità per le prestazioni anche se collocati nella stessa macchina virtuale con il contenitore EJB.

In seguito, Sun si è resa conto che la maggior parte delle applicazioni aziendali non distribuiva EJB su un livello diverso e ha corretto le specifiche (in EJB 2.0) introducendo il concetto di interfacce locali in modo che i client collocati nella stessa macchina virtuale con il contenitore EJB possano chiamare EJB usando invocazione diretta del metodo, bypassando totalmente la semantica RMI (e il relativo overhead).

Mi è stato detto che uno dei grandi vantaggi di Java EE è che è facile da ridimensionare (il che credo significhi che è possibile distribuire componenti diversi su server diversi)

Java EE può ridimensionare, ma ciò non significa necessariamente distribuire componenti. È possibile eseguire un'applicazione Web + EJB su un cluster senza separare il livello Web e il livello EJB.

Dovresti utilizzare le interfacce remote se ti aspetti che l'applicazione abbia componenti diversi su server diversi? E utilizzare le interfacce locali se l'applicazione risiederà su un solo server?

Lo direi così: usa le interfacce remote se il client non si trova nella stessa JVM (questo non significa usare solo un server / JVM).

(...) Iniziare utilizzando le interfacce locali e passare gradualmente alle interfacce remote dove applicabile?

Probabilmente inizierei usando le interfacce locali. E come già accennato, il passaggio a interfacce remote non è sempre obbligatorio (è possibile raggruppare una struttura collocata ).

Suggerisco di verificare le risorse di seguito indicate (le prime 2 sono piuttosto vecchie ma comunque rilevanti, le altre 2 sono più recenti).

risorse

• Sotto il cofano del clustering J2EE di Wang Yu
• Ridimensionamento delle applicazioni Java EE di Wang Yu
• Ridimensionamento delle applicazioni Java EE - Parte 2 di Wang Yu

Mentre sono d'accordo con la maggior parte di ciò che è scritto sopra, vorrei affinare un po 'le idee "come iniziare".

Il mio consiglio è di non programmare mai direttamente le interfacce EJB all'interno del proprio codice. Utilizzare sempre un'interfaccia regolare e orientata al business, programma (ovvero, disporre dei metodi di chiamata in codice sull'interfaccia orientata al business) e fornire il codice "colla" EJB come implementazione collegabile. Il tuo programma dovrebbe essere focalizzato sulla logica aziendale e non su dettagli di implementazione come EJB.

In questo modo, puoi facilmente passare da implementazioni remote a implementazioni locali e, se usi un contenitore IoC come Spring, puoi farlo solo tramite la configurazione.

Una nota speciale sul passaggio da locale a remoto: nota che ci sono alcune differenze semantiche tra i due. Ad esempio, la chiamata di un metodo EJB tramite la sua "interfaccia remota" comporta il passaggio di argomenti per valore, mentre la chiamata attraverso "l'interfaccia locale" comporta il passaggio di argomenti per riferimento. Questa è una grande differenza; quindi se "inizi con local", assicurati di progettare il tuo sistema in modo che tenga conto anche della semantica "remota".

Se il tuo progetto si basa sui metodi EJB che cambiano gli oggetti passati, sarebbe difficile per te "passare al telecomando" in seguito; forse persino impossibile.

In bocca al lupo.

Secondo la specifica 3.2 del bean, un bean può essere locale o remoto . Un'interfaccia aziendale non può essere contemporaneamente locale e remota.

@Local i bean annotati sono accessibili solo se si trovano nella stessa applicazione.

@Remote i bean annotati sono accessibili attraverso diverse applicazioni, residenti in diversi jvms o tra server delle applicazioni.

Quindi le cose importanti da tenere a mente sono:

1. Se una classe bean contiene l' @Remoteannotazione, tutte le interfacce implementate devono essere remote.
2. Se una classe bean non contiene annotazioni o se @Localviene specificata l' annotazione, si presume che tutte le interfacce implementate siano locali.
3. Qualsiasi interfaccia definita esplicitamente per un bean che non contiene alcuna interfaccia deve essere dichiarata come @Local.
4. La versione 3.2 di EJB tende a fornire una maggiore granularità per le situazioni in cui è necessario definire esplicitamente le interfacce locali e remote.

Questo potrebbe rispondere alle tue preoccupazioni:

In generale, Enterprise Java Bean richiede una vista client remota nei casi in cui si prevede di utilizzare il bean in ambienti distribuiti. In particolare, questi sono i casi in cui il client che lavorerà con esso si troverà in una Java Virtual Machine (JVM) diversa. Nel caso di una vista client remota, la chiamata di qualsiasi metodo dall'interfaccia home remota e / o dall'interfaccia del componente remoto verrà gestita tramite la chiamata del metodo remoto (RMI).

Un bean può utilizzare la vista client locale solo se è garantito che altri bean enterprise o client indirizzeranno il bean solo all'interno di una singola JVM. In tal caso, tale accesso verrà effettuato con chiamate di metodo dirette, anziché RMI.

Fonte: http://www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page=last&x-showcontent=text