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


180

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.

Respuestas:


186

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


2
Encontré esta pregunta interesante. ¿Qué quiso decir con "cambiar a interfaces remotas no es absolutamente obligatorio"? ¿Eso significa que cuando agrega un nuevo cliente fuera de la misma JVM, no tiene que hacer una interfaz remota?
mohamida

2
@Josek Gracias, me alegro de que te guste @mohamida Hice un ligero cambio en la redacción. Lo que quise decir es que puedes agrupar una estructura colocada.
Pascal Thivent

1
Gracias por la respuesta y los recursos adicionales, han sido muy útiles. Parece que hay un par de formas de escalar una aplicación web ... es decir, distribuir los componentes (¿lo considero como dividir los diferentes niveles en diferentes JVM?) O usar el equilibrio de carga (que sería tener toda la aplicación activada) numerosos servidores?) y supongo que podría usar una combinación de ambos? ¿Conoces por casualidad buenos libros sobre este tema? ¡Gracias de nuevo!
Brian DiCasa

2
@Brian It seems like there are a couple ways of scaling a web application (...) and I suppose you could use a combination of both?Sí, eso es exactamente. Do you, by chance know of good books on this topic?Lamentablemente, no, no sé "ZE" recurso absoluto, si hay uno. Sin embargo, he agregado más recursos con algunas referencias.
Pascal Thivent

el primer enlace de recursos está muerto
Viacheslav Dobromyslov

48

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.


2
Suena como otra razón para minimizar la mutabilidad por java efectivo. ¿Esto ayudaría en la flexibilidad para "cambiar a remoto" para la interfaz de tipo RMI con EJB?
Thufir

19

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.

1
Pregunta: ¿Se puede utilizar @Localpara invocar un EJB en otra aplicación (JAR, WAR, EAR), pero la misma JVM?
Carlitos Way

@PritamBanerjee Cualquier idea sobre el Carlitos Wa, también estoy enfrentando el mismo problema. EJB está en un clúster diferente y la aplicación de servlet del cliente está en una diferente.
Govi S

@GovindaSakhare No estoy muy seguro de eso. Lo sentimos :(
Pritam Banerjee

7

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.