UNIFACS – Universidade Salvador Prof.Email: Arquitetura Cliente/Servidor Parte V Middleware Eduardo Xavier.

Apresentação em tema: "UNIFACS – Universidade Salvador Prof.Email: Arquitetura Cliente/Servidor Parte V Middleware Eduardo Xavier."— Transcrição da apresentação:

1 UNIFACS – Universidade Salvador Prof.Email: Arquitetura Cliente/Servidor Parte V Middleware Eduardo Xavier

2 www.redes.unifacs.br 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

3 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: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

4 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

5 www.redes.unifacs.br Objetivo O Middleware se propõe a:O Middleware se propõe a: –Ser uma camada adicional de software usada para o cultar a heterogeneidade da coleção de plataformas Melhorar e simplificar a distribuição, o encapsulamento e a transparência.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.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

6 www.redes.unifacs.br Camadas O middleware pode ser decomposto em camadas de funcionalidades Aplicações Middleware de Infra-estrutura do Hospedeiro Sistema Operacional e Protocolos Hardware Middleware de Distribuição Serviços Comuns de Middleware Serviços de Middleware Específicos do Domínio Camadas de Middleware

7 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

8 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

9 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

10 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

11 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

12 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

13 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 n- camadas 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

14 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, e- comerce, 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.

15 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,...

16 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

17 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

18 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

19 www.redes.unifacs.br Modelos de Construção: O Modelo Remote Procedure Call

20 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

21 www.redes.unifacs.br Modelos de Construção: O Modelo Transacional

22 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

23 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

24 www.redes.unifacs.br Modelos de Construção: O Modelo Orientado a Mensagens

25 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,...)

26 www.redes.unifacs.br Modelos de Construção: O Modelo Object Request Brokers