4 - Comunicação

Prévia do material em texto

Comunicação
Raphael Winckler de Bettio
 
Estrutura
● Conceitos
– Middleware;
– Comunicação
● Persistente
● Transiente
– Comunicação
● Assincrona
● Síncrona
● Tipos de Comunicação
– Orientada a Fluxo;
– Orientada a Mensagem;
– RPC.
 
Conceitos
● Middleware: É uma aplicação que faz a 
mediação entre demais aplicações.
– Interligar sistemas de arquiteturas diferentes
App1 App2
Middleware
 
Middleware
● Servidor de Email
Aplicação Email
Mail Server
Aplicação Email
 
 
Conceitos
● Persistência (Validade da Mensagem)
– Comunicação Persistente
● Uma mensagem de comunicação é 
armazenada no middleware o tempo 
necessário para ser entregue
● email
– Comunicação Transiente
● A mensagem é válida apenas enquanto a 
aplicação remetente/receptora estiverem 
sendo executadas.
● Aplicação Chat/Socket
 
Comunicação Persistente
App1 App2
d1 d3d2
Queda de rede?
Middleware
 
Comunicação Transiente
App1 App2
d1 d3d2 d4 d6d5
Queda de rede
 
 
Conceitos
● Sincronização (Relação entre Envia/Recebe)
– Comunicação Assíncrona
● O remetente continua sua execução 
imediatamente após a mensagem ser 
armazenada.
– Comunicação Síncrona
● O remetente é bloqueado até saber se a 
requisição foi aceita.
 
Sincronização
● Assíncrona
– Email
– Messengers
● Síncrona
– Execução de um comando em um BD
 
Tipos de Comunicação
● Comunicação Orientada a Fluxo
– Utilizada em Sistemas Multimídia
● Comunicação Orientada a Mensagem
– Pode ser Transiente ou Persistente
● RPC (Remote Procedure Call)
– DCOM (microsoft)
– Corba, RMI e EJB (java)
Tanenbaum
 
Comunicação Orientada a Fluxo
● Troca de unidades de informação 
dependentes onde tempo é crucial
– Fluxos de áudio e vídeo
– Slides com áudio
● Fluxo Simples
– Sequência simples de dados (Voz)
● Fluxos Complexos
– Vários fluxos relacionados denominados subfluxos
– Existe uma relação temporal enter os subfluxos
 
Comunicação Orientada a Fluxo
● QoS (Qualidade de Serviço)
– Requisitos que descrevem o que é necessário 
para garantir que as relações temporais em 
um fluxo possam ser preservadas
● Pontualidade: Chegou no tempo certo
● Volume: Chegou na velocidade certa
 
Comunicação Orientada a Fluxo
● Bufferização (Ferramenta garantir QoS)
Tanenbaum
 
Comunicação Orientada a Fluxo
● Fluxos Complexos - Sincronização
– Fluxo Discreto: Slides + Áudio
– Fluxo Continuo: Áudio + Vídeo
App1 App2
d1 d3d2 d4 d6d5d1 d3d2 d4 d6d5
d1 d3d2 d4 d6d5d1 d3d2 d4 d6d5
SubFluxo 1
SubFluxo 2
 
Comunicação Orientada a 
Mensagens
● Comunicação Transiente Orientada a 
Mensagens
– XTI (X/Open Transport Interface)
● Desenvolvida pela AT&T
● Muito semelhante a Sockets
– Sockets (Tecnologia x Padrão)
● Socket, Listen, Accept, Connect, Send, 
Receive, Close.
 
Socket
● Listen
● Accept
● Connect
● Send
● Receive
● Close
 
Comunicação Orientada a 
Mensagens
App1 App2
Oi, tudo bom?
Tudo bem .. e você?
● A app1 não sabe onde a App2 está (IP)
● A app1, app2 não estão sempre funcionando
● A app1 não consegue “falar” com a app2 por 
diferenças arquiteturais/tecnologicas
 
Comunicação Orientada a 
Mensagens
● Comunicação Persistente Orientada a 
Mensagens
– Importante classe de serviços Middleware
● Sistemas de Enfileiramento de Mensagens
● MOM (middleware orientado a mensagens)
● Indústria comulmente chamado de Sistemas de 
Mensageria
 
Middleware
msg1
msg2
msg3
msg4
msg5
msg6
Comunicação Orientada a 
Mensagens
App1 (Java)
App2 (Cobol)
● Filas (Estrutura de Dados)
– Fila Entrada
– Fila Saída
Java
Cobol
 
Comunicação Orientada a 
Mensagens
App1 (Java) App2 (Cobol)
● Estrutura de uma mensagem
– Bytes?
– Construção de um procotolo?
● ['nome','endereco','telefone']
Msg1
 
Comunicação Orientada a 
Mensagens
App1 (Java) App2 (Cobol)
● XML (extensible Markup Language)
– W3C
– Separa o conteúdo da formatação
– Simplifica a leitura (humanos e computadores)
– Permite validação
– Interligação de aplicações distintas
XML
 
Comunicação Orientada a 
Mensagens
App1 (Java)
App2 (Cobol)
● XML (extensible Markup Language)
XML
 
Comunicação Orientada a 
Mensagens
App1 (Java)
App2 (Cobol)
● Brokers (Conversor de Mensagens)
– ['nome','endereco','telefone']
– XML ...
XML
Bytes
App2 (.Net)
XML
Broker
XML
Bytes
 
E na prática?
● Java
– ESBs (Enterprise Service Bus)
● Utiliza JMS (Java Message Services)
● Broker
● Transport/Connectors 
Pode ser utilizado
para o trabalho final
www.mulesoft.org
 
RPC
● Remote Procedure Call
– Em geral os SD são baseados em trocas de 
mensagens;
– Utilização de Sockets não “escondem” o 
processo
– 1984
● Birrell e Nelson
● Propôs um método diferente de comunicação
– Os programas poderiam chamar procedimentos 
em outros computadores
 
RPC
Processo A
Procedimento 1
Procedimento 2
Processo B
● Remote Procedure Call
– Procedimento 1 pode chamar o Procedimento 2
– Processo A fica bloqueado até o retorno do 
procedimento 2
– Informações podem ser transportadas de A até B
 
RPC
● Int res = soma(int valor1, 
int valor2)
● Acesso a um recurso local
– Int String = 
leiaArquivo();
 
RPC
 
Tecnologias RPC
● Corba (Common Object Request Broker Architeture) 
– Padrão independente de plataforma
● DCOM (Distributed Component Object Model) 
– Windows
● RMI (Remote Method Invocation) 
– Java
 
Corba
● Corba (Common Object Request Broker)
● Criado pele Object Management Group
● Independente de Plataforma
● Conceitos
– ORB – Object Request Broker
● Localiza/Executa os objetos através da rede
– IDL – Interface Definition Language
● Permite a Interoperabilidade
– IIOP – Internet Inter-ORB Protocol
● Protocolo de comunicação utilizado pelos ORBS
 
Corba
 
DCom
● Activex – Framework para componentes 
reutilizáveis.
– Activex X Applet
– COM – Component Object Model
 
Com
Client
ComRuntime
ComRuntime
Component
ComRuntime
Component
 
DCom
Client
ComRuntime
DCOM Network-Protocol
ComRuntime
DCOM Network-Protocol
Component
Client
ComRuntime
DCOM Network-Protocol
ComRuntime
DCOM Network-Protocol
Component
 
DCom
● COM + RPC → DCOM
– Distributed Component Object Model
● Na época foi o principal concorrente do Corba
– Atualmente → API .NET Remoting
 
RMI
É uma arquitetura de software que permite que um objeto mande 
mensagens para um objeto remoto assim como se mandasse 
para um objeto local (transparência de localização).
Método X {
 A.latir()
 ...
}
método latir {
 ....
}
B A
host cliente host servidor
 
Como 
funciona...
cliente servidor
stub skeleton
Servidor de
Registro
4
5
6 7
8
9
12 3
(1) o servidor se registra com um 
nome no servidor de registro,
(2) cliente pede uma referência para o 
objeto servidor
(3) o servidor de registro retorna uma 
referência do objeto servidor (e o RMI 
carrega e cria o stub na máquina do 
cliente)
(4) o cliente manda uma mensagem 
para o servidor (no caso, manda para 
o stub que serve de proxy para o 
servidor, mascarando seus métodos)
(5) o stub abre uma conexão com o 
skeleton do servidor, e serializa os 
parâmetros nesta conexão (podem ser 
quaisquer objetos java!)
(6) o skeleton recebe o pedido, 
deserializa os parâmetros e chama o 
método solicitado no servidor
(7) recebe a resposta do servidor e 
serializa a resposta no canal de 
comunicação
(8) o stub recebe a resposta e 
(9) retorna para o cliente
 
RMI - Detalhes
● Cliente e servidor são programas separados que executam 
em hosts separados
● Necessita-se de utilizar um identificador o servidor que deve 
ser único, pois podem existir mais de um servidor executando 
ao mesmo tempo
● Formato dos nomes de servidores
● rmi://hostname:port/pathname, onde hostname é o nome 
do host na Internet, port é uma porta escolhida pelo usuário e 
pathname é um nome do diretório escolhido pelo usuário no 
servidor
● O registry service é um programa que mantémuma lista de 
nomes registrados de servidores em um host
 
RMI - Exemplo
● Nosso exemplo terá 4 classes
– Interface da mensagem
– A implementação da mensagem
– Servidor
– Cliente
● A mensagem deve ter uma interface e sua 
implementação
● O servidor registra a classe de mensagem
● Por fim, o cliente acessa o serviço de 
mensagem através do nome registrado
 
Mensagem.java
 
MensagemImpl.java
 
ServidorDeMensagem.java
 
ClienteMensagem.java
 
Trabalho
● Cite um exemplo de sistema que poderia 
utilizar mensageria, explicando o motivo.
● Defina a estrutura de um programa baseado 
em RPC para uma calculadora que faça as 
operações básicas (+,-,/,*)
– Necessário definir os métodos utilizados
– Necessário definir os métodos que vão ficar na interface
– Necessário definir os métodos que vão ficar no serviço
– Não é necessário definir a implemetação
 
Bibliografia
● Tanenbaum. Andrew S., Steen. Maarten 
Van. Sistemas Distribuidos – Princípios e 
Paradigmas.
● Coulouris George, Dollimore Jean, 
Kindberg Tim. Sistemas Distribuídos – 
Conceitos e Projeto
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45