5
 2Resumo cap. 2 – Arquitetura (Livro Sistemas Distribuídos princípios e paradigmas) A organizaço de sistemas distribuídos trata! em grande parte! dos componentes de so"t#are que constituem o sistema. $ssas arquiteturas de so"t#ar e nos dizem como os v%rios componentes de so"t#are devem ser organizados e como devem interagir. A rea&izaço e"etiva de um sistema distribuído imp&ica que especi'quemos e co&oquemos componentes de so"t#are em m%quinas reais. ara "azer isso! % di"erentes opç*es. A especi'caço 'na& de uma arquitetura de so"t#are + tamb+m denominada arquitetura de sistema.  , amb+m pode se conseguir a adaptabi&idade em sistemas dis tribuídos "azendo o sistema monitorar seu pr-prio comportamento e tomar as providncias adequadas quando necess%rio. $sse modo de ver as coisas resu&tou em uma c&asse que agora denominada sistemas auton/micos. $sses sistema distribuídos so "requentemente organizados sob a "orma de rea&imentaç*es de contato que "ormam um importante e&emento arquitet/nico durante o pro0eto de um sistema. 2.1 $sti&os Arquitet/nicos esti&o arquitet/nico + "ormu&ado em termos de componentes! do modo como esses componentes esto conectados uns aos outros! dos dados trocados entre componentes e! por 'm! da maneira como esses e&ementos so con'gurados em con0unto para "ormar um sistema. 3m componente + uma unidade modu&ar com inter"aces requeridas e "ornecidas bem de'nidas que + substituíve& dentro de seu ambiente. 3ma questo importante sobe um componente para sistemas distribuídos + que e&e pode ser substituído! contanto que respeitemos suas inter"aces. 3m conceito um pouco mais di"íci& de entender + o de um conector que! em gera&! + descrito como um mecanismo que serve de mediador da comunicaço ou da cooperaço entre componentes. 3sando componentes e conectores! podemos cegar a v%rias con'guraç*es que! por sua vez! "oram c&assi'cadas em esti&o arquitet/nicos. At+ agora 0% "oram identi'cados v%rios esti&os! os mais importantes sero citados a seguir. esti&o de arquitetura em camadas + simp&es! os componentes so organizados em camadas! e um componente na camada L4i tem permisso de camar componentes na camada sub0acente L4(i51)! mas no o contr%rio! L4(i51) no tem permisso de camar componentes na camada L4i. contro&e 6ui de camada para camada7 requisiç*es descem pe&a ierarquia! ao passo que resu&tados 6uem para cima.

Resumo Cap 2

Embed Size (px)

DESCRIPTION

Este texto aborda de maneira resumida as arquiteturas dos sistemas distribuídos.

Citation preview

2Resumo cap. 2 Arquitetura (Livro Sistemas Distribudos princpios e paradigmas)A organizao de sistemas distribudos trata, em grande parte, dos componentes de software que constituem o sistema. Essas arquiteturas de software nos dizem como os vrios componentes de software devem ser organizados e como devem interagir.A realizao efetiva de um sistema distribudo implica que especifiquemos e coloquemos componentes de software em mquinas reais. Para fazer isso, h diferentes opes. A especificao final de uma arquitetura de software tambm denominada arquitetura de sistema.Tambm pode se conseguir a adaptabilidade em sistemas distribudos fazendo o sistema monitorar seu prprio comportamento e tomar as providncias adequadas quando necessrio. Esse modo de ver as coisas resultou em uma classe que agora denominada sistemas autonmicos. Esses sistema distribudos so frequentemente organizados sob a forma de realimentaes de contato que formam um importante elemento arquitetnico durante o projeto de um sistema.2.1 Estilos ArquitetnicosO estilo arquitetnico formulado em termos de componentes, do modo como esses componentes esto conectados uns aos outros, dos dados trocados entre componentes e, por fim, da maneira como esses elementos so configurados em conjunto para formar um sistema. Um componente uma unidade modular com interfaces requeridas e fornecidas bem definidas que substituvel dentro de seu ambiente.Uma questo importante sobe um componente para sistemas distribudos que ele pode ser substitudo, contanto que respeitemos suas interfaces. Um conceito um pouco mais difcil de entender o de um conector que, em geral, descrito como um mecanismo que serve de mediador da comunicao ou da cooperao entre componentes.Usando componentes e conectores, podemos chegar a vrias configuraes que, por sua vez, foram classificadas em estilo arquitetnicos. At agora j foram identificados vrios estilos, os mais importantes sero citados a seguir.O estilo de arquitetura em camadas simples, os componentes so organizados em camadas, e um componente na camada L_i tem permisso de chamar componentes na camada subjacente L_(i-1), mas no o contrrio, L_(i-1) no tem permisso de chamar componentes na camada L_i. O controle flui de camada para camada: requisies descem pela hierarquia, ao passo que resultados fluem para cima.O estilo de arquitetura baseada em objetos uma arquitetura mais solta, cada objeto corresponde a um componente, e esses componentes so conectados por meio de uma chamada de procedimento. Arquiteturas de entradas em dados se desenvolvem em torno da ideia de que processos se comunicam por meio de um repositrio comum (passivo ou ativo). Em arquiteturas baseadas em eventos, os processos se comunicam, em essncia, por meio da propagao de eventos que, opcionalmente, tambm transportam dados. A ideia bsica que processos publiquem eventos aps os quais o middleware assegura que somente os processos que se subscreveram para esses eventos os recebero. A principal vantagem de sistemas baseados em eventos que os processos so fracamente acoplados.2.2 Arquiteturas de sistemasDecidir a respeito de componentes de software, sua interao e sua colocao leva a um exemplo de uma arquitetura de software tambm denominada arquitetura de sistema.2.2.1 Arquiteturas centralizadasApesar da falta de consenso sobre muitas questes de sistemas distribudos, h uma delas com a qual muitos pesquisadores e praticantes concordam: pensar em termos de clientes que requisitam servios de servidores nos ajuda a entender e gerenciar a complexidade de sistemas distribudos.No modelo cliente-servidor bsico, processos em um sistema distribudo so divididos em dois grupos, com possvel sobreposio. Um servidor um processo que implementa um servio especifico. Um cliente um processo que requisita um servio de um servidor enviando-lhe uma requisio e, na sequncia, esperando pela resposta do servidor.Considerando que muitas aplicaes cliente-servidor visam a dar suporte ao acesso de usurios a banco de dados, muitas pessoas defendem uma distino entre os trs nveis, nvel de interface de usurio, nvel de processamento e nvel de dados. Em essncia o estilo arquitetnico em camadas.O nvel de interface de usurio contm tudo que necessrio para fazer interface diretamente com o usurio, como gerenciamento de exibio. O nvel de processamento normalmente contm as aplicaes. O nvel de dados gerencia os dados propriamente ditos sobre os quais est sendo executada alguma ao.A distino entre trs nveis lgicos, sugere vrias possibilidades para a distribuio fsica de uma aplicao cliente-servidor por vrias mquinas. A organizao mais simples ter s dois tipos de mquinas:Uma mquina cliente que contm apenas os programas que implementam o nvel de interface de usurio.Uma mquina do servidor que contm o resto, ou seja, os programas que implementam o nvel de processamento e de dados.Nessa organizao, tudo manipulado pelo servidor, ao passo que, em essncia, o cliente nada mais do que um terminal burro, possivelmente com uma interface grfica bonitinha.2.2.2 Arquiteturas descentralizadasArquiteturas cliente-servidor multidivididas so uma consequncia direta da diviso de aplicaes em uma interface de usurio em componentes de processamento e em um nvel de dados. As diferentes divises correspondem diretamente organizao lgica das aplicaes. Em muitos ambientes de negcios, processamento distribudo equivale a organizar uma aplicao cliente-servidor como uma arquitetura multidivididas. Esse tipo de distribuio denominada distribuio vertical. O aspecto caracterstico da distribuio vertical que ela obtida ao se colocar componentes logicamente diferentes em mquinas diferentes.Na distribuio horizontal um cliente ou servidor pode ser fisicamente subdividido em partes logicamente equivalentes, mas cada parte est operando em sua prpria poro do conjunto completo de dados, o que equilibra a carga.Em uma arquitetura peer-to-peer estruturada, a rede de sobreposio construda com a utilizao de um procedimento determinstico. O procedimento mais usado , de longe organizar os processos por meio de uma tabela de hash distribuda.O ponto crucial de todo sistema baseado em DHT implementar um esquema eficiente e determinstico que mapeie exclusivamente a chave de um item de dado para o identificador de um n tendo como base somente alguma distncia mtrica. O mais importante que, ao consultar um item de dado, o endereo de rede do n responsvel por aquele item de dado retornado.Sistemas peer-to-peer no estruturados dependem, em grande parte, de algoritmos aleatrios para construir uma rede de sobreposio. A ideia principal que cada n mantenha uma lista de vizinhos, mas que essa lista seja construda de modo mais ou menos aleatrio. Da mesma maneira, admite-se que itens de dados sejam colocados aleatoriamente em ns. Por consequncia, quando um n precisa localizar um item de dado especfico, a nica coisa que ele efetivamente pode fazer inundar a rede com uma consulta de busca.Pode parecer que sistemas peer-to-peer estruturados e no estruturados formem classes estritamente independentes, na verdade pode no ser esse o caso. Uma observao fundamental que ao trocar e selecionar cuidadosamente as entradas de vises parciais, possvel construir e manter topologias especificas de redes de sobreposio.Localizar itens de dados relevantes em sistemas peer-to-peer no estruturados pode se tornar problemtico medida que a rede cresce. Muitos sistemas peer-to-peer propuseram a utilizao de ns especiais que mantenham um ndice de itens de dados. Esses ns em geral so chamados superpares. 2.2.3 Arquiteturas hbridasUma classe importante de sistemas distribudos organizada segundo uma arquitetura hbrida formada por sistemas de servidor de borda. Usurios finais, ou clientes em geral, se conectam com a Internet por meio de um servidor de borda. A principal finalidade do servidor de borda servir contedo, possivelmente aps ter aplicado funes de filtragem e transcodificao. Mais interessante o fato de que um conjunto de servidores de borda pode ser usado para otimizar distribuio de contedo e de aplicao.Estruturas hibridas so disponibilizadas notavelmente em sistemas distribudos colaborativos. A questo principal em muitos desses sistemas conseguir dar a partida, para o que muitas vezes disponibilizado um esquema cliente-servidor tradicional. To logo um n se junte ao sistema, ele pode usar um esquema totalmente descentralizado para colaborao. A ideia bsica que, quando um usurio final estiver procurando um arquivo, ele transfira pores do arquivo de outros usurios at que as pores transferidas possam ser montadas em conjunto, resultando no arquivo completo.2.3 Arquitetura versus MiddlewareMoldar o middleware de acordo com um estilo arquitetnico especifico tem como beneficio a simplificao do projeto de aplicaes. Contudo, uma bvia desvantagem que o middleware pode no ser mais o ideal para aquilo que um desenvolvedor de aplicao tinha em mente. Uma abordagem em geral considerada melhor fazer sistemas de middleware de modo que sejam simples de configurar, adaptar e personalizar conforme necessrio para uma aplicao.Um interceptador nada mais do que um constructo de software que interromper o fluxo de controle usual e permitir que seja executado um outro cdigo. Fazer com que interceptores sejam genricos pode exigir esforo substancial de implementao.2.3.2 Abordagens gerais para o software adaptativoO que os interceptadores realmente oferecem um meio de adaptar o middleware. A necessidade de adaptao resulta do fato de que o ambiente no qual as aplicaes distribudas so executadas est sempre mudando. Em vez de fazer com que as aplicaes sejam responsveis por reagir mudanas, essa tarefa colocada no middleware.2.3.3 DiscussoArquiteturas de software para sistemas distribudos, encontradas consideravelmente como middleware, so volumosas e complexas. Em grande parte, tal volume e complexidadesurgem da necessidade de ser geral no sentido de que preciso proporcionar transparncia de distribuio. Ao mesmo tempo, aplicaes tm requisitos extrafuncionais especficos que conflitam com a meta de conseguir totalmente essa transparncia. Esses requisitos conflitantes para generalidade e especializao resultaram em solues de middleware de alta flexibilidade.2.4 Autogerenciamento em sistemas distribudosSistemas distribudos e em especial seu middleware associado precisam fornecer solues gerais de blindagem contra aspectos indesejveis inerentes a redes, de modo que possam suportar o maior nmero possvel de aplicaes. Por outro lado, a total transparncia de distribuio no algo que, na verdade, a maioria das aplicaes quer, o que resulta em solues especficas de aplicao que tambm precisam ser suportadas. Quando a adaptao precisa ser automtica, observamos um forte intercmbio entre arquiteturas e sistemas de software.2.4.1 O modelo de realimentao de controleH muitas vises diferentes sobre sistemas autogerenciadores, mas o que a maioria deles tem em comum, explicita ou implicitamente, a premissa de que as adaptaes ocorrem por meio de um ou mais laos de realimentao de controle. De acordo com esse fato, sistemas organizados por meio desses laos so denominados sistemas de realimentao de controle. O ncleo de um sistema de realimentao de controle formado pelos componentes que precisam ser gerenciados.