componentes corba n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Componentes CORBA PowerPoint Presentation
Download Presentation
Componentes CORBA

Loading in 2 Seconds...

play fullscreen
1 / 25

Componentes CORBA - PowerPoint PPT Presentation


  • 119 Views
  • Uploaded on

Componentes CORBA. Aluno: Alexandre Ricardo Nardi Orientador: Prof. Dr. Francisco C. R. Reverbel. Objetivo. Apresentar os problemas existentes atualmente em CORBA que o CCM pretende resolver Familiarizar o participante com os termos usados pelo CCM

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Componentes CORBA' - deanne


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
componentes corba

Componentes CORBA

Aluno: Alexandre Ricardo Nardi

Orientador: Prof. Dr. Francisco C. R. Reverbel

objetivo
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
roteiro
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
introdu o
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
introdu o cont
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
introdu o cont1
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
apresenta o do ccm
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
ponto de vista do cliente

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

ponto de vista do cliente gerenciamento do ciclo de vida dos componentes
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
ponto de vista do cliente cen rios de uso de componentes
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
ponto de vista do desenvolvedor portas
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
ponto de vista do desenvolvedor portas1

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

ponto de vista do desenvolvedor component implementation framework cif
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
ponto de vista do desenvolvedor component implementation framework cif1
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

ponto de vista do desenvolvedor containers
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
ponto de vista do desenvolvedor containers1
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
ponto de vista do desenvolvedor categorias de componentes
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
ponto de vista do desenvolvedor empacotamento e distribui o
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
extens es dos orbs
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
outras tecnologias
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
proposta de trabalho
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
exemplo
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
exemplo cont1
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
refer ncias
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/