EJB's: ¿cuándo usar interfaces remotas y / o locales?

Soy muy nuevo en Java EE y estoy tratando de entender el concepto de interfaces locales e interfaces remotas. Me han dicho que una de las grandes ventajas de Java EE es que es fácil de escalar (lo que creo que significa que puede implementar diferentes componentes en diferentes servidores). ¿Es ahí donde entran las interfaces remotas y locales? ¿Se supone que debe usar interfaces remotas si espera que su aplicación tenga diferentes componentes en diferentes servidores? ¿Y usa interfaces locales si su aplicación solo va a residir en un servidor?

Si mis suposiciones anteriores son correctas, ¿cómo elegiría si usaría interfaces locales o remotas para una nueva aplicación, donde no está seguro de cuál sería el volumen de tráfico? Comience usando las interfaces locales y actualice gradualmente a las interfaces remotas cuando corresponda.

Gracias por cualquier aclaración y sugerencia.

Soy muy nuevo en Java EE y estoy tratando de entender el concepto de interfaces locales e interfaces remotas.

En las versiones iniciales de la especificación EJB, se suponía que los EJB eran componentes remotos y la única forma de invocarlos era hacer una llamada remota, utilizando la semántica RMI y toda la sobrecarga que implica (una llamada de red y serialización de objetos para cada llamada al método). Los clientes EJB tuvieron que pagar esta penalización de rendimiento incluso cuando se ubicaron en la misma máquina virtual con el contenedor EJB.

Más tarde, Sun se dio cuenta de que la mayoría de las aplicaciones comerciales en realidad no distribuían EJB en un nivel diferente y arreglaron la especificación (en EJB 2.0) al introducir el concepto de interfaces locales para que los clientes colocados en la misma máquina virtual con el contenedor EJB puedan llamar a EJB utilizando invocación de método directo, sin pasar por alto la semántica de RMI (y la sobrecarga asociada).

Me han dicho que una de las grandes ventajas de Java EE es que es fácil de escalar (lo que creo significa que puede implementar diferentes componentes en diferentes servidores)

Java EE puede escalar, pero esto no necesariamente significa distribuir componentes. Puede ejecutar una aplicación Web + EJB en un clúster sin separar el nivel web y el nivel EJB.

¿Se supone que debe usar interfaces remotas si espera que su aplicación tenga diferentes componentes en diferentes servidores? ¿Y usa interfaces locales si su aplicación solo va a residir en un servidor?

Lo diría así: use interfaces remotas si el cliente no está en la misma JVM (esto no significa usar solo un servidor / JVM).

(...) Comience utilizando interfaces locales y actualice gradualmente a interfaces remotas cuando corresponda.

Probablemente comenzaría usando interfaces locales. Y como ya se indicó, cambiar a interfaces remotas no siempre es obligatorio (puede agrupar una estructura colocada ).

Sugiero verificar los recursos mencionados a continuación (los 2 primeros son bastante antiguos pero aún relevantes, los otros 2 son más recientes).

Recursos

• Bajo el capó de la agrupación J2EE por Wang Yu
• Escalando sus aplicaciones Java EE por Wang Yu
• Escalando sus aplicaciones Java EE - Parte 2 por Wang Yu

Si bien estoy de acuerdo con la mayoría de lo que está escrito anteriormente, me gustaría refinar un poco las ideas de "cómo comenzar".

Mi sugerencia para usted es que nunca jamás programar directamente a las interfaces EJB dentro de su código. Utilice siempre una interfaz regular orientada a los negocios, programe para ello (es decir, tenga sus métodos de llamada de código en la interfaz orientada a los negocios) y proporcione el código de "pegamento" EJB como una implementación conectable. Su programa debe centrarse en la lógica empresarial y no en los detalles de implementación, como EJB.

De esa manera, puede cambiar fácilmente entre implementaciones remotas y locales, y si usa un contenedor IoC como Spring, puede hacerlo solo mediante la configuración.

Una nota especial sobre el cambio de local a remoto: tenga en cuenta que hay algunas diferencias semánticas entre los dos. Por ejemplo, llamar a un método EJB a través de su "interfaz remota" hace que los argumentos se pasen por valor, mientras que llamar a través de la "interfaz local" hace que los argumentos se pasen por referencia. Este es un importante diferencia; así que si "comienza con lo local", asegúrese de diseñar su sistema de manera que también tenga en cuenta la semántica "remota".

Si su diseño se basa en métodos EJB que cambian los objetos pasados, entonces sería difícil "cambiar a remoto" más adelante; quizás incluso imposible.

Buena suerte.

Según la especificación 3.2 de EJB, un EJB puede ser local o remoto . Una interfaz de negocios no puede ser local y remota al mismo tiempo.

@Local Solo se puede acceder a beans anotados si están en la misma aplicación.

@Remote Se puede acceder a beans anotados a través de diferentes aplicaciones, que residen en diferentes jvms o en servidores de aplicaciones.

Entonces, las cosas importantes a tener en cuenta son:

1. Si una clase de bean contiene la @Remoteanotación, todas las interfaces implementadas deben ser remotas.
2. Si una clase de bean no contiene ninguna anotación o si @Localse especifica la anotación, se supone que todas las interfaces implementadas son locales.
3. Cualquier interfaz que esté explícitamente definida para un bean que no contenga interfaz debe declararse como @Local.
4. La versión EJB 3.2 tiende a proporcionar más granularidad para situaciones en las que las interfaces locales y remotas deben definirse explícitamente.

Esto puede responder a sus inquietudes:

En general, su Enterprise Java Bean necesitará una vista remota del cliente en los casos en que planee usar el bean en entornos distribuidos. Específicamente, estos son los casos en que el cliente que trabajará con él estará en una máquina virtual Java (JVM) diferente. En el caso de una vista de cliente remoto, la llamada a cualquier método desde la interfaz de inicio remota y / o la interfaz de componente remota se manejará mediante la invocación de método remoto (RMI).

Un EJB puede usar la vista de cliente local solo si realmente está garantizado que otros beans empresariales o clientes solo abordarán el bean dentro de una sola JVM. Si este es el caso, dicho acceso se realizará con llamadas a métodos directos, en lugar de RMI.

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