Testar funcionamento de instância de EJB Stateless/Stetefull bean 3.0

Como voce fez esse objeto proxy?

Na verdade esse objeto foi o que obtive através do lookup, criado pelo InitalContext.

Aplicação Desktop certo?

Indiferente.
Mas suponha que sim.

Existe alguma forma de testar se aquele objeto “lookpeado” ainda é válido?

Obrigado!

É realmente não posso afirmar nada.

o que posso te afirmar é que quando o container a “passiva” um bean por exemplo… ele se responsabiliza por na hora de “ativar novamente” restaurar as referencias a outros EJB, agora como ele faz isto se é fazendo lookup novamente ou de outra forma. Teria que dar uma olhada em alguma implementação por exemplo a do Jboos talvez la você encontre algum exemplo de como fazer isto sem ficar fazendo lookup toda hora.

t+

Olá, a interface remota do seu ejb eh um proxy remoto que contem informacoes de onde seu servidor esta localizado na rede. Quando vc invoca um metodo de negocios na sua interface remota , a conexao eh feita com seu servidor , e uma instancia do pool de beans(SLSB, no caso de SFSB uma instancia dedicada) eh escolhida para servir sua solicitacao.
A conexao eh feita toda vez q vc chama o metodo de negocio e nao quando vc faz lookup, logo seu proxy nunca esta invalido (a conexao eh stateless). Tente isso faca o lookup obtenha o proxy no cliente , interrompa a thread dele, derrube seu servidor, suba ele novamente ,e continue a thread do cliente chamando seu metodo de negocio , seu servico funciona normalmente , se o servidor nao tiver disponivel sera gerado uma excessao apenas . Para encapsular esse codigo de tratamento de tentativas de conexao no seu servidor e de excessoes de conexao , use o padrao business delegate. Para nao fazer lookup o tempo todo e nao estiver usando injecao de dependencia use o padrao Service Locator com cache. Para evitar esse problema da indisponibilidade de servidor e se precisar escalar o sistema, considere clusterizar , assim outros nos podem responder se um estiver inativo, outra solucao eh desacoplar seu cliente e seu servidor com mensagens assincronas.

Obs: No ejb2 da pra vc obter um manipulador(atraves de getHandle do EJBobject) , transformar ele em string , gravar no banco e depois recuperar e reconstruir e reobter a referencia remota , da para criar ejbobject no ejb3 da mesma forma , mas nao sei se eh a melhor forma nao.

Espero ter ajudado.

hehe ajudou bastante.

Na verdade você descreveu exatamente o que implementei, um ServiceLocator com cache.

Ele obtém as instâncias por demanda, alternando entre nós pré-configurados, encapsulando toda a chamada de lookup, tornando isso transparente para os usuários do SL.
O que ficou faltando foi uma forma não intrusiva de testar se aquela instância no cache ainda é válida, afim de refazer lookup ou ainda em caso de falha tentar outro nó, pra somente ai retornar a instância pro cliente.

Sim, só com beans stateless, caso contrário o cache seria uma solução bastante equivocada.

Isso tudo já está implementado a um tempo, mas queria uma forma mais inteligente de fazer esse teste.
Esses dias fiz um “roadmap” com melhorias do SL e uma delas é justamente fazer esse teste de forma não intrusiva (não me perguntem como é feito hoje hehehe), entre outras opções extras.

Anyway, foi um exercício maravilhoso implementar esse cara! Como ainda vai levar um bom tempo pra todas as aplicações usarem injeção de dependência ele será bastante útil até lá.

Edit: incrível, você realmente descreveu EXATAMENTE o que eu tinha implementado. Há mais recursos disponíveis, vou me informar se posso expô-los… seria legal compartilhar esse cara com a comunidade, seria uma mão na roda!