Aula 19 - IME-USP

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
 Mostrar a estrutura geral do CCM
 Apresentar um exemplo de utilização

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
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.)

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.)




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

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
IDL
interface A, B;
component Foo supports A, B
{
provides W, X, Y, Z;
...
};
// definição de equivalent interface
// e supported interfaces
// Facetas (provided interfaces)
// outras definições do componente
Equivalent interface
(suporta as interfaces
A e B por herança)
Componente
Foo
W
Facetas
(provided
interfaces)
X
Y
Z
Implementações
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
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
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
Ponto de Vista do Desenvolvedor
Eventos
source
sink
consome
publica
usa
Eventos
source
sink
Event
Channel X
Event
Channel Y
Notification Service
publica
consome
Atributo
F6
F5
Facetas
F3
Facetas
F2
F4
Componente B
Receptáculos
F1
Atributo
Componente A
Receptáculos
Portas usa
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

Ponto de Vista do Desenvolvedor
Component Implementation Framework (CIF)
Arquivos CIDL
Component
Descriptions
Component
Implementation
Source Code
Compilador
CIDL
Interface
Repository
Component
Implementation
Skeletons
Compilador
C++
Component
Program
(DLL)
Compilador
IDL
(componentaware)
Arquivos IDL
Server
Skeletons
Client
Stubs
Compilador
C++
Client
Source
Code
Client
Program
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
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
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
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 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

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
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
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
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.)
Cliente1
Servidor
Consumidor1
Cliente2
Consumidor2
Cliente3
Consumidor3
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
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/
