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


180

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.

Respostas:


186

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


2
Achei essa pergunta interessante. O que você quis dizer com "mudar para interfaces remotas não é absolutamente obrigatório"? Isso significa que, quando você adiciona um novo cliente fora da mesma JVM, não precisa criar uma interface remota?
mohamida 28/09/10

2
@ Josephk Obrigado, que bom que gostou @mohamida Fiz uma pequena alteração no texto. O que eu quis dizer é que você pode agrupar uma estrutura colocada.
Pascal Thivent

1
Obrigado pela resposta e pelos recursos adicionais, eles foram muito úteis. Parece que existem algumas maneiras de dimensionar um aplicativo da Web ... ou seja, distribuir os componentes (que eu considero dividir as diferentes camadas em diferentes JVM's) ou usar o balanceamento de carga (que teria o aplicativo inteiro ativado inúmeros servidores?) e suponho que você possa usar uma combinação de ambos? Você, por acaso, conhece bons livros sobre esse assunto? Obrigado novamente!
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?Sim, é exatamente isso. Do you, by chance know of good books on this topic?Infelizmente, não, não conheço o recurso absoluto "ZE", se houver um. Eu adicionei mais recursos com algumas referências.
Pascal Thivent 28/09/10

o primeiro elo recursos está morto
Viacheslav Dobromyslov

48

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.


2
parece mais um motivo para minimizar a mutabilidade por java eficaz. isso ajudaria na flexibilidade de "alternar para remoto" para uma interface do tipo RMI com EJBs?
Thufir

19

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.

1
Pergunta: Você pode usar @Localpara chamar um EJB em outro aplicativo (JAR, WAR, EAR), mas a mesma JVM?
Carlitos Way

@PritamBanerjee Qualquer idéia sobre o Carlitos Wa, também estou enfrentando o mesmo problema. O EJB está em um cluster diferente e o aplicativo de servlet do cliente está em um diferente.
Govi S

@GovindaSakhare Não tenho muita certeza disso. Desculpe ,(
Pritam Banerjee

7

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.