TRANSAÇÕES EM SISTEMAS DISTRIBUÍDOS E ABERTOS
Autores: Marcelo Postel Lang - CEFET
Manoel Camillo de Oliveira Penna Neto - CEFET
Este trabalho aborda o conceito de transações em sistemas distribuídos. É feita uma revisão geral das técnicas utilizadas para realização deste mecanismo, e o estudo de dois modelos para atividades atômicas: o modelo de ações atômicas do projeto ANSA e o modelo e transações para processamento distribuído aberto .
1 Introdução
Com a descentralização do processamento surgiu a necessidade de implementar técnicas que garantissem a integridade das informações processadas neste novo ambiente. Uma das técnicas que possui esta característica é a transação, baseada no conceito de ação atômica. Esta técnica permite o encapsulamento de um conjunto de operações quando da sua execução de tal forma que, se o processamento ocorrer sem a presença de falhas, garante-se que todas as operações foram executadas. Caso ocorra uma falha na execução de qualquer uma das operações do conjunto, garante-se que qualquer resultado obtido por este conjunto será ignorado, voltando o processamento ao estado anterior ao da execução da transação.
Esta característica de execução ou não de um determinado conjunto de operações é que garante a integridade das informações processadas, não importando a localização tanto do ponto de processamento como das informações acessadas (arquivos).
Este trabalho repassa o conceito de transações e suas características e apresenta o modelo de processamento atômico proposto pelo projeto Advanced Networked Systems Architecture (ANSA) [1], que se preocupa com a integridade dos objetos distribuídos no sistema. O trabalho também aborda a normalização ISO/CCITT que trata do processamento aberto distribuído (Open Distributed Processing - ODP) [2] [3] [4] [5] [6] que normaliza os conceitos necessários para processamento aberto distribuído, utilizando-se intensamente do conceito de transações como instrumento de garantia de integridade dos sistemas distribuídos. Por fim, é verificada a importância da utilização do conceito de objetos e a importância, das interfaces destes objetos para atingir a transparência necessária ao processamento distribuído aberto.
Na seção 2 serão abordados os conceitos básicos relacionados às transações. Na seção 3 será estudado o modelo ANSA para atividades atômicas. Na seção 4 será abordado o modelo de transações ODP. Para finalizar, na seção 5 serão feitas as considerações finais do trabalho e apresentadas algumas propostas de trabalhos futuros.
2 Transações
As transações surgiram na teoria de bancos de dados. São uma forma de permitir alterações de forma segura em bases de dados, distribuídas ou não, garantindo a integridade das informações tratadas, sem a necessidade de controle explícito detalhado a nível de programação [7].
Uma transação é um conjunto de operações delimitadas por cláusulas do tipo Begin Transaction e End Transaction, sendo que os resultados obtidos - parciais ou finais - das operações delimitadas ou são efetivados como um todo ou nada é efetivado.
2.1 Propriedades das Transações
Para garantir o conceito das transações, foram especificadas quatro propriedades que definem suas características [8]: atomicidade, consistência, independência e durabilidade (propriedades ACID). Estas propriedades aplicadas em conjunto garantem a integridade e consistência das informações tratadas pelas transações. As quatro propriedades estão descritas a seguir.
2.1.1 Atomicidade
Esta propriedade determina que todas as operações delimitadas na transação ou executam ou nenhuma delas executa. Desta forma, vê-se a transação como uma ação única. Se uma transação executa até o seu final, os resultados obtidos serão efetivados; caso contrário, nenhum resultado obtido dentro da transação até o instante da ocorrência da falha será efetivado.
2.1.2 Consistência
Esta propriedade determina que os resultados obtidos por uma transação são consistentes no que diz respeito à concorrência entre transações. Ou seja, mesmo no caso do processamento concorrente de várias
transações, o resultado será o mesmo que seria obtido, caso estas várias transações tossem executadas de forma seqüencial.
2.1.3 Independência
Esta propriedade prevê que os resultados obtidos por uma transação somente serão utilizados por esta mesma transação, até o encerramento e efetivação destes resultados, sendo então disponibilizados para uso externo à transação em questão (apenas no caso de efetivação).
2.1.4 Durabilidade
Esta propriedade garante que os resultados obtidos por uma transação serão efetivados e não serão perdidos, salvo em caso de catástrofes com inundações ou terremotos.
2.2 Manutenção de Concorrência e Controle de Deadlocks
Como sistemas computacionais podem executar vários processos de forma concorrente, existe a possibilidade de concorrência entre transações e, ainda, a concorrência no acesso à base de dados por estas transações. Para evitar problemas como conflitos, é necessário um controle seguro de acesso a objetos por parte das transações para permitir a perfeita concorrência de processamento entre estas transações ou, no caso da ocorrência de deadlocks, a detecção destes casos e a devida solução.
Para solucionar estes casos, existem várias técnicas que permitem evitar ou contornar casos de conflitos. As técnicas mais comuns são two-phase locking e optimistic locking. Na primeira, cada transação possui duas fases no que tange a acesso a objetos. A primeira fase é aquela na qual a transação obtém o bloqueio de todos os objetos que serão utilizados no seu processamento. Na segunda fase, existe o processamento e a efetivação dos resultados com o conseqüente desbIoqueio dos objetos usados. Esta técnica garante que não irão ocorrer conflitos durante o processamento, já que a transação só irá prosseguir caso obtenha o controle dos objetos necessários. Com isto evita-se o problema de solucionar deadIocks, com a execução já parcialmente realizada por parte das transações.
No optimistic locking, assume-se que a ocorrência de conflitos será mínima, sendo portanto desprezado o controle de concorrência. Todas as alterações realizadas pela transação são armazenadas até o seu final, quando irão ser ou não processadas. Se forem permitidas as alterações - se outra transação não modificou o estado inicial dos objetos a serem alterados - a transação encerra normalmente. Caso contrário, a transação será abortada e seus resultados abandonados.
2.3 Efetivação de Transações
A parte mais crítica da transação é sem dúvida, o momento da efetivação dos resultados obtidos pelas suas operações. Para garantir a integridade das informações deve-se permitir que ou todos os resultados sejam efetivados ou, caso isto não seja possível, todos os resultados obtidos deverão ser desprezados. Para permitir esta característica, utiliza-se o algoritmo conhecido como Two-phase Commit [9].
Neste algoritmo, um nodo é o coordenador e os outros são os subordinados. O coordenador manda uma mensagem para cada subordinado, perguntando se estes estão aptos a comprometer a transação. Se pelo menos um dos nodos subordinados não concordar, a transação é abortada e seus resultados desprezados. Cada nodo concordante deverá gravar um registro em um log de processamento. Se todos os subordinados aceitarem o encerramento da transação, o nodo coordenador também grava esta informação em um log e então envia uma mensagem para cada subordinado para que os resultados sejam efetivados.
As gravações em log descritas acima são úteis na recuperação em caso de falhas, para ser conhecido o ponto onde estava o processamento quando ocorreu a falha e a atitude a ser tomada.
2.4 Transações Aninhadas
Para permitir um melhor controle no processamento de uma transação e permitir o processamento concorrente de várias partes de uma mesma transação, permite-se subdividir uma transação em várias subtransações, de tal forma que estas subtransações estejam vinculadas ao processamento da primeira.
Este vínculo está relacionado com as três propriedades das transações aninhadas, relacionadas abaixo:
(i) Uma transação atômica é efetivada com sucesso se, e somente se, a transação principal é efetivada e se todas as subtransações desta principal também forem efetivadas com sucesso.
(ii) O cancelamento de uma subtransação é notificado à transação principal sem cancelá-la para que esta possa decidir se deve prosseguir ou não.
(iii) O cancelamento de uma transação principal cancela todos os resultados obtidos por subtransações, mesmo que estas tenham supostamente sido efetivadas.
Deve-se ressaltar que, mesmo que uma subtransação tenha sido efetivada, os seus bloqueios são herdados pela principal até o seu encerramento.
2.5 Vantagens na Utilização de Transações
A utilização de transações em sistemas distribuídos abertos garante a integridade das informações tratadas, pelo simples fato de que a ocorrência de qualquer falha no processamento, ocorrida nos nodos envolvidos com este processamento, fará com que os resultados parciais obtidos sejam ignorados.
Isto permite com que a base de dados permaneça sempre num estado seguro e consistente.
Outra vantagem na utilização de transações em sistemas distribuídos abertos é a facilidade de programação, já que estes controles de concorrência e integridade de execução não necessitam ser feitos explicitamente no código de aplicação, a não ser pela determinação do início e fim destas transações.
Com todas estas facilidades surgiram algumas propostas de modelos para processamento atômico distribuído. Um destes modelos, o ANSA Atomic Activity Model é comentado na seção seguinte, considerando as principais características revistas até aqui, utilizadas na implementação de transações em sistemas distribuídos.
3 O Modelo ANSA
O modelo de transações ANSA [10] consiste na determinação de manipulação de objetos de forma a não perder a integridade das informações armazenadas, com processamento concorrente em sistemas computacionais distribuídos.
Para compreensão das propriedades e de sua infra-estrutura de controle deve-se entender alguns conceitos básicos e terminologias especificados no modelo computacional ANSA [1].
3.1 Conceitos Básicos
Um objeto computacional é o encapsulamento de um estado e as operações que manipulam este estado. O estado de um objeto é definido em termos de ligações, onde uma ligação é a associação entre um nome e uma interface. Uma operação é um conjunto de regras que permitem o acesso para consulta e/ou alteração do estado de um objeto. O conjunto completo de operações suportadas por um objeto determinam as transições possíveis de estado deste objeto.
A interface de um objeto são as operações possíveis em um objeto, caracterizadas por: nome da operação, número e tipo de argumentos, nomes das terminações possíveis resultantes da operação e o número e tipos dos resultados.
Uma atividade é a forma na qual a computação progride. No caso de uma atividade estar sendo executada em um cliente e este requisitar informações de um servidor, a atividade em questão passará do cliente para o servidor, e assim por diante se necessário. Desta forma está caracterizado um modelo cliente-servidor, genérico, no qual um objeto pode assumir a figura de um cliente ou de um servidor, ou ambas.
3.2 Propriedades ACID
O modelo conceitual de atividade atômica ANSA compreende o processamento que mantém e preserva a integridade de objetos distribuídos e seus estados mesmo na presença de falhas de software e hardware no sistema distribuído como um todo, incluindo, falhas de cliente, de servidor e/ou de comunicação.
A atividade atômica no modelo ANSA corresponde ao modelo clássico de transação, onde uma atividade atômica deve possuir as propriedades da atomicidade, consistência, independência e durabilidade.
Para que a atividade atômica possa executar com toda a segurança, deverão existir alguns controles fundamentais a serem realizados. Estes controles são definidos na infra-estrutura do modelo.
3.3 Infra-estrutura
Para ordenação da execução foi criado o conceito de Atomic Activity Tree, que determina a forma como uma atividade atômica, irá executar. Para explicar esta árvore de atividades atômicas, deve-se começar por uma atividade principal. Esta atividade pode acionar outras atividades das seguintes formas: através de um announcement, criando uma nova árvore de atividade atômica, com execução independente da primeira; ou através de um interrogation, onde cria-se uma nova atividade, cujo término permite a continuação do processamento da atividade principal.
A infra-estrutura genérica apresentada em [10] permite a execução concorrente de atividades atômicas,
definindo seis gerentes para este controle: atomic operation manager, timestamp manager, atomic activity
descriptors manager, concurrency control manager, version store manager, deadlock resolution manager. Nos itens a seguir serão comentadas as funções de cada um destes gerentes.
3.3.1 Atomic Operation Manager
Este módulo coordena a execução de atividades atômicas suportadas por um objeto atuando como servidor, de acordo com as propriedades ACID. Como complemento a este módulo, conceituou-se as partes inicial e final da atividade atômica como funções prelude e postIude. Estas funções complementares foram projetadas para interceptar requisições para - e respostas de - atividades atômicas. As funções prelude relacionam as requisições com as devidas atividades atômicas e criam o ambiente de execução da atividade atômica. As funções postIude tratam do perfeito encerramento deste processamento.
A função prelude recebe a invocação da atividade atômica e junto com o Atomic Operation Manager cria o ambiente para execução. Este ambiente inclui a identificação da atividade a ser iniciada com o uso do Timestamp Manager e de um descritor através do Atomic Activity Descriptor Manager.
A função postlude tem como objetivo encerrar a atividade atômica e entregar ou não os resultados ao cliente que a requisitou. Esta função também é responsável por retornar ao estado original, caso haja uma reversão - ou cancelamento - da atividade.
3.3.1.1 Reversão
Pode-se reverter uma atividade atômica por quatro motivos:
(i) encerrar a atividade voluntariamente;
(ii) encerrar a atividade a pedido da sua atividade principal, revertendo seus resultados;
(iii) encerrar a atividade devido a falha no nodo ou falhas de comunicação;
(iv) encerrar devido ao seu envolvimento em um caso de conflito.
Caso ocorra uma reversão, o Atomic Operation Manager requer à sua subatividade que reverta sua atividade, revertendo em seguida os seus próprios passos, retornando ao estado anterior ao início da execução da atividade.
3.3.1.2 Efetivação
Para efetivação de um atividade atômica utiliza-se o protocolo Two-phase Commit, que garante a efetivação de todas as subatividades envolvidas ou de nenhuma delas, como já foi descrito na seção 2.3.
3.3.2 Timestamp Manager
Este módulo retorna identificações baseadas no relógio do nodo ou do sistema em resposta a requisições feitas pelo Atomic Operation Manager. Estas identificações facilitam determinadas políticas de ordenação de eventos distribuídos para o controle de suas evoluções.
3.3.3 Atomic Actívity Descriptor Manager
Este módulo cria, manipula e remove descritores para atividades atômicas sobre a supervisão do Atomic Operation Manager. Estes descritores são usados para manter controle sobre a identidade e execução de atividades atômicas.
3.3.4 Concurrency Control Manager
Este módulo controla a separação de diferentes atividades atômicas. Este controle é dividido em duas fases distintas: separation phase e ordering phase. A primeira fase consiste na separação da execução de atividades atômicas que podem vir a interferir umas nas outras, para produzir uma seqüência serial de execução e controle. A segunda fase se preocupa em regular o acesso as bases de acordo com as necessidades de integridade de cada objeto atuando como servidor.
Tem-se potencialmente duas técnicas cujos algoritmos podem ser utilizados para controlar a concorrência de atividades atômicas: as técnicas baseadas em bloqueio, suscetíveis a ocorrência de conflitos; e a técnica baseada em identificação da atividade a partir da hora de requisição desta atividade, uma variação do Optimistic locking, onde caso haja a ocorrência de um conflito o algoritmo utilizado decide qual atividade irá reverter.
Se a ocorrência de conflitos não é freqüente, opta-se pela segunda técnica. Caso contrário, ocorrerão muitos casos de reversão e então a primeira técnica é mais recomendada.
3.3.5 Version Store Manager
Este módulo provê repositórios estáveis para armazenar o histórico das atividades atômicas e opera, juntamente com o Atomic Operation Manager, para recuperação de falhas e reversões da atividade.
3.3.6 Deadlock Resolution Manager
Este módulo em conjunto com o Concurrency Control Manager tenta evitar e/ou detectar e solucionar a ocorrência de deadlocks no sistema.
Este é um modelo para controle e processamento de atividades atômicas. A seguir será abordado o modelo de referência ODP, mais abrangente já que trata de processamento distribuído aberto, mas de interesse a este trabalho já que contém características de atomicidade para integridade dos objetos.
4 Modelo de Referência ODP
O Open Distribsded Processing (ODP) [2] [3] [4] [5] é um modelo de referência que descreve as características necessárias que um sistema de processamento distribuído necessita para ser aberto. Este modelo é descrito em quatro partes: visão geral do modelo, modelo descritivo, modelo prescritivo, e semântica da arquitetura com técnicas de especificação.
A visão geral descreve a motivação para o ODP apresentando o escopo, justificação e explanação de conceitos chave. O modelo descritivo contém a definição dos conceitos e a estrutura analítica para descrição normalizada de sistemas de processamento distribuído. O modelo prescritivo contém a especificação das características que qualificam o processamento distribuído como aberto. O quarto módulo contém a formalização dos modelos conceituais do ODP.
Para melhor compreensão do modelo como um todo, ele é dividido em cinco pontos de vista distintos: visão da empresa, visão da informação, visão da computação, visão da engenharia e visão da tecnologia.
O ponto de vista da empresa se preocupa com o ambiente onde um sistema ODP deve operar. Isto inclui como e onde este sistema se posiciona na empresa. No ponto de vista da informação, as rotinas que devem ser automatizadas serão vistas da mesma forma que as manuais, visualizando a informação como um todo. O ponto de vista computacional trata das funções de processamento e dos tipos de dados. A estrutura da aplicação é independente dos computadores e da rede que os interliga. O ponto de vista da engenharia especifica mecanismos de controle e transparência, processadores, memória e redes de comunicação que juntos permitem a distribuição dos dados. O ponto de vista da tecnologia é responsável pela configuração, instalação e manutenção de hardware e software de um sistema ODP.
Para o nosso estudo será abordado apenas o ponto de vista da computação, já que é nele que são enumerados os objetos a serem processados e a forma como estão organizados.
Para compreensão dos detalhes pertinentes, estão descritos a seguir alguns conceitos correlatos apresentados no modelo de referência ODP. Em seguida são colocados alguns detalhes sobre o ponto de vista computacional.
4.1 Conceitos Básicos de ODP
Para que não haja problemas na interpretação do modelo, o modelo ODP descreve de forma concisa os conceitos básicos utilizados, sendo apresentados apenas os relevantes a este trabalho. Uma ação é definida como um acontecimento. Uma ação atômica é definida como uma ação que possui a propriedade de
atomicidade, ou seja, que não pode ser subdividida. Um objeto é um modelo de uma entidade - qualquer elemento concreto ou abstrato de interesse. O estado de um objeto em um determinado instante é o conjunto de todas as seqüências de ações que ele pode executar. Uma interação é uma ação entre dois ou mais objetos.
O conceito de objeto é largamente utilizado no modelo de referência porque com ele é possível determinar o que será feito independente de como o será. Desta forma, garante-se a transparência necessária quando tem-se vários equipamentos de vários fornecedores cooperando entre si, levando a um processamento aberto.
4.2 O Ponto de Vista da Computação
O ponto de vista da computação trata das funções e como serão utilizadas. Para compreender como os objetos se relacionam, primeiro serão abordados alguns conceitos para o ponto de vista. Logo em seguida, obtém-se o funcionamento das transações através da união destes conceitos.
4.2.1 Conceitos Básicos
No ponto de vista computacional, tem-se os seguintes conceitos relevantes a este estudo:
- Announcement: uma atividade iniciada em um objeto computacional cliente, passando por um objeto de comunicação até o objeto servidor, onde uma operação de invocação acontece.
- Computational invocation: a ação inicial de um interrogation ou de um announcement.
- Computational termination: ação final de um interrogation.
- Interrogation: uma atividade iniciada em um objeto computacional cliente, passando por um objeto de comunicação até o objeto servidor, onde uma operação de invocação acontece, retornando ao cliente através do objeto de comunicação.
- Operation Interface: interfaces definidas por um conjunto de operações.
- Transactional Interface: uma interface contendo uma ou mais operações transacionais.
- Transactional Operation: uma operação que contém as quatro propriedades ACID.
- Transparency constraints: atributos de ambiente que provê uma ou mais transparências para distribuição, incluindo transparência de acesso, concorrência, localização e replicação.
4.2.2 Estruturação
Uma especificação computacional é aquela onde tem-se interfaces computacionais e os objetos estão relacionados com o ambiente. Qualquer operação possui um nome distinto, tanto para o seu início como para o seu término. Se for uma operação transacional, o término deve conter uma identificação de sucesso ou fracasso.
O comportamento de uma interface transacional consiste de:
a) determinação das ações iniciais e finais das operações da interface;
b) resolução de conflitos;
c) uma expressão do comportamento para cada operação.
Para invocar uma operação computacional em um objeto por outro, é necessário utilizar-se um objeto de comunicação entre eles. As invocações possíveis são interrogations e announcements.
Um interrogation consiste dos seguintes passos:
a) uma interação entre o objeto cliente e o objeto de comunicação, requisitando uma invocação de uma operação com ou sem parâmetros;
b) uma interação entre o objeto de comunicação e o objeto servidor, resultando em uma invocação computacional no servidor,
c) as ações da operação invocada, a partir do seu início até o seu final, com o objeto de comunicação requisitando a transferência do término e dos resultados, se existirem;
d) uma interação entre o objeto cliente e o objeto de comunicação, para o retomo da informação de término para o cliente.
Já, um announcement prevê os seguintes passos:
a) uma interação entre o objeto cliente e o objeto de comunicação, requisitando uma invocação de uma operação com ou sem parâmetros;
b) uma interação entre o objeto de comunicação e o objeto servidor, resultando em uma invocação computacional no servidor;
c) as ações da operação invocada.
A diferença entre um interrogation e um announcement é que, na primeira forma, o objeto cliente apenas continua o seu processamento após o retorno do processamento do objeto servidor. Já, na segunda forma, o objeto cliente continua o seu processamento independente da execução da invocação realizada.
Todas as invocações de transações devem ser invocações de operações transacionais, podendo ser:
a) iniciada uma nova transação quando a invocação for um announcement;
b) iniciada uma nova transação quando a invocação for um interrogation e a ação que invoca não faz parte da transação;
c) iniciada uma nova subtransação quando a invocação for um interrogation e a ação que invoca faz parte da transação.
No final de uma operação transacional:
a) se a ação encerra com falha, a operação é revertida; a reversão da operação implica na reversão de todas as subtransações, se existirem;
b) se a ação encerra com sucesso e a operação é a raiz de um conjunto de transações, a transação como um todo é comprometida;
c) se a ação encerra com sucesso e a operação não é a raiz de um conjunto de transações, o término é determinado pelo pai da transação.
A partir destes conceitos, é possível identificar o conceito clássico de transação adaptado à utilização em sistemas distribuídos abertos através da sua união ao conceito de objeto, que permite entre outras vantagens a transparência de implementação.
5 Comentários Finais
Os sistemas distribuídos, entre outros objetivos, permitem facilitar o crescimento computacional e permitem que a capacidade de processamento, além das informações, estejam mais próximas do seu cliente final.
Sistemas abertos têm como um dos seus objetivos a interconexão de sistemas computacionais disponibilizados por vários fabricantes, permitindo a troca de informações entre eles.
Com a adoção de sistemas abertos e distribuídos, aumentaram as dificuldades como a de manter a integridade das informações processadas. Para solucionar este problema adaptou-se o conceito de transações largamente utilizado em bancos de dados para sua utilização em sistemas distribuídos.
Para implementar estes conceitos, surgiram experimentos como o Argus [11], que permitiram ter uma noção do seu real funcionamento em sistemas distribuídos. Além de modelos experimentais, surgiram modelos completos de atividades atômicas para sistemas distribuídos, como o descrito em [10]. Mas isto não é o suficiente, visto que o futuro requer um funcionamento mais abrangente para este conceito.
Para permitir uma globalização do conceito em termos de sistemas operacionais distribuídos abertos, tem-se a proposta de padronização Open Distributed Processing (ODP) [1] [2] [3] [4] [5] que se utiliza do conceito de atividades atômicas como forma de manter a integridade das informações.
A forma abrangente na definição ODP atende ao conceito básico, mas não menciona a forma de implementação. Isto pode permitir a implementação de várias formas. O que poderá definir um perfeito inter-relacionamento entre sistemas distintos será a interface de acesso a um objeto de controle de atomicidade. Desta forma tem-se realmente o conceito de sistemas distribuídos abertos na sua totalidade, garantindo transparência no funcionamento deste como um todo. Esta definição apresentada no modelo de referência ODP evidencia a importância das interfaces no desenvolvimento de sistemas abertos, permitindo a sua utilização da forma mais abrangente possível. Com isto, salienta-se a importância da definição de interfaces, devendo ser suficientemente completas para cobrir uma gama variada de possibilidades, tanto para processamento normal como para o caso da ocorrência de falhas. Por outro lado, deve-se limitar a quantidade de operações executadas por um objeto, para não torná-lo ineficiente pela quantidade de estados a serem gerenciados.
A definição destas interfaces também influenciará os objetos gerenciadores, responsáveis pela ordenação do processamento como um todo. Objetos deste tipo podem ser definidos como nos gerenciadores descritos na seção 3.
Para prosseguir o estudo na área, propõe-se a identificação de interfaces ou operações necessárias para o perfeito controle de transações em sistemas distribuídos abertos. Uma outra linha de estudo pode tentar identificar interfaces já definidas em modelos ou implementações já apresentadas, verificando a sua validade em sistemas distribuídos abertos.
Referências bibliográficas:
1. ANSA atomic activity model and infrastructure. Cambridge, Feb. 1992.
2. BASIC reference model of ODP - Part 1: overview. CCITT X901, ISO 10746-1, 91. ISO/IEC/JTC/SC21/WG7, July 92.
3. BASIC reference model of ODP - Part 2: descriptive model. CCITT X902, ISO 10746-2, 92. ISO/IEC/JTC/SC21/WG7, Feb. 92.
4. BASIC reference model of ODP - Part 3: prescriptive model. CCITT X903, ISO 10746-3, 91. ISO/IEC/JTC/SC21/WG7, July 92.
5. BASIC reference model of ODP - Part 4: architectural semantics specification techniques and formalisms. CCITTX 905, ISO 10746-4, 91 - ISO/IEC/JTC/SC21/WG7, July 92.
6. BERNSTEIN, P. A.; GOODMAN, N. Concurrency control in distributed database systems. ACM Computíng Surveys, v. 13, n. 2, p. 185-221, June 1981.
7. GOSCINSKI, Andrzej. Distributed operating Systems: the logical design. Addison-Wesley, 1991.
8. HAERDER, Theo; REUTER, Andreas. Principles of transaction-oriented database recovery. Computer Surveys, v. 15, n. 4, Dec. 1983.
9. LISKOV, B. et al. Implementation of Argus. In: SYMPOSIUM OF OPERATING SYSTEMS PRINCIPLES, 11 th, 1987, Austin. Proceedings. New York: ACM, 1987.
10. RESS, R. T. O. The ANSA computational model. Cambridge, Architecture Projects Management Ltd., 1991. (AR.001)
11. UNE INTRODUCTION au modèle de référence ODP. In: PENNA, Manoel Camilio; GAY, Valery. Des nouvelles architectures pour les communications. Paris, 1992.
Manoel Camillo de Oliveira Penna Neto - CEFET
Este trabalho aborda o conceito de transações em sistemas distribuídos. É feita uma revisão geral das técnicas utilizadas para realização deste mecanismo, e o estudo de dois modelos para atividades atômicas: o modelo de ações atômicas do projeto ANSA e o modelo e transações para processamento distribuído aberto .
1 Introdução
Com a descentralização do processamento surgiu a necessidade de implementar técnicas que garantissem a integridade das informações processadas neste novo ambiente. Uma das técnicas que possui esta característica é a transação, baseada no conceito de ação atômica. Esta técnica permite o encapsulamento de um conjunto de operações quando da sua execução de tal forma que, se o processamento ocorrer sem a presença de falhas, garante-se que todas as operações foram executadas. Caso ocorra uma falha na execução de qualquer uma das operações do conjunto, garante-se que qualquer resultado obtido por este conjunto será ignorado, voltando o processamento ao estado anterior ao da execução da transação.
Esta característica de execução ou não de um determinado conjunto de operações é que garante a integridade das informações processadas, não importando a localização tanto do ponto de processamento como das informações acessadas (arquivos).
Este trabalho repassa o conceito de transações e suas características e apresenta o modelo de processamento atômico proposto pelo projeto Advanced Networked Systems Architecture (ANSA) [1], que se preocupa com a integridade dos objetos distribuídos no sistema. O trabalho também aborda a normalização ISO/CCITT que trata do processamento aberto distribuído (Open Distributed Processing - ODP) [2] [3] [4] [5] [6] que normaliza os conceitos necessários para processamento aberto distribuído, utilizando-se intensamente do conceito de transações como instrumento de garantia de integridade dos sistemas distribuídos. Por fim, é verificada a importância da utilização do conceito de objetos e a importância, das interfaces destes objetos para atingir a transparência necessária ao processamento distribuído aberto.
Na seção 2 serão abordados os conceitos básicos relacionados às transações. Na seção 3 será estudado o modelo ANSA para atividades atômicas. Na seção 4 será abordado o modelo de transações ODP. Para finalizar, na seção 5 serão feitas as considerações finais do trabalho e apresentadas algumas propostas de trabalhos futuros.
2 Transações
As transações surgiram na teoria de bancos de dados. São uma forma de permitir alterações de forma segura em bases de dados, distribuídas ou não, garantindo a integridade das informações tratadas, sem a necessidade de controle explícito detalhado a nível de programação [7].
Uma transação é um conjunto de operações delimitadas por cláusulas do tipo Begin Transaction e End Transaction, sendo que os resultados obtidos - parciais ou finais - das operações delimitadas ou são efetivados como um todo ou nada é efetivado.
2.1 Propriedades das Transações
Para garantir o conceito das transações, foram especificadas quatro propriedades que definem suas características [8]: atomicidade, consistência, independência e durabilidade (propriedades ACID). Estas propriedades aplicadas em conjunto garantem a integridade e consistência das informações tratadas pelas transações. As quatro propriedades estão descritas a seguir.
2.1.1 Atomicidade
Esta propriedade determina que todas as operações delimitadas na transação ou executam ou nenhuma delas executa. Desta forma, vê-se a transação como uma ação única. Se uma transação executa até o seu final, os resultados obtidos serão efetivados; caso contrário, nenhum resultado obtido dentro da transação até o instante da ocorrência da falha será efetivado.
2.1.2 Consistência
Esta propriedade determina que os resultados obtidos por uma transação são consistentes no que diz respeito à concorrência entre transações. Ou seja, mesmo no caso do processamento concorrente de várias
transações, o resultado será o mesmo que seria obtido, caso estas várias transações tossem executadas de forma seqüencial.
2.1.3 Independência
Esta propriedade prevê que os resultados obtidos por uma transação somente serão utilizados por esta mesma transação, até o encerramento e efetivação destes resultados, sendo então disponibilizados para uso externo à transação em questão (apenas no caso de efetivação).
2.1.4 Durabilidade
Esta propriedade garante que os resultados obtidos por uma transação serão efetivados e não serão perdidos, salvo em caso de catástrofes com inundações ou terremotos.
2.2 Manutenção de Concorrência e Controle de Deadlocks
Como sistemas computacionais podem executar vários processos de forma concorrente, existe a possibilidade de concorrência entre transações e, ainda, a concorrência no acesso à base de dados por estas transações. Para evitar problemas como conflitos, é necessário um controle seguro de acesso a objetos por parte das transações para permitir a perfeita concorrência de processamento entre estas transações ou, no caso da ocorrência de deadlocks, a detecção destes casos e a devida solução.
Para solucionar estes casos, existem várias técnicas que permitem evitar ou contornar casos de conflitos. As técnicas mais comuns são two-phase locking e optimistic locking. Na primeira, cada transação possui duas fases no que tange a acesso a objetos. A primeira fase é aquela na qual a transação obtém o bloqueio de todos os objetos que serão utilizados no seu processamento. Na segunda fase, existe o processamento e a efetivação dos resultados com o conseqüente desbIoqueio dos objetos usados. Esta técnica garante que não irão ocorrer conflitos durante o processamento, já que a transação só irá prosseguir caso obtenha o controle dos objetos necessários. Com isto evita-se o problema de solucionar deadIocks, com a execução já parcialmente realizada por parte das transações.
No optimistic locking, assume-se que a ocorrência de conflitos será mínima, sendo portanto desprezado o controle de concorrência. Todas as alterações realizadas pela transação são armazenadas até o seu final, quando irão ser ou não processadas. Se forem permitidas as alterações - se outra transação não modificou o estado inicial dos objetos a serem alterados - a transação encerra normalmente. Caso contrário, a transação será abortada e seus resultados abandonados.
2.3 Efetivação de Transações
A parte mais crítica da transação é sem dúvida, o momento da efetivação dos resultados obtidos pelas suas operações. Para garantir a integridade das informações deve-se permitir que ou todos os resultados sejam efetivados ou, caso isto não seja possível, todos os resultados obtidos deverão ser desprezados. Para permitir esta característica, utiliza-se o algoritmo conhecido como Two-phase Commit [9].
Neste algoritmo, um nodo é o coordenador e os outros são os subordinados. O coordenador manda uma mensagem para cada subordinado, perguntando se estes estão aptos a comprometer a transação. Se pelo menos um dos nodos subordinados não concordar, a transação é abortada e seus resultados desprezados. Cada nodo concordante deverá gravar um registro em um log de processamento. Se todos os subordinados aceitarem o encerramento da transação, o nodo coordenador também grava esta informação em um log e então envia uma mensagem para cada subordinado para que os resultados sejam efetivados.
As gravações em log descritas acima são úteis na recuperação em caso de falhas, para ser conhecido o ponto onde estava o processamento quando ocorreu a falha e a atitude a ser tomada.
2.4 Transações Aninhadas
Para permitir um melhor controle no processamento de uma transação e permitir o processamento concorrente de várias partes de uma mesma transação, permite-se subdividir uma transação em várias subtransações, de tal forma que estas subtransações estejam vinculadas ao processamento da primeira.
Este vínculo está relacionado com as três propriedades das transações aninhadas, relacionadas abaixo:
(i) Uma transação atômica é efetivada com sucesso se, e somente se, a transação principal é efetivada e se todas as subtransações desta principal também forem efetivadas com sucesso.
(ii) O cancelamento de uma subtransação é notificado à transação principal sem cancelá-la para que esta possa decidir se deve prosseguir ou não.
(iii) O cancelamento de uma transação principal cancela todos os resultados obtidos por subtransações, mesmo que estas tenham supostamente sido efetivadas.
Deve-se ressaltar que, mesmo que uma subtransação tenha sido efetivada, os seus bloqueios são herdados pela principal até o seu encerramento.
2.5 Vantagens na Utilização de Transações
A utilização de transações em sistemas distribuídos abertos garante a integridade das informações tratadas, pelo simples fato de que a ocorrência de qualquer falha no processamento, ocorrida nos nodos envolvidos com este processamento, fará com que os resultados parciais obtidos sejam ignorados.
Isto permite com que a base de dados permaneça sempre num estado seguro e consistente.
Outra vantagem na utilização de transações em sistemas distribuídos abertos é a facilidade de programação, já que estes controles de concorrência e integridade de execução não necessitam ser feitos explicitamente no código de aplicação, a não ser pela determinação do início e fim destas transações.
Com todas estas facilidades surgiram algumas propostas de modelos para processamento atômico distribuído. Um destes modelos, o ANSA Atomic Activity Model é comentado na seção seguinte, considerando as principais características revistas até aqui, utilizadas na implementação de transações em sistemas distribuídos.
3 O Modelo ANSA
O modelo de transações ANSA [10] consiste na determinação de manipulação de objetos de forma a não perder a integridade das informações armazenadas, com processamento concorrente em sistemas computacionais distribuídos.
Para compreensão das propriedades e de sua infra-estrutura de controle deve-se entender alguns conceitos básicos e terminologias especificados no modelo computacional ANSA [1].
3.1 Conceitos Básicos
Um objeto computacional é o encapsulamento de um estado e as operações que manipulam este estado. O estado de um objeto é definido em termos de ligações, onde uma ligação é a associação entre um nome e uma interface. Uma operação é um conjunto de regras que permitem o acesso para consulta e/ou alteração do estado de um objeto. O conjunto completo de operações suportadas por um objeto determinam as transições possíveis de estado deste objeto.
A interface de um objeto são as operações possíveis em um objeto, caracterizadas por: nome da operação, número e tipo de argumentos, nomes das terminações possíveis resultantes da operação e o número e tipos dos resultados.
Uma atividade é a forma na qual a computação progride. No caso de uma atividade estar sendo executada em um cliente e este requisitar informações de um servidor, a atividade em questão passará do cliente para o servidor, e assim por diante se necessário. Desta forma está caracterizado um modelo cliente-servidor, genérico, no qual um objeto pode assumir a figura de um cliente ou de um servidor, ou ambas.
3.2 Propriedades ACID
O modelo conceitual de atividade atômica ANSA compreende o processamento que mantém e preserva a integridade de objetos distribuídos e seus estados mesmo na presença de falhas de software e hardware no sistema distribuído como um todo, incluindo, falhas de cliente, de servidor e/ou de comunicação.
A atividade atômica no modelo ANSA corresponde ao modelo clássico de transação, onde uma atividade atômica deve possuir as propriedades da atomicidade, consistência, independência e durabilidade.
Para que a atividade atômica possa executar com toda a segurança, deverão existir alguns controles fundamentais a serem realizados. Estes controles são definidos na infra-estrutura do modelo.
3.3 Infra-estrutura
Para ordenação da execução foi criado o conceito de Atomic Activity Tree, que determina a forma como uma atividade atômica, irá executar. Para explicar esta árvore de atividades atômicas, deve-se começar por uma atividade principal. Esta atividade pode acionar outras atividades das seguintes formas: através de um announcement, criando uma nova árvore de atividade atômica, com execução independente da primeira; ou através de um interrogation, onde cria-se uma nova atividade, cujo término permite a continuação do processamento da atividade principal.
A infra-estrutura genérica apresentada em [10] permite a execução concorrente de atividades atômicas,
definindo seis gerentes para este controle: atomic operation manager, timestamp manager, atomic activity
descriptors manager, concurrency control manager, version store manager, deadlock resolution manager. Nos itens a seguir serão comentadas as funções de cada um destes gerentes.
3.3.1 Atomic Operation Manager
Este módulo coordena a execução de atividades atômicas suportadas por um objeto atuando como servidor, de acordo com as propriedades ACID. Como complemento a este módulo, conceituou-se as partes inicial e final da atividade atômica como funções prelude e postIude. Estas funções complementares foram projetadas para interceptar requisições para - e respostas de - atividades atômicas. As funções prelude relacionam as requisições com as devidas atividades atômicas e criam o ambiente de execução da atividade atômica. As funções postIude tratam do perfeito encerramento deste processamento.
A função prelude recebe a invocação da atividade atômica e junto com o Atomic Operation Manager cria o ambiente para execução. Este ambiente inclui a identificação da atividade a ser iniciada com o uso do Timestamp Manager e de um descritor através do Atomic Activity Descriptor Manager.
A função postlude tem como objetivo encerrar a atividade atômica e entregar ou não os resultados ao cliente que a requisitou. Esta função também é responsável por retornar ao estado original, caso haja uma reversão - ou cancelamento - da atividade.
3.3.1.1 Reversão
Pode-se reverter uma atividade atômica por quatro motivos:
(i) encerrar a atividade voluntariamente;
(ii) encerrar a atividade a pedido da sua atividade principal, revertendo seus resultados;
(iii) encerrar a atividade devido a falha no nodo ou falhas de comunicação;
(iv) encerrar devido ao seu envolvimento em um caso de conflito.
Caso ocorra uma reversão, o Atomic Operation Manager requer à sua subatividade que reverta sua atividade, revertendo em seguida os seus próprios passos, retornando ao estado anterior ao início da execução da atividade.
3.3.1.2 Efetivação
Para efetivação de um atividade atômica utiliza-se o protocolo Two-phase Commit, que garante a efetivação de todas as subatividades envolvidas ou de nenhuma delas, como já foi descrito na seção 2.3.
3.3.2 Timestamp Manager
Este módulo retorna identificações baseadas no relógio do nodo ou do sistema em resposta a requisições feitas pelo Atomic Operation Manager. Estas identificações facilitam determinadas políticas de ordenação de eventos distribuídos para o controle de suas evoluções.
3.3.3 Atomic Actívity Descriptor Manager
Este módulo cria, manipula e remove descritores para atividades atômicas sobre a supervisão do Atomic Operation Manager. Estes descritores são usados para manter controle sobre a identidade e execução de atividades atômicas.
3.3.4 Concurrency Control Manager
Este módulo controla a separação de diferentes atividades atômicas. Este controle é dividido em duas fases distintas: separation phase e ordering phase. A primeira fase consiste na separação da execução de atividades atômicas que podem vir a interferir umas nas outras, para produzir uma seqüência serial de execução e controle. A segunda fase se preocupa em regular o acesso as bases de acordo com as necessidades de integridade de cada objeto atuando como servidor.
Tem-se potencialmente duas técnicas cujos algoritmos podem ser utilizados para controlar a concorrência de atividades atômicas: as técnicas baseadas em bloqueio, suscetíveis a ocorrência de conflitos; e a técnica baseada em identificação da atividade a partir da hora de requisição desta atividade, uma variação do Optimistic locking, onde caso haja a ocorrência de um conflito o algoritmo utilizado decide qual atividade irá reverter.
Se a ocorrência de conflitos não é freqüente, opta-se pela segunda técnica. Caso contrário, ocorrerão muitos casos de reversão e então a primeira técnica é mais recomendada.
3.3.5 Version Store Manager
Este módulo provê repositórios estáveis para armazenar o histórico das atividades atômicas e opera, juntamente com o Atomic Operation Manager, para recuperação de falhas e reversões da atividade.
3.3.6 Deadlock Resolution Manager
Este módulo em conjunto com o Concurrency Control Manager tenta evitar e/ou detectar e solucionar a ocorrência de deadlocks no sistema.
Este é um modelo para controle e processamento de atividades atômicas. A seguir será abordado o modelo de referência ODP, mais abrangente já que trata de processamento distribuído aberto, mas de interesse a este trabalho já que contém características de atomicidade para integridade dos objetos.
4 Modelo de Referência ODP
O Open Distribsded Processing (ODP) [2] [3] [4] [5] é um modelo de referência que descreve as características necessárias que um sistema de processamento distribuído necessita para ser aberto. Este modelo é descrito em quatro partes: visão geral do modelo, modelo descritivo, modelo prescritivo, e semântica da arquitetura com técnicas de especificação.
A visão geral descreve a motivação para o ODP apresentando o escopo, justificação e explanação de conceitos chave. O modelo descritivo contém a definição dos conceitos e a estrutura analítica para descrição normalizada de sistemas de processamento distribuído. O modelo prescritivo contém a especificação das características que qualificam o processamento distribuído como aberto. O quarto módulo contém a formalização dos modelos conceituais do ODP.
Para melhor compreensão do modelo como um todo, ele é dividido em cinco pontos de vista distintos: visão da empresa, visão da informação, visão da computação, visão da engenharia e visão da tecnologia.
O ponto de vista da empresa se preocupa com o ambiente onde um sistema ODP deve operar. Isto inclui como e onde este sistema se posiciona na empresa. No ponto de vista da informação, as rotinas que devem ser automatizadas serão vistas da mesma forma que as manuais, visualizando a informação como um todo. O ponto de vista computacional trata das funções de processamento e dos tipos de dados. A estrutura da aplicação é independente dos computadores e da rede que os interliga. O ponto de vista da engenharia especifica mecanismos de controle e transparência, processadores, memória e redes de comunicação que juntos permitem a distribuição dos dados. O ponto de vista da tecnologia é responsável pela configuração, instalação e manutenção de hardware e software de um sistema ODP.
Para o nosso estudo será abordado apenas o ponto de vista da computação, já que é nele que são enumerados os objetos a serem processados e a forma como estão organizados.
Para compreensão dos detalhes pertinentes, estão descritos a seguir alguns conceitos correlatos apresentados no modelo de referência ODP. Em seguida são colocados alguns detalhes sobre o ponto de vista computacional.
4.1 Conceitos Básicos de ODP
Para que não haja problemas na interpretação do modelo, o modelo ODP descreve de forma concisa os conceitos básicos utilizados, sendo apresentados apenas os relevantes a este trabalho. Uma ação é definida como um acontecimento. Uma ação atômica é definida como uma ação que possui a propriedade de
atomicidade, ou seja, que não pode ser subdividida. Um objeto é um modelo de uma entidade - qualquer elemento concreto ou abstrato de interesse. O estado de um objeto em um determinado instante é o conjunto de todas as seqüências de ações que ele pode executar. Uma interação é uma ação entre dois ou mais objetos.
O conceito de objeto é largamente utilizado no modelo de referência porque com ele é possível determinar o que será feito independente de como o será. Desta forma, garante-se a transparência necessária quando tem-se vários equipamentos de vários fornecedores cooperando entre si, levando a um processamento aberto.
4.2 O Ponto de Vista da Computação
O ponto de vista da computação trata das funções e como serão utilizadas. Para compreender como os objetos se relacionam, primeiro serão abordados alguns conceitos para o ponto de vista. Logo em seguida, obtém-se o funcionamento das transações através da união destes conceitos.
4.2.1 Conceitos Básicos
No ponto de vista computacional, tem-se os seguintes conceitos relevantes a este estudo:
- Announcement: uma atividade iniciada em um objeto computacional cliente, passando por um objeto de comunicação até o objeto servidor, onde uma operação de invocação acontece.
- Computational invocation: a ação inicial de um interrogation ou de um announcement.
- Computational termination: ação final de um interrogation.
- Interrogation: uma atividade iniciada em um objeto computacional cliente, passando por um objeto de comunicação até o objeto servidor, onde uma operação de invocação acontece, retornando ao cliente através do objeto de comunicação.
- Operation Interface: interfaces definidas por um conjunto de operações.
- Transactional Interface: uma interface contendo uma ou mais operações transacionais.
- Transactional Operation: uma operação que contém as quatro propriedades ACID.
- Transparency constraints: atributos de ambiente que provê uma ou mais transparências para distribuição, incluindo transparência de acesso, concorrência, localização e replicação.
4.2.2 Estruturação
Uma especificação computacional é aquela onde tem-se interfaces computacionais e os objetos estão relacionados com o ambiente. Qualquer operação possui um nome distinto, tanto para o seu início como para o seu término. Se for uma operação transacional, o término deve conter uma identificação de sucesso ou fracasso.
O comportamento de uma interface transacional consiste de:
a) determinação das ações iniciais e finais das operações da interface;
b) resolução de conflitos;
c) uma expressão do comportamento para cada operação.
Para invocar uma operação computacional em um objeto por outro, é necessário utilizar-se um objeto de comunicação entre eles. As invocações possíveis são interrogations e announcements.
Um interrogation consiste dos seguintes passos:
a) uma interação entre o objeto cliente e o objeto de comunicação, requisitando uma invocação de uma operação com ou sem parâmetros;
b) uma interação entre o objeto de comunicação e o objeto servidor, resultando em uma invocação computacional no servidor,
c) as ações da operação invocada, a partir do seu início até o seu final, com o objeto de comunicação requisitando a transferência do término e dos resultados, se existirem;
d) uma interação entre o objeto cliente e o objeto de comunicação, para o retomo da informação de término para o cliente.
Já, um announcement prevê os seguintes passos:
a) uma interação entre o objeto cliente e o objeto de comunicação, requisitando uma invocação de uma operação com ou sem parâmetros;
b) uma interação entre o objeto de comunicação e o objeto servidor, resultando em uma invocação computacional no servidor;
c) as ações da operação invocada.
A diferença entre um interrogation e um announcement é que, na primeira forma, o objeto cliente apenas continua o seu processamento após o retorno do processamento do objeto servidor. Já, na segunda forma, o objeto cliente continua o seu processamento independente da execução da invocação realizada.
Todas as invocações de transações devem ser invocações de operações transacionais, podendo ser:
a) iniciada uma nova transação quando a invocação for um announcement;
b) iniciada uma nova transação quando a invocação for um interrogation e a ação que invoca não faz parte da transação;
c) iniciada uma nova subtransação quando a invocação for um interrogation e a ação que invoca faz parte da transação.
No final de uma operação transacional:
a) se a ação encerra com falha, a operação é revertida; a reversão da operação implica na reversão de todas as subtransações, se existirem;
b) se a ação encerra com sucesso e a operação é a raiz de um conjunto de transações, a transação como um todo é comprometida;
c) se a ação encerra com sucesso e a operação não é a raiz de um conjunto de transações, o término é determinado pelo pai da transação.
A partir destes conceitos, é possível identificar o conceito clássico de transação adaptado à utilização em sistemas distribuídos abertos através da sua união ao conceito de objeto, que permite entre outras vantagens a transparência de implementação.
5 Comentários Finais
Os sistemas distribuídos, entre outros objetivos, permitem facilitar o crescimento computacional e permitem que a capacidade de processamento, além das informações, estejam mais próximas do seu cliente final.
Sistemas abertos têm como um dos seus objetivos a interconexão de sistemas computacionais disponibilizados por vários fabricantes, permitindo a troca de informações entre eles.
Com a adoção de sistemas abertos e distribuídos, aumentaram as dificuldades como a de manter a integridade das informações processadas. Para solucionar este problema adaptou-se o conceito de transações largamente utilizado em bancos de dados para sua utilização em sistemas distribuídos.
Para implementar estes conceitos, surgiram experimentos como o Argus [11], que permitiram ter uma noção do seu real funcionamento em sistemas distribuídos. Além de modelos experimentais, surgiram modelos completos de atividades atômicas para sistemas distribuídos, como o descrito em [10]. Mas isto não é o suficiente, visto que o futuro requer um funcionamento mais abrangente para este conceito.
Para permitir uma globalização do conceito em termos de sistemas operacionais distribuídos abertos, tem-se a proposta de padronização Open Distributed Processing (ODP) [1] [2] [3] [4] [5] que se utiliza do conceito de atividades atômicas como forma de manter a integridade das informações.
A forma abrangente na definição ODP atende ao conceito básico, mas não menciona a forma de implementação. Isto pode permitir a implementação de várias formas. O que poderá definir um perfeito inter-relacionamento entre sistemas distintos será a interface de acesso a um objeto de controle de atomicidade. Desta forma tem-se realmente o conceito de sistemas distribuídos abertos na sua totalidade, garantindo transparência no funcionamento deste como um todo. Esta definição apresentada no modelo de referência ODP evidencia a importância das interfaces no desenvolvimento de sistemas abertos, permitindo a sua utilização da forma mais abrangente possível. Com isto, salienta-se a importância da definição de interfaces, devendo ser suficientemente completas para cobrir uma gama variada de possibilidades, tanto para processamento normal como para o caso da ocorrência de falhas. Por outro lado, deve-se limitar a quantidade de operações executadas por um objeto, para não torná-lo ineficiente pela quantidade de estados a serem gerenciados.
A definição destas interfaces também influenciará os objetos gerenciadores, responsáveis pela ordenação do processamento como um todo. Objetos deste tipo podem ser definidos como nos gerenciadores descritos na seção 3.
Para prosseguir o estudo na área, propõe-se a identificação de interfaces ou operações necessárias para o perfeito controle de transações em sistemas distribuídos abertos. Uma outra linha de estudo pode tentar identificar interfaces já definidas em modelos ou implementações já apresentadas, verificando a sua validade em sistemas distribuídos abertos.
Referências bibliográficas:
1. ANSA atomic activity model and infrastructure. Cambridge, Feb. 1992.
2. BASIC reference model of ODP - Part 1: overview. CCITT X901, ISO 10746-1, 91. ISO/IEC/JTC/SC21/WG7, July 92.
3. BASIC reference model of ODP - Part 2: descriptive model. CCITT X902, ISO 10746-2, 92. ISO/IEC/JTC/SC21/WG7, Feb. 92.
4. BASIC reference model of ODP - Part 3: prescriptive model. CCITT X903, ISO 10746-3, 91. ISO/IEC/JTC/SC21/WG7, July 92.
5. BASIC reference model of ODP - Part 4: architectural semantics specification techniques and formalisms. CCITTX 905, ISO 10746-4, 91 - ISO/IEC/JTC/SC21/WG7, July 92.
6. BERNSTEIN, P. A.; GOODMAN, N. Concurrency control in distributed database systems. ACM Computíng Surveys, v. 13, n. 2, p. 185-221, June 1981.
7. GOSCINSKI, Andrzej. Distributed operating Systems: the logical design. Addison-Wesley, 1991.
8. HAERDER, Theo; REUTER, Andreas. Principles of transaction-oriented database recovery. Computer Surveys, v. 15, n. 4, Dec. 1983.
9. LISKOV, B. et al. Implementation of Argus. In: SYMPOSIUM OF OPERATING SYSTEMS PRINCIPLES, 11 th, 1987, Austin. Proceedings. New York: ACM, 1987.
10. RESS, R. T. O. The ANSA computational model. Cambridge, Architecture Projects Management Ltd., 1991. (AR.001)
11. UNE INTRODUCTION au modèle de référence ODP. In: PENNA, Manoel Camilio; GAY, Valery. Des nouvelles architectures pour les communications. Paris, 1992.