acs05

Arquitetura
Cliente/Servidor
Parte V
Middleware
Eduardo Xavier
UNIFACS – Universidade Salvador
Prof.
Email:
Introdução
• Toda vez que separamos uma aplicação em componentes e
colocamos esses componentes em máquinas separadas suge
um novo problema: como estes componentes vão interagir
entre si?
– Devemos providenciar uma forma de comunicação
• Middleware é um termo genérico para todos as ferramentas de
software que ajudam a conectar as diversas camadas e
componentes de um sistema distribuído
– Dependendo do modelo de distribuição adotado, isso pode significar
coisas bem diferentes de ambiente para outro
• Do início da década de 1990 até hoje, o middleware
cliente/servidor creceu rapidamente (especialmente nos
últimos anos)
– Diversas filosofias, tecnologias e abordagens
www.redes.unifacs.br
Definição
• O que é Middleware?
– Segundo Cris Loosley, em “High Performance Client/Server”, o
problema em definir middleware é que grande parte da literatura
técnica se preocupa mais em estabelecer “o que não é” do que “o que
é” middleware.
– Assim, se o software em questão não for enquadrado em nenhuma
outra categoria conhecida, como SGBDs, programas de aplicação ou
sistema operacional, então é associada ao termo middleware
– Em termos realísticos, middleware é computação cliente/servidor, por
que provê os meios pelos quais clientes e servidores estabelecem sua
comunicação.
• Podemos considerar middelware como:
– Um conjunto de drivers, APIs, ou outro software que melhora a
conectividade entre uma aplicação do cliente e um servidor
– Um conjunto de serviços encarregado de fornecer meios para
comunicação e distribuição, oferecendo transparência à
aplicação
www.redes.unifacs.br
Justificativa Técnica
• Por que vale a pena adotar Middleware?
– Porque construir sistemas distribuídos
diretamente sobre a camada de transporte da
rede é muito mais difícil.
• Comunicação em geral precisa manipular o envio de
parametros complexos
• Diferentes codificações de tipos de dados
• Desenvolvedores e administradores teriam que
implementar a ativação de componentes
• Implementar sincronização é complexo e propenso a
erros
www.redes.unifacs.br
Objetivo
• O Middleware se propõe a:
– Ser uma camada adicional de software usada para ocultar a
heterogeneidade da coleção de plataformas
• Melhorar e simplificar a distribuição, o encapsulamento e a transparência.
– Estar entre as aplicações e o sistema operacional de rede,
oferecendo um alto nível de abstração.
• Assim, tais aplicações não fazem uso direto da interface de programação.
– Permitir que uma aplicação ou um usuário em um cliente
acesse uma variedade dos serviços no servidor sem que
haja preocupação sobre diferenças entre usuários.
– Oferecer portabilidade para componentes de aplicações
distribuídas
– Aumentar a interopreabilidade em aplicações distribuídas
www.redes.unifacs.br
Camadas
• O middleware pode ser decomposto em camadas
de funcionalidades
Aplicações
Serviços de Middleware Específicos do Domínio
Camadas
de
Serviços Comuns de Middleware
Middleware
Middleware de Distribuição
Middleware de Infra-estrutura do Hospedeiro
Sistema Operacional e Protocolos
Hardware
www.redes.unifacs.br
Camada: Middleware de
Infra-estrutura do Hospedeiro
• Esta camada encapsula e
potencializa a comunicação
nativa do sistema operacional e
seus mecanismos para controle
de concorrência para criar uma
rede de componentes
reutilizáveis.
• Estes componentes abstraem as
peculiaridades individuais de
cada ambiente e ajudam a
eliminar diversos aspectos
trabalhosos, não portáveis e
sujeitos a erros de quem
manipula diretamente as APIs
de programação em baixo nível
do sistema operacional local
www.redes.unifacs.br
Camada: Middleware de
Infra-estrutura do Hospedeiro (cont.)
• Exemplos:
– Sun Java Virtual machine (JVM)
• Provê um meio independente de plataforma de executar código
Java através da abstração de diferenças entre sistemas operacionais
e arquiteturas de CPU.
• A JVM é responsável pela interpretação de bitecode Java e por
traduzir isso em ações ou chamadas ao sistema operacional,
encapsulando detalhes da plataforma hospedeira
– .NET
• Plataforma da Microsoft para Web Services em XML, projetada
para conectar informações, serviços e pessoas de uma forma
customizada.
• A solução é totalmente construída de forma similar à JVM,
provendo um ambiente para execução que gerencia códigos
executáveis e simplifica o desenvolvimento de software de mais
alto nível
www.redes.unifacs.br
Camada: Middleware de
Distribuição
• Define os modelos de
programação de mais alto
nível, cujas APIs
automatizam e ampliam as
capacidades de programação
nativas do SO, que foram
encapsuladas na camada de
middleware de infra-estrutura
do hospedeiro
• Permitem a inteligação de
aplicações remotas de forma
transparente
www.redes.unifacs.br
Camada: Middleware de
Distribuição
• O coração desta camada é o que se chama de “request
broker”. Alguns exemplos de request brokers:
– RMI (Remote Method Invocation)
• Desenvolvido pela Sun Microsystems, este middleware de distribuição
permite que desenvolvedores criem aplicações distribuídas em Java,
onde os métodos remotos possam ser invocados a partir de outras
JVMs a partir de hospedeiros diferentes.
• O modelo RMI só funciona para Java, mas graças a JVM, executa em
diversas plataformas
– CORBA (Common Object Request Broker Architecture)
• Padrão aberto de distribuiçao que permite que objetos interajam
através de uma rede sem preocupações com compatibilidades de
linguagem de programação ou plataforma
www.redes.unifacs.br
Camada: Middleware de
Distribuição (cont.)
• Mais exemplos de request brokers:
– DCOM (Distributed Component Object Model)
• Criado pela Microsoft, este modelo permite que componentes de
software se comuniquem remotamente a partir de instanciamento e
invocação de métodos.
• Diferente das soluções CORBA e RMI, que executam em qualquer
sistema operacional, o modelo DCOM é exclusivo da plataforma
Windows
– SOAP (Simple Object Access Protocol)
• Tecnologia baseada em um protocolo simples e leve estruturado em
XML que permite que aplicações troquem informações estruturadas
via web.
• Pode ser escrita em uma ampla gama de linguagens de programação e
usada de forma combinada com diversos protocolos e formatos internet
(HTTP, SMTP, MIME, ...) e RPC
www.redes.unifacs.br
Camada: Serviços Comuns de
Middleware
•
•
Serviços independestes de alto
nível que permitem que
desenvolvedores de aplicações se
concentrem em programas
apenas a lógica de negócio, sem
a necessidade de escrever o
código responsável pela
distribuição da aplicação (que
fica nas camadas anteriores)
O desenvolvedor não precisa
mais escrever o código que lida
com o comportamento de
transações, segurança, conexão
com o banco de dados, etc. por
que isso tudo é provido pela
camada de serviços comuns do
middleware na forma de
componentes reutilizáveis
www.redes.unifacs.br
Camada: Serviços Comuns de
Middleware (cont.)
•
Exemplos:
– CORBA (Common Object Request Broker Architecture)
• Provê independência de domínio nas interfaces e capacidades que podem ser
usadas por diversas aplicações
• Existem diversos serviços disponíveis, tais como notificação de eventos,
streaming, persistência, segurança,...
– EJB (Enterprise Java Beans)
• Tecnologia da Sun Microsystems que permite aos desenvolvedores criar SDs ncamadas ligando um certo número de serviços pré-fabricados (chamados de
“beans”) sem necessidade de muita codificação
• Por ser construído no topo da especificação da tecnologia Java, os componentes
EJB só podem ser implementados nessa linguagem, mas existe uma
especificação no modelo CORBA que também aceita outras linguagens
– Web Services .NET
• Complementação da plataforma .NET que permite aos desenvolvedores
“empacotar” sua lógica de aplicação em componentes que são acessados
usando protocolos internet de alto nível (como HTTP).
• Os web services funcionam em uma filosofia de “caixa-preta”, que descreve a
interface sem se preocupar com a forma como o serviço foi implementado
• Diferente dos modelos tradicionais, os web services .NET não são acessados
usando os protocolos definidos pelas tecnologias CORBA, RMI e DCOM, e
sim usando XML e protocolos web
www.redes.unifacs.br
Camada: Serviços de Middleware
Específicos do Domínio
•
•
•
São confeccionados a partir dos
requerimentos particulares de cada
domínio, como telecomunicações, ecomerce, saúde, automação de
processos ou indústria areoespacial.
Diferente das demais camadas, que
provêem mecanismos e serviços
reutilizáveis “horizontais”, esta
camada enfoca alvos “verticais”
(voltados apenas para o domínio
específico a que se dedica)
É a camada que tem maior potencial
para aumentar a qualidade de um
sistema e reduzir tempo e esforços
gastos no desenvolvimento de
aplicações específicas
.
www.redes.unifacs.br
Camada: Serviços de Middleware
Específicos do Domínio (cont.)
• Exemplos:
– O OMG (Object Management Group) criou diversas “Domais Task
Forces” concentradas em padronizar serviços de middleware com
foco específico em certas áreas, como o comércio eletrônico,
pesquisas biológicas, automação de processos
– O Siemens Medical Engineering Group desenvolveu o Syngo, que é
tanto uma coleção integrada de servicós de middleware quanto uma
plataforma aberta de aplicações voltadas para tarefas relacionadas a
tratamento de imagens (ultra-som, radiografia, tomografia,
ressonância magnética, medicina nuclear, monitoramento de
pacientes,...)
– A Boing lançou uma arquitetura não-propietária chamada “Bold
Stroke” de componentes voltados para ampliar as capacidades
computacionais de aplicações em aviação militar, como navegação
computadorizada, conrole de armas, sensores, etc.
– Outros domínios onde é comum a adoção de middleware específico:
• Telecomunicações, comércio eletrônico, computação móvel, automação,
energia, ...
www.redes.unifacs.br
Benefícios do Uso de
Middleware em Camadas
• Aumento do foco na integração, substituindo a programação
• Maior demanda por qualidade de ponta-a-ponta, não apenas
pala qualidade de cada componente
• Aumento de viabilidade de sistemas abertos
• Incentivo ao desenvolvimento baseado na “Lei da Disrupção”,
reduzindo custos e aumentando a competição global
• Potencial encapsulamento de complexidade para as próximas
gerações de sistemas complexos
• Esconde do programador de aplicações distribuídas as
diferenças entre:
•
•
•
•
•
•
Plataformas de hardware
Sistemas operacionais
Bibliotecas e protocolos de comunicação
Formatação de dados
Linguagens de programação
Modelos de programação
www.redes.unifacs.br
Modelos de Construção
• Para simplificar o desenvolvimento e a integração de
aplicações distribuídas, a maioria dos produtos oferecidos
na categoria de middleware se baseia em um ou mais
modelos (paradigmas) de distribuição e comunicação
• Os quatro modelos mais conhecidos são:
– Modelo Remote Procedure Call (RPC)
• Permitem que um cliente acione funções que se processam remotamente por
meio de troca de mensagens
– Modelo Transacional (TPs)
• Também conhecidos como “Transaction Processing Monitors”, se focam no
controle de transações envolvendo componentes que executam em hosts
distribuídos
– Modelo Orientado a Mensagens (MOMs)
• Residem nos dois lados da arquitetura cliente/servidor e suportam chamadas
assíncronas entre aplicações
– Modelo Object Request Broker (ORB)
• Permitem que uma aplicação seja composta de objetos distribuídos em redes
heterogêneas
www.redes.unifacs.br
Modelos de Construção:
O Modelo Remote Procedure Call
• Como funciona:
– RPC permite que programas chamem procedimentos localizados em
outras máquinas sem saber que esta chamada é remota.
• Isso é feito durante a compilação dos componentes, por meio da inclusão de
códigos chamados “stubs”, que se responsabilizam por proteger os programas de
aplicação de detalhes de comunicação em mais baixo nível (exemplo: sockets)
– É preciso existir algum dispositivo que tenha uma lista dos serviços
remotos disponíveis e suas localizações na rede. Este serviço é
chamado binder
• Principais características
– O RPC é um método de tranferência de controle de execução
– É um método de transferência de controle
• Quem aciona o procedimento remoto suspende sua execução e fica aguardando o
retorno do mesmo (ou seja, passa o controle da execução adiante)
• O procedimento remoto assume o controle, executa suas funções e devolve o
controle para quem o acionou
• O acionador retoma sua execução do ponto em que parou
• Uma chamada remota de procedimento usa comunicação direta e síncrona
www.redes.unifacs.br
Modelos de Construção:
O Modelo Remote Procedure Call
www.redes.unifacs.br
Modelos de Construção:
O Modelo Transacional
• Como funciona:
– Se baseia no mapeamento de pedidos de clientes por meio de serviços
de aplicação (rotinas) localizadas em um servidor.
– Essa tecnologia controla transações, computações de regras de negócio
e atualizações em banco de dados
• Principais características
– É usado em aplicações que demandam rapidez na execução de
transações remotas
– É uma alternativa de baixo custo para atualização de sistemas legado
com bases de dados grandes e plataformas complexas
– Inclui aspectos de gerenciamento (exemplo:balanceamento dinâmico
de carga)
– Usa chamadas de procedimento remoto associadas a controle de
transações
– É independente da arquitetura de banco de dados
– Escalabilidade, flexibilidade e robustez
– É capaz de efetuar comunicação síncrona e assíncrona
www.redes.unifacs.br
Modelos de Construção:
O Modelo Transacional
www.redes.unifacs.br
Modelos de Construção:
O Modelo Orientado a Mensagens
•
Como funciona:
– Reside tanto no lado cliente quanto no lado servidor
– Cada lado possui uma fila de mensagens
– Sempre que o programa destino da mensagem está ocupado ou desconectado,
a mensagem é colocada na fila
– Um gerente de filas rodando em separado gerencia as filas e garante que não
importa o que ocorra na rede, apenas uma cópia da mensagem eventualmente
chega ao seu destino
– O armazenamento de mensagens é temporário (são apagadas a medida que são
atendidas)
•
Principais características:
– As filas permitem que cada lado funcione de forma assíncrona em relação ao
outro
– Aumenta a interoperabilidade, portabilidade e flexibilidade da aplicação
– Suporta plataformas heterogêneas
– A comunicação entre um processo e o gerente de filas geralmente é síncrona
– Altamente tolerante a falhas
– Fica a cargo do desenvolvedor de aplicações garantir que emissores e
receptores conhecem o formato da mensagem
www.redes.unifacs.br
Modelos de Construção:
O Modelo Orientado a Mensagens
• O MOM é usado quando a comunicação assíncrona confiável
é a forma dominante de interação de um sistema distribuído
• Variações do MOM:
– Message Queueing (baseado em fila)
• Usa filas de mensagem conforme já foi descrito anteriormente
• Geralmente usado em ambientes orientados à transação
• Não há conexão direta entre as partes
– Publish/Subscribe
• Subscribe:
–
Clientes se registram para receber mensagens de uma determinada fila
• Publish:
–
O middleware envia mensagens deste fila para os clientes registrados
• Exemplos:
– MSMQ da Microsoft
– Java Message Service (JMS) da SUN
– Tuxedo/Q da BEA Systems
www.redes.unifacs.br
Modelos de Construção:
O Modelo Orientado a Mensagens
www.redes.unifacs.br
Modelos de Construção:
O Modelo Object Request Broker
•
Como funciona:
– Um ORB (Object Request Broker) age como um intermediário para as requisições
que os clientes enviam para os servidores
– O ORB serve como distribuidor de comunicação entre agrupamento de objetos
(componentes de software) em diferentes máquinas, diferentes softwares e diferentes
fornecedores
– Os desenvolvedores da aplicação deixam de se preocupar com detalhes referentes à
implementação do ORB e se concentram apenas na interface de cada objeto (como
acionar o objeto e o que esperar como resposta)
– Cada ORB provê uma lista de serviços e colabora no estabelecimento da conexão
entre cada cliente e estes serviços
– Cada ORB pode ser implementado de diversas formas. Por exemplo
• Compilados dentro do cliente
• Processados separadamente
• Ser parte do kernel de um sistema operacional
•
Principais caractrísticas:
– Fornece transparência de localização e suporte a arquiteturas heterogêneas
(interoperabilidade)
– Esconde detalhes de implementação dos objetos (linguagem, sistema operacional,
hardware,...)
www.redes.unifacs.br
Modelos de Construção:
O Modelo Object Request Brokers
www.redes.unifacs.br