O ambienteCliente/Servidor

2

Sistema centralizado

• Computador central (mainframe)- Conjunto de terminais- Recursos centralizados

mainframe

recursos

terminais

3

Sistema distribuído

• Grupo de computadores- Suporte de comunicação- Recursos compartilhados

C1 C3C2

rede

recursos

4

Relações entre entidades

• Peer-to-peer(não hierárquico)

• Filtros

• Cliente/servidor

A A’cooperação

B CAdadosdados

SCresposta

pedido

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

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

Arquitetura cliente/servidor

Cliente Serv. A

pedidoresposta

Serv. B

Middleware Middleware

Suporte de comunicação

Máquina BMáquina A

Usuário

8

Características dos sistemas C/S

• ContratoContrato entre cliente e servidor

• EncapsulamentoEncapsulamento do serviço

• Comportamento assimétricoassimétrico

• TransparênciaTransparência de localização

• IndependênciaIndependência de plataforma

• Interações por mensagensmensagens

• EscalabilidadeEscalabilidade horizontal e vertical

9

Vantagens dos sistemas C/S

Melhor relaçãoMelhor relação preço/desempenho preço/desempenho equipamentos mais baratos

Maior facilidade de expansãoexpansão expansão incremental dos serviços

É possível adotar soluçõessoluções abertasabertas integrar soluções de diferentes fabricantes

10

Desvantagens dos sistemas C/S

Software maisSoftware mais complexo complexo é preciso quebrar a aplicação em partes

Problemas de saturaçãosaturação dada rederede Maior dependência do meio de comunicação interações devem ser bem projetadas

Aspectos de segurançasegurança mais críticos dados confidenciais circulam na rede necessidade de criptografia

11

Sistemas cliente/servidor típicos

• Servidores de arquivos/impressão

cliente

cliente

Acessos a arquivos

servidorJobs de impressão

12

Sistemas cliente/servidor típicos

• Servidores de bancos de dados

cliente

cliente

Chamadas SQLservidor

DBMS

13

Sistemas cliente/servidor típicos

• Servidor de cálculo

terminal (comandos)

Servidor de cálculo

Cliente gráfico

Cliente de cálculoServidor gráfico

X-Protocol (saída gráfica)

14

Sistemas cliente/servidor típicos

• Servidores de WWW

HTTP

servidorHTMLHTML

HTML

CGI

aplicação

cliente

Java

cliente

HTML

15

Sistemas cliente/servidor típicos

cliente

Específicos

WWW

DHCP

DNS

News

E-mailArquivos Impressão

FTPSegurança

Cálculo

Bootp

Groupware

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

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

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

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

20

Clientes gordos ou magros ?

Cliente

Servidor

GUI

Lógica

Dados

GUI

Lógica

Dados

Arquivos

Bancos de dados

Transações

WWW

21

Gordos X Magros

• ClienteCliente gordogordo:• menos processamento para o servidor• possivelmente mais tráfego na rede• cliente é mais sensível a mudanças

• ClienteCliente magromagro:• mais processamento no servidor• menos tráfego na rede• manutenção mais simples

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:

Servidorescorporativos

Servidoresdepartamentais

PCs

Servidores debcos de dados

Servidoresde aplicação

Cliente

Banco de dadoscorporativo

Banco de dadoslocal

Cliente

t

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

clienteclienteservidor de aplicação

servidor de aplicação servidor de

dados Bservidor de

dados B

servidor de dados A

servidor de dados A

24

WWW: uma arquit 3-tiers típica

HTTPWWWserver

RDBMSOODBMS

OLTP

Groupware

browserHTML docs

CGI

CGI

CGI

client application data

Comunicação em Sistemas Distribuídos

Prof. Agnaldo L Martins

Aplicações

RMI, RPC, CORBA, WEBSERVICES

REPRESENTAÇÃO DOS DADOS

Sistema operacional

Middleware

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

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

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

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.

33

Chamadas Remotas de Procedimentos (RPC)

● Permite ao programador projetar um programaconvencional que solucione o problema, e entãodividir o programa em procedimentos quepodem ser executadas em vários computadores.

● Uma mensagem enviada por um cliente a umservidor corresponde a uma "chamada" de umprocedimento remoto, e uma resposta doservidor ao cliente corresponde a um "retorno"de uma chamada de procedimento.

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

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

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

Falhas em RPC

1. Cliente não consegue localizar o servidor2. Mensagem de requisição do cliente para oservidor é perdida3. Mensagem de resposta do servidor para ocliente é perdida4. O servidor falha após receber a requisição5. 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.

42

Funcionamento de Sockets

Os sistemas de operação suportam a comunicação de dados entre osdiferentes computadores envolvidos num sistema distribuído

Interfaces geralmente de baixo nívelOs protocolos mais populares são os protocolos TCP/IP que oferecem osseguintes 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 transmitidoscomo 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 Pemite m1, m2, … então Q recebe m1, m2, ...

47

Primitivas Socket para TCP/IP

Comunicação por streams (fluxos)

Modelo bastante comum e fácil de usar.

Concorrência: permite concorrência porque bloqueia o emissor seexistirem problemas com buffers. Trata-se, no essencial, de uma relaçãoassíncrona do emissor com o receptor do tipo produtor / consumidor

Sincronização: o receptor sabe que os dados foram produzidos antes deserem consumidos e o emissor sabe que os dados só podem serconsumidos no futuro.

Ordenação: geralmente garante a ordem das mensagens do mesmoemissor. (mesmo que houver perdas)

Modelo de falhas: o emissor não sabe quando é que o receptor vaireceber os dados. Em caso de falha o emissor não sabe que dados oreceptor recebeu exatamente. O processo que usa o canal não sabe se afalha é no canal ou no outro processo.

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

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

Suporte para Mídia ContínuaFluxo 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).