Service Integration BUS (SIBus)

Conceito básico

Service Integration BUS (SIBus): Foi incluído ao Websphere, a partir da versão 6, como provedor padrão de mensagens JMS. Que é nada mais é do que a implementação de um Servidor de mensagens JMS. No entanto ele também implementa um Message Driven Bean (MDB) e tem capacidades de alta disponibilidade e escalonamento, bem como controle e distribuição de carga (Workload Management) e QoS (Quality Of Service). Atendentendo à especificação Java para troca de mensagens (JMS - Java Message Service).

Java Message Service (JMS): é a especificação JAVA para troca confiável de mensagens, permitindo que aplicações sejam capazes de trocar mensagens de forma rápida e segura. Uma de suas principais características é a padronização, desta forma qualquer programa, feito em qualquer linguagem, que obedeça o padrão da especificação Java para troca de mensagens pode trocar mensagens.

Message Driven Bean (MDB): É a forma que os EJBs (Enterprise Java Bean) utilizam para trocar mensagens entre si. Ao invés de efetuarem chamadas diretas, eles enviam mensagens de forma assíncrona. Quando uma mensagem chega ou é enviada eventos são gerados que são monitorados e podem disparar a execução de alguma rotina. Ele não participa de transações e não mantém estado (stateless).

Provider (Procedor)

Como o nome sugere é o método utilizado para prover mensagens para um sistema. É nele que definimos se vamos armazenar as mensagens em disco ou em banco de dados. Este sistema de mensagem é relativamente simples de entender. Um cliente JMS, programa que envia mensagem, se conecta com o provedor de mensagem (pode ser uma rotina interna ou externa), através de um Connection Factory, escreve a mensagem e envia ao JMS Server (no Websphere é chamado de Message Engine). A mensagem tem um endereço, que é uma fila, então o Message Engine envia a mensagem para uma fila no destino (Destinations), que acaba sendo persistida em um disco ou banco de dados. Esta é uma visão funcional, separando as partes para maior compreenção:

Figura 1

Para receber uma mensagem, basta um cliente JMS requisitar uma conexão ao Connection Factory, passando a ele qual o destino que deseja ler (normalmente o destino é requisitado por um JNDI); a Message Engine irá buscar a mensagem no Destination (recipiente) e enviará ao requisitante através do mesmo Connection Factory.

Separação no Console

Uma dúvida muito comum é confundir a fila com o destino. De uma forma simples, é a Message Engine quem executa todas as atividades, então não seria errado refazer o desenho incluindo todos os itens dentro dela. Na figura abaixo é uma representação que se aproxima da forma em que os objetos serão executados (podemos ver a esqueda o local no Websphere, onde podemos configurar cada item):

Figura 2

A fila que é configurada em (Resources > JMS > Queues) é apenas uma configuração, que irá determinar o seu comportamento e o seu JNDI. Para o desenvolvedor o que importa é o JNDI, pois é através dele que a fila será localizada e utilizada no sistema. Ou seja, configuramos apenas a parte lógica, destinada a usabilidade da fila/tópico, mas ainda não indicamos onde a mensagem em sim ficará.

Quando uma mensagem é recebida, deverá ficar, efetivamente, em um destino (um recipiente), para que possa ser armazenada ao ser recebida e posteriormente processada. Na prática, uma fila utiliza um Destination (recipiente) para armazenar as suas mensagens, veja que a "Fila 1" e o "Tópico 1" armazenam suas mensagens em seus respectivos recipientes (note que é um-para-um). Esta é a situação mais comum de se encontrar em qualquer ambiente em funcionamento.

Outra situação menos comum, mas também bem utilizada e a capacidade de utilizar várias filas armazenando num mesmo Destination (recipiente). Na figura acima temos a "Fila 2" e "Fila 3" armazenando no mesmo recipiente (Destination). Não é possível uma fila enviar mensagens para dois recipientes; isto só é possível para tópicos.

Em resumo: Filas/Tópicos se referem à parte lógica da configuração, entre elas o JNDI que é utilizado pelo desenvolvedor. Destination é a configuração do recipiente que irá receber as mensagens em si.

BUS

Embora a configuração do SIBus seja bem complexa, podemos citar quatro principais itens:

1. Membro (bus member): indica qual ou quais recursos (JVM ou Cluster) irão executar eventos relativos às mensagens;

2. Message Engine (ME): Instância que de um membro, recurso JAVA que irá processar nossas mensagens;

• Cada instância tem sua própria memória e controla seu próprio estado;

3. Destinos (Destinations): é o recipiente lógico que irá canalizar as mensagens, é de/para ele que enviamos ou recebemos mensagens;

• Pode ser do tipo Fila (Queue) ou Tópico (Topic);

4. Armazenamento (Message Store): local físico onde as mensagens serão armazenadas;

• Podemos escolher uma pasta no disco ou um banco de dados;
• Este item é definido na criação de um provider.

Este é um exemplo de um SIBus com um servidor (JVM) como membro. Podemos ver uma aplicação rodando dentro de uma JVM, acessando a ME, que é o recurso que irá processar a mensagem, enviando para um destino, que irá realizar a sua persistência, seja em disco ou banco de dados. Este mensagem ira dispara eventos em um MDB, que podem ser ou não tratadas por alguma aplicação:

Figura 3

Na figura acima o Destination não aparece, para não poluir a imagem, mas estaria dentro do ME, como mostrado na figura 2.

Porque um SIBus?

O SIBus é um conjunto de configuração que, sozinhas, não realizam nada. Para que estas configurações entrem em ação, necessitam de um membro, que é capaz de executar o que foi configurado. Os membros podem ser removidos e adicionados, dando escalabilidade. Assim podemos:

• Alta dispobibilidade
  • Tem a capacidade de manter um BUS em um cluster;
  • Dependendo do recursos disponíveis e a criticidade das atividades, pomos replicar a engine em vários integrantes do cluster ou não;
  • Mensagens podem são persistidas, em caso de travamento, basta reiniciar o sistema;
• Escalabilidade
  • Permite que sejam criados novos servidores (JVMs) em novos hardwares e estender o ambiente com novos membros;
• Utilização inteligente de recursos
  • O sistema aceita QoS, com priorização de mensagens e/ou recursos;
  • Controle de carga, onde as mensagens não irão consumir mais recursos que as aplicações que as processam;

Este é um recurso que o Websphere apresenta como um poderoso instrumento de mensageria, que vem como Provedor Padrão (Default Provider) e só consumirá recursos se configurado, pois por padrão não vem configurado.