Cliente-Servidor
Alexsandro Oliveira, Luan Lima, Randerson Lessa
Arquitetura de Software
Agenda
● Modelo Cliente - Servidor
○ Contextualização
○ Solução
○ Vantagens
○ Desvantagens
● Quando Utilizar (Exemplo)
○ LoLNews
● Quando Não Utilizar (Exemplo)
○ Notificações
● Caso de Sucesso
○ Internet
○ SGBDs
○ Servidor de Arquivos Samba
ContextualizaçãodoModeloCliente-Servidor
Contexto : Existem recursos e serviços compartilhados que um
grande número de clientes distribuídos desejam acessar.
Deseja-se controlar esse acesso e a qualidade do serviço.
Problema : Ao gerir um conjunto de recursos e serviços
compartilhados, podemos promover manutenibilidade e reuso a
partir da fatoração de serviços. Sendo assim, queremos
melhorar a disponibilidade e escalabilidade, centralizando o
controle, enquanto os recursos e serviços são distribuídos
em um ou vários servidores.
SoluçãodoModeloCliente-Servidor
Os clientes interagem solicitando recursos e/ou serviços de
servidores, que fornecem esse conjunto de recursos e
serviços.
Os componentes podem agir como clientes ou servidores.
Pode haver um servidor central ou múltiplos servidores
distribuídos.
SoluçãodoModeloCliente-Servidor
Resumo ● Clientes iniciam interações com Servidores, por
meio da requisição de serviços quando
necessitarem e esperando a resposta dessas
requisições
Elementos ● Cliente, Servidor e Conector Requisição/Resposta
Relações ● Attachment Relation (Relação de Ligação)
Restrições ● Clientes são conectados a Servidores apenas por
regras de Requisição/Resposta
● Servidores podem ser clientes apenas de outros
Servidores
● Restrições de números de clientes por servidores
e de quantidade de serviço provido pelo servidor
Vantagens
● Integridade
● Confiabilidade
● Manutenibilidade*
● Disponibilidade*
● Escalabilidade*
● Segurança
● É possível substituir, reparar, atualizar ou
mesmo realocar um servidor sem que os
clientes sejam afetados
● Os dados são armazenados no servidor, o que
facilita a centralização da segurança
● Atualizações nos dados são mais fáceis de
administrar
● Funciona com vários clientes de capacidades
diferentes
● Gerenciamento de Performance e Taxa de
Transferência
Desvantagens
● Manutenibilidade*
● Disponibilidade*
● Escalabilidade*
● Servidor pode ser um gargalo
● O Servidor pode representar um ponto
de falha único
● Decisões de onde colocar
funcionalidades (lado cliente ou
servidor) são geralmente complexas de
mudar depois do sistema pronto
● Clientes podem solicitar serviços, mas
não podem oferecê-los para outros
clientes, sobrecarregando o servidor,
pois quanto mais clientes, mais
informações que irão demandar mais
banda
QuandoUtilizar(Exemplo):LoLNews
Exemplo de um sistema em Java EE, utilizando o tomcat como
servidor.
QuandoNãoUtilizar(Exemplo):AppcomNotificação
Exemplo de um sistema em Android, utilizando o apache2 como
servidor.
QuandoNãoUtilizar(Exemplo):AppcomNotificação
QuandoNãoUtilizar(Exemplo):AppcomNotificação
RepositóriosdoGitHub
LOLNews : https://bitbucket.org/luanchaoskk/trabalhoweb.git
Notificação : https://bitbucket.org/luanchaoskk/app-
notifica-o-arquitetura.git
CasodeSucesso:Internet
CasodeSucesso:SGBDs
CasodeSucesso:Servidor deArquivosSamba
Referências
ArchLinux, Samba. Disponível em <https://wiki.archlinux.
org/index.php/Samba>. Acesso em 5 de novembro.
DevMedia, Google Clouding Messaging : Introdução. Disponível
em <http://www.devmedia.com.br/google-cloud-messaging-
introducao/29776>. Acesso em 4 de Novembro.
SEI, Reasoning About Software Quality Attributes. Disponível
em <http://www.sei.cmu.edu/architecture/start/reasoning.
cfm>. Acesso em 5 de Novembro.
Reviewer-Herzog, J. (2015). Software Architecture in
Practice Third Edition Written by Len Bass, Paul Clements,

Arquitetura de software : Cliente-Servidor

  • 1.
    Cliente-Servidor Alexsandro Oliveira, LuanLima, Randerson Lessa Arquitetura de Software
  • 2.
    Agenda ● Modelo Cliente- Servidor ○ Contextualização ○ Solução ○ Vantagens ○ Desvantagens ● Quando Utilizar (Exemplo) ○ LoLNews ● Quando Não Utilizar (Exemplo) ○ Notificações ● Caso de Sucesso ○ Internet ○ SGBDs ○ Servidor de Arquivos Samba
  • 3.
    ContextualizaçãodoModeloCliente-Servidor Contexto : Existemrecursos e serviços compartilhados que um grande número de clientes distribuídos desejam acessar. Deseja-se controlar esse acesso e a qualidade do serviço. Problema : Ao gerir um conjunto de recursos e serviços compartilhados, podemos promover manutenibilidade e reuso a partir da fatoração de serviços. Sendo assim, queremos melhorar a disponibilidade e escalabilidade, centralizando o controle, enquanto os recursos e serviços são distribuídos em um ou vários servidores.
  • 4.
    SoluçãodoModeloCliente-Servidor Os clientes interagemsolicitando recursos e/ou serviços de servidores, que fornecem esse conjunto de recursos e serviços. Os componentes podem agir como clientes ou servidores. Pode haver um servidor central ou múltiplos servidores distribuídos.
  • 5.
    SoluçãodoModeloCliente-Servidor Resumo ● Clientesiniciam interações com Servidores, por meio da requisição de serviços quando necessitarem e esperando a resposta dessas requisições Elementos ● Cliente, Servidor e Conector Requisição/Resposta Relações ● Attachment Relation (Relação de Ligação) Restrições ● Clientes são conectados a Servidores apenas por regras de Requisição/Resposta ● Servidores podem ser clientes apenas de outros Servidores ● Restrições de números de clientes por servidores e de quantidade de serviço provido pelo servidor
  • 6.
    Vantagens ● Integridade ● Confiabilidade ●Manutenibilidade* ● Disponibilidade* ● Escalabilidade* ● Segurança ● É possível substituir, reparar, atualizar ou mesmo realocar um servidor sem que os clientes sejam afetados ● Os dados são armazenados no servidor, o que facilita a centralização da segurança ● Atualizações nos dados são mais fáceis de administrar ● Funciona com vários clientes de capacidades diferentes ● Gerenciamento de Performance e Taxa de Transferência
  • 7.
    Desvantagens ● Manutenibilidade* ● Disponibilidade* ●Escalabilidade* ● Servidor pode ser um gargalo ● O Servidor pode representar um ponto de falha único ● Decisões de onde colocar funcionalidades (lado cliente ou servidor) são geralmente complexas de mudar depois do sistema pronto ● Clientes podem solicitar serviços, mas não podem oferecê-los para outros clientes, sobrecarregando o servidor, pois quanto mais clientes, mais informações que irão demandar mais banda
  • 8.
    QuandoUtilizar(Exemplo):LoLNews Exemplo de umsistema em Java EE, utilizando o tomcat como servidor.
  • 9.
    QuandoNãoUtilizar(Exemplo):AppcomNotificação Exemplo de umsistema em Android, utilizando o apache2 como servidor.
  • 10.
  • 11.
  • 12.
    RepositóriosdoGitHub LOLNews : https://bitbucket.org/luanchaoskk/trabalhoweb.git Notificação: https://bitbucket.org/luanchaoskk/app- notifica-o-arquitetura.git
  • 13.
  • 14.
  • 15.
  • 16.
    Referências ArchLinux, Samba. Disponívelem <https://wiki.archlinux. org/index.php/Samba>. Acesso em 5 de novembro. DevMedia, Google Clouding Messaging : Introdução. Disponível em <http://www.devmedia.com.br/google-cloud-messaging- introducao/29776>. Acesso em 4 de Novembro. SEI, Reasoning About Software Quality Attributes. Disponível em <http://www.sei.cmu.edu/architecture/start/reasoning. cfm>. Acesso em 5 de Novembro. Reviewer-Herzog, J. (2015). Software Architecture in Practice Third Edition Written by Len Bass, Paul Clements,