Dúvida básica de EJB

É meio complicado explicar - se você puder pedir emprestado para alguém o livro da Kathy “Head First EJB”, vai aprender direitinho. É que para entender direito você precisa desenhar alguns diagramas, até pegar o jeito.

toma ae mas depois devolve 8)

http://rapidlibrary.com/index.php?q=Head+First+EJB&filetype=0

att,

A chave para entender EJB, ou qualquer outro mecanismo de RPC, é conhecer o [google]pattern proxy[/google].

Quando uma interface é marcada por @Remote, o container EJB não injeta a classe que você fez (que herda a interface citada e é anotada por @EJB), mas sim uma classe Stub, que implementa os métodos da interface para fazer chamadas remotas. Do outro servidor, onde os EJBs estão, existem os Skeletons, instanciados pelo container EJB para ouvir as chamadas de métodos vindo de outros lugares e chamar o método do objeto EJB da classe que você criou. Essas classes Stubs e Skeletons costumam aparecer em servidores de aplicação antigos, onde havia rotinas antes da geração do EAR para criar essas classes. Atualmente, tudo é feito dinamicamente, e você não vê mais as classes intemediárias.

O EJB remoto só faz sentido se você tiver um cluster de servidores de aplicações, o que, na maioria das vezes, não é feito e nem sua implementação é justificável. Um EJB cliente não precisa saber o endereço do EJB remoto para funcionar, isso é descoberto automaticamente.

Leonardo3001:

A chave para entender EJB, ou qualquer outro mecanismo de RPC, é conhecer o [google]pattern proxy[/google].

Quando uma interface é marcada por @Remote, o container EJB não injeta a classe que você fez (que herda a interface citada e é anotada por @EJB), mas sim uma classe Stub, que implementa os métodos da interface para fazer chamadas remotas. Do outro servidor, onde os EJBs estão, existem os Skeletons, instanciados pelo container EJB para ouvir as chamadas de métodos vindo de outros lugares e chamar o método do objeto EJB da classe que você criou. Essas classes Stubs e Skeletons costumam aparecer em servidores de aplicação antigos, onde havia rotinas antes da geração do EAR para criar essas classes. Atualmente, tudo é feito dinamicamente, e você não vê mais as classes intemediárias.

O EJB remoto só faz sentido se você tiver um cluster de servidores de aplicações, o que, na maioria das vezes, não é feito e nem sua implementação é justificável. Um EJB cliente não precisa saber o endereço do EJB remoto para funcionar, isso é descoberto automaticamente.

Obrigado por responder…estou perguntando isso, pois tenho uma aplicação aqui que usa hibernate e faz um insert com o persist(). Só que eu debugando, não vejo onde ele faz o commit, imaginei que talvez ele fizesse o commit no servidor remoto :S