Post on 05-Jan-2016
description
Componentes CORBAComponentes CORBA
Aluno: Alexandre Ricardo Nardi
Orientador: Prof. Dr. Francisco C. R. Reverbel
ObjetivoObjetivo
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 CCMApresentar um exemplo de utilização
RoteiroRoteiro 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
IntroduçãoIntroduçã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 (cont.)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 CCMApresentaçã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 ClientePonto de Vista do Cliente IDLinterface 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
};
ComponenteFoo
W
X
Y
Z
Equivalent interface(suporta as interfaces A e B por herança)
Facetas(providedinterfaces)
Implementações
Ponto de Vista do ClientePonto de Vista do ClienteGerenciamento do Ciclo de Vida dos ComponentesGerenciamento 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 ClientePonto de Vista do ClienteCenários de Uso de ComponentesCená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 DesenvolvedorPonto de Vista do DesenvolvedorPortasPortas
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 DesenvolvedorPonto de Vista do DesenvolvedorPortasPortas
F1
F2
F3
Atrib
utoComponente A
Eventossinksource
Rece
ptác
ulos
Facetas
F4
F5
F6
Atrib
utoComponente B
Eventossinksource
Rece
ptác
ulos
Facetas
EventChannel X
EventChannel Y
Notification Service
publica
usa
usa
consome
consomepublica
Ponto de Vista do DesenvolvedorPonto de Vista do DesenvolvedorComponent Implementation Framework (CIF)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
Ponto de Vista do DesenvolvedorPonto de Vista do DesenvolvedorComponent Implementation Framework (CIF)Component Implementation Framework (CIF)
Arquivos CIDL
ClientStubs
InterfaceRepository
Arquivos IDLCompilador
CIDL
CompiladorIDL
(component-aware)
ServerSkeletons
ComponentImplementation
Skeletons
ComponentDescriptions
ComponentImplementation
Source Code
ComponentProgram
(DLL)
ClientProgram
ClientSourceCode
CompiladorC++
CompiladorC++
Ponto de Vista do DesenvolvedorPonto de Vista do DesenvolvedorContainersContainers
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 DesenvolvedorPonto de Vista do DesenvolvedorContainersContainers
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 DesenvolvedorPonto de Vista do DesenvolvedorCategorias de ComponentesCategorias 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 CIDLCategoria do Componente
CORBA Usage
Model
Tipo de API do
Container
Keyed Home
Interface
Exemplo
Service Stateless Session Não Wrappers para aplic. procedurais de legado
Session Conversational Session Não Iteradores
Process Durável Entity Não Regras de negócio. Ex.: carrinho de compras
Entity Durável Entity Sim Peças num inventário
Ponto de Vista do DesenvolvedorPonto de Vista do DesenvolvedorEmpacotamento e DistribuiçãoEmpacotamento 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 ORBsExtensõ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 TecnologiasOutras 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 TrabalhoProposta 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
ExemploExemplo
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 (cont.)Exemplo (cont.)
Cliente1
Cliente3
Cliente2 Consumidor2
Consumidor3
Consumidor1Servidor
Exemplo (cont.)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ênciasReferênciasObject 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/