Modelo de Componentes CORBA

O Modelo de Componentes CORBA (CCM) [17] é parte da especificação CORBA 3 [96] e repre- senta o esforço desenvolvido pelo OMG para minimizar as limitações do modelo de objetos CORBA e atender aos novos requisitos, impostos pela evolução da computação de objetos distribuídos para a computação de componentes distribuídos. Motivado pela necessidade de redução da complexi- dade durante as fases de desenvolvimento e instalação de aplicações orientadas a componentes e pelo sucesso do EJB, CCM proporciona um modelo de programação de mais alto nível de abstração, baseado no conceito de componentes como elementos de software com alto potencial de reutilização [15]. CCM é um padrão para a implementação do lado servidor de aplicações distribuídas, compostas de componentes distribuídos e heterogêneos, podendo ser utilizado também no lado cliente destas aplicações.

CCM especifica um modelo de componentes que define os padrões utilizados durante o ciclo de desenvolvimento de componentes — incluindo um modelo de suporte ao ambiente de execução — que utiliza a plataforma CORBA tradicional. CCM é um modelo neutro, ou seja, foi especificado considerando interoperabilidade. Portanto, os componentes de uma aplicação desenvolvidos segundo

o modelo CCM podem ser implementados utilizando-se diferentes linguagens de programação e sis- temas operacionais.

Componentes CCM

Um componente CCM é uma extensão de um objeto CORBA, sendo especificado por meio de uma extensão da IDL do CORBA para a declaração de componentes. Os desenvolvedores de com- ponentes CCM definem as especificações funcionais das interfaces IDL, que posteriormente são co- dificadas gerando as implementações de componentes. O modelo de componentes CCM define um mapeamento da IDL estendida para a IDL padrão, e é a partir desta IDL que o desenvolvedor codifi- cará a parte funcional do componente.

Um componente CCM proporciona mecanismos denominados portas, atributos e referência de componente. Um componente CCM tem uma única referência de componente e um número arbitrário de portas e de atributos. A Figura 2.1 apresenta uma representação de um componente CCM. Nesta figura:

• portas: são mecanismos através dos quais clientes, componentes cooperantes e outros elemen- tos do ambiente da aplicação podem interagir com este componente;

• atributos: são propriedades, normalmente utilizadas para configuração de componentes;

• interface equivalente: é uma interface que identifica unicamente uma instância de um compo- nente e permite o acesso às portas do componente.

CCM define quatro tipos de portas:

• facetas, também conhecidas como interfaces proporcionadas, são as interfaces que um compo- nente provê para interação com os seus clientes;

• receptáculos são os pontos de conexão que armazenam as interfaces requeridas pelo compo- nente;

• produtores de eventos são os pontos de conexão que emitem eventos, de um dado tipo, para um ou mais consumidores de eventos do mesmo tipo;

• consumidores de eventos são os pontos de conexão capazes de consumir eventos de um dado tipo.

Interface Equivalente Faceta Receptáculo Consumidor de Evento Produtor de Evento Atributos Componente CORBA Fig. 2.1: Componente CCM.

Uma instância de um componente é identificada, principalmente, pela sua interface equivalente e, alternativamente, pelo seu conjunto de referências de facetas. O modelo CCM proporciona operações para a navegação entre as interfaces de um componente onde, a partir de uma interface conhecida de um componente (o que inclui a interface equivalente), um cliente pode obter as referências para as suas demais interfaces.

De forma a padronizar a interface de gerenciamento do ciclo de vida de um componente, CCM proporciona o elemento home. Este elemento gerencia o conjunto de todas as instâncias de um tipo específico de componente. As interfaces home proporcionam operações para gerenciar o ciclo de vida (criar, procurar e remover) de instâncias de um componente. Assim, para utilizar um componente, um cliente precisa primeiramente adquirir uma referência para a interface home do componente. O modelo proporciona, para os clientes, a interface home finder para a obtenção da referência para a interface home de um componente. Depois que o cliente obtém esta referência, ele pode criar ou encontrar a referência do componente desejado.

Interação entre Componentes CCM

Os componentes desenvolvidos segundo o modelo CCM interagem com entidades externas através de portas. Em adição, por meio de atributos, CCM permite que mecanismos de configuração modi- fiquem as configurações de um componente.

O mecanismo de interação proporcionado pelo modelo CCM é baseado em chamada de méto- dos remotos, portanto obedecendo ao estilo de interação operacional proposto pelo RM-ODP. CCM fornece também a interface de sinal, representada pelo modelo de comunicação publicador/subscritor, segundo o estilo de interação sinal do RM-ODP. Portanto, o modelo proporciona dois modos de interação: invocações síncronas através de facetas e notificações assíncronas através de pontos de conexão produtores e consumidores de eventos. Em adição, um componente pode definir as inter-

faces que ele necessita por meio de receptáculos que armazenam referências para as portas de outros componentes. Entretanto, este modelo não define a interface stream, que é extremamente importante para o desenvolvimento de aplicações multimídia distribuídas.

O Framework de Implementação de Componentes CCM

O Framework de Implementação de Componentes CCM (CIF: Component Implementation Frame-

work) define o modelo de programação do CCM para a implementação de componentes. Segundo

Marvie e Merle [12], o principal objetivo deste modelo de programação é prover o suporte para a des- crição dos aspectos não-funcionais dos componentes e, a partir destes, fornecer a geração automática desta parte da implementação de forma que o desenvolvedor da aplicação codifique apenas os seus aspectos funcionais. Exemplos de aspectos não-funcionais propiciados pelo modelo de componentes CCM incluem transações, segurança e persistência.

CCM define uma linguagem declarativa, a linguagem de definição de implementação de compo- nentes (CIDL: Component Implementation Definition Language), para descrever implementações e o estado persistente de componentes e homes de componentes. CIF utiliza as descrições em CIDL para gerar esqueletos de programação distribuída que automatizam uma parte do comportamento básico de componentes, tais como navegação entre facetas, ativação, gerenciamento de portas, gerenciamento de ciclo de vida do componente, gerenciamento de estado, etc. Os desenvolvedores de componentes estendem certos métodos providos por estes esqueletos durante a fase de implementação do compo- nente. O compilador CIDL gera os descritores de componentes que definem as funcionalidades dos componentes bem como as restrições técnicas que serão garantidas em tempo de instalação, tais como descrições das interfaces dos componentes, políticas de transação, políticas de threading e os tipos de serviços que este componente necessita.

A especificação CCM define, de acordo com o modelo de persistência de estado adotado por meio da CIDL, quatro categorias de componentes CORBA: componentes de serviço, componentes

de sessão, componentes de processo e componentes entidade. Um componente de serviço contém

as propriedades de suporte a uma única invocação por instância. Estes componentes não possuem estado nem identidade (equivalentes aos beans de sessão sem estado do EJB). Um componente de sessão contém as propriedades de suporte a uma seqüência de invocações por instância. Estes com- ponentes possuem estado transiente e identidade não persistente (equivalentes aos beans de sessão com estado do EJB). Um componente de processo contém as propriedades de comportamento, que podem ser transacionais. Estes componentes possuem estado persistente, comportamento transa- cional, são gerenciados pelo ambiente e possuem identidade persistente gerenciada pelo cliente. Um componente entidade é similar ao anterior e contém as propriedades de comportamento, que podem ser transacionais. Estes componentes possuem estado persistente e identidade visível para o cliente

(equivalentes aos beans de entidade do EJB).

Modelo de Programação de Contêineres CCM

Um contêiner representa o ambiente de execução para uma implementação de componente CORBA. Um contêiner provê o encapsulamento para as instâncias de um único tipo de componente. Para tal, o contêiner utiliza o adaptador portável de objeto (POA: Portable Object Adapter) especializado para este componente, bem como de um conjunto de interfaces para o acesso transparente a serviços CORBA necessários ao componente, tais como persistência, transação, segurança e notificação de eventos. Adicionalmente, ele também provê recursos de baixo nível, tais como memória, proces- sador, entre outras dependências que o componente hospedado necessite. As implementações de componentes dependem do POA para interceptar e enviar as requisições dos clientes para os seus ob- jetos servidores correspondentes. A partir da descrição do componente, a implementação do modelo de componentes CCM gera automaticamente a criação e configuração da hierarquia do POA, bem como localiza os serviços comuns definidos pelo modelo.

Um modelo de programação de contêiner define um conjunto de interfaces para facilitar o de- senvolvimento de aplicações CORBA. O contêiner integra os serviços CORBA ao comportamento funcional de componentes tendo como base os descritores de componentes apresentados na seqüên- cia. A Figura 2.2 ilustra o modelo de programação do contêiner CCM.

Transação ORB Serviços CORBA Notificação Persistência Segurança Componente CORBA Interfaces Internas Home POA Interfaces Externas Interface de Callback Contêiner Cliente IIOP

Fig. 2.2: Contêiner para componentes CORBA.

• interfaces externas, interfaces disponíveis para os clientes do componente hospedado. Estas interfaces estabelecem o contrato entre o desenvolvedor do componente e o cliente deste com- ponente;

• interfaces do contêiner, estabelecem o contrato entre um componente e o seu contêiner por meio de dois tipos de interfaces:

1. interfaces internas, definidas como as interfaces locais que são disponibilizadas para que o componente hospedado possa acessar os serviços proporcionados pelo contêiner; 2. interfaces callbacks, também interfaces locais, implementadas pelo componente, que po-

dem ser invocadas pelo contêiner para gerenciar e notificar o componente.

• modelo de uso, que define as interações entre o contêiner e a plataforma CORBA (POA, ORB e serviços CORBA);

• funcionalidades para a navegação entre as interfaces do componente hospedado, por meio da interface Home;

• conexão das facetas e receptáculos do componente;

• canais de eventos para transmitir e para receber eventos entre os componentes.

Empacotamento e Distribuição de Componentes CCM

Os componentes CCM podem ser distribuídos por meio de vários servidores e geralmente uti- lizam diferentes linguagens de programação, sistemas operacionais e compiladores. Em adição, estes componentes podem depender de outros componentes. Conseqüentemente, o empacotamento e a dis- tribuição destes componentes podem tornar-se muito complexos. Com o intuito de simplificar estas etapas, a especificação do modelo de componentes CCM define técnicas que fornecem o padrão para o empacotamento e distribuição. Estas técnicas são resumidas a seguir.

A especificação CCM define a forma como os componentes e suas implementações são empaco- tados para, posteriormente, serem instalados em máquinas dispostas na rede. Um pacote de compo- nentes consiste de um ou mais descritores e de um conjunto de arquivos contendo a implementação de um único componente. Estes descritores são utilizados para descrever os componentes e as suas dependências, e são escritos na linguagem OSD (Open Software Description). OSD é um vocabulário XML, ou seja, é um DTD (Document Type Definition) definido pelo consórcio W3C. Os componentes são empacotados em arquivos no formato ZIP.

O pacote de componente pode ser distribuído sozinho ou pode ser incluído em um pacote de montagem de componente e distribuído junto com outros componentes. Uma montagem especifica

uma configuração inicial. Este pacote de montagem consiste de um conjunto de pacotes de com- ponentes (incluindo os homes dos componentes) interrelacionados, de um arquivo de propriedades e de um descritor de montagem. O descritor de montagem é também especificado utilizando um vocabulário XML contendo os componentes, as conexões entre eles e as informações de partição. Estas informações especificam um padrão de distribuição em que grupos de componentes devem ser distribuídos dentro de uma máquina ou processo específico, ou especificam se eles podem ser dis- tribuídos livremente. O arquivo de propriedades define os parâmetros de configuração (atributos) de componentes e de seus homes.

A especificação CCM define um processo de distribuição que utiliza os pacotes de componentes de forma a instalar as implementações dos componentes, criar instâncias de componentes e interco- nectá-las de maneira a proporcionar uma aplicação executável.

Em adição aos descritores apresentados acima, o modelo especifica o descritor de componente, também por meio de um vocabulário XML. O compilador CIDL gera este descritor que lista as restri- ções técnicas a serem garantidas em tempo de instalação. Este descritor especifica as características do componente utilizadas em tempo de projeto e de instalação. Estas características incluem uma descrição da estrutura do componente em termos de interfaces suportadas, componentes herdados, eventos e portas proporcionadas e necessitadas, além dos aspectos não-funcionais de transação, segu- rança e persistência. Adicionalmente, em tempo de instalação, o descritor de componente é utilizado para determinar o tipo de contêiner em que o componente precisa ser instalado, bem como para fornecer informações do componente para o contêiner.

Considerações Gerais Sobre o Modelo CCM

O modelo CCM tem dois predecessores: o modelo de objetos CORBA e o modelo de compo- nentes EJB. CCM foi modelado de acordo com a especificação EJB, ou seja, CCM integrou em sua especificação o bem sucedido modelo de componentes do EJB, adotando-o no mundo CORBA e mantendo a interoperabilidade e a neutralidade no nível de linguagem do CORBA. CCM é portanto compatível com EJB e define um mapeamento padrão entre os dois modelos de componentes. Desta forma, é facil a interoperação entre os componentes CCM e EJB. Em adição, o framework de comu- nicação do EJB suporta o protocolo IIOP da especificação CORBA. Assim, um componente CCM pode ser considerado como um componente EJB para clientes EJB e portanto pode ser instalado em um contêiner EJB, respeitando a restrição imposta pelo EJB, que exige o uso da linguagem Java como a linguagem de implementação para os componentes aderentes a este modelo. Da mesma forma, um componente EJB pode ser considerado como um componente CCM para clientes CCM e, assim, po- dem ser instalados em um contêiner CCM. Esta integração permite que uma aplicação seja montada utilizando uma combinação de componentes CCM e EJB.

O modelo CCM pode ser visto como um modelo adequado para o desenvolvimento de aplicações distribuídas e escaláveis. No entanto, algumas considerações são pertinentes.

Uma primeira consideração é que a especificação CCM é muito extensa, complexa e só foi disponibilizada recentemente, o que significa que as implementações do modelo e ferramentas de suporte ainda estão sendo desenvolvidas. A primeira implementação CCM, denominada OpenCCM, foi publicada recentemente com apenas uma parte do modelo. Portanto, é difícil avaliar a qualidade e performance do modelo, apesar da sua crescente aceitação como um padrão de componentes. En- tretanto, devido a sua compatibilização com o modelo de componentes EJB, cuja aceitação é ampla, comprova que pelo menos esta parte do CCM pode ser considerada avaliada. As outras partes que estendem o EJB, no entanto, ainda precisam ser melhor analisadas e efetivadas na prática.

Uma segunda consideração enfatiza que o modelo CCM não é adequado às aplicações que ma- nipulam mídias contínuas, porque não proporciona suporte à interface stream proposta pelo modelo de referência RM-ODP. A incorporação desta interface ao CCM foi abordada na Seção 1.4.

Finalmente, a definição estática de contêineres impede a flexibilidade das aplicações emergentes quanto a novos requisitos, por exemplo, a adequação a aspectos de qualidade de serviço impostos por novos ambientes com recursos limitados. Seria mais interessante poder utilizar contêineres adap- táveis, que permitissem a adição (estática ou dinâmica) de novos aspectos não-funcionais a serem gerenciados pelo contêiner.