Novos Modelos de Componentes de Software

COMQUAD

O modelo de componentes COMQUAD (Components with Quality properties and Adaptivity) [62] tem como objetivo propiciar a especificação e suporte em tempo de execução de alguns aspectos não- funcionais do sistema, tais como propriedades de QoS (tempo de resposta, precisão, banda de rede e uso de CPU) e propriedades de mais alto nível para o usuário final (qualidade de vídeo e número de clientes ativos no servidor) para o domínio de aplicações tempo-real. Este modelo, definido recente- mente, utiliza alguns conceitos dos modelos EJB e CCM, bem como adiciona a estes a especificação dos aspectos não-funcionais citados (realizados via interceptadores como mecanismo de programação reflexiva), a gerência pelo contêiner da instanciação e conexão de implementações de componentes, além de interfaces de fluxos (streams). COMQUAD suporta ainda adaptação dinâmica de compo- nentes via interceptadores disponíveis no servidor de aplicação JBOSS [63].

COMQUAD restringe o modelo de componentes em função da tecnologia à qual está vinculado. Está ainda em desenvolvimento uma implementação de um contêiner sobre o sistema operacional

de tempo real DROPS [61]. Componentes COMQUAD da aplicação executarão parte sobre este contêiner e parte sobre o servidor de aplicação JBOSS. Outra restrição imposta pela vinculação de aspectos dependentes da tecnologia (recursos tempo real) é a imposição de que componentes sofram composição apenas através do contêiner. Esta restrição visa garantir que os recursos necessários para as interações de tempo real serão corretamente alocados. COMQUAD exige ainda a descrição de componentes em COMQUAD IDL, uma extensão de CCM-IDL para incorporar interfaces de fluxo contínuo e o uso de interceptadores portáveis CORBA para monitoração e adaptação dinâmica de componentes. Com estas restrições, a utilização ampla do modelo fica comprometida.

A proposta apresentada nesta tese de desvincular o modelo de componentes da tecnologia de im- plementação é uma vantagem em relação ao modelo COMQUAD. Por exemplo, no modelo CM-tel é possível implementar uma outra plataforma que represente um mapeamento para um ambiente de tempo real. As particularidades deste ambiente ficariam circunscritas ao mapeamento (mais especifi- camente, ao descritor de distribuição deste mapeamento), e não no modelo de componentes como no COMQUAD. Modelos neutros permitem ainda a especificação de componentes em alto nível, como UML, em oposição a notações vinculadas a tecnologias como IDLs.

A plataforma que implementa o modelo CM-tel para as tecnologias CORBA/Java permite tam- bém o uso de interceptadores portáveis CORBA para adaptação dinâmica do comportamento de com- ponentes, de forma semelhante ao COMQUAD. Interceptadores permitem ainda incorporar novas funções à plataforma tais como criptografia, controle de acesso, auditoria, monitoramento e segu- rança. Quanto à adaptação dinâmica ao ambiente de execução, nosso modelo permite um segundo mecanismo ainda mais rico que interceptadores, agentes móveis.

Finalmente, apesar de certas similaridades com o modelo aqui proposto, notadamente interfaces de fluxos, de sinal e capacidade de adaptação dinâmica para comportamento de componentes e am- biente de execução, os artigos sobre o modelo COMQUAD publicados recentemente informam que aspectos de implementação ainda serão divulgados e não citam aplicações que fazem uso deste mo- delo, sugerindo um estágio preliminar de desenvolvimento.

OpenORB

A plataforma OpenORB [64] e seu modelo de middleware reflexivo apresentam uma solução construída no topo de um modelo de componentes denominado OpenCOM [65], derivado do modelo centralizado COM [66] da Microsoft. Portanto, diferentemente da nossa proposta, OpenORB trata de uma proposta dependente de tecnologia (CORBA, C++ e plataforma Windows). OpenORB apre- senta uma plataforma de middleware, onde os componentes são organizados em dois espaços (níveis): nível base e nível meta. Os componentes pertencentes ao nível base implementam os serviços que são comumente encontrados nos middlewares existentes. Os componentes pertencentes ao nível meta

são eventualmente conectados àqueles do nível base e oferecem facilidades que permitem aos progra- madores inspecionar e adaptar a plataforma às necessidades da aplicação.

Nossa proposta para adaptação dinâmica baseada em código móvel não exclui o uso de reflexão, mas deixa para a plataforma dependente de tecnologia a sua implementação. Por exemplo, um ma- peamento poderia incluir componentes situados no nível meta (como no caso do OpenORB), utilizar a introspecção oferecida pela linguagem de programação (como no caso de Java) ou ainda utilizar propriedades para inspeção e alteração de parâmetros da plataforma9_{. Para um modelo independente}

de tecnologia, acreditamos que o único suporte à introspecção possível seria o componente expor, via interface ou propriedades, a sua especificação em uma linguagem neutra.

A plataforma OpenORB define uma API (Application Programming Interface) básica [67] para suporte a conexões de componentes ponto-ponto. Esta API pode ser estendida para suportar dife- rentes tipos de conexões (bindings) entre componentes OpenCOM, tais como invocação síncrona e assíncrona de métodos remotos, filas de mensagens, esquemas publicador/subscritor, fluxos de mídia contínua e protocolos de alocação de recursos. A desvantagem da estratégia adotada pelo OpenORB aos diferentes tipos de conexões é que a API básica deve ser estendida pelo desenvolvedor da apli- cação, com a adição de novas funções, para cada tipo de conexão que a aplicação venha a requerer. Esta estratégia é bastante limitada dado que exige do desenvolvedor o fornecimento de todo o código para a realização da conexão.

Uma linha de trabalho semelhante à API da plataforma OpenORB relata uma arquitetura [68] que propõe a construção de aplicações distribuídas utilizando componentes de interação denominados

mediuns para diferenciá-los dos componentes funcionais da aplicação. Mediuns encapsulam serviços

ou protocolos de comunicação reusáveis (por exemplo, difusão de vídeo, protocolos de votação e caixas de mensagens). Desta forma, os mediuns propiciam aos componentes funcionais um conjunto restrito de esquemas de interações. Mediuns não executam em contêineres, sendo portanto entidades distintas dos componentes de aplicação que os utilizam.

O modelo proposto nesta tese provê as duas formas de interação (ponto-ponto e ponto-multiponto) para cada um dos três tipos de interfaces prescritos pelo modelo RM-ODP. Este modelo de inte- ração é genérico o suficiente para atender a maioria das aplicações distribuídas, conforme descrito na Seção 3.2.2. Outra característica importante do modelo proposto é permitir a adição de novos modos de conexão com a utilização de componentes baseados no modelo e não por extensões de APIs como no projeto OpenORB. A plataforma que implementa o mapeamento do modelo CM-tel para as tecnologias de Serviços Web e J2ME gera componentes de configuração a partir de diagramas UML de colaboração [32]. Acreditamos que esta é a maneira desejável pela qual as aplicações podem

9_{A plataforma implementada para CORBA-Java no escopo desta tese utiliza propriedades para inspeção e alteração}

obter benefícios ao especificar diferentes formas de conexão em alto nível e não pela utilização de APIs que exigem do desenvolvedor da aplicação grande esforço de codificação.

Finalmente, uma característica fundamental, recomendada pela engenharia de software para mo- delos de componentes e que é adotada pelo nosso modelo de componentes, é a capacidade do com- ponente armazenar as referências do outro extremo da conexão [11]. Este mecanismo, denominado receptáculo no CCM10, armazena referências de interfaces necessárias para a execução deste compo- nente e é descrito na Seção 3.2. Dos modelos de componentes reportados na literatura, além do CCM, apenas os modelos CM-tel e COMQUAD possuem este mecanismo.