O protocolo classificado sob este item não apresenta um mecanismo de coordenação para as transações entre agrupamentos. As transações intra agrupamentos acontecem com a utilização de um mecanismo de coordenação.
4.4.1 Estrutura de agentes segundo PITOURA & BHARGAVA (1995)
Nesta proposta, os autores abordam a utilização de agentes para sugerir uma estrutura que forneça suporte a recuperação de falhas em ambientes móveis. O problema principal a ser tratado é a adequação das propriedades ACID para um ambiente de banco de dados móvel. A utilização de agentes permite uma maior independência das unidades e menor tráfego de mensagens na rede. Segundo os autores, um agente é, basicamente, um objeto que encapsula dados e procedimentos a serem executados pela unidade receptora do agente. A execução de um agente ocorre através da execução dos seus procedimentos sobre os seus dados. Ao invés de contar com o tráfego de mensagens, a rede irá carregar os agentes para o seu destino final.
Cada sistema de banco de dados envolvido no ambiente, apresenta um conjunto de operações denominadas primitive database methods. O relacionamento das aplicações é possível através da utilização de application agents. Um application agent só poderá acessar os itens de dados através da utilização dos primitive database methods. A coordenação do acesso aos dados é responsabilidade dos database agents, que ainda agem nos processos de consistência dos sistemas de banco de dados e recuperação de falhas. A comunicação entre os agentes de aplicação é possível pela solicitação de métodos de acesso aos dados mantidos em outros agentes. Segundo os autores, estas operações são selecionadas de um conjunto pré-definido de primitive methods chamado de primitive application methods. No estudo, duas definições para agentes e métodos são apresentadas pelos autores, estas definições são descritas abaixo:
• Agente: um agente é um objeto (D, M, SD, P), onde D é um conjunto de dados locais, M é um conjunto de métodos, SD é um conjunto de dependências estruturais entre métodos e P um conjunto de pontos de quebra e realocação.
• Método: os autores definem método em três possibilidades, (i) uma primitiva de banco de dados ou método de aplicação que acessa dados de um banco de dados ou outro agente, (ii) um método local que acessa os dados locais do agente, (iii) uma combinação de métodos e primitivas locais.
Os agentes de aplicação são constituídos de um conjunto de métodos e um determinado número de fluxos de controle. O fluxo de controle de um determinado agente determina a ordem de execução dos métodos do agente, esta ordem de execução é baseada em uma estrutura determinada dependência estrutural. A cooperação entre os agentes é uma característica do ambiente, os breakpoints definem os pontos de interação entre os agentes, já os relocation points definem o ambiente de execução do agente. A seguir serão apresentadas as definições de dependência estrutural, breakpoint e relocation points conforme a proposta dos autores:
• Dependência estrutural: a dependência estrutural é uma tripla (C, M, S), onde C é uma especificação, M é um conjunto de métodos e S é um conjunto de estados controláveis do conjunto de métodos M. Para uma primitiva M, um estado controlável em S poder ser commit, abort, prepare-to-commit ou submit.
• Breakpoint: um breakpoint de um agente A é uma tripla (Bs, Be, {(Ai, Mj)}) onde {(Ai, Mj)} é um conjunto de pares de métodos e agentes. Bs e Be são estados controláveis de métodos em A que permitem membros de {(Ai, Mj)} serem executados entre os estados Bs e Be de A.
• Relocation point: um relocation point de um determinado agente A é uma tripla (Bs, Be, (A’, B’s)) onde Bs e Be são estados controláveis de métodos em A. A’ identifica um segundo agente, B’s é um estado controlável de um método em A’ e determina que a parte de A entre os estados Bs e Be é executada como parte de A’ após B’s.
No estudo, os autores definem a informação que necessita ser recuperada após uma falha como context. No context estarão englobados também, os dados locais do agente e o seu estado de processamento. As informações relativas a cada agente estarão armazenadas em um banco de dados chamado de context database. Os autores assumem que o banco de dados context será armazenado em um local estável e livre de falhas.
As atualizações nas informações do banco de dados context não serão sobrescritas. A proposta é manter registros correspondentes às várias versões de atualização da informação. Desta forma, o último valor escrito para um determinado item de dados através de um método que já foi confirmado (commit), será reconhecido como o último valor confirmado (committed) para aquele item de dados. Um estado confirmado do banco de dados context com relação a uma determinada execução é o estado no qual cada item de dados apresenta o seu último valor confirmado.
Segundo os autores, quando uma falha de um determinado site ocorrer depois que um método foi executado com sucesso, mas antes dos seus resultados terem sido tornados permanentes, o método em questão será desfeito (undo). No decorrer do processo o método poderá ser executado novamente ou considerado abortado. As falhas decorrentes da execução de um agente cooperado serão manuseadas utilizando o context local do agente, neste caso um estado confirmado do banco de dados context será restaurado. Nas falhas de comunicação, quando um agente é perdido, ele será reconstruído utilizando o seu respectivo contexto. Segundo os próprios autores, nesta proposta não existe a possibilidade da aplicação da propriedade de atomicidade na sua totalidade. Isto decorre do fato de que vários agentes podem tomar decisões independentes com relação à confirmação ou aborto de um determinado método submetido por um agente de aplicação.
4.5 Análise comparativa entre as propostas de protocolos para recuperação de