Componentes CORBA

1. Componentes CORBA Aluno: Alexandre Ricardo Nardi Orientador: Prof. Dr. Francisco C. R. Reverbel

2. Objetivo • Apresentar os problemas existentes atualmente em CORBA que o CCM pretende resolver • Familiarizar o participante com os termos usados pelo CCM • Mostrar a estrutura geral do CCM • Apresentar um exemplo de utilização

3. Roteiro • Introdução • Apresentação do CCM • Ponto de vista do cliente • Ponto de vista do desenvolvedor • Extensões dosORBs • Outras Tecnologias • Proposta de Trabalho • Exemplo • Referências

4. Introdução • CORBA tem sido utilizado por um número crescente de aplicações distribuídas, como pode ser visto em “success stories” em http://www.omg.org, devido a características como: • Independência de linguagem, sistema operacional, hardware e localização relativa entre cliente e servidor • Serviços como naming, trading e event notification, que fornecem reusabilidade • Serviços essenciais como os de transações e segurança

5. Introdução (cont.) • Entretanto, a especificação de CORBA 2.3 não atende bem a pontos tais como: • Falta de padrão para implantação (deployment) de objetos • Falta de suporte para o uso de subconjuntos de funcionalidades “comuns”. Por exemplo, um grande número de aplicações utiliza apenas um subconjunto das possíveis configurações do POA e, apesar disso, o desenvolvedor deve conhecer muitas políticas do POA para conseguir o efeito desejado • Dificuldade para estender funcionalidades de objetos CORBA, possível apenas através de herança • Falta de definição de serviços obrigatórios: a aplicação deve possuir código que trate a indisponibilidade de serviços • Falta de padrão para gerenciamento de ciclo-de-vida de objetos: apesar da existência do “Lifecycle Service”, seu uso não é obrigatório, o que dificulta o trabalho no cliente • Problemas como esses levam à produção de aplicações com objetos fortemente acoplados (tightly coupled) difíceis de modelar, reutilizar, implantar, manter e estender

6. Introdução (cont.) • Com o objetivo de solucionar esses problemas, a OMG adotou o CORBA Component Model (CCM) como parte da especificação de CORBA 3.0 • CCM estende o modelo de objetos de CORBA, definindo funcionalidades e serviços que permitem que o desenvolvedor implemente, gerencie, configure e implante componentes que integrem os serviços de CORBA, como segurança, transações, persistência e eventos, em um ambiente padronizado • CCM permite maior reutilização de servidores e mais flexibilidade para configuração dinâmica de aplicações CORBA • Nesta apresentação, veremos as principais funcionalidades e serviços definidos pelo CCM

7. Apresentação do CCM • Uma das principais contribuições do CCM é a padronização do processo de desenvolvimento, que pode ser resumido como: • O desenvolvedor de componentes define, em IDL, as interfaces que as implementações dos componentes irão suportar • O desenvolvedor implementa os componentes utilizando ferramentas disponibilizadas pelo fornecedor do CCM • O componente é empacotado em uma DLL • O componente é implantado por mecanismo desenvolvido pelo fornecedor do CCM • A seguir apresentaremos os componentes do CCM sob as ópticas do cliente e do desenvolvedor, e as extensões dos ORBs necessárias para suporte ao CCM

8. W X Y Z Ponto de Vista do Cliente IDL interface A, B; component Foo supports A, B // definição de equivalent interface { // e supported interfaces provides W, X, Y, Z; // Facetas (provided interfaces) . . . // outras definições do componente }; Equivalent interface (suporta as interfaces A e B por herança) Componente Foo Facetas (provided interfaces) Implementações

9. Ponto de Vista do ClienteGerenciamento do Ciclo de Vida dos Componentes • É importante que o servidor de componentes trate adequadamente os problemas relativos ao gerenciamento do ciclo de vida dos componentes, e que os clientes auxiliem os servidores no tratamento relativo às instâncias de componentes que utilizem • O servidor deve saber quando criar e destruir instâncias no sentido de evitar resource leaks • CORBA Object Services define o Lifecycle Service, que não é de uso obrigatório, fazendo com que o desenvolvedor implemente sua própria estratégia de gerenciamento • CCM introduz a palavra-chave home, interface que pode ser usada pelos clientes para controlar o ciclo do componente, podendo ser keyless (suporte a operações factory) ou keyed (factory e finder). Possui o método remove_component, que notifica o servidor para tratar da remoção de uma instância conforme sua estratégia

10. Ponto de Vista do ClienteCenários de Uso de Componentes • O cliente deve obter referência à home do componente. Para isso, CCM define a interface HomeFinder, semelhante ao OMG Naming Service, que implementa um serviço de diretório para component homes. Para obter referência a esta interface utiliza-se: • resolve_initial_references(“HomeFinder”) • A partir desta referência, utiliza-se um dos métodos da interface HomeFinder para se obter referência à Home do componente. Por exemplo: • find_home_by_name(“HomeDoComponenteA”) • Uma vez com uma referência à home do componente, o cliente usa operações de factory ou finder, conforme apropriado, para obter uma referência ao componente

11. Ponto de Vista do DesenvolvedorPortas • São mecanismos de interação com entidades externas, como serviços fornecidos pelo ORB, outros componentes ou clientes. Existem os seguintes tipos: • Facetas (unrelated interfaces): permitem reutilização através de composição, ao invés de herança • Receptáculos: modo de um componente delegar operações a outros componentes • Event sources/sinks: para publicação/subscrição a eventos • Atributos: facilitam a configuração dos componentes • Esses mecanismos podem ser utilizados pelo cliente, mas o objetivo principal dos três últimos relaciona-se à configuração dos componentes, sendo utilizados pela CCM deployment framework

12. Componente A Componente B Atributo Atributo Facetas Facetas Receptáculos Receptáculos Eventos Eventos source source sink sink Event Channel X F4 F6 F5 F3 F2 F1 Event Channel Y Notification Service Ponto de Vista do DesenvolvedorPortas usa usa publica consome consome publica

13. Ponto de Vista do DesenvolvedorComponent Implementation Framework (CIF) • CCM define grande número de interfaces (por exemplo, Home e Navigation) para suportar a estrutura e funcionalidade dos componentes • As implementações de muitas dessas interfaces podem ser geradas automaticamente: esse é o objetivo de CORBA Component Implementation Framework (CIF) • CCM define uma linguagem declarativa, Component Implementation Definition Language (CIDL), para descrever implementações e persistência de estado de componentes e homes • CIF usa a CIDL para gerar skeletons que automatizam tarefas básicas, como navegação, ativação e gerenciamento de estado

14. Ponto de Vista do DesenvolvedorComponent Implementation Framework (CIF) Arquivos CIDL Interface Repository Compilador IDL (component- aware) Arquivos IDL Compilador CIDL Component Descriptions Component Implementation Skeletons Server Skeletons Client Stubs Component Implementation Source Code Client Source Code Compilador C++ Compilador C++ Component Program (DLL) Client Program

15. Ponto de Vista do DesenvolvedorContainers • Como vimos, componentes são empacotados em DLLs e executados em servidores de componentes. As implementações dos componentes dependem do POA para encaminhar requisições de clientes para os serventes • Os componentes não precisam saber como tratar problemas como a criação de hierarquia de POAs e localizar serviços do CCM. Para isso foram definidos os containers, com as seguintes funcionalidades: • Ativação/desativação de implementações de componentes, preservando recursos (como memória) • Fornecimento de camada de adaptação com os serviços de transação, persistência, segurança e notificação • Fornecimento de camada de adaptação para callbacks • Gerenciamento de políticas do POA

16. Ponto de Vista do DesenvolvedorContainers • O gerenciamento do tempo de vida dos serventes é feito através de políticas que controlam o momento de ativação/desativação dos componentes: • Method: ativação/desativação a cada chamada de método, limitando o uso de memória ao tempo de duração da operação, mas acrescentando o custo de ativação e desativação do componente • Transaction: ativação/desativação a cada transação. Memória permanece alocada durante a transação • Component: o container ativa o componente quando for feita a primeira chamada a alguma de suas operações, e desativa quando explicitamente requisitado pela aplicação, desalocando a memória utilizada pelo componente • Container: o componente será ativado quando for feita a primeira chamada a alguma de suas operações e, ao final da execução da mesma, será desativado. Entretanto, a memória permanecerá alocada até que o container decida desalocá-la

17. Ponto de Vista do DesenvolvedorCategorias de Componentes • Estendem o CORBA Usage Model, que classifica o padrão de interação entre o container, o POA e os serviços de CORBA • São especificadas em arquivo CIDL

18. Ponto de Vista do DesenvolvedorEmpacotamento e Distribuição • Em sistemas distribuídos, componentes podem ser implantados em diversos servidores e sistemas operacionais. Além disso, um componente pode depender de outros componentes, tornando o processo de empacotamento e distribuição bem complicado • CCM descreve componentes e suas dependências usando Open Software Description (OSD), que é um XML Document Type Definition(DTD) definido pelo consórcio WWW. Componentes são empacotados em DLLs. Package descriptors são documentos XML em conformidade com o OSD DTD, descrevendo o conteúdo da DLL e suas dependências • CCM OSD também define component assembly descriptors, que descrevem instruções de implantação e topologia dos componentes, e objetiva o suporte à implantação automática

19. Extensões dos ORBs • Simplificam a implementação da CCM framework, focando também em melhorias de performance • Locality-constrained interfaces: permite comunicação local entre componente e container, melhorando a performance • Extensões ao Interface Repository (IR): o modelo do CCM utiliza largamente a navegação através das interfaces dos componentes, o que já era possível utilizando o IR, mas ganhou em desempenho ao se utilizar CCMObject, uma vez que a chamada de operações é feita de modo “co-locado” • Extensões à IDL, com construções para importação de declarações de tipos definidos em arquivos separados, e mecanismos para controlar identificadores no IR

20. Outras Tecnologias • Enterprise Java Beans (EJB): a especificação do CCM foi modelada em muitos pontos baseada na do EJB. Entretanto, CCM utiliza CORBA como arquitetura para interoperabilidade, não estando associada a uma linguagem em particular. CCM também define mapeamento entre os dois padrões • Microsoft .NET: possui vários pontos em comum com o CCM sendo, entretanto, limitada às plataformas Microsoft

21. Proposta de Trabalho • Elaborar um texto capaz de apresentar de forma clara as principais características do CCM (a seguir), em profundidade suficiente para que o leitor, uma vez já conhecendo os princípios de CORBA, possa ter sua atualização agilizada • Construção de uma aplicação exemplo para melhor ilustrar o processo de desenvolvimento, desde o modelo de classes até a implantação e execução

22. Exemplo • Demonstração inclusa no OpenCCM 0.2 • Plataforma/ambiente • Windows 2000 • JDK 1.3 • ORBacus 4.0.5 • OpenCCM • Ilustra o uso de facetas, receptáculos e eventos • Aplicação cliente que utiliza faceta do servidor, e este envia evento para consumidores

23. Exemplo (cont.)

24. Exemplo (cont.) • Demo3.idl: definição dos componentes cliente, servidor e consumidor • Demo3.java: programa principal, que instala e instancia os componentes • ClientImpl.java, ServerImpl.java e ConsumerImpl.java: implementação dos componentes • ClientHomeImpl.java, ServerHomeImpl.java e ConsumerHomeImpl.java: implementação dos homes dos componentes • EventImpl.java e EventDefaultFactory.java: implementação do evento a ser disparado pelo servidor aos consumidores

25. Referências • Object Management Group. • Don Box. Essential COM (Addison-Wesley, 1998) • M. Henning, S. Vinoski. Advanced CORBA Programming with C++ (Addison-Wesley, 1999) • E. Gamma et al. Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994) • http://ditec.um.es/~dsevilla/ccm/