TENDÊNCIAS DA PESQUISA EM SISTEMAS DISTRIBUí ?· externas (correio eletrônico, ISDN, acesso a banco…

Download TENDÊNCIAS DA PESQUISA EM SISTEMAS DISTRIBUí ?· externas (correio eletrônico, ISDN, acesso a banco…

Post on 09-Nov-2018

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

<ul><li><p>SBA: Controle &amp; Automao, VoI. 1, NQ 4, pp. 264-276</p><p>TENDNCIAS DA PESQUISA EM SISTEMAS DISTRIBUDOS</p><p>Yves Deswarte</p><p>INRIA - LAAS/CNRS7, Avenue du Colonel Roche</p><p>31~77 - Toulouse - FRANA</p><p>Resumo</p><p>Este trabalho visa descrever sucintamente as principais orientaes</p><p>da pesquisa sobre sistemas distribudos e levantar tendncias mais</p><p>significativas para os proxlmos anos. So apresentadas as necessidadesde suporte para aplicaes distribudas e os requisitos de qualidade 'destes</p><p>servios. O ciclo de vida de uma aplicao e as particularidades dos</p><p>sistemas distribudos em automao industrial so tambm objeto destapublicao.</p><p>Research Trends in Distribllted Systems</p><p>Abstract</p><p>In this paper are briefly described the principal orientations on</p><p>distributed systems researchs and the more relevant trends for next</p><p>years. Support and quality requirements for distributed applications are</p><p>also presented. At last, life cycle of such application and distributedsystem particularities in industrial manufacturing systems and process</p><p>control are also addressed.</p><p>A ~gunda parte dedicada aossuporte::; fornecidos s aplicaesdistribu!das: comunicaes, modelos deaplicag e sistemas operacionais.</p><p>A terceira parte apresenta os servios</p><p>esperadQs do sistema distribudo, empartic4lar no que diz respeito transparncia da distribuio e seguranade funcionamento.</p><p>Cada vez que for possvel, seroreferenciados projetos de pesquisa</p><p>ilustrando ~stas tendncias, principalmente</p><p>na Fran~ ~ na Europa (que o autor conhecemelhor- ).</p><p>primeira deste artigohistrico dodistribudos e</p><p>e as direesrazesas</p><p>partebreve</p><p>dos sistemas</p><p>Aapresent;!. um</p><p>desenvol.vim~nto</p><p>tenta l~vntarfuturas.</p><p>Este artigo visa descreversucintamente as principais orientaes da</p><p>pesquisa sobre os sistemas distribudos e</p><p>levantar as tendncias mais significativaspara os prximos anos.</p><p>1. INTRODUO</p><p>Os Sistemas Distribudos so, desde</p><p>alguns anos, o ponto de encontro de algumasdisciplinas entre as mais ativas da</p><p>informtica: comunicaes, redes, sistemas</p><p>operacionais, linguagens, base de dados,controle de processos, modelizao,tolerncia a faltas, etc. Este fenmenoacompanha o desenvolvimento do mercado dainformtica distribuda que atinge um</p><p>crescimento mundial da ordem de 75% ao ano(enquanto o mercado global da informtica</p><p>cresce somente 15% ao ano).</p><p>264</p></li><li><p>A quarta parte descreve o ciclo de</p><p>vida de uma aplicao distribuda e as</p><p>ferrar"entas e mtodos que lhe so</p><p>associados: concepo, realizao, operao.</p><p>homogneas (fechadas = "propl~ietr.ias" ): na</p><p>IBM: SNA; na Honeywell-Bull: D5A; na DEC:</p><p>DNA,. etc.</p><p>Por fim, a ltima parte aborda certas</p><p>particularidades dos sistemas distribudos</p><p>de automao industrial.</p><p>2. HISTRICO DOS SISTEMAS DISTRIBUDOS</p><p>De 1960 a 1970</p><p>Com o desenvolvimento dos sistemas a</p><p>tempo compartilhado ("time-sharing"), oafastamento dos perifricos conduz ao</p><p>refinamento de tcnicas de comunicao</p><p>ponto-a-ponto e multi-ponto (concentrador</p><p>de terminais) ao redor do computador</p><p>central,. bem como ao gerenciamento de</p><p>perifricos distantes ("remote batch</p><p>processing").</p><p>De 1980 a 1985</p><p>Assiste-se ao aparecimento dos</p><p>primeiros sistemas operacionais distribudos</p><p>por interconexo de sistema~ homogneos</p><p>(geralmente UNIX} com sistemas de</p><p>gerenciamento de arquivos distribudos (Ex:</p><p>Newcastle Connection (Brownbridge et alii,</p><p>1982 ou permitindo a execuo distncia(Ex: LOCUS (Popek &amp; Walker, 1985.</p><p>Por outro lado, a importncia dos</p><p>organismos de normalizao cresce: modelo</p><p>de referncia das interconexes de sistemas</p><p>abertos (Open System Interconnection</p><p>Reference Model) da ISO (Zimmermann, 1980)</p><p>que permitem a comunicao do hardware (e</p><p>do software) de vrios fornecedores.</p><p>Paralelamente, desenvolveram-se os</p><p>primeiros sistemas distribudos com vrios</p><p>computadores interligados por conexes</p><p>ponto-a-ponto, para aplicaes muito</p><p>especficas (Sistema SAGE de vigilncia do</p><p>territrio dos Estados Unidos, sistema SABRE</p><p>de reserva de passagens areas). Os</p><p>protocolos implementados so muito simples e</p><p>gerenciados diretamente pela aplicao.</p><p>Aparecem tambm as "redes digitais a</p><p>integrao de servios" (ISDN: Integrated</p><p>Service Digital Networks).</p><p>Tendncia Atual</p><p>A tendncia geral est na abertura:</p><p>trabalho com</p><p>recursos (arquivos,</p><p>De 1975 a 1980</p><p>De 1970 a 1975</p><p>Por outro lado, os principaisconstrutores desenvolvem suas prprias redes</p><p>Mas os trabalhos de normalizao somuito lentos: so necessrios v~rios anos</p><p>para obter uma norma aceitvel. Para ganhartempo, os organismos de normalizao tm</p><p>tendncia a normalizar padres "de fato"pr-existentes: por exemplo, Ethernet, 10anos aps seu desenvolvimento 7 foinormalizado pela IEEE (IEEE 8~2.3) e depoispela ISO (ISO 8802). Alm disso, amultiplicidade das necessidades dosusuarios</p><p>e das tecnologias dos fabricantes conduz a</p><p>uma multiplicao das"classes", o que leva anormas no-homogneas. Para remediar este</p><p>- abertura dos fabricantes que tentam</p><p>aproximar suas arquiteturas de redes</p><p>aos padres ISO ou i:)S padres "de</p><p>fato" (TCP/iP, Ethernet) ou aindadesenvolvem "gateways" para a</p><p>interconexo de redes heterogneas</p><p>(Ex: DSA-SNA);</p><p>- abertura em direo de sistemas</p><p>operacionais "no-proprietrios"; por</p><p>exemplo, os trabalhos de normalizao</p><p>do UNIX pelo grupo X-Open.</p><p>o surgimento daso desenvolvimento</p><p>de</p><p>Estes anos vemprimeiras redes locais e</p><p>das estaescompartilhamento deimpressoras).</p><p>Para reduzir o custo das comunicaes,so concebidas redes gerais de grande</p><p>distncia, fornecendo um servio de</p><p>comunicao independente da aplicao: nos</p><p>Estados Unidos: ARPANET, na Frana: CYCLADES</p><p>e depois TRANSPAC. Estas redes necessitam de</p><p>protocolos mais complexos (comutao de</p><p>pacotes, roteamento, etc.) mas do lugar a</p><p>novos servios gerais (transferncia de</p><p>arquivos).</p><p>265</p></li><li><p>3.2.1. Modelo Cliente-Servidor</p><p>3.2. Modelos de Aplicao Distribuda</p><p>utilizao da difuso fornecida pelascamadas baixas dos protocolos.</p><p>Conceber uma aplicao distribudaconsiste em imaginar e depois estruturar um</p><p>conjunto de aes ocorrendo em paralelo, emcooperao e/ou concorrncia sobrecomputadores geograficamente distribudos.</p><p>estruturao facilitada pelade modelos. Classificaremos amodelos em quatro categorias,</p><p>certos modelos propostos possama vrias categorias ao mesmo</p><p>Estautilizaoseguir osainda quepertencertempo.</p><p> 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 vriasentidades equivalentes ou ainda ser, elemesmo, um cliente de outro servidor(Svoboda, 1984).</p><p>- aplicaes de controle de processos,de superviso, de segurana;</p><p>- aplicaes de gerenciamento deestoques, de planificao;</p><p>- aplicaes de gesto administrativa(comandos, faturas, pessoal);</p><p>- aplicaes de estudo e desenvolviQento(CAD) ;aplicaes de relaes pblicas;</p><p>-aplicaes de relaes internas eexternas (correio eletrnico, ISDN,acesso a banco de dados, transferncia</p><p>eletrnica de dinheiro, etc.).</p><p>Orientaes Futuras</p><p> possvel prever que, a mais ou menoslongo prazo, os sistemas distribudos</p><p>integraro aplicaes distribudasmltiplas. Desta forma, sobre a(s) rede(s)de uma mesma empresa coabitaro e</p><p>cooperaro:</p><p>fato, "grandes" usurios tentam imporsub-conjuntos destas normas, adaptados asuas necessidades: por exemplo, GeneralMotors prope MAP (GM, 1986), British</p><p>Aerospace associou-se a BMW, Aeritalia e aoutros usurios no projeto CNMA do programa</p><p>europeu ESPRIT (CNMA, 1986).</p><p>3. A PESQUISA SOBRE OS SUPORTES DEAPLICAES DISTRIBUDAS 3.2.2. Modelo Transacional</p><p>3.1. Comunicao</p><p>A pesquisa nesta rea menos dinmicaque h alguns anos atrs:</p><p>Este modelo foi inicialmente definidopara os acessos mltiplos a bases de dados(ex.: reserva de passagens de avio) (Gray,1978). Uma transao um conjunto deoperaes que tm as seguintes propriedades:</p><p>2) Sequencialidade: se vrias transaesso executadas em paralelo, seuresultado o mesmo que se elasfossem executadas sequencialmente numadeterminada ordem.</p><p>os problemas bsicos das comunicaes(qualidade do servio, controle defluxo, etc.) foram solucionados deforma satisfatria:os mtodos e ferramentas de concepoexistem e so normalmente utilizados,pelo menos para as camadas baixas dosprotocolos:</p><p>- as normas existentes so um freio evoluo.</p><p>1) Atomicidade: todas astransao so terminadasinicializada.</p><p>operaes daou nenhuma </p><p>Entretanto, pesquisas continuam emreas como:</p><p>3) Permanncia: quando umaterminada, seu resultado("commit" da transao).</p><p>transao mantido</p><p>- comunicaes com taxa de transfernciamuito alta (vrias Gbits/s);confidencial idade das comunicaes(criptografia, fragmentao-dissemi-nao) ;</p><p>266</p></li><li><p>mesmo conteraninhadas).</p><p>o estadosalvo e</p><p>da transao</p><p>Uma transao pode ela</p><p>var1as transaes (transaesPara permitir a atomicidade,inicial da transao deve sermantido durante toda a execuo</p><p>para poder ser restitudo:</p><p>em caso de deteo de erro (pontos de</p><p>recuperao);- em caso de interbloqueamento ("dead-</p><p>-lock").</p><p>A salvao-restaurao do estadoinicial facilitada pela utilizao de"memria-estvel" em disco (por exemplo,Tandem) ou em "memria rpida" (projetos</p><p>ENCHERES (Banatre et atlii, 1986a) e GOTHIC(Banatre et alii, 1986b)).</p><p>3.2.3. Atores (em CHORUS (Zimmermann etalii, 1984)) ou Mdulos (em CONIC</p><p>(Kramer et alii, 1983))</p><p>Vrios projetos de Sistemas</p><p>Distribudos so baseados neste modelo:</p><p>- nos Estados Unidos: ARGUS (Liskov,1985), EDEN (Black, 1985), EMERALD(Black et alii, 1986), CLOUDS (Le</p><p>Blanc &amp; Wilkers, 1985), etc.- na Europa: SOMIW (Shapiro, 1986), DASE</p><p>(DASE, 1986), COMANDOS (Balter, 1986),GUIDE, etc.</p><p>O modelo orientado-objeto bemadaptado ao controle dos direitos de acesso.</p><p>A fronteira entre estes modelos bastante difusa. Assim, a execuo de umaoperao sobre um objeto pode serconsiderada como a execuo de um servio no</p><p>modelo cliente-servidor. Por outro lado, emcertos projetos, as opraes sobre osobjetos so "atmicas", o que permiteconstruir facilmente transaes. Da mesma</p><p>forma, os "atores" podem ser consideradoscomo gerentes de objetos.</p><p>3.2.4. Modelo de Aplicao Orientado-Objeto</p><p>Neste modelo, toda entidade do sistema um objeto. Um objeto, designado por um~, possui um "estado" que pode serconsultado ou modificado por funes deacesso. O conjunto de objetos que tm asmesmas funes de acesso constitui umaclasse. Por exemplo, uma palavra-memria,uma pilha, um arquivo, um processo soobjetos.</p><p>So sequncias de cdigo ativadas pelachegada de mensagens e gerando outrasmensagens. As comunicaes entre "atores"(ou mdulos) se expressam da mesma forma,estejam eles na mesma estao ou em estaesdiferentes. Para tolerar as faltas,"reconfiguraes" permitem reorientar asmensagens destinadas a um ator sobre umaestao em falha em direo de um "ator"equivalente de uma outra estao (Banino etalii, 1985a). Uma aplicao entoconstituda de execues sucessivas de umconjunto de "atores" comunicando pormensagens.- O controle da aplicao pode serfacilitado pela utilizao de "mensagens deatividade" (Banino et alii, 1985b).</p><p>O modelo orientado-objetovezes, implementado na formaabstratos": a "programao-objeto".</p><p>, muitasde "tiposorientada-</p><p>267</p><p>Nenhum destes modelos de aplicaodistribuda especializado para uma classede aplicaes dada, mesmo se alguns somelhor adaptados a determinadas classes (porexemplo, transaes para os sistemas deb&amp;ses de dados distribudas). No entanto,nenhum destes modelos reconhecido comosuficientemente geral p~ra ser adotado comomodelo de referncia para servir de base construo de aplicaes distribudasintegradas (no sentido dado no item I).Contudo, esta a ambio do projeto ANSA(ANSA, 1987). Paralela~ente, a Comisso dasComunidades Europias organiza um grupo detrabalho, dirigido por Hubert Zimmermann,encarregadv de definir um "modelo dereferncia do processamento distribudo"(Distributed Processing Reference Model:DPRM) , que deveria ser,o ao nvel dasaplicaes, o equivalente do OSI~RM aonvel das comunicaes.</p><p>3.3. Sistemas Operacionais Distribudos</p><p>Os sistemas operacionais distribudosvisam fornecer ao projetista de aplicaomecanismos que .~he permitam a realizaoeficaz dos modelos de ap~icao. Estesmecanismos podem ser mais ou menosevoludos.</p></li><li><p>o primeiro (tambm o mais antigo e omais simples) destes mecanismos atransferncia de mensagens entre osprocessos de aplicao utilizando primitivas</p><p>tais como SEND e RECEIVE, sncronas ou no,com ou sem difuso. De fato, trata-se de ummecanismo de base sobre o qual pode-seconstruir todos os outros mecanismos.Numerosos sistemas fornecem um servio destenvel: CHORUS (Zimmermann et alii, 1984),CONIC (Kramer et alii, 1983), Amoeba(Mullender, 1985), Accent (Fitzgerald &amp;Rashid, 1986), V-Kernel (Cheriton, 1984),</p><p>Mach-1 (Rashid, 1986), etc. Uma extensodestes mecanismos de passagem de mensagem constitudo pelos fluxos, generalizao dos</p><p>"pipes" do UNIX.</p><p>Um mecanismo mais evoludo (mesmo queeste ponto seja asperamente discutido pelospartidrios dos sistemas a passagem demensagens) fornecido pela chamada de</p><p>procedimento remoto (RPC: "remote procedurecall"): isto consiste em fornecer uma</p><p>interface idntica chamada de procedimentoclssico, seja a execuo local ou remota.A execuo do RPC bloqueante (sncrona)at o retorno do procedimento. O esquema deexecuo ) consequentemente, simples, poisretoma o esquema clssico de execuosequencial. Alguns projetos tornam "atmica"a execuo de procedimentos remotos,permitindo deste modo a construo simplesde aplicaes tolerantes a faltas (projetos:CONCORDIA do programa ESPRIT, GOTHIC(Banatre et alii, 1986b), ARGUS (Liskov,</p><p>1985)) ou a construo de transaes.Outras extenses do RPC consistem em torn-lo "no-bloqueante" (RSR: "remote servicerequest" do projeto DELTA-4 (Bonn et alii,1986)) para aumentar o paralelismo, ou apermitir as comunicaes de m chamantes a nchamados ("multi-functions" (Banatre etalii, 1986b)).</p><p>Outros sistemas operacionaisdistribudos implementam diretamente osmodelos orientados-objeto e as operaescorrespondentes da linguagem que os suporta(CLOUDS (Le Blanc &amp; Wilkes, 1985), SOMIW(Shapiro, 1986)).</p><p>4. QUALIDADES EXIGIDAS PARA OS SISTEMASOPERACIONAIS DISTRIBUDOS</p><p>4.1. Transparncia da Distribuio</p><p>268</p><p>O programador de uma aplicaodistribuda deseja geralmente no ter que</p><p>gerar o endereamento das entidades quemanipula: ele designa essas entidades por um</p><p>~, cabendo ao sistema operacional oencargo de associar um endereo ao nomeconhecido da aplicao. Isto no exclui que</p><p>certas entidades (sensores, atuadores,perifricos, servidores especializados,etc.) sejam localizadas em estaespr-definidas. Mas isto permite que certaspartes da aplicao possam ser executadas</p><p>em estaes no pr-definidas, ou ainda,migrar de uma estao a outra em curso deexecuo, seja aps uma falha(reconfigurao), seja para melhorar o</p><p>desempenho (repartio de carga) (Theimer etalii, 1985). Assim possvel chamar pelomesmo nome um conjunto de recursos ou "poolde servidores", com o sistema operacionalescolhendo neste pool o servidor menoscarregado ou o mais prximo do cliente.Este o caso nos projetos "CambridgeDistributed Computing System" (Needham &amp;Hebert, 1982), Amoeba (Mullender, 1985),SATURNE (Deswarte et alii, 1986a).</p><p>Em certos casos, o sistema operacionalfornecer aplicao uma interfaceidntica de um sistema centralizado. Istopode ser obtido gerando uma memria virtualou um espao de endereamento nico sobretoda a rede (sistema Domain d'Apo110 (Leachet a1ii, 1983)), ou um...</p></li></ul>