EJB's - quando usar interfaces remotas e / ou locais?

Sou muito novo no Java EE e estou tentando entender o conceito de interfaces locais e interfaces remotas. Foi-me dito que uma das grandes vantagens do Java EE é que é fácil de escalar (o que acredito que significa que você pode implantar componentes diferentes em servidores diferentes). É aí que entram as interfaces remota e local? Você deveria usar interfaces remotas se espera que seu aplicativo tenha componentes diferentes em servidores diferentes? E use interfaces locais se seu aplicativo residir apenas em um servidor?

Se minhas suposições acima estiverem corretas, como você escolheria usar interfaces local ou remota para um novo aplicativo, onde não tem certeza de qual seria o volume de tráfego? Comece usando interfaces locais e atualize gradualmente para interfaces remotas, quando aplicável?

Obrigado por qualquer esclarecimento e sugestões.

Sou muito novo no Java EE e estou tentando entender o conceito de interfaces locais e interfaces remotas.

Nas versões iniciais da especificação EJB, os EJBs eram "assumidos" como componentes remotos e a única maneira de invocá-los era fazer uma chamada remota, usando a semântica RMI e toda a sobrecarga que isso implica (uma chamada de rede e serialização de objeto para cada chamada de método). Os clientes EJB tiveram que pagar essa penalidade de desempenho mesmo quando colocados na mesma máquina virtual com o contêiner EJB.

Posteriormente, a Sun percebeu que a maioria dos aplicativos de negócios não estava distribuindo EJBs em uma camada diferente e eles corrigiram a especificação (no EJB 2.0) introduzindo o conceito de interfaces locais para que os clientes colocados na mesma máquina virtual com o contêiner EJB possam chamar EJBs usando invocação direta de método, ignorando totalmente a semântica de RMI (e a sobrecarga associada).

Disseram-me que uma das grandes vantagens do Java EE é que é fácil de escalar (o que acredito significa que você pode implantar componentes diferentes em servidores diferentes)

O Java EE pode ser dimensionado, mas isso não significa necessariamente a distribuição de componentes. Você pode executar um aplicativo Web + EJB em um cluster sem separar a camada da Web e a camada EJB.

Você deveria usar interfaces remotas se espera que seu aplicativo tenha componentes diferentes em servidores diferentes? E use interfaces locais se seu aplicativo residir apenas em um servidor?

Eu diria o seguinte: use interfaces remotas se o cliente não estiver na mesma JVM (isso não significa usar apenas um servidor / JVM).

(...) Comece usando interfaces locais e atualize gradualmente para interfaces remotas, quando aplicável?

Eu provavelmente começaria usando interfaces locais. E, como já foi sugerido, a mudança para interfaces remotas nem sempre é obrigatória (você pode agrupar uma estrutura colocada ).

Sugiro verificar os recursos mencionados abaixo (os 2 primeiros são bastante antigos, mas ainda relevantes, os 2 outros são mais recentes).

Recursos

• Sob o capô do cluster J2EE por Wang Yu
• Escalando seus aplicativos Java EE por Wang Yu
• Escalando seus aplicativos Java EE - parte 2 por Wang Yu

Embora eu concorde com a maior parte do que está escrito acima, eu gostaria de refinar um pouco as idéias de "como começar".

Minha sugestão para você é nunca nunca programar diretamente às interfaces EJB dentro de seu código. Sempre use uma interface regular, orientada a negócios, programe-a (ou seja, tenha seus métodos de chamada de código na interface orientada a negócios) e forneça o código de "cola" do EJB como uma implementação conectável. Seu programa deve se concentrar na lógica de negócios, e não nos detalhes da implementação, como EJB.

Dessa forma, você pode alternar facilmente entre implementações remotas e locais - e se você usar um contêiner de IoC, como o Spring, poderá fazê-lo apenas por meio de configuração.

Uma observação especial sobre como mudar de local para remoto: observe que existem algumas diferenças semânticas entre os dois. Por exemplo, chamar um método EJB por meio de sua "interface remota" resulta em argumentos sendo passados ​​por valor, enquanto chamar a "interface local" resulta em argumentos sendo passados ​​por referência. Essa é uma grande diferença; portanto, se você "começar com local", certifique-se de projetar seu sistema de forma que leve em consideração a semântica "remota".

Se o seu design depende de métodos EJB alterando objetos passados, seria difícil para você "mudar para remoto" mais tarde; talvez até impossível.

Boa sorte.

De acordo com o EJB Spec 3.2, um EJB pode ser local ou remoto . Uma interface de negócios não pode ser local e remota ao mesmo tempo.

@Local os beans anotados podem ser acessados ​​apenas se estiverem no mesmo aplicativo.

@Remote beans anotados podem ser acessados ​​em diferentes aplicativos, residindo em diferentes jvms ou em servidores de aplicativos.

Portanto, as coisas importantes a serem lembradas são:

1. Se uma classe de bean contiver a @Remoteanotação, todas as interfaces implementadas deverão ser remotas.
2. Se uma classe de bean não contiver anotação ou se a @Localanotação for especificada, todas as interfaces implementadas serão consideradas locais.
3. Quaisquer interfaces definidas explicitamente para um bean que não contenha nenhuma interface devem ser declaradas como @Local.
4. A liberação do EJB 3.2 tende a fornecer mais granularidade para situações em que as interfaces local e remota precisam ser explicitamente definidas.

Isso pode responder às suas preocupações:

Geralmente, o Enterprise Java Bean precisará de uma visualização remota do cliente nos casos em que você planeja usar o bean em ambientes distribuídos. Especificamente, esses são os casos em que o cliente que trabalhará com ele estará em uma Java Virtual Machine (JVM) diferente. No caso de uma visão remota do cliente, a chamada de qualquer método a partir da interface inicial remota e / ou da interface do componente remoto será tratada via RMI (Remote Method Invocation).

Um EJB pode usar a visualização do cliente local apenas se for realmente garantido que outros beans corporativos ou clientes apenas endereçam o bean em uma única JVM. Se for esse o caso, esse acesso será realizado com chamadas de método diretas, em vez de RMI.

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