Post on 03-Oct-2018
03/09/2008
1
IA844Redes e Sistemas Abertos de
Comunicação
Prof. Eleri CardozoDCA/FEEC/Unicamp
eleri@dca.fee.unicamp.brhttp://www.dca.fee.unicamp.br/~eleri
Dra. Eliane Gomes GuimarãesCTI Renato Archer
eliane.guimaraes@cenpra.gov.br
1IA844 - Prof. Eleri Cardozo IA844 - Prof. Eleri Cardozo 2
Sistemas Distribuídos
Um sistema distribuído é um sistema computacional com as seguintes propriedades:
1. Distribuição: um subconjunto de seus componentes são controlados por entidades independentes e dispersas (processos, máquinas virtuais, etc.).
2. Concorrência: um subconjunto de seus componentes executam concorrentemente (paralelismo real ou pseudo-paralelismo).
3. Falhas parciais: qualquer componente do sistema pode falhar independentemente dos demais.
4. Assincronismo: as atividades do sistema não são regidas por um relógio global (por exemplo, pode ser impossível estabelecer causa-efeito ou determinar precisamente o estado do sistema).
IA844 - Prof. Eleri Cardozo 3
Sistemas Abertos
Sistemas abertos são sistemas implementados segundo padrões abertos.
Padrão aberto: documento estabelecido por consenso e publicado por organismo de padronização acreditado para uso comum e repetitivo. Exemplo: Protocolos TCP/IP (IETF), RM-ODP (ISO), UML (OMG).
Padrão de-facto: padrões aceitos por razões de disponibilidade, custo, convêniência, etc. Exemplo: Windows, Linux, Java, MATLAB.
OBS: 1. A motivação para uso de padrões aberto é a independência de fornecedores.
2. Um sistema desenvolvido segundo padrões abertos não necessariamente é um sistema gratuito ou de código aberto.
IA844 - Prof. Eleri Cardozo 4
Sistemas Abertos: Classificação
Podemos classificar sistemas abertos em quatro categorias:
1. Modelos de referência: descrevem os componentes do sistema, suas funções, relações e formas de interação. Exemplo: Modelos OSI e ODP.
2. Arquiteturas de referência: igual aos modelos de referência, mas com especificação mais precisa das interfaces e pontos de referência entre os componentes do sistema. Exemplo: Arquiteturas SOA e OMA.
3. Arquiteturas abertas: igual às arquiteturas de referência, mas com especificação precisa dos protocolos de interação entre os componentes do sistema. Exemplo: Arquiteturas CORBA e TCP/IP.
4. Implementações de referência: provêem código aberto (gratuito ou não) para os componentes fundamentais da arquitetura. Exemplo: Linux kernel e Projetos da Apache.
O grau de interoperabilidade é menor para os modelos de referência e maior para as implementações de referência.
03/09/2008
2
IA844 - Prof. Eleri Cardozo 5
Exemplo: Arquitetura CORBA
Object Request Broker (ORB)
Objetos deAplicação
CORBAServices
CORBAFacilities
Arquitetura OMA
IDL (Interface Description Language)
IIOP (Internet Inter-ORB Protocol)
OMA + IDL + IIOP = CORBA
IA844 - Prof. Eleri Cardozo 6
Desenvolvimento de Sistemas Distribuídos
Infra-estrutura necessária:� Hardware: rede de computadores, multiprocessador, processador multitarefa� Software: ORBs, middlewares, contêineres, ...
A infra-estrutura de hardware é responsável por:� Suportar a distribuição do processamento;� Suportar comunicação entre os elementos do sistema.
A infra-estrutura de software é responsavel por:� Prover transparência (esconder a distribuição) aos componentes do sistema;� Atender a um subconjunto de requisitos não-funcionais do sistema.
IA844 - Prof. Eleri Cardozo 7
Desenvolvimento de Sistemas Distribuídos
Um sistema distribuído é especificado em diferentes níveis de abstração e/ou visões (viewpoints).
A parte mais importante da especificação é sua arquitetura.
Uma arquitetura de software define os elementos (objetos, módulos, componentes, etc.) que compõem o sistema, a estruturação destes elementos (camadas, tiers, clusters, etc.), as relações entre os elementos (cliente/servidor, produtor/consumidor, etc.), e as propriedades visíveis externamente destes elementos e relações (pontos de interação).
IA844 - Prof. Eleri Cardozo 8
Desenvolvimento de Sistemas Distribuídos
Atualmente, a tendência é se concentrar mais na arquitetetura e menos nas tecnologias de implementação:� favorece o reuso de arquiteturas (em oposição ao reuso de código);� alterar a arquitetura em fase adiantada de desenvolvimento é extremamente custoso;� ferramentas de desenvolvimento de software possuem capacidade crescente de geração de código.
Adotam esta estratégia:� ODP: Visão de tecnologia; � MDA (Model-driven Architecture): PIM (Platform Independent Model).
03/09/2008
3
IA844 - Prof. Eleri Cardozo 9
Redes de ComputadoresRede de Telefonia
Redes Locais
CATV
Redes de Acesso(Última Milha)
(Cable Modem,ADSL, Fibra)
Troncos(Fibra ótica)SONET/SDH
Redes ATM
Redes TCP/IP
Ethernet Wireless
VoIP IPTV
Fixa Móvel
2G, 3G
WWW
WiFi/WiMax
Sensores
Veicular
Corporal
...
Chão deFábrica
Tecnologias(camadas 1,2)
Aplicações(camadas 5,6,7)
Fibra Ótica(DWDM)
Comunicação(camadas 3,4)
IA844 - Prof. Eleri Cardozo 10
Redes de Computadores
Modelo OSI (ISO): um modelo de referência para redes de computadores.
Protocolos ISO para o modelo OSI: conjunto de protocolos para os elementos (camadas) do modelo OSI.
Arquitetura TCP/IP (IETF): arquitetura de rede não aderente ao modelo OSI.
Outras arquiteturas de rede: NetWare (Novell), IN (Rede Inteligente) (ITU-T), SNA (IBM).
IA844 - Prof. Eleri Cardozo 11
Modelo OSI
Rede
Física
Enlace
Transporte
Sessão
Apresentação
Aplicação
Transmissão de bits no meio físico
Transferência de quadros entre nós próximos
Transferêrncia de pacotes (store-and-forward)
Transferência de segmentos fim-a-fim
Manutenção de estado da comunicação fim-a-fim
Formatação canônica de dados
Infra-estrutura para o desenvolvimento de aplicações
IA844 - Prof. Eleri Cardozo 12
Modelo OSI: Exemplo
Rede
Física
Enlace
Transporte
Sessão
Apresentação
Aplicação
Par trançado (100BaseT)
Ethernet (IEEE 802.3)
Internet Protocol (IP), Address Resolution Protocol (ARP)
Transfer Control Protocol (TCP)
Secure Socket Layer (SSL)
Hypertext Markup Language (HTML)
Hypertext Transfer Protocol (HTTP, HTTPS)
Navegador Web
03/09/2008
4
IA844 - Prof. Eleri Cardozo 13
Modelo OSI: Visão Geral
4-7
1-3 1-3 1-3
1-3
4-7
1-3
1-3
roteamento
comunicaçãoem broadcast
comunicação fim-a-fim
subrede decomunicação
OBS: Esta visão “OSI” não é mais atual. Exemplo:� meio físico dedicado (switching);� roteamento baseado em restrições;� L2-VPNs (Layer 2 Virtual Private Networks).
comunicaçãoponto-a-ponto
IA844 - Prof. Eleri Cardozo 14
Arquitetura TCP/IP
Interface de Rede
Interconexão de Redes
Transporte
Aplicação
Rede
Física
Enlace
Transporte
Sessão
Apresentação
Aplicação
OBS: Na arquitetura TCP/IP a camada de aplicação é responsável pela representação canônica de dados (apresentação) e por manter o estado da comunicação (sessão).
IA844 - Prof. Eleri Cardozo 15
Protocolos TCP/IPA camada interface de rede não prescreve protocolos específicos.
A camada de rede define os seguintes protocolos:� IP (Internet Protocol): define o formato de um pacote de rede (datagrama);� ARP (Address Resolution Protocol): mapeia endereços de rede em endereços de interface de rede (enlace);� ICMP (Internet Control Message Protocol): define mensagens de controle (p.ex., echo request) e erros (e.g., host unreachable).
A camada de transporte define os seguintes protocolos:� TCP (Transfer Control Protocol): transporte de cadeia de bytes com garantia de entrega fim-a-fim;� UDP (User Datagram Protocol): transporte de mensagens sem garantia de entrega fim-a-fim.
A camada de aplicação define vários protocolos tais como HTTP, SMTP (Simple Mail Transfer Protocol) e SSH (Secure Shell).
IA844 - Prof. Eleri Cardozo 16
Protocolos TCP/IP
Além dos protocolos básicos, a Arquitetura TCP/IP especifica umgrande número de protocolos de rede e aplicação, por exemplo:
Camada de rede:� IPSec (IP Secure): confidencialidade e integridade de pacote IP;� OSPF (Open Shortest Path First): roteamento de pacotes IP;� RSVP (Resource Reservation Protocol): reserva de recursos para comunicação;� DiffServ (Serviços Diferenciados): priorização de pacotes;� DHCP (Dynamic Host Configuration Protocol): atribuição de endereços de rede.
Camada de Aplicação:� SNMP (Simple Network Management Protocol): gerência de rede;� DNS (Domain Name System): mapeamento nome hierárquico-endereço de rede;� NAT (Network Address Translation): mapeamento endereçamento privado-público.
03/09/2008
5
IA844 - Prof. Eleri Cardozo 17
Endereçamento TCP/IP
Endereço físico(distingue a conexão ao meio físico)
Física
Endereço de enlace(distingue a interface de rede no enlace)
Endereço de rede(distingue globalmente a interface)
Enlace
Rede
TransporteEndereço de transporte(distingue um ponto de acesso à rede utilizado por aplicação)
AplicaçãoEndereço de aplicação(distingue um serviço ou aplicação)
IA844 - Prof. Eleri Cardozo 18
Mapeamento de Endereços TCP/IP
Física
Enlace
Rede
Transporte
Aplicação
hardwired
00:11:43:CF:06:53
ARP (Address Resolution Protocol)
143.106.50.145
8080
prainha.dca.fee.unicamp.br
DNS (Domain Name System)
http://prainha.dca.fee.unicamp.br:8080/
RJ-45
IA844 - Prof. Eleri Cardozo 19
Endereços IP
Camada de rede: utiliza endereçamento de 32 bits hierarquizados em dois níveis (subrede - host)� Classe A: 7 bits para subrede e 24 para host;� Classe B: 14 bits para subrede e 16 para host;� Classe C: 21 bits para subrede e 8 para host.
Notação decimal: valor decimal de 8 bits separados por pontoExemplo: 143.106.8.30
Notação classless: notação decimal / tamanho do prefixo (agrega 2N endereços consecutivos)Exemplos: 143.106.8/24 (rede com 256 hosts), 143.106.8/26 (rede com 1024 hosts), 143.106.8.30/32 (host específico)
IA844 - Prof. Eleri Cardozo 20
Por que TCP/IP Prevaleceu ?
Não especificar protocolos de rede e enlace permitiu evoluir as tecnologias de rede e preservar as aplicações (a custa do protocolo ARP).
Camada de rede simples com serviço de melhor-esforço (protocolo IP) barateia os roteadores.
Deixa para os computadores dos usuários o ônus da comunicação confiável e o controle de congestionamento (protocolo TCP) -- escalabilidade.
Fácil de configurar (protocolo DHCP).
Compartilhamento de endereços públicos (NAT).
Portabilidade de aplicações (sockets).
Killing application (WWW).
03/09/2008
6
IA844 - Prof. Eleri Cardozo 21
Requisitos de Rede
Requisitos Funcionais:
Transporte de bytes entre componentes do sistema distribuído.
Requisitos Não Funcionais:� Confiabilidade (taxa de perdas, probabilidade de falha, ...);� Segurança (privacidade, autenticidade, ...);� Qualidade de serviço (atraso, jitter, ...);� Classes de serviço (priorização de tráfego)� Mobilidade (de terminal, de sessão, ...).
Os requisitos funcionais são atendidos pelas camadas 1-7. Os requisitos não funcionais podem necessitar de infra-estrutura adicional (Gerência baseada em políticas, QoS brokers, etc.).
IA844 - Prof. Eleri Cardozo 22
Requisitos de Rede
Que requisitos de rede TCP/IP é capaz de atender ?
a. Segurança: atende razoavelmente bem com mecanismo de chaves criptográficas (ex: HTTPS);b. QoS (atraso, jitter): não atende (Internet atual);c. CoS: atende em redes privadas com equipamentos adequados (ex: priorização de tráfego VoIP);d. Mobilidade: não tende.
Cenário hoje:
a. sobre-provisionamento de recursos para QoS/CoS;b. mobilidade apenas na camada 2 (ex: WiFi) ou via redes sobrepostas (ex: IP em redes de telefonia celular).
IA844 - Prof. Eleri Cardozo 23
Qualidade de Serviço
Visão OSIQoS nas camadas 1,2,3 garantidos por controle de admissão;QoS nas camadas superiores negociados no estabelecimento de conexões.
Visão TCP/IP (original)Campo TOS (Type of Service) no datagrama IP utilizado para definir o tipo de serviço conferido ao datagrama pelos roteadores.
Visão TCP/IP (Arq. de Serviços Integrados - IntServ)Utiliza-se um protocolo para sinalizar reserva de recursos na camada 3 (RSVP).
Visão TCP/IP (Arq. de Serviços Diferenciados - DiffS erv)Redefine-se o campo TOS para identicar classes de serviço.
IA844 - Prof. Eleri Cardozo 24
Conexões
Uma conexão é uma negociação entre duas camadas adjacentes (por meio de seus respectivos protocolos) visando dotar a comunicação de certos atributos relavantes para a camada. Por exemplo, para a camada de rede atributos de taxa de transferência e atraso são importantes; para a camada de transporte ausência de perdas é importante.
Conexões garantem a utilização dos recursos de forma planejada (por exemplo, evitando congestionamento nos roteadores).
Entretanto, a complexidade dos protocolos orientados a conexão é muito maior em relação àqueles que operam sem conexão.
03/09/2008
7
IA844 - Prof. Eleri Cardozo 25
Campo TOS
De acordo com o valor do campo TOS, o roteador confere um tratamento adequado ao pacote:� máxima vazão;� máxima confiabilidade;� mínimo atraso;� máxima segurança.� mínimo custo monetário.
Problema: os roteadores primitivos não tinham como honrar o campo TOS.
Resultado: serviço de melhor esforço independente do campo TOS.
IA844 - Prof. Eleri Cardozo 26
Arquitetura IntServ
Solução orientada a fluxo.
R RRfluxo� Estabelece reserva de recursos para um fluxo individual.� Define um modelo de reoteador capaz de diferenciar fluxos. � Define um protocolo para reserva de recursos por fluxo.
A B
estado
IA844 - Prof. Eleri Cardozo 27
Roteadores IntServ
Agente deRoteamento(e.g., OSPF)
Base de Dados(Tabela) deRoteamento
Agente deReserva
(e.g., RSVP)
Agente deGerência
(e.g., SNMP)
Controle deAdmissão
Controlede Tráfego
Classificadorde Pacotes
Escalonadorde Pacotes
Interfacede Saída
Interfacede
Entrada
Roteadorde Pacotes
Filas
IA844 - Prof. Eleri Cardozo 28
Protocolos IntServA Arquitetura IntServ define o protocolo RSVP (Resource Reservation Protocol). RSVP é um protocolo:
- soft state;- extensível (cabeçalho simples + objetos);- complexo (combinação e compartilhamento de reservas);- exige tráfego modelado por meio de token bucket.
A B
R RR
Path (fluxo, Tspec)
Resv
A mensagen Path instala (e “refresca”) o estado e Resv confirma o estado.
03/09/2008
8
IA844 - Prof. Eleri Cardozo 29
IntServ: Legado
A arquitetura IntServ foi uma proposta muito radical:� estabele conexão no nível de rede !!!� exige roteadores complexos (e portanto caros);� exige sinalização no host (externa à rede);� não é solução escalável (estado e controle por fluxo).
Pelas razões acima, IntServ nunca foi utilizada pelos provedores de rede. Entretanto ...� o modelo de roteador IntServ prevalece;� o protocolo RSVP é empregado em outas arquiteturas de rede (ex: MPLS);� a idéia é viável se houver agregação de fluxo (como no MPLS).
IA844 - Prof. Eleri Cardozo 30
Arquitetura DiffServ
Solução orientada a diferenciação de serviços:� define-se N classes de serviço;� para cada classe, define-se um comportamento homogêneo para pacotes pertencentes à classe (per hop behavior - PHB).
Classes de serviço são especificadas separadamente. Cada classe é identificada por um código no campo TOS (DiffServ Code Point - DSCP) e pode possuir mais de uma subclasse. Cada subclasse pode possuir mais de uma “prioridade de descarte”. Atualmente existem 3 classes:� EF (Expedited Forward) - similar a uma “linha privada virtual” - não define subclasses;� AF (Assured Forward) - “melhor que melhor esforço” - define 4 subclasses com 3 prioridades de descarte cada;� BE (Best Effort) - serviço padrão - não define subclasses.
IA844 - Prof. Eleri Cardozo 31
Roteadores DiffServ
Medidorde Tráfego
Classifi-cador dePacotes
Escalo-nador dePacotes
Interfacede
Saída
Interfacede
Entrada
Roteadorde
Pacotes
Filas
AF1
BE
EF
Condicio-nador dePacotes
Marcadorde
Pacotes ...
Agente deRoteamento(e.g., OSPF)
Base de Dados(Tabela) deRoteamento
Agente deGerência
(e.g., SNMP)
SLAs (Service Level Agreements)
IA844 - Prof. Eleri Cardozo 32
DiffServ Hoje� Utilizada em redes privadas e entre provedores de rede; � Marcação pelo host usualmente ignorada pela rede;� Apesar de escalar melhor que IntServ, o tratamento de SLAs pode ainda comprometer a escalabilidade;� Cenário provável:
Provedor de Rede
Provedorde ConteúdoRede de
Acesso
SLA
DiffServAlocaçãode Banda
Usuário
03/09/2008
9
Redes IP Móveis
IA844 - Prof. Eleri Cardozo 33
Mobilidade na camada de rede: o terminal muda de subrede e preserva as conexões de transporte. O processo de mudança de subrede é denominado “handover”.
• Macro-mobilidade: handover entre domínios• Micro-mobilidade: handover interior ao domínio
Protocolos:
• Baseados em tunelamento entre as redes home e visitada• Baseados em roteamento móvel
Handover
IA844 - Prof. Eleri Cardozo 34
Handover de camada 2 (trocas de ponto de acesso): em redes WiFi é realizado automaticamente pelo nó móvel em função da relação sinal-ruido medida entre as redes já configuradas.
Handover de camada 3 (troca de subrede): realizado quando algum evento (trigger) no nó móvel indicar que ocorreu uma mudança de subrede:• o nó móvel realizou handover de camada 2 para rede com ESSID diferente;• mensagens de Router Advertisement (IPv6) indicam que o prefixo da subrede mudou;• o nó movel perdeu sua conectividade com a rede atual.
Protocolos Baseados em Tunelamento
IA844 - Prof. Eleri Cardozo 35
Utilizam endereço “home” e endereço(s) “foreign”:
HoA: Home address – endereço permanente e roteávelCoA: Care-of Address – endereço transiente e roteável.
Protocolos:
• Mobile IPv4 (MIPv4) – suportada macro-mobilidade• Mobile IPv6 (MIPv6) – suporta macro-mobilidade• Hierarchical MIPv6 (HMIPv6) – adiciona ao MIPv6 suporte a micro-mobilidade• Proxy MIPv6 (PMIPv6) – idem ao HMIPv6
MIPv6
IA844 - Prof. Eleri Cardozo 36
Home Agent(“defende” HoA do nó móvel)
Home Network
Foreign Network
Correspondent Node
Tunel IP/IP
Nó Móvel
HoaCoa
Tunel IP/IP (opcional)
03/09/2008
10
MIPv6 - Sinalização
IA844 - Prof. Eleri Cardozo 37
HA
HomeNetwork
ForeignNetwork
CorrespondentNode
MN
BindingCache
BindingUpdate(HoA, CoA)
BindingACK Care-of Test
Init (CoA)
HomeTestInit (HoA)
Care-of Test (CKey)
HomeTest (HKey)
BindingUpdate(HoA, CoAbmKey)
BindingACK
Hkey é gerada a partir de HoACkey é gerada a partir de CoAbmKey é gerada a partir de Hkey e CKey
MIPv6 - Problemas
IA844 - Prof. Eleri Cardozo 38
•Triangularização – toda a comunicação passa pelo HA (se o nó correspondente não suporta MIPv6)
• Requer rede IPv6 e protocolo adicional no nó móvel
• Handover lento (autoconfiguração + DAD)
• Protocolo complexo para dispositivos de baixo poder computacional
• Gera muito tráfego de sinalização (Bindings update, Return Routeability)
• O no móvel precisa ter o papel de servidor?
HMIPv6
IA844 - Prof. Eleri Cardozo 39
• Minimiza o tráfego de sinalização quando ocorre handovers dentro do domínio
• Introduz um novo elemento – MAP (Mobile Anchor Point)
• Novo endereço – RCoA (Regional CoA), LCoA (Local CoA), HoA.
• Altera sinalização do MIPv6
• HA e CN não são afetados pelo HMIPv6
HMIPv6
IA844 - Prof. Eleri Cardozo
40
HA
Home Network
ForeignNetwork
Correspondent Node
Tunel IP/IPDestino: RCoA
MN
Tunel IP/IP (opcional)
Tunel IP/IPDestino: LCoA
MAP
Handover
03/09/2008
11
HMIPv6: Sinalização
IA844 - Prof. Eleri Cardozo
41
HA
Home Network
ForeignNetwork
Correspondent Node
BU (HoA, RCoA)
MN
Local BU (RCoA, LCoA1)
MAP
Local BU (RCoA, LCoA2)
RA (MAP)
BindingCache
HMIPv6: Problemas
IA844 - Prof. Eleri Cardozo 42
• Nó móvel deve escolher qual MAP é “mais próximo”
• Roteadores devem propagar MAPs nas mensagens de RA (quais?)
• MAPs devem realizar DAD para os RCoAs registrados
• MAPs devem interceptar pacotes destinados a RCoA (portanto, devem ser roteadores ou nós que defendem os RCoAs)
PMIPv6: Proxy MIPv6
IA844 - Prof. Eleri Cardozo 43
• Proposta do NETLMM (IETF).
• Propõe que todo o overhead da mobilidade recaia sobre a rede (e não sobre o nó móvel).
• Nenhum protocolo adicional é necessário para o nó móvel.
• Evita que túneis passem por enlaces aéreos.
• Toda a sinalização de mobilidade é restrita à rede de transporte.
• Elimina a necessidade de HoA/CoA (usa um endereço fixo).
• Não requer DAD a cada handover.
PMIPv6
IA844 - Prof. Eleri Cardozo 44
MAG (MobilityAccess Gateway)
MobileNetwork
Correspondent Node
BindingCache
MN
LMA (Local Mobility Anchor)
MAG
HoA HoA
03/09/2008
12
PMIPv6: Sinalização
IA844 - Prof. Eleri Cardozo 45
MAGMobileNetwork
MN
LMA
MAG
HoA-X HoA-X
AAA Server(e.g., Radius)
AAA query(e.g., WPA2) PBU (MNid)
MNid ?
Prefixo YPrefixo X
RA RA emulando X
PMIPv6: Problemas
IA844 - Prof. Eleri Cardozo 46
• Cache do nó móvel deve ser zerada após handover.
• IPv6 requer DAD após autoconfiguração.
• Servidor AAA consultado a cada handover.
• Requer trigger de camada 2 (portanto, a detecção de movimento é dependente da tecnologia da rede sem fio).
IA844 - Prof. Eleri Cardozo 47
Arquiteturas deSistemas Distribuídos
IA844 - Prof. Eleri Cardozo 48
Arquiteturas de SDs
O termo “arquitetura” refere-se a arquitetura de uma aplicação específica (exemplo: e-Banking). O termo “estilo arquitetural” ou “padrão arquitetural” refere-se a um esboço de arquitetura a partir do qual arquiteturas de aplicações podem ser projetadas (exemplo: estilo cliente/servidor).
Arquiteturas que seguem o mesmo estilo arquitetural compartilham propriedades estrututurais semelhantes.
A partir daqui, os termos “arquitetura” e “estilo arquitetural” serão utilizados como sinônimos.
03/09/2008
13
IA844 - Prof. Eleri Cardozo 49
Arquiteturas de SDs
Arquiteturas usualmente estabelecem:
1. Os elementos que compõem a arquitetura;Exemplo: Uma arquitetura de agentes possui os elementos agência e agentes.
2. A estruturação dos elementos da arquitetura;Exemplo: Agentes são elementos contidos em agências (relaçãocontêiner/contido).
3. As relações entre os elementos da arquitetura;Exemplo: Uma agência controla a execução de agentes.
4. Os pontos de interação da arquitetura.Exemplo: Agências interagem entre sí segundo um protocolo de gerência deagentes. Agentes oferecem interfaces de callback para controle por parte daagência. Agências oferecem interfaces para os agentes obterem informaçõessobre o seu ambiente de execução.
IA844 - Prof. Eleri Cardozo 50
Arquiteturas de SDsExemplo de modelagem de arquiteturas
IA844 - Prof. Eleri Cardozo 51
Padrões Arquiteturais� Cliente/Servidor;� n-Tier;� Dirigidas a Eventos e a Mensagens;� Peer-to-Peer (P2P);� Grades Computacionais;� Orientadas a Serviço;� Multi-agentes.
IA844 - Prof. Eleri Cardozo 52
Arquitetura Cliente/Servidor
O sistema é decomposto em elementos clientes e servidores. Servidores provêem serviços por meio de uma ou mais interfaces. Clientes utilizam serviços invocando operações nestas interfaces.
Clientes dependem de servidores para desempenhar suas funções.
A relação entre clientes e servidores é a de provedor/consumidor de serviços. Esta relação é estabelecida apenas durante a execução de serviços.
Um ponto de interação entre clientes e servidores deve explicitar protocolos para descrição de interfaces de serviços e para invocação de serviços.
03/09/2008
14
IA844 - Prof. Eleri Cardozo 53
Protocolos de Interação Cliente/Servidor
RPC (Remote Procedure Call) - O servidor suporta um conjunto de subrotinas que podem ser invocadas dinamicamente.� a passagem de parâmetros e retorno é sempre por valor;� necessita de infra-estrutura para invocação remota.
Infra-estrutura mínima:
bibliotecaRPC
bibliotecaRPC
P1 P2 P3
invocação localcallRPC
protocoloRPC
serializa parâmetrosde-serializa retorno
de-serializa parâmetrosserializa retorno
Cliente
Servidor
IA844 - Prof. Eleri Cardozo 54
Compiladores RPC
Stub
bibliotecaRPC
P2 P3P1
bibliotecaRPC
P1 P2 P3
invocação local
Servidor
Skeleton
protocolo RPC
associação (binding)
Cliente
P1, P2, P3Descrição de interfaces
CompiladorRPC
IA844 - Prof. Eleri Cardozo 55
RPC: Registro de ServidoresServidores devem registrar seus procedimentos para que clientes os encontrem. Registros podem ser locais, centralizados ou distribuídos.
C
Nó
R
S
Nó
R
S
Nó
R
S
Nó
C
Nó
S
Nó
R
S
Nó
S
Nó
C
Nó
S
Nó
S
Nó
S
Nó
R
DistribuídoLocal
Centralizado
IA844 - Prof. Eleri Cardozo 56
RPC: Registro de Servidores
RegistroRegistro:� portmapper� serviço de nomes� negociador (trader)
ServidorCliente
Stub Skeleton
1. registra2. busca
3. invoca
03/09/2008
15
IA844 - Prof. Eleri Cardozo 57
RPC: Registro de Servidores
Portmapper : mapeia procedimentos (programa, versão, procedimento) em um port de servidor local. Exemplo (0x12345678, 1, 2) -> 111
Serviço de nomes : mapeia nomes hierárquico em endereços de servidores. Exemplo: /Servidores/TimeServers/T1/getTime -> (143.106.50.145, 111)
Negociador (Trader) : mapeia nomes hierárquicos e atributos em endereços de servidores locais. Exemplo:/Servidores/TimeServers/T1/getTime {Precision = 99.990} ->(143.106.50.145, 111)
Ao buscar um servidor, o cliente define um critério de busca. Exemplo:/Servidores/TimeServers/*/getTime {Precision > 99.0}
IA844 - Prof. Eleri Cardozo 58
RPC: Protocolos
SUN RPC: Utilizada em serviços como NFS e NIS. Possui linguagem de descrição de procedimentos (RPC Language) e compilador (rpcgen). Opera com registro local (portmapper). Stubs possuem assinaturas diferentes dos procedimentos.
/* RPC Language */program DATE_PROG {version DATE_VERS {long BIN_DATE(void) = 1; /* numero do procedimento */string STR_DATE(long) = 2;} = 1; /* versao */} = 0x12345678; /* numero do programa */
......
/* codigo do cliente */CLIENT cl = clnt_create(server, DATE_PROG, DATE_VERS, “udp”); /* stub */long ldate = bin_date_1(NULL, cl);
IA844 - Prof. Eleri Cardozo 59
RPC: Protocolos
DCE RPC: Utilizada inicialmente no DCE (Distributed Computing Environment), serviu de base para o Microsoft DCOM/COM+. Possui invocação segura e compilador. Stubs possuem assinaturas diferentes dos procedimentos. Hoje disponível em código aberto.
/* DCE IDL */[uuid(70ff8220-6e1a-11cc-89ee-080002b2a1bca)]interface date {long bin_date();[string, prt] str_date ([in] long date);}
........
/* codigo do cliente */rpc_binding_handle_t binding_h; /* stub */unsigned32 dce_status;import_interface(“date”, date_v1.0_c_ifspec, &binding_h, &dce_status);long ldate = time(NULL);char* date = str_date(binding_h, ldate, &dca_status);
IA844 - Prof. Eleri Cardozo 60
Objetos Distribuídos
Comumente arquiteturas cliente/servidor são realizadas com objetos distribuídos. Um objeto distribuído:� possui uma referência que extrapola o seu espaço de endereçamento;� possui uma ou mais interfaces descritas segundo uma linguagem de descrição de interfaces;� é ancorado por uma infra-estrutura que suporta invocação remota dos métodos definidos em sua(s) interface(s).
A infra-estrutura de suporte a objetos distribuídos provê minimamente:� stubs e skeletons gerados para uma dada interface;� mecanismo de ligação stub-skeleton (binding).
Adicionalmente a infra-estrutura pode prover:� mecanismo de controle de execução e persistência de objetos distribuídos;� serviços adicionais (segurança, transação, etc.).
03/09/2008
16
IA844 - Prof. Eleri Cardozo 61
Objetos Distribuídos: CORBA
Stub
bibliotecaORB
P2 P3P1
bibliotecaORB
O1 O2 O3
invocaçãolocal
Servidor
Skeleton
protocolo IIOP
associação (binding)
Cliente
I1, I2, I3Descrição de interfaces: CORBA IDL
CompiladorIDL
POA
controle
Objetos serventes
IA844 - Prof. Eleri Cardozo 62
Objetos Distribuídos: CORBA
// CORBA IDLinterface date {long bin_date();string str_date(in long ldate);}
......
// clienteorg.omg.CORBA.Object obj = nserver.resolve_str(“TimeServer”);
date dt = dateHelper.narrow(obj); /* stub */long ldate = dt.bin_date();String str = str_date(ldate);
IA844 - Prof. Eleri Cardozo 63
Arquitetura n-Tier
Variante da arquitetura Cliente/Servidor onde os elementos da aplicação distribuída são estruturados em camadas verticais (tiers). Comumente são empregadas 3 camadas (Arquitetura 3-Tier):
- Apresentação : contém os elementos responsáveis pela interação com o usuário.
- Lógica da Aplicação (de negócio): contém os elementos responsáveis pela lógica da aplicação (processamento da informação).
- Dados (Back-End) - contém os elementos responsáveis pela persistência e consistência dos dados.
Elementos de uma camada interagem apenas com elementos de camadas adjacentes.
Pontos de interação entre camadas devem explicitar protocolos para descrição de interfaces de serviços e para invocação de serviços disponíveis em cada camada.
IA844 - Prof. Eleri Cardozo 64
Exemplo de Arquitetura 3-Tier
Apresentação
EJBContainer
(EnterpriseJava Beans)
WebContainer
(JSP/Servlet)
Base deDados
Relacional
Lógica daAplicação
Dados(Back-End)
HTTPRMI
JDBCJava BeansHibernate
03/09/2008
17
IA844 - Prof. Eleri Cardozo 65
Arquitetura Dirigida a Eventos e Mensagens
O sistema é decomposto em elementos produtores e consumidores de eventos (mensagens).
Produtores e consumidores são desacoplados por meio de um canal de difusão de eventos (mensagens).
Produtores e consumidores de eventos (mensagens) dependem do canal de difusão para desempenhar suas funções.
Um ponto de interação entre produtores, consumidores e canal de difusão deve explicitar protocolos e interfaces para subscrição, “de-subscrição”, publicação e consumo de eventos (mensagens).
IA844 - Prof. Eleri Cardozo 66
Arquitetura Dirigida a Eventos e Mensagens
ProxyConsumidor
ProxyProdutor
Admin
Persistência
Produtor
Produtor
push
subscribeunsubscribe
pull
Consumidor(push)
Consumidor(pull)
push
Canal deDifusão
IA844 - Prof. Eleri Cardozo 67
Arquitetura Dirigida a Eventos e Mensagens
Exemplo de infra-estruturas de eventos/mensagens:� Serviço de Notificação e de Mensagens CORBA;� Java Message Systems (JMS);� ActiveMQ (Apache);� WebSphere MQ (IBM).
IA844 - Prof. Eleri Cardozo 68
Arquitetura Peer-to-Peer (P2P)
O sistema é composto de elementos que desempenham funções semelhantes (elementos pares).
Não há uma estruturação definida para os elementos pares, apesar de prevalecer uma estruturação em grafos não orientados.
Não há relação de dependência ou hierarquia entre os elementos pares.
Um ponto de interação entre pares deve ser definido para que estes possam cooperar (tipicamente por meio de troca de mensagens).
Arquiteturas P2P são comumente empregadas em redes de compartilhamento de informação (Gnutella, Napster, etc.) e de processamento cooperativo (SETI@Home, Entropia, etc).
03/09/2008
18
IA844 - Prof. Eleri Cardozo 69
Arquitetura P2P
Rede de suporte ( underlay, e.g., Internet)
Rede suportada ( overlay, e.g., Gnutella)
peer
Topologia, protocolos de interação e funcionalidade dos nós diferem entre as duas redes.
IA844 - Prof. Eleri Cardozo 70
Exemplo de Arq. P2P: Gnutella
Gnutella é uma arquitetura de propósito geral para compartilhamento de informação (tipicamente arquivos). Gnutella define um protocolo de interação entre os nós que suporta:� descoberta de pares (mensagens PING e PONG);� busca de informação (mensagens QUERY e QUERY RESPONSE);� transferência de informação (mensagens GET e PUSH).
Em arquiteturas P2P estilo Gnutella um fator fundamental é o roteamento de queries.
IA844 - Prof. Eleri Cardozo 71
Exemplo de Arq. P2P: Gnutella
Mensagem PING Mensagem PONG
IA844 - Prof. Eleri Cardozo 72
Exemplo de Arq. P2P: Gnutella
Query (inundação) Query Response
Get/Push
03/09/2008
19
IA844 - Prof. Eleri Cardozo 73
Arquiteturas Grid
Internet
Job
Job
Submissão remota de jobs
Mainframe
Computação em Grid
Do ponto de vista do usuário, o Grid é um processador virtual composto de dezenas/centenas de processadores interconectados.
Analogia: Power Grid (sistema elétrico de potência).
IA844 - Prof. Eleri Cardozo 74
Arquiteturas Grid
Os elementos da arquitetura são recursos computacionais (CPU, armazenamento, hardware especializado, software, etc.).
Os recursos são estruturados em recursos virtuais e organizações virtuais (VOs) -- virtualização.
VOs são regidas por meio de SLAs (Service Level Agreements).
Pontos de interação são definidos entre VOs para fins de submissão de jobs, inquirição e notificação de status e coleta de resultados.
Arquiteturas Grid
IA844 - Prof. Eleri Cardozo 75
Aplicação
Coordenação
Recurso
Conectividade
Recursos “locais”
Reserva AntecipadaGerência & MonitoramentoReplicação
ServiçosAPIs/SDKsMiddleware
IdentificaçãoRegistroDescoberta
Single-sign onAutorizaçãoDelegação
CPUArmazenamentoComunicação
IA844 - Prof. Eleri Cardozo 76
Grid: Recursos Virtuais
Recursos
Serviços
Acesso
Armaze-
namentoSensores Aplicações InformaçãoComputadores
Interfaces dos Recursos
Interfaces Comuns
Classes de Interfaces
(c) Open Grid Forum
03/09/2008
20
IA844 - Prof. Eleri Cardozo 77
Grid: Organizações Virtuais
Organização Real
Organização Virtual
SLA
SLA
Recurso
IA844 - Prof. Eleri Cardozo 78
Grid X Conceitos Similares
Processamento Distribuído:� Fraco acoplamento;� Heterogêneo;� Intra/inter-organizacional, Pequena escala.
Processamento Paralelo (Cluster):� Forte acoplamento;� Homogêneo;� Intra-organizacional.
Grid:� Fraco acoplamento;� Heterogêneo;� Inter-organizacional, Larga escala.
IA844 - Prof. Eleri Cardozo 79
Grid: Exemplo
Recursos
Virtualizados
Serviços
de Grid(middleware) Brokering
Service
Registry Service
DataService
Equipment Service
Job-Submit Service
ComputeService
Notify
Advertise
ApplicationService
(c) Open Grid Forum
1
2
3
4
5
IA844 - Prof. Eleri Cardozo 80
Grid: Exemplo de Serviços� Compartilhamento de dados (Data Grids) - Exemplo: dados astronômicos.� Processamento (Computational Grids) - Exemplo: simulação.� Equipamentos especializados (Equipment Grids) - Exemplo: telescópio.
Aplicações desenvolvidas segundo uma arquitetura Grid devem utilizar uma infra-estrutura comum para disponibilização, gerência e uso dos serviços. Esta infra-estrutura pode consistir de um middleware, toolkit, ou ambiente de programação.
03/09/2008
21
IA844 - Prof. Eleri Cardozo 81
Grid: Globus Toolkit
Conjunto de funções de suporte a arquiteturas Grid:� Gerência de execução (alocação e gerência de recursos, manutenção de workspace);� Comunicação (mensagem, RPC, estado compartilhado, I/O remoto providos pela Nexus Communication Library);� Gerência de Informação (publicação, descoberta e acesso a informação sobre serviços disponíveis no Grid);� Segurança (autenticação, autorização, delegação, gerência de credenciais).
http://www.globus.org
IA844 - Prof. Eleri Cardozo 82
Grid: Globus Toolkit
(c) Globus Aliance
IA844 - Prof. Eleri Cardozo 83
Grid: Open Grid Service Architecture (OGSA)� Arquitetura aberta orientada a serviço para computação em Grid em padronização
pelo Open Grid Forum.� Classes de serviços similar ao Globus.� Utiliza padrões XML existentes (WS-Security, WS-Policy, etc.) e padrões específicos para computação em Grid (Configuration Description Language (CDL), Job Submission Description Language (JSDL)).
http://www.ogf.org
IA844 - Prof. Eleri Cardozo 84
Grid: OGSA
Security• Cross-organizational users• Trust nobody• Authorized access only
Information Services• Registry• Notification• Logging/auditing
Execution Management• Job description & submission• Scheduling• Resource provisioning
Data Services• Common access facilities• Efficient & reliable transport• Replication services
Self-Management• Self-configuration• Self-optimization• Self-healing
OGSA
OGSA “profiles”
Web services foundation
(c) Global Grid Forum
03/09/2008
22
IA844 - Prof. Eleri Cardozo 85
Arquitetura Orientada a Serviço
Tal como em Grids, arquitetura orientada a serviço (SOA - Service- oriented Architecture) é uma solução de processamento distribuído inter-organizacional. O foco principal está na interoperabilidade e segurança (mesmo comprometendo a eficiência).
Um serviço encapsula uma lógica (de negócio) auto-contida, com interface bem definida e auto-descritiva, cuja execução não depende do contexto ou estado de execução de outros serviços.
Devido aos requisitos de interoperabilidade, implementações de SOA têm se limitado à tecnologia de serviços Web.
IA844 - Prof. Eleri Cardozo 86
Arquitetura Orientada a Serviço
Os elementos da arquitetura são serviços.
Serviços são estruturados em serviços primitivos e compostos (composição de serviços).
Serviços compostos dependem dos serviços primitivos que os suportam.
Pontos de interação são definidos para registro, descoberta e invocação de serviços.
IA844 - Prof. Eleri Cardozo 87
SOA: objetos X componentes X serviços
Objeto Componente Serviço
Granularidade baixa média alta
Acoplamento médio baixo baixo
Aspectos não- providos pelo providos pelo providos pelafuncionais programador container plataforma
Interoperoperabilidade protocolo protocolo protocoloespecífico específico XML
Composiçao embutida descritor de script deno código montagem composição
(ñ recursiva) (recursiva)
IA844 - Prof. Eleri Cardozo 88
SOA: Características Próprias
Provedores e clientes de serviços podem trocar metadados sobre a utilização de serviços, por exemplo, políticas de uso do serviço.
Serviços são “sem estado” (stateless). Entretanto, o efeito da execução do serviço pode refletir em invocações subseqüentes (via alteração em base de dados, por exemplo).
Um serviços usualmente reflete um workflow balizado por regras de negócio.
Um serviço composto é também um serviço.
03/09/2008
23
IA844 - Prof. Eleri Cardozo 89
SOA: Composição de Serviços
Composição é um fluxo de execução de serviços descrito por uma linguagem de composição (script descrevendo um workflow) e processado por uma máquina de composição. Tipicamente, linguagens de composição suportam:� execução sequencial e paralela de serviços;� variáveis (armazenam resultados intermediários);� pontos de decisão;� laços de iteração;� ações de compensação (tratamento de exceções).
Máquina deComposiçãoScript
ServiçoPrimitivo
ServiçoPrimitivo
...
conexão (partner link)Serviço
Composto
IA844 - Prof. Eleri Cardozo 90
SOA: Orquestração X Coreografia
Coreografia descreve contratos inter-organizacionais para a execução de serviços. É um processo não necessariamente automatizado similar a um SLA.
Orquestração é um processo intra-organização, usualmente automatizado por meio de composição de serviços.
Coreografia
Orquestração
IA844 - Prof. Eleri Cardozo 91
Desenvolvimento Orientado a Serviço
Usualmente empregam-se um processo multi-camadas:
Camada de negócio : representada por workflows, regras de negócio, políticas, etc.
Camada de serviço : representa as interfaces e conexões entre os serviços responsáveis pela lógica de negócio. Possui 3 subcamadas:� Serviços de orquestração (serviços criados via composição de serviços);� Serviços de negócio (serviços específicos do negócio);� Serviços de aplicação (serviços de propósito geral).
Camada de aplicação : plataformas de suporte a serviços e máquinas de orquestração.
IA844 - Prof. Eleri Cardozo 92
Desenv. Orientado a Serviço
Camada deAplicação
Camada deServiço
Camada deNegócio
M.C M.C M.C
Plataforma
03/09/2008
24
IA844 - Prof. Eleri Cardozo 93
SOA: Camada de Negócio
A camada de negócio utiliza editores dedicados para modelar processos de negócio. Estes editores geram scrips de composição.
IA844 - Prof. Eleri Cardozo 94
SOA: Camada de Serviço
Serviços são descritos por meio de suas interfaces. O ciclo de desenvolvimento de um serviço segue o modelo clássico: definição de interface, compilação de interface, implementação da lógica de serviço.
Alternativamente, um serviço pode ser desenvolvido por meio de composição de serviços utilizando uma plataforma apropriada capaz de integrar as interfaces dos serviços primitivos, o script de composição, e código executável.
Uma vez desenvolvido, a interface do serviço pode ser registrada em um diretório de serviços.
IA844 - Prof. Eleri Cardozo 95
SOA: Camada de Aplicação
A camada de aplicação utiliza utiliza plataformas e máquinas de composição. Plataformas oferecem facilidades de desenvolvimento de serviços via aplicativos, editores, debuggers, etc., bem como servidores onde os serviços serão instalados e diretórios onde os serviços serão registrados.
Máquinas de composição podem ou não ser integradas às plataformas.
Exemplos (produtos gratuitos):� Apache Axis: executa como aplicação no Tomcat (não possui editor ou máquina de orquestração, apenas aplicativos). Bom para o desenvolvimento de serviços primitivos.� Eclipse BPEL Project, Oracle BPEL Process Manager, ActivBPEL: Máquinas de orquestração. Bom para o desenvolvimento de serviços compostos.
IA844 - Prof. Eleri Cardozo 96
SOA: Tecnologias Web
WS-BPELWS-CDL
WSDL, UDDI
SOAP, XML
HTTP, HTTPS
Codificaçãoe
Transporte
Descrição
Processode Negócio
Web Service Business Process Description LanguageWeb Service Choreography Description Language
Web Services Description LanguageUniversal Description, Discovery and Invocation
Simple Object Access ProtocolExtensible Markup Language
Hypertext Transfer Protocol (Secure)
WS-PolicyWS-Security
WS-Metadata
03/09/2008
25
IA844 - Prof. Eleri Cardozo 97
SOA: Tecnologias & Produtos
WS-BPELWS-CDL
WSDL, UDDI
SOAP, XML
HTTP, HTTPS
WS-PolicyWS-Security
WS-Metadata
Contêiners(Ex: Tomcat + Axis)
Aplicativos & APIs(Ex: java2wsdl, jUDDI)
Máquinas de composição(Ex: ActivBPEL)
Arquiteturas Multi-Agentes
IA844 - Prof. Eleri Cardozo 98
Elementos: agente, agência, localizador.
Agente: programa autônomo (fixo ou móvel) que possui sua própria thread de execução. Tipicamente executa o ciclo “monitora, processa, age”.
Agência: local onde agentes executam (por exemplo, processo).
Localizador: serviço que informa a localização de agências e agentes.
Arquiteturas Multi-Agentes
IA844 - Prof. Eleri Cardozo 99
Interface Agência-Agente
InterfaceExterna da Agência
Interface Externado Agente
Agência
Agente
CriaAgenteDestriAgenteMigraAgente
Localizador
Interface doLocalizador Registra(agente/agencia)
Busca(agente/agencia)
GetEnv
Callback
IA844 - Prof. Eleri Cardozo 100
Padrões Arquiteturais: Resumo
Padrão Elementos Estruturação Dependências Ponto de Int eração
Cliente/Servidor clientes e arbitrária clientes de prot. RPC entreservidores servidores clientes e servidores
Dirigida a Evento/ produtores e em torno de prods. e cons. prot. de interaçãoMensagem consumidores canais de difusão do canal c/ o canal
n-Tier clientes e camadas tier de tiers prot. de interaçãoservidores verticais (tiers) adjacentes entre tiers
Peer-to-peer pares redes nó dos nós prot. de cooperaçãoconectados entre pares
Grades recursos organizações orgs. de SLAs prot. de uso dosComputacionais virtuais virtuais estabelecidos recursos virtuais
Orientada a serviço composição serviço composto prot. de invocação eServiço de serviços dos primitivos composição de serviços
Multi-Agentes agentes e agentes contidos agentes de prot. de interaçãoagências em agências agências agente-agência e
agência-agência