Padrões de Projeto Implementados em Infraestrturas de Componentes

Transcrição

1 Padrões de Projeto Implementados em Infraestrturas de Componentes Paulo Pires http//genesis.nce.ufrj.br/dataware/hp/pires 1

2 distribuídas baseadas em componentes Comunicação transparente, independente de plataforma. Estratégias de ativação para componentes remotos. Propriedades Não-funcionais tais como desempenho, escalabilidade, qualidade de serviço. Mecanismo para encontrar e criar componentes remotos. Manutenção de estado persistente e consistente. Questões de segurança. Transformação de dados. Configuração e Distribuição. Usando Middleware OO Padrão Que tal usar CORBA, DCOM, ou RMI? Sim, eles fornecem um OO-RPC, Mas: desenvolvedores devem integrar serviços tais como transação ou segurança por eles mesmos. Integração feita pelos desenvolvedores pode tomar mais de 50% do tempo de desenvolvimento. Conclusão: Um RPC orientado a objeto ajuda a conectar diferentes ilhas de código, mas não é suficiente para construir a camada intermediária. 2

3 Arquitetura de componentes para a camada intermediária Vamos introduzir passo a passo alguns dos elementos de arquitetura necessários para construir Infra-estruturas sofisticadas de componentes da camada intermediária. Comunicação!"#$!"%$ & '"#"((" 3

4 Comunicação Síncrona ) *+ ) Padrão Proxy # ",-" 3 3 &. / 0 () 1 / 0 $) 1",- ' )2",-.. ) ",- ) 4

5 Dinâmica (' ' (' ' Proxy++ Porém, usar proxies não é suficiente: Como localizar componentes remotos? Como lidar com o estabelecimento da comunicação e a troca de pacotes de rede (o protocolo)? 5

6 Middleware Orientado a Objeto O que precisamos é uma arquitetura que... suporte o paradigma da invocação remota de métodos forneça transparência de localização permita acrescentar, mudar, ou remover serviços dinamicamente esconda os detalhes do sistema do desenvolvedor Padrão de Arquitetura : Broker # " " # #!! # " " 6

7 Broker - Dinâmica,- 4 '4 ' Prós Benefícios e Responsabilidades Broker e Proxies escondem detalhes de comunicação Detalhes do SO também são escondidos Interoperabilidade com outros brokers (pontes) Reusabilidade de serviços Transparência de Localização Reconfiguração Dinâmica Contras Eficiência restrita devido a indireção Multiplos pontos de falha Testes e depuração de erros mais difíceis, como acontece com todos os sistemas distribuídos 7

8 Geração das Classes Utilitárias? Quem é o responsável por implementar todos esses factories, proxies, etc.? Ferramentas Geradoras fornecem a geração de artefatos necessários para definição de dados de linguagens de alto nível: % & $ Problema: Ativação Não é factível ter as implementações no servidor rodando todas ao mesmo tempo. Então, tem de haver um modo de ativar os servidores sob demanda. Qual estratégia de ativação um broker deve adotar? 8

9 Solução Integrar código de ativação para iniciar automaticamente implementações no servidor. Fornecer informações necessárias em tabelas: À medida que os pedidos chegam, o Ativador verifica se um objeto destino já está ativo. Se o objeto nao está rodando, ele ativa a implementação. A Tabela de ativação guarda associações entre serviços e suas localizações físicas. O Cliente usa o Ativador para ter acesso ao serviço. Um Serviço implementa um tipo específico de funcionalidade que ele fornece aos clientes. Solução 5# ) * * * * '( 9

10 Dinâmica: Cenário de Exemplo ) '# 78 % #9 6- '- '- Comunicação Assíncrona e Independente de Tempo Usando semântica convencional os brokers suportam apenas comunicação síncrona: Os clientes devem esperar até que suas chamadas retornem. Mesmo se eles usarem multi-threading os brokers subjacentes irão bloquear. Um receptor (receiver) deve estar ativo (online). Porém, isto nem sempre pode ser garantido. 10

11 Solução :;. & * ; ' ). ') ' / ) 1 ' ) 1 %": ' 0. ') Solução <<==! %! <<9== + <<== + <<==, <<==! % 11

12 Dinâmica! % + +! %! ' ' '.9, ' ' Ponto de Vista do Desenvolvedor Desenvolvedores OO preferem a semântica de pedido/resposta (request/response): Dois tipos de mensagem são usados: Pedidos (requests) contêm argumentos in / in-out Resultados (results) carregam argumentos out / in-out e resultados Objeto Callback ou Poller para recuperar resultados. Estratégia Player/Recorder : Recorder enfileira a parte pedido da chamada, Player despacha para a implementação real e enfileira a parte resultado. 12

13 Publicação/Subscrição Geralmente, um cliente específico chama um servidor remoto específico e faz um bloqueio até que o resultado seja retornado. Algumas vezes, esta estratégia não é suficiente. Considere um servidor que reporta valores compartilhados. Uma estratégia de polling implica em gargalos de performance. Os valores compartilhados podem estar espalhados por diferentes servidores. Mais de um cliente está interessado na informação. Como desacoplar clientes e servidores? Solução Desacoplar fornecedores (publicadores) e consumidores (assinantes) de eventos: Uma Fila de Eventos (Event Queue) armazena eventos. Publicadores criam eventos e os armazenam em uma fila de eventos na qual eles se registraram previamente. Consumidores se registram nas filas de eventos nas quais eles recuperam eventos. Eventos são objetos usados para transmitir informação de mudança de estado de publicadores para consumidores. Para transmissão de eventos são possíveis os modelos push e pull. Filtros podem ser usados para filtrar eventos em nome dos assinantes. 13

14 Solução *+ > * - Como fornecer e evoluir a funcionalidade de componentes Cada Modelo de Componente define como os componentes devem importar e exportar funcionalidades. Componentes devem ser capazes de evoluir ao longo do tempo sem impacto nos clientes. 14

15 Interfaces Múltiplas A maioria dos objetos possuem apenas uma interface. Então, se nós quisermos a banana, vamos receber junto o gorila. Como tornar isso mais flexível? Padrão - Extension Interface %6...,. > : 9 > 3 > -.. +% <<,== * % +% 3? 15

16 Dinâmica - #4 * " * / :,):.)3 9!.)@,3 3 *-:.,:.A!.)@,A A Visão Cliente/Componente Como vimos, clientes acessam as funcionalidades dos componentes usando RPCs Síncronas ou outros estilos de comunicação. A próxima questão é como criar novos componentes ou achar os já existentes. 0 16

17 Solução: Padrão - Factory/Finder Separa a gerência de componentes do seu uso: Home abstrato: declara uma interface para operações que acham ou criam instâncias abstratas de componentes. Home Concreto: implementa a interface abstrata Home para achar instâncias específicas ou criar novas. Componente Abstrato: declara uma interface para um tipo específico de classe de componente. Componente Concreto: define instâncias. Chave Primária (Primary Key): associada com um componente. Solução: Padrão - Factory/Finder 1 % 1 % 2 17

18 Dinâmica "-B- 1 6 Localizando as Homes Homes permitem criar e achar componentes, mas como localizamos as homes? Resposta: Use um serviço de diretório global

19 Visão Componente/Container Os containers são introduzidos a fim de isolar os componentes das particularidades da infra-estrutura subjacente. Containers são responsáveis por: Gerenciar o ciclo de vida dos componentes e notificá-los sobre o ciclo de vida de eventos tais como ativação, passivação, progresso de transações. Fornecer aos componentes acesso uniforme a serviços tais como transações, segurança, persistência. Registrar e distribuir (deploy) componentes. Container Um container é um ambiente de tempo de execução (runtime) para componentes que podem ser baseados em: Servidor Web ou Servidor de Banco de Dados ou Servidor CORBA ou Monitor-TP ou Sistema Operacional,... 19

20 Container % 6 ), &&& ), &&& Programação Declarativa Um desenvolvedor de componentes não sabe a priori em que ambiente seu componente irá executar. Componentes devem especificar declarativamente em arquivos de configuração qual o contexto de execução que eles requerem. O container então deve fornecer o ambiente de execução adequado: Exemplo: criando uma nova transação quando necessário. Mas como podemos fazer esta estratégia funcionar? 20

21 Solução :. #!.96 ) 0 ' ) : $.. CD), 0.. ) Solução %, *7 % % * % * > 6 21

22 Dinâmica, F : % " F6. ', Interceptação pelo Container O container intercepta todos os pedidos que chegam dos clientes. Ele lê os requisitos dos componentes de um arquivo de configuração XML e faz algum pre-processamento antes de realmente delegar o pedido ao componente. Interceptação também possibilita otimização de ativação: Just-in-Time, Pooling de objetos, e Caching. 22

23 Interfaces de Container/Componente Um componente fornece interfaces de evento que o container automaticamente invoca quando eventos específicos ocorrem: tais como ativação ou passivação. O container fornece interfaces genéricas ao componente que ele pode usar para acessar funcionalidades do container: tais como controle de transação. Ciclo de Vida do Componente Quem está encarregado de ativar e desativar um componente? O Container é responsável por ativar um componente. Um Componente pode ser desativado por si mesmo, pelo container, depois de cada chamada de método, depois de cada transação. 23

24 Estratégias de Persistência Persistência gerenciada de Componentes: Componentes podem acessar diretamente seus dados de persistência. Persistência gerenciada de Containers: Containers podem automaticamente gerar código de Persistência durante a instalação (deployment). Persistência de Serviço: Uma camada de adaptação (Adapter layer) pode esconder o componente das particularidades do fornecedor de Persistência. Acesso e Integração de Serviços Dentro de seus arquivos de configuração os fornecedores de componentes podem especificar: Segurança baseada em papéis: Quem está autorizado a chamar que métodos dos componentes, etc. Atributos de Transação : Como o componente usa transações. Questões de Persistência. Requisitos de Concorrência e Sincronização. 24

25 Tipos de Componentes Podemos identificar diferentes tipos de componentes: Acoplamento ao Container Ciente de Contexto Chave primária Categorias de Componentes transiente Não Não Serviço transiente Sim Não Sessão persistente Sim Não Processo persistente Sim Sim Entidade Empacotamento de Componente Basicamente, um componente pronto para rodar consiste de: Recursos Código Binário Informação de Configuração Metadados Uma infra-estrutura de componentes precisa também definir como estes artefatos são combinados e empacotados. 25

26 Papéis Fornecedor de Componentes Fornecedor de Persistência fornece facilidades de armazenamento Fornecedor de Container fornece os containers onde os componentes vivem Fornecedor do Servidor fornece o ambiente operacional Servidor de Aplicação: SO, ORB, Banco de Dados... Papéis Montador de Aplicação Montagem de aplicações a partir de um conjunto de componentes Administrator de Sistema responsável pela configuração e administração do ambiente da empresa Distribuidor (Deployer) Distribui componentes e aplicações 26

27 Cenário JD)9 3N): % H) M) - & L)!!. G)9 K)9 33)*-.' 3G)O' JD)#:. 3)- I): ' A). -8-3A)@ 6 ) 27