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