Comunicação Síncrona

É uma forma de integrar aplicações, na qual a aplicação que cria e envia uma mensagem fica esperando uma confirmação de que o(s) cliente(s)

recebeu(ram) a mesma para continuar sua rotina de execução. Essa forma é muito utilizada por sistemas convencionais de comunicação (IBRAHIM, 2012).

Tem sua principal vantagem no fato de que toda operação finalizada deve ter sido realizada completamente. Por exemplo, quando todas as aplicações envolvidas no processo são pertencentes a uma mesma empresa.

Sua desvantagem, em alguns cenários, é que algumas aplicações não podem esperar que suas mensagens sejam recebidas por seus clientes. Por exemplo, um e-commerce não poderá ficar parado esperando confirmar um pagamento de cartão de crédito, impedindo que o cliente possa efetuar outras operações.

2.5.2 Comunicação Assíncrona

Com mensagem assíncrona o baixo acoplamento é mais evidente, pelo fato de que uma aplicação ao criar e enviar uma mensagem não precisa esperar confirmação que essa foi consumida pelo(s) cliente(s).

Em ambientes corporativos, nos quais várias aplicações, criadas por diferentes empresas, consumirão mensagens simultaneamente, essa forma se mostra a mais indicada por facilitar a integração de novas aplicações de forma dinâmica, sem a necessidade de refazer as já integradas.

Mesmo sendo indicada, se tratando de serviços prestados nos quais para o prestador é importante se certificar do recebimento da mensagem pelo destinatário, essa forma de comunicação demanda um trabalho maior na concepção dos aplicativos, pelo fato de ser necessário criar outras formas de confirmar o recebimento das mensagens.

2.5.3 Domínio point-to-point

Domínio point-to-point (PTP) tem a característica de trabalhar com filas (queues) de mensagens (SUN, 2002). Nele, mensagens são criadas pela aplicação e enviadas para uma fila no gerenciador de mensagens, depois entregues, por esse, ao destinatário.

Uma questão a ser levada em consideração nesse domínio é o fato de que uma mensagem é entregue a uma fila específica (queue) e que essa fila só tem um destinatário, desta forma não é possível usar esse domínio quando se pretende compartilhar as mensagens com mais de um destinatário.

Portanto, o emprego desse domínio é interessante quando as mensagens a serem criadas têm um destinatário único, geralmente gerenciado pela mesma empresa. Por exemplo, uma empresa e sua filial que pretendem se comunicar por meio de mensagens. Dessa forma fica mais fácil ter certeza que apenas a filial está tendo acesso às mensagens enviadas.

2.5.4 Domínio publish-subscribe

No Domínio publish-subscribe (Pub/Sub) produtores de mensagens as publicam para um tópico específico, ao qual assinantes se conectam para retirar essas mensagens.

Trata-se de um sistema de compartilhamento abrangente, no qual uma mensagem pode ser entregue a um número indefinido de destinatários, sendo eficaz quando se pretende divulgar as mensagens sem saber exatamente quem as receberá.

Nesse domínio é mais conveniente ser usada comunicação assíncrona, pois a espera por respostas dependeria de todos os destinatários envolvidos, o que

aumentaria a espera à medida que novos destinatários se inscrevessem nos tópicos.

A configuração do domínio deve ser executada no servidor Glassfish, isto pode ser feito utilizando a interface web ou via código de deploy do Middleware produtor. Para que um cliente possa se inscrever e receber mensagens point-to- point ou publishe/subscribe, as configurações precisam ter sido realizadas anteriormente.

2.6 Trabalhos Relacionados

Sistemas de banco de dados distribuídos é um tema recorrente, sendo abordado em diferentes livros e artigos como em: Date (2004), Ray (2009), Ozsu e Valduriez (2011), dentre outros.

A consistência de dados em banco de dados em nuvem é um tema discretamente abordado na literatura cientifica (FREITAS, 2014). Mesmo assim é possível citar trabalhos que tratam do tema.

Os trabalhos expostos têm relevantes contribuições sobre o tema proposto por esta pesquisa, sendo analisados de acordo com sua proposta de solução para o problema da manutenção da consistência de dados em banco de dados distribuídos e foram selecionados por proporem suas soluções baseadas numa hierarquia entre as réplicas do banco de dados.

Em WANG (2010), o autor defende a divisão da estratégia da consistência em quatro categorias: da consistência forte à fraca além de combinações dessas de acordo com a frequência de leitura e escrita. Ajustando assim o nível de consistência dos dados em tempo de execução, de acordo com métricas de leitura e escrita previamente determinadas.

Não há participação do usuário na escolha do nível de consistência com o qual os dados devem ser tratados. Desse modo, o conhecimento do usuário sobre

sua aplicação é ignorado na escolha do nível de consistência, tendo importância apenas no momento de definir as métricas de leitura e escrita.

A vantagem dessa abordagem é o ajuste, em tempo de execução, dos níveis de consistência dos dados, tornando isto transparente ao usuário, por outro lado, o ponto, fraco dessa abordagem é a definição das métricas necessárias para esse ajuste, que fica a cargo de um especialista nos dados.

Em FREITAS (2014), a autora propõe o uso de réplicas do banco de dados, das quais uma réplica denominada master fica encarregada de receber atualizações e criar uma mensagem incorporando as atualizações que serão enviadas ao servidor Glassfish. Este servidor que se encarrega de entregá-la a seus destinatários (réplicas) de forma assíncrona. Os destinatários são providos de aplicação JAVA criada conforme especificação JMS (SUN, 2002).

Para garantir um baixo tempo de resposta, é proposto o uso de uma consistência parcial dos dados por meio da seleção dos dados que devem ser atualizado imediatamente e dos que podem esperar uma janela de tempo para sua atualização.

A proposta é interessante e adequada a muitas aplicações. No entanto, a parcialidade de sua consistência é um ponto negativo, tendo em vista que algumas aplicações importantes no mercado não poderiam utilizar esse tipo de garantia de consistência.

Para ajustar sua proposta a um grupo maior de aplicações, pretende-se descentralizar as atualizações da réplica master, garantindo sua aplicação a todas as réplicas, sem uma ordem definida de prioridade. Será retirada do SGBD Oracle8 a responsabilidade de criar e enviar as mensagens ao GlassFish, sendo essa operação responsabilidade da aplicação. Assim, as réplicas, como clientes do sistema de mensagem, concorrem simultaneamente para aplicação das atualizações.

8

Contudo esse método não garante que num determinado momento as réplicas estarão num estado consistente, sendo possível, por alguns instantes uma desatualização entre elas, levando em consideração que algumas réplicas estarão mais distantes, fisicamente, do servidor Glassfish que as outras, gerando retardos na realização de atualizações nestas. Sendo assim é importante que esse retardo seja o menor possível, para não causar problemas aos usuários.

Outra característica deste trabalho é que cada tabela está associada a um tópico específico. Com esta abordagem cada transação terá de criar uma mensagem para cada tabela envolvida na mesma. Por exemplo, caso uma transação envolva atualização em quatro tabelas, esta transação terá de criar e enviar quatro mensagens que serão administradas pelo servidor e entregues aos destinatários, isso geraria um fluxo maior de mensagens sendo trafegadas na rede.

Em seu trabalho ZHAO (2012) afirma que replicação de dados é uma estratégia para alcançar disponibilidade, escalabilidade e melhoria de desempenho no gerenciamento de dados. Segundo o autor existem duas arquiteturas, comumente usadas, de replicação de dados em nuvem, a arquitetura

master-slave (mestre-escravo) e a multi-master (multi-mestre).

A arquitetura multi-master permite que cada réplica mantenha uma cópia completa do banco para servir a transações de leitura e escrita. Conflitos de escrita são resolvidos pelo Middleware de replicação. Por outro lado, a replicação

master-slave melhora o rendimento de leitura. Nessa arquitetura, transações de

leitura são servidas pelas réplicas slaves e transações de escrita pela master. O

Middleware fica encarregado de repassar às réplicas slaves as transações de

escrita executadas na réplica master, desta forma conflitos de gravação são resolvidos no lado master.

Seu estudo se concentrou na arquitetura master-slave, por ser a mais empregada por muitas aplicações web, apresentando um framework para a

replicação dos dados o qual deve considerar um SLA de atualidade dos dados para cada réplica.

O SLA (Service Level Agreement - Acordo de Nível de Serviço) trata-se de um contrato especificando regras a serem cumpridas por partes envolvidas num contrato. No contexto de sua pesquisa o SLA define o atraso aceitável de atualizações das réplicas do bando de dados.

O framework dispõe de três módulos: monitor, controle e ação. O primeiro monitora o atraso na atualização de cada réplica (diferença entre os timestamp de atualização no master e na réplica), o segundo, deve comparar os atrasos à SLA e disparar um comportamento do modulo de ação (terceiro).

O modelo trata apenas da atualização dos dados, não garantindo consistência, sendo esta indefinida se forte ou fraca. Ademais a definição do SLA pode ser bastante custosa, já que fica por conta do usuário definí-la.

A arquitetura de replicação master/slave adotada apresenta um risco considerável à disponibilidade pelo fato de que se a réplica master estiver indisponível não será possível realizar transações de escrita, uma vez que o

middleware responsável não pode executar escrita diretamente nas réplicas slaves. Isso faz com que uma partição na rede no host da réplica master torne

indisponível, pelo menos para escrita, todo o banco de dados.

A proposta deste trabalho é usar a arquitetura multi-master, com escrita realizada por meio de envio de mensagens, usando um sistema de mensageria criado em Java, o qual enviará uma mensagem contendo a escrita para um servidor Glassfish, que repassará a mensagem às réplicas que de fato executarão a operação de escrita em suas respectivas cópias do banco de dados.

Uma vez adotada a arquitetura multi-master, o banco de dados estará disponível para leitura e escrita mesmo que uma ou mais réplicas sofram uma partição de rede, contanto que ao menos uma réplica continue ativa.

O Quadro 2.2 faz uma comparação dos trabalhos relacionados, levando em consideração o método, o tipo de consistência e a participação do usuário na definição das métricas.

Quadro 2.2 – Comparação dos trabalhos relacionados

Autor Método Consistência Interferên cia do Usuário Vantagem Desvantagem Wang. Al 2010 Seleção de nível de consistência em tempo de execução. Quatro categorias são definidas: da consistência forte a fraca além de combinações delas, de acordo com a frequência de leitura e escrita.

Indefinida Usuário não define a consistência , porém define as métricas para os ajustes em tempo de execução

Ajuste dos níveis de consistência em tempo de execução, tornando essa operação transparente para o usuário. A Definição das métricas necessárias para os ajustes dos níveis requer um especialista no negócio.

Freitas et. Al 2014

Réplica os dados em réplicas hierarquicas, propagando atualizações da réplica

master às slaves mesclando

atualização ansiosa e preguiçosa de acordo com requisitos de negócios. Requer interferência de um especialista nos dados para definir quais dados devem ser mantidos consistentes em tempo de execução e quais podem estar em um estado inconsistente por um intervalo de tempo arbitrário. Fraca Usuário interfere na seleção dos dados que requerem consistência forte Uso de sistema de mensageria para propagar as atualizações entre as réplicas do banco de dados. A centralização das operações de atualizações em uma réplica master.

Zhao et. Al 2012

Uso de um framework que deve equilibrar a carga de usos das réplicas afim de garantir latência reduzida no consumo do SGBD. O mesmo requer participação de usuário para definir SLA que deve ser consultada para verificar se as atualizações estão dentro do esperado.

Indefinida Usuário interfere definindo o SLA

Definição de uma SLA para avaliar se uma réplica deve ser desativadas caso ultrapasse um detrinado tempo para ser atualizada. A centralização das operações de atualizações em uma réplica master.

2.7 Conclusões do Capítulo

Este capítulo contribuiu para a dissertação apresentando uma revisão da literatura, fundamentando, assim, este trabalho. Foram abordados os temas de Banco de Dados distribuídos, Consistência de Dados considerando o teorema CAP, PACELC e tipos de consistência de dados, além desses temas foi abordado o paradigma de Middleware Orientado a Mensagens.

A revisão da literatura destacou a relevância do tema desta pesquisa e mostrou como os autores o abordaram. Mostrou ainda a necessidade de desenvolver novos métodos para prover a manutenção da consistência dos dados distribuídos, deixando de simplesmente ignorá-la.

O próximo capitulo apresenta o modelo proposto para manutenção de consistência de dados relacionais distribuídos, detalhando seus componentes, funcionalidades e arquitetura.

3 MODELO PARA MANUTENÇÃO DE CONSISTÊNCIA DE