Apache Tribes, um módulo do Tomcat 6, suporta comunicação de grupos no servidor cluster. Filip Hanik falou sobre os desafios em clusters heterogêneos e como Tribes ajuda com requisitos de comunicação de grupos do Tomcat clusters. Ele fez uma apresentação na conferência SpringOne Americas sobre o framework de messaging Tribes.
Filip iniciou a apresentação dizendo que existem diversos projetos open source para comunicação de grupos incluindo Appia, Spread, Erlang e JGroups. Ele falou sobre o modelo de grupo uniforme onde todos nós em um cluster são idênticos e eles processam, enviam e recebem mensagem da mesma maneira. Muitos módulos de comunicação de grupo são construídos para um modelo de comunicação uniforme. Mas na maioria das implementações de clusters heterogêneos isto frequentemente não é a melhor solução para alcançar a performance e a escalabilidade que é necessário no cluster.
Um modelo de comunicação de grupo não uniforme é a melhor solução quando os processos em cada nó do cluster são dinâmicas e estão em execução em ambiente hardware heterogêneo. As mensagens são enviadas com diferentes prioridades e níveis de garantia.
Tribes é um framework de messaging com capacidades de comunicação de grupo que foi criado a partir do código de replicação do cluster/session do Tomcat 5. É o framework de comunicação para implementação de cluster do Tomcat. Um de seus objetivos é simplificar a comunicação peer-to-peer e peer-to-group para aplicações distribuídas. Tribes suporta dois tipos de entrega de mensagem, uma entrega de mensagem concorrente que pode ser usado até mesmo entre dois nós e uma entrega paralela que pode ser usada para enviar mensagens para nós múltiplos.
Outas características no Tribes framework são:
- Entrega de Mensagem Garantida: A implementação default é baseada em TCP e usa pacotes java.io e java.nio.
- Níveis de Garantia: Tribes suporta 3 níveis de garantia de entrega da mensagem (NO_ACK, ACK, and SYNC_ACK).
- Per message delivery semantics: Esta semântica permite que cada mensagem seja entregue de maneira diferente bem como usar um nível diferente de garantia por mensagem.
- Interceptores Plugáveis: Este pode ser usado para interceptar qualquer evento através de métodos definidos e reagir em atributos de mensagem (flags). A classe ChannelInterceptorBase pode ser usada para minimizar o código redundante para métodos não interceptados.
- Entrega de Feedback: Tribes visa entregar feedback para cada mensagem e cada semântica de entrega (NO_ACK, ACK, SYNC_ACK). Entrega de mensagem pode ser síncrona ou assíncrona.
- Entrega Concorrente & Paralela: Entrega Concorrente é mais do que uma mensagem que pode ser enviada ou recebida em qualquer momento. Não existe "message blocking" significando que uma mensagem de 10 MB com nível de garantia SYNC_ACK não vai parar um nível de garantia NO_ACK de 10 KB. Entrega Paralela permite enviar uma mensagem para vários destinos em paralelo usando uma thread (NIO).
- Fixed Node Hierarchy: Esta funcionalidade suporta a habilidade para determinar o determine cluster leadership, grupos auto merge, e a descoberta de nó onde multicast pode não funcionar.
- Detecção de falha: Este inclui um interceptor simples TcpFailureDetector para fornecer feedback quando um membro do cluster cai. Não há necessidade de esperar por timeout e sem riscos de pings de nós ficarem presos em uma rede ocupada.
Tribes também suporta funcionalidades como mensagem RPC e um Canal JNDI para ligar um canal em um JNDI tree. A arquitetura do framework inclui os seguintes componentes:
- Canal: Este é o primeiro interceptor na cadeia. Contém uma lista de um ou mais ChannelListeners e MembershipListeners. Ele serializa e deserializa mensagens e suporta ByteMessage para transferênca de pure byte[] data.
- Interceptors: Alguns exemplos de interceptors são failure detection/static membership, por ordem total ou por ordem do membro, leadership election/message data encryption, message dispatch (mensagens assíncronas) e todas ou nenhuma garantia de entrega.
- Coordenador: Este é o último interceptor na cadeia. Ele coordena componentes I/O tais como Sender, Receiver e Membership.
Na apresentação, Filip também demonstrou uma aplicação de exemplo mostrando como habilitar clustering no Tomcat e as opções de configuração para habilitar um webapp para replicação de sessão e contexto. O arquivo server.xml inclui a configuração para elementos cluster como Cluster, Session Manager (DeltaManager ou BackupManager), Channel (Tribes), Membership (suporta duas formas de membership: Dynamic membership que usa multicasting para descobrir outros nós em tempo real e Static membership onde definimos cada nó no server.xml), Messaging (acontece no TCP; cada nó tem um receiver e um sender), Receiver (recebe mensagens de clusters), Sender (envia mensagens de cluster), Interceptors (semelhante a valves em termos de funcionalidade), Valves (iniciam a replicação da sessão no final de cada request), e ClusterListener (suporta custom messaging listeners para certos tipos de mensagens).