1. INTRODUÇÃO
2.1.3 CORBA Component Model
O CORBA Component Model – CCM é o modelo de componentes do Object Management Group (OMG), e é parte da especificação do CORBA 3. O CMM herda todas as características do CORBA como independência de linguagem e de plataforma, interoperabilidade e escalabilidade. Além disso, o CMM adiciona a elas um modelo de componentes distribuídos e um container para o gerenciamento do ciclo de vida destes componentes (OMG, 2002).
Um típica arquitetura CCM consiste dos seguintes itens (Raj, 1999): De containers CCM;
De componentes CORBA, que são executados nestes containers;
Do “Adaptador de Objetos Portáveis” (Portable Object Adapter – POA); Do “Negociador de Acesso a Objetos” (Object Request Broker – ORB); De outros serviços CORBA, tais como:
¾ Transações; ¾ Segurança; ¾ Persistência; ¾ Eventos; ¾ Entre outros.
Figura 2.2 – Componente CCM
A estrutura básica de um componente deste tipo é composta por (OMG, 2002):
¾ Uma interface, que define os métodos e atributos que são acessados externamente, e que é processada pelo compilador IDL (Interface Definition Language);
¾ Propriedades, que são qualificadores do componente. Assim como um objeto, eles são usados para armazenar valores, constantes ou variáveis, e podem ser utilizados por qualquer um dos métodos do componente;
¾ Facetas, que são interfaces de acesso a determinados métodos. O padrão CCM diz que as facetas podem ser vistas como uma maneira dos projetistas associarem “métodos de contexto” a um componente. Um método definido em uma faceta só pode ser acessado por componentes que possuam portas associadas a ela;
¾ Receptáculos, que são uma maneira abstrata de se criar uma porta de comunicação em um componente para que este receba comunicação de determinado tipo. Os receptáculos necessitam de facetas associadas para se comunicar;
Produtores de Eventos: incorporam o potencial que o componente possui de gerar eventos de determinado tipo, e disponibilizam mecanismos de associação de consumidores a esses eventos;
Consumidores de Eventos: englobam o potencial que o componente possui de receber eventos de determinado tipo.
A Figura 2.3 mostra a arquitetura CCM:
Figura 2.3 – Arquitetura CCM (Balasubramanian, 2002)
Nota-se aqui a existência de containers, que possuem as mesmas funções de seus similares EJB. A interface ComponentHome gerencia o ciclo de vida dos componentes e suas funcionalidades são acessadas pelo mundo externo através de suas interfaces externas. Os componentes CCM podem ser escritos em qualquer liguagem, e comunicam-se com aplicações externas ao container. Além disso, o CCM necessita de um ORB (Object Request Broker) para funcionar. Um ORB é o suporte que trata de vários aspectos ligados à implementação das semânticas do RMI do CORBA. Portanto, pode-se concluir que o CCM é essencialmente dependente do CORBA.
O servidor CCM (ComponentServer) disponibiliza um ambiente de execução, multiprocessamento, balanceamento (load-balacing), acesso, serviços de transações e
identificação e torna os containers visíveis (Raj, 1999). Um container CCM funciona como uma interface entre o componente e o mundo externo, um cliente CCM nunca acessa um componente CORBA diretamente. Qualquer acesso é feito através de métodos gerados pelo container, que por sua vez, invocam métodos dos componentes. Existem dois tipos de containers CCM (Raj, 1999):
• Transitórios: Que contêm componentes transitórios ou não-persistentes, ou seja, aqueles cujo estado não é salvo pelo container;
• Persistentes: Possui componentes persistentes, cujo estado é salvo entre uma transação e outra.
O cliente CCM é aquele que faz uso de componentes CCM nas suas operações. Ele procura a identificação do container que possui o componente desejado através do serviço de nomes CORBA COSNaming, e utiliza a interface ComponentHome para obter uma referência para este container. Feito isto, o cliente utiliza então o container para invocar os métodos do componente desejado.
Os componentes CCM se subdividem em quatro tipos:
¾ Componentes de serviço (Service Components): Cada componente de serviço é geralmente associado a um cliente CCM e seu ciclo de vida é restrito a uma única operação (ou única invocação de método). Ele é criado e destruído pelo cliente associado a ele. Componentes de serviços não “sobrevivem” a um desligamento do sistema;
¾ Componentes de sessão (Session Components): Um componente de sessão também está associado a um único cliente CCM, e da mesma forma que os componentes de serviço, é criado e destruído por seu cliente. Componentes de sessão podem possuir ou não estado e são muito semelhantes aos Session Beans (Seção 2.1.2). Os componentes de sessão também não “sobrevivem” a um desligamento do sistema;
¾ Componentes de processo (Process Components): Componentes de processo sempre possuem estado. Entretanto, um componente de processo pode ser compartilhado por mais de um cliente CCM. Seus estados é salvo ao longo das diversas invocações, portanto, “sobrevive” aos desligamentos;
¾ Componentes-entidade (Entity Componentes): Um componente-entidade é bastante similar a um componente de processo, pois possui estados persistentes entre diversas invocações, pode ser compartilhado entre múltiplos clientes e “sobrevive” a um desligamento do sistema. Contudo, um componente-entidade possui um identificador exclusivo associado e é muito semelhante a um Entity Bean (Seção 2.1.2). Desta forma, os componentes-entidade podem ser explicitamente identificados pelos clientes, diferentemente dos componentes de processo.
Para suportar todas essas características, o CCM expande a Linguagem de Definição de Interface CORBA (IDL) e cria a Linguagem de Definição para a Implementação de Componentes (CIDL) (Bartlett, 2001). A CIDL adiciona novas palavras-chave para descrever o comportamento dos componentes CCM, além da especificação necessária para interação com o container CCM.
Interoperabilidade com o EJB
De maneira geral, o CCM e o EJB são modelos que possuem muitas semelhanças, porque foram projetados com os mesmos objetivos (iCMG, 2004). Ambos possuem um ambiente de execução e gerenciamento de componentes (containers), e utilizam diferentes tipos de componentes (por exemplo, persistentes e não-persistentes). O CCM, inclusive, possui um adaptador (bridge) para se comunicar com componentes EJB.
Entretanto, durante a fase de desenvolvimento, um componente EJB é originalmente definido na linguagem Java, e um componente CCM é definido através da IDL e da CIDL. Por causa disso, diferentemente do EJB, o CCM é independente de linguagem.