Middleware Reflexivo

Middleware Reflexivo Construindo Sistemas Distribuídos Flexíveis, Adaptáveis e Reconfiguráveis Prof. Dr. Fabio Kon Departamento de Ciência da Computação IME / USP 21 de maio de 2003 SBRC’2003 - Natal, RN

O que é “Middleware”? Software que reside entre o sistema operacional e a aplicação a fim de facilitar (simplificar) o desenvolvimento de aplicações. Middleware SO Aplicação

O que é “Middleware de Comunicação”? Middleware cujo objetivo é facilitar o desenvolvimento de aplicações e sistemas distribuídos. Cliente Servidor Middleware Middleware

Benefícios do Middleware de Comunicação esconde do programador diferenças entre plataformas de hardware sistemas operacionais bibliotecas de comunicação protocolos de comunicação formatação de dados linguagens de programação modelos de programação

Esconde as Heterogeneidades Middleware Linux PC Middleware Windows PC Middleware Solaris Sparc Middleware MacOS iMAC Middleware PalmOS Palm

Outros Benefícios Gerenciamento de Nomes e Referências Ativação Automática de Serviços Seleção do Receptor das Mensagens Migração de Serviços Controle de Qualidade de Serviço (QoS) Gerenciamento de Concorrência único thread, thread para cada serviço, para cada cliente, pool de threads etc. Gerenciamento de Conexões

Serviços Padronizados Nomes Negociação ( Trading ) Tolerância a Falhas Segurança Transações Persitência etc. etc.

Principais Plataformas de Middleware Existentes CORBA da OMG J2EE da Sun (também J2ME e J2SE) DCOM da Microsoft .NET da Microsoft (ainda em formação)

Conclusão Parcial Sistemas de middleware facilitam enormemente a criação de aplicações distribuídas complexas. Mas o mundo está se tornando mais dinâmico a cada dia. O middleware convencional está preparado para os desafios das próximas décadas?

Limitações dos Primeiros Sistemas de Middleware Modelo de concorrência fixo Protocolo de transporte fixo (e.g., IIOP /TCP/IP) Estratégia de segurança fixa ( normalmente nenhuma ) Algoritmo de escalonamento fixo Formatação de dados fixa Arquitetura monolítica tudo ou nada  sistemas enormes

Ambientes onde arquiteturas fixas e monolíticas não funcionam Sistemas Altamente Dinâmicos Computação Móvel Computação Ubíqua Multimídia Sistemas Especializados Sistemas embutidos ou dedicados Aplicações adaptativas

Paradoxo do Middleware A maior parte das aplicações necessitam que o middleware esconda os detalhes das camadas inferiores. Algumas aplicações podem obter grandes melhorias em desempenho se puderem observar e manipular os detalhes das camadas inferiores.

Solução: Modelo Reflexivo para Middleware Middleware Reflexivo: Oferece transparência para as aplicações que a desejam. Permite a inspeção e manipulação dos detalhes internos do Middleware e do SO para as aplicações que necessitarem.

Middleware Reflexivo Cliente Servidor Middleware Middleware meta-interface interface convencional

Interfaces Interface Convencional permite a execução de aplicações convencionais Meta-Interfaces inspeção dos componentes internos do middleware alteração da configuração interna do middleware inspeção do estado dinâmico do middleware inspeção do estado dinâmico do SO inspeção da configuração estática do SO e do HW

Reflexão Computacional Si stem a s Reflexivos [Smith 84] Meta-Object Protocol (MOP) [Kiczales 91] ORBs Reflexivos [Singhai and Campbell 97] Reflexão: “pensar” sobre si mesmo. manter representação de sua estrutura interna inspecionar configuração interna alterar configuração interna

Exemplos de Sistemas de Middleware Reflexivos dynamicTAO University of Illinois at Urbana-Champaign Open ORB Lancaster University UIC UIUC / UbiCore Outros LuaORB, LORB, mChaRM, COMERA, OpenCOM

dynamicTAO Extensão do ORB CORBA TAO [Schmidt et al] Escrito em C++ Design m odular baseado em padrões de projeto OO. TAO já permitia configuração no momento da inicialização: modelo de concorrência (thread s ) demultiplexação de mensagens escalonamento gerenciamento de conexões

Acrescentando Suporte para Reconfiguração Dinâmica dynamicTAO exporta a interface DynamicConfigurator que permite: 1. Transfer ência de component e s através da Internet. 2. Carga e descarga dinâmica de component e s . 3. Inspe ção e modificação da configuração do ORB (e das aplicações sendo executados sobre ele).

Reificação da Es trutur a do ORB Arcabouço ComponentConfigurator Armazena dependências entre componentes. Permite navegação, inspeção e reconfiguração. Pode ser personalizado através de herança OO.

DOCTOR D ynamic O RB C onfiguration T ool

Reconfigura ção com Agent e s Móveis Para sistemas de grande escala Agent e carrega gra fo script de reconfiguração estado result ados

Aplicações de dynamicTAO Monitoramento configurável Segurança controle de acesso com DAC, MAC, RBAC. Distribuição escalável de multimídia QoS em multimídia (MONET @ uiuc) Base do SO experimental 2K (SRG @ uiuc)

Open ORB Construído a partir do zero no modelo reflexivo Componentes: implementam os vários elementos funcionais do ORB Instâncias personalizadas da plataforma: produzidas através da combinação dos componentes apropriados Modelo de componentes composição hierárquica distribuição componentes como entidades de tempo de execução

Open ORB: Reconfiguração Dinâmica Reflexão como princípio fundamental Uma clara separação entre nível base : componentes que implementam os serviços usuais de middleware meta-nível : mecanismos que reificam a implementação da plataforma inspeção e adaptação dinâmica O meta-nível é definido utilizando o mesmo modelo de componentes do nível base reflexão pode também ser aplicada ao meta-nível

Open ORB: Múltiplos Modelos de Meta-espaço

Open ORB: Meta-espaço de Interfaces Representação externa de um componente conjunto de interfaces exportadas operações e atributos de uma interface MOP: Inspeção busca e enumeração de interfaces enumeração das operações e atributos de uma interface

Open ORB: Meta-espaço de Arquitetura Representação interna de um componente Arquitetura de software do componente grafo de componentes interconexões entre os componentes mais primitivos que compõem o componente reificado restrições arquiteturais regras para validar configurações de componentes facilitam a manutenção da consistência do ORB após reconfigurações

Open ORB: Modelo de Arq uitetura – Exemplo Grafo de componentes Restrições arquiteturais Componente A depende do componente C Componente D não pode ser substituído ou removido Interface 1 do componente B só pode ser ligada a uma interface exatamente equivalente

Open ORB: Meta-espaço de Interceptadores Permite adaptar as propriedades não-funcionais associadas às interfaces de componentes, tais como segurança e sincronização em tempo real Pré- e pós-processamento das interações emitidas e recebidas em uma interface Interceptadores podem ser adicionados ou removidos dinamicamente em pontos arbitrários da implementação da plataforma

Open ORB: Meta-espaço de Recursos Acesso padronizado aos recursos subjacentes da plataforma aos mecanismos utilizados para o seu gerenciamento Inspeção e reconfiguração recursos alocados a tarefas específicas quantidade alocada parâmetros associados aos recursos prioridades, algoritmos de gerenciamento Fundamental para o gerenciamento de QoS em ambientes dinâmicos

Open ORB: Protótipos OOPP – Open ORB Python Prototype OpenCOM

dynamicTAO e Open ORB: Considerações gerais Dois projetos independentes, mas com motivações muito parecidas levaram ao mesmo modelo arquitetural: reflexão dynamicTAO re-engenharia de TAO para adicionar flexibilidade de tempo de execução. Open ORB projeto e implementação do middleware em função dos princípios de reflexão computacional.

Middleware (Enxuto) Baseado em Componentes Uso da tecnologia de componentes de software para construção da plataforma. Serviços e mecanismos do ORB implementados como componentes implementações alternativas com propriedades diferentes. Plataforma pode ser configurada com apenas os componentes necessários.

UIC Universally Interoperable Core UIUC e ubi-core.com A configuração de componentes pode ser alterada em tempo de execução adicionar, substituir, remover componentes Implementação de diferentes personalidades de ORB Ex.: CORBA, Java RMI

UIC: configuração abstrata Um esqueleto de ORB com componentes abstratos (ganchos) representando os tipos de funcionalidades comuns de middleware: protocolos de comunicação mecanismos de gerenciamento de conexões seriação e de-seriação chamada de métodos escalonamento geração de referências de objetos APIs para clientes e servidores gerenciamento de memória e concorrência

UIC: configuração concreta Implementações concretas de cada componente abstrato são carregados dinamicamente. Diferentes personalidades de ORB podem ser criadas. Permite atender aos requisitos de aplicações específicas.

UIC: reconfiguração dinâmica Mecanismos internos do ORB podem ser reconfigurados em tempo de execução substituição da implementação de componentes abstratos. Por exemplo: variação de conectividade computador móvel em rede com fio: TCP deslocamento para uma rede sem fio: WTCP mecanismos de transporte otimizados para cada ambiente.

UIC: Configurações Enxutas Middleware para um cliente minimal adotando personalidade CORBA: 29KB no Windows CE 72KB no Windows 2000 18KB no PalmOS Middleware minimal para cliente / servidor 48.5KB no Windows CE 100KB no Windows 2000 31KB no PalmOS Conclusão: ideal para sistemas embutidos

Outros Sistemas de Middleware Reflexivo mChaRM (U. Genova, Ítália) COMERA (Microsoft) AspectIX (Friedrich-Alexander U., Alemanha) LuaORB (PUC-Rio) Meu foco atual: LORB (PUC-Rio) (Projeto InteGrade)

O Futuro do Middleware Arquiteturas convencionais de middleware tem adotado os resultados de pesquisas em middleware reflexivo Ex.: interceptadores em CORBA, carga dinâmica de componentes em Orbix, arquitetura do JBoss. Middleware existente está se tornando mais flexível e reconfigurável: abordagem ad hoc. Entretanto, a natureza de “caixa preta monolítica” de middleware convencional limita o quanto da implementação da plataforma pode ser exposta.

O Futuro que Esperamos Adoção de reflexão como princípio básico para o design de middleware. Quais seriam os benefícios: solução genérica, abertura abrangente dos aspectos internos da plataforma, manipulação e adaptação da implementação da plataforma de maneiras não previstas a priori.

O que ainda falta fazer? Definição de um padrão internacional para middleware reflexivo de forma a garantir interoperabilidade. Pesquisa teórica e prática em ferramentas para garantia de consistência em reconfigurações dinâmicas. Uso de middleware reflexivo por aplicações variadas. Bibliotecas de mecanismos automatizados para adaptar o middleware em tempo de execução com o objetivo de facilitar a construção de aplicações adaptativas.

International Workshop on Reflective Middleware 1 st Workshop on Reflective Middleware junto com Middleware’2000 em NY 2 nd Workshop on Adaptive and Reflective Middleware junto com Middleware’2003 no Rio em junho Em ambos os casos os artigos estão disponíveis na Web.

Conclusões Middleware Reflexivo já é um conceito bem conhecido e aceito na comunidade acadêmica de middleware. A penetração em sistemas e padrões comerciais está avançando (mas mais lentamente do que gostaríamos). É uma área de pesquisa ativa.

M aiores I nforma ções Visão geral sobre Middleware Reflexivo: www.ime.usp.br/~kon/papers/cacm02.pdf Grupo de Sistemas Distribuídos do IME/USP: http://gsd.ime.usp.br

Middleware Reflexivo

Mais conteúdo relacionado

Mais procurados (20)

Destaque (8)

Semelhante a Middleware Reflexivo (20)

Mais de elliando dias (20)

Último (19)

Middleware Reflexivo