java java-ee ejb

java - @ejb



EJB: ¿cuándo usar interfaces remotas y/o locales? (4)

Soy 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 de 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 tenían que pagar esta penalización de rendimiento incluso cuando estaban ubicados 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 empresariales no distribuían EJB en un nivel diferente y repararon 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 invocar EJB usando invocación de método directo, omitiendo totalmente 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 que significa que puede implementar diferentes componentes en diferentes servidores)

Java EE puede escalar, pero esto no significa necesariamente 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 debes usar interfaces remotas si esperas que tu aplicación tenga componentes diferentes en servidores diferentes? ¿Y usa interfaces locales si tu aplicación solo va a residir en un servidor?

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

(...) Comience usando las interfaces locales, y actualice gradualmente a las interfaces remotas donde corresponda?

Probablemente comenzaría usando interfaces locales. Y como ya se sugirió, el cambio a interfaces remotas no siempre es obligatorio (puede agrupar una estructura coubicada ).

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

Recursos

Soy 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 debes usar interfaces remotas si esperas que tu aplicación tenga componentes diferentes en servidores diferentes? ¿Y usa interfaces locales si tu aplicación solo va a residir en un servidor?

Si mis suposiciones anteriores son correctas, ¿cómo elegiría si utilizará las interfaces Locales o Remotas para una nueva aplicación, si 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 sugerencias.

Esto puede responder a sus inquietudes:

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

Un EJB solo puede usar la vista de cliente local si realmente se garantiza que otros beans o clientes empresariales solo direccionarán el bean dentro de una sola JVM. Si este es el caso, dicho acceso se llevará a cabo 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

Según EJB Spec 3.2, un EJB puede ser local o remoto . Una interfaz de negocios no puede ser tanto local como remota al mismo tiempo.

@Local frijoles solo se puede acceder si están en la misma aplicación.

@Remote puede acceder a @Remote beans anotados en 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 anotación @Remote , todas las interfaces implementadas deben ser remotas.
  2. Si una clase de bean no contiene ninguna anotación o si se especifica la anotación @Local , se supone que toda la interfaz implementada es local.
  3. Cualquier interfaz que se defina explícitamente para un bean que no contenga ninguna interfaz debe declararse como @Local.
  4. El lanzamiento de EJB 3.2 tiende a proporcionar más granularidad para situaciones donde las interfaces locales y remotas necesitan definirse explícitamente.

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 programe directamente en interfaces EJB dentro de su código. Siempre use un programa de interfaz regular orientado a negocios (es decir, tenga sus métodos de llamada de código en la interfaz orientada a negocios) y proporcione el código EJB "pegamento" como una implementación conectable. Su programa debe centrarse en la lógica de negocios, y no en detalles de implementación como EJB.

De esta forma, puede cambiar fácilmente entre implementaciones remotas y locales, y si utiliza un contenedor IoC como Spring, puede hacerlo solo mediante 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" da como resultado que los argumentos pasen por valor-por, mientras que la llamada a través de la "interfaz local" hace que los argumentos pasen por referencia. Esta es una gran diferencia; así que si "comienzas con local", asegúrate de diseñar tu sistema de forma 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 complicado para usted "cambiar a remoto" más tarde; quizás incluso imposible.

Buena suerte.