O ambiente Cliente/Servidor

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

Sistema distribuído Grupo de computadores - Suporte de comunicação - Recursos compartilhados C1 C3 C2 rede recursos

Relações entre entidades Peer-to-peer (não hierárquico) Filtros Cliente/servidor A A’ cooperação B C A dados S C resposta pedido

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

Middleware Infra-estrutura para: Presente no cliente E no servidor 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

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

Características dos sistemas C/S Contrato entre cliente e servidor Encapsulamento do serviço Comportamento assimétrico Transparência de localização Independência de plataforma Interações por mensagens Escalabilidade horizontal e vertical

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

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

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

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

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)

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

Sistemas cliente/servidor típicos Cálculo Arquivos Impressão E-mail DHCP FTP Segurança WWW News Groupware Bootp DNS Específicos

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 !

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

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, ...

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 GUI Lógica Dados Thin client Fat server Fat client Thin server

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

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

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 Banco de dados corporativo Banco de dados local Cliente Servidores de bcos de dados Servidores de aplicação Cliente t

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

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

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

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

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)

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)

O problema se repete quando caixas-postais enchem 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

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

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.

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.

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

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.

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

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

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.

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.

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.

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.

Funcionamento de Sockets

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.

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)

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.

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, ...

Primitivas Socket para TCP/IP

Comunicação por streams (fluxos) Modelo bastante comum e fácil de usar 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.

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.

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).

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).