X-CORE: Um Serviço de Repositório Compartilhado e
Distribuído de Componentes de Software
João PauloF.Oliveira, Talles Brito,AdrianaOliveira,SebastiãoRabelo,GlêdsonElias COMPOSE - Departamento de Informática
Universidade Federal da Paraíba (UFPB) – João Pessoa, PB – Brasil
{joaopaulo,talles,drill,sebastiao,gledson}@compose.ufpb.br
Abstract. This paper presents X-CORE, a repository service that provides shared
and distributed mechanisms to facilitate component based software development processes. Besides providing functionalities, such as configuration management, reuse metrics and metadata for representing assets, X-CORE also provides security facilities, making possible to protect users, information and assets.
Resumo. Este artigo apresenta o X-CORE, um serviço de repositório que provê
mecanismos compartilhados e distribuídos para auxiliar no desenvolvimento de software baseado em componentes. Além de suportar um conjunto de funcionalidades, tais como gerência de configuração, métricas de reuso e metadados para representação dos artefatos, o X-CORE também provê facilidades de segurança, protegendo usuários, informações e artefatos.
1. Introdução
A evolução dos processos de desenvolvimento de software tem caminhado na direção da redução do esforço de produção e manutenção através do reuso [1]. Porém, para alcançar as metas de qualidade e produtividade almejadas, não basta apenas disponibilizar componentes. As organizações necessitam desenvolver mecanismos que possibilitem aos desenvolvedores facilmente reusá-los, pois, como mencionado por Crnkovic [1], ainda existe dificuldade de identificar, selecionar, negociar e recuperar componentes que atendam aos requisitos especificados, e, além disso, possuam alto grau de reusabilidade e qualidade.
Neste cenário, repositórios de componentes surgem como instrumentos de auxílio no reuso de componentes, pois possibilitam o armazenamento, a busca e a recuperação dos mesmos. Apesar das relevantes contribuições, os principais repositórios propostos na academia e indústria [2][3][4][5][6][7][8] adotam, geralmente, abordagens locais e centralizadas, que inibem a existência de uma expressiva quantidade de componentes, limitando a reusabilidade, acessibilidade, disponibilidade e escalabilidade. Além disso, como indicado por Grundy [9], muitos repositórios foram desenvolvidos com base em abordagens similares às utilizadas por bibliotecas de software, herdando suas deficiências, como a falta de um alto nível de descrição dos componentes e a inexistência de validação e certificação dos componentes.
Com o objetivo de superar as limitações expostas, o grupo COMPOSE (Component Oriented Service Engineering) propôs o ComponentForge [10], um framework arquitetural que adota uma abordagem de arquitetura orientada a serviços (SOA – Service-Oriented Architecture), na qual um conjunto de serviços distribuídos, compartilhados, independentes e fracamente acoplados comunicam-se e colaboram entre si através de interfaces e protocolos de comunicação bem definidos. O ComponentForge é organizado em três camadas. A camada superior é composta por ferramentas de gerenciamento e desenvolvimento. A camada intermediária é composta pelos serviços de busca, certificação, negociação. A camada inferior é definida pelo serviço de repositório,
que provê a infra-estrutura adotada pelos demais serviços do framework para armazenar, indexar, buscar, recuperar, certificar e negociar variados artefatos de software, incluindo códigos executáveis e fonte, especificações de interfaces e componentes, documentações e diagramas.
No contexto do ComponentForge, este artigo apresenta a implementação do serviço de repositório, denominado X-CORE, que adota uma abordagem distribuída e compartilhada, pois é baseado em um conjunto de entidades geograficamente dispersas que cooperam para prover as funcionalidades especificadas aos vários produtores que podem manipular de forma autônoma e independente seus artefatos. Além disso, o X-CORE inclui facilidades de gerência de configuração, métricas de reuso, metadados para representação dos artefatos, como também trata aspectos de segurança relacionados à autenticação, privacidade, controle de acesso e visibilidade.
O restante deste trabalho está organizado da seguinte forma. Na Seção 2, o serviço de repositório é apresentado, destacando a arquitetura adotada e as suas funcionalidades. Na seção 3, um cenário de utilização do serviço de repositório é ilustrado. Por fim, a Seção 4 apresenta algumas considerações finais.
2. O Serviço de Repositório X-CORE
O serviço de repositório X-CORE (X-ARM Component Repository) atua como um middleware, provendo meios para armazenar, localizar, recuperar e gerenciar componentes. O X-CORE é composto por uma coleção de entidades cooperantes e distribuídas, denominadas containers, que, conjuntamente, provêem facilidades através de interfaces bem definidas. Como mostra a Figura 1, o projeto arquitetural do container está organizado em três camadas, onde cada uma destas provê um conjunto de componentes, que também adotam a abordagem de serviços. A Figura 1 também ilustra a relação entre os demais serviços do ComponentForge e o serviço de repositório X-CORE.
Figura 1. Arquitetura em camadas e serviços do container
A camada de acesso permite a interação das ferramentas e dos outros serviços do ComponentForge com o container e com o serviço de repositório como um todo. A camada de distribuição trata de aspectos de distribuição e segurança, tornando possível a descoberta transparente e a segurança das informações armazenadas nos containers. Por fim, a camada de armazenamento disponibiliza facilidades de persistência, que são adotadas pelos serviços das camadas de acesso e de distribuição, oferecendo meios para armazenar, atualizar e recuperar artefatos.
Com o objetivo de concretizar a arquitetura proposta, o protótipo foi implementado utilizando componentes Enterprise JavaBeans [11] e Web Services [12], executando em um servidor de aplicações JBoss Application Server [13], conforme
Camada de
ArmazenamentoServiço de Persistência Container N Container 1 Container 2 X-CORE Camada de Distribuição Serviço de Diretório Serviço de Segurança Camada de Acesso Serviço de Gerenciamento Serviço de Administração Serviço de Desenvolvimento Serviço do Consumidor Serviço de Qualidade Serviço de Descoberta Serviço de Negócio Serviço de Busca Serviço de Negociação Serviço de Certificação Ferramentas Container
ilustrado na Figura 2. A camada de acesso foi implementada usando stateless beans, pois os serviços desta camada não precisam manter informações de estado dos clientes. Além disto, suas interfaces são expostas como Web Services, proporcionando assim interoperabilidade.
A camada de distribuição também foi implementada utilizando stateless beans. Porém, a fim de tornar mais eficiente a manipulação de dados importantes para os serviços de diretório e de segurança, estes dados são mantidos em memória por um tipo especial de bean, denominado MBean[14]. Para suportar mecanismos de autenticação dos usuários e integridade das informações, foi utilizada uma implementação da especificação WS-Security [15], que trata questões de criptografia e assinaturas digitais.
A camada de armazenamento foi implementada utilizando entity beans, juntamente com o sistema de gerenciamento de banco de dados MySQL [16]. Vale ressaltar que, em conjunto, as tecnologias adotadas atendem satisfatoriamente às necessidades do serviço de repositório, e, em testes realizados, têm se mostrado adequadas em relação à manutenibilidade, confiabilidade e escalabilidade.
Web Services Clientes do Serviço de Repositório HTTP SOAP WS-Security RMI MySQL SQL
JBoss Application Server
Enterprise Java Beans
Acesso Armazenamento
Distribuição
Figura 2. Visão Geral da Implementação
A seguir, as funcionalidades de cada serviço do container, em sua respectiva camada, serão identificadas. Porém, por questão de espaço, não será possível mencionar e detalhar todas as interfaces e operações dos vários serviços.
2.1 Camada de Acesso
A camada de acesso é composta por um conjunto de sete serviços que, conjuntamente, provêem mais de 400 operações distribuídas em 33 interfaces e viabilizam a interação dos usuários (gerente do container, administradores de zona, desenvolvedores e consumidores) e serviços do ComponentForge (serviços de certificação, negociação e busca) com o container.
Serviço de Gerenciamento. Entidades que desejam compartilhar ou até mesmo comercializar seus artefatos necessitam estar cadastradas em um container. Neste contexto, por meio do serviço de gerenciamento, o gerente do container registra essas entidades em zonas, que estão dispostas em uma árvore hierárquica no serviço de repositório. Além disso, o gerente pode obter informações estatísticas sobre o container, e, ainda, manipular informações necessárias à autenticação do container.
Serviço de Administração. Para facilitar a organização dos artefatos armazenados em uma zona, os administradores de zona podem subdividi-la em domínios, cuja função é agrupar artefatos por área de aplicação ou produto. Para tal, o serviço de administração provê operações para que o administrador da zona crie e remova domínios, assim como registre e remova papéis que serão desempenhados por administradores e desenvolvedores, incluindo a configuração de suas permissões de acesso.
Serviço de Desenvolvimento. Possibilita aos desenvolvedores registrar, remover e recuperar artefatos, bem como controlar as versões desenvolvidas e configurar as permissões de acesso de desenvolvedores externos a sua zona, por meio de esquemas de visibilidade para seus artefatos. Além disso, é possível ao desenvolvedor manipular as informações do modelo de representação de artefatos, o X-ARM [17], por meio de
operações que além de registrar informações funcionais, também registram informações sobre os modelos de certificação e de negócio adotados pelos produtores dos artefatos. Serviço do Consumidor. Permite aos consumidores acessar e recuperar os artefatos armazenados no repositório, como também os próprios metadados X-ARM que os descrevem. Este serviço ainda permite que os consumidores registrem informações de reuso, tais como áreas de aplicação, graus de satisfação e comentários sobre o artefato. Vale ressaltar que o serviço do consumidor permite apenas a manipulação de artefatos sem modelo de negócio, e, portanto, que podem ser livremente recuperados.
Serviço de Qualidade. Provê meios para que serviços de certificação do ComponentForge, que são independentes do X-CORE, registrem e recuperem certificados de qualidade emitidos para artefatos e também para processos de desenvolvimento adotados pelos produtores. O serviço de qualidade permite aos produtores controlar quais serviços de certificação podem registrar certificados.
Serviço de Descoberta. Possibilita que serviços de busca do ComponentForge, que também são independentes do X-CORE, façam varreduras da árvore hierárquica do serviço de repositório, recuperando e indexando as descrições X-ARM e os próprios artefatos. O serviço de descoberta permite aos produtores controlar quais serviços de busca podem recuperar e indexar seus artefatos.
Serviço de Negócio. Provê operações para que os serviços de negociação do ComponentForge, que também são independentes do X-CORE, possam recuperar os artefatos e seus modelos de negócio. O serviço de negócio permite aos produtores controlar quais serviços de negociação podem negociar e recuperar seus artefatos com modelos de negócio. Assim, quando um consumidor deseja recuperar um artefato com modelo de negócio, deve adquiri-lo via o serviço de negociação autorizado, que, por sua vez, recupera o artefato por meio das interfaces do serviço de negócio.
2.2 Camada de Distribuição
A camada de distribuição trata aspectos não funcionais do serviço de repositório relacionados à distribuição e segurança. Para tal, esta camada oferece dois serviços que conjuntamente provêem 280 operações distribuídas em 10 interfaces.
Serviço de Segurança. Para prover autenticação, integridade e privacidade, os containers adotam técnicas de assinatura digital e criptografia. Para tal, o serviço de segurança provê operações para cadastrar informações de segurança (chaves públicas) dos usuários, dos serviços autorizados e dos outros containers, bem como assinar e cifrar as mensagens que são trocadas com o container. Além disto, o serviço de segurança provê um mecanismo de controle de acesso, semelhante ao modelo RBAC (Role-Based Access Control) [18], onde as permissões de acesso são associadas a papéis, que, por sua vez, são atribuídos aos usuários e serviços.
Serviço de Diretório. O X-CORE utiliza um esquema de nomes hierárquico, organizados em uma árvore dispersa entre os containers, de forma a possibilitar a localização não ambígua. Assim, o serviço de diretório é o responsável pelo processo de resolução de nomes, que traduz nomes hierárquicos de zonas, domínios e artefatos para os identificadores dos respectivos containers onde estão localizados.
2.3 Camada de Armazenamento
A camada de armazenamento provê um único serviço, denominado Serviço de Persistência, que coopera com todos os demais serviços do X-CORE, proporcionando independência em relação ao sistema de armazenamento (SGBD ou sistema de arquivo)
usado pelo container. Essa cooperação ocorre através de 7 interfaces que, em conjunto, provêem cerca de 300 operações.
3. Um Cenário de Uso
Para facilitar o entendimento das funcionalidades e do uso do X-CORE, apresentamos um cenário no qual o repositório é utilizado como instrumento para desenvolver e compartilhar artefatos entre duas equipes de desenvolvedores e, posteriormente, consumidores. As etapas que compõem o cenário de uso são indicadas na Figura 3.
Primeiramente, o gerente do container registra as zonas de níveis superiores (br e br.ufpb) ativando operações da interface IManageZone do serviço de gerenciamento (Etapa 1). Em seguida, para viabilizar a resolução de nomes, o administrador da zona (br) faz a associação da sua zona filha (br.ufpb) na árvore hierárquica (Etapa 2) usando operações da interface IManageHierarchicalTree do serviço de administração.
Com o objetivo de organizar os artefatos gerados pelas equipes de desenvolvedores, o administrador da zona (br.ufpb) registra dois domínios usando operações da interface IManageZone do serviço de administração (Etapa 3). Os domínios br.ufpb.specification e br.ufpb.implementation são usados para manter artefatos de especificação de componentes e implementação de componentes, respectivamente.
Em seguida, o administrador de zona utiliza operações da interface IManageUser do serviço de administração para definir papéis, atribuir permissões aos papéis, cadastrar desenvolvedores e associá-los aos seus respectivos papéis (Etapas 4 e 5). Vale ressaltar que os papéis associados aos desenvolvedores possuem restrições de acesso de forma que a equipe de especificação pode apenas registrar e recuperar artefatos do domínio br.ufpb.specification (Etapa 6), enquanto que a equipe de implementação pode recuperar e registrar artefatos do domínio br.ufpb.implementation, além de também poder recuperar artefatos do domínio br.ufpb.specification, pois necessita das especificações para implementar os componentes (Etapa 7). Durante o processo de desenvolvimento, para registrar os artefatos, os desenvolvedores utilizam a interface IManageAsset do serviço de desenvolvimento. Para registrar e controlar novas versões dos artefatos, podem utilizar a interface IConfigurationMgmt do mesmo serviço.
Por fim, consumidores que desejam reusar artefatos devem interagir com o X-CORE para adquiri-los (Etapa 8), e, posteriormente, registrar informações de reuso sobre o artefato, indicando, por exemplo, o grau de satisfação e comentários em relação ao reuso dos artefatos (Etapa 9). Esta interação é feita usando operações das interfaces IRetrieveAsset e IAssetReuseInformation do serviço do consumidor, respectivamente.
4. Considerações Finais
Este artigo apresentou o X-CORE, um serviço de repositório que, diferentemente dos principais repositórios existente no mercado e na academia, reúne simultaneamente um conjunto de funcionalidades, tais como: mecanismos próprios de controle de versões; um conjunto de informações de reuso que facilitam o processo de escolha de um dado artefato; e um modelo de descrição de artefatos (X-ARM) mais abrangente, que descreve as funcionalidades dos artefatos, como também inclui informações sobre o processo de desenvolvimento, histórico de evolução, modelos de componentes e classificação em domínios de aplicação. Além disso, o X-CORE adota um esquema de segurança que permite autenticar e controlar o acesso dos usuários. Explorando o conceito de papéis, este esquema facilita a administração e manutenção dos usuários.
Como principais benefícios da adoção de uma arquitetura distribuída e compartilhada, o X-CORE possui satisfatórios graus de acessibilidade, escalabilidade e disponibilidade, que, em conjunto, têm o potencial de promover o aumento da quantidade de componentes disponíveis no repositório.
Como trabalhos futuros, podemos destacar a implementação dos demais serviços que compõem o ComponentForge, assim como a implementação de funcionalidades que assegurem uma melhor comunicação para equipes distribuídas. Por tratar-se de um protó-tipo, o X-CORE ainda não possui uma forma de licenciamento definida pelos autores, mas, instruções para avaliação de uma instância ativa do serviço podem ser obtidas em “http://www.compose.ufpb.br/x-core”.
5. Referências
[1] Crnkovic, Ivica. (2003) “Component-Based Software Engineering–New Challenges in Software Development”. 25th International Conference on Information Technology Interfaces (ITI’03), pp. 127-133, Cavtat, Croatia.
[2] Inoue, K. et al. (2003) “Component Rank: Relative Significance Rank for Software Component Search”. 25th International Conference on Software Engineering (ICSE), pp. 14-24, Portland, Oregon.
[3] Ye, Y. (2001) ”Supporting Component-Based Software Development with Active Component Repository Systems”. PhD Thesis, University of Colorado.
[4] Component Source (2007). http://www.componentsource.com.
[5] SourceForge Enterprise Edition (2006). http://www.vasoftware.com/sourceforge.
[6] Xtras.Net (2006). http://xtras.net.
[7] CompoNex (2006). http://www.componex.biz.
[8] Boldyreff, C.; Nutter, D.; Rank, S. (2003) “Open-Source Artifact Management”. 3rd Workshop Open Source Software Engineering, Orlando, Florida, USA.
[9] Grundy J.; Wang, X. and Hosking, J. (2002) “Building Multi-device, Component-based, Thin-client Groupware: Issues and Experiences”. Australian Computer Science Conference, Volume 24, Issue 4, pp. 71-80, January-February 2002.
[10] Oliveira, J.P.F.; Santos, M.S.; Elias, G. (2006). “ComponentForge: Um Framework
Arquitetural para Desenvolvimento Distribuído Baseado em Componentes. VI Workshop de Desenvolvimento Baseado em Componentes.
[11] Sun Microsystems. (2006) “Java™ Platform, Enterprise Edition 5”. http://java.sun.com/javaee/5/docs/API
[12] Stal, M. (2002) “Web Services: Beyond Component Based Computing“.
Communications of the ACM, Vol. 45, Issue 110, pp 71-76.
[13] JBoss Reference Guide (2007).
http://docs.jboss.com/jbportal/v2.6/reference-guide/en/html.
[14] JMX (Java Management Extensions) “Java Management Extensions”.
http://java.sun.com/j2se/1.5.0/docs/guide/jmx
[15] OASIS Specification (2006) “Web Services Security”.
http://docs.oasis-open.org/wss/v1.1.
[16] MySQL 5.0 (2007) “Reference Manual”. Copyright 1997-2007 MySQL AB.
[17] Schuenck, M. (2006) “X-ARM: Um Modelo de Representação de Artefatos de
Software”. Dissertação de Mestrado, DIMAp-UFRN, Natal-RN.
[18] Ferraiolo, D. F. et al. (2001) “Proposed NIST Standard for Role-Based Access
