Injeção de referência remota de EJB

Na verdade a maneira mais comum de se implantar uma aplicação JEE é através de um EAR. Nesse caso, não importa se vc está
utilizando um cluster ou se roda em uma unica máquina, os componentes dos módulos web poderão sempre acessar as interfaces
locais dos EJBs. Do ponto de viste de um componente web todo EJB do pertencente ao mesmo projeto é local.

dev.rafael:

Na verdade a maneira mais comum de se implantar uma aplicação JEE é através de um EAR. Nesse caso, não importa se vc está
utilizando um cluster ou se roda em uma unica máquina, os componentes dos módulos web poderão sempre acessar as interfaces
locais dos EJBs. Do ponto de viste de um componente web todo EJB do pertencente ao mesmo projeto é local.

Olá Rafael,

Você tem certeza qe que isso funciona?

Eu sempre soube que se a aplicação está rodando em diferentes clusters, só era possível o acesso a interfaces remotas, o que pra mim até faz sentido, visto que interfaces locais utilizam a referência dos objetos na JVM e passam parâmetros por referência. Se os objetos estiverem em diferentes JVMs, um objeto não conseguiria acessar a referência de outro, em outra JVM.

Esse link inclusive fala:

No caso, em um ambiente clusterizado, os containers estariam separados.

Agora fiquei na dúvida.

Alguém confirma?

Sim! O comportamento é esse mesmo. É importante notar as diferenças na maneira como você implanta a sua aplicação.

O modo mais comum de se implantar uma aplicação JEE é empacotar todos os módulos WEB e EJB dentro de um EAR e
implantar esse EAR em um servidor clusterizado. Nesse caso o cluster serve como um meio de distribuir a carga das
requisições, mas principalmente como um recurso de segurança a mais posto que se um nó do cluster “cai” por algum
motivo, outro nó possuirá uma cópia das sessões web e dos SFSBs do nó que caiu, assim o usuário conectado nem vai
perceber que houve algum problema. Nesse caso, ainda, todos os componentes WEB acessam apenas EJBs locais. O
balanceamento de carga fica por conta de um outro programa, geralmente um iPlanet ou nginx. Esses programas são
proxies reversos, eles recebem a requisição HTTP e direcionam para algum nó do seu cluster. Ou seja, o seu servidor
Java só tem o trabalho de manter copias dos dados desses nós para o caso de algum falhar.

Outro modo seria você implantar os módulos WEB e EJB separados, sem um projeto EAR. Nesse caso, os componentes
dos modulos WEB precisariam usar as interfaces remotas dos EJBs para acessa-los (ou mesmo uma interface REST, agora
com o EJB 3.1) pois eles não fazem parte do mesmo projeto. Até mesmo os próprios EJBs precisariam usar as interfaces
remotas para acessar EJBs em outros modulos. Mesmo que eles estejam na mesma máquina.

Eu não vejo muito motivo para você usar esse segundo modo de implantação já que ele envolve mais complexidade e o
overhead de acesso a interfaces remotas é bem maior que de interfaces locais. Em geral, você só vai precisar usar
interfaces remotas em EJBs se o front end for uma aplicação desktop ou applet, ou por conta de alguma política doida
da sua empresa.