Real motivo para EJBs remotos em aplicações Web

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Pegando carona no outro tópico.
Pelos projetos que vejo o pessoal está usando EJB remotos por inércia sem motivo aparente.
Ou melhor ainda, EJB sem motivo aparente.

Já vi gente que alega ser por causa dos clusters.
Mas porque não colocar a aplicação toda se ela é web ?

Gostaria de opiniões !

Colocar a aplicação toda onde?

E cluster não tem necessidade de chamada remota.

Bem, depende muito..
Por exemplo:
Se o cliente expecifica que o aplicativo terá que suportar cluster e escalabilidade.
Aproveitando a onda de perguntas
Quanto ao que o pcalcado disse, eu tenho uma pergunta.
Cluster não é ter a mesma aplicação em servidores diferentes e que este se vire para saber qual é o servidor menos "abarrotado"?
Como poderia ter isso sem ser remoto?

Valeu

Pelo mesmo motivo que usam XML a torto e a direito.

Já vi aplicação usando EJB e retornando XML para o web-tier processar, a escalabilidade ficou patética, devem ter precisado de um E10K para romper os 10 usuarios simultâneos.

kina wrote:
Cluster não é ter a mesma aplicação em servidores diferentes e que este se vire para saber qual é o servidor menos "abarrotado"?
Como poderia ter isso sem ser remoto?

Não, isso é load balancing.

Cluster nesse caso é você ter uma única aplicação distribuída em vários nós.

This message was edited 1 time. Last update was at 03/05/2005 18:03:25

Vou explicar melhor:

Já me falaram que um bom motivo para criar tiers entre a camada web e a camada de negócios seria criar uma cluster da camada de négocio entre vários servidores.
quer dizer manter a tier web da tier de negócio separados.

Também acho estranho pois não seria mais fácil replicar toda a aplicação.
E manter a camada web e de negócio na mesma tier.

Independente disso quais as vantagens dos EJBs na opinião e experiências de vcs?

EDITADO:
Isso mesmo o nome certo é Load Balance.

Mantendo o negocio em um tier diferente você tem o reuso de forma mais facil entre aplicações.

Bem, se você realmente quer manter sua interface web separada, vai poder usar load balancing sim e vai ter que usar interfaces remotas. Note que isso pode acabar sendo mais lento, na verdade (já aconteceu comigo).

"Replicar" que você diz é mantêr várias cópias da aplicação? Se você tem uma aplicação onde o estado dos objetos não é mantido, pode ser bem legal, mas se você precisa que os mesmos objetos sejam manipulados por nós diferentes, clusterizar pode salvar sua alma contra problemas de concorrência. Claro que você sempre pode confiar no seu SGBD para fazer a sincronização, mas estratégias de caching constumam jogar os locks do BD pela janela, você acaba com lentidão ridícula com locks retidos inutilmente nos registros, principalmente por malditos entity beans.

Se você puder, utilize uma estratégia de cache distribuído de objetos, provido pelo container ou não

pcalcado wrote:Cluster nesse caso é você ter uma única aplicação distribuída em vários nós.

Ele deve ter confundido com Cluster de banco, que é basicamente como ele disse.

Um cluster pode usar tanto o modelo SSI (Single System Image), o mais comum, quando um amontoado de máquina se apresentam como um sistema só aos seus usuarios; ou o modelo federado, quando cada nó realiza atividades proprias em colaboração com os outros.

jprogrammer wrote:
Independente disso quais as vantagens dos EJBs na opinião e experiências de vcs?

O legal do GUJ é que os questionamentos sempre voltam!

EJB x QualQuerOutraCoisa http://www.guj.com.br/posts/list/15/21063.java

morte EJB???
http://www.guj.com.br/posts/list/15/2339.java

[]'s
Marco Campêlo

Notícias, artigos e o maior fórum brasileiro sobre Java