O ambiente Cliente/Servidor. 2 Sistema centralizado Computador central (mainframe) - Conjunto de...
Transcript of O ambiente Cliente/Servidor. 2 Sistema centralizado Computador central (mainframe) - Conjunto de...
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).