componentes corba aluno: alexandre ricardo nardi orientador: prof. dr. francisco c. r. reverbel

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

Upload: agustina-coimbra-varejao

Post on 07-Apr-2016

220 views

Category:

Documents


0 download

TRANSCRIPT

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

Componentes CORBAComponentes CORBA

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

Page 2: Componentes 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

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

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

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

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

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

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

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

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

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

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

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

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

WXYZ

Equivalent interface(suporta as interfaces A e B por herança)

Facetas(providedinterfaces)

Implementações

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

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

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

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

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

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

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

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

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

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

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

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++

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

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

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

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

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

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 UsageModel

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

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

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

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

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

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

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

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

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

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

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

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

Exemplo (cont.)Exemplo (cont.)

Cliente1

Cliente3

Cliente2 Consumidor2

Consumidor3

Consumidor1Servidor

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

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

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

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/