Desenvolvimento de Aplicações Distribuídas

(1)

Comunica¸c˜

ao

Geanderson Esteves dos Santos

Pontif´ıcia Universidade Católica de Minas Gerais Instituto de Ciências Exatas e Informática

(2)

Apresenta¸c˜

ao da disciplina

Introdu¸

c˜

ao

Desafios e caracter´ısticas

Arquitetura Comunica¸c˜ao Nomea¸c˜ao

Controle de tempo e sincronismo Transa¸c˜ao e controle de concorrˆencia Seguran¸ca

Arquitetura Orientada a Servi¸

cos (SOA) e WebServices

Sistemas de arquivos distribu´ıdos

Aplica¸

c˜

oes m´

oveis

Semin´

arios

(3)

A comunica¸

c˜

ao ´

e o cora¸

c˜

ao de todo e qualquer sistema

distribu´ıdo, assim n˜

ao faz sentido estudarmos sistemas

distribu´ıdos sem examinar em detalhes como m´

aquinas trocam

informa¸

c˜

oes

Esta comunica¸

c˜

ao ser´

a baseada na troca de mensagens

oferecida pela rede

Sistemas Distribu´ıdos Modernos frequentemente s˜

ao

compostos de milhares de m´

aquinas ou at´

e mesmo milh˜

oes de

processos dispersos na rede com comunica¸

c˜

ao n˜

ao confi´

avel!!

A menos que tais primitivas de comunica¸

c˜

ao sejam

substitu´ıdas por algo melhor, o desenvolvimento de aplica¸c˜

oes

(4)

Premissa: toda comunica¸c˜

ao em sistemas distribu´ıdos tem

por base o envio e recep¸

c˜

ao de mensagens no n´ıvel mais baixo

da pilha de comunica¸

c˜

ao em raz˜

ao da ausˆ

encia de mem´

oria

compartilhada

Embora esta id´

eia b´

asica pare¸ca simples, os processos que

desejam trocar informa¸

c˜

oes devem acordar a forma como os

bits/bytes ser˜

ao enviados – protocolo.

Exemplo:

A envia informa¸

c˜

oes escritas em Francˆ

es e codificadas em

C´

odigo EBCDIC, enquanto B aguarda as informa¸

c˜

oes em

Inglˆ

es e codificada em C´

odigo ASCII

(5)

EBCDIC (Extended Binary Coded Decimal Interchange Code):

codifica¸

c˜

ao de caracteres 8 bits descendente do C´

odigo BCD

(6 bits) criado pela IBM no in´ıcio dos anos 1960 e usado no

IBM 360

(6)

Processos que desejam trocar informa¸

c˜

oes devem acordar na

forma como os bits/bytes ser˜

ao enviados.

Modelo OSI: prop˜

oe um modelo de referˆ

encia que claramente

identifica os v´

arios n´ıveis/camadas bem como nomes e

servi¸

cos que devem oferecer;

OSI (Open System Interconnection): foi proposto para

permitir que sistemas abertos se comuniquem;

“open systems”: sistema preparado para comunicar-se com outro sistema aberto utilizando as regras padrões que governam o formato, conteúdo e significado das mensagens Tais regras são formalizadas e chamadas de protocolos

(7)

Fundamentos de Redes

Tipos de redes

Esquemas de comuta¸c˜ao Protocolos

Interliga¸c˜ao de redes

Comunica¸c˜

ao entre Processos

API de protocolos Internet Representa¸c˜ao externa de dados e Empacotamento

Invoca¸

c˜

ao Remota

Protocolos de Requisi¸c˜ao/Resposta

Chamadas de Procedimento Remoto (RPC) Invoca¸c˜ao de M´etodo Remoto (RMI)

Comunica¸c˜

ao Indireta

Caracter´ısticas e t´ecnicas Sistemas publicar-subescrever

(8)

Fundamentos de Redes

Tipos de redes

Comunica¸c˜

ao entre Processos

Invoca¸

c˜

ao Remota

Comunica¸c˜

ao Indireta

Caracter´ısticas e t´ecnicas Sistemas publicar-subescrever Fila de mensagens

(9)

(10)

Esquemas de comuta¸

c˜

ao

Broadcast

Tudo ´e enviado para todos os nodos Comuta¸c˜ao de circuitos

Estabelecimento de canais dedicados de comunica¸c˜ao Comuta¸c˜ao de pacotes

Sistema de armazenamento e encaminhamento de pacotes com base nas informa¸c˜oes de origem e destino

Frame Relay

Avan¸co na comuta¸c˜ao de pacotes com a passagem de pacotes em tempos reais

(11)

Protocolos

(12)

Protocolos

Camadas

— Suites — Portas — Endere¸camento

(13)

Premissa: para permitir que computadores troquem

informa¸

c˜

oes pela rede, ´

e preciso acordar quais protocolos

ser˜

ao usados na comunica¸

c˜

ao

Existem dois tipos gerais de protocolos de comunica¸

c˜

ao:

“connection oriented”: necessário estabelecer uma conexão e possivelmente negociar que protocolo será utilizado e, somente depois, efetuar a troca de mensagens de conexão “connectionless”: Não é necessário estabelecimento de conexão, assim o transmissor simplesmente transmite a mensagem quando estiver pronto

(14)

Formato de uma mensagem t´ıpica trocada na rede

(15)

Protocolos

Camadas

— Suites — Portas — Endere¸camento

“protocol suite” ou “protocol stack”: cole¸c˜ao de protocolos usados em um sistema em particular

´

E importante distinguir o modelo de referˆencia dos protocolos comumente utilizados nos sistemas de comunica¸c˜ao dispon´ıveis Iniciando pelas camadas inferiores:

Protocolos das Camadas de N´ıvel Baixo Protocolos de Transporte

Protocolos de Camadas Superiores Protocolos de Middleware

(16)

Protocolos

Camadas

— Suites — Portas — Endere¸camento

Camada f´ısica: contém a especifica¸cão e implementa¸cão dos bits e da transmissão entre transmissor e receptor

Camada de enlace: prescreve a transmissão como uma série de bits no frame para permitir o controle de fluxo e de erros Camada de rede: descreve como pacotes em uma rede de computadores serão roteados e/ou encaminhados

Observa¸cão: Para muitos sistemas distribu´ıdos, a interface da camada mais baixa é aquele disposto na camada de redes e não na camada f´ısica

(17)

Protocolos

Camadas

— Suites — Portas — Endere¸camento

Camada de transporte: provˆe as facilidades de comunica¸c˜ao que possibilitam a troca de mensagens entre os processos – base para a maioria dos sistemas distribu´ıdos

Protocolos da internet:

Transmission Control Protocol (TCP): orientado a conexão, confiável e comunica¸cão orientada por “stream” (fluxo de bytes)

User Datagram Protocol (UDP): comunica¸cão não confiável Real-time Transport Protocol (RTP): especifica formato de pacotes para tempo real sem prover mecanismo que garanta a entrega do dado.

(18)

Protocolos

Camadas

— Suites — Portas — Endere¸camento

Camada de sessão: versão melhorada da camada de transporte tem por fun¸cão oferecer controle de sessão e facilidades de sincroniza¸cão

Camada de apresenta¸cão: se preocupa com a representa¸cão canônica dos dados bem como com a estrutura¸cão dos mesmos Camada de aplica¸cão: aplica¸cão que provê um ou uma cole¸cão de servi¸cos

Modelo OSI foi originalmente proposto para acomodar um cole¸cão de aplica¸cões padrões de rede tais como email, transferência de arquivo e emula¸cão de terminal

(19)

Protocolos

(20)

Protocolos

Camadas — Suites —

Portas

— Endere¸camento

(21)

Protocolos

(22)

Protocolos

Camadas — Suites — Portas —

Endere¸camento

(23)

Protocolos de “Middleware”

Proposto para prover servi¸

cos comuns e protocolos a serem

utilizados por diferentes aplica¸

c˜

oes;

´

E uma aplica¸

c˜

ao que est´

a presente em muitas camadas de

aplica¸

c˜

ao, mas que cont´

em protocolos de prop´

osito geral que

garantem suas pr´

oprias camadas

Este protocolos devem suportar servi¸

cos de comunica¸c˜

ao de

alto n´ıvel de forma transparente

Suporte para servi¸

cos de comunica¸c˜

ao de forma transparente:

“data (un)marshaling”: necessário para sistemas integrados “naming protocols”: facilitar o compartilhamento de recursos “security protocols”: para seguran¸ca de comunica¸cão “scaling mechanisms”: para replica¸cão e salvaguarda

(24)

Adaptive Reference Model

(25)

Para melhor entender as v´

arias alternativas de comunica¸

c˜

ao

que o middleware pode ofererecer para as aplica¸

c˜

oes, podemos

ver o middleware como um servi¸co adicional no modelo

cliente/servidor

Por exemplo: considere um sistema de correio eletrˆ

onico, cujo

n´

ucleo do sistema de entrega de mensagens pode ser visto

como um servi¸

co de comunica¸c˜

ao do “middleware”

Cliente ´

e representado pelo agente do usu´

ario que permite ao

mesmo a composi¸

c˜

ao, envio e recep¸c˜

ao de emails

Um agente transmissor repassa este email para o sistema de

entrega de mensagens – respons´

avel pela entrega da

mensagem ao sistema de entrega de mensagens do

destinat´

ario

(26)

Para melhor entender as v´

arias alternativas de comunica¸

c˜

ao

que o middleware pode ofererecer para as aplica¸

c˜

oes, podemos

ver o middleware como um servi¸co adicional no modelo

cliente/servidor

(27)

comunica¸

c˜

ao transiente: servidor de comunica¸

c˜

ao descarta

mensagens quando n˜

ao podem ser entregues no pr´

oximo

servidor ou mesmo no solicitante da requisi¸

c˜

ao

comunica¸

c˜

ao persistente: mensagem ´

e armazenada no

servidor de comunica¸

c˜

ao pelo tempo que for necess´

ario de

modo que a entrega da mensagem seja garantida

(28)

comunica¸

c˜

ao ass´ıncrona: remetente continua o seu

processamento imediatamente ap´

os submeter a mensagem

comunica¸

c˜

ao s´ıncrona: remetente ´

e bloqueado at´

e que sua

requisi¸

c˜

ao seja enviada/processada pelo receptor.

(29)

Interliga¸

c˜

ao

de Redes

Roteador Ponte (Bridge) Hub Switch Modem VPN NAT Firewall

(30)

Interliga¸

c˜

ao de Redes - Virtual Private Network (VPN)

(31)

(32)

Interliga¸

c˜

ao de Redes - Firewall

(33)

Fundamentos de Redes

Tipos de redes

Comunica¸c˜

ao entre Processos

Invoca¸

c˜

ao Remota

Comunica¸c˜

ao Indireta

(34)

Processos

(35)

Processos

API de protocolos Internet

Caracter´ısticas da comunica¸c˜ao entre processos

Comunica¸c˜ao s´ıncrona e ass´ıncrona Destinos de mensagem

Confiabilidade Ordenamento

Sockets

De acordo com KUROSE: ”socket é a interface entre a camada de aplica¸cão e a de transporte dentro de uma máquina”.

Cada socket tem um endere¸co único na internet. Este endere¸co é formado por um número IP e por um número de porta.

(36)

Processos

API de protocolos Internet - Sockets

(37)

Processos

API de protocolos Internet - Sockets

Uma API de comunica¸c˜ao via sockets oferece classes que permitem o envio e o recebimento de dados

Os sockets podem utilizar:

UDP (User Datagram Protocol): Comunica¸cão via datagramas não orientada a conexão

TCP (Transmission Control Protocol): Comunica¸c˜ao via stream orientada a conex˜ao

Ao socket deve ser fornecido o endere¸co de IP e a porta de destino

Na plataforma Java, a API de sockets provˆe as seguintes classes:

Comunica¸c˜ao via datagramas: DatagramSocket e DatagramPacket

(38)

Processos

Nota

Stream ´

e uma sequˆ

encia de dados que ´

e transmitida de um

processo a outro.

Datagrama ´

e uma unidade de transferˆ

encia em uma rede baseada

em pacotes.

(39)

Processos

(40)

Processos

API de protocolos Internet - Sockets - UDP

(41)

Processos

(42)

Processos

Programando o Cliente

Inicializa¸c˜ao

gethostbyname - traduz nome do servidor

socket - cria o socket connect - conecta `a porta do servidor

Transmiss˜ao

send - envia msg para o servidor recv - recebe msg do servidor Encerramento

close - fecha o socket

(43)

Processos

Programando o Servidor

Inicializa¸c˜ao

socket - cria o socket

bind - associa o socket ao endere¸co local

listen - associa socket a requisi¸c˜ao de entrada

Transmiss˜ao

accept - aceita cone¸c˜ao de cliente recv - recebe msg do cliente recv - envia msg para o cliente Encerramento

(44)

Processos

API de protocolos Internet - Sockets - TCP

(45)

Processos

(46)

Processos

API de protocolos Internet - Sockets - TCP

(47)

Processos

Representa¸c˜

ao externa de dados e Empacotamento

Formatos diferentes de dados em diferentes computadores.Ex: ASCII, big-endian/little-endian

(48)

Processos

Empacotamento

Marshalling: montar os itens de dados de forma apropriada para transmiss˜ao da mensagem

Unmarshalling: desmontar o pacote da mensagem e restaurar os itens de dados equivalentes

Representa¸c˜

ao de dados

Serializa¸c˜ao de objetos XML

CORBA

(49)

(50)

Processos

Representa¸c˜

ao externa de dados e Empacotamento

-Serializa¸

c˜

ao de objetos

Serializa¸c˜ao e De-serializa¸c˜ao

Tarefa de converter objetos ou um conjunto de objetos em uma sequˆencia de dados para armazenamento em disco ou transmiss˜ao de uma mensagem.

A sequˆencia de dados gerada preserva informa¸c˜oes sobre a classe de cada objeto

Referências para outros objetos são representadas por handles Serializa¸cão em Java

Classe: ObjectOutputStream

M´etodos: ObjectOutputStream.writeObject, ObjectInputStream.readObject

(51)

(52)

Processos

Uso de reflection

Reflection: funcionalidade que permite verificar informa¸cões (nomes, tipos, métodos) a partir de uma instância. Isto permite a cria¸cão de objetos a partir do nome das classes. Através de reflection é poss´ıvel realizar a serializa¸cão e a de-serializa¸cão de uma forma genérica

(53)

Processos

Representa¸c˜

ao externa de dados e Empacotamento

-Serializa¸

c˜

ao de objetos

(54)

Processos

Representa¸c˜

ao externa de dados e Empacotamento - XML

Tags definidas pelo usu´ario (diferente do HTML que possui tags predefinidas)

Aplica¸c˜oes diferentes utilizam diferentes tags Conte´udo 100% textual

Permite uso de namespaces para resolu¸c˜ao de conflitos Permite defini¸c˜ao de tipos e de esquemas

(55)

Fundamentos de Redes

Tipos de redes

Comunica¸c˜

ao entre Processos

Invoca¸

c˜

ao Remota

Comunica¸c˜

ao Indireta

(56)

(57)

Protocolos de Requisi¸c˜

ao/Resposta

Primitivas

DoOperation: Cliente invoca uma opera¸cão no servidor GetRequest: Obtém a requisi¸cão do cliente

SendReplay: Envia uma resposta ao cliente

(58)

Protocolos de Requisi¸c˜

ao/Resposta

Primitivas de Comunica¸c˜ao

(59)

Protocolos de Requisi¸c˜

ao/Resposta - Exemplo HTTP

Requisi¸c˜ao

M´etodos HTTP: GET, HEAD, POST, PUT, DELETE, OPTIONS

URL: Identifica¸c˜ao do recurso Headers

Resposta do Servidor

Vers˜ao do protocolo: HTTP 1.0 x HTTP 1.1 Status code e Raz˜ao do retorno

(60)

Protocolos de Requisi¸c˜

ao/Resposta - Exemplo HTTP

(61)

Chamadas de Procedimento (RPC)

O RPC permite que um processo execute um

procedimento/fun¸c˜ao em outro processo, situado na mesma m´aquina ou em um computador remoto conectado por uma rede, de forma transparente.

(62)

Chamadas de Procedimento (RPC)

Birrell & Nelson (1984): quando um processo em uma máquina “A” chama um procedimento em um processo em uma máquina “B”, processo “A” é suspenso e a chamada é executada em “B”

Considerado um dos maiores avan¸cos de Sistemas Distribu´ıdos (1984)

Informa¸c˜oes podem ser passadas do remetente para o

destinatário como parâmetros assim como do destinatário para o remetente como resultado do procedimento.

Este m´etodo ´e conhecido como Remote Procedure Call (RPC).

(63)

Chamadas de Procedimento (RPC)

A ideia central do RPC é fazer com que a Chamada RPC se pare¸ca tanto quanto poss´ıvel com uma “chamada local”, ou seja, queremos uma chamada remota que seja transparente A comunica¸cão entre remetente e destinatário pode ser escondida utilizando o mecanismo de chamada de procedimento.

(64)

Chamadas de Procedimento (RPC)

Caracter´ısticas Relevantes

Programa¸cão de sistemas distribu´ıdos tornou-se similar (ou até idêntica) a sistemas centralizados

Alto n´ıvel de transparˆencia

Procedimentos em m´aquinas remotas s˜ao chamados como se estivessem no espa¸co de endera¸camento local

Quest˜oes de Projeto

Estilo de Programa¸c˜ao (Interfaces) Transparˆencia

(65)

Chamadas de Procedimento (RPC) - Interfaces

Define um contrato entre seus utilizadores

Permite modifica¸c˜oes de implementa¸c˜ao sem afetar os clientes do procedimento

Interfaces de Servi¸co

Especifica¸c˜ao das procedures ofertadas pelo servidor

Defini¸c˜ao dos tipos de entrada e retorno de cada procedimento

Benef´ıcios

Abstra¸cão de detalhes de implementa¸cão Permite implementa¸cão em diferentes linguagens

(66)

Chamadas de Procedimento (RPC) - Interfaces

Impacto da natureza distribu´ıda das aplica¸c˜oes

Módulo cliente não acessa espa¸co de variáveis do módulo remoto

Parâmetros de entrada e retorno são, na verdade, transmitidos entre máquinas na rede

Parâmetros de entrada e retorno são mapeados para variáveis ou pontos do retorno após transmissão

Um mecanismo RPC pode ser integrado a uma particular linguagem de programa¸c˜ao

´

Util quando todas as partes do SD s˜ao implementadas em uma mesma linguagem

Exemplo: Java para cliente e objeto remoto (servidor)

Linguagens de Defini¸c˜ao de Interfaces (IDLs) s˜ao projetadas para permitir que procedimentos implementados em linguagens diferentes possam executar uma a outra.

(67)

IDL - Linguagem de Defini¸

c˜

ao de Interfaces

Vantagens

IDL ´e uma linguagem neutra que permite que clientes e servidores sejam implementados em linguagens diferentes Um cliente Java pode interagir com aplica¸c˜oes COBOL empacotadas com Java IDL

IDL permite que a especifica¸c˜ao dos servi¸cos seja separada da implementa¸c˜ao.

Desvantagens

Dif´ıcil de usar

(68)

IDL - Linguagem de Defini¸

c˜

ao de Interfaces

M´odulo sayHello seria implementado por um servidor e chamado por um cliente remotamente

(69)

(70)

Invoca¸

c˜

ao de M´

etodo Remoto (RMI)

Conceito pr´oximo ao RPC, extendido para objetos

Evolu¸c˜ao do RPC com base nos princ´ıpios da programa¸c˜ao orientada a objetos.

O RMI permite que um processo instancie um objeto remoto e utilize seus m´etodos e propriedades. Este objeto remoto pode estar no mesmo computador ou em um outro computador conectado por rede.

Permite a passagem de objetos como parˆametros por referˆencia

(71)

(72)

Invoca¸

c˜

ao de M´

etodo Remoto (RMI) - Exemplo Java RMI

(73)

(74)

Comandos para execu¸

c˜

oa do servidor RMI

1 _{javac *.java}

2 _{rmiregistry & (levanta o servidor na porta padr˜}_ao)

3 _{java CalculatorServer}

4 _{java CalculatorClient}

(75)

RPC vs RMI

Ambos os paradigmas suportam programa¸c˜ao com interfaces Constru´ıdos sobre o protocolo pedido/resposta

(request/response)

N´ıvel similar de transparˆencia

Sistemas distribu´ıdos orientados a objetos (expressividade e poder do paradigma)

Modelo mais sofisticado de passagem de parˆametros

Passagem de parâmetro por valor Passagem de parâmetro por referência

(76)

(77)

Fundamentos de Redes

Tipos de redes

Comunica¸c˜

ao entre Processos

Invoca¸

c˜

ao Remota

Comunica¸c˜

ao Indireta

(78)

Caracter´ısticas

Comunica¸c˜ao via um intermedi´ario

Não há acoplamento direto entre emissor e receptor Paradigma que suporta comunica¸cão 1 para N Desacoplamento Espacial

O remetente n˜ao conhece ou precisa conhecer a identidade do destinat´ario e vice versa

Desacoplamento Temporal

O remetente e o destinatário podem ter independência do momento de existência

(79)

T´

ecnicas de comunica¸

c˜

ao indireta:

Comunica¸c˜ao em grupo

Mensagem ´e enviada para um grupo

Grupo: Um conjunto de processos que cooperam entre si para prover um servi¸co

Posteriormente a mensagem ´e enviada para todos os destinat´arios

Exemplos

Jogos multiusu´arios

Estratégias de balanceamento de carga Replica¸cão de bancos de dados Conferências multim´ıdia

Aplica¸c˜oes que em geral necessitem de uma alta taxa de disponibilidade, confiabilidade, tolerˆencia a falhas

(80)

T´

ecnicas de comunica¸

c˜

ao indireta:

Comunica¸c˜ao em grupo

Comunica¸c˜ao de grupo coordena a troca de mensagens entre os membros do grupo e dos processos externos com o grupo Comunica¸c˜ao em RPC envolve somente dois processos, gerando problemas quando se quer enviar mensagens para mais de um servidor

Em comunica¸cão de grupos, com uma única opera¸cão pode-se enviar uma mensagem á vários destinos

Permitem que processos em um grupo sejam tratados como uma ´unica abstra¸c˜ao

Pode ser implentada usando Unicast, Multicast ou Broadcast Exemplos

Unicast: de um source para um destino e.g. One-to-One

Broadcast: de um source para todos os destinos poss´ıveis e.g. One-to-All Multicast: de um source para m´ultiplos destinos com o interesse de receber o tr´afico e.g. One-to-Many

(81)

Aspectos de SDs – Comunica¸c˜

ao – Comunica¸c˜

ao Indireta

Comunica¸

c˜

ao em grupo - Aplica¸

c˜

oes

Dissemina¸cão de informa¸cão para grande número de destinatários

Suporte a aplica¸c˜oes colaborativas, ex: jogos multi-usu´ario

implementado em meados de 1998

Open source e possui licen¸ca que pode ser usada em projetos comerciais

Considerado altamente confi´avel

Suporta grupos de processos nos quais cada entidade pode entrar ou deixar o grupo

Envio de mensagens Todo o grupo

(82)

Aspectos de SDs – Comunica¸c˜

ao – Comunica¸c˜

ao Indireta

Comunica¸

c˜

ao em grupo - Aplica¸

c˜

oes

Suporte a aplica¸c˜oes colaborativas, ex: jogos multi-usu´ario Ex: JGroups toolkit: Paradigma de Grupos de Processos

Toolkit para comunica¸c˜ao em grupo escrito em Java implementado em meados de 1998

Para um simples integrante

(83)

Comunica¸

c˜

ao em grupo - Aplica¸

c˜

oes

Suporte a aplica¸c˜oes colaborativas, ex: jogos multi-usu´ario Ex: JGroups toolkit: Paradigma de Grupos de Processos

Toolkit para comunica¸c˜ao em grupo escrito em Java implementado em meados de 1998

Envio de mensagens Todo o grupo

(84)

Aspectos de SDs – Comunica¸c˜

ao – Comunica¸c˜

ao Indireta

Sistemas Publicar-Subscrever

Permite que v´arios objetos sejam notificados sobre eventos ocorrendo em um dado objeto

Publicador: Objeto que gera eventos publica os eventos que deseja tornar dispon´ıveis

Assinador: Objetos interessados em eventos de um dado outro objeto

Sa´ıda de um usu´ario de uma sala de bate papo

(85)

Sistemas Publicar-Subscrever

Permite que v´arios objetos sejam notificados sobre eventos ocorrendo em um dado objeto

Publicador: Objeto que gera eventos publica os eventos que deseja tornar dispon´ıveis

Assinador: Objetos interessados em eventos de um dado outro objeto

Exemplos

Notifica¸cão de altera¸cão em documentos colaborativos Sa´ıda de um usuário de uma sala de bate papo

(86)

Sistemas Publicar-Subscrever

S˜ao conhecidos como sistemas baseados em eventos distribu´ıdos

A tarefa principal do sistema ´e combinar as assinaturas com os eventos publicados e garantir a entrega correta para os assinantes

(87)

Aspectos de SDs – Comunica¸c˜

ao – Comunica¸c˜

ao Indireta

T´

ecnicas de comunica¸

c˜

ao indireta:

Sistemas de fila de mensagens: As mensagens são direcionadas para a abstra¸cão de uma fila com receptores de extra¸cão de mensagens de tais filas

Filas de mensagens

Prov´em servi¸co de comunica¸c˜ao ponto-a-ponto Desacoplamento espacial e temporal

Tamb´em chamados de Message-Oriented Middleware

Regras de remo¸c˜ao de mensagens da fila

FIFO (first in, first out)

Baseadas em prioridades do “leitor”

Baseadas em sele¸c˜ao de propriedades de mensagens

(88)

T´

ecnicas de comunica¸

c˜

ao indireta:

Sistemas de fila de mensagens: As mensagens são direcionadas para a abstra¸cão de uma fila com receptores de extra¸cão de mensagens de tais filas

Filas de mensagens

Prov´em servi¸co de comunica¸c˜ao ponto-a-ponto Desacoplamento espacial e temporal

Tamb´em chamados de Message-Oriented Middleware

Regras de remo¸c˜ao de mensagens da fila

FIFO (first in, first out)

Baseadas em prioridades do “leitor”

Baseadas em sele¸c˜ao de propriedades de mensagens

Exemplos

Sistema de Pagamento Brasileiro Plataformas WebSphere MQ

(89)

Sistemas de fila de mensagens

Processos produtores enviam (send ) mensagens para fila Processos consumidores recebem (receive) mensagens desta fila

Mensagens s˜ao persistentes (permanecem na fila at´e serem consumidas)

Podem ser implementados controles de seguran¸ca via SSL para confidencialidade e autentica¸c˜ao para controle de acesso Aplica¸c˜ao: Java Messaging Service (JMS)

(90)

Java Messaging Service (JMS)

Especifica¸cão padrão para comunica¸cão indireta em programas Java

Unifica os paradigmas

Publicar/Assinar Filas de Mensagens

Implementa¸c˜oes

OW2, Java Messaging from JBoss, Sun’s Open MQ, Apache ActiveMQ and OpenJMS

Componentes JMS

Cliente JMS: programa Java que produz ou consome mensagens Provedor JMS: uma implementa¸cão do servi¸co segundo a especifica¸cão Mensagem JMS: objeto utilizado para comunica¸cão entre clientes JMS (produtores ou consumidores)

Destino JMS: suporte `a comunica¸c˜ao indireta

(91)

Aspectos de SDs – Comunica¸c˜

ao – Comunica¸c˜

ao Indireta

T´

ecnicas de comunica¸

c˜

ao indireta:

Abordagens baseadas em mem´oria compartilhada:

Processos lˆeem e escrevem na mem´oria compartilhada como se estivessem acessando seu espa¸co de endere¸camento de

mem´oria

Abstra¸c˜ao utilizada para compartilhar dados entre computadores em espa¸cos de mem´oria diferentes

Processos acessam memória compartilhada realizando leitura e escrita como se estivem em seus espa¸cos de memória próprios Um servi¸co é responsável por garantir de forma transparente que cada processo tome conhecimento dos updates dos outros processos

(92)

T´

ecnicas de comunica¸

c˜

ao indireta:

Abordagens baseadas em mem´oria compartilhada:

Processos lˆeem e escrevem na mem´oria compartilhada como se estivessem acessando seu espa¸co de endere¸camento de

mem´oria

Abstra¸c˜ao utilizada para compartilhar dados entre computadores em espa¸cos de mem´oria diferentes

Processos acessam memória compartilhada realizando leitura e escrita como se estivem em seus espa¸cos de memória próprios Um servi¸co é responsável por garantir de forma transparente que cada processo tome conhecimento dos updates dos outros processos

Exemplos Clusters

(93)

Abordagens baseadas em mem´

oria compartilhada

Vantagens:

Transparência: usuário não precisa lidar diretamente com mecanismos de comunica¸cão

Desenvolvimento:

Programador lida com conceitos com os quais j´a est´a familiarizado

Aplica¸c˜oes centralizadas podem ser facilmente paralelizadas/distribu´ıdas

(94)