Aula 11 Sistemas Distribuidos

Prévia do material em texto

Sistemas Distribuídos
Prof. Carlos Viana
Middleware
• No início dos anos 80, a Sun Microsystems 
desenvolveu um protocolo baseado em chamada de 
procedimento remoto como parte da arquitetura 
Open Network Computing [Charles 1999].
• Este protocolo, que fazia parte do sistema 
operacional desenvolvido pela Sun, permitia que 
uma máquina cliente executasse uma chamada 
remota de procedimento a uma máquina servidora 
escondendo os detalhes da rede. 
Middleware
• “O software que é usado para mover 
informação de um programa para um ou mais 
programas, protegendo o desenvolvedor de 
dependências do protocolo de comunicação, 
sistemas operacionais e hardware”. 
[Talarian 2000] 
Middleware
• O middleware fornece uma camada de 
abstração entre a aplicação e o sistema 
operacional, sendo responsável por 
realizar a comunicação entre elementos 
de sistemas distribuídos.
Estrutura do Middleware
Middleware Procedural
• É caracterizado por chamada de procedimento 
remoto, que consiste na invocação de uma 
função de um servidor por um cliente, onde 
ambos encontram-se em máquinas distintas.
• Estas chamadas remotas são síncronas, de 
maneira que o cliente permanece bloqueado 
até que o servidor envie uma resposta da 
execução da função remota.
Stub
• Um stub ou method stub, em português esboço 
de método, em desenvolvimento de software, é 
um pedaço de código usado para substituir 
algumas outras funcionalidades de programação. 
• Um stub pode simular o comportamento de um 
código existente (como um procedimento em uma 
máquina remota) ou ser um substituto temporário 
para o código ainda a ser desenvolvido. 
Exemplo Stub
Conclusão
• Stubs é tipo um proxy para os objetos 
remotos no lado cliente, e skeletons 
seriam esses proxys no lado servidor.
• Stubs repassam os métodos invocados do 
cliente remoto para os skeletons 
(servidor). Skeletons devolvem o 
resultado para os clientes atraves dos 
stubs. 
Middleware Orientado a Objetos
• É uma evolução do middleware procedural e 
permite que objetos localizados em diferentes 
pontos da rede se comuniquem de maneira 
transparente, como se a comunicação 
ocorresse entre objetos locais.
• Este tipo de middleware possui todas as 
características do paradigma de orientação a 
objetos, como herança, polimorfismo e 
encapsulamento [Bakken 2001].
Middleware Orientado a Objetos
• Normalmente, a comunicação síncrona é 
utilizada em sistemas de middleware de 
objetos distribuídos. No entanto, a 
comunicação assíncrona também é 
suportada por determinadas plataformas de 
middleware orientadas a objeto (e.g. 
CORBA). 
T ipos de Middleware Orientado a 
Objetos
RMI (Java Remote Method 
Invocation) 
• É o middleware para objetos distribuídos em 
Java. Objetos que residem em uma máquina 
virtual Java (JVM - Java Virtual Machine) 
podem acessar métodos de objetos que 
residem em uma outra JVM através de RMI.
• RMI fornece transparência de localização, 
segurança, independência de plataforma, mas 
é dependente de linguagem de programação 
Java.
RMI (Java Remote Method 
Invocation) 
• O cliente comunica-se com o registry, um servidor 
de nomes que permite que clientes obtenham 
referências remotas para servidores.
• O cliente utiliza-se de um stub para realizar a 
invocação.
• No servidor, um skeletton recebe a requisição 
remota, realiza a operação unmarshalling (processo 
inverso ao marshalling) e então repassa a chamada 
para o objeto servidor, que executa o método. 
RMI (Java Remote Method 
Invocation) 
• Os stubs e skelletons são gerados 
automaticamente a partir do compilador 
rmic, bastando que o desenvolvedor da 
aplicação distribuída informe a referência 
da classe à qual o stub e o skelleton 
deverão se referir. 
EJB (Enterprise Java Beans) 
• É a uma especificação de middlweare 
baseado em componentes para 
computação distribuída, definida pela 
Sun Microsystems. Os componentes EJB 
são gerenciados por um container que 
executa no servidor.
EJB (Enterprise Java Beans) 
• O container provê suporte a distribuição, 
transações, segurança e gerenciamento 
de recursos. 
• O suporte aos requisitos não-funcionais 
providos pelo container, como transação 
e segurança, são configuráveis através de 
meta dados definidos em XML.
EJB (Enterprise Java Beans) 
• O EJB possui uma especificação que deve ser 
seguida por qualquer empresa de software 
que desenvolva um container. 
• O EJB provê interoperabilidade entre 
aplicações distribuídas Java executando em 
diferentes containers e sistemas operacionais. 
Porém, assim como RMI, EJB é restrito à Java.
Arquitetura EJB
• Os elementos principais da arquitetura EJB 
são:
• entity beans: 
– Provê persistência e compartilhamento dos dados 
do sistema.
• session beans:
– Podem ser de dois tipos: 
• container-managed persistence.
• bean-managed persistence.
Arquitetura EJB
• container-managed persistence:
– No qual o container realiza automaticamente a 
implementação necessária à inserção, leitura e 
atualização de um objeto representado por um EJB.
• bean-managed persistence:
– No qual o desenvolvedor da aplicação precisa criar 
a implementação de métodos de inserção, leitura e 
atualização de um objeto representado por um EJB.
Arquitetura EJB
• Session e entity beans, executam e têm 
suas operações controladas pelo 
container. 
• Os clientes fazem requisições a session 
beans, que fornecem serviços de negócio 
e fazem a comunicação com entity beans 
que, por sua vez, acessam bases de 
dados.
CORBA
• É uma especificação de um middleware orientado 
a objetos desenvolvido e mantido pela OMG 
(Object Management Group) um consórcio de 
mais de 800 companhias, primariamente da 
indústria.
• CORBA fornece independência de localização, de 
plataforma e de linguagem de programação para 
sistemas que utilizam sua arquitetura. A primeira 
especificação de CORBA data do início dos anos 
90.
• A comunicação entre objetos distribuídos 
ocorre basicamente da seguinte maneira: 
– Ao realizar a chamada ao método de um servidor, 
o cliente utiliza-se de um stub, possuidor da 
mesma interface do servidor, que por sua vez 
repassa a chamada para o ORB; 
– Este último direciona a chamada para um object 
adapter, que redireciona para um skeleton que, 
finalmente, invoca o servidor.
Middleware Transacional
• Fornece a capacidade de gerenciar transações 
em bancos de dados distribuídos, sendo 
normalmente utilizados em aplicações 
distribuídas que necessitam realizar 
transações coordenadas e sincronizadas 
através de múltiplos servidores de bancos de 
dados. 
Middleware Transacional
• Os clientes invocam, em servidores, 
procedimentos remotos que possuem as 
propriedades de atomicidade, consistência, 
isolamento, e durabilidade (ACID) [Tanenbaum 
et al. 2002].
Middleware Transacional
• Atomicidade:
– Significa que, para o mundo externo, a transação é 
indivisível, sendo executada como se fosse uma 
única operação. 
• Consistência:
– Garante que a transação não viola as invariantes 
do sistema, de modo que após sua execução, o 
sistema sempre se encontrará em um estado 
consistente. 
Middleware Transacional
• Isolamento:
• Refere-se ao fato de que uma transação não 
interfere em outra transação concorrente, e seus 
efeitos só serão externamente visíveis após ela ter 
sido completada com sucesso. 
– Durabilidade:
• Quer dizer que uma transação confirmada têm 
seus efeitos persistidos de maneira permanente.
Middleware Transacional
• Os sistemas de middleware transacionais 
utilizam-se de um software denominado TP 
Monitor (Transaction Processing Monitor) que 
tem o papel de monitorar econtrolar as 
transações, para garantir que cada transação 
seja completada com sucesso ou que, em caso 
de falha, seja a mantida a integridade do 
sistema [Talarian 2000]. 
Middleware Transacional
• O TP Monitor conecta múltiplos clientes a 
múltiplos servidores que acessam múltiplas 
bases de dados, gerenciando transações e 
garantindo as propriedades ACID.
Middleware Transacional
• Sistemas de middleware transacionais 
costumam suportar dois tipos de transações: 
flat transactions e nested transactions. Em flat 
transactions, dentro de um mesmo 
procedimento, ou todos os comandos são 
bem-sucedidos ou todos falham.
MOM (Message Oriented 
Middleware)
• É um tipo de middleware caracterizado pela 
troca de mensagens. A comunicação realizada 
por um MOM é assíncrona. 
• Ao emissor, é garantida a entrega da 
mensagem. No entanto, um emissor não tem 
como saber quando o destinatário irá receber 
a mensagem.
MOM (Message Oriented 
Middleware)
• Deste modo, o emissor e destinatário da mensagem 
executam de maneira completamente 
independente, devido ao baixo grau de acoplamento 
existente. Existem dois tipos de MOM: 
– message queuing: Uma mensagem é produzida por uma 
aplicação e consumida por outra.
– message passing: As mensagens não são enviadas a 
apenas um destinatário. Em vez disso, as mensagens são 
enviadas para uma estrutura conhecida como tópicos.
Message Queuing
Message Passing
Web Services
• São serviços que podem ser descritos, 
publicados, localizados e invocados em uma 
rede, normalmente a Web, utilizando 
protocolos padrões, independentes de 
linguagem e plataforma.
• Web Services podem ser desenvolvidos 
utilizando qualquer linguagem de programação 
e instalados em qualquer plataforma. 
Web Services
• Além disso, Web Services utilizam XML 
(eXtensible Markup Language) para descrever 
suas interfaces e codificar suas mensagens.
• Pelo fato de toda a comunicação ser realizada 
utilizando padrões consolidados, como HTTP e 
XML, qualquer aplicação é capaz de entender 
mensagens de Web Services.
SOAP (Simple Object Access 
Protocol) 
• SOAP não é um protocolo de comunicação na 
acepção da palavra, visto que para a 
comunicação ser realizada é preciso que um 
protocolo de comunicação como HTTP ou 
SMTP encapsule o conteúdo SOAP. 
• O SOAP Envelope, consiste basicamente de 
um cabeçalho (header) e um corpo (body).
WSDL (Web Services Description 
Language)
• Define onde o serviço está disponível e 
que protocolo de comunicação deve ser 
utilizado para chamar um serviço. 
• Uma descrição WSDL define o serviço 
como uma coleção de pontos finais de 
rede ou portas. Cada porta possui um 
tipo, que suporta uma coleção de 
operações.
UDDI (Universal Description, 
Discovery and Integration Service)
• Permite o registro e a localização de Web 
Services. 
• Utilizando o registro UDDI, um cliente pode se 
conectar dinamicamente a Web Services. Para 
isso, é necessário que o servidor publique seus 
serviços no registro UDDI, utilizando WSDL 
para isso. 
Middleware da Próxima Geração
• Nos últimos anos, vem ganhando espaço 
um modelo emergente de computação 
distribuída, no qual se destacam 
aplicações móveis, ubíquas, multimídia 
ou que possuem requisitos de qualidade 
de serviço (QoS).
• As plataformas de middleware 
tradicionais provém abstração de rede, 
sistema operacional e opcionalmente de 
linguagem de programação, fornecendo 
um conjunto de serviços como nomes e 
segurança, mas falham em suportar o 
requisito de adaptação destas aplicações 
[Kon et al. 2002].
Exemplo
• Aplicações móveis, podem tirar proveito da sua 
corrente localização para fazer uma requisição ao 
servidor mais próximo, por questões de 
performance. 
• Além disso, aplicações móveis podem sofrer de 
perda temporária de conectividade enquanto estão 
em movimento, pondo por terra a suposição 
adotada por middlewares tradicionais, como OMG 
CORBA e Java RMI, de que existe uma conexão 
permanente entre cliente e servidor
• Para satisfazer as necessidades destas 
aplicações, o middleware da próxima geração 
precisa ser capaz de adaptar-se às mudanças 
de contexto ocorridas no ambiente em tempo 
de execução, enquanto preserva a qualidade 
de serviço necessária para a aplicação. 
Exemplo
• Se o tráfego da rede aumentou, o middleware 
pode dinamicamente adotar um novo algoritmo 
que aumente a compressão de dados. 
• Adicionalmente, como certas aplicações podem se 
beneficiar do conhecimento do contexto do 
ambiente de execução, o middleware da próxima 
geração deve fornecer transparência para as 
aplicações que desejem e ciência de contexto para 
as aplicações que necessitem [Kon et al. 2002].
• Em relação à configuração dinâmica de 
middleware, uma das técnicas mais utilizadas 
é a reflexão computacional. 
• Um middleware reflexivo, possuidor de uma 
auto-representação casualmente conectada, é 
capaz de modificar dinamicamente o seu 
comportamento através de inspeção e 
adaptação [Coulson 2002].
Dúvidas
	Slide 1
	Middleware
	Middleware
	Middleware
	Estrutura do Middleware
	Middleware Procedural
	Slide 7
	Stub
	Exemplo Stub
	Conclusão
	Middleware Orientado a Objetos
	Middleware Orientado a Objetos
	Slide 13
	RMI (Java Remote Method Invocation)
	RMI (Java Remote Method Invocation)
	Slide 16
	RMI (Java Remote Method Invocation)
	EJB (Enterprise Java Beans)
	EJB (Enterprise Java Beans)
	EJB (Enterprise Java Beans)
	Arquitetura EJB
	Arquitetura EJB
	Arquitetura EJB
	Slide 24
	CORBA
	Slide 26
	Slide 27
	Middleware Transacional
	Middleware Transacional
	Middleware Transacional
	Middleware Transacional
	Middleware Transacional
	Middleware Transacional
	Slide 34
	Middleware Transacional
	MOM (Message Oriented Middleware)
	MOM (Message Oriented Middleware)
	Message Queuing
	Message Passing
	Web Services
	Web Services
	SOAP (Simple Object Access Protocol)
	Slide 43
	WSDL (Web Services Description Language)
	Slide 45
	UDDI (Universal Description, Discovery and Integration Service)
	Middleware da Próxima Geração
	Slide 48
	Exemplo
	Slide 50
	Exemplo
	Slide 52
	Dúvidas