RES: [cejug-discussao] Load Balance e ciclo de vida de EJB's

[Julio Cesar C Neto]

> Pessoal, gostaria de extrair a real necessidade/aplicabilidade dos EJB's (Session e Entity's). Por favor me corrijam onde minha >an�lise da tecnologia for insuficiente.  >   Quando se prop�s a utilizar uma tecnologia distribu�da (Cluster), as principais necessidades eram balanceamento de carga e >oler�ncia a falhas. No caso dos Session Fa�ades, utilizados em larga escala, podemos ter um efeito de balanceamento de carga >emelhante simplesmente utilizando tomcat + apache (que se encarrega de encaminhar cada sess�o ao servidor competente) com >frameworks tipo Struts + Hibernate e n�o precisamos utilizar SessionBean's nem EntityBean's. Conseguimos ent�o o >balanceamento de carga (de sess�es).   Algumas defini��es antes: “ ���������� �Load sharing is different to load balancing – the load is distributed arbitrarily without any feedback from the �������������� components in use.� (*** � o seu caso ***) ��������������� ���������� Ex: DNS Round-Robin - setup multiple alias records for a host ( �--- � o que vc quer fazer…) DNS MX records - MX allows multiple mail hosts to be set Web server redirect - setup a redirect from www to www1/www2 using JSP/servlets/_javascript_ ����������� ����������� Load Partitioning Clients are sent to particular servers based on their state – e.g. if (userNum < 10,000) go to server 1. Yahoo/Hotmail use this technique for webmail - us.f206.mail.yahoo.com Cons: doesn’t distribute load, users locked to one server.   Load balancing & fault tolerance. Load balancing uses a family of algorithms (e.g. allocate 60% to server 1 and 40% server 2) and feedback from the components (e.g. if a server is down it’s removed from the valid servers list) to intelligently distribute load and assist with fault tolerance. It can be made via Hardware or Software.”   Dito isso, a solu��o que voc� est� propondo � o 1o caso: Load Sharing (Compartilhamento de carga), e n�o load Balancing.� O problema com ele , como mencionado acima, � que se uma maquina do cluster cair(Jboss, e n�o o tomcat),a maquina que est� distribuindo (nesse caso, o apache) n�o vai saber que ela caiu, ali�s pode at� saber, mas os dados que aquela maquina estava processando(dados da sess�o) o apache n�o os matem.   � ai onde entra as solu��es de outras empresas: replica��o da sess�o, ou seja, se uma maquina cair, outra maquina pode assumir o lugar dele sem que o cliente perceba (Note que replica��o de sess�o pode ser implementada de diversas formas: uma maquina respons�vel por manter todos os dados da sess�o de todas maquinas ativas; ou todas as maquinas mantendo o estado da sess�o das outras no disco de cada uma) etc, etc...   Para uma boa e detalhada explica��o da nomenclatura e tipos de arquiteturas utilizadas: “J2EE Clustering” http://www.javaworld.com/jw-02-2001/jw-0223-extremescale.html http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-extremescale2.html         1 - Qual � a efici�ncia desta solu��o em compara��o com os EJB's? Depende das exig�ncias do seu site: O site mant�m muitas sess�es? Se sim, preciso mant�-las (recuper�-las) caso ocorra alguma falha em alguma servidor?� Com a solu��o acima voc� n�o teria como fazer isso.       2 - Na arquitetura com EJB's cada membro do cluster acessa o SGBD  e mant�m os outros membros sincronizados para realizar a toler�ncia a falhas. O qu� que � sincronizado: os SessionBeans, EntityBeans ou os dois?. Depende do servidor, pois isso n�o � exigido na especifica��o 2.0. O que � exigido � que os Entity Beans sobrevivam a crashs no servidor, enquanto que com Sessions beans isso n�o � exigido. Por exemplo, pela especifica��o os Stateful Session Beans n�o contemplam em seu ciclo de vida um pool, mas alguns servidores(acho que a maioria) mant�m um pool de Stateful Session Beans.       3 - Como � feita a configura��o dos DataSources para realizar a toler�ncia a falhas? Devem ser todos configurados para uma inst�ncia de um SGBD que est� em uma m�quina dedicada ou cada membro deve apontar para inst�ncias pr�prias de SGBD's? Qual das duas solu��es � a correta?   De novo, isso � com voc�. A especifica��o n�o contempla isso. Voc� decide que arquitetura o seu SGBD(ou cluster deles) vai utilizar e como ele vai interagir com o seu container(ou cluster deles).       4 - Se eu estiver criando/alterando/removendo um CMP atrav�s de seus respectivos m�todos como � que esse bean vai ser replicado nas outras m�quinas do Cluster? O servidor em quest�o atualiza os outros servidores chamando que m�todos?   Depende do servidor. BEA Weblogic, Oracle 9ias, iplanet suportam, mas a especifica��o n�o exige isso. Cada servidor implementa replica��o da sua forma. ( Por isso existem JSRs para padronizar como isso � feito)       5 - Se desejarmos a toler�ncia a falhas, al�m do balanceamento de carga, podemos usar o JBoss apenas com os m�dulos web e clustering sem os demais m�dulos o que em �ltima an�lise resultaria em um servidor web mais parrudo. O que acham dessa afirmativa? Como assim sem os outros m�dulos? Sem os m�dulos de transa��o?  De Mensagens? Ai voc� n�o teria um container J2EE... A sua solu��o seria equivalente a usar Apache + Tomcat, que seria melhor que usar o jboss, pq o apache faz um servi�o melhor que o jboss...       Julio Cesar