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

Apresentação em tema: "Componentes CORBA Aluno: Alexandre Ricardo Nardi Orientador: Prof. Dr. Francisco C. R. Reverbel."— Transcrição da apresentação:

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 dos ORBs 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 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 }; Componente Foo W X Y Z Equivalent interface (suporta as interfaces A e B por herança) Facetas (provided interfaces) Implementações

9 Ponto de Vista do Cliente (cont.) Uma referência a uma instância do componente Foo aparece para os clientes como um objeto CORBA tradicional. Assim, clientes component-unaware podem invocar operações através de uma referência à equivalent interface, que é aquela que identifica unicamente a instância do componente, e que pode herdar de outras interfaces, chamadas supported interfaces Vimos que é difícil estender objetos CORBA apenas por herança. Como alternativa, CCM define o conceito denominado facetas, semelhante às interfaces dos componentes COM, permitindo suporte a interfaces não relacionadas ( unrelated interfaces ). Os clientes podem navegar pelas interfaces de um componente (facetas e equivalent interfaces ) por intermédio da interface Navigation, definida em CORBA::CCMObject (herdada por todos os componentes)

10 Ponto de Vista do Cliente Gerenciamento 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

11 Ponto de Vista do Cliente Cená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

12 Ponto de Vista do Desenvolvedor Portas 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

13 Ponto de Vista do Desenvolvedor Portas F1 F2 F3 Atributo Componente A Eventos sinksource Receptáculos Facetas F4 F5 F6 Atributo Componente B Eventos sinksource Receptáculos Facetas Event Channel X Event Channel Y Notification Service publica usa consome publica

14 Ponto de Vista do Desenvolvedor Component 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

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

16 Ponto de Vista do Desenvolvedor Containers 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

17 Ponto de Vista do Desenvolvedor Containers 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

18 Ponto de Vista do Desenvolvedor Categorias 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 Categoria do Componente CORBA Usage Model Tipo de API do Container Keyed Home Interface Exemplo ServiceStatelessSession Não Wrappers para aplic. procedurais de legado SessionConversationalSession NãoIteradores Process Durável Entity NãoRegras de negócio. Ex.: carrinho de compras Entity Durável Entity SimPeças num inventário

19 Ponto de Vista do Desenvolvedor Empacotamento 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

20 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

21 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

22 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

23 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

24 Exemplo (cont.)

25 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

26 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/