Também uso Oracle iAS aqui no trabalho…
Tenho o mesmo requisito de mais de um servidor provendo EJBs. Estes servidores podem mudar. Hoje a aplicação está rodando em um servidor, mas amanhã pode ser que tenha que rodar em um outro - por N motivos que não vem ao caso. Então, isso tem que ficar transparente para as aplicações.
Minha solução…
Onde quer que exista um cliente dos meus EJBs (seja outro EJB, ou web app, ou sei lá o que), há um diretório mapeado para uma variável de ambiente MINHA_APP_HOME. Neste diretório há um sub-diretório config, onde tenho meus arquivos *-jndi.properties contendo as configurações de JNDI para cada servidor.
Assim, se uma aplicação precisar acessar outro servidor para consumir os mesmos EJBs, apenas mudo a configuração em um desses arquivos que estão fora do meu EAR, e boa, tá tudo funcionando.
A resumo, a minha solução foi essa…
Acho que pode ser mais ou menos adaptada para o que você precisa.
Abraço!
Legal!
Bom saber que outros também tem as mesmas dificuldade que eu.
A sua solução é basicamente o que eu propus aqui. Vejo que não tem o que fazer fora isso mesmo.
Pobre de nós!
[quote=danieldestro]Legal!
Bom saber que outros também tem as mesmas dificuldade que eu.
A sua solução é basicamente o que eu propus aqui. Vejo que não tem o que fazer fora isso mesmo.
Pobre de nós![/quote]
Verdade!
Escrevi minha experiência mesmo pra você ver que você não é o único…
Abraço!
nao tem mesmo como fazer uma inversao de controle ai de jeito nenhum? se nao tiver, acho que eh a unica solucao viavel…
bem, receber o ServiceLocator via construtor em vez de usar o acesso singleton ja deixa o codigo muito mais elegante.
Bom, no meu caso, o problema é que quem usa os meus EJBs não são somente EJBs, dai eu não poderia usar a injeção de dependência do próprio containner. Mas até ai, tudo bem, esse não é o maior problema, eu poderia facilmente fazer uma injeção via Spring, por exemplo. Mas isso não resolveria o meu requisito de poder alterar o servidor onde estão meus EJBs sem afetar os aplicativos clientes (digo: ter que alterar e redeployar), sejam eles EJBs ou não. Porque todas as vezes que eu precisasse mudar meus EJBs de servidor (isso não será sempre, claro, mas ainda que sejam pouquíssimas vezes, eu não tenho domínio sobre os aplicativos clientes), teria também que ser modificadas as propriedades JNDI usadas pelos aplicativos clientes.
Mas ainda não é tudo. Eu também não tenho acesso ao servidor de produção, então, preciso prover pro pessoal de infra que cuida do servidor de produção, uma maneira de alterar usuário e senha do app-server sem ter que gerar um novo EAR, etc.
Então, tenho o problema da remotabilidade transparente (nem sei que essa frase está semanticamente correta, but…) e o problema da falta de “poderes” no servidor de produção.
Nosso build, então, é gerado pelo nosso ambiente de integração contínua e implantado no servidor de homologação; estando tudo OK, quando dos releases, o pessoal de infra apenas pega o EAR gerado e faz deploy na produção (na verdade até pelo próprio ambiente de i.c.).
É, é mais ou menos isso…
Depois de pensar, testar, e pensar, e testar novamente, esta foi a solução que cheguei e não tive problemas até agora… graaaças a Deus! 
Depois de fazer uns profilers, acabei optando por usar um ServiceLocator cacheado, por causa do custo de inicialização e lookup; e, quando necessário, caso modifique propriedades JNDI, basta fazer um refresh na aplicação e boa, tá tudo no ar novamente.
Bom, pelo menos até agora não houve nenhum problema. É claro que, em cluster, vou ter uma instancia de ServiceLocator em cada nó, mas isso também não será o fim.
[code]@Stateless
public class MeuPehDeJacarandaBean implements MeuPehDeJacaranda {
@EJB
private ServiceLocator locator;
public void alimentarMe() {
List nutris = locator.getEJB(“Solo”).extrairNutrientes();
yammi( nutris );
}
}[/code]
Hehehehehehe… um ServiceLocator & EJB.
Na versão 3.1 do EJB deverá haver EJB Singleton.
Sei que o Rodrigo já disse sobre isso Daniel, mas eu tbm acho que a saída mais transparente é utilizar as instancias em Cluster. Não ter que se preocupar em que host esta o componente e ainda ter ganhos de fail-over e load-balance é algo a se pensar.
http://download-uk.oracle.com/docs/cd/B32110_01/web.1013/b28221/undejdev011.htm
Você tem alguma restrição quanto a isso ou o foco do problema não é este ?
Cluster e Load Balance não é minha necessidade.
O que preciso mesmo é ter serviços em diferentes containers.
Seja por uma questão de serviços verticais (ex: vendas, rh, financeiros), ou por demanda (volume de uso).
Mas este é um requisito ou decisão de arquitetura sua? Se for uma decisão a ser tomada por você, vale apenas considerar um parque de máquinas trabalhando de forma colaborativa, não vale?
Ainda não é requisito, será uma decisão conjunta da área de arquitetura (que me incluo) e do gerente.
A princípio, não deve rodar nada em cluster, apenas load balance, mas não gerenciado pelo App Server.
É que cada serviço vertical (rh, financeiro, etc) precisa rodar em uma instância diferente, para que sua manutenção não afete diretamente uma outra. Se estiverem num mesmo container, isso prejudica.
Não é o caso de Load Balance ou Cluster.
service locator ser um ejb stateless ficou perfeito! e ai faz injecao. parabens daniel. enquanto nao vem o ejb singleton, deixe o mapa de objetos estatico dentro do locator!
