Introdução
Um modelo de componente define novos recursos e serviços que permitem aos desenvolvedores de aplicação implementar, gerenciar, configurar e implantar componentes de forma padronizada, facilitando a reutilização e a manutenção do sistema.
Criada pelo Object Management Group (OMG), o modelo CORBA estabelece e simplifica a troca de dados entre sistemas distribuídos. Propõe a comunicação local e/ou remota entre aplicações que têm como base a tecnologia orientada a objetos. Entretanto, a especificação de CORBA não atende bem a determinados pontos tais como: Padrão para implantação, estender funcionalidades de objetos CORBA, definição de serviços, entre outros, levando a OMG a adotar o CORBA Component Model (CCM) como parte da especificação de CORBA 3.0.
O CCM é uma extensão do modelo de objetos CORBA criado para tratar os problemas citados a cima e que foram deixados em aberto por esta arquitetura.
O modelo descreve como um componente é constituído, como armazena suas propriedades internas (atributos) e como se comunica com outros componentes (portas). Os componentes criados usando o padrão CCM podem ser instalados em servidores de diversos fornecedores (que respeitam a especificação CCM).
OMG – Padronização
O Object Management Group (OMG) é um consórcio internacional da indústria de software fundado em maio de 1989 com o propósito de criar padrões para possibilitar a interoperabilidade e portabilidade das aplicações distribuídas utilizando a tecnologia de objetos.
A organização desenvolve padrões de integração de uma grande variedade de tecnologias, incluindo padrões de middleware e perfis, são baseados na arquitetura de agente de solicitação de objeto (CORBA) e suporta uma grande variedade de indústrias.
Os trabalhos de padronização do OMG são executados sobre um modelo conceitual denominado core object model e uma arquitetura geral de referência denominada Object Management Architecture (OMA) que busca definir de forma abstrata as várias funcionalidades necessárias a computação distribuída, onde cada componente de software é representado como um objeto.
O OMG não tem como propósito a produção de software, somente especificações, criadas a partir de ideias e tecnologias propostas e discutidas pelas organizações membro envolvidas com a computação distribuída.
Dentre os muitos membros podemos destacar as grandes industrias tais como Dell, Ericsson, Microsoft, IBM, HP e Apple.
Origem CCM – Modelo Corba
CORBA é uma tentativa de cooperação da indústria de computação coordenada pelo OMG no sentido de desenvolver um padrão aberto para possibilitar computação distribuída entre ambientes de aplicação. A inovação do modelo foi a orientação a objeto e sua independência em relação a protocolo, sistema operacional, linguagem de programação de plataforma de hardware.
Para utilizar o modelo, exige-se apenas que a aplicação, escrita de qualquer linguagem, instalada em qualquer lugar da rede, mapeie sua interface para IDL (Interface Definition Language), que se trata da linguagem neutra do padrão, desenhada para a disponibilização e acesso a serviços (métodos e funções) de objetos remotos CORBA.
A arquitetura CORBA possui duas partes de destaque: A IDL – que é empregada para estabelecer contratos, limitando a interação das aplicações e estabelecendo as interfaces com os clientes, constituindo-se uma linguagem neutra, dispõe de mecanismos para que as interfaces dos componentes de aplicações distribuídas possam especificar herança de classes, eventos, atributos e exceções em padrão compatível com a base ORB. E sua outra parte ORB – que funciona como uma ponte, disponibilizando a infra-estrutura de comunicação para enviar e receber solicitações e respostas dos clientes para os servidores.
CORBA permite a implementação em linguagens de programação bastante difundidas atualmente como "C", "C++" e Java.
Estrutura CCM
A estrutura de componente CCM possuí quatro tipo de portas, que são os pontos de comunicação dos componentes.
- Facetas - interfaces fornecida pelo componente;
- Receptáculos - referências para outros objetos com os quais o componente interage;
- Emissores de evento - utilizadas para produzir eventos;
- Receptores de eventos - utilizadas para consumir eventos.
Eventos - Estabelecem uma comunicação entre componentes.
Completando a estrutura verifica-se a existência de cinco tipos de categorias:
- Serviço (Service) - Componente limitado a duração de execução do método. São usados para chamar métodos como consultas ou execução de código;
- Sessão (Session) - Disponível durante toda a existência de uma chamada, ou seja, ele fica aberto de forma independente para cada cliente, armazenando as informação enquanto o cliente estiver executando funções. São usados para operações do tipo iterador, ou quando o resultado de uma operação chamada for pré-requisito para o acionamento da próxima operação;
- Processo (Process) - Componentes persistentes usados para representar, no servidor, processos de negócio em lugar de representar tabelas de BD;
- Entidade (Entity) - Continua no sistema, mesmo que o cliente que o chamou tenha o fechado, ou seja, podem ser obtidos posteriormente através de uma chave primária.São usados para realizar mapeamento, assim, cada instância representa na forma de objetos uma determina "tupla" de uma tabela.
- Vazio (Empty) - Um componente vazio tem seu funcionamento customizado pelo desenvolvedor, através dos descritores de instalação e da implementação do executores.
A modelagem CCM é usada por clientes (usuários comuns) para realizar operações através de referência a uma instância, ou seja, podem navegar pelas interfaces dos componentes por intermédio defina em CORBA.Também é usada por desenvolvedores que configuram componentes.
Para que serve?
O modelo 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.
Uma das principais contribuições do CCM é a padronização do processo de desenvolvimento de componentes, tratando alguns problemas deixados em aberto pela arquitetura CORBA. Esta padronização pode ser resumida como: O desenvolvedor de componentes define, em IDL, as interfaces que as implementações dos componentes irão suportar, como armazena suas propriedades internas (atributos), como se comunica com outros componentes (portas), implementar os componentes utilizando ferramentas disponibilizadas pelo fornecedor do CCM, empacotar o componente em uma DLL e implementar o componente por mecanismo desenvolvido pelo fornecedor do CCM.
Os componentes são armazenados num pacote contendo sua implementação e a descrição de suas características, permitindo que o executor tenha acesso às conexões em suas portas, assim como utilizar serviços de objetos da arquitetura. Esse pacote é então utilizado para implantar o componente num servidor de componentes, onde esse pode ser então utilizado por clientes.
Estes componentes são desenvolvidos para executar uma atividade específica combinada para compor aplicações. O componente encapsula, dentro de si, seu projeto e implementação, e oferece serviços, por meio de interfaces para o meio externo. Em geral são desenvolvidos usando os métodos, técnicas, linguagens e ferramentas tradicionais, podendo ser facilmente utilizados e reutilizados em outras aplicações ou fornecidos por terceiros.
Com utilização destes componentes, além de diminuir o tempo para o desenvolvimento do software, a confiabilidade também é melhorada, pois os componentes são testados individualmente.
Outra vantagem do uso de componentes é a manutenção do software, pois os componentes podem ser substituídos e atualizados independentemente do restante da aplicação, e esta atualização é feita pelo fornecedor do componente.
Conclusão
Um modelo de componente define a forma como os componentes são vistos, aspectos da estrutura interna, mecanismo usado para a comunicação entre os componentes, o processo de desenvolvimento, de distribuição e de implementação.
Os componentes desenvolvidos a partir do modelo fornecem serviços a terceiros através de suas interfaces contribuindo para que o tempo de desenvolvimento seja diminuído, devido a reutilização dos códigos, e que a confiabilidade e facilidade na manutenção do software sejam melhorados.
Referências
BARBOSA, Nadia Milena, UFCG,
O que é CCM?, Paraíba, Disponível em <
http://www.dsc.ufcg.edu.br/ ~wdcopin/VWDCOPIN/artigos/
nadia/WDCOPIN_nadia.pdf> Acesso em 16 mar. 2013.
