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.
