tendÊncias da pesquisa em sistemas distribuídos · externas (correio eletrônico, isdn, acesso a...
TRANSCRIPT
SBA: Controle & Automação, VoI. 1, NQ 4, pp. 264-276
TENDÊNCIAS DA PESQUISA EM SISTEMAS DISTRIBUíDOS
Yves Deswarte
INRIA - LAAS/CNRS7, Avenue du Colonel Roche
31~77 - Toulouse - FRANÇA
Resumo
Este trabalho visa descrever sucintamente as principais orientações
da pesquisa sobre sistemas distribuídos e levantar tendências mais
significativas para os proxlmos anos. São apresentadas as necessidadesde suporte para aplicações distribuídas e os requisitos de qualidade 'destes
serviços. O ciclo de vida de uma aplicação e as particularidades dos
sistemas distribuídos em automação industrial são também objeto destapublicação.
Research Trends in Distribllted Systems
Abstract
In this paper are briefly described the principal orientations on
distributed systems researchs and the more relevant trends for next
years. Support and quality requirements for distributed applications are
also presented. At last, life cycle of such application and distributedsystem particularities in industrial manufacturing systems and process
control are also addressed.
A §~gunda parte é dedicada aossuporte::; fornecidos às aplicaçõesdistribu!das: comunicações, modelos deaplicaçãg e sistemas operacionais.
A terceira parte apresenta os serviços
esperadQs do sistema distribuído, empartic4lar no que diz respeito àtransparência da distribuição e à segurançade funcionamento.
Cada vez que for possível, serãoreferenciados projetos de pesquisa
ilustrando ~stas tendências, principalmente
na Franç~ ~ na Europa (que o autor conhecemelhor- ).
primeira deste artigohistórico dodistribuídos e
e as direçõesrazõesas
partebreve
dos sistemas
Aapresenté;!. um
desenvol.vim~nto
tenta l~vªntar
futuras.
Este artigo visa descreversucintamente as principais orientações da
pesquisa sobre os sistemas distribuídos e
levantar as tendências mais significativaspara os próximos anos.
1. INTRODUÇÃO
Os Sistemas Distribuídos são, desde
alguns anos, o ponto de encontro de algumasdisciplinas entre as mais ativas da
informática: comunicações, redes, sistemas
operacionais, linguagens, base de dados,controle de processos, modelização,tolerância a faltas, etc. Este fenômenoacompanha o desenvolvimento do mercado dainformática distribuída que atinge um
crescimento mundial da ordem de 75% ao ano(enquanto o mercado global da informática
cresce somente 15% ao ano).
264
A quarta parte descreve o ciclo de
vida de uma aplicação distribuída e as
ferrar"entas e métodos que lhe são
associados: concepção, realização, operação.
homogêneas (fechadas = "propl~ietár.ias" ): na
IBM: SNA; na Honeywell-Bull: D5A; na DEC:
DNA,. etc.
Por fim, a última parte aborda certas
particularidades dos sistemas distribuídos
de automação industrial.
2. HISTÓRICO DOS SISTEMAS DISTRIBUíDOS
De 1960 a 1970
Com o desenvolvimento dos sistemas a
tempo compartilhado ("time-sharing"), oafastamento dos periféricos conduz ao
refinamento de técnicas de comunicação
ponto-a-ponto e multi-ponto (concentrador
de terminais) ao redor do computador
central,. bem como ao gerenciamento de
periféricos distantes ("remote batch
processing").
De 1980 a 1985
Assiste-se ao aparecimento dos
primeiros sistemas operacionais distribuídos
por interconexão de sistema~ homogêneos
(geralmente UNIX} com sistemas de
gerenciamento de arquivos distribuídos (Ex:
Newcastle Connection (Brownbridge et alii,
1982» ou permitindo a execução à distância
(Ex: LOCUS (Popek & Walker, 1985».
Por outro lado, a importância dos
organismos de normalização cresce: modelo
de referência das interconexões de sistemas
abertos (Open System Interconnection
Reference Model) da ISO (Zimmermann, 1980)
que permitem a comunicação do hardware (e
do software) de vários fornecedores.
Paralelamente, desenvolveram-se os
primeiros sistemas distribuídos com vários
computadores interligados por conexões
ponto-a-ponto, para aplicações muito
específicas (Sistema SAGE de vigilância do
território dos Estados Unidos, sistema SABRE
de reserva de passagens aéreas). Os
protocolos implementados são muito simples e
gerenciados diretamente pela aplicação.
Aparecem também as "redes digitais a
integração de serviços" (ISDN: Integrated
Service Digital Networks).
Tendência Atual
A tendência geral está na abertura:
trabalho com
recursos (arquivos,
De 1975 a 1980
De 1970 a 1975
Por outro lado, os principaisconstrutores desenvolvem suas próprias redes
Mas os trabalhos de normalização sãomuito lentos: são necessários v~rios anos
para obter uma norma aceitável. Para ganhartempo, os organismos de normalização têm
tendência a normalizar padrões "de fato"pré-existentes: por exemplo, Ethernet, 10anos após seu desenvolvimento 7 foinormalizado pela IEEE (IEEE 8~2.3) e depoispela ISO (ISO 8802). Além disso, amultiplicidade das necessidades dosusuarios
e das tecnologias dos fabricantes conduz a
uma multiplicação das"classes", o que leva anormas não-homogêneas. Para remediar este
- abertura dos fabricantes que tentam
aproximar suas arquiteturas de redes
aos padrões ISO ou éi:)S padrões "de
fato" (TCP/iP, Ethernet) ou aindadesenvolvem "gateways" para a
interconexão de redes heterogêneas
(Ex: DSA-SNA);
- abertura em direção de sistemas
operacionais "não-proprietários"; por
exemplo, os trabalhos de normalização
do UNIX pelo grupo X-Open.
o surgimento daso desenvolvimento
de
Estes anos vêemprimeiras redes locais e
das estaçõescompartilhamento deimpressoras).
Para reduzir o custo das comunicações,são concebidas redes gerais de grande
distância, fornecendo um serviço de
comunicação independente da aplicação: nos
Estados Unidos: ARPANET, na França: CYCLADES
e depois TRANSPAC. Estas redes necessitam de
protocolos mais complexos (comutação de
pacotes, roteamento, etc.) mas dão lugar a
novos serviços gerais (transferência de
arquivos).
265
3.2.1. Modelo Cliente-Servidor
3.2. Modelos de Aplicação Distribuída
utilização da difusão fornecida pelascamadas baixas dos protocolos.
Conceber uma aplicação distribuídaconsiste em imaginar e depois estruturar um
conjunto de ações ocorrendo em paralelo, emcooperação e/ou concorrência sobrecomputadores geograficamente distribuídos.
estruturação é facilitada pelade modelos. Classificaremos amodelos em quatro categorias,
certos modelos propostos possama várias categorias ao mesmo
Estautilizaçãoseguir osainda quepertencertempo.
É um dos primeiros modelos propostospara os sistemas distribufdos, emparticular para o compartilhamento dosrecursos (servidores de arquivos,servidores de impressora, etc.). Um servidorpode ser centralizado ou composto de váriasentidades equivalentes ou ainda ser, elemesmo, um cliente de outro servidor(Svoboda, 1984).
- aplicações de controle de processos,de supervisão, de segurança;
- aplicações de gerenciamento deestoques, de planificação;
- aplicações de gestão administrativa(comandos, faturas, pessoal);
- aplicações de estudo e desenvolviQento(CAD) ;aplicações de relações públicas;
-aplicações de relações internas eexternas (correio eletrônico, ISDN,acesso a banco de dados, transferência
eletrônica de dinheiro, etc.).
Orientações Futuras
É possível prever que, a mais ou menoslongo prazo, os sistemas distribuídos
integrarão aplicações distribuídasmúltiplas. Desta forma, sobre a(s) rede(s)de uma mesma empresa coabitarão e
cooperarão:
fato, "grandes" usuários tentam imporsub-conjuntos destas normas, adaptados asuas necessidades: por exemplo, GeneralMotors propõe MAP (GM, 1986), British
Aerospace associou-se a BMW, Aeritalia e aoutros usuários no projeto CNMA do programa
europeu ESPRIT (CNMA, 1986).
3. A PESQUISA SOBRE OS SUPORTES DEAPLICAÇÕES DISTRIBUíDAS 3.2.2. Modelo Transacional
3.1. Comunicação
A pesquisa nesta área é menos dinâmicaque há alguns anos atrás:
Este modelo foi inicialmente definidopara os acessos múltiplos a bases de dados(ex.: reserva de passagens de avião) (Gray,1978). Uma transação é um conjunto deoperações que têm as seguintes propriedades:
2) Sequencialidade: se várias transaçõessão executadas em paralelo, seuresultado é o mesmo que se elasfossem executadas sequencialmente numadeterminada ordem.
os problemas básicos das comunicações(qualidade do serviço, controle defluxo, etc.) foram solucionados deforma satisfatória:os métodos e ferramentas de concepçãoexistem e são normalmente utilizados,pelo menos para as camadas baixas dosprotocolos:
- as normas existentes são um freio àevolução.
1) Atomicidade: todas astransação são terminadasinicializada.
operações daou nenhuma é
Entretanto, pesquisas continuam emáreas como:
3) Permanência: quando umaterminada, seu resultado("commit" da transação).
transação éé mantido
- comunicações com taxa de transferênciamuito alta (várias Gbits/s);confidencial idade das comunicações(criptografia, fragmentação-disseminação) ;
266
mesmo conteraninhadas).
o estadosalvo e
da transação
Uma transação pode ela
var1as transações (transaçõesPara permitir a atomicidade,inicial da transação deve sermantido durante toda a execução
para poder ser restituído:
em caso de deteção de erro (pontos de
recuperação);- em caso de interbloqueamento ("dead-
-lock").
A salvação-restauração do estadoinicial é facilitada pela utilização de"memória-estável" em disco (por exemplo,Tandem) ou em "memória rápida" (projetos
ENCHERES (Banatre et atlii, 1986a) e GOTHIC(Banatre et alii, 1986b)).
3.2.3. Atores (em CHORUS (Zimmermann etalii, 1984)) ou Módulos (em CONIC
(Kramer et alii, 1983))
Vários projetos de Sistemas
Distribuídos são baseados neste modelo:
- nos Estados Unidos: ARGUS (Liskov,1985), EDEN (Black, 1985), EMERALD(Black et alii, 1986), CLOUDS (Le
Blanc & Wilkers, 1985), etc.- na Europa: SOMIW (Shapiro, 1986), DASE
(DASE, 1986), COMANDOS (Balter, 1986),GUIDE, etc.
O modelo orientado-objeto é bemadaptado ao controle dos direitos de acesso.
A fronteira entre estes modelos ébastante difusa. Assim, a execução de umaoperação sobre um objeto pode serconsiderada como a execução de um serviço no
modelo cliente-servidor. Por outro lado, emcertos projetos, as opérações sobre osobjetos são "atômicas", o que permiteconstruir facilmente transações. Da mesma
forma, os "atores" podem ser consideradoscomo gerentes de objetos.
3.2.4. Modelo de Aplicação Orientado-Objeto
Neste modelo, toda entidade do sistemaé um objeto. Um objeto, designado por um~, possui um "estado" que pode serconsultado ou modificado por funções deacesso. O conjunto de objetos que têm asmesmas funções de acesso constitui umaclasse. Por exemplo, uma palavra-memória,uma pilha, um arquivo, um processo sãoobjetos.
São sequências de código ativadas pelachegada de mensagens e gerando outrasmensagens. As comunicações entre "atores"(ou módulos) se expressam da mesma forma,estejam eles na mesma estação ou em estaçõesdiferentes. Para tolerar as faltas,"reconfigurações" permitem reorientar asmensagens destinadas a um ator sobre umaestação em falha em direção de um "ator"equivalente de uma outra estação (Banino etalii, 1985a). Uma aplicação é entãoconstituída de execuções sucessivas de umconjunto de "atores" comunicando pormensagens.- O controle da aplicação pode serfacilitado pela utilização de "mensagens deatividade" (Banino et alii, 1985b).
O modelo orientado-objetovezes, implementado na formaabstratos": é a "programação-objeto".
é, muitasde "tiposorientada-
267
Nenhum destes modelos de aplicaçãodistribuída é especializado para uma classede aplicações dada, mesmo se alguns sãomelhor adaptados a determinadas classes (porexemplo, transações para os sistemas deb&ses de dados distribuídas). No entanto,nenhum destes modelos é reconhecido comosuficientemente geral p~ra ser adotado comomodelo de referência para servir de base àconstrução de aplicações distribuídasintegradas (no sentido dado no item I).Contudo, esta é a ambição do projeto ANSA(ANSA, 1987). Paralela~ente, a Comissão dasComunidades Européias organiza um grupo detrabalho, dirigido por Hubert Zimmermann,encarregadv de definir um "modelo dereferência do processamento distribuído"(Distributed Processing Reference Model:DPRM) , que deveria ser,o ao nível dasaplicações, o equivalente do OSI~RM aonível das comunicações.
3.3. Sistemas Operacionais Distribuídos
Os sistemas operacionais distribuídosvisam fornecer ao projetista de aplicaçãomecanismos que .~he permitam a realizaçãoeficaz dos modelos de ap~icação. Estesmecanismos podem ser mais ou menosevoluídos.
o primeiro (também o mais antigo e o
mais simples) destes mecanismos é atransferência de mensagens entre osprocessos de aplicação utilizando primitivas
tais como SEND e RECEIVE, síncronas ou não,com ou sem difusão. De fato, trata-se de ummecanismo de base sobre o qual pode-seconstruir todos os outros mecanismos.Numerosos sistemas fornecem um serviço destenível: CHORUS (Zimmermann et alii, 1984),CONIC (Kramer et alii, 1983), Amoeba(Mullender, 1985), Accent (Fitzgerald &Rashid, 1986), V-Kernel (Cheriton, 1984),
Mach-1 (Rashid, 1986), etc. Uma extensãodestes mecanismos de passagem de mensagem éconstituído pelos fluxos, generalização dos
"pipes" do UNIX.
Um mecanismo mais evoluído (mesmo queeste ponto seja asperamente discutido pelospartidários dos sistemas a passagem demensagens) é fornecido pela chamada de
procedimento remoto (RPC: "remote procedurecall"): isto consiste em fornecer uma
interface idêntica à chamada de procedimentoclássico, seja a execução local ou remota.A execução do RPC é bloqueante (síncrona)até o retorno do procedimento. O esquema deexecução é) consequentemente, simples, poisretoma o esquema clássico de execuçãosequencial. Alguns projetos tornam "atômica"a execução de procedimentos remotos,permitindo deste modo a construção simplesde aplicações tolerantes a faltas (projetos:CONCORDIA do programa ESPRIT, GOTHIC(Banatre et alii, 1986b), ARGUS (Liskov,
1985)) ou a construção de transações.Outras extensões do RPC consistem em tornálo "não-bloqueante" (RSR: "remote servicerequest" do projeto DELTA-4 (Bonn et alii,1986)) para aumentar o paralelismo, ou apermitir as comunicações de m chamantes a nchamados ("multi-functions" (Banatre etalii, 1986b)).
Outros sistemas operacionaisdistribuídos implementam diretamente osmodelos orientados-objeto e as operaçõescorrespondentes da linguagem que os suporta(CLOUDS (Le Blanc & Wilkes, 1985), SOMIW(Shapiro, 1986)).
4. QUALIDADES EXIGIDAS PARA OS SISTEMASOPERACIONAIS DISTRIBUÍDOS
4.1. Transparência da Distribuição
268
O programador de uma aplicaçãodistribuída deseja geralmente não ter que
gerar o endereçamento das entidades quemanipula: ele designa essas entidades por um
~, cabendo ao sistema operacional oencargo de associar um endereço ao nomeconhecido da aplicação. Isto não exclui que
certas entidades (sensores, atuadores,periféricos, servidores especializados,etc.) sejam localizadas em estaçõespré-definidas. Mas isto permite que certaspartes da aplicação possam ser executadas
em estações não pré-definidas, ou ainda,migrar de uma estação a outra em curso deexecução, seja após uma falha(reconfiguração), seja para melhorar o
desempenho (repartição de carga) (Theimer etalii, 1985). Assim é possível chamar pelomesmo nome um conjunto de recursos ou "poolde servidores", com o sistema operacionalescolhendo neste pool o servidor menoscarregado ou o mais próximo do cliente.Este é o caso nos projetos "CambridgeDistributed Computing System" (Needham &Hebert, 1982), Amoeba (Mullender, 1985),SATURNE (Deswarte et alii, 1986a).
Em certos casos, o sistema operacionalfornecerá à aplicação uma interfaceidêntica à de um sistema centralizado. Istopode ser obtido gerando uma memória virtualou um espaço de endereçamento único sobretoda a rede (sistema Domain d'Apo110 (Leachet a1ii, 1983)), ou um sistema degerenciamento de arquivos (NewcastleConnection (Brownbridge et alii, 1982), NFS
(Lyon et alii, 1984)), ou ainda, fornecendoum interface sistema geral (Locus (Popek &Walker, 1985)).
Devemos notar que ,por razões detolerância a faltas ou de desempenho(proximidade), certas entidades (certosarquivos, por exemplo, ou ainda, tabelas deconfiguração ou de endereçamento) sãocopiadas no sistema distribuído, sendo os diferentes exemplares designados pelo
mesmo nome. Em consequência, é importante
manter a coerência deste, apesar dos acessosparalelos aos vários exemplares e apesar dapresença possível de faltas (Locus (Popek &Walker, 1985), Saturne (Deswarte et a1ii,1986a)) .
4.2. Segurança de Funcionamento
A Segurança de Funcionamento("Dependability") pode definir-se como apropriedade de um sistema que permite
colocar uma confiança justificada no serviço
oferecido (Laprie, 1986). Segurança deFuncionamento é um termo genérico que visa
cobrir ao mesmo tempo:
- a confiabilidade ("reliability") ou
medida da continuidade do serviço:- a disponibilidade ("availability") ou
probabilidade de fornecer o serviçonum instante dado, levando em conta asaIternância.s entre os estados "em
serviço" e "fora de serviço";- a segurança ("safety") que mede a
resistência a faltas catastróficas.- a segurança ("security") que mede a
resistência a faltas intencionais(intrusões).
hidrometria, formação do pessoal de
operação, etc.)~
As técnicas de impedimento serão
desenvolvidas no item 4. Mas, qualquer queseja a "qualidade" do sistema, e portanto
para tão baixa que seja a taxa d~ falha dosseus elementos, as consequências destas
falhas poderiam ser de tal modo importantes
que pode-se tornar indispensável aintrodução de técnicas de tolerância a
faltas.
A tolerância a faltas é obtida pelaredundância, material e/ou temporal. Podese recorrer a duas técnicas para tolerar asfaltas: a deteção dos erros e a recuperaçãodestes ou o mascaramento dos erros.
faltas consiste emoperar o sistema dea probabilidade de
Os sistemas distribuídos colocam umtriplo problema do ponto de vista dasegurança de funcionamento:
Os dois outros pontos necessitam aimplementação de técnicas de impedimento afaltas ou de tole~ância a faltas no conjuntodo sistema distribuído, hardware esoftware.
- qualidade da concepção do hardware edo software (métodos e ferramentas deespecificação e de concepção);qualidade da realização (fabricação,componentes, integração, verificação);
- qualidade do ambiente de operação(alimentação elétrica, temperatura,
O mascaramento de erros consiste emutilizar redundâncias, de maneira a podercontinuar o tratamento mesmo em caso deerro: o estado do sistema é suficientementeredundante para permitir restabelecer umestado correto a partir do estado incorreto.O exemplo mais simples desta técnica é ovoto majoritário: o tratamento é efetuadonum número de exemplares suficiente paraque os exemplàres corretos sejam"majoritários"; os resultados dos diferentes
A deteção e arecu2eração dos erroscomporta uma fase de deteção com o auxíliode mecanismos integrados ou acrescentados aohardware e/ou software para efetuar ocontrole de verossimilhança sobre o estado
do hardware, do software e dos dados:verificação das durações ("watchdog"),verificação dos valores (códigos detetores,
deteção de código de instrução não-válido oude endereço inexistente, controle deverossimilhança da aplicação, programas detestes, etc.), verificação dos direitos (deum processo efetuar certas operações sobrecertos objetos).
Após deteção do erro, deve-se efetuarum diagnóstico dos elementos com falhas e,no caso da falta ser diagnosticada comopermanente, operar uma reconfiguração paraeliminar estes elementos e/ou acrescentarnovos elementos permitindo continuar otratamento. A seguir, é necessário corrigiro estado errôneo, seja por uma recuperação("roll-back") sobre um estado anterior salvo("backward recovery"), seja peloestabelecimento de um novo estado correto,por exemplo, por reinicialização ("forwardrecovery").
deem
é capaz
capazes deparasitc3s,
erros
1) as ligações físicas sãogerar erros (ruídos,etc. ) ;
2) a multiplicidade de equiparnentosaumenta
a probabilidade de falha e deintrusão;
3) a falha de um elementopropagar rapidamenteelementos sem falhas.
..O impedimento as
conceber, realizar eforma a minimizarocorrência de faltas:
O primeiro ponto pode geralmente serresolvido pelos protocolos de comunicação
(códigos detetores ou corretores de erro,repetição de mensagens, roteamentoadaptativo) ou, por dispositivos decomunicação redundantes (barramentoduplicado, anel duplicado, etc.)
269
exemplares são votados e os resultados
majoritários são considerados como corretos
(Deswarte et alii, 1986a). Esta técnica é
particularmente interessante para os
sistemas em tempo-real, visto que ostratamentos (e então as durações deexecução) são sempre os mesmos quer se tenhaou não erros. Devemos notar que a fronteira
entre "mascaramento" e "deteção +recuperação" não está clara mas depende doponto de vista do observador: um códigocorretor de erro corresponde ao mascaramento
ou à deteção-recuperação?
Nos sistemas distribuídos, é muitas
vezes tentador utilizar a redundância
intrínseca do sistema para tolerar asfaltas; a falha material de um elementopode não bloquear o conjunto do sistema, epode persistir um número suficiente deelementos corretos para continuar ostratamentos. Mas este princípio simples se
choca com dois problemas:
dominó" (Randell, 1975). Portanto, é
indispensável conceber o software de
aplicação em vista da recuperação e
estruturá-lo em função dosmecanismos disponíveis: transações,
conversação (Randell, 1975). Masesta estruturação prejudica atransparência e impõe restrições quepodem deteriorar o desempenho deforma significativa.
Por outro lado, existe uma classe defalhas "maliciosas" que devem geralmenteser levadas em conta na concepção de umsistema distribuído tolerante a faltas,pelo menos quandc se deseja atingir um alto
grau de segurança ("safety"): são as falhas"bizantinas" (do nome do problema dosgenerais bizantinos (Lamport et alii,1982) Isto pode somente ser feito ~s custasde uma redundância mais forte ou de umaconcepção específica (em particular dosmeios de comunicação) (Wensley et alii,1978) •
"recovery
Em cada etapa do ciclo de vida de umaaplicação,convêm prestar-se particular atenção
5. CONCEPÇÃO, REALIZAÇÃO E OPERAÇÃO DEAPLICAÇÕES DISTRIBUíDAS
É um dos pontos estudados dentro doprojeto SATURNE (Deswarte et alii, 1986a).
mesmo
deteção e recuperação:block" (Randell, 1975);
- mascaragem: programação em "N-versões"(Avizienis & Laprie, 1986).
A diversificação pode atéatingir a especificação funcional.
- da sua vulnerabilidade: é muitodifícil proteger fisicamente umsistema geograficamente extenso;
- da gravidade potencial ~as sabotagensou divulgações de informação.
Enfim, a segurança ("security") diantedas falhas intencionais ("intrusões") deveser particularmente estudada nos sistemasdistribuídos por causa:
As técnicas de tolerância a faltas aplicam:-se evidentemente às falhas materiais,mas elas podem também ser adaptadas àsfalhas de concepção do software pelautilização da diversificação:
- por um lado, o mascaramento necessitade uma redundância forte, geralmentemais importante que aquela que poderiaser fornecida "gratuitamente" peloselementos inativos da rede (o projetoSATURNE (Deswarte et alii, 1986a) visautilizar, da melhor forma possível, oselementos inativos para aumentar aredundânc i a ;
- por outro lado, a deteção-recuperaçãonecessita de:* se precaver contra a propagação de
erros: os mecanismos de deteção não
têm geralmente uma cobertura de l~~h
e não atuam instantaneamente; osdispositivos de comunicação entreprocessos são, por conseguinte,susceptíveis de propagar erros e decontaminar outros processos, etc ;
* definir "estados" do sistema, sejapara salvar um estado em vista deuma recuperação ("backwardrecovery") seja para estabelecer umnovo estado sadio ("forwardrecovery"); ora, é muito difícilobservar um estado estável de umsistema distribuído, por causa doparalelismo elevado e daconcorrência-cooperação entreprocessos; além disso, é desejávelrealizar somente o recobrimento dosprocessos contaminados e deixarcontinuar os outros. Utilizar"brutalmente" as técnicas derecuperação pode levar ao "efeito
270
à qualidade de forma a evitar as falhas deconcepção e de interação. Este problema é
mais difícil para as aplicações distribuídasque para as aplicações sequenciais, pois oser humano tem dificuldade em conceber e
assimilar ações múltiplas que se desenvolvemem paralelo. As aplicações distribuídasapresentam maior complexidade ~
consequentemente, maior possibilidade de
erros.
5.1. Especificações funcionais
Partindo das especificações dosrequisi tos ("requirement specifications"), asespecificações funcionais são a primeira
etapa de concepção da aplicação distribuída.É uma etapa particularmente importante,poisuma falha de concepção, a este nível, te~á
consequências graves sobre as etapasseguintes e será tanto mais custosa decorrigir. Portanto, é conveniente verificartanto quanto possível estas especificaçõesfuncionais segundo dois tipos de critérios:
1) Adequação aos requisitos: é necessárioverificar que as especificaçõesfuncionais propostas satisfazem asexigências das especificações dosrequisitos:- sob o aspecto funcional (averificação pode ser manual);
- sob o aspecto do desempenho:precisão, desempenho temporal, ...(pode ser necessário o uso esimuladores);
- sob o aspecto da segurança defuncionamento (por cálculos préviosde confiabilidade, disponibilidade,etc, eventualmente utilizandoferramentas tais como programa SURFdesenvolvido no LAAS).
2) Coerência das especificaçõesfuncionais: deve-se verificar que asespecificações sejam implementáveis eque a implementação possa funcionar(ausência de inter-bloqueios, desaturação, .•. ) •
Estas duas classes de verificaçõesserão tanto mais fáceis e válidas quanto asespecificações sejam escritas formalmente.Existem numerosos métodos de especificaçãoformal; entretanto citaremos aqui apenastrês,particularmente adaptados aos sistemasdistribu'í,dos:
271
1) As Redes de Petri: é uma representaçãográfica de sistemas paralelos, mais
sintética que as máquinas de estadosfinitos (ou autômatas), mas com a
mesma potência de representação.Existem várias extensões das redes dePetri de base (redes de Petri
"coloridas", "temporizadas","estocásticas", •.• ) melhor adaptadas acertas classes de problemas ou de
verificação. Para verificar as redesde Petri podem ser utilizados doistipos de ferramentas:
- as ferramentas analíticas quepermitem verificar formalmentecertas propriedades tais como a
ausência de inter-bloqueio, aausência de saturação, etc.
- os simuladores ou interpretadoresque permitem verificar certascaracterísticas (temporais, porexemplo) .
2) Estelle (Courtiat et alii, 1987):linguagem de ~rogramaçao de algoritmos
distribuídos, em curso de normalizaçãopela ISO, é baseada sobre autômatoscomunicantes, mais no estilo de umalinguagem procedural de tipo Pascal.Esta linguagem serve de base a ummétodo de desenvolvimento queapresenta ferramentas:- de apoio à programação (manipulação
de descrições formais),- de verificação formal de algoritmos,- de ajuste e simulação,- de geração de código.
3) Lotos (ISO, 86): é outra linguagem emcurso de normalização pela ISO para adescrição de protocolos, mas baseadaem outro formalismo (CCS, lógicatemporal).
Estas duas linguagens são estudadas noprojeto SEDOS do programa ESPRIT. Elas podemservir à especificação funcional dealgoritmos distribuídos e à sua verificaçãoformal, como também podem servirdiretamente à programação e à geração decódigo.
Mesmo que as especificações funcionaisnãc sejam descritas formalmente, é possívelutilizar ferramentas de software paraverificar algumas das suas características.Assim o simulador SPHINX desenvolvido nocontexto do projeto SCORE (Le Lann, 1987)
5.2. Realização de Aplicações Distribuídas
Existem "Ambientes de Produção deSoftware" que permitem implementar, de formaeficaz, os algoritmos descritos por
especificações funcionais. Mas poucos deleslevam em conta as particularidades dossistemas distribuídos. Uma exceção é oprojeto SEDOScitado precedentemente.
permite a avaliação de
arquiteturas distribuídas.
desempenho de ainda por execução (interpretação)
direta das redes de Petri. A linguagemde especificação torna-se então uma"linguagem de muito alto nível" (VHLL- 'very high leveI language'). Este
tipo de interpretação dasespecificações formais pode igualmenteservir à deteção de erros por
comparação entre a execução doprograma real e da interpretação daespecificação (Ayache et alii, 1982):é uma utilização da diversificação do
software.
1) Ações de monitoração: convém monitoraro comportamento da aplicação, sejapara ajustar certos parâmetros deforma a melhorar o desempenho, sejapara detetar a presença de falhas deconcepção residuais e as diagnosticar.A implementação de observadores(Ayache et alii, 1982) facilita amonitoração das aplicaçõesdistribuídas ou dos protocolos.
3) É necessário igualmente realizarmedidas para verificar que o sistemasatisfaz às exigências das
especificações de requisitos:- medidas de desempenho, por simulação
do ambiente (ex: simulação de
tráfego); existem ferramentas geraispara este tipo de medidas dedesempenho, como LYNX, desenvolvidono contexto do projeto SCORE
(Le Lann, 1987);
medição de certos parâmetros dasegurança de funcionamento(cobertura, tempo de latência .•• ) everificação do comportamento dosistema na presença de falhas; paratal, usam-se "inj etores de falhas'~
tais como o sistema MESSALINEdesenvolvido no LAAS.
A fase de realização deve também serverificada por três tipos de validação:
1) Testes funcionais devem ser aplicadospara ajustar e verificar os módulosdesenvolvidos e sua integração. Oparalelismo e a impossibilidade de
observar o estado completo do sistematornam particularmente difíceis ostestes "exaustivos". Entretanto,algumas vezes, baterias de testespodem ser geradas automaticamente por
analisadores de especificação formal.Por outro lado, ferramentas de testesinterativos podem ser desenvolvidaspara realizar testes "representativos"ou testes "agressivos" (Deswarte et
alii, 1986b).
2) Devem ser efetuadas Verificações deconformidade com as especificaçõesfuncionais. Se as especificaçõesfuncionais foram expressas formalmentee se a linguagem de programação for
adequada, é possível imaginar oestabelecimento de "provas" deequivalência entre as duas formas dealgoritmos (especificação formal eprograma). A execução simbólica podepermitir a obtenção de tais provas.Entretanto, essas técnicas são, nomomento, apenas aplicáveis a programassequenciais simples. Resta a percorrermuito caminho antes que elas possamser aplicadas de forma eficaz aossistemas distribuídos assíncronos.
5.3. Operação
Na fase dedistribuída devemde ações:
operação de uma aplicação
ser previstos três. tipos
Portanto, é necessário recorrer amétodos mais formais como as "revisõesde programa" por equipes de revisores.
Uma outra via para garantir estaequivalência consiste em transformarautomaticamente as especificaçõesformais em programa executável. Isto épossível com Estelle)por exemplo, ou
2) Ações de manutenção: a deteção ecorreção de falhas residuais deconcepção conduz ao desenvolvimento denovas versões da aplicação. Estasversões devem ser validadas como osprogramas iniciais (ver ítem IV.2) e,também, podem ser verificadas portestes de "não-regressão" para
272
assegurar que nenhuma função presente
na versão precedente não esteja
ausente na nova versão. É desejável,
às vezes, fazer coabitar váriasversões da aplicação no sistema real
para terminar a validação das novas
versões (Deswarte et alii, 1986b).
3) Evolução da aplicação: é possível que,
no decorrer do uso, novas necessidades
surjam ou que o ambiente da aplicação
mude ou que o suporte material seja
modificado ou ainda que novasaplicações precisem ser integradas e
cooperar com a aplicação existente.
Isto pode levar a modificações
completas da aplicação, para as quais
o conjunto do desenvolvimento deve ser
retomado. Evidentemente, este trabalho
de modificação é facilitado quando tenham sido utilizados metodos formais.
Por fim, é preciso ressaltar a
importância fundamental dos operadores
humanos (e do pessoal de manutenção) durante
a fase de operação. Muitas vezes, estas
pessoas são susceptíveis de cometer errosmais graves e sobretudo menos previsíveis
que as falhas materiais (Deswarte et alii,
1986b). É necessário então formá-los com
cuidado e facilitar seu trabalho por uma
interface amigável com o sistema. Deve-se
ressaltar que os operadores são responsáveispela grande maioria das intrusões na
transferência ilícita de fundos,- divulgaçãode informações confidenciais ou sabotagem.
Consequentemente, é primordial limitar e
verificar seus direitos sobre o sistema.
6. PARTICULARIDADES DOS SISTEMAS
DISTRIBUíDOS EM AUTOMAÇÃO INDUSTRIAL
Os Sistemas Distribuidos utilizados em
automação industrial implementam geralmente
os mesmos meios de comunicação, os mesmosmodelos de aplicação, as mesmas linguagens,as mesmas ferramentas de desenvolvimento que
os outros sistemas distribuídos. Entretanto,pelo menos para os mais críticos, sediferenciam pelas suas exigências em termosde tempo real.
"Um sistema é chamado 'tempo real' sealguma ou o conjunto das entidades sãoobrigadas a respeitar datas físicas para oinício e o fim de suas execuções e se odesrespeito destas datas constitui uma falhado sistema" (Le Lann, 1987).
273
Para respeitar estas datas físicas, os
Sistema Distribuídos Tempo Real impoem
geralmente limites máximos aos tempos de
acesso na rede de comunicação. Isto pode
conduzir a escolhas de alguns sub-conjuntos
de protocolos normalizados que privilegiam o
tempo de resposta (por exemplo, MAP
(GM, 1986)). Mas para aplicações que têm
exigências de confiabilidade e de segurança
('safety') rigorosas, estes limites devem
levar em conta as hipóteses de falhas (por
e~emplo, perda de ficha, reconfiguração, ••• )
o que pode levar a conceber protocolos
específicos. É o caso, por exemplo, do
protocolo 8~2.3D desenvolvido para o projeto
SCORE (Le Lann, 1987) que é compatível com a
norma IEEE 8~2.3 e Ethernet, mas que garante
tempo de acesso limitado.
A consideração de datas físicas, quetem que ser respeitadas,pode eerintegrada no
sistema operacional distribuído (por
exemplo, MARS (Kopetz et alii, 1982)). Mas
existe uma outra estrutura da aplicação que
é suscetível de se desenvolver no contexto
dos sistemas distribuídos tempo real:trata -se dos sistemas "reativos" e das
linguagens correspondentes (CCS, LCS, FP2,Esterel, .•• ) (Perrin, 1987).
Entretanto, na medida em que as
aplicações tempo real são somente uma parte
do sistema distribuído industrial, tendo porconseguinte que cooperar com outras
aplicações (gestão, planificação, CAD, ••. ),
é desejável adotar um modelo único para
todas estas aplicações e funções idênticasao nível dos sistemas operacionais
distribuídos.
7, CONCLUSÃO
A nossa intenção foi pintar umretrato da pesquisa atual a respeito dos
Sistema Distribuídos e tirar asprincipais orientações que devem determinar
sua evolução nos prOX1mos anos. Mas) se érelativamente fácil olhar para o passado eapresentar um histórico do desenvolvimentoda informática nesta área, é muito maisdifícil pretender tirar do atual universodifuso da pesquisa em Sistem.asDistribuídosas tendências que se solidificarão nofuturo. Somente o porvir permitirá julgar a
exatidão das nossas conjecturas.
Reconhecimento
Determinadas partes deste artigo e dabibliografia foram influenciad s por(Krakowiak, 1987) e (Balter, 1986).
8. REFERÊNCIAS
Black, A.P., (1985). "Supporting distributedoperations: experience with Eden". Proc.of the 1fl,lth ACM SIGO?S, Washington,December 1985.
Black, A. et alii, (1986). "Distributionand abstract types in Emerald". IEEETrans. on Software Engineering, December1986.
ANSA, (1987). ANSA: Advanced NetworkedSystems Architecture. "Building a newfuture for Information Systems".PR.26.07, January 1987, Cambridge, UK.
Avizienis, A. & Laprie, J.C., (1986)."Dependable computing: from concepts todesign diversity". Proceedings of theIEEE, vol.74, no.5, May 1986, pp.629638.
Ayache, J.M. & Courtiat, J.P. & Diaz, M.,(1982). "Self-checking software indistributed systems". Proc. of the 3!"dIEEE Int. Conf. on Distributed ComputingSystems, Miami, October 1982, pp.163170.
Bonn, G. & Martin, P. & Powell, D. &Seaton, D.T., (1986). "Delta-4: Overallsystem specificátion (Issue 1)". LAASReport no.86.276, August 1986.
Brownbridge, D.R. & Marshall, L.F. &Randell, B., (1982) • "The NewcastleConnection or UNIXes of the WorldUnite !". Software Practice anct.Experience, vol.12, 12, December 1982,pp.1147-1162.
Cheriton, D.R., (1984). "The V-kernel: asoftware base for distributed systems".IEEE Software, vol.l, 2, 1984, pp.19-42.
Balter, R., (1986). "Systemes distribues surreseau local: Analyse etclassification". BulI, DSG/CRG/OSI,decembre 1986.
CNMA, (1986). "CNMA: Communication Networkfor Manufacturing Applications". ESPRITProject 955, Proc. of the ESPRITTechnical Week, 1986, North-Holland.
Banatre, J.P. & Banatre, M. & Lapalme, G. &Ployette, F., (1986a). "The design andbuilding of Enchere, a distributedelectronic marketing system". Comm. ACM,vol. 29, 1, January 1986, pp.19-29.
Courtiat, J.P. & Dembinski, P. & Groz, R. &Jard, C., (1987). "ESTELLE: un langageISO pour les algorithmes distribues etles protocoles". T.S.I., vo1.6, no.2,1987, pp.89-1fl,l2.
Deswarte, Y. & Alami, K. & Tedaldi, O.,(l986b). "Realization, Validation andExploitation of a Fault-TolerantMultiprocessor: ARMURE". Proc. of the16th IEEE Int. Symposium on FaultTolerant Systems (FTCS-16), Vienna, July1986.
Deswarte, Y. & Fabre, J.C. & Laprie, J.C. &Powell, O., (1986a). "A saturationnetwork to tolerate faults andintrusions". Proc. of the 5th IEEE Int.Symposium on Reliability in DistributedSoftware and Database Systems, LosAngeles, January 1986, pp.74-81.
DASE , (1986) • "::.,.P.:;..r..;:.e.=l.=i.:.;cm:..::i::...nc.::.ac.::.r..>LY_--::d:.:;r-:;:a-=f:-.t:.....-.....:f::...o;:;..:r:.....-_T::..::.:RDase". ICL contribution to ECMA TC32TG2, April 1986.
Svstem
Rozier, M.,
distributedactivity
Hawai
Banino, J.S. & Morisset, G. &(1985b). "Controllingprocessing with CHORUSmessages". Proc. 18thInternational Conference on
Banatre, J.P. & Banatre, M. & Ployette, F.,(1986b). "An overview of the Gothicdistributed operating system". ResearchReport no.284, INRIA-IRISA, January1986.
Banino, J.S. & Fabre, J.C. & Guillemont, M.& Morisset, G. & Rozier, M., (1985a)."Some Fault-Tolerance Aspects of theCHORUS Distributed System". Proc. of the5th IEEE Int. Conf. on DistributedComputing Systems, Denver, May 1985,pp.43fl,l-438.
Science, January 1985.
274
Fitzgerald, R. & Rashid, R. F . , (1986) •. "The
integration of virtual memory management
and interprocess communication in
Accent". ACM Trans. on Computer Systems,vol.4, 2, May 1986, pp.147- 177.
Le Lann, G., (1987). "Le proj et SCORE: les
systemes informatiques repartis
temps-reel". T.S.I., volo6, no.2, 1:987,pp.175-178.
General Motors, (1986). "MAP specifications
versions 2.1A & 2.2". August 1986.
Gray, J .• N., (1978). "Notes on databaseoperating systems". Operating Systems,
Lecture Notes in Computer Science no.60,Springer-Verlag, 1978, pp.393-481.
Liskov, B.H., (1985). t~e / Argus languageand system". Dist~ibuted Systems:
methods and tools". Ed. .M. Paul & H.J.Siegerteditors, Lecture Notes inComputer· Science no.190, Springer-Verlag, 1985.
ISO/TC97/SC21/WG16-1 DP8807, (1986). "Lotos:a formal description technique". July1986.
Lyon, B. et ali i, (1984). "Overview of theSUN Network File Svstem". SUNMicrosystems Inc, October 1984.
& Merker, W. &"The architecture
University of1982.
Kopetz, H. & Lohnert, F.Pauthner, G., (1982).of MARS". TechnicalBerlin, MA 82/2, April
Mullender, (1985) . "Principles ofDistributed Operating Systems Design".PhD Thesis Report, Mathematisch Centrum,Vrije Universiteit Amsterdam,Netherlands, October 1985.
Lamport, L.(1982) .problem".LanguagesJuly 1982,
structure forIEEE Trans.
volo SE-1 , 2,
Needham, R.M. & Herbert, A.J., (1982). "':ç,heCambridge Distributed Computing System~t.
Addison-Wesley ICS series, 1982.
Randell, B., (1975). "Systemsoftware fault-tolerance".on Software Engineering,June 1975, pp.220-232.
Perrin, G.R., (1987). "Programmatí-on. parallele: point de vue sur les langages
et les methodes" • T. S. L, volo 6, no.,2,1987, pp.1!ll3-113.
Popek, G. & Walker, B.J., (1985). "The Locúsdistributed system architecture". MITPress, 1985.
Magee, J. & Sloman, M. &(1983) . "CONIC: an
approach to distributedcontrol systems". IEE Proc.
Pt. E, no.1, January 1983,
& Shostak, R. & Pease, M.,"The Byzantine generalsACM Trans. on Programming
and Systems, vol.4, no.3,pp.382~4!ll1.
Kramer, J. &Lister, A.,integratedcomputer
vol.13!ll,pp.1-1!ll.
Krakowiak, S., (1987). "Les systemesd'exploitation repartis evolution
recente et tendances de la recherche".~., vol.6, no.2, 1987, pp.151-161.
Laprie, J.C., (1986). "Dependability: AUnifying Concept for Reliable Computing
and Fault-Tolerance". LAAS Reportno.86.357, December 1986.
Rashid, R.F.,system".pp.37.
(1986) • "Threads ofUnix Review, August
a new1986,
Leach, J.P. & Levine, P.H. & Douros, B.P. &Hamilton, J.A. & Nelson, D.L. &Stumpf, B.L., (1983). "The architectureof an integrated local network". IEEEJournal on Selected Areas inCommunications, November1983, pp.842856.
LeBlanc, R. & Wilkes, T., (1985). "Systemsprogrammi~g with objects and actions".Proc. of the 5th IEEE Int. Conf. onDistributed Computing Svstems, Denver,May 1985.
Shapiro, M., {1986). "Structure andencapsulation in distributed systems:the proxyprinciple". Proc. of the 6thIEEE Int. Conf. on DistributedComputing, Boston, May 1986, pp.198-2!ll4.
Svoboda, L., (1984). "File servers fornetwork-based distributed systems". ACMComputing Surveys, volo16, 4, December1984, pp.353-398.
275