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