Um bocado de duvidas com JEE

3 respostas
tRuNkSnEt

Em meus estudos de JEE surgiram algumas duvidas teoricas, as quais seguem a baixo:

Eu criei um Componente EJB que realizava a função de um Contador de Acesso. Criei primeiramente um Session Bean Stateless e carreguei diversos clientes e observei que a numeração incrementava de acordo com a quantidade de clientes que acessava meus EJBs. Então fiz pequenas modificações e transformei meu Stateless Bean em um Stateful Bean e observei que embora o incremento estivesse sendo realizado o resultado era sempre 1. Não era para acontecer o contrario? O Stateless não deveria perder o estado de conversação e o Stateful não deveria manter o estado? Alguém tem uma explicação mais plausível para minha simplória duvida? Partindo do exemplo eu posso dizer que Session Beans Stateless são semelhantes aos objetos servlets thread-safe? O que me permitiria trabalhar facilmente com , por exemplo, com uma conta bancaria que não pode ficar negativa mas pode ter acessos simultâneos?

Observei também que de uma forma ou de outra o desenvolvedor dos clientes precisão conhecer a interface remota do EJB. Vamos supor que eu vendi meus Componentes para uma outra equipe; como que essa outra equipe pode obter informações das interfaces remotas dos meus componentes? Somente através de documentação? Nesse caso seria interessantes utilizar o javadoc para fazer a documentação das regras de negócios para a minha equipe e outra documentação publica das interfaces remotas? O pior ainda está por vir! Se eu por loucura alterar o comportamento dos meus componentes todas essas alterações vão refletir nos clientes provocando um forte acoplamento entre o cliente e os componentes?

Suponhamos que eu tenho um sistema distribuído mas cada “subsistema” trabalha independente uns dos outros, apenas trocam informações entre si. Se eu estiver utilizando EJB e meu Servidor de Aplicação cair todos os clientes independentes entre si, logicamente não conseguirão acessar os objetos de negócios? Esse é um caso que não justifica utilizar EJBs uma vez que posso trocar mensagens entre esses aplicativos usando apenas xml (RSS)?

Que diferença tem entre EJBs e WebServices (wsdl)? Pelo que vi posso conseguir distribuir serviços utilizando EJBS assim como webservices? Dessa maneira posso vender não somente componentes EJBS mas também serviços através da especificação JEE?

Resumindo, qual o cenário em que realmente vale a pena utilizar EJBS? Afinal vejo mais limitações do que vantagens!

3 Respostas

Fabricio_Cozer_Marti

Eliezer Reis:
Eu criei um Componente EJB que realizava a função de um Contador de Acesso. Criei primeiramente um Session Bean Stateless e carreguei diversos clientes e observei que a numeração incrementava de acordo com a quantidade de clientes que acessava meus EJBs. Então fiz pequenas modificações e transformei meu Stateless Bean em um Stateful Bean e observei que embora o incremento estivesse sendo realizado o resultado era sempre 1. Não era para acontecer o contrario? O Stateless não deveria perder o estado de conversação e o Stateful não deveria manter o estado? Alguém tem uma explicação mais plausível para minha simplória duvida? Partindo do exemplo eu posso dizer que Session Beans Stateless são semelhantes aos objetos servlets thread-safe? O que me permitiria trabalhar facilmente com , por exemplo, com uma conta bancaria que não pode ficar negativa mas pode ter acessos simultâneos?

Sim lógico, o Stateful MANTEVE o estado, afinal vc é um cliente , e a especificação diz que Stateful é pra manter o estado de um cliente específico e um Stateless beans serve a diversos clientes.

O ciclo de vida dos dois tipos também diferem.

fabriciobraga

EJBs utilizam RMI, e Web Services utilizam um protocolo chamado SOAP, baseado em XML.

O SOAP é mais lento que o RMI, mas quando se fala de integração de aplicações baseadas em tecnologias diferentes, há um motivo razoável para usar Web Services, porque todas “falam” SOAP, mas nem todas “falam” RMI.

As motivações principais para usar EJB, na minha modesta opinião seriam:

  • Controle transacional
  • Escalabilidade
  • Arquitetura com diferentes clientes (Web e Swing, por exemplo)
  • Independência dos componentes de negócios da camada de persistência

Muitas pessoas vão dizer, talvez com razão, que devemos evitar utilizar EJBs quando realmente não houver necessidade. Que quando couber devemos sempre preferir utilizar POJOs e DAO, etc.

Mas com a nova especificação (JSR 220) para o EJB (EJB 3.0), os antigos Entitys Beans não são mais serviços, e sim… POJOS!

Acredito que com a simplificação e diminuição drástica da curva de aprendizado que essa nova especificação traz, essas críticas deveriam ser repensadas.

Porque não usufruir de toda a robustez que um conteiner de EJB oferece, com seu controle transacional, otimização da perfornance usando cache para queries, etc? Porque abrir mão de ter uma arquitetura altamente escalável?

Quando o argumento da complexidade do desenvolvimento não existe mais, acho que deveríamos repensar as críticas quanto ao uso de EJBs.

Espero ter ajudado.

Fabricio Braga
SCJP 1.5
http://www.fabriciobraga.com.br

tRuNkSnEt

Obrigado pelas dicas fabricio. Corri a traz de mais informações é seus artigos foram de grande valia. Qualquer coisa estamos na area,

Até!

Criado 29 de abril de 2006
Ultima resposta 5 de mai. de 2006
Respostas 3
Participantes 3