Cliente/Servidor Desenvolvimento de Sistemas Graça Bressan Graça Bressan/LARC 2000 1
Desenvolvimento de Sistemas Cliente/Servidor As metodologias clássicas, tradicional ou orientada a objeto, são aplicáveis desde que observadas as necessidades específicas de ambientes cliente/servidor. Consideremos as seguintes etapas do ciclo de vida do projeto: Análise Projeto Implementação Teste Manutenção Análise de Sistemas Cliente/Servidor De entrevistas com o cliente e sessões JAD (Joint Application Development) devem ser definidos os documentos com os requisitos do sistema. Analisar as aplicações existentes, para verificar necessidades de integração com sistemas legados, e o compromisso com as plataformas a serem preservadas. Projeto de Sistemas Cliente/Servidor A partir dos requisitos do sistema devem ser definidas as tecnologias a serem utilizadas, a lógica de apresentação (GUI), distribuição da aplicação entre cliente e servidor e a distribuição dos dados. Considerações no Projeto de Sistemas Cliente/Servidor Definição dos padrões a serem utilizados. Definição do hardware, software, tecnologia de comunicação e dos protocolos de rede que serão utilizados. Particionamento funcional da aplicação cliente/servidor, isto é, definir quanta lógica será colocada no cliente e no servidor. Como será feita a interação entre cliente e servidor: mecanismos de comunicação entre cliente e servidor. Para isto deve ser definida um protocolo de aplicação entre cliente e servidor. Definir a distribuição de dados lembrando que os dados devem ficar próximos ao local onde serão utilizados na maioria das vezes para Graça Bressan/LARC 2000 2
minimizar as transferências e melhorar o tempo de resposta. Qual a segurança e políticas de acesso necessárias. Como será feito o tratamento e recuperação de erros. Considerar sempre o caso em que a comunicação é interrompida. O processamento deve ser síncrono ou assíncrono. Implementação de Sistemas Cliente/Servidor Definir as metodologias e ferramentas a serem utilizadas. Pode ser utilizada a programação convencional ou orientada a objetos. A escolha da linguagem de programação deve levar em conta as flexibilidades e facilidades de implementação em múltiplas plataformas. Deve ser feita a escolha das bibliotecas de classes que são particularmente úteis na implementação das GUIs e OOUIs da comunicação entre cliente e servidor. Testes de Sistemas Cliente/Servidor Os testes consistem em verificar se o sistema funciona corretamente segundo o que foi definido pelos requisitos do projeto Os testes em geral são conduzidos em duas etapas: Testes isolados Testes integrados. Testes Isolados de Sistemas Cliente/Servidor Do lado cliente pode ser testada a interface com o usuário e simulada a comunicação com o servidor. Do lado servidor podem ser exercitados os diversos serviços implementados através de simulação de requisições de clientes. Testes Integrados de Sistemas Cliente/Servidor Verificar o funcionamento em caso normal e na presença de erros. Deve ser dada atenção aos casos de falha de comunicação. Verificar o desempenho do sistema quanto a tempo de resposta e ao volume (vazão) de requisições processadas por unidade de tempo. Considerar os casos de carga normal e nos limites de carga (baixa e alta). Graça Bressan/LARC 2000 3
Verificar a segurança do sistema. Verificar a qualidade do projeto: código, manuais, Help, documentação Manutenção de Sistemas Cliente/Servidor Correção de problemas resultantes de falha de implementação ou situações não previstas nos requisitos. Mudanças de configuração de parâmetros do sistema necessárias à melhoria do desempenho em razão de mudanças da carga. Adaptações necessárias para compensar alterações nas configurações de hardware, software ou rede. O ambiente cliente é o mais sujeito a mudanças tais como atualização de versão do sistema operacional. Solicitações dos usuários por novas funcionalidades. TCP/IP e Implementação Cliente/Servidor O TCP/IP é um protocolo que apresenta as características necessárias à programação Cliente Servidor. A programação pode ser feita através de: API de programação, tal como a de sockets, para acesso à camada de transporte. RPC que é um mecanismo de programação para chamadas de procedimentos remotos. Modelo em Camadas do TCP/IP Simplificado Graça Bressan/LARC 2000 4
TCP/IP e Implementação Cliente/Servidor Exemplo: TFTP ( Trivial File Transfer Protocol ) Esta aplicação permite a um usuário em um sistema enviar e receber arquivos de outro sistema. Esta aplicação faz parte do conjunto TCP/IP. Exemplo de Cliente/Servidor Modelo Cliente/Servidor e Projeto de Software Terminologia e conceitos Cliente é um programa que inicia a comunicação com o servidor, envia uma solicitação e espera por uma resposta do servidor. Servidor é um programa que espera por solicitações de clientes efetua o processamento necessário e retorna o resultado ao cliente. Graça Bressan/LARC 2000 5
Servidores precisam acessar recursos que são protegidos pelo sistema operacional. Por esta razão precisam de privilégios especiais do sistema. Servidores devem atender às solicitações concorrentemente, assim como se responsabilizar prlos privilégios, o que os tornam mais complicados de implementar. Arquiteturas de Servidores Quanto a conexão Sem conexão Orientado a conexão Quanto a conexão Stateless - sem estado Statefull - com estado Quanto a concorrência Iterativos concorrentes Quanto a conexão Sem conexão Se o cliente e o servidor se comunicarem usando o protocolo UDP. Orientado a conexão Se o cliente e o servidor se comunicarem usando o protocolo TCP (circuito virtual). TCP - fornece uma comunicação confiável e com conexão. UDP - não garante a ordem e a entrega dos datagramas. Só deve ser usado nas seguintes situações: Em redes confiáveis tais como locais, Quando a aplicação tolerar a perda de datagramas (envio de voz ou imagens). Quando o programa cuidar da confiabilidade, Para fazer "broadcast" ou "multicast", Graça Bressan/LARC 2000 6
Se a aplicação não tolerar o "overhead" do circuito virtual. Quanto a conexão Servidor stateless (sem estado) Que não mantém qualquer informação de estado das interações com clientes. São mais tolerantes a ocorrências de erros de transmissão ou falhas em clientes. Deve ser projetado de forma que o servidor forneça sempre a mesma resposta para a mesma solicitação não importando o número de vezes (transações idempotentes). Por exemplo, cada mensagem de um cliente que solicita uma operação sobre um arquivo ao servidor de arquivos deve especificar sempre o nome do arquivo, a posição do byte no arquivo e o número de bytes. Exemplo de servidor stateless: servidor de arquivo NFS da SUN. Servidores statefull(com estado) Quando mantém alguma informação de estado das interações com clientes. São mais eficientes pois podem realizar otimizações dependentes do estado. São mais vulneráveis a falhas pois a informação de estado no servidor pode ficar incorreta se a mensagem for perdida, duplicada, estiver fora de ordem ou se o computador do cliente parar e reinicializar. Exemplos de servidores statefull: a maioria dos servidores de arquivos (Netware, Windows NT, DFS do DCE). Exemplo de servidor de arquivos "statefull" Quando o cliente abre um arquivo, o servidor monta uma tabela do tipo: Descritor de nome Arquivo Posição Corrente 1 A 0 2 B 456 3 C 38 e envia um descritor de arquivo para o cliente. O cliente usa o descritor para as operações de escrita. Se a mensagem do cliente for perdida ou duplicada, ou se o computador do cliente cair o servidor ficará com informações desatualizadas. Graça Bressan/LARC 2000 7
Quanto a concorrência Servidor iterativo É uma implementação de servidor que processa uma solicitação por vez. Um servidor iterativo é o mais fácil de projetar, programar, depurar e modificar. Servidor concorrente É uma implementação de servidor que processa muitas solicitações ao mesmo tempo. É implementado através de processos concorrentes. Se o servidor efetua uma quantidade de processamento pequeno comparado com a quantidade de E/S, é possível implementar o servidor concorrente com um único processo usando E/S assíncrona. Quando usar cada tipo de servidor Iterativo vs Concorrente : Servidores iterativos são mais fáceis de projetar, implementar e manter. Servidores concorrentes são mais rápidos Deve-se usar implementação iterativa se o tempo de processamento de solicitações for suficientemente rápido para a aplicação. Concorrência real vs aparente : Deve-se usar a solução de um único processo se o servidor precisar compartilhar ou trocar dados entre conexões. Deve-se usar a solução multi-processo se cada escravo puder operar isoladamente ou se a máquina for multiprocessadora. Orientado a conexão vs sem conexão : Deve-se usar transporte sem conexão somente se a aplicação cuidar da confiabilidade ou se os clientes acessarem seus servidores dentro de uma rede local com baixa perda e sem reordenação de pacotes. Deve-se usar transporte orientado a conexão sempre que um cliente for separado do servidor por uma WAN. Nunca se deve mover uma aplicação cliente/servidor sem conexão para um ambiente WAN sem verificar antes se o protocolo de aplicação cuida do problema de confiabilidade. Fim do módulo Desenvolvimento de Sistemas Graça Bressan/LARC 2000 8