A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

O ambiente Cliente/Servidor. 2 Sistema centralizado Computador central (mainframe) - Conjunto de terminais - Recursos centralizados mainframe recursos.

Apresentações semelhantes


Apresentação em tema: "O ambiente Cliente/Servidor. 2 Sistema centralizado Computador central (mainframe) - Conjunto de terminais - Recursos centralizados mainframe recursos."— Transcrição da apresentação:

1 O ambiente Cliente/Servidor

2 2 Sistema centralizado Computador central (mainframe) - Conjunto de terminais - Recursos centralizados mainframe recursos terminais

3 3 Sistema distribuído Grupo de computadores - Suporte de comunicação - Recursos compartilhados C1C3C2 rede recursos

4 4 Relações entre entidades Peer-to-peer (não hierárquico) Filtros Cliente/servidor AA cooperação BCA dados SC resposta pedido

5 5 O paradigma cliente/servidor O servidorO servidor: –oferece um serviço aos clientes –passivo: responde aos pedidos dos clientes –efetua um processamento específico O cliente:O cliente: –ativo: submete pedidos ao servidor –implementa a interface com o usuário O serviço:O serviço: –constitui o contrato entre as partes

6 6 Middleware Infra-estrutura para: –Execução (sistema operacional) –Comunicação (protocolos) –Gerenciamento (ferramentas de suporte) Presente no cliente E no servidor Baseado em padrões abertos Estruturado em camadas

7 7 Arquitetura cliente/servidor ClienteServ. A pedido resposta Serv. B Middleware Suporte de comunicação Máquina BMáquina A Usuário

8 8 Características dos sistemas C/S ContratoContrato entre cliente e servidor EncapsulamentoEncapsulamento do serviço assimétricoComportamento assimétrico TransparênciaTransparência de localização IndependênciaIndependência de plataforma mensagensInterações por mensagens EscalabilidadeEscalabilidade horizontal e vertical

9 9 Vantagens dos sistemas C/S Melhor relação preço/desempenho Melhor relação preço/desempenho equipamentos mais baratos expansão Maior facilidade de expansão expansão incremental dos serviços soluções abertas É possível adotar soluções abertas integrar soluções de diferentes fabricantes

10 10 Desvantagens dos sistemas C/S Software mais complexo Software mais complexo é preciso quebrar a aplicação em partes saturação da rede Problemas de saturação da rede Maior dependência do meio de comunicação interações devem ser bem projetadas segurança Aspectos de segurança mais críticos dados confidenciais circulam na rede necessidade de criptografia

11 11 Sistemas cliente/servidor típicos Servidores de arquivos/impressão cliente Acessos a arquivos servidor Jobs de impressão

12 12 Sistemas cliente/servidor típicos Servidores de bancos de dados cliente Chamadas SQL servidor DBMS

13 13 Sistemas cliente/servidor típicos Servidor de cálculo terminal (comandos) Servidor de cálculo Cliente gráfico Cliente de cálculo Servidor gráfico X-Protocol (saída gráfica)

14 14 Sistemas cliente/servidor típicos Servidores de WWW HTTP servidor HTML CGI aplicação cliente Java cliente HTML

15 15 Sistemas cliente/servidor típicos cliente EspecíficosWWWDHCPDNSNews ArquivosImpressãoFTPSegurançaCálculoBootpGroupware

16 16 Características do cliente Estreita relação com o usuário Pode acessar diversos servidores Interface gráfica usual ou a objetos Sistema operacional leve e flexível Win XP-Vista, OS/2, MacOS, JavaOS,... Browser Web e o Telnet: os clientes universais !

17 17 Características do servidor Processamento especializado Pode servir clientes simultâneos controle de concorrência Sistema operacional robusto Unix, Windows Server/2k,... Mainframe + protocolos abertos Servidores replicados Versatilidade em comunicação Atender clientes com vários protocolos

18 18 Características do middleware Suporte às interações entre clientes e servidores: –Protocolos de transporte: TCP/IP, NetBIOS, IPX/SPX, SNA,... –NOS - Network Operating Systems: mensagens, RPC, segurança, arquivos,... –DSM - Distributed System Management: SNMP, CMIP, NIS, SMS,... –Suporte a serviços específicos: HTTP, SMTP, ODBC,...

19 19 Clientes gordos ou magros ? Aplicação: GUI + lógica + dados Onde separar cliente e servidor ? –Fat Server : lógica no servidor –Fat client : lógica no cliente GUILógicaDados Thin clientFat server Fat clientThin server

20 20 Clientes gordos ou magros ? Cliente Servidor GUI Lógica Dados GUILógicaDados Arquivos Bancos de dados Transações WWW

21 21 Gordos X Magros ClientegordoCliente gordo: menos processamento para o servidor possivelmente mais tráfego na rede cliente é mais sensível a mudanças ClientemagroCliente magro: mais processamento no servidor menos tráfego na rede manutenção mais simples

22 22 2-Tiers X 3-Tiers 2-tiers: cliente e servidor 3-tiers: cliente, lógica e servidor Uso ambíguo ao longo do tempo: Servidores corporativos Servidores departamentais PCs Servidores de bcos de dados Servidores de aplicação Cliente Banco de dados corporativo Banco de dados local Cliente t

23 23 Arquitetura 3-tiers Separação completa:Separação completa: clientecliente : interface com o usuário aplicaçãoaplicação : lógica do negócio dadosdados : informações armazenadas cliente servidor de aplicação servidor de dados B servidor de dados A

24 24 WWW: uma arquit 3-tiers típica HTTP WWW server RDBMS OODBMS OLTP Groupware browser HTML docs CGI clientapplicationdata

25 Comunicação em Sistemas Distribuídos Prof. Agnaldo L Martins

26 Aplicações RMI, RPC, CORBA, WEBSERVICES REPRESENTAÇÃO DOS DADOS Sistema operacional Middleware

27 27 Protocolos de Camadas Como não existe memória compartilhada, toda a comunicação em SDs acontece através de troca de mensagens Qual o significado dos bits enviados? Qual a voltagem usada para sinalizar 0 e 1? Como se detecta o bit final da mensagem, ou que uma mensagem foi danificada ou perdida? A International Standards Organization (ISO) desenvolveu um modelo de referência para interconexão de sistemas abertos (OSI)

28 28 Primitivas Bloqueadas X Não-Bloqueadas Nas primitivas bloqueadas (síncronas), o processo é bloqueado enquanto uma mensagem é enviada ou recebida Nas primitivas não-bloqueadas (assíncronas), o processo é desbloqueado antes do envio da mensagem Processo continua sua execução em paralelo com o envio da mensagem (não-bloqueado) Processo que envia a mensagem não pode usar o buffer até que a mensagem seja enviada.(não- bloqueado, mas sem acesso ao buffer)

29 29 Primitivas Bufferizadas X Não-Bufferizadas Não-bufferizadas: Após várias tentativas cliente pode pensar que o servidor pifou ou endereço é inválido. Esse problema é agravado no caso do servidor estar com muitas requisições Bufferizadas: Núcleo do SO, pode armazenar mensagens temporariamente e iniciar temporizadores. Uso de caixas-postais (bufferizadas) O problema se repete quando caixas-postais enchem Emissor bloqueado até receber ACK do servidor. Caso a caixa-postal esteja cheia o emissor é suspenso pelo escalonador

30 30 Confiáveis X Não-Confiáveis Definem se o sistema garante ou não a entrega de mensagens Definir semântica de send como não- confiável. implementação de comunicação confiável é tarefa dos usuários Núcleo da máquina receptora envia ACK de volta ao núcleo da máquina emissora. Transparente para os processos

31 RPC (Remote Procedure Call) Na codificação, o procedimento remoto do cliente chama o stub cliente como qualquer outro procedimento local, e a implementação interna do stub cliente é responsável por iniciar o processo de transmissão para stub servidor, empacotando a chamada numa mensagem. Ao chegar, o stub servidor desempacota a mensagem e invoca localmente o procedimento, aguardando o retorno. Quando a chamada local retorna, o stub servidor é responsável por iniciar o processo de transmissão para o stub cliente, empacotando a resposta numa mensagem. Chegando, a resposta é desempacotada pelo stub cliente, sendo retornada localmente para o procedimento que realizou a chamada remota.

32

33 33 Chamadas Remotas de Procedimentos (RPC) Permite ao programador projetar um programa convencional que solucione o problema, e então dividir o programa em procedimentos que podem ser executadas em vários computadores. Uma mensagem enviada por um cliente a um servidor corresponde a uma "chamada" de um procedimento remoto, e uma resposta do servidor ao cliente corresponde a um "retorno" de uma chamada de procedimento.

34 34 Chamadas Remotas de Procedimentos (RPC) RPC possibilita a comunicação entre máquinas com diferentes SOs e/ou configurações de hardware, pois a mensagem transferida é escrita em uma estrutura de dados padronizada Máquina com menor capacidade de processamento pode requisitar serviços para outra mais rápida Exemplo - servidores de arquivos Permite que qualquer programador com conhecimento em programação estruturada seja capaz de desenvolver aplicações distribuídas sem grandes dificuldades

35 35 Chamadas Remotas de Procedimentos (RPC) Detalhes sobre a localização do servidor e os protocolos de transporte subjacentes são totalmente invisíveis ao programador A comunicação por RPC pode ser em chamadas locais ou remotas O objetivo da RPC é manter a transparência da execução, fazendo com que chamadas remotas se pareçam com chamadas locais Uso de um stub no cliente e no servidor, são procedimentos auxiliares, gerados pelo compilador RPC.

36 36 Chamadas Remotas de Procedimentos (RPC) 1. Procedimento cliente chama o stub do cliente (mesmo modo local ou remoto) 2. Stub do cliente monta mensagem e chama SO local 3. OS do cliente envia mensagem 4. OS remoto entrega mensagem ao stub do servidor 5. Stub do servidor desempacota parâmetros e chama o Servidor 6. Servidor executa e retorna o resultado para o stub 7. Stub do servidor empacota mensagem e chama o SÓ Local 8. SO do servidor envia mensagem para o SO do cliente 9. SO do Cliente entrega mensagem ao stub do cliente 10. Stub desempacota resultado e entrega ao cliente

37 37 Falhas em RPC 1. Cliente não consegue localizar o servidor 2. Mensagem de requisição do cliente para o servidor é perdida 3. Mensagem de resposta do servidor para o cliente é perdida 4. O servidor falha após receber a requisição 5. O cliente falha após enviar a requisição

38 RMI (RPC para Java) O RMI (Remote Method Invocation) é uma interface de programação que permite a execução de chamadas remotas em aplicações desenvolvidas em Java. É uma forma de implementar Sistemas Distribuídos em Java. A RMI provê ferramentas para que seja possível ao programador desenvolver uma aplicação sem se preocupar com detalhes de comunicação entre os diversos possíveis elementos de um sistema. A grande vantagem do RMI em relação ao RPC se dá ao fato de ser possível invocar métodos de objetos remotos e transferir objetos complexos entre estes.

39 SOAP (Padrão de RPC para webservices) SOAP (acrônimo do inglês Simple Object Access Protocol) é um protocolo para intercâmbio de mensagens entre programas de computador. SOAP é um dos protocolos usados na criação de WebServices. Geralmente servidores SOAP são implementados utilizando-se servidores HTTP pré-existentes, embora isto não seja uma restrição para funcionamento do protocolo. As mensagens SOAP são documentos XML.

40 DCOM Distributed component object model é uma tecnologia proprietária da Microsoft para criação de componentes distribuídos em computadores interligados em rede. O DCOM é uma extensão do COM (também da Microsoft) para a comunicação entre objetos em sistemas distribuídos. A tecnologia DCOM foi substituída, na plataforma de desenvolvimento.NET, pela.NET REMOTING. O DCOM pode ser utilizado na construção de aplicações em 3 camadas, de forma a centralizar as regras de negócio e processos, obter escalabilidade e facilitar a manutenção.

41 SOCKETS Especificamente em computação, um soquete pode ser usado em ligações de redes de componentes para um fim de um elo bidirecional de comunicação entre dois programas. A interface padronizada de soquetes surgiu originalmente no sistema operacional Unix BSD (Berkeley Software Distribution); portanto, eles são muitas vezes chamados de Berkeley Sockets. É também uma abstração computacional que mapeia diretamente a uma porta de transporte (TCP ou UDP) e mais um endereço de rede. Com esse conceito é possível identificar unicamente um aplicativo ou servidor na rede de comunicação IP.

42 42 Funcionamento de Sockets

43 Os sistemas de operação suportam a comunicação de dados entre os diferentes computadores envolvidos num sistema distribuído Interfaces geralmente de baixo nível Os protocolos mais populares são os protocolos TCP/IP que oferecem os seguintes modos de comunicação de base: Datagramas– comunicação por mensagens. Mensagens podem-se perder, duplicar e chegar fora de ordem. Streams– comunicação por fluxo contínuo de dados. Dados transmitidos como fluxo contínuo. Dados chegam de forma confiável a menos que o stream seja quebrado. Funcionalidades adicionais (sincronização, suporte para tratamento de falhas, segurança, heterogeneidade) devem ser implementadas pelas aplicações ou por um nível intermédio ( middleware) destinatários.

44 Comunicação por streams (fluxos) Em geral é entre dois pontos e bidirecional (full duplex). Também pode ser uni- direcional com uma origem e um ou vários destinos Comunicação por mensagens Pode assumir duas formas: - Comunicação multiponto ou comunicação em grupo (1 para N por exemplo). - Comunicação baseada no paradigma pedido / resposta Invocação de métodos/procedimentos remotos (RMI / RPC)

45 Comunicação por streams (fluxos) Sincronização entre o emissor e o receptor: Padrão de sincronização do tipo produtor / consumidor assíncrono: O emissor só fica bloqueado até o seu pedido de emissão ser considerado. O receptor fica bloqueado até ser possível consumir dados. Ou seja o receptor fica bloqueado aguardando. E o emissor só bloqueia no envio.

46 Comunicação por streams (fluxos) A dimensão (fronteira) das mensagens deve ser definida pela aplicação A ordem de emissão das mensagens é (geralmente) mantida, isto é, se P emite m1, m2, … então Q recebe m1, m2,...

47 47 Primitivas Socket para TCP/IP

48 Comunicação por streams (fluxos) Modelo bastante comum e fácil de usar. Concorrência: permite concorrência porque bloqueia o emissor se existirem problemas com buffers. Trata-se, no essencial, de uma relação assíncrona do emissor com o receptor do tipo produtor / consumidor Sincronização: o receptor sabe que os dados foram produzidos antes de serem consumidos e o emissor sabe que os dados só podem ser consumidos no futuro. Ordenação: geralmente garante a ordem das mensagens do mesmo emissor. (mesmo que houver perdas) Modelo de falhas: o emissor não sabe quando é que o receptor vai receber os dados. Em caso de falha o emissor não sabe que dados o receptor recebeu exatamente. O processo que usa o canal não sabe se a falha é no canal ou no outro processo.

49 49 Comunicação Orientada a Fluxo A temporização desempenha papel crucial. –Fluxo de áudio (mono/stereo); –Fluxo de vídeo e áudio; Fluxos de dados são, portanto, seqüências unidades de dados.

50 50 Suporte para Mídia Contínua Classificada quanto aos meios de apresentação: –Mídia contínua (de representação) – relações temporais entre diferentes itens de dados são fundamentais para interpretação correta dos dados (áudio, vídeo); –Mídia discreta (de representação) – as relações temporais não são importantes (texto, imagens estáticas, executáveis).

51 51 Suporte para Mídia Contínua Fluxo de Dados Costuma-se fazer distinção entre diferentes modos de transmissão, a fim de capturar aspectos de temporização, que é crucial para fluxos contínuos de dados: –Assíncrono – sem restrição de temporização; –Síncrono – definido atraso máximo fim-a-fim; –Isócrono – as unidades devem ser transferidas em um tempo certo, sendo definidos um valor máximo e um valor mínimo (serão considerados os fluxos, neste capítulo, deste último caso). Também são separados fluxos simples (1 subfluxo) de fluxos complexos (vários).


Carregar ppt "O ambiente Cliente/Servidor. 2 Sistema centralizado Computador central (mainframe) - Conjunto de terminais - Recursos centralizados mainframe recursos."

Apresentações semelhantes


Anúncios Google