Chamando um método de um EJB a partir de outro container?

Se entendi bem,
sendo eles EJB`s, podem ser acessados remotamente, de qualquer lugar da rede…e um servico
que esta disponivel na rede, e vc acessa ele remotamente…
para acessa-los, usa-se as interfaces, a interface home para “instanciar” o objeto, e a interface
remote para acessar os metodos…
e essa a duvida???

[]`s
Alexandre Martins.

O problema é que não estando no mesmo container, não será encontrada a interface home para instanciar o EJB.
Entendeu?

Como é que me referencio a outros EJBS em outros servidores (vários)?

Obrigado por tentar me ajudar…

Rapaz, todo EJB pode ser cliente de outro, é só vc colocar o seu ejb do container A para criar todo aquele processo que provavelmente vc ja cria em seus clientes:

cria um InitialContext, faz o lookup chama o create e manda bala!

Uma boa forma de se fazer isso é atraves de interfaces locais, vc pode importa-las para o seu projeto A e usalas dentro do seu SessionBean se preferir ok?
[]s
leo

“leo.dep”:

Uma boa forma de se fazer isso é atraves de interfaces locais, vc pode importa-las para o seu projeto A e usalas dentro do seu SessionBean se preferir ok?
[]s
leo

Como os EJB’s estão em conteiners (Servidores) diferentes, a chamada por interfaces locais não é possivel, pois não estão na mesma JVM.

Agora com relação a trocar o InitialContext, isso deve funcionar sem problemas.

[]'s
Gustavo Eduardo Abras
Sun Certified Programmer for Java 2 Plataform

geabras escreveu:
Como os EJB’s estão em conteiners (Servidores) diferentes, a chamada por interfaces locais não é possivel, pois não estão na mesma JVM.
Agora com relação a trocar o InitialContext, isso deve funcionar sem
problemas.

leo responde:
é possivel sim eu faço, exemplo:

SessionBean:

private void metodoXXX (String aaa, String sss, Integer i)

throws FinderException {

Collection eee = localHome.findXXX(aaa, sss);

Iterator it = eee.iterator();

while(it.hasNext()){

InterfaceLocal local = (InterfaceLocalHome)it.next();

Set q = local.getXXX();

if (!q.isEmpty()){	

local.setXXX(i);

else

local.setXXX(null);

}

}

public void ejbActivate() throws EJBException {

try{

InitialContext ctx = new InitialContext();

localHome = (InterfaceLocalHome) ctx.lookup(“local/ejb/Name”);

}

catch(NamingException n){

}

}

public void ejbPassivate() throws EJBException {

homeExercicio = null;

}

Se vc estiver utilizando dois servidores, e estiver utilizando a rede para trocar informações entre eles, vc deve utilizar as interfaces remotas do ejb.
Porem, se vc estiver utilizando, em um mesmo servidor, projetos diferentes, vc pode utilizar as interfaces locais.

A necessidade de utilização das interfaces, se dá pelo tráfego ou não dos objs na rede.

Galera, o problema eh outro, lembrando que:

Caso o acesso seja a outra jvm as interfaces remotas e os stubs tambem devem ser distribuidos

Como o deploy foi feito em dois appservers diferentes os ejbs nao serao publicados na mesma JNDI (a nao ser que tenha sido configurado para isso!).

Logo vc precisa avisar ao InitialContext onde esta a jndi do outro appserver se nao o lookup nao vai achar ninguem do outro app server.

O InitialContext pode receber um HashTable com informacoes de configuracao (ver mais em javax.naming.Context) como urls, usuario, senha etc.

Procure na documentacao do app server o que deve ser passado como parametro no InitialContext para que ele encontre a outra jndi, a key que representa essa configuracao eh Context.PROVIDER_URL.

import javax.naming.*;
import java.util.*;

public class TesteJndi
{
       public static void main(String[] args) {
              Hashtable env = new Hashtable(11);
              env.put(Context.PROVIDER_URL, "ProcureNosDocsDoAppServer://oque_vai_aqui:000");

             try{

                     Context ctx = new InitialContext(env);

                     ctx.lookup("ejb/EjbB"); // aqui o lookup no outro container

                     .....

              }catch(Exception e){
                     e.printStackTrace();
              }
       }
}

aqui um codigo para jrun 3.x, onde alem do provider o usuario e senha tb sao passados:

...
import javax.naming.InitialContext;
import javax.naming.Context;
...
try {
      Properties properties = new Properties();
      properties.setProperty(Context.INITIAL_CONTEXT_FACTORY, "allaire.ejipt.ContextFactory");
      properties.setProperty(Context.PROVIDER_URL, "ejipt://remotehost:2773");
      String user_name = "client";
      String password = "client";
      properties.setProperty(Context.SECURITY_PRINCIPAL, user_name);
      properties.setProperty(Context.SECURITY_CREDENTIALS, password);

      Context ctx = new InitialContext(properties);
...

mais um codigo, soh que com weblogic:

private Context getInitialContext() throws NamingException {

      Hashtable h = new Hashtable();						
      h.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
      h.put(Context.PROVIDER_URL, "t3://localhost:7001");
      h.put(Context.SECURITY_PRINCIPAL, "username");
      h.put(Context.SECURITY_CREDENTIALS, "password");

      return new InitialContext(h);

  }

Eh isso ai,

abraco,