Sistemas distribuídos e Middleware

Middleware
Prof. Me. Hélio Esperidião
Middleware
• Termo que se aplica a uma camada de software que proporciona uma
abstração de programação assim como esconde a heterogeneidade
da rede, hardware, sistema operativo e linguagens de programação
usadas
Necessidade do Middleware
• Três problemas do processamento de dados:
• A integração de software proveniente de origens destinas
• O acesso ao software dentro e fora da empresa;
• O desenvolvimento rápido de aplicações
Middleware
• Torna transparente a distribuição.
• Resolve heterogeneidade de:
•
•
•
•
Hardware
Sistemas Operacionais
Redes
Linguagens de programação
• Provê um ambiente de desenvolvimento e de tempo de execução
para sistemas distribuídos
Características do Middleware
• O “Middleware” tem que estar disponível em diversas máquinas.
• Transferências tem que ser confiáveis.
• Tem que existir a garantia de que quando uma aplicação entrega uma
mensagem ao “Middleware” que o destino recebe a mensagem uma única
vez.
• Isto tem que acontecer mesmo que um computador ou a rede falhe.
• Adaptação ao tráfego
• A largura de banda do “bus” tem que suportar um aumento de tráfego
resultante do aumento do número de aplicações.
• Esta é uma característica de base muito importante já que o “Middleware” é
o esqueleto de qualquer aplicação.
Características do Middleware
• Estruturas de comunicação
• Uma aplicação pode comunicar com uma outra aplicação ou enviar uma única
mensagem para n destinos.
• Utilização de um nome.
• A aplicação que envia uma mensagem refere-se ao destino através de um
nome e não de um endereço físico.
• Esta característica permite a transferência de uma aplicação de um computador para
outro sem haver implicações nas aplicações que com ela comunicam.
Middleware” no modelo OSI
• O “Middleware” forma uma estrutura de comunicação independente dos
sistemas operacionais e da natureza da rede de comunicação usadas.
• O “Middleware” situa-se logo abaixo das aplicações. No modelo de
camadas OSI corresponderá as camadas superiores definindo o protocolo a
usar entre as aplicações.
• O “Middleware será suportado pelos protocolos das camadas inferiores (
TCP/IP, DECnet, SNA) e por mecanismos dos próprios sistemas operacionais
das máquinas onde são executadas as aplicações.
Middleware” no modelo OSI
Classificação Middleware
• Tipo de comunicação
• Linguagens p/ construção da aplicação
• Forma de disponibilização
• Ambiente de execução
Tipo de Comunicação
• Comunicação síncrona
• Baseada em chamadas de procedimentos
• Centrada “objeto/função”
• Exemplo: CORBA, RMI
• Comunicação assíncrona
• Baseado em filas
• Centrada na informação
• Exemplo: JMS
Linguagem da Aplicação
• Diversas linguagens
• IDL para descrição da interface do serviço
• Linguagem de programação para implementação do serviço
• e.g., CORBA (IDL CORBA) + Java
• única linguagem
• interface e implementação do serviço usando uma única linguagem
• e.g., RMI
Forma de Disponibilização
• Proprietário
• MQSeries (IBM)
• baseado em padrões
• CORBA
• código aberto
• Implementação aberta pode ser baseado em padrão e.g., JBOSS
Ambiente de Execução
• Computadores pessoais
•
•
•
•
Automação do negócio
Suporte à aplicações genéricas
Altamente renconfiguráveis
Facilidade de integração
• Embarcados
• Suporte à aplicações específicas
• Restrições de capacidade de processamento
• Desempenho e tempo-real são fundamentais
Soluções para o “Middleware”
• Transacional
• Message-based
• Remote-Procedure-Call.
• Middleware orientada por objetos
Middleware Transacional
• Suporte a transações síncronas
• Coordena requisições entre clientes e servidores
• Fornecem suporte (coordenação e sincronização) à execução de
transações de acesso à bases de dados.
• usado em sistemas de processamento de transações de alta escala
(banco)
Middleware Transacional
Middleware Transacional
• Exemplos:
•
•
•
•
CICS (IBM)
Encina (DCE-based)
OMG Object Transaction Service
Java Transaction Service
Middleware Transacional
• Vantagens
• Componentes se mantêm consistentes
• Bastante confiável
• Boa performance
• Escalonamento e priorização de solicitações
• Desvantagens
• Ausência de padronização para descrever serviços
• Executa numa menor quantidade de plataformas
• Bloqueios desnecessários
• Marshalling e unmarshalling implementadas manualmente
Message Oriented Middleware
• Trata-se de uma infraestrutura de software cliente/servidor que cria uma
camada entre as aplicações de alto nível e as plataformas onde estão
instaladas, substituindo a comunicação direta entre aplicações por um
sistema de troca de mensagens.
• Comunicação assíncrona.
• A MOM usa uma aproximação “send and forget”. Deste modo o emissor
não tem que esperar que o receptor receba a mensagem, basta-lhe esperar
que a mensagem seja transmitida e guardada na pilha de recepção do
receptor. Comunicação assíncrona permite independência temporal e
execução não bloqueante, pois os processos não são obrigados a esperar
uns pelos outros
Message-based Middleware(MOM)
• Um cliente pode enviar e receber mensagens de forma assíncrona de
qualquer outro cliente, conectados a um meio que fornece facilidades
para criar, enviar, receber e ler mensagens.
Message-based Middleware(MOM)
• Primitiva de interação: passagem de
mensagem
• Uso de filas temporárias de
mensagens
• Exemplos:
• MQSeries,
• Sun ONE Message Queue
• JORAM free
Message Oriented Middleware
• Vantagens
• Suporta comunicação em grupo
• Confiabilidade
• Amplo suporte a protocolos de rede
• Desvantagens
• Escalabilidade e heterogeneidade limitadas
• Pouca portabilidade por falta de padronização
Remote-Procedure-Call Middleware (RPC)
• Permite que chamadas de procedimentos cruzem os limites entre
máquinas diferentes
• Permite que clientes efetuem comunicação com servidores através
de chamadas de procedimentos.
• A chamada remota segue o modelo da chamada local sendo que o
procedimento chamado executa em um processo diferente
normalmente em um computador diferente.
Remote-Procedure-Call
RPC - Interfaces
• Interfaces são definidas usando uma Linguagem de Definição de
Interfaces (IDL)
• Especifica os procedimentos disponíveis remotamente
Remote-Procedure-Call Middleware (RPC)
Marshalling/Unmarshalling
• Marshalling
• Converter estruturas de dados em um formato no qual possam ser transmitidas
• Unmarshalling
• Remontar a estrutura de dados original a partir do formato serializado
Analogia
Marshalling
Unmarshal
char * marshal() {
char * msg;
msg=new char[4*(sizeof(int)+1)
+
strlen(name)+1];
sprintf(msg,"%d %d %d %d %s",
void unmarshal(char * msg) {
int name_len;
sscanf(msg,"%d %d %d %d ",
&dob.day,&dob.month,
&dob.year,&name_len);
name = new char[name_len+1];
sscanf(msg,"%d %d %d %d %s",
&dob.day,&dob.month,
dob.day,dob.month,dob.year,
strlen(name),name);
return(msg);
};
&dob.year,&name_len,name);
};
RPC: Marshalling e Unmarshalling
• Cliente A
• Deve converter os parâmetros para um formato que possa ser transmitido
por um protocolo de transporte (TCP, por exemplo).
• Este processo é chamado de marshalling.
• Servidor B:
• Deve converter mensagem recebida em uma estrutura de dados
• Este processo é chamado de unmarhalling.
• Processo de marshalling/unmarshalling é tedioso e sujeito a erros
• Portanto, deve ser automatizado pela plataforma de middleware
RPC - Marshalling/unmarshalling
• Marshalling/unmarshalling tem funcionamento interno baseado em
módulos chamados de stubs.
• Stubs: encapsulam detalhes de comunicação no cliente e servidor
• Automatizam processo de marshalling e unmarshalling
• Automatizam comunicação com o processo remoto (interagindo com o
protocolo de transporte)
RPC: Arquitetura Interna
RPC: Arquitetura Interna
RPC: Arquitetura Interna
Resumo
• Stub cliente envia a requisição e espera até que o servidor termine
• Stub servidor espera por requisições e chama o objeto servidor quando a
requisição chega
Middleware Orientados por Objetos(MOO)
• Evolução dos middlewares procedurais.
• Interação por invocação de métodos.
• Comunicação tipicamente síncrona.
• Ideia básica: objetos clientes podem chamar métodos de objetos
remotos com transparência de acesso (isto é, com a mesma sintaxe
de chamadas locais)
• CORBA, Java RMI, DCOM, .NET Remoting etc
MOO
MOO
Middleware Orientado a Objetos (MOO)
• Vantagens
• Grande suporte a heterogeneidade
• Marshalling e unmarshalling automáticos
• Versatilidade
Middleware Orientado a Objetos (MOO)
• Desvantagens
• Pouca Escalabilidade
Linguagem de Definição de Interfaces
• Cada plataforma de middleware orientada a objetos possui uma
linguagem de definição de interfaces (IDL) própria.
Principais Middlewares
• Transacionais
• Tuxedo (BEA)
• CICS (IBM)
• Encina (Transarc)
• MOM
• MQSeries (IBM)
• JMS (Sun)
• MOO
• CORBA (OMG)
• COM (Microsoft)
• RMI
CORBA
• CORBA (Common Object Request Broker Architecture) é a arquitetura
padrão criada pelo Object Management Group para estabelecer e
simplificar a troca de dados entre sistemas distribuídos heterogêneos.
• CORBA atua de modo que os objetos (componentes dos softwares)
possam se comunicar de forma transparente ao usuário.
• CORBA é um dos modelos mais populares de objetos distribuídos
Object Request Broker
• Em computação distribuída, um object request broker (ORB), ou em
português agente de requisição de objetos, é uma parte de um
software middleware que permite que programadores façam
chamadas a programas de um computador para outro através de uma
rede de computadores.
Object Request Broker
Interoperabilidade
• Os ORBs promovem interoperabilidade de sistemas de objetos
distribuídos pois eles permitem que usuários desenvolvam sistemas
através da junção de objetos de diferentes fornecedores, podendo se
comunicar uns com os outros através do ORB.
ORB
• A arquitetura CORBA define o ORB (Object Request Broker) como um
módulo intermediário entre cliente e objeto, sendo responsável em
aceitar a requisição do cliente, enviá-la para o objeto competente e,
assim que disponível a resposta, entregá-la para o cliente.
DCOM - Distributed Component Object
Model
• DCOM é uma tecnologia proprietária da Microsoft para criação de
componentes de software distribuídos em computadores interligados
em rede.