sdII- franca

FACULDADE DE INFORMTICA LEMOS DE CASTROAutorizada pelo Parecer no. 423/99 de 18/05/1999 e homologado pela Portaria Ministerial no. 947 de 22/06/1999

Nome da Disciplina (CD) COMPUTAO DISTRIBUDA

Perodo 7o

Carga Horria 120

Notas de Aula v4 Janeiro de 2012

Professor M. Frana [email protected] http://www.franca.pro.br/profFILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 1

Esta pgina foi deixada propositadamente em branco.

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 2

O AutorMarcelo Frana tcnico em Processamento de Dados, tecnlogo em Processamento de Dados, analista de sistemas ps-graduado pela PUC-Rio, bacharel em Administrao de Sistemas de Informao, licenciado em Informtica pelo Instituto Superior de Educao do Rio de Janeiro ISERJ, mestre em Informtica pela Universidade Federal do Estado do Rio de Janeiro UNIRIO, aluno do MBA em gerenciamento de projetos da Fundao Getlio Vargas, certificado MCAD pela Microsoft, certificado SCJA pela Sun, certificado RAD Associate pela IBM, certificado OCJP 6 (SCJP) pela Oracle, professor de Informtica da FAETEC e da Faculdade de Informtica Lemos de Castro, e especialista de sistemas da IBM Brasil. Estuda Informtica desde 1990 e trabalha com Informtica desde 1994.

DedicatriaDedico este trabalho a todos os meus alunos e ex-alunos. Desejo a todos vocs muito sucesso profissional. Que seus objetivos sejam alcanados e que vocs sempre perseverem, mantendo o foco!

AgradecimentosAgradeo ao Professor Walter Henrique pelo voto de confiana, e por ter me aberto as portas da FILC. Obrigado, professor!




ndiceAula 1 Aspectos Estratgicos da Computao Distribuda ....................................... 9 Introduo....................................................................................................... 9 Sistema Distribudo........................................................................................... 9 Histrico .......................................................................................................... 9 Tecnologias ................................................................................................... 10 Padres para Aplicaes .................................................................................. 11 EAI Enterprise Application Integration ou Integrao de Aplicaes Corporativas . 12 Enterprise Architecture .................................................................................... 12 A Profisso de Arquiteto .................................................................................. 13 Outras Questes............................................................................................. 14 Exerccios ...................................................................................................... 14 Aula 2 Middlewares ......................................................................................... 15 Introduo..................................................................................................... 15 Middleware .................................................................................................... 15 Taxonomia..................................................................................................... 16 Stubs vs. Skeletons ........................................................................................ 16 Queue VS. Topic ............................................................................................. 18 Servidores de Aplicao................................................................................... 19 Outras Questes............................................................................................. 19 Exerccios ...................................................................................................... 19 Aula 3 Objetos Distribudos (Java IDL) [ESTUDO DIRIGIDO] ................................ 21 Introduo..................................................................................................... 21 Serializao e RMI ............................................................................................. 26 Serializao e Persistncia ............................................................................... 26 Introduo ao RMI .......................................................................................... 27 Outras Questes............................................................................................. 29 Exerccios ...................................................................................................... 29 Aula 4 Balanceamento de Carga ....................................................................... 31 Introduo..................................................................................................... 31 Recursos ....................................................................................................... 31 Taxonomia..................................................................................................... 32 Polticas de Escalonamento .............................................................................. 33 Outras Questes............................................................................................. 34 Exerccios ...................................................................................................... 35 Aula 5 Algoritmos Distribudos .......................................................................... 37 Introduo..................................................................................................... 37FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 5

Breve Histrico .............................................................................................. 37 Caractersticas dos Sistemas Distribudos .......................................................... 38 Computao Concorrente ................................................................................ 39 Comunicao ................................................................................................. 39 Taxonomia .................................................................................................... 40 Caractersticas ............................................................................................... 41 Outras Questes ............................................................................................ 41 Exerccios ...................................................................................................... 42 Aula 6 Banco de Dados Distribudos .................................................................. 45 Introduo .................................................................................................... 45 Consideraes Importantes ............................................................................. 45 Vantagens de bancos de dados distribudos ....................................................... 45 Desvantagens de banco de dados distribudos ................................................... 46 Arquitetura de um banco de dados distribudos em Oracle ................................... 47 Transaes Distribudas .................................................................................. 49 Outras Questes ............................................................................................ 52 Exerccios ...................................................................................................... 52 Aula 7 Tolerncia a Falhas em Ambiente Distribudo ........................................... 55 Introduo .................................................................................................... 55 Mitigar Riscos ................................................................................................ 55 Soluo ........................................................................................................ 56 Outras Questes ............................................................................................ 57 Exerccios ...................................................................................................... 58 Aula 8 Segurana em Ambientes Distribudos ..................................................... 59 Cenrio-Exemplo............................................................................................ 59 Sub-net Masking ............................................................................................ 59 Motivao ..................................................................................................... 59 Desafios ........................................................................................................ 59 Conceitos Bsicos........................................................................................... 60 Cuidados ....................................................................................................... 60 Ataque (Taxonomia):...................................................................................... 61 Polticas de Segurana .................................................................................... 61 Criptografia ................................................................................................... 62 Concluso ..................................................................................................... 64 Outras Questes ............................................................................................ 64 Exerccios ...................................................................................................... 65 Aula 9 Computao em Grade .......................................................................... 67FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 6

Histrico ........................................................................................................ 67 Internet/Web Como Plataforma ........................................................................ 68 Tecnologias ................................................................................................... 68 Concluso ...................................................................................................... 69 Outras Questes............................................................................................. 70 Exerccios ...................................................................................................... 71 Aula 10 Anlise de Desempenho de SD [ESTUDO DIRIGIDO] ............................... 73 Introduo..................................................................................................... 73 Benchmark .................................................................................................... 75 Outras Questes............................................................................................. 76 Exerccios ...................................................................................................... 76 Aula 11 Componentes para Computao Distribuda ............................................ 77 Introduo..................................................................................................... 77 Componentes Distribudos ............................................................................... 77 Desenvolvimento Orientado a Componentes ...................................................... 78 Padres para Empacotamento e Distribuio ...................................................... 78 Outras Questes............................................................................................. 79 Exerccios ...................................................................................................... 79 Aula 12 Microsoft .NET Remoting ...................................................................... 81 Introduo..................................................................................................... 81 DCOM ........................................................................................................... 81 .NET Remoting ............................................................................................... 81 .NET Framework ............................................................................................. 81 Diferenas entre o Microsoft .NET Remoting e o DCOM ........................................ 82 Outras Questes............................................................................................. 83 Exerccios ...................................................................................................... 83 Bibliografia/Crditos .......................................................................................... 85 Apndice A Questionrio de Avaliao do Curso .................................................. 87




Aula 1 Aspectos Estratgicos da Computao DistribudaIntroduoEstratgia competitiva o conjunto de planos, polticas, programas e aes desenvolvidos por uma empresa ou unidade de negcios para ampliar ou manter, de modo sustentvel, suas vantagens competitivas (inclui oferecer valor agregado) frente aos concorrentes. Para Ohmae (1983), ... Sem competidores no haveria necessidade de estratgia, pois o nico propsito do planejamento estratgico tornar a empresa apta a ganhar, to eficientemente quanto possvel, uma vantagem sustentvel sobre seus concorrentes. .... Para Porter (1985), A estratgia competitiva visa estabelecer uma posio lucrativa e sustentvel contra as foras que determinam a competio industrial. A informtica (TI) suporte para a estratgia corporativa (sistemas de informao versus cincia da computao). Implementar sistemas distribudos (SD) uma forma de se operacionalizar este suporte.

Sistema DistribudoDefinio de um SD: vrios computadores, interconectados por uma rede, compartilhando um estado. Comunicao por mensagem (sncronas ou assncronas) entre os componentes. Exemplos de SD: Internet, Web, DNS, Multiprocessador, Cluster, Grid. Cenrios favorveis distribuio (motivao): problema distribudo (groupware), escalabilidade (horizontal) e confiabilidade (dependability) so caractersticas desejveis. Caractersticas de um SD: [heterogeneidade,] modularidade, escalabilidade,

compartilhamento de recursos, degradao paulatina, mais sujeito a ataques (maior rea), custo menor (ao longo do tempo)[, controle distribudo]. Valores agregados com a distribuio: redundncia (suporte a falhas, disponibilidade), flexibilidade, manutenibilidade (crescimento modular), integrao de servios. Entretanto, o custo com gerncia tende a aumentar - TCO.

HistricoHistrico dos sistemas distribudos: 1. acesso remoto (terminais/mainframes) 2. distribuio de arquivos e memria (workstations) 3. servidores de arquivo (fator custo) 4. arquitetura cliente-servidor (downsizing) 5. cliente servidor em trs camadas (thin client/www) 6. arquitetura peer-to-peer (P2P) 7. computao ubqua (pervasive computing) faculdade, trabalho, praia, etc.. Impulsionadores da evoluo das arquiteturas: avanos tecnolgicos e mudanas nos requisitos definidos pelos usurios.FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 9

Processos de Negcio: Representam as atividades relacionadas a negcios do dia-a-dia de uma empresa. Centralizados ou distribudos em mltiplos sites (carros so projetados em um lugar, montados em muitos lugares e comercializados em diversos outros lugares). Anos 60, 70 e 80: Processos de Negcios Centralizados. Sistemas de Informao centralizados (CPD). Processamento centralizado. Poder dos negcios centralizado. Aplicaes centralizadas. Indstria dos computadores guiada mais pela tecnologia do que pelas necessidades dos usurios. Vendedores so controladores do mercado. Mercado de massa. Tempo longo para firmar presena no mercado. Tempo longo entre concepo e entrega. Anos 90: Novo Ambiente de Negcios. Demanda cada vez mais sofisticada. Maior nmero de concorrentes. Concorrncia acirrada. Necessidades de respostas rpidas (ondemand): novos produtos e novos servios. Os vendedores j no mais controlam o mercado. Clientes que mandam: tratamento individualizado (Amazon.com); Informam o que desejam, como desejam e quanto pagaro (eBay, MercadoLivre); Produtos configurados (personalizados, customizados Fiat.com.br); Cronogramas de entrega; Prazos de

pagamentos mais convenientes. Organizaes novatas no obedecem s definem as regras (copyright & Internet).

regras, elas

Disperso dos Sistemas de Informaes. Disperso dos negcios (Internet). Disperso do poder de processamento. Disperso das aplicaes. Diminuio dos sistemas proprietrios (crescimento do Open Source e Padres Abertos xml, webservices). Departamentos adquirem recursos computacionais (fim do CPD). Globalizao. Para atender a estas exigncias: Interao e cooperao crescentes entre grupos de trabalhos e departamentos nas empresas (Intranet), assim como entre empresas (Extranet). Mudanas organizacionais (culturais) drsticas. Groupware. Reengenharia Empresarial: Mudanas maiores nas prprias estruturas organizacionais: Reengenharia Empresarial: O repensar fundamental e a reestruturao radical dos processos empresariais, objetivando alcanar drsticas melhorias em indicadores crticos e

contemporneos de nveis de desempenho: custos, qualidade, atendimento e rapidez. Para satisfazer a estes e outros desafios competitivos, empresas esto crescendo contando com as Tecnologias da Informao (TI). Negcios esto sendo fundamentalmente transformados atravs das Tecnologias da Informao.

TecnologiasRPC, Middleware (integrar a empresa, programa de computador que faz a mediao entre outros softwares) Orientados a Mensagem, OSF DCE (industry-standard, vendor-neutral set of distributed computing technologies), Middleware de Dados Distribudos (gateways SQL, ODBC, JDBC), Middleware de Processamento de Transaes, Cliente/Servidor, Servios de rede (sockets TCP/IP), Servidores de Replicao, Groupware, Multimdia, WWW (gateways,


servidores e browsers), Objetos Distribudos (CORBA, OLE, OpenDoc, Microsoft .NET Remoting), Middleware para Computao Mvel. Tecnologia da Informao, com as funcionalidades oferecidas pela Computao Distribuda, adequa-se perfeitamente como fornecedora de solues para as organizaes que buscam os modelos adotados pela Reengenharia. Sistemas Proprietrios (Hardware + Software): Muitas empresas fornecedoras de sistemas de computadores consideravam seu diferencial de competitividade baseado em tecnologias proprietrias. Portabilidade de aplicaes era quase impossvel. Preos

exagerados, gerando grandes lucros para os fornecedores. Sistemas Abertos: Com o advento de microprocessador (Anos 80), os fabricantes viram seu poder comear a ser contestado. Grupos de interesse: Grupo de Desenvolvedores de Software, Grupos de Usurios, Grupo dos Fabricantes de Hardware. Exigncia: padres para os produtos de Tecnologia da Informao. Os sistemas abertos formam um conjunto compreensivo de padres internacionais para a Tecnologia da Informao, que especificam interfaces, servios e suporte a formatos que possam atender interoperabilidade e portabilidade de aplicaes, dados (xml) e pessoas. Uma metodologia para a integrao de tecnologias divergentes, permitindo que se crie um ambiente flexvel para resolver os problemas de negcios de uma organizao, atravs do uso de software e hardware abertos, isto no proprietrios. A fora de sustentao dos sistemas abertos a independncia de fornecedores. rgos de Padronizao: OMG, W3C, ANSI (American National Standards Institute), ISO (International Organization for Standardization), IEEE (Institute of Eletrical and Eletronic Engineers), JIS (Japanese Institute for Standards), ABNT (Brasil).

Padres para AplicaesAPI (Interface de Programao de Aplicaes). O que posso fazer com essa aplicao? Estensibilidade. Permitir que um mesmo sistema operacional suporte diversos conjuntos de interfaces, no sentido de que as aplicaes possam ser executadas em qualquer sistema operacional que suporte esse conjunto de interfaces. Aplicaes escritas para um ambiente de sistema operacional podem rodar em outros sistemas operacionais, porque existe uma API para o desenvolvedor comum aos dois sistemas operacionais (c/c++, Java). A Computao Distribuda fornece toda a infraestrutura necessria para a construo e operao efetiva de aplicaes distribudas e engloba todos os produtos necessrios para permitir que essas aplicaes sejam construdas e possam ser executadas em um ambiente de rede heterogneo, ou em um ambiente centralizado. A infra-estrutura para a Computao Distribuda (CD) no precisa basear-se, obrigatoriamente, em sistemas abertos. Podem ser suportados elementos abertos ou proprietrios. Porm, medida que a complexidade e o nmero de aplicaes construdas emFILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 11

uma plataforma de CD forem crescendo, ento diferentes ambientes operacionais e plataformas de HW vo estar presentes. Nestas circunstncias, prudente o uso de interfaces o mais abertas possveis.

EAI Enterprise Application Integration ou Integrao de Aplicaes CorporativasCom o objetivo de conter custos durante as mudanas de negcios, as indstrias de tecnologia freqentemente necessitam integrar suas aplicaes com sistemas legados sob diferentes plataformas. Esta necessidade tem criado uma rea de atuao atualmente conhecida como mercado de integrao de aplicaes. O termo EAI ou Enterprise Application Integration novo, mas sugere toda essa integrao. , ainda, o termo formal que contempla a integrao de aplicaes corporativas e de um conjunto de ferramentas e tecnologias. A dependncia das corporaes em relao tecnologia tem crescido e se tornado mais complexa. Por isso, a integrao de aplicaes em um nico arsenal de processos de negcios tem se tornado prioridade para o sucesso de uma empresa. No contexto de EAI, uma figura de destaque o broker, ncleo das integraes. O Broker fica no centro das integraes fazendo o roteamento das mensagens para os seus destinatrios. Tambm faz a verificao das regras de negcio e transformaes necessrias. O objetivo substituir integraes ponto a ponto, principalmente reutilizando mensagens. A sada nica, indo para o broker, que transforma e roteia a mensagem.

Enterprise ArchitectureAn enterprise architecture (EA) is a rigorous description of the structure of an enterprise, which comprises enterprise components (business entities), the externally visible properties of those components, and the relationships (e.g. the behavior) between them. "Enterprise" as used in enterprise architecture generally means more than the information systems employed by an organization. The popular TOGAF framework divides the practice into three domains: "Business Architecture", "Information Systems Architecture" and "Technology Architecture" and then subdivides the information systems architecture into "Information Architecture and

"Applications Architecture". Describing the architecture of an enterprise aims primarily to improve the effectiveness or efficiency of the business itself. This includes innovations in the structure of an organization, the centralization or federation of business processes, the quality and timeliness of business information, or ensuring that money spent on information technology (IT) can be justified.


A Profisso de Arquiteto

Arquitetos definem arquitetam solues para problemas de negcios de clientes atravs da aplicao fundamentada da Tecnologia; Essas solues podem incluir sistemas e/ou processos e geralmente envolvem a aplicao ou integrao de uma variedade de produtos, tecnologias e servios; Caractersticas gerais de um arquiteto incluem: Experincia no ciclo de vida completo de solues; Amplo conhecimento de tecnologia; Experincia em diversos casos; Bom comunicador; Liderana tcnica; Usa metodologias formais; Produz arquiteturas de valor;

A demanda por arquitetos est aumentando. Mais detalhes em http://www.slideshare.net/msavio/slideshowsFILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 13

Outras Questes Carreira (Punto VS. MBA) No ser um profissional bit/byte (estar antenado ao negcio da empresa). Que tal R$ 5.000 (CLT) em uma grande empresa? P, no d... Que perfil esse? (Especialista em Middleware/Integrao) Viso estratgica de TI (maximizar lucros, reduzir custos, sempre estamos empregados). Engenharia de Produo (Analista de Negcios) Clusterizao versus Virtualizao (Mainframes Z10/ZOS) custo Oracle por processador.

Exerccios1. O que so sistemas distribudos, e como eles podem ajudar na estratgia competitiva de uma empresa? 2. Cite caractersticas encontradas em sistemas distribudos. 3. O que dependability? 4. O que Groupware? 5. Relacione Sistemas Proprietrio e Sistemas Abertos com o histrico da tecnologia da informao. 6. O que uma API? Qual a relao desse conceito com o sucesso (aceitao) da tecnologia Java? 7. Quais os dois entendimentos mais comuns para o termo EAI? 8. No contexto de EAI, defina Broker. 9. Relacione padres de mercado, solues de TI e TCO. 10.O que faz um arquiteto (de integrao)?


Aula 2 MiddlewaresIntroduoSistema distribudo (SD): coleo de componentes, distribudos entre vrios computadores conectados via uma rede. Esses componentes interagem a fim de trocar dados ou acessar os servios uns dos outros. Essa interao pode ser construda diretamente atravs das APIs do sistema operacional extremamente complexo para muitos

desenvolvedores. Em vez disso

suporte de Sistemas de Middleware: localizados entre

componentes do SD e componentes do sistema operacional; sua tarefa facilitar as interaes entre esses componentes.

MiddlewareCamada de software que permite a comunicao entre aplicaes (distribudas); Um conjunto de servios que fornece comunicao e distribuio de forma transparente aplicao: Middleware permite que processos em diferentes espaos de endereamento consigam se comunicar. Objetivo: Facilitar o desenvolvimento de aplicaes e a integrao de sistemas legados (adaptadores) ou desenvolvidos de forma no integrada (transparncia). Ajudam a gerenciar a complexidade e a heterogeneidade inerentes ao desenvolvimento de aplicaes e sistemas distribudos; Mascara a heterogeneidade com que os programadores de aplicaes distribudas tm que lidar: Rede & hardware; Sistemas operacionais & linguagem de programao; Localizao, acesso, falhas, concorrncia; Diferentes plataformas de middleware. Middleware deve fornecer: Facilidade de Uso - Middleware deve ser mais fcil de usar do que escrever uma interface de comunicao de baixo nvel usando sockets; Transparncia de Localizao - Deve ser possvel mover uma aplicao para um endereo de rede diferente sem a necessidade de recompilar qualquer software (diminuir o acoplamento/DNS); Transparncia de Linguagem (e plataforma) - Um processo usando o middleware deve ser capaz de se comunicar com um processo que foi escrito em uma linguagem diferente. Servios Oferecidos: Infra-estrutura: Encapsulam e melhoram os mecanismos de concorrncia e comunicao nativos do sistema operacional. Ex. estabelecimento de conexo, sincronizao, (un) marshalling (serializao). Ex.: RPC, ACE (Adaptive

Communication Environment) abstraem as peculiaridades dos SOs. Distribuio, remotabilidade: Permitem a integrao de aplicaes remotas de forma transparente. Exemplo: Brokers CORBA, RMI, SOAP. Definem modelos de programao que permitem a construo de aplicaes distribudas, onde a comunicao abstrada.FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 15

Comuns: Servios independentes do domnio de aplicao que fazem uso da infra-estrutura de distribuio/comunicao. Ex. segurana, transao.

Especficos, outros: Diretamente relacionados a domnios especficos. Exemplo de domnios: telecomunicaes (URAs, CTI), comrcio eletrnico, automao, sade, computao mvel.

Principais Plataformas de Middleware Existentes: CORBA da OMG, JEE da Sun/Oracle, COM, COM+, DCOM da Microsoft, .NET Remoting da Microsoft (hoje, WCF), Web

Services/SOA. Denominaes Equivalentes: Modelos de Integrao de Objetos, Plataformas de Distribuio de Objetos.

TaxonomiaProcedure Oriented Middleware (RPC Remote Procedure Call): Chamadas Remotas de Procedimentos. uma chamada de procedimento que cruza as fronteiras dos componentes locais (hosts). Idia bsica: no que concerne ao processo cliente, no h diferena lgica entre chamar um procedimento local ou um remoto. Uma chamada remota de procedimento usa comunicao direta, orientada a conexo e sncrona para permitir a um processo cliente chamar um procedimento remoto. Paradigma criado pela Sun como parte de sua plataforma Open Network Computing (ONC). Servios: comunicao sncrona (request/wait-for-reply). Vrios problemas devem ser tratados pelo programador. Exemplo: Falhas na comunicao.

Stubs vs. Skeletons

Dado (marshalling)

.--...

(unmarshalling) Dado

In the distributed computing environment, stub stands for client side object participating in the distributed object communication. The stub acts as a gateway (design pattern PROXY) for client side objects and all outgoing requests to server side objects that are routed through it. The stub wraps client object functionality and by adding the network logic ensures the reliable communication channel between client and server. In the distributed computing environment skeleton stands for server side object participating in the distributed object communication. Skeleton acts as gateway for serverFILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 16

side objects and all incoming clients requests are routed through it. The skeleton wraps server object functionality and exposes it to the clients, moreover by adding the network logic ensures the reliable communication channel between clients and server. Para fazer uma RPC: O processo cliente chama o stub do cliente como se fosse um procedimento local. O stub do cliente converte os parmetros em uma string de bits (marshalling) e envia os bits na rede para o skeleton do servidor. O skeleton do servidor converte os bits de volta para parmetros (unmarshalling) e chama o procedimento no servidor. O skeleton do servidor converte a resposta do procedimento em uma string de bits e envia pela rede para o stub do cliente. O stub do cliente converte os bits para a resposta e a retorna para o procedimento chamador. Middleware Orientado a Transao: Conhecidos como Monitores de Processamento de Transaes (transaction-processing - TP). Chamada de procedimento remoto + controle de transaes. Principais Servios: Comunicao sncrona/assncrona, Transao, Outros

Servios: Segurana e integridade de dados, Tuning, Balanceamento de carga, Entrega confivel dos dados, Servios de nomes - facilitam a descoberta de recursos distribudos. Usado em aplicaes que demandam rapidez na execuo de transaes remotas. Frequentemente usado com aplicaes de bancos de dados distribudos. Tipicamente, os monitores de TP no so usados para comunicao aplicao-aplicao. Mas, fornecem um ambiente completo para aplicaes de transaes que acessam bancos relacionais. Exemplo: BEA Tuxedo. Construdo sobre uma arquitetura orientada a servios (Service Oriented Architecture - SOA). Sua plataforma para processamento de transaes fornece a infra-estrutura necessria para: consolidar solues para aumentar a acessibilidade e passagem de de aplicaes existentes; a maior

transaes

mensagens;

garantir

disponibilidade e o maior throughput possvel de aplicaes; aumentar a eficincia de processamento e melhorar a gerncia de recursos. Middleware Orientado a Mensagem (Message Oriented Middleware MOM): o mais usado, mais comum. Comunicao atravs de passagem de mensagens; Tecnologia


inerentemente assncrona, e com fraco acoplamento; Filas de mensagens implementam um link de comunicao indireto, sem conexo e assncrono entre dois ou mais processos; Um gerente de filas rodando em um servidor separado gerencia as filas e garante que no importa o que ocorra na rede, apenas uma cpia da mensagem eventualmente chega ao seu destino; Deve-se notar que embora a comunicao de processo para processo seja assncrona, a comunicao entre um processo e o gerente de fila em geral implementada usando um link de comunicao direto e sncrono; Isso significa que se a rede cair ou se o gerente cair, um processo no pode incluir mensagens em uma fila ou obter mensagens da mesma. Filas (queue) so independentes de um processo. Ento, muitos processos podem incluir, ou obter (retirando ou no as mensagens da fila) mensagens de uma mesma fila. Um processo pode tambm acessar mltiplas filas; Se a rede ou um destino cair, as mensagens podem esperar na fila at a falha se resolver; Filas podem ser armazenadas em disco de forma que se o gerente de filas cair, a fila no perdida; O gerente de filas pode cooperar com um gerente de transaes; se uma transao iniciada e uma mensagem colocada em uma fila durante a transao a qual mais tarde abortada, ento no somente o BD tem que sofrer roll back, mas a mensagem tambm removida da fila e no enviada.

Queue VS. Topic-On-line, multi-cast. Principais Servios: comunicao assncrona, priorizao de mensagens, segurana, suporte a Multicasting (delivery of information to a group of destinations simultaneously using the most efficient strategy to deliver the messages over each link of the network only once, creating copies only when the links to the multiple destinations split), MOM usado quando comunicao assncrona e confivel a forma dominante de interao do sistema distribudo: no assume um transporte confivel. Exemplo de Produtos: MQSeries da IBM (hoje, IBM WebSphere MQ), MSMQ da Microsoft, Tuxedo/Q (WebLogic) da BEA Systems, Java Message Service - JMS (Sun), WebMethods Broker (costumava vir com o SAP). Middleware Baseado em Objetos (Object Oriented Middleware): evoluiu mais ou menos diretamente da idia de RPC. Usado para chamar uma operao (implementada por um mtodo) em uma instncia de objeto (instanciada a partir de uma classe) que reside em outro processo. A idia aqui tornar os princpios orientados a objetos disponveis para o desenvolvimento de sistemas distribudos, ou seja, distribuio + OO = Objetos Distribudos. O primeiro desses sistemas foi o OMG Common Object Request Broker Architecture (CORBA). Microsoft adicionou capacidades de distribuio a seu Component Object Model (COM DCOM). Sun forneceu mecanismos para Invocao Remota de Mtodos Remote

Method Invocation (RMI).FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 18

Servidores de AplicaoGlassFish, MS IIS, JBoss, IBM WAS. Principais Vantagens do middleware OO sobre o middleware RPC: Mais flexvel, Naturalmente integrado com linguagens OO. Exemplos de Tecnologias: Java Remote Method Invokation (RMI) e EJB (Sun), Common Object Request Broker (CORBA), Distributed Component Object Model (DCOM), Microsoft .NET Remoting (usado com o Microsoft COM+). Middleware para Web: WebServices, HTTP (padro), ubiqidade (at videogame acessa http), XML (padro), codificao dos dados, SOAP (padro), comunicao (RPC), executa sobre o http, WSDL Web Service Definition Language (padro): o que, onde, como, UDDI Universal Description Discovery and Integration (padro): Descoberta e negociao.

WebServices agem como uma interface para acessar os servios providos por outros middleware.

Outras Questes Arquitetura SOA: In computing, service-oriented architecture (SOA) provides methods for systems development and integration where systems group functionality around business processes and package these as interoperable services. An SOA infrastructure allows different applications to exchange data with one another as they participate in business processes. Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. Arquitetura Enterprise Service Bus: In computing, an enterprise service bus (ESB) refers to a software architecture construct. This construct is typically implemented by technologies found in a category of middleware infrastructure products, usually based on recognized standards, which provide fundamental services for complex architectures via an event-driven and standards-based messaging engine (the bus). Software Microsoft BizTalk Server: often referred to as simply "BizTalk", is a business process management (BPM) server. Through the use of "adapters" which are tailored to communicate with different software systems used in a large enterprise, it enables companies to automate and integrate business processes. Offered by Microsoft, it provides the following functions: Business Process Automation, Business Process Modeling, Business-to-business

Communication, Enterprise Application Integration and Message broker. JBoss Enterprise Middleware - http://www.jboss.com/products

Exerccios1. O que so Middlewares, e quais seus objetivos? 2. Explique o conceito de transparncia no contexto de middlewares.FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 19

3. Explique a arquitetura de um MOM? 4. O que Cloud Computing? 5. O que SOA? 6. O que ESB? 7. Relacione stub e skeleton. 8. Precisa-se integrar uma aplicao legada que usa um banco proprietrio (ZIM). Como proceder? 9. Ao tentar implementar RMI, detectou-se um problema de conexo (socket) por conta de um firewall. Como proceder? 10.Justifique por que filas promovem o baixo acoplamento entre aplicaes?


Aula 3 Objetos Distribudos (Java IDL) [ESTUDO DIRIGIDO]IntroduoRPC Remote procedure call: Este termo utilizado para aplicativos clientes que fazem normalmente chamadas a procedimentos remotos que esto em outro processo e hosts. RPC objetiva permitir chamada de procedimento remoto como se fosse local, ocultando entrada/sada de mensagens. RMI Remote method invocation: O modelo baseado orientado a objeto utiliza este termo para definir uma chamada local a um mtodo em um objeto remoto. Interface Definition Languages IDL (padro/interoperabilidade): Permite criar uma notao universal para interface de mtodos e variveis para serem utilizados entre diversas linguagens de programao. Marshalling: Linearizao (serializao) de uma coleo de itens de dados estruturados (com exceo dos atributos transientes/java). Traduo dos dados em formato externo (bits). Unmarshalling: Traduo do formato externo para o local. Restaurao dos itens de dados de acordo com sua estrutura. Programao distribuda em Java: Entre os atrativos de Java est a facilidade que essa linguagem oferece para desenvolver aplicaes para execuo em sistemas distribudos. J em sua primeira verso, Java oferecia facilidades para o desenvolvimento de aplicaes cliente-servidor usando os mecanismos da Internet, tais como os protocolos TCP/IP e UDP. Se o cliente na aplicao distribuda precisa acessar um servidor de banco de dados relacional, Java oferece uma API especfica para tal fim, JDBC. Atravs das classes e interfaces desse pacote possvel realizar consultas expressas em SQL a um servidor de banco de dados e manipular as tabelas obtidas como resultado dessas consultas. Em termos de desenvolvimento voltado para a World-Wide Web, Java oferece o j clssico mecanismo de applets, cdigo Java que executa em uma mquina virtual no lado do cliente (tipicamente um navegador) Web. O mecanismo de servlets permite associar o potencial de processamento da plataforma Java a servidores Web, permitindo construir assim aplicaes com arquitetura de distribuio de trs camadas baseadas no protocolo HTTP e em servios implementados em Java. Aplicaes distribudas mais elaboradas podem ser desenvolvidas usando uma arquitetura de objetos distribudos, onde aplicaes orientadas a objetos lidam diretamente com referncias (variveis) a objetos em processos remotos (servidores de aplicao). Java oferece duas alternativas nessa direo, RMI (Remote Method Invocation), uma soluo 100% Java, e Java IDL, esta uma soluo integrada arquitetura padro CORBA. Um passo adiante na evoluo desse tipo de sistema a utilizao do conceito de agentes mveis, onde


no apenas referncias a objetos so manipuladas remotamente mas os prprios objetos (cdigo e estado) movem-se pela rede. Outras (Java): EJB, Spring Framework

Objetos Distribudos: Na programao distribuda usando a arquitetura cliente-servidor, clientes e servidores podem ser implementados usando qualquer paradigma de programao. Assim, possvel que um servio especfico seja executado por um mtodo de algum objeto. No entanto, mesmo que o cliente tambm tenha sido desenvolvido orientao a objetos, na comunicao entre o cliente e o servidor esse paradigma deve ser esquecido, devendo ser utilizado algum protocolo pr-estabelecido de troca de mensagens para a solicitao e resposta ao servio. Um sistema de objetos distribudos aquele que permite a operao com objetos remotos. Dessa forma possvel, a partir de uma aplicao cliente orientada a objetos, obter uma referncia para um objeto que oferece o servio desejado e, atravs dessa referncia, invocar mtodos desse objeto mesmo que a instncia desse objeto esteja em uma mquina diferente daquela do objeto cliente. O conceito bsico que suporta plataformas de objetos distribudos o conceito de arquiteturas de objetos. Essencialmente, uma arquitetura orientada a objetos estabelece as regras, diretrizes e convenes definindo como as aplicaes podem se comunicar e interoperar. Dessa forma, o foco da arquitetura no em como a implementao realizada, mas sim na infra-estrutura e na interface entre os componentes da arquitetura. Na plataforma Java, dois mecanismos so oferecidos para o desenvolvimento de aplicaes usando o conceito de objetos distribudos: Java RMI e Java IDL. RMI (invocao remota de mtodos) um mecanismo para desenvolver aplicaes com objetos distribudos que opera exclusivamente com objetos Java. Java IDL utiliza a arquitetura padro CORBA para integrao de aplicaes Java a aplicaes desenvolvidas em outras linguagens. Java IDL: A API Java IDL, presente na plataforma Java 2, permite a integrao entre objetos Java e outros objetos remotos (caixa preta), eventualmente desenvolvidos em outras linguagens de programao, atravs da arquitetura CORBA. Os principais pacotes que compem essa API so org.omg.CORBA e org.omg.CosNaming. A partir da verso 1.3 da plataforma Java 2, possvel gerar interfaces IDL para classes Java usando o compilador rmic com a opo "-idl". Outra opo, "-iiop", indica que o protocolo de comunicao de CORBA, IIOP, ser utilizado em stubs e ties (correspondentes aos skeletons) de RMI. Uma vez obtida a interface IDL para um servio, as classes auxiliares para acessar o objeto remoto que implementa o servio so obtidas pela compilao da interface, usando o aplicativo idlj (ou idltojava ou ainda idl2java em verses anteriores ao Java 1.3). Alm de classes para stubs e skeletons, so geradas classes auxiliares (helpers e holders) para permitir a comunicao entre objetos Java e outras linguagens.FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 22

Na plataforma Java h uma implementao para o servio de nomes de CORBA, oferecida pelo aplicativo tnameserv. Esse servio est mapeado por default para a porta 900, podendo esta ser modificada pela opo "-ORBInitialPort". ORB o Object Request Broker, o ncleo da arquitetura CORBA. um programa que deve estar sendo executado em cada mquina envolvida em uma aplicao CORBA, sendo o responsvel pela conexo entre clientes e servios atravs dos correspondentes stubs e skeletons. A interao entre um ORB e um programa Java d-se atravs de mtodos da classe ORB. Para inicializar a referncia ao ORB, utiliza-se o mtodo esttico init() dessa classe. Para obter uma referncia para o servio de nomes utiliza-se o mtodo resolve_initial_references() tendo a NameService como argumento. Exemplo de Java IDL: Este exemplo, obtido da documentao da Sun, uma implementao em Java IDL do tradicional "hello world", composto por trs arquivos:

Interface IDL: uma interface para um servio com um nico mtodo definido usando as construes da linguagem IDL. Usando o aplicativo idl2j gera-se a interface Java correspondente, com a traduo das construes IDL para as primitivas Java segundo o padro estabelecido em CORBA, e outros arquivos auxiliares (stub, skeleton, helper, holder), no apresentados aqui. Exemplo:module HelloApp {

interface Hello { string sayHello(); }

}


Exemplo de cliente que ativa o ORB, obtm uma referncia para o servio de nomes e, a partir deste servio, obtm uma referncia remota para o objeto com o servio Hello. Obtida a referncia, o mtodo invocado normalmente.import HelloApp.*; import org.omg.CosNaming.*; import org.omg.CORBA.*;

public class HelloClient {

public static void main (String args[]) {

try { // Create ORB object ORB meuOrb = ORB.init(args,null);

// Find hello server org.omg.CORBA.Object objRef = meuOrb.resolve_initial_references("NameService");

// Narrow the reference from generic object NamingContext ncRef = NamingContextHelper.narrow(objRef);

// Find service in Naming (req. array of NameComp) NameComponent nc = new NameComponent("Hello",""); NameComponent path[] = {nc}; Hello helloRef = HelloHelper.narrow(ncRef.resolve(path));

// Invoke remote service String hi = helloRef.sayHello(); System.out.println(hi); } catch(Exception e) { System.out.println(e); e.printStackTrace(System.out); } } }


Exemplo de servidor/servio: nesse arquivo so criadas duas classes. A classe HelloServer um servidor que ativa o ORB, cria o objeto que implementa o servio, obtm uma referncia para o servio de nomes e registra o objeto neste diretrio associado ao nome Hello. A classe HelloServant uma implementao do servio especificado; observe que essa classe uma extenso de _HelloImplBase, o skeleton definido pelo aplicativo idltojava.import HelloApp.*; import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*;

public class HelloServer {

public static void main(string args[]) { try { // Create the ORB ORB orb = ORB.init(args,null);

// Instantiate the servant object HelloServant helloRef = new HelloServant();

// Connect servant to the ORB orb.connect(helloRef);

//Registering the servant org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("Hello",""); NameComponent path[] = {nc}; ncRef.rebind(path, helloRef);

// Wait for invocation java.lang.Object sync = new java.Lang.Object(); synchronized(sync) { sync.wait(); } } catch(Exception e) { System.out.println(e); e.printStackTrace(System.out); } } }

class HelloServant extends _HelloImplBase {

public String sayHello() { return "\nHelloWorld!\n"; } }


Serializao e RMISerializao e Persistncia Serializando e Persistindo Objetos o Como transferir os dados da aplicao servidora para as aplicaes clientes? o Objetos Java vivem dentro de uma JVM; necessrio que a classe desses objetos esteja carregada (Onde? Basta ser homnima?). o O processo de criar uma cpia em formato binrio dos dados de um objeto chamado serializao. o Podemos armazenar este contedo (binrio) em um arquivo (file system) ou at mesmo em um banco de dados; Os dados desse objeto so persistidos.

Definindo uma classe Serializable. o Exemplo (package java.io): package br.com.caelum; public class Livro implements Serializable { private static final long serialVersionUID = 1L; private String nome; // } o Interface de Marcao no requer, de fato, a implementao de mtodo algum - annotations. o ObjectOutputStream o responsvel por serializar os objetos. o Exemplo: Livro effectiveJava = new Livro(); FileOutputStream saidaArquivo = new FileOutputStream(effectiveJava.txt); // qualquer extenso ObjectOutputStream serializador = new ObjectOutputStream(saidaArquivo); serializador.writeObject(effectiveJava); o Exemplo (inverso): FileInputStream entradaArquivo = new FileInputStream(effectiveJava.txt); ObjectInputStream ois = new ObjectInputStream(entradaArquivo); Livro livro = (Livro) ois.readObject(); Compatibilidade (serialVersionUID) o Distribuir o arquivo .class (JARs). Serializao em Cascata o Em relacionamento do tipo has-a ambas as classes precisam implementar Serializable, seno o processo ir falhar. o Serialization lets you simply say save this object and all of its instance variables. Unless Ive explicitly marked a variable as transient.


Atributos Transientes o Oposto de persistente. o Voc no deseja que todos os atributos participem do processo de serializao. o Exemplo: public class Pessoa implements Serializable { private Calendar dataDeNascimento; private transient int idade; } o Quando for desserializado o Java coloca o valor default para esse atributo (no exemplo, 0). o private void writeObject (ObjectOutputStream os){ o private void readObject(ObjectInputStream is){ defaultWriteObject() defaultReadObject() obs.: The constructor does not run mas o da super classe no serializvel, sim.

Introduo ao RMI

Conceitos: - transparncia; - contrato (buscar no catlogo); - objeto de mentira (stub) retornado pelo catlogo/padro de projeto PROXY:

implementa a comunicao/gerado automaticamente (Proxy dinmico); - serializao (com RMI) Ateno: RMI no Java EE, Java SE. Invocao Remota de Mtodo o Como disponibilizar este servio? o No quero ser o responsvel por cdigo de infra (sockets). o aplicao cliente apenas tendo uma referncia utilizada para invocar mtodos em um objeto que est na aplicao servidora, em outra JVM. o Objeto remoto/remotabilidade.

Java RMI Remote Method Invocation o Se o objeto deve aceitar invocaes remotas ento ele funciona como se fosse um mini servidor. o O objeto de mentira (stub) do lado do cliente invoca o objeto remoto. o Para o cliente ter a impresso de estar conversando com o objeto de verdade (transparncia), o objeto de mentira tem que ter as mesmas assinaturas deFILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 27

mtodos basta criar uma interface que implementada pelas classes dos dois objetos. o Exemplo (Interface): public interface ProcuraLivro extends Remote { Livro procura (String isbn) throws RemoteException; } o Exemplo (Classe que implementa o Servio) public class ProcuraLivroService extends UnicastRemoteObject implements ProcuraLivro { //... public Livro procura (String isbn) throws RemoteException { return this.repositorio.get(isbn); } } o Quem vai criar a classe do objeto de mentira? Deixamos a mquina virtual criar a classe dinamicamente (proxy dinmico) em tempo de execuo a partir da interface remota. Colocando o Objeto no Servidor o Registrando (bind) um objeto remoto (utilizando um catlogo de objetos remotos) utilizando um apelido. o Os clientes fazem uma busca (lookup) pelo apelido do objeto desejado. O catlogo devolve as informaes necessrias para a prpria mquina virtual da aplicao cliente construir um stub que possa se conectar com o objeto remoto. o Exemplo (subindo o catlogo/na mquina Servidora): LocateRegistry.createRegistry(1099); //porta listener do catlogo o Exemplo (registrando um objeto remoto/na mquina Servidora): ProcuraLivroService buscadorDeLivro = new ProcuraLivroService(); Naming.rebind(loja/procura, buscadorDeLivro); o Exemplo (buscando um objeto remoto/na mquina Cliente): ProcuraLivro biblioteca = (ProcuraLivro) Naming.lookup(rmi://localhost:1099/loja/procura); o O servio de nomes bsico do Java chamado rmiregistry. Em produo mais comum o uso do JNDI Java Naming and Directory Interface. Quem so os servidores? o RMI uma tecnologia realmente distribuda. O servio de nomes centraliza as informaes de onde est cada objeto. Servidor de Nomes (catlogo) e Aplicao. O Cliente o Exemplo: import Java.rmi.Naming; public class ClienteLoja { public static void main (String[] args) throws Exception { ProcuraLivro biblioteca = (ProcuraLivro) Naming.lookup(rmi://localhost:1099/loja/procura); Livro livro = biblioteca.procura(1111); System.out.println(Livro: + livro.getNome()); } }


Outras Questes Design Patterns do ponto de vista do arquiteto (EJB, VO, TO) Uso de Stored Procedures (Velocidade, Camada de Indireo Adicional) Exemplo arquitetura para um sistema de carto de crdito. Outras tecnologias: Silverlight (MS), Flash/Flex, Java FX. Posso usar (outra) aplicao Java para instanciar os objetos (no servidor) e registr-los no catlogo, e me preocupar com a gesto do pool ou... Servidor de Aplicao/Middleware (IBM WAS, JBoss, etc..)

Exerccios1. Compare Java IDL com Java RMI. 2. Compare Marshaling e Unmarshaling. 3. Relacione ORB com a arquitetura CORBA.




Aula 4 Balanceamento de CargaIntroduoUm sistema distribudo constitui-se de um conjunto de processadores autnomos conectados atravs de um subsistema de comunicao, que cooperam entre si atravs da troca de mensagens. Esse tipo de sistema deve apresentar duas caractersticas inerentes: 1) a transparncia na sua utilizao, ou seja, a capacidade de apresentar-se aos seus usurios como uma entidade nica, e 2) o alto grau de tolerncia a faltas (falhas). Uma das formas de se implementar tolerncia a falhas atravs do balanceamento de carga. Balanceamento de carga: Todo o hardware tem o seu limite, e muitas vezes o mesmo servio tem que ser repartido por vrias mquinas, sob pena de se tornar congestionado. Estas solues podem-se especializar em pequenos grupos sobre os quais se faz um balanceamento de carga.

RecursosUtilizao do CPU, de armazenamento, ou de rede. Qualquer uma delas introduz o conceito de clustering, ou server farm, j que o balanceamento ser, provavelmente, feito para vrios servidores. Balanceamento de CPU: Este tipo de balanceamento efetuado pelos sistemas de processamento distribudo e consiste, basicamente, em dividir a carga total de processamento pelos vrios processadores no sistema (sejam eles locais ou remotos). Solues (software): Beowulf, openMosix, openSSI, OSCAR. Balanceamento de Carga em SD de Propsito Geral: Um sistema distribudo consiste numa coleo de computadores autnomos conectados por uma rede de comunicao. Devido a flutuaes na taxa de chegada e no tempo de servio das tarefas submetidas pelos usurios durante um certo intervalo de tempo, algumas mquinas podero estar ociosas enquanto outras estaro pesadamente carregadas. Os algoritmos de compartilhamento ou distribuio de carga tentam melhorar o desempenho deste tipo de sistema compartilhando a carga de trabalho do sistema entre as mquinas que o compem. Os algoritmos de balanceamento de carga vo alm, visando equilibrar a carga de todas as mquinas. O problema do balanceamento de carga um problema de escalonamento, que consiste em determinar qual mquina da rede ir executar uma determinada tarefa de maneira a otimizar o desempenho do sistema. Encontrar a soluo tima para este tipo de problema em geral um problema NP-Completo (os problemas tratveis tambm so comumente denominados "P"/Polinomiais, enquanto os intratveis so denominados

"NP"/No-Polinomiais). Algoritmos de balanceamento de carga podem ter sua atividade de distribuio de carga disparada pelas mquinas com pouca carga (receptoras) que tentam obter tarefas aFILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 31

partir de outras mais carregadas (remetentes), ou disparada pelas mquinas sobrecarregadas que tentam enviar tarefas quelas menos carregadas. Algoritmos que utilizam a primeira estratgia so chamados receiver-initiated e os algoritmos que utilizam a segunda estratgia sender-initiated. Nos algoritmos symmetrically-initiated, tanto as mquinas receptoras quanto as remetentes podem disparar a atividade de distribuio de carga. Estudos mostram que, em sistemas com baixa carga de trabalho, algoritmos senderinitiated tm mais sucesso em encontrar mquinas subcarregadas e em sistemas com alta carga de trabalho, algoritmos receiver-initiated tm mais sucesso em encontrar mquinas sobrecarregadas.

TaxonomiaClasses de algoritmos de balanceamento de carga: esttico versus dinmico: estas classes se diferem quanto ao momento em que as decises de escalonamento so tomadas. Nos algoritmos estticos assume-se que o nmero de tarefas e comportamento de cada tarefa conhecido quando o sistema ainda est sendo compilado; cada tarefa atribuda a um processador fixo e toda vez que uma imagem desta tarefa for instanciada, ela ser atribuda a este processador. Nos algoritmos dinmicos assume-se que se tem pouqussimo conhecimento a priori sobre as necessidades de recursos das tarefas que compem o sistema; portanto, as decises de escalonamento so tomadas somente quando o sistema est em execuo. fisicamente distribudo versus fisicamente no-distribudo: quando a

responsabilidade de tomar decises sobre o escalonamento de tarefas reside em um nico processador dizemos que este algoritmo fisicamente no-distribudo. Caso contrrio o algoritmo dito fisicamente distribudo. cooperativo versus no-cooperativo: os algoritmos onde um processador individual toma decises independentemente das aes tomadas por outros processadores so denominados no-cooperativos. Os algoritmos onde h cooperao entre os componentes distribudos so chamados cooperativos. adaptvel versus no-adaptvel: numa soluo adaptvel os algoritmos e os parmetros utilizados para implementar o escalonador podem mudar

dinamicamente de acordo com o comportamento anterior e atual do sistema em resposta s decises anteriores feitas pelo escalonador (otimizao). Alm de poderem ser divididos nestas classes, os algoritmos de balanceamento de carga podem ser sncronos ou assncronos, e preemptivos ou no-preemptivos. Algoritmos sncronos exigem que todas as mquinas do sistema estejam sincronizadas para que possam iniciar a atividade de distribuio num mesmo instante no tempo. Uma vez distribuda a carga, as mquinas sincronizam-se novamente e voltam a executar as tarefas aindaFILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 32

pendentes. Algoritmos assncronos so mais flexveis. Grupos de mquinas do sistemas podem iniciar a atividade de distribuio em momentos diferentes, no existindo a necessidade de sincronizao. Nas solues preemptivas a execuo de uma tarefa pode ser interrompida para que esta tarefa seja migrada de uma mquina para outra; em solues no preemptivas somente as tarefas que no estejam sendo executadas podem ser movidas. Algoritmos preemptivos geralmente tm um custo muito alto, uma vez que guardar o estado de uma tarefa, que pode ser muito grande ou complexo, na maior parte das vezes uma tarefa difcil.

Polticas de EscalonamentoOs algoritmos de balanceamento de carga podem ser divididos em 4 componentes: poltica de transferncia, poltica de seleo, poltica de localizao, e poltica de informao. A poltica de transferncia determina qual mquina deve iniciar a transferncia de tarefas. A poltica de localizao deve encontrar uma outra mquina que possa receber ou enviar tarefas para mquina selecionada pela poltica de transferncia. A poltica de seleo seleciona a tarefa ser transferida. A poltica de informao decide quando, a partir de onde, e quais as informaes sobre as mquinas do sistema devem ser coletadas. Uma das maneiras de se implementar estas polticas base-las em um limiar (threshold/Ferramentas Administrativas Performance Counters): toda vez que o ndice que caracteriza a carga do sistema ultrapassar este limite, uma deciso dever ser tomada de maneira a alterar o estado do sistema. A dificuldade est em encontrar o limiar que otimize o desempenho do sistema. Entretanto, existem diferentes maneiras para se implementar cada uma destas polticas e portanto, uma grande variedade de algoritmos de balanceamento de carga. Polticas adaptveis possuem maior habilidade em evitar estados de baixo

desempenho. Entretanto, como estas polticas devem coletar e reagir s informaes sobre o estado do sistema, elas so necessariamente mais complexas que polticas estticas. Uma das perguntas a serem feitas sobre estas polticas e talvez a mais importante : qual o nvel apropriado de complexidade para tais polticas? Polticas adaptveis extremamente simples, que coletam pouca informao sobre o estado do sistema e que utilizam esta informao de uma maneira simplificada, so capazes de melhorar dramaticamente o desempenho de um sistema. Alm disso, o resultado obtido com estas polticas extremamente simples so prximos queles alcanados por polticas muito complexas e que exigem muita informao sobre o estado do sistema. Exemplo: Requisitos de um Algoritmo de Balanceamento de Carga para Sistemas de Realidade Virtual Distribudos (Second Life), WOW (MMORPG). necessrio que o algoritmo de balanceamento de carga seja fisicamente distribudo, para que no insiramos um novo gargalo no sistema de realidade virtual, e assncrono, poisFILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 33

as sincronizaes dos servidores exigidas por um algoritmo sncrono impossibilitam seu uso em um sistema de tempo real como este que estudamos. O algoritmo a ser proposto tambm deve ser adaptvel, uma vez que o nmero de clientes no sistema varia com o tempo, isto , clientes podem entrar e sair do ambiente virtual a qualquer instante. Supondo um algoritmo que seja ativado quando o nmero de clientes em um servidor ultrapassar um determinado limiar (threshold), este limiar no poder ser o mesmo quando no sistema existirem 100 ou 1000 clientes. O sistema de balanceamento de carga deve ser cooperativo, para evitar que decises tomadas por um nico servidor atrapalhe o desempenho dos demais servidores. Acima de tudo, o sistema de balanceamento de carga deve possuir polticas bem simples que necessitem de informaes que possam ser facilmente colhidas, para que o balanceamento possa ser realizado de forma dinmica e em tempo real, inserindo o mnimo de sobrecarga no sistema de realidade virtual.

Outras Questes Web Farm versus Web Garden (servidor multiprocessado). Cluster (Web): Sesses no Banco versus Middleware (ip fixo). o o o o Microsoft Sharepoint / NLB (Windows Server 2003, cluster NLB) Conceito de afinidade (sticky session) Espelhamento Evita erros intermitentes, j que a sesso fica sempre na mesma mquina servidora. Seno funciona, no-funciona (problema no cliente). o o o o Criao de um novo IP para o cluster. Tabela NAT Cookies/Expirao timeout da sesso Sesso: In-proc (sticky) Out-proc DB


Exerccios1. Nos sistemas que visam atender a milhares de usurios simultaneamente, os servidores podem facilmente se tornar gargalos do sistema. Alm disso, se o sistema no for cuidadosamente planejado, ele poder ter sua escalabilidade reduzida. Uma tcnica utilizada para melhorar a escalabilidade de sistemas distribudos o balanceamento de carga entre os servidores do sistema. o Se, na sua equipe de trabalho, voc fosse o arquiteto responsvel pelo projeto/configurao do algoritmo de balanceamento de carga a ser utilizado em conjunto com o sistema de informao, quais seriam os requisitos que voc consideraria indispensveis ao algoritmo? Justifique sua resposta. o Quais problemas poderiam surgir se voc escolhesse utilizar uma poltica de transferncia baseada num limiar (threshold) fixo? Durante o projeto de um algoritmo de balanceamento de carga, natural pensarmos que utilizao de polticas de escalonamentos complexas e baseadas em informaes detalhadas mais vantajosa que a utilizao de polticas de escalonamento mais simples e baseadas em pouqussimas informaes. Qual sua opinio sobre esta questo? 2. Defina Balanceamento de Carga e o que motiva sua implementao. 3. Compare Web Farm com Web Garden. 4. Que recursos podem ser compartilhados atravs do balanceamento de carga? 5. Que consideraes precisamos ter ao escalar horizontalmente uma web application?




Aula 5 Algoritmos DistribudosIntroduoEscalabilidade: Um sistema distribudo deve permitir a expanso em termos do nmero de usurios e recursos e, mesmo assim, manter a performance relativa de atendimento a servios do usurio. A maioria dos sistemas distribudos atuais projetada para trabalhar com poucas centenas de processadores. Atualmente solues que funcionam com 200 mquinas falham miseravelmente se aplicadas a 200.000 mquinas. Exemplo de um sistema que deve possuir escalabilidade: a PTT (Post Telephone and Telegraph Administration) francesa pretendia instalar um terminal em cada residncia e ponto comercial da Frana por volta de 1995. Estes terminais seriam utilizados para acesso a base de dados de telefone (lista telefnica) e tambm como correio eletrnico, por cerca de 50 milhes de habitantes. Para implementao de um sistema distribudo deste porte deve-se evitar:

Centralizao de Componentes (arquitetura monoltica, gargalo) ter um nico servidor de correio para 50 milhes de usurio no uma boa idia; Centralizao de tabelas (orkut.com) uma nica tabela possui uma imensa vulnerabilidade a falhas; Centralizao de Algoritmos (redundncia) a falha em uma mquina arruna o algoritmo. Todas as mquinas tm que ter informao completa sobre o estado do sistema.

Breve HistricoApareceu na dcada de 60 dentro do contexto de Sistemas Operacionais. A motivao foi a criao de unidades de hardware denominadas canais ou dispositivos de controle. Estes dispositivos funcionam independente de um processador de controle e podem fazer operaes de E/S concorrentemente com a execuo de um programa. Um canal (hardware) comunica-se com o processador central atravs de uma interrupo ( exceo). Com a introduo dos canais, partes de um programa poderiam funcionar de forma imprevisvel. Logo aps o aparecimento dos canais, foram desenvolvidas as mquinas multiprocessadas. Estas mquinas permitem que aplicaes diferentes sejam executadas em processadores diferentes ao mesmo tempo. Permite tambm que uma aplicao possa ser executada mais rapidamente se puder ser reescrita de forma a utilizar mltiplos processadores. Perguntas: Como sincronizar as atividades de processos concorrentes? Como utilizar mltiplos processadores para que uma aplicao seja executada mais rapidamente? Resposta... Algoritmos Distribudos: Algoritmos que foram desenvolvidos para serem executados em muitos processadores distribudos em uma grande rea geogrfica.


Atualmente, o termo cobre

algoritmos que so executados em redes locais e em

multiprocessadores de memria compartilhada.

Caractersticas dos Sistemas Distribudos compartilhamento de recursos: um sistema distribudo deve permitir o compartilhamento eficiente de recursos fsicos e lgicos; abertura: um sistema distribudo deve pertencer classe de sistemas abertos (OPENNESS), permitindo sua estensibilidade ( fcil estender e alterar o sistema?); concorrncia: um sistema distribudo deve possuir algoritmos e tcnicas eficientes para o escalonamento de processos concorrentes (balanceamento de carga); escalabilidade: um sistema distribudo deve permitir a expanso em termos do nmero de usurios e recursos e, mesmo assim, manter a performance relativa de atendimento a servios do usurio; tolerncia a falhas: um sistema distribudo deve possuir estratgias para tolerar falhas em algum(uns) de seu(s) componente(s) e manter o provimento de servios ao usurio final; transparncia: um sistema distribudo deve ser transparente ao usurio final, ou seja, o usurio deve executar operaes remotas como se estive executando-as na sua mquina (local). Dentre estas caractersticas, iremos falar mais especificamente da concorrncia obtida atravs de algoritmos distribudos. Cenrio-Exemplo: Vrios carros desejam ir de um ponto A a um ponto B. Eles podem competir por espaos em uma mesma estrada (A) ou acabam seguindo uns aos outros ou competindo por posies. Ou poderiam andar em vias paralelas (B), desta forma chegando quase que ao mesmo tempo sem invadir a via do outro. Ou poderiam trafegar em rotas diferentes (C) usando estradas separadas.

Ou seja: (A) 1 processador (time slice), ou (B) mltiplos processadores, ou (C) processadores distribudos (clusters ou grids).

Recursos independentes (acostamento).A B C


Computao ConcorrenteExistem mltiplas tarefas a serem feitas. (carros em movimento). Cada tarefa pode ser executada: uma de cada vez em um nico processador (uma nica estrada); em paralelo em mltiplos processadores (pistas em uma estrada); ou, em processadores distribudos (estradas separadas). Como elas sero executadas? Caractersticas: Um programa concorrente contm dois ou mais processos que trabalham juntos para executar uma tarefa. Cada processo um programa seqencial. Programa seqencial nico thread de controle. Programa concorrente mltiplos threads

de controle onde thread um fio de execuo.

ComunicaoOs processos em um programa concorrente trabalham juntos comunicando-se entre si. A comunicao pode ser feita atravs de: variveis compartilhadas, troca de mensagens (loopback). Independente da forma de comunicao, os processos precisam sincronizar-se: excluso mtua (sees crticas), sincronizao condicional. Interprocess Synchronization (Windows): Multiple processes can have handles to the same event, mutex, semaphore, or timer object, so these objects can be used to accomplish interprocess synchronization. The process that creates an object can use the handle returned by the creation function (CreateEvent, CreateMutex, CreateSemaphore, or

CreateWaitableTimer). Other processes can open a handle to the object by using its name, or through inheritance or duplication. Mutex: 1 or 0 (in use, available) = usually one resource. Semaphore: available counters (pools) = a set of resources. Synchronized Methods: in JAVA, to make a method synchronized, simply add the synchronized keyword to its declaration:public class SynchronizedCounter { private int c = 0;

// synchronized = mutex public synchronized void increment() { c++; }

public synchronized void decrement() { c--; }

public synchronized int getContador() { return c; } }


Or in (Microsoft) C#.netusing System; using System.Runtime.CompilerServices; using System.Threading; class Program { public static void Main() { Sync s = new Sync(); for (int i = 1; i

sdII- franca

Documents

Transcript of sdII- franca