O Componente CCM

Os componentes CORBA descreve o uso de portas de compo- nentes como uma forma de oferecer diferentes visões de um mesmo componentes conforme o cliente que o utiliza. No exemplo descrito em (MARVIE, Raphael; MERLE, Philippe, 2001), um componente que im- plementa uma máquina de bebidas apresenta diferentes conjuntos de funções conforme o cliente que o utiliza. O fornecedor de bebidas uti- liza somente as portas relacionadas a provisão de estoque de bebidas

da máquina. Um comprador, por outro lado, teria acesso a portas que o permitissem a escolha e a compra do produto.

O CCM estende o modelo de objetos CORBA adicionando no- vos tipos, ferramentas e mecanismos. Esta extensão se reflete na IDL3, uma extensão da IDL2 (da especificação CORBA 2.X) especificado pelo modelo abstrato. A IDL3 inclui palavras chave que permitem a defini- ção de componentes. O mapeamento das definições da IDL3 em IDL2 (também chamada de interface equivalente) torna possível que clientes, componentes ou não, possam utilizar os serviços de um componente (Figura 3). IDL2 Fonte Código IDL3 Skeleton Definição _{Programação} Mapeamento Mapeamento Projetista Desenvolvedor

+

Figura 3: Mapeamento IDL3 em IDL2.

As interações de um componentes são definidas pela exposição de um conjunto de portas (Figura 4) que se dividem em:

• Facetas: Interfaces nomeadas providas por componentes para in- teração com clientes. Elas permitem que componentes exponham diferentes visões para seus clientes. Cada faceta engloba um con- junto de funcionalidades voltado para um cliente em particular; • Receptáculos: Pontos de conexão que descrevem a habilidade do

componente em usar uma referência provida por um agente ex- terno. Os receptáculos especificam o que componentes podem ou precisam usar;

• Fontes de Eventos: Pontos de conexão em que eventos de um tipo específico são disponibilizados;

• Consumidores de Eventos: pontos de conexão em que eventos de um tipo específico são processados;

• Atributos: Valores expostos através de métodos específicos que são usados inicialmente para configuração do componente.

Componente Implementações de Facetas Receptáculo Faceta Atributos Referência Consumidor de Evento Fontes de Evento

Figura 4: Portas de Componente CCM.

No CCM, as portas são variáveis nomeadas e com tipo definido, portanto facetas diferentes de um mesmo componente podem ter o mesmo tipo. Um componente agrupa definições de atributos e portas. Em geral as portas de componentes são projetadas para conexão entre componentes, mas podem também ser usadas em tempo de implanta- ção. Os componentes CCM possuem tipo definido e podem estabelecer relação de herança com outros componentes, o que significa que o com- ponente herda as interfaces do outro componente. Os componentes CCM também podem ser definidos através de herança, entretanto é suportada somente herança simples, de um único componente. Assim ocorre com objetos do CORBA padrão, instâncias de componentes são caracterizadas por suas interfaces e por uma referência, chamada de referência base no contexto CCM. Esta é a referência que permite aos clientes acessar portas de instâncias de componentes.

O CCM define quatro tipos de componentes: service, entity, ses- sion e process. Os componentes CCM podem ser dos seguintes tipos:

• Service: Os componentes deste tipo não armazenam estado ou identidade, o tempo de vida deste tipo de componente é confinado à duração de uma única invocação (uma única interação com um cliente);

• Session: Os componentes do tipo session são definidos como com- ponentes que possuem estado transiente e identidade não persis- tente. O tempo de vida deste tipo de componente é igual ao tempo de duração de uma seqüência de invocações de um único cliente.

• Process: Os componentes do tipo process possuem estado persis- tente. A identidade deste tipo de componente é gerenciada pelo componente (a critério do desenvolvedor). Componentes deste tipo geralmente representam processos de negócios (ex: carrinho de compras em comércio eletrônico);

• Entity: Os componentes do tipo entity são similares aos compo- nentes process, porém, os clientes destes componentes têm conhe- cimento explícito da persistência do componente. Estes compo- nentes são usados para modelar entidades de negócios (ex: clien- tes de uma empresa, contas bancárias).

Além destas, outras propriedades de projeto são consideradas na especificação de cada categoria de componente. Algumas destas propri- edades são: a definição de interfaces externas e internas, interfaces de callback, modelo de uso do CORBA, padrão de projeto do cliente, tipos de APIs externas, gerenciamento de persistência, política de tempo de vida do servant, o uso ou não de transações, tipos de eventos e espe- cificação de executores. A nomeação de cada um destes elementos do conjunto de propriedades possibilita a configuração automática do am- biente de execução do componente. Estas definições são especificadas na declaração do tipo do componente e na documentação do mesmo, gerada pelo compilador da IDL e posteriormente inclusas no pacote a ser implantado.

As interfaces externas são providas por componentes para rece- ber invocações de clientes através do container que o abriga. As inter- faces internas são usadas para interação entre componente e container. Estas interfaces provêem acesso aos serviços e contexto gerenciados pelo container, tais como gerenciamento de ciclo de vida e operações de tran- sação. As interfaces de callback, por sua vez, permitem ao container informar às instâncias de componentes sobre eventos importantes tais como quando uma instância de componente está disponível para algum serviço. Estas interfaces são ilustradas na Figura 5.

Para cada tipo de componente CCM existe um home associado. O home de componente CCM é responsável por atribuir chaves pri- márias e instanciar componentes. Além disso, o home gerencia o ciclo de vida do componente, contendo o método de criação, localização e destruição do componente. Assim como ocorre com componentes, ho- mes são criados a partir da herança de tipos básicos, com atributos e operações "clássicas"de homes. Em tempo de execução, uma instân- cia de componente só pode ser gerenciada por uma única instância de home. Embora possam ser gerados de forma automática, homes po-

dem também ser projetados com operações específicas definidas pelo projetista.

Tanto componentes como homes possuem atributos que são pa- râmetros nomeados projetados para configuração. Os mecanismos de implantação usam descritores de propriedades XML para configurar o valor inicial destes atributos em componentes e homes. A padroniza- ção de propriedades e interfaces para componentes, portas, atributos e homes, permite que clientes de componentes e desenvolvedores sejam capazes de definir quais propriedades são disponíveis e como acessá-las. O padrão CCM também define um conjunto de portas de operações genéricas que permite à ferramentas padronizadas verificar as funciona- lidades do componente, configurar atributos, obter interfaces de portas e fazer a conexão em portas. Estas portas padronizadas provêem a fle- xibilidade necessária para composição e implantação de componentes em aplicações em execução de forma automatizada.