Você está na página 1de 102

“DYMOS: Uma abordagem para suporte a variabilidades

dinâmicas em Linhas de Produto de Software Orientado a
Serviços e Sensível ao Contexto”
Por

Dhiego Abrantes de Oliveira Martins
Dissertação de Mestrado

Universidade Federal de Pernambuco
posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao

Recife, Agosto/2013

Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação

Dhiego Abrantes de Oliveira Martins

“DYMOS: Uma abordagem para suporte a
variabilidades dinâmicas em Linhas de Produto de
Software Orientado a Serviços e Sensível ao Contexto”

Trabalho apresentado ao Programa de Pós-graduação em
Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial
para obtenção do grau de Mestre em Ciência da Computação.

Orientador: Vinicius Cardoso Garcia
Co-Orientador: Uirá Kulesza

Recife, Agosto/2013

Este trabalho representa um passo muito importante em
minha vida e eu o dedico a meus pais, que sempre serão
minha fonte inesgotável de inspiração em querer uma
superação a cada dia, lutando de mãos limpas pelo meu
crescimento pessoal e profissional.

iii

Agradecimentos

Inicialmente eu agradeço a Deus, por ter me permitido chegar até aqui e cumprir com
sucesso os meus objetivos. Apenas ele sabe o quão desgastante [e prazerosa] foi esta
jornada.
Agradeço a meus pais Carlos e Branca, por todo o esforço e dedicação incomensuráveis para me prover o melhor, dentro de seus limites. A minha irmã Mirella, pelos
momentos de paciência quando eu estava em momentos de stress. Eu amo vocês.
Agradeço a minha namorada, Marta Soraya, pela paciência, companheirismo, apoio,
força e motivação que sempre me proporcionou. Sem você, tudo seria mais difícil. Ou
simplesmente não seria.
Agradeço aos inesquecíveis amigos dos CInFuturo: Paulo Fernando, Airton Pereira,
Lenin Abadié, Marco André, Thiago Vieira, Rodolfo Arruda, Adriano Tito, Bruno Felipe e Hélio Rodrigues. Senhores, que a nossa amizade seja eterna! Obrigado pelos
momentos de descontração!
Agradeço aos amigos Jackson Raniel e Renê Gadelha, por estarem presentes quando
mais precisei e, simplesmente, por serem amigos verdadeiros!
Agradeço aos demais amigos, com quem compartilhei momentos de aprendizado e
de aperreios em disciplinas, artigos e projetos: Fernando Selleri, João Emanoel (João
de Tuta), Jamilson Batista, Ivan Samuel, Kelliton Brito (KBrito) e Fernando Carvalho
(Fish).
Agradeço aos companheiro de AP Júlio Cesar (Pastor Júlio) e Rodrigo pelo companheirismo e “tiração de onda” durante o tempo que convivemos no mesmo AP. “Que
vocês casem primeiro!!! hahaha”
Agradeço aos Professores Silvio Meira (Engenharia de Software), Augusto Sampaio
(PLP), Fábio Queda (Metodologia de Pesquisa e Systematic Literature Review), Paulo
Borba e Fernando Castor (Arquitetura de Software), e Sérgio Soares (Engenharia de
Software Experimental).
Agradeço aos meus Orientadores Vinicius Garcia e Uirá Kulesza pela paciência durante todo este processo de aprendizado e lapidação do conhecimento. Obrigado por
todas as contribuições construtivas e por acreditarem no meu trabalho. Obrigado por
não “me darem de comer” e “me ensinarem a caçar”!
Agradeço a Profa. Rossana Andrade e ao Prof. Kiev Gama por aceitarem compor a
banca examinadora da minha defesa de mestrado.
Por fim, agradeço a Universidade Federal de Pernambuco e a todos que a compõe.

iv

Those mist covered mountains
Are a home now for me
But my home is the lowlands
And always will be
Some day you’ll return to
Your valleys and your farms
And you’ll no longer burn
To be brothers in arms
Through these fields of destruction
Baptism of fire
I’ve whittnessed your suffering
As the battles raged higher
And though they did hurt me so bad
In the fear and alarm
You did not desert me
My brothers in arms
There’s so many different worlds
So many different suns
And we have just one world
But we live in different ones
Now the sun’s gone to hell
And the moon’s riding high
Let me bid you farewell
Every man has to die
But it’s written in the starlight
And every line on your palm
We’re fools to make war
On our brothers in arms
—DIRE STRAITS (Brothers in Arms)

v

Resumo

É notório o surgimento de ambientes cada vez mais dinâmicos, exigindo sistemas mais
flexíveis, de forma que componentes possam ser plugados ou desplugados durante o seu
ciclo de vida, inclusive em tempo de execução. Para atender estes requisitos, é necessário
que decisões sobre possíveis adaptações e variações do produto possam ser tomadas em
tempo de execução. Sistemas Sensíveis ao Contexto atendem a esse propósito, sendo
capazes de adaptar-se em tempo de execução de acordo com mudanças no ambiente,
obedecendo um conjunto de regras.
Quando técnicas de Linhas de Produto de Software (LPS) são aplicadas no desenvolvimento de sistemas adaptativos, tais decisões podem resultar na configuração de um
novo produto. Em uma LPS tradicional, um produto é derivado de acordo com sua configuração, que ocorre na fase de design e consiste na seleção de features que irão compor
o produto, remoção das features que não farão parte do produto e ligação dos pontos de
variação.
Linhas de Produto de Software Dinâmicas extendem o conceito convencional de LPS
abordando aspectos dinâmicos, provendo uma abordagem para tratar variabilidades que
precisam ser manipuladas em tempo de execução.
Quando alinhamos paradigmas como Sistemas Sensíveis ao Contexto, Arquitetura
Orientada a Serviços e LPS, podemos enfrentar alguns desafios. O sistema derivado de
uma LPS é composto por features e pontos de variação. Considerando que o modelo de
Arquitetura Orientada a Serviços segue o padrão arquitetural Cliente-Servidor, podemos
ter um cenário em que as features que compõem o produto no lado cliente podem endereçar uma composição de serviços. Dessa forma, os pontos de variação podem sofrer
variabilidades de acordo com mudanças no contexto, exigindo a execução de reconfigurações nos serviços de modo a atender tais variabilidades. As abordagens propostas
atualmente não oferecem um suporte para esse tipo de problema ou são incipientes, estando em fases iniciais de pesquisa.
Neste trabalho é apresentado um estudo sobre variabilidades dinâmicas em Linhas
de Produto de Software Orientadas a Serviços e Sensíveis ao Contexto, innvestigando
especificamente situações quando features que endereçam um ou mais serviços são reconfiguradas no lado cliente, requerendo reconfigurações nos serviços, no lado servidor.
Palavras-chave: sistemas adaptativos, arquitetura orientada a serviços, linhas de produto de software dinâmicas, reconfiguração dinâmica, variabilidade dinâmica

vi

dynamic variability. we face some challenges. requiring reconfiguration on the server side. a product is derived according to its configuration. Contextaware Systems (CAS) meets this purpose. obeying a set of rules. This work presents a study of variability dynamics in LPSOSSC. demanding the execution of reconfigurations services to meet such variability. Keywords: adaptive system. In a traditional SPL. runtime variability vii . Thus. service-oriented architecture.Abstract It is well known that the onset of more and more dynamic environments requires more flexible systems. The system derived from an SPL is composed of variation points and features. DSPL extends the conventional concept of SPL addressing dynamic aspects. providing an approach to address variability that needs to be manipulated at runtime. being able to adapt at run time according to changes in the environment. so that components can be unplugged or plugged during their life cycle. which occurs in the design phase. dynamic reconfiguration. it is necessary that decisions on possible adaptations and variations of the product can be made at runtime. investigating specific situations where features that address one or more services are reconfigured. The proposed approaches do not currently offer support for this type of problem or are incipient. When Software Product Line (SPL) techniques are applied in the development of adaptive systems. including at run time. When paradigms such as CAS. the variation points may suffer from variabilities according to changes in context. removing features that are not part of the product and the binding of variation points. Whereas the model of SOA follows the Client-Server architectural pattern. being in the early stages of research. SOA and SPL align. such decisions may result in the setting of a new product. we have a scenario in which the features that make the product on the client side can address a service composition. and consists of selecting features that will make the product. dynamic software product line. To meet these requirements.

6 10 12 18 20 21 29 30 31 32 33 34 35 36 37 38 40 41 42 49 51 54 55 56 57 57 58 60 viii . . . .3 3. . . . . .4 2. . .6 4. . LoginServiceProvider: Métodos para estabelecer e finalizar uma conexão com o banco de dados . . . . . .12 3. . . . . . . . . . MySQLDataSourceFactory: Fábrica de conexões MySQL utilizando JDBC MySQLDataSourceFactory: Configuração iPOJO do Componente e sua Instância .2 2. . . . . . . . . . . . . . . . . . . . 3. Descritor de Variabilidades: Estrutura de Metadados . .4 4. . . . . . . . . . . . . . . . . . . .Lista de Figuras 1. . . . . . . . . . . .13 4. Relacionamento entre Descritores . .1 2. . . . . . . . . . Descritor de WSDL: Fluxo de Dados . . . . . . . . Descoberta de Serviços: Diagrama de Sequência . . . . . . . . . . . . .1 DYMOS: Arquitetura Externa . . . . . . . . . . . . . .1 3. . . . . . . . . . . . . . . . . . . . . . . . .5 3. Descritor de Serviços: Exemplo Prático . . Linha de Produto Orientadas a Serviços: Configuração de Produtos . . . . . . . . . . . . . GREat Tour: Modelo de Feature Parcial .5 4. . . LoginService: Configuração parcial do arquivo POM . . . . Descoberta de Serviços: Visão geral sobre a interação entre componentes Descoberta de Serviços: Serviços descritos para um exemplo prático . . .1 4. . . . . . . . .2 3. . . . . . . . . . . . . . . . . . . . . . . . . . .5 Custos do desenvolvimento de uma Linha de Produto . . . . . . . . 3. . . . . . . . . . LoginServiceProvider: Uma implementação para o LoginService . . . .2 4. . . . . . . . . . . .3 2. . . . . MySQLServiceProvider: Dependência entre o Serviço Provedor de Conexões e os demais Serviços Modularizados . . .7 3. . .6 3. . . . . . . . . . . . . . .7 4. . . .4 3. . . . . . . . . . . . . . . . . . . . . .8 4. . . . . Descritor de Variabilidades: Exemplo Prático . . . . . . . . . . . . . . .3 4. 2. . . . . . . . . . . . . . . . . .9 DYMOS: Visão Geral da Arquitetura . . . . . Especificação de Descritores . . . . . . Descritor de Serviços: Estrutura de Metadados . . . . . . . . .10 3. .9 . . . . . . . . . .8 3. . . . LoginService: Especificação . . . Composição de features . . . . . . . . . Reconfigurando Variabilidades Dinâmicas: Diagrama de Sequência . . Atividades Essenciais na Engenharia de Linha de Produto de Software Arquitetura Orientada a Serviços: Papéis e Operações . . . . . . . . . . . .11 3. . . . . . . . . Componente ServiceContext: Uma visão sob uma perspectiva de dependência entre componentes . . . Abordagem utilizada na MobiLine . . .

CIn Tour: Modelo de Feature Parcial . . . . . . . . . . . . . . . . .4. . . . . . . . LoginServiceProvider: Configuração parcial do arquivo POM . . GREat Tour: Descritor de Serviços . . . . . . . . . . . . . . . . .10 4. . . . .16 4. . . . . Aplicação Cliente: Declaração de constantes e Interação com Serviço . . . . . .14 4. . . . . . . . . . . .13 4. . . . . . . . . . . .17 4. .11 4. . . . . . . . . . . . . . . . . . . . . . . .18 LoginServiceProvider: Configuração de Instância . . . . . . . . Aplicação Cliente: Descoberta de Serviço por meio da biblioteca “DymosClientLib” . . .12 4. . . . . . . . . . . . . . GREat Tour: Descritor de Variabilidades . . . . . . . . . . . . . . . . . CIn Tour: Descritor de Variabilidades . . . . . . .19 Aplicação Cliente: Reconfiguração de variabilidades por meio da biblioteca “DymosClientLib” . . . . . . . . . . . . . 4. CIn Tour: Descritor de Serviços . 60 61 63 64 66 67 68 69 70 70 ix . .15 4. . . . .

. .1 4. Requisitos Funcionais e Requisitos NãoFuncionais . . . . . . . . . . . . . .1 Relação entre Componentes. . 47 Relação entre Features e Artefatos . . . . . . . . . . . . . . . . . . . 52 x . . . . . . . . . . . . .Lista de Tabelas 3. . . . .

Lista de Acrônimos AOS Arquitetura Orientada a Serviços COS Computação Orientada a Serviços DS Descritor de Serviços DV Descritor de Variabilidades WSR Web Service Resolver ELPS Engenharia de Linha de Produto de Software JAXB Java Architecture for XML Binding LPS Linha de Produto de Software LPSD Linha de Produto de Software Dinâmica LPSOS Linha de Produto de Software Orientado a Serviços LPSOSSC Linha de Produto de Software Orientado a Serviços e Sensível ao Contexto RF Requisito Funcional RNF Requisito Não-Funcional SSC Sistema Sensível ao Contexto WSDL Web Service Definition Language XML Extensible Markup Language xi .

2 Linhas de Produto Orientadas a Serviços . . . . . . 2. . . . . . . . . . . . . . . . . . . . . . Web Service Resolver . . . . . . . . . Reconfigurando Variabilidades Dinâmicas . DYMOS Framework 3. . . . . . . . . . .1 Componentes Descritores . . . . . . . . . . . . .4 Escopo Negativo . . . . 2. . . 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Princípios e Papéis . . Descritor de Serviços . . . . . . Motivação . . . . . . . . . . . . . . 1.2 Computação Orientada a Serviços: Uma visão geral . . . . . . . . .2. . . . . . . . . 2. . .2. . 23 23 26 27 28 29 31 33 35 36 37 39 43 44 xii . . . . . .4 Arquitetura e Implementação . . . . . . . . . . .5 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . 1 1 3 5 7 8 . . . . . . . . . . . . . . . . . . . . . . . . .Sumário 1 2 3 Introdução 1. . . . .1 Visão Geral da Solução . . . . . . 9 9 10 11 13 14 15 16 16 17 19 21 . . . . . . . 3. . . . . .2 Elicitação de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. . .4 Linhas de Produto de Software Dinâmicas .1. . . . .2 Engenharia de Linha de Produto de Software . . . Revisão da Literatura 2. . Descritor de Variabilidades . . . . . . . . 2. . . . .1 Motivação . . . . .4. . Descoberta de Serviços . . . . . . . 2. . . . . . . . . . . .1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. .2 Componente ServiceContext . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . .3 Modelos de Adoção de Linhas de Produto de Software 2. . . . . . . . . . . . . . . . . . .3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . .1 Arquiteturas Orientadas a Serviços . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . . . . . . 3. .1. . . . . . . . . . . . 3. . . . . .1 Linhas de Produto de Software: Uma visão geral . . . . . . . . 1. . . . . . . . .3 Visão Geral da Solução . .3 Componente ApplicationService . .3 Tecnologias Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . . . . 2. . . . . . . . .4. 2. . . . . . . . . . . . . . . Reconstruindo o ServiceContext com o ContextHotBuild 3. . . .2 Problemática . . 3. . . . .

. . . . . LoginServiceProvider . . . . . . . . . . . . . . . . 4. . . 4. . 4. . . . . . . . . . . . . . . . . . . . . . . 72 72 73 . . . . . .4 4 5 Decisões Arquiteturais e Conclusão . . 45 . .5 Descrevendo Serviços e Variabilidades 4. . . . . . 4. . . . . . . . . . . .2. . . . . . .3. . . . . . . . . . . . . .3 CIn Tour . . . . . . . . . . . . . . . . . . . . 4. . . . . . . . . . . . . . . . . . . . . . . . MySQLServiceProvider . . . . . . . . . .1 Contribuições . . . . . . . . . . . . .3. . . . . . . . . . . . . . .2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . .2 Analisando o Modelo de Features . .1 Análise e Definições . . . . . . . . . . 5. . A. . . .4 Analisando e Integrando a Aplicação Cliente . . . . . . . . . . . . . . .2. . . . . . . . . . . . . . . . . . . . . . . . .4. . A. . . . . 4. . . . . . . . .5 Considerações Finais . . . . . . 82 82 83 84 xiii . Referências 74 Apêndice 81 A Componentes Descritores A.1 Descritor de Serviços . . . . . . . . . .1 MobiLine . . . . . .2 Descritor de Variabilidades . . . . . . . . . . . . . . .2. . . Uma Avaliação Preliminar 4. . . . . . . . . . .1 Analisando o Modelo de Features . . . . . . . . . . . . . . . . .2 GREat Tour . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Descrevendo Serviços e Variabilidades 4. . . . . . . . . . . . . . .2. . . . . . . . . . . 48 48 50 50 51 52 53 54 56 58 62 65 65 67 68 70 Conclusão 5. . . . . . . . . . . . .2. . . . . . . . . . .4 Modularizando Serviços . . . . . . . . . . . . . . . . . . . . . . .3 Analisando os Artefatos . . . . . . . . . . 4. . . . . . . . . . 4. . . . . . . . .3 Descritor de WSDL . . . LoginService . . . . . . . . . . . . . .

Niebuhr et al. 2010. sendo capazes de adaptar-se em tempo de execução de acordo com mudanças no ambiente. mas nós insistimos em complicá-la. inclusive em tempo de execução (Kim et al. 2011). 2011) e consiste na seleção de features que irão compor o produto. 2009). 1 . remoção das features que não farão parte do produto e ligação dos pontos de variação (Alferez and Pelechano. no domínio de sistemas adaptativos. Em uma LPS tradicional. decisões sobre quais são as features que irão compor o produto podem estar ligadas a algum atributo ou característica do ambiente... No entanto. 2005. Hallsteinsen et al. que ocorre na fase de design ou de implementação (Rosenmüller et al. requerendo que a LPS seja dinâmica. exigindo sistemas mais flexíveis.. —CONFUCIUS 1. Quando técnicas de Linha de Produto de Software (LPS) são aplicadas no desenvolvimento de sistemas adaptativos. tais decisões podem resultar na configuração de um novo produto.. Oreizy et al.1 Motivação É notório o surgimento de ambientes cada vez mais dinâmicos. 2005.. de modo que tais decisões possam ser adiadas da fase de desenvolvimento para a fase de execução (Galster. obedecendo um conjunto de regras (Hallsteinsen et al. Life is really simple.1 Introdução A vida é simples. Para atender estes requisitos. but we insist on making it complicated.. Kim et al. de forma que componentes possam ser plugados ou desplugados durante o seu ciclo de vida.. 1999). 2006. é necessário que decisões sobre possíveis adaptações e variações do sistema possam ser tomadas em tempo de execução. um produto é derivado de acordo com sua configuração. Sistemas Sensíveis ao Contexto (SSCs) atendem a esse propósito.

Smith and Lewis.1. provendo uma estrutura dinâmica e desacoplada. 2012). 2007.. Este modelo de arquitetura possui características dinâmicas e flexíveis que podem ajudar a obter uma gerência de variabilidades mais otimizada (Galster. Trujillo and Kaestner. Este tipo de tecnologia é utilizado para o desenvolvimento de software como serviço. 2005. têm investigado sobre a utilização de abordagens de LPS no desenvolvimento de sistemas adaptativos. necessitam passar por adaptações para atender a diferentes requisitos (Lee et al. 2007). Linhas de Produto de Software Dinâmicas (LPSDs) (Hallsteinsen et al. 2010).. unindo práticas de orientação a serviços a LPS. Tecnologias orientadas a serviços possuem características que são requeridas por muitas LPS (Yu et al. 2008) estendem o conceito convencional de Linhas de Produto de Software abordando aspectos dinâmicos e provendo uma abordagem para tratar variabilidades que precisam ser manipuladas em tempo de execução (Bencomo et al. 2007. Portanto.. resultando em componentes com baixo acoplamento e interoperabilidade entre linguagens e plataformas (Demirkan et al.. é possível perceber benefícios como o suporte contínuo a mudanças no contexto e a possibilidade de combinar serviços em várias configurações. 2010.. 2008). Com isso. 2007. dinâmicos e 1 associação de uma variante a um ponto de variação de uma variante a um ponto de variação 2 dissociação 2 . MOTIVAÇÃO 2008).. 2010). Kim et al.1. 2008). é introduzido o conceito de variabilidade dinâmica.. diversas pesquisas (Dhungana et al. para construir aplicações customizadas. LPSOS representa uma categoria de LPSD. simplificando a implantação de pontos de variação que. possibilitando que o produto derivado de uma LPS seja reconfigurado em tempo de execução (Bencomo et al. 2008). de modo que possibilite obter mais flexibilidade e maior poder de adaptação a novos cenários (Ye et al. que é desenvolvida seguindo uma arquitetura orientada a serviços e. 2007) têm investigado o uso do modelo de Arquitetura Orientada a Serviços (AOS) para este propósito. LPSDs efetuam bind1 e unbind2 de pontos de variação em tempo de execução. de diferentes áreas.. 2006. Wolfinger et al. 2010)... 2012).. surge o conceito de Linha de Produto de Software Orientado a Serviços (LPSOS) (Krut and Cohen.. Com isso. é importante a existência de técnicas de engenharia de software que apoie o desenvolvimento de sistemas com baixo acoplamento. Com o objetivo de construir artefatos de software cada vez mais reutilizáveis. diversas abordagens (Galster. Neste contexto. de acordo com um segmento específico de mercado. por exemplo. 2009. do ponto de vista da Engenharia de Linha de Produto de Software (ELPS). Hallsteinsen et al. embora utilizem a mesma base de serviços. Raatikainen and Mannisto. Segura et al.

podemos ter um cenário em que as features que compõem o produto no lado cliente podem endereçar uma composição de serviços. apesar de algumas dessas abordagens proverem mecanismos que permitem o reuso de artefatos. ao ocorrer uma ativação ou 3 . Marinho et al.2. Rocha et al. estando em fases iniciais de pesquisa. podemos enfrentar alguns desafios. que está em execução no lado servidor. Viana and Andrade. As abordagens propostas atualmente não oferecem um suporte para esse tipo de problema ou são incipiente. Em contrapartida. Portanto. de modo que features da aplicação cliente sejam ativadas ou desativadas. 2008). 2007. 2009).. propõem abordagens sistemáticas para desenvolvimento desse tipo de sistema.. Considerando que o modelo de AOS segue o padrão arquitetural Cliente-Servidor (Erl. Diversas soluções para desenvolvimento de sistemas sensíveis ao contexto foram propostas (Kon et al. De acordo com (Pohl et al. 2000. O sistema derivado de uma LPS é composto por features e pontos de variação. 2007). PROBLEMÁTICA flexíveis (Ali and Babar. 1. o produto pode ser composto por features que. elas não são aplicadas de forma sistemática durante as fases de desenvolvimento de software Marinho et al. para entrar em execução. No entanto. os pontos de variação podem sofrer variabilidades de acordo com mudanças no contexto. é possível perceber a necessidade de um framework que permita a reconfiguração de tais variabilidades. Quando alinhamos paradigmas como Sistemas Sensíveis ao Contexto. Se considerarmos serviços como parte de uma feature. Tais decisões influenciam diretamente nos artefatos de software que compõem o produto. no cenário de Linha de Produto de Software Orientado a Serviços e Sensível ao Contexto.2 Problemática O principal desafio quando utilizamos técnicas de LPS no desenvolvimento de SSCs é a necessidade de adiar decisões que ocorreriam na fase de design ou de implementação para a fase de execução (runtime). Dessa forma. precisam utilizar um serviço ou uma composição deles.. e Parra et al. AOS e LPS. um produto derivado de uma LPS é composto por características (features) comuns e variáveis (variabilities). exigindo a execução de reconfigurações nos serviços de modo a atender tais variabilidades.1. Desse modo. onde o primeiro autor utiliza técnicas de LPS e o segundo autor combina técnicas de LPS e AOS. 2005).. efetuando reconfigurações dinâmicas em Linhas de Produto de Software Orientado a Serviços e Sensível ao Contexto.

1. de forma fixa. 2007).. De acordo com (Erl. é necessário que o framework seja capaz de (i) receber notificações sobre mudanças na composição de features da aplicação cliente.. de modo que a adaptação das features e mudança no contexto seja atendida (Alferez and Pelechano. é necessário um (iii) mecanismo de descoberta de serviços. Como resultado deste estudo é 4 . mas para um serviço que atenda a uma determinada especificação. 1999). 2011). e em tempo de execução. que insira uma camada de abstração entre o cliente. nas quais suas respostas definem a abordagem a ser investigada no trabalho. obedecendo um conjunto de regras (Hallsteinsen et al. compondo uma plataforma de serviços dinâmica. Considerando que os serviços estarão em execução em uma plataforma com características dinâmicas. requerendo reconfigurações nos serviços. O mecanismo de descoberta de serviços deve ser responsável por selecionar com base em critérios de seleção o serviço mais adequado e retornar a sua referência (endpoint) para que possa ser acessado. no lado servidor. PROBLEMÁTICA desativação de uma ou mais features no sistema. tornando disponível ou indisponível um ou mais serviços. investigando especificamente situações quando features que endereçam um ou mais serviços são reconfiguradas no lado cliente. Com isso. visto que não devem existir requisições para um serviço específico. A abordagem utilizada neste trabalho é direcionada para responder a seguinte pergunta: • Como é possível permitir reconfigurações de variabilidades dinâmicas em Linhas de Produto de Software Orientado a Serviços e Sensível ao Contexto (LPSOSSCs)? Portanto. dinâmicos e se adaptam em tempo de execução de acordo com mudanças no ambiente. é necessário efetuar uma reconfiguração na composição dos serviços. SSCs são flexíveis. para que (ii) reconfigurações possam ser efetuadas no lado servidor. o servidor e o serviço requisitado. 2006. Quando mudanças ocorrem. espera-se que haja um menor acoplamento e maior flexibilidade. faz-se necessário um framework que seja responsável por tratar reconfigurações de tais variabilidades. Então. reconfigurações são executadas. Neste trabalho é apresentado um estudo sobre variabilidades dinâmicas em Linha de Produto de Software Orientado a Serviços e Sensível ao Contexto. O problema investigado pode ser expressado por meio de perguntas de pesquisa. como o cliente e o servidor são executados em ambientes diferentes. Oreizy et al. Dessa forma. Kim et al. o modelo de AOS segue o padrão arquitetural Cliente-Servidor.2.. como forma de obter uma resposta para esta pergunta de pesquisa. 2005.

a forma como o DYMOS está disposto em relação as demais tecnologias utilizadas. de uma forma desacoplada. Como 3 http://www. permitindo agregar critérios para a seleção do serviço mais adequado.apache. mantendo a mesma estrutura e arquitetura. O framework foi desenvolvido de forma modular utilizando tecnologias OSGi3 . que provê uma abstração entre o Cliente e o Serviço.. 2011). permitindo que o framework seja utilizado por aplicações desenvolvidas em outras plataformas.org/site/apache-felix-ipojo. permitindo que serviços sejam adicionados ou removidos da configuração do produto em tempo de execução por meio de mecanismos de auto-implantação.osgi. é obtida a característica de interoperabilidade. O DYMOS provê. que é um framework para desenvolvimento de componentes orientados a serviço para compor sistemas modulares que requerem adaptações em tempo de execução (Escoffier et al.1.3 Visão Geral da Solução De modo a permitir variabilidades dinâmicas em LPSOSSCs. Como forma de obter componentes modularizados. 1. foi proposto e desenvolvido o DYMOS Framework. “arquitetural” ou “reconfiguração de componentes”.org 4 http://felix. foi utilizado o iPOJO4 . de acordo com uma requisição. uma plataforma de reconfiguração de variabilidades dinâmicas e descoberta de serviços para Linhas de Produto de Software Orientado a Serviços e Sensível ao Contexto. O tipo de reconfiguração executada pelo DYMOS se trata de reconfiguração de componentes. VISÃO GERAL DA SOLUÇÃO provido um framework para suporte a reconfiguração e descoberta de serviços. O DYMOS oferece algumas vantagens como: possibilidade de Gerência de variabilidades de uma forma leve e simples. é possível classificar uma reconfiguração em tempo de execução como “comportamental”. Mecanismo de Descoberta de Serviço. De acordo com (Gomaa and Hashimoto. de modo que o funcionamento do sistema não seja afetado e que tais modificações sejam aplicadas e reconhecidas imediatamente. Uma adaptação de componentes envolve uma substituição de um componente por outro que implemente a mesma interface. 2007).1. É apresentado por meio da da Figura 1. As principais funcionalidades do DYMOS estão dispostas na forma de serviços web e.3. Uma adaptação arquitetural ocorre quando a arquitetura do sistema é impactada diretamente pela adaptação.html 5 . Uma adaptação comportamental ocorre quando o comportamento do sistema é alterado. por meio destes.

A reconfiguração é feita em termos de ativação ou desativação de um ou mais serviços. tornando-os disponíveis ou indisponíveis para utilização.1 DYMOS: Arquitetura Externa Com o objetivo de abordar os itens i.apache. tais regras devem ser utilizadas a fim de selecionar o serviço adequado. que é uma implementação do OSGi Service Platform. implementações e regras que são aplicadas quando a operação de descoberta de serviço é solicitada. Mecanismo de Reconfiguração de Serviços é responsável por reconfigurar os serviços para atender a mudanças no ambiente. mencionado na Seção 1.apache. VISÃO GERAL DA SOLUÇÃO plataforma de execução.apache. os seguintes itens foram desenvolvidos em forma de componentes como parte da solução: Descritor de Serviços permite descrever serviços. é utilizado o framework Apache Felix5 . Este componente atende ao item ii. especificações. indicando um ID (identificador). 5 http://felix.1. A descrição consiste na atribuição de um ID e um mapeamento entre pontos de variação e um ou mais serviços. Quando há uma requisição. é utilizado o OSGi Distribuído6 .org 6 . ii e iii destacados na Seção 1.org/distributed-osgi.org/ 6 http://cxf. Descritor de Variabilidades permite descrever variabilidades. que é um subprojeto do Apache CXF7 . indicando pontos de variação.html 7 http://cxf.2. Figura 1. Para expor funcionalidades por meio de serviços web.2.3.

serviços podem ser inseridos ou removidos a qualquer momento. Com isso. Este mecanismo deve selecionar o serviço mais adequado. As operações de reconfiguração e descoberta de serviços que são providas respectivamente pelo “Mecanismo de Reconfiguração de Serviços” e “Mecanismo de Descoberta de Serviços”. que deverá ser utilizada para especificar cada um dos itens. alguns pontos não são diretamente endereçados por este trabalho: Agente Para que um sistema possa adaptar-se. Assim. atendendo ao item i. Nossa solução oferece um conjunto de mecanismos que são responsáveis por receber notificações sobre adaptações. estão disponíveis por meio de Serviços Web.1. Este trabalho pode ser visto como um passo inicial de uma pesquisa sobre Reconfiguração Dinâmica de Variabilidades em Linhas de Produto de Software Orientado a Serviços e Sensível ao Contexto (LPSOSSCs). De modo a permitir os Descritores de Serviços e de Variabilidades.2 Uma descrição mais detalhada sobre a solução proposta é apresentada no Capítulo 3. em seguida.4. 1. Essas operações possibilitam a recuperação de referências (endpoint) de acesso a serviços. de acordo com o ID informado e. O Serviço Web referente operações de reconfiguração permite que o framework seja notificado sobre mudanças no contexto. Os itens “Descritor de Serviços” e “Descritor de Variabilidades” são utilizados pelos mecanismos de Reconfiguração e Descoberta de Serviços. foi definida e disponibilizada uma sintaxe baseada em XML. é preciso que algum componente notifique sobre uma possível mudança no contexto. deve ser retornado o endpoint do serviço para que possa ser utilizado pelo cliente. mencionado na Seção 1. sem haver a necessidade de alteração de código no cliente ou no servidor. de modo que as operações de reconfiguração e descoberta de serviços sejam efetuadas de acordo com cada uma das descrições. que são responsáveis por observar o contexto e informar sobre tais mudanças. ESCOPO NEGATIVO Mecanismo de Descoberta de Serviços é responsável por prover operações de descoberta de serviços.4 Escopo Negativo Alguns aspectos que são relacionados a esta pesquisa não são considerados como parte do escopo deste trabalho. 7 . informando o ID atribuído na descrição do serviço. Isso torna necessário a implementação de agentes.

a função de cada componente da solução e como estes componentes permitiram atender os requisitos. No entanto. Principais Contribuições e Trabalhos Futuros. No Capítulo 4 é apresentada uma avaliação preliminar da abordagem proposta por meio de um estudo de caso. de modo a efetuar uma contextualização sobre as principais áreas abordadas neste trabalho.5 Organização da Dissertação A estrutuda dessa dissertação está organizada da seguinte forma: No Capítulo 2 é apresentada uma revisão da literatura. ORGANIZAÇÃO DA DISSERTAÇÃO Interpretação de Regras de Contexto Para determinar quais são os componentes que serão adaptados. 8 . algumas regras definidas previamente devem ser consideradas. indicando quais os pontos de variação serão afetados. No Capítulo 3 é apresentada em detalhes a solução proposta neste trabalho. destacando os requisitos elencados. quando ocorre uma notificação de mudança no contexto.5. No Capítulo 5 são apresentadas as Considerações Finais.1. a aplicação cliente deve ser responsável por analisar tais regras e notificar a nossa solução. 1.

1 Linhas de Produto de Software: Uma visão geral A ELPS tem seus princípios inspirados em fábricas de automóveis. —CONFUCIUS 2. 9 . Este grupo de sistemas são desenvolvidos com base em um conjunto de core assets. O objetivo da ELPS é explorar partes comuns em um conjunto de sistemas. enquanto gerencia as partes variáveis. Estas fábricas utilizam uma plataforma comum para derivar os produtos que podem ser customizados de acordo com as necessidades de um segmento de mercado (Clements and Northrop. 2001). que são documentos. Uma linha de produto pode ser definida como um grupo de sistemas de software que compartilham um conjunto de características em comum e que satisfazem as necessidades específicas de um segmento de mercado. componentes e outros artefatos de software que possam ser reutilizados durante o desenvolvimento de cada sistema de software que compõe a linha de produto (Clements and Northrop. permitindo o desenvolvimento de uma família de sistemas de uma forma rápida e com baixo custo quando comparado ao desenvolvimento de um sistema separadamente (Gomaa. especificações.2 Revisão da Literatura O silêncio é um amigo verdadeiro que nunca trai. 2001).1 uma comparação entre o custo de produção de um único produto e o custo de produção de vários produtos. que possuiam produtos com um custo mais interessante quando produzidos em massa do que quando produzidos de forma individual. É demonstrado por meio da Figura 2. 2004). Silence is a true friend who never betrays.

o custo de cada sistema desenvolvido diminui e o custo acumulado da produção cresce mais lentamente quando comparado ao custo de desenvolvimento de sistemas individuais. o custo de desenvolvimento e tempo de entrega de produtos individuais são reduzidos consideravelmente. 2005). é exigido um investimento inicial e um longo período de tempo para desenvolver os core assets que serão reutilizados durante o desenvolvimento de cada produto. 10 . LINHAS DE PRODUTO DE SOFTWARE: UMA VISÃO GERAL Figura 2. 2007) Observando a Figura 2. de acordo com (Pohl et al.1. o custo do desenvolvimento de uma pequena quantidade de sistemas utilizando ELPS é relativamente alto e.2.1. estes benefícios consistem em: • Uma vez que muitos produtos são desenvolvidos com base em um conjunto de core assets comuns. a linha sólida representa o custo de desenvolvimento de sistemas de forma independente.1 Motivação Existem diversas razões para desenvolver uma família de produtos utilizando o paradigma de ELPS.1 Custos do desenvolvimento de uma Linha de Produto. No entanto. a medida que a aumenta-se a quantidade de sistema desenvolvidos.. enquanto a linha pontilhada representa o custo de desenvolvimento de sistemas utilizando ELPS. 2.. Como é possível perceber. Este paradigma proporciona muitos benefícios e.1. Adaptado de (Linden et al.

os produtos são customizados de acordo com as necessidades do cliente ou de um segmento específico de mercado. Dessa forma. que de acordo com (Pohl et al. identificando e definindo as partes comuns e variáveis da linha de produto. proporcionando um aumento na satisfação do cliente. Então. A partir da etapa de configuração do produto. 2007). pois diferentes produtos são desenvolvidos a partir da plataforma da LPS em conjunto com uma seleção de variabilidades. 11 . LINHAS DE PRODUTO DE SOFTWARE: UMA VISÃO GERAL • Os core assets de uma plataforma de LPS são reutilizados em muitos produtos. No entanto. 2.2 Engenharia de Linha de Produto de Software As atividades da Engenharia de Linha de Produto de Software (ELPS) são divididas em duas fases principais. • Quando os artefatos da plataforma da LPS são modificados ou novos artefatos são adicionados.1. podemos citar como um ponto de variação o tipo de acesso do sistema e. aumentando a qualidade do produto. como exemplo de variação. os core assets são revisados. em diferentes cenários. Variabilidades representam diferenças entre os produtos de uma LPS. os produtos entregues atendem a necessidades e requisitos individuais com um baixo custo e alta qualidade. 2005). Na próxima seção será detalhado o processo de desenvolvimento e as atividades da ELPS. e é por meio do gerenciamento de variabilidades que diversos produtos são construídos a partir de um conjunto de artefatos reutilizáveis. é possível efetuar a ligação entre pontos de variação (variation point) e variações (variant).1. Para ilustrar um exemplo. Isto torna mais fácil encontrar e corrigir possíveis problemas. o gerenciamento das variabilidades é essencial para o sucesso de uma linha de produto (Pohl et al. testados e reutilizados muitas vezes... Isto torna a manutenção e evolução mais simples e com custo mais baixo do que tratar cada produto de forma separada. etc. podemos citar autenticação por usuário e senha. Engenharia de Domínio é a fase onde é estabelecida uma plataforma reutilizável e customizável. apesar de proporcionar estes benefícios. • Em uma LPS. biometria. 2005) e (Linden et al. consistem na Engenharia de Domínio e Engenharia de Aplicação. as mudanças são refletidas para todos os produtos derivados desta LPS.. reconhecimento facial.2.

(ii) derivação do produto. Desenvolvimento de core assets esta atividade é equivalente à Engenharia de Domínio. (Clements and Northrop.2: Figura 2. “Desenvolvimento do Produto” e “Gerenciamento”.1.2.2 Atividades Essenciais na Engenharia de Linha de Produto de Software. Neste sentido. as fases consistem no “Desenvolvimento de core assets”. 2001) define três importantes atividades para a ELPS. 2005). que consiste na construção de combinações válidas de variabilidades identificadas no processo de engenharia de domínio. 2001) Conforme é possível observar na Figura 2. O processo de engenharia de aplicação é composto por atividades para (i) configuração do produto.. Adaptado de (Clements and Northrop. Nesta etapa são produzidos um conjunto de core assets.2. um plano de produção e é 12 . conforme apresentado na Figura 2. é necessário utilizar um tipo de processo que considere o reuso de artefatos nas fases de Engenharia de Domínio e Aplicação. LINHAS DE PRODUTO DE SOFTWARE: UMA VISÃO GERAL Engenharia de Aplicação é a fase em que os produtos são construídos por meio da reutilização dos core assets da plataforma e seleção de variabilidades para permitir customizações do produto. que consiste no processo concreto de construção de uma aplicação da LPS (Pohl et al.

requisitos e abordagens para a realização dos core assets. projetadas e implementadas de forma incremental. Desenvolvimento do Produto esta atividade é equivalente à Engenharia de Aplicação. principalmente por razões econômicas... projetadas e. é exigido um esforço por parte da organização interessada. Este modelo é ideal para organizações que têm o domínio completo sobre os requisitos da linha de produto e que possuem tempo e recursos disponíveis para um longo período de desenvolvimento. que pode utilizar alguns modelos de adoção de acordo com seus objetivos. reduzindo consideravelmente os custos de desenvolvimento e tempo de entrega dos produtos (Linden et al. Reativa e Extrativa: Pro-ativa este modelo de adoção é equivalente ao modelo cascata no desenvolvimento convencional de software. 2005). 2007). Para a adoção bem sucedida do paradigma de LPS. De acordo com (Krueger. 2001). onde todas as variações do produto são analisadas.1.3 Modelos de Adoção de Linhas de Produto de Software Muitas organizações são motivadas a adotar o paradigma de LPS. o gerenciamento em um nível técnico e organizacional possui ligação com todo o processo da engenharia da linha de produto. por fim. Recebe como entrada os core assets produzidos na fase anterior e os requisitos para a produção de um produto específico. as variações do produto são analisadas. tempo e orçamento disponível para investimentos. implementadas. requisitos. LINHAS DE PRODUTO DE SOFTWARE: UMA VISÃO GERAL definido o escopo da linha de produto. 2002). Serão apresentadas na próxima seção algumas abordagens utilizadas na adoção do paradigma de LPS. influenciando diretamente no seu sucesso. De acordo com (Pohl et al. pois utilizando as abordagens de LPS é possível obter a reutilização de artefatos em larga escala durante o desenvolvimento de software. Reativa neste modelo.2. permitindo que o escopo da LPS evolua de acordo 13 . 2. os modelos de adoção consistem nas abordagens Pro-ativa. Gerenciamento esta atividade é importante devido a existência de interação entre as etapas de “Desenvolvimento de core assets” e “Desenvolvimento do Produto” (Clements and Northrop.1. padrões. É recebido como entrada os pontos comuns e variáveis dos produtos.

2. a fim de identificar as semelhanças e variações entre os produtos. e um domínio estável de negócio (Pohl et al. um produto é derivado de acordo com sua configuração. adequações no processo de desenvolvimento e possivelmente modificações na estrutura organizacional da empresa (Linden et al. reduzir riscos e permitir uma adoção rápida. 2005. A abordagem pro-ativa possui mais riscos pois o ciclo de desenvolvimento é longo e requer um investimento inicial considerado alto. Cada um dos modelos de adoção está associado a um conjunto de riscos e benefícios.1. processos bem definidos. o retorno de investimento é alto quando comparado com os retornos de investimento das abordagens reativa e extrativa (Alves et al.. tais decisões podem resultar na configuração de um novo produto. saindo do modelo convencional para o modelo de desenvolvimento de linhas de produto. Este modelo é ideal para organizações que não conseguem prever os requisitos da linha de produto e que não têm a possibilidade de interromper o desenvolvimento da linha de produto ou estender o tempo durante o processo de adoção. para que a escolha de um modelo de adoção que possa atender da melhor forma as expectativas da organização. A adoção do paradigma de LPS requer um investimento inicial. Clements and Northrop. é necessário que haja uma análise de alguns fatores relativos a própria organização como objetivos.1. Este modelo é ideal para organizações que pretendem migrar o seu modelo de desenvolvimento de software. No entanto. Além disso.. que ocorre na fase de design ou de implementação (Rosenmüller et al. LINHAS DE PRODUTO DE SOFTWARE: UMA VISÃO GERAL com a demanda por novos produtos ou novos requisitos em produtos já existentes. Em contrapartida. Extrativa a construção da LPS é feita a partir da extração de características comuns e variáveis de um conjunto de sistemas de software previamente desenvolvidos. 2011) e consiste na seleção de features que irão compor o produto.4 Linhas de Produto de Software Dinâmicas Quando técnicas de Linha de Produto de Software (LPS) são aplicadas no desenvolvimento de sistemas adaptativos. pessoas que conhecem as necessidades do mercado. 2002). Em uma LPS tradicional.. é possível citar alguns pré-requisitos para a adoção deste paradigma como utilizar uma tecnologia que permita implementar os conceitos de linhas de produto. Neste sentido. pois nem sempre é possível diminuir ou parar a produção de software durante a transição (Krueger. remoção das features que não 14 . 2005). 2001).. 2. estas abordagens podem eliminar as barreiras encontradas no processo de adoção. 2007). tempo e recursos disponíveis.

LPSD é um termo relativamente novo e diversas pesquisas estão em evolução. No entanto. COMPUTAÇÃO ORIENTADA A SERVIÇOS: UMA VISÃO GERAL farão parte do produto e ligação dos pontos de variação (Alferez and Pelechano.. será feita uma discussão sobre as vantagens apresentadas por nossa proposta. Kim et al. Alguns estudos (Raatikainen and Mannisto..2. 2010). 2012). de diferentes áreas. 2005.. que possuem suas funcionalidades expostas como serviços para serem utilizadas por outras aplicações ou serviços. 2008) estendem o conceito convencional de Linhas de Produto de Software abordando aspectos dinâmicos. requerendo que a LPS seja dinâmica. O autor apresenta um novo conceito que utiliza abordagens de LPS para construir sistemas que podem ser adaptados em tempo de execução. Trujillo and Kaestner. O termo “Linhas de Produto de Software Dinâmicas” (em inglês.. Este tipo de aplicação geralmente possui uma arquitetura orientada a serviços (em inglês. 2008).2.. por fim. 2007. Na Seção 2. decisões sobre quais são as features que irão compor o produto podem estar ligadas a algum atributo ou característica do ambiente. 2010. 2007.. 2011). LPSDs efetuam bind e unbind de pontos de variação em tempo de execução. Linhas de Produto de Software Dinâmicas (LPSDs) (Hallsteinsen et al. Nesse contexto.3 serão apresentados os principais trabalhos relacionados à nossa abordagem e. de acordo com requisitos do usuário e mudanças no ambiente.. Segura et al. diversas pesquisas (Dhungana et al. Hallsteinsen et al. 2008). Service-Oriented Architecture.2 Computação Orientada a Serviços: Uma visão geral O desenvolvimento de software orientado a serviços apresenta uma abordagem para construção de aplicações distribuídas... no domínio de sistemas adaptativos. Hallsteinsen et al. provendo uma abordagem para tratar variabilidades que precisam ser manipuladas em tempo de execução (Bencomo et al. é introduzido o conceito de variabilidade dinâmica. Wolfinger et al. 2008). possibilitando que o produto derivado de uma LPS seja reconfigurado em tempo de execução (Bencomo et al. 2007. têm investigado sobre Linhas de Produto de Software Dinâmicas (LPSDs). 2. uma vez que seus artefatos podem ser decompostos em unidades lógicas distintas como serviços e componentes.. ou DSPL) foi introduzido em 2008 por (Hallsteinsen et al. ou SOA) e permite o reuso de software. que consiste na utilização de abordagens de LPS no desenvolvomento de sistemas adaptativos. 2006. Dynamic Software Product Lines. 2007) têm investigado e discutido a possibilidade de utilizar o modelo de arquitetura 15 . Com isso. de modo que tais decisões possam ser adiadas da fase de desenvolvimento para a fase execução (Galster.

permitindo a composição de aplicações distribuídas de forma rápida e com baixo custo. e muitas empresas têm falhado neste processo. e autocontidos. De acordo com (Raatikainen and Mannisto. utilizando serviços como elementos fundamentais (Papazoglou and Georgakopoulos.2. o paradigma de computação orientada a serviços por meio de metodologias de desenvolvimento de software.1 Arquiteturas Orientadas a Serviços Nos últimos anos. a proposta deste paradigma é bastante atrativa para organizações que desejam obter mais efetividade em suas soluções (Erl. 2003). 2. 2007). Service-Oriented Computing. No entanto. a possibilidade de compor novos serviços reutilizando serviços já existentes provê algumas vantagens para a organização como Retorno de Investimento (em inglês. 16 . utiliza o modelo de Arquitetura Orientada a Serviços (AOS). agilidade e produtividade. ou SOC) é um paradigma cujo o objetivo é o desenvolvimento de aplicações integradas e implantadas em ambientes distribuídos. 2008). De modo a obter mais eficiência. metodologias para desenvolvimento de sistemas e arquiteturas têm evoluído. unindo abordagens de orientação a serviços a LPS. Com isso. diminuição de custos e tempo de entrega (Elfatatry and Layzell. 2004). de acordo com um segmento específico de mercado. 2003).2. COMPUTAÇÃO ORIENTADA A SERVIÇOS: UMA VISÃO GERAL orientada a serviços em conjunto com abordages de LPS. de forma que seja possível desenvê-los e implantá-los de forma independente. Return on Investiments. As principais razões para adotar o modelo de AOS são: • Reusabilidade: a reusabilidade é um dos principais objetivos da Engenharia de Software e. Computação Orientada a Serviços (COS) (em inglês. auto descritivos. ou ROI). Existem diversos motivos para adotar o modelo de AOS e produzir software utilizando o paradigma de desenvolvimento orientado a serviços. tais serviços devem ser independentes de plataforma.2. no contexto de AOS. Com este é estabelecido um modelo de arquitetura que provê uma infraestrutura entre serviços interconectados por meio de interfaces padronizadas (Papazoglou and Georgakopoulos. 2007). qualidade de software. partindo de um paradigma de desenvolvimento de aplicações monolíticas e centralizadas para um paradigma de aplicações distribuídas. surge o conceito de LPSOS (Krut and Cohen. para construir aplicações customizadas. Motivação A adoção do paradigma de computação orientada a serviços não é uma tarefa fácil.

O princípio do acoplamento também afeta outro atributos de qualidade como a modificabilidade e reusabilidade da aplicação (McGovern et al. regras e características dos serviços e suas funcionalidades. a arquitetura do sistema de software deve ser reconfigurável. 2005). • Integração e Interoperabilidade: serviços podem ser desenvolvidos de forma independente e então são compostos com outros serviços a fim de prover funcionalidades de uma aplicação que pode ser facilmente adaptada a novos requisitos e. 2004). permitindo a troca de mensagem entre estes (Erl. serviços heretogêneos são facilmente integrados. são utilizados formatos padronizados como XML. de uma forma simples. COMPUTAÇÃO ORIENTADA A SERVIÇOS: UMA VISÃO GERAL • Flexibilidade e Agilidade: constantemente os sistemas de software precisam passar por modificações para atender novos requisitos. Os princípios que são diretamente relacionados com este modelo de arquitura são: • Acoplamento: este princípio se refere ao número de dependências entre serviços. Para permitir estas definições. possibilitando responder rapidamente a possíveis mudanças nos requisitos (Endrei et al. As características do modelo de AOS permitem um melhor alinhamento entre o sistemas de software e as necessidades de mercado por meio da integração de novos serviços e reuso de serviços existentes.2. o modelo de arquitetura orientada a serviços é definido com base em um conjunto de princípios que apoiam suas características. 2011). 17 . O baixo acoplamento é obtido por meio do uso de padrões e contratos de serviços entre clientes e provedores. Por isso. O modelo de arquitetura orientada a serviços normalmente é definido com base em um conjunto de princípios (Erl. WSDL e XSD (Erl. por meio da interoperabilidade. Serão apresentados na próxima seção os princípios que são diretamente relacionados com este modelo de arquitetura. Zi-yun and Ru-long. Neste contrato são definidos formato de dados.. • Contrato de Serviço: serviços aderem a contratos de comunicação. que permitem a interação dos serviços utilizando interfaces bem definidas. Dirksen.. 2005.2. Princípios e Papéis Conforme mencionado anteriormente. 2005. 2007). definidos por um ou mais serviços. que são requeridos por novas exigências de mercado (Carter. 2003). 2013).

• Alta Granularidade: serviços provêem abstrações que suportam a separação de interesses de domínio (separation of concerns) e visibilidade de informação (information hidding). 2003). Provedor de Serviço (Service Provider). os papéis consistem em: Cliente (Service Consumer). Adaptado de (Papazoglou and Georgakopoulos. • Descoberta de Serviços: serviços são especificados de uma forma descritiva para permitir a sua localização por meio de mecanismos de descoberta de serviços.3 Arquitetura Orientada a Serviços: Papéis e Operações. O modelo de arquitetura orientada a serviços não trata apenas aspectos sobre a definição de serviços.3. os relacionamentos entre os papéis elencados acima. 2005). 2007) e (Papazoglou and Georgakopoulos. a performance do serviço é comprometida e. COMPUTAÇÃO ORIENTADA A SERVIÇOS: UMA VISÃO GERAL • Autonomia e Abstração: os serviços devem ser autônomos e auto-contidos. De acordo com (Erl. Figura 2. 1 http://uddi. Também é possível observar nesta mesma figura. tendo o controle sobre a lógica que é encapsulada por eles e provendo uma abstração de suas funcionalidades por meio do seu contrato de serviço (Erl.2. mas também provê definições de papéis e suas responsabilidades. Discovery and Integration) (Erl. por esta razão. 2003) Conforme a Figura 2. os serviços devem prover funcionalidades de alta granularidade. Devido a existência de chamadas remotas. conforme apresentado na Figura 2. são definidos quatro papéis.3. como o UDDI1 (Universal Description. diminuindo a necessidade de várias chamadas remotas para resolver uma única requisição.2.org 18 .xml. Registro e Descoberta de Serviços (Service Registry) e o Contrato de Serviço (Service Contract). 2005) e o WS-Discovery (Microsoft Corporation. 2005).

2. de modo que possibilite obter mais flexibilidade e maior poder de adaptação a novos cenários (Ye et al. Isto implica ganhos em produtividade. um componente ou outra entidade de software que expõe sua interface como serviço (Josuttis. Medeiros. 2010. um serviço ou outra entidade de software que necessita acessar o serviço. As informações sobre provedores de serviços são publicadas no registro de serviços (McGovern et al.2. Esta entidade pode ser uma aplicação legada. 2003). 2003). 2007. 2010. que é a motivação por reutilização de artefatos em vez de desenvolvê-los do início. utilizando o registro de serviço (Josuttis. Smith and Lewis. 2007. 2007). redução de custos e tempo de entrega. • Contrato de Serviços: por meio do contrato de serviço é especificado a forma como o Cliente irá interagir com o Provedor do Serviço. McGovern et al. • Registro de Serviço: é entidade responsável por manter as informações sobre contratos de serviços e provedores. 2010).. 2009. Trujillo and Kaestner. 2005. • Provedor de Serviço: é a entidade que recebe e processa as requisições efetuadas pelo Cliente. 2007) têm investigado o uso do modelo de Arquitetura Orientada a Serviços (AOS) em conjunto com abordagens de LPS.. condições para acessar o Provedor do serviço e pode descrever atributos de qualidade (Erl. provendo uma implementação para um especificação ou contrato de serviço. provendo uma estrutura dinâmica e desacoplada. 2. Algumas abordagens propostas (Istoan et al. Este acesso pode ser possibilitado diretamente por meio do URI (Uniform Resource Identifier) ou por meio da descoberta de serviços. 2009. Esta entidade pode ser utilizada para implementação de atributos de qualidade de serviços como disponibilidade e modificabilidade (Garcia-Gonzalez et al. 2007). 2007). Este contrato especifica o formato das mensagens.. Ribeiro. COMPUTAÇÃO ORIENTADA A SERVIÇOS: UMA VISÃO GERAL • Cliente: pode ser uma aplicação.. 2010) que tratam questões relacionadas a Linhas de Produto Orientadas a Serviços..2. Com o objetivo de construir artefatos de software cada vez mais reutilizáveis.2 Linhas de Produto Orientadas a Serviços Os paradigmas de AOS e LPS possuem um objetivo em comum. Segura et al.. 2010). LPS explora características comuns e variáveis entre um conjunto de sistemas e o paradigma de AOS possui características que são requeridas por muitas LPSs (Yu et al.. Raatikainen and Mannisto. consideram 19 . diversas abordagens (Galster.

conforme apresentado na Figura 2.4. uma feature pode ser composta por um ou mais serviços e um conjunto de implementações que utilizam tais serviços para prover funcionalidades. Opcional ou Alternativo. respeitando restrições que determinam os serviços como Obrigatório.4 Linha de Produto Orientadas a Serviços: Configuração de Produtos Conforme apresentado na Figura 2. conforme a Figura 2. Figura 2. Na abordagem proposta neste trabalho. é considerado que os serviços são partes de uma feature. Ou seja. que pode compor a configuração do produto.4.5.2. COMPUTAÇÃO ORIENTADA A SERVIÇOS: UMA VISÃO GERAL unidades de serviços como features. 20 .2. cada unidade de serviço é considerada uma feature.

2009) propõe uma Linha de Produto Dinâmica. de acordo com as features adaptadas na aplicação Cliente. ou SCA) com propriedades dinâmicas que permite operações de bind e unbind de componentes em tempo de execução. Orientada a Serviço e Sensível ao Contexto denominada CAPucine. 2..5 Composição de features Com essa definição. O FraSCAti é uma plataforma de Arquitetura de Componentes Orientados a Serviço (em inglês. que é composto e transformado para gerar o produto.3.2. Estes trabalhos são descritos abaixo: (Parra et al. Esse alinhamento foi possibilitado por meio de reconfigurações na composição de serviços.ow2. No primeiro processo. Service Component Architecture. foi possível estabelecer um alinhamento entre as adaptações da aplicação Cliente e os serviços disponíveis no lado Servidor.3 Trabalhos Relacionados Durante o desenvolvimento deste trabalho foi possível identificar alguns trabalhos relacionados. todas as features selecionadas são associadas ao artefato que corresponde ao modelo parcial do produto.org/ 21 . Esta linha de produto possui uma abordagem orientada a modelos e é dividida em dois processos para a execução da derivação do produto. TRABALHOS RELACIONADOS Figura 2. 2 http://frascati. que são efetuadas utilizando o FraSCAti2 . O segundo processo é referente a adaptações dinâmicas.

onde são utilizados modelos de variabilidades como políticas de adaptação para gerar e executar de forma automática o plano de reconfiguração.. A primeira fase da abordagem consiste em especificar a arquitetura da linha de produto. onde features que compõem o produto no lado cliente podem endereçar uma composição de serviços. que devem seguir a arquitetura da linha de produto. No próximo capítulo (Capítulo 3) será apresentada a solução proposta neste trabalho. os reconfiguradores utilizados pelas abordagens atuais. Neste caso.. No trabalho proposto por (Alferez and Pelechano. detalhando como a solução trata as limitações descritas nesta seção. 2010) propõe uma abordagem que é dividida em três fases e une conceitos de LPS a COS para desenvolver composições dinâmicas de serviços.. Por fim. efetuando adaptações dinâmicas por meio da substituição de seus provedores. 2009) diz respeito a complexidade da abordagem. foi possível observar uma limitação que consiste em considerar um serviço como uma única feature. A segunda fase consiste em definir composições de serviços. A partir destes trabalhos foram identificadas algumas limitações na tentativa de aplicálos no cenário de LPSOSSC que seguem o modelo de AOS utilizando o padrão arquitetural Cliente-Servidor (Erl. mas também por outros artefatos que utilizam tais serviços para prover suas funcionalidades. apresentam um forte acoplamento com sua respectiva LPSD. A abordagem proposta é apoiada pelo (MoRE-WS).2. 22 . (Alferez and Pelechano. 2007). conforme colocado por (Silva et al. 2011) propõe uma abordagem para projetar e implementar Web Services Sensíveis ao Contexto em uma família de sistemas. TRABALHOS RELACIONADOS (Yu et al.. 2011). A terceira fase consiste em criar e manter de forma autônoma a aplicação construída com base na arquitetura da linha de produto. não são tratadas as features que são compostas não apenas por serviços. 2013). inclusive (Yu et al. que é uma plataforma de reconfiguração guiada por modelos. 2010). efetuando a sua integração com o modelo de variabilidades. Uma limitação encontrada no trabalho proposto por (Parra et al. que dificulta a sua utilização em sistemas de pequeno porte ou que estão na fase inicial da adoção do paradigma de LPS.3.

de acordo com uma requisição.3 DYMOS Framework Seja uma referência em qualidade. Mecanismo de Descoberta de Serviço. As principais funcionalidades do DYMOS estão dispostas na forma de serviços web e.1 Visão Geral da Solução O DYMOS provê. de modo que o funcionamento do sistema não seja afetado e que tais modificações sejam aplicadas e reconhecidas imediatamente. que provê uma abstração entre o Cliente e o Serviço. permitindo que o framework seja utilizado por aplicações desenvolvidas em outras plataformas. Be a yardstick of quality. De acordo com (Gomaa and Hashimoto. —STEVE JOBS 3. é obtida a característica de interoperabilidade. de uma forma desacoplada. 2011). O DYMOS oferece algumas vantagens como: possibilidade de Gerência de Variabilidades de uma forma leve e simples. Algumas pessoas não estão acostumadas com um ambiente em que a excelência é esperada. Uma adaptação comportamental ocorre quando o comportamento do 23 . permitindo que serviços sejam adicionados ou removidos da configuração do produto em tempo de execução por meio de mecanismos de auto-implantação. “arquitetural” ou “reconfiguração de componentes”. Some people aren’t used to an environment where excellence is expected. é possível classificar uma reconfiguração em tempo de execução como “comportamental”. permitindo agregar critérios para a seleção do serviço mais adequado. por meio destes. uma plataforma de reconfiguração de variabilidades dinâmicas e descoberta de serviços para Linhas de Produto de Software Orientado a Serviços e Sensível ao Contexto.

é necessário um (iii) mecanismo de descoberta de serviços.. o modelo de AOS segue o padrão arquitetural Cliente-Servidor. O tipo de reconfiguração executada pelo DYMOS se trata de reconfiguração de componentes. Para expor funcionalidades através de serviços web. é necessário que o DYMOS seja capaz de (i) receber notificações sobre mudanças no contexto. reconfigurações são executadas. de forma fixa. Como forma de obter componentes modularizados.1. compondo uma plataforma de serviços dinâmica. Na Seção 1. mantendo a mesma estrutura e arquitetura. tornando disponível ou indisponível um ou mais serviços. que insira uma camada de abstração entre o cliente. obedecendo um conjunto de regras (Hallsteinsen et al. a forma como o DYMOS está disposto em relação as demais tecnologias utilizadas.1. foi utilizado o OSGi Distribuído. O mecanismo de descoberta de serviços deve ser responsável por selecionar e prover uma referência (endpoint) para o serviço mais adequado. espera-se que haja um menor no acoplamento e maior flexibilidade. que é uma implementação do OSGi Service Platform. Como plataforma de execução. foi utilizado o framework Apache Felix. Uma adaptação arquitetural ocorre quando a arquitetura do sistema é impactada diretamente pela adaptação. para que (ii) reconfigurações possam ser efetuadas.. dinâmicos e se adaptam em tempo de execução de acordo com mudanças no ambiente. É apresentado por meio da Figura 1. faz-se necessário um framework que seja responsável por tratar reconfigurações de tais variabilidades. VISÃO GERAL DA SOLUÇÃO sistema é alterado. Então. SSCs são flexíveis. como o cliente e o servidor são executados em ambientes diferentes. com a finalidade de permitir variabilidades dinâmicas em Linhas de Produto de Software Orientado a Serviços e Sensível ao Contexto (LPSOSSCs). 2007). Com isso. visto que não devem existir requisições para um serviço específico. 1999).2 foi apresentada a problemática tratada na abordagem proposta neste 24 . o servidor e o serviço requisitado. Kim et al. 2005. que é um framework para desenvolvimento de componentes orientados a serviço para sistemas dinamicamente adaptáveis (Escoffier et al.3.. O DYMOS foi desenvolvido de forma modular utilizando tecnologias OSGi. foi utilizado o iPOJO. Quando mudanças ocorrem. 2006.. mas para um serviço que atenda a uma determinada especificação. Uma adaptação de componentes envolve uma substituição de um componente por outro que implemente a mesma interface. Dessa forma. Considerando que os serviços estarão em execução em uma plataforma com características dinâmicas. De acordo com (Erl. 2007). Oreizy et al. que é um subprojeto do Apache CXF.

serviços podem ser inseridos ou removidos a qualquer momento. Mecanismo de Descoberta de Serviços é responsável por prover operações de descoberta de serviços. reconfiguração de variabilidades e descoberta de serviços. Essas operações possibilitam a recuperação de referências (endpoint) de acesso a serviços. informando o ID atribuído na descrição do serviço. foi definida e disponibilizada uma sintaxe baseada em XML. sem haver a necessidade de alteração de código no cliente ou no servidor. de acordo com o ID informado e. especificações. Com isso.2. respectivamente. Este componente atende ao item iii. VISÃO GERAL DA SOLUÇÃO trabalho e foram elencados os itens i. Este componente atende ao item ii. As operações de reconfiguração e descoberta de serviços que são providas respectivamente pelo “Mecanismo de Reconfiguração de Serviços” e “Mecanismo de Desco- 25 . tais regras devem ser utilizadas a fim de selecionar o serviço adequado. Quando há uma requisição. de modo que as operações de reconfiguração e descoberta de serviços sejam efetuadas de acordo com cada uma das descrições. A reconfiguração é feita em termos de ativação ou desativação de um ou mais serviços.1. indicando pontos de variação. indicando um ID (identificador). De modo a permitir os Descritores de Serviços e de Variabilidades. Descritor de Variabilidades permite descrever variabilidades.2. os seguintes artefatos foram desenvolvidos em forma de componentes como parte da solução: Descritor de Serviços permite descrever serviços. endereçam as funcionalidades de recebimento de notificações sobre mudanças no contexto. em seguida. mencionado na Seção 1. Com o objetivo de abordar estes itens. ii e iii que. A descrição consiste na atribuição de um ID e um mapeamento entre pontos de variação e um ou mais serviços. mencionado na Seção 1. deve ser retornado o endpoint do serviço para que possa ser utilizado pelo cliente. Mecanismo de Reconfiguração de Serviços é responsável por reconfigurar os serviços para atender a mudanças no ambiente.3. implementações e regras que são aplicadas quando a operação de descoberta de serviço é solicitada. obedecendo um meta-modelo. tornando-os disponíveis ou indisponíveis para utilização. Os itens “Descritor de Serviços” e “Descritor de Variabilidades” são utilizados pelos mecanismos de Reconfiguração e Descoberta de Serviços. Este mecanismo deve selecionar o serviço mais adequado. Esta sintaxe deverá ser utilizada para especificar cada um dos itens.

permite que o framework seja notificado sobre mudanças no contexto.2 e o objetivo proposto neste trabalho. variabilidades e mapeamento entre estes. mencionado na Seção 1. Elicitação de Requisitos é o processo identificação das necessidades de um determinado domínio de negócio. Este processo é executado com o apoio de usuários. 3. Analisando a problemática descrita na Seção 1.2 Elicitação de Requisitos Nesta seção serão apresentados os requisitos elicitados para o desenvolvimento do DYMOS Framework. RF2 A aplicação cliente é composta por features que podem ser ativadas ou desativadas de acordo com mudanças no ambiente. atendendo ao item i. Nas próximas seções deste capítulo serão apresentados mais detalhes sobre a solução proposta neste trabalho.3. 2011). RF3 É necessário o desenvolvimento de um mecanismo capaz de tratar a notificações sobre mudanças na composição das features. É por meio de RFs que as funcionalidades são elencadas.2. O serviço web referente a operações de reconfiguração. foi possível elicitar os Requisitos Funcionais (RFs) e Requisitos Não-Funcionais (RNFs) do framework proposto. ELICITAÇÃO DE REQUISITOS berta de Serviços”. Os requisitos de um sistema são categorizados como Requisitos Funcionais (RFs) ou Requisitos Não-Funcionais (RNFs).. RF4 O DYMOS deve ser capaz de efetuar reconfigurações na plataforma de serviços de acordo com as variabilidades identificadas no RF3. Dessa forma. identificando as variabilidades que serão afetadas.. descrevendo as operações que o sistema deve prover.2. 2012). Os requisitos estão detalhados abaixo: RF1 É necessário prover uma forma de descrever serviços. Os RNFs elencam restrições de qualidade que são atribuídas aos RFs (Ullah et al. clientes e stakeholders1 (Tiwari et al. 1 Pessoa ou Entidade interessada no projeto 26 . o DYMOS deve prover um mecanismo que possibilite receber notificações sobre mudanças na composição das features na aplicação cliente. estão disponíveis através de serviços web.

Os descritores devem ser tratados como meta-dados e convertidos em objetos. e acordo com este. RNF2 O RF2 deve estar disponível por meio de serviços web. a forma como o DYMOS está disposto em relação às demais tecnologias utilizadas.. OSGi O framework OSGi define um conjunto de especificações que permitem o desenvolvimento de modulares em Java. seja retornada uma referência para o serviço mais adequado. 2011). Nesta seção é apresentada uma breve descrição sobre cada uma das delas. Hall et al. TECNOLOGIAS UTILIZADAS RF5 O DYMOS deve prover um mecanismo para descoberta de serviços. encerrados. que devem ser utilizados em caso de indisponibilidade do serviço principal. 2011.3. inicializados. RNF1 O RF1 deve ser contemplado por meio de uma linguagem baseada em XML. de modo que variabilidades possam ser incluídas ou excluídas sem a necessidade de interromper a execução do DYMOS. atualizados e desinstalados sem a necessidade de reiniciar a aplicação (de Castro Alves.1. 3. RF9 A seleção do serviço adequado deve acontecer de acordo com uma prioridade. RF7 Para possibilitar a descoberta de serviços.3. de modo que quando houver uma requisição por um determinado serviço. o mecanismo deve receber o ID atribuído ao serviço no descritor e. RF8 Deve existir a possibilidade de mapear serviços alternativos.3 Tecnologias Utilizadas É apresentado por meio da Figura 1. e devem ser utilizados no gerenciamento das reconfigurações e descobertas de serviços. Este framework permite que componentes sejam instalados. 27 . RF6 É necessária a existência de um mecanismo que permita a implantação de novos serviços e atualização dos descritores de serviços e variabilidades em tempo de execução. que é atribuída na descrição do serviço. o serviço mais adequado deve ser selecionado. provendo um maior controle sobre a estrutura do código e gerenciamento dinâmico do ciclo de vida dos componentes.

4 Arquitetura e Implementação A arquitetura de software tem um papel importante no seu ciclo de vida. iPOJO é um modelo de componente orientado a serviço que tem como objetivo simplificar o desenvolvimento de aplicações OSGi. Nesse contexto. A Seção 3. uma arquitetura de software pode ser vista como uma ligação entre os requisitos de um sistema e a implementação. ARQUITETURA E IMPLEMENTAÇÃO Apache Felix é uma distribuição open-source. também foi utilizado o JAXB2 (Java Architecture for XML Binding). O JAXB consiste em um conjunto de bibliotecas Java que permitem a conversão de XML em objetos Java e vice-versa. permitindo uma visão mais clara sobre a análise e projeto de componentes do sistema (Kruchten et al. De acordo com (Clements et al. ligações entre estes e possíveis restrições. Conforme é possível 2 http://www. 2007).4. 2003). descrevendo componentes..3.. OSGi Distribuído (em inglês. 2006).1 uma visão geral da Arquitetura do DYMOS. mantida pela Apache Foundation com o apoio da comunidade.oracle. O iPOJO permite o desenvolvimento de componentes orientados a serviço para compor sistemas modulares que requerem adaptações em tempo de execução (Escoffier et al. a partir de detalhes internos de cada componentes (Shaw and Garlan. A utilização das tecnologia mencionadas nesta seção possibilitou o desenvolvimento da solução proposta neste trabalho. nós definimos a arquitetura do DYMOS com o objetivo de atender os requisitos descritos na Seção 3. 1996). Além disso.html 28 . que segue a especificação OSGi Remote Services e permite que aplicações OSGi sejam implantadas na forma de serviços web.com/technetwork/articles/javase/index-140168. é por meio da arquitetura do software que a estrutura geral do sistema é separada em termos de componentes e conexões. destacando os principais componentes e suas respectivas ligações. “Distributed OSGi” ou DOSGi) é um subprojeto do Apache CXF. Na arquitetura é desenhada a estrutura e organização que define como os componentes e subsistemas interagem.x da especificação OSGi Service Platform e é utilizado como plataforma de execução de aplicações OSGi. Este framework implementa a versão 4. O DOSGi fornece uma implementação de referência com base em Web Services.4 descreverá com mais detalhes a escolha destas tecnologias e onde cada uma delas foram utilizadas.2. Além das tecnologias mencionadas acima. 3. É apresentada por meio da Figura 3..

que externaliza as funcionalidades de descoberta de serviços e reconfiguração de variabilidades por meio de web services. na Seção 3.4. Estas estruturas foram modeladas utilizando notações XSD (XML Schema Definition) e permitem que os elementos sejam descritos por meio de XML. Por fim. que são utilizadas para gerenciar as informações sobre as Variabilidades e Composições de Serviços.1 DYMOS: Visão Geral da Arquitetura As próximas subseções apresentam a arquitetura sob diferentes visões e discussões sobre os principais componentes. que podem ser visualizadas no Capítulo A do Apêndice.4 é feita uma discussão sobre as decisões arquiterurais e como os requisitos elencados foram atendidos. o WSResolver e o ApplicationService. 29 . nós definimos estruturas de metadados. os principais componentes são o ServiceContext. Como um requisito para prover a descrição do elemento em forma de objetos Java. Figura 3. o ServiceDescriptor.3. 3.4. podendo ser convertidos para uma estrutura de objetos Java.1 Componentes Descritores Como forma de permitir a descrição de elementos como Variabilidades e Composição de Serviços. ARQUITETURA E IMPLEMENTAÇÃO observar na figura. é necessário que o descritor siga a especificação definida pela interface ObjectDescriptor. o VariabilityDescriptor.4.

2 Especificação de Descritores Os descritores implementados para o DYMOS consistem em: Descritor de Serviços (DS). Além desses métodos. ARQUITETURA E IMPLEMENTAÇÃO Conforme é possível observar na Figura 3. de objeto Java para XML. É apresentado por meio da Figura 3. onde o tipo de retorno T representa o tipo do elemento descrito. provendo várias formas de entrada de dados. são definidos métodos getObjectDescriptors que possuem diferentes parâmetros. o descritor também provê um método para efetuar uma conversão inversa. Figura 3. e o Web Service Resolver (WSR) por meio do componente (WSResolver).3 como a especificação de cada descritor está disposta em relação a especificação genérica ObjectDescriptor. 30 .2. por meio do componente (ServiceDescriptor).3. Descritor de Variabilidades (DV) por meio do componente (VariabilityDescriptor).4.

efetuando a substituição do tipo T pelo respectivo tipo do descritor. Os metadados definidos para descrever Serviços obedecem a estrutura de classes apresentada na Figura 3.3. ARQUITETURA E IMPLEMENTAÇÃO Figura 3. a especificação de cada descritor herda da especificação genérica ObjectDescriptor. A seguir. 31 . os serviços que estarão ligados a features do produto. Descritor de Serviços Conforme mencionado anteriormente. serão apresentados detalhes sobre a implementação de cada um dos descritores.4. por meio de XML.3 Relacionamento entre Descritores Como é possível perceber na Figura 3.3.4. nós definimos uma estrutura de metadados que foi modelada utilizando notações XSD e possibilitam descrever.

32 . além dessas informações.4 que um Serviço possui: uma Identificação (ID). É apresentado por meio da Figura 3. é possível observar na Figura 3. e um conjunto de Serviços Alternativos.5 um exemplo prático de Descrições de Serviços. Apesar de não ser mandatório. ARQUITETURA E IMPLEMENTAÇÃO Figura 3. uma Implementação. uma Especificação. por meio do atributo “serviceImpl”.4. Ao descrever um serviço.4 Descritor de Serviços: Estrutura de Metadados Conforme foi definido a estrutura dos metadados de Serviços. por meio do atributo “id”. por meio do atributo “serviceSpec”. é possível atribuir uma determinada Implementação e um conjunto de Serviços Alternativos. é necessário atribuir um Identificador Único e uma Especificação. que indica um contrato de implementação (interface) que o serviço implementa. que possuem uma referência para um outro serviço descrito e uma prioridade.3.

IDataAccessService</service-spec> <alternative-service ref="fileAccessService" priority="1" /> </service> <service id="fileAccessService" service-impl="br.assert. permitindo que tais informações sejam utilizadas pelo DYMOS nas operações de Reconfiguração e Descoberta de Serviços.ws.encrypt.cin. ARQUITETURA E IMPLEMENTAÇÃO <?xml version="1.ufpe. as variabilidades que farão parte do produto.6.assert.dataEncrypt.4.dataAccess. como demonstrado na figura. é possível ob- 33 .ufpe. para o DV também foi definida uma estrutura de metadados que possibilitam descrever.auth.dataAccess.dataEncrypt.ws.ws.1 e a forma como as informações provenientes de tais metadados são utilizadas em tais operações são descritas com mais detalhes na Seção 3.assert.IAuthService</service-spec> </service> </services> Figura 3.impl. Os metadados definidos para descrever Variabilidades obedecem a estrutura de classes apresentada na Figura 3. Cada Serviço Alternativo deve receber uma prioridade.dataAccess. é possível obter objetos Java que representam as informações sobre os serviços descritos.dataAccess.ufpe.cin. A estrutura de metadados de serviços pode ser visualizada na Seção A.ufpe.cin.ufpe.assert.FileAccessServiceImpl"> <service-spec>br. Conforme foi definido a estrutura dos metadados de Variabilidades.impl.encrypt.DataBaseAccessServiceImpl"> <service-spec>br.impl.cin.cin.assert.cin.5 Descritor de Serviços: Exemplo Prático Referente a atribuição de valores aos atributos. que deve ser um ID de um serviço já descrito.EncryptServiceImpl"> <service-spec>br.assert. por meio de XML.ufpe. a especificação e implementação do serviço devem seguir o padrão de nome de classe Java na forma completa.2 Descritor de Variabilidades Assim como foi feito no DS.3.cin.4.assert.ufpe.ws.ws.ws.IDataAccessService</service-spec> </service> <service id="dataEncryptService" service-impl="br.0"?> <services> <service id="dataBaseAccessService" service-impl="br. Um Serviço Alternativo pode ser declarado atribuindo um valor ao atributo “service-ref”. Por meio do DS.IDataEncryptService</service-spec> </service> <service id="authService"> <service-spec>br.ws.

um Nome e um conjunto de Referência para Serviços. um nome e um conjunto de Referência para Serviços. uma nome . Um elemento do tipo (Variant) representa uma possibilidade de variação na configuração de um produto (Pohl et al. Para cada referência deve ser atribuindo o valor do atributo “service-ref” coincidente com um ID válido de serviço já descrito.4. 34 . por meio do atributo “name”. ARQUITETURA E IMPLEMENTAÇÃO servar na Figura 3. O conjunto de Referência para Serviços representam os serviços que são endereçados por features e que devem ser ativados ou desativados quando uma reconfiguração é efetuada.6 Descritor de Variabilidades Ao descrever uma variabilidade. Figura 3.6 que uma Variabilidade possui: uma Identificação (ID). É apresentado por meio da Figura 3.3. por meio do atributo “id”. é necessário atribuir um Identificador Único. um Nome não obrigatório e um conjunto de variações (Variant). 2005) e pode ser descrito indicando um Identificador Único. e um conjunto de variações (Variant).7 um exemplo prático de Descrições de Variabilidades. Uma Variant é composta por um ID..

7.3. são descritas duas variabilidades.4. O WSR utiliza a versão 1. e “auth” para a variabilidade “authVariability”. Esta composição de serviços atendem a uma ou mais features do produto e deve manter os serviços ativos e disponíveis quando a variação estiver ligada a estas features. de acordo com o exemplo demonstrado na Figura 3. serviços como um conjunto de operações. formando uma composição de serviços. Isso quer dizer que.4.2 e a forma como as informações provenientes de tais metadados são utilizadas em operações de reconfiguração de variabilidades são descritas com mais detalhes na Seção 3. Cada uma das variabilidades possuem possibilidades de variações que são: “dataBaseAccess” e “fileAccess” para a variabilidade “dataAccess”. por meio de XML.7 Descritor de Variabilidades: Exemplo Prático No exemplo apresentado por meio da Figura 3.3. 35 . ARQUITETURA E IMPLEMENTAÇÃO <?xml version="1. Este componente não faz interação direta com o usuário e é utilizado por outros componentes da arquitetura.1 da estrutura.7. que está disponível na Seção A. Cada uma das variações descritas podem endereçar um conjunto de Referências para Serviços.0"?> <variabilities> <variability id="dataAccess"> <variant id="dataBaseAccess"> <service-ref ref="dataBaseAccessService" /> </variant> <variant id="fileAccess"> <service-ref ref="fileAccessService" /> <service-ref ref="dataEncryptService" /> </variant> </variability> <variability id="authVariability"> <variant id="auth"> <service-ref ref="authService" /> </variant> </variability> </variabilities> Figura 3. os serviços “fileAccessService” e “dataEncryptService” devem estar ativos e disponíveis para uso. A estrutura de metadados de variabilidades pode ser visualizada na Seção A. que são: “dataAccess” e “authVariability”. foi utilizado uma estrutura XSD que permite descrever. no momento em que a variação “fileAccess” for ligada ao produto.2 Web Service Resolver Na definição e modelagem dos metadados referentes ao WSDL.

que respectivamente significam os serviços descritos e as variabilidades descritas.2 Componente ServiceContext Uma vez que os Serviços estão descritos e mapeados nas descrições de Variabilidades por meio de Composição de Serviços. indicando a relação entre eles através de importação e exportação de pacotes (packages). prover de acordo com um determinado serviço. em tempo de execução. as informações sobre tais descrições devem ser utilizadas no gerenciamento das Variabilidades.9 uma visão sob uma perspectiva de dependência entre o ServiceContext e os demais componentes. Durante o decorrer desta seção mecionaremos os termos “Contexto de Serviços” e “Contexto de Variabilidades”. É apresentado por meio da Figura 3. ambos em memória.8 o dado de entrada é um Web Service Definition Language (WSDL) referente a um determinado serviço e é obtido como saída um objeto Java que permite acessar.4.3.4.8 o fluxo de dados durante a execução deste descritor. Target Namespace. É apresentado por meio da Figura 3. etc. 3. as informações sobre este serviço. o WSR permite uma maior flexibilidade ao DYMOS. O Componente ServiceContext é responsável por manter tais informações em memória.2 é feita uma explanação com mais detalhes sobre a utilidade deste componente e como as informações obtidas através dele são úteis para a operação de Descoberta de Serviços. PortType. Na Seção 3. atributos que não são descritos no DS e que são particulares a cada implementação de um serviço como ServiceName. de modo que seja possível utilizá-las durante as operações de Reconfiguração de Variabilidades e Descoberta de Serviços. Dessa forma.8 Descritor de WSDL: Fluxo de Dados Conforme é possível visualizar na Figura 3. sendo a sua principal função. de forma mais simples. 36 . ARQUITETURA E IMPLEMENTAÇÃO O WSR é utilizado em operações de Descoberta de Serviços. agregando características dinâmicas e de baixo acoplamento. Figura 3.4.

permitindo o gerenciamento das Variabilidades e Serviços descritos. 2006). A utilização destes componentes permite ao ServiceContext obter todas as informações descritas na forma de objetos Java.9. ARQUITETURA E IMPLEMENTAÇÃO Figura 3. Cada uma destas funcionalidades são descritas com mais detalhes nas próximas seções. “uninstall”. Reconfigurando Variabilidades Dinâmicas Utilizar técnicas de LPS tem se mostrado uma forma eficiente de lidar com diferentes necessidades dos usuários (Hallsteinsen et al. Descoberta de Serviços e “ContextHotBuild”..9 Componente ServiceContext: Uma visão sob uma perspectiva de dependência entre componentes Conforme é possível observar na Figura 3. “stop” e “getEndpoint”.3. As principais funcionalidades implementadas pelo componente ServiceContext são as operações de Reconfiguração de Variabilidades. “start”. Este gerenciamento consiste em utilizar as informações sobre as Variabilidades e Serviços para em manipular o container OSGi.4. o componente ServiceContext faz uso de todos os componentes descritores. efetuando operações como “install”. uma vez que é possível construir 37 .

. como aplicações sensíveis ao contexto. o DYMOS deve ser notificado sobre a adaptação na aplicação e informado sobre as variabilidades que foram afetadas. Para que seja possível efetuar uma reconfiguração. é possível ativar ou desativar serviços que são endereçados por variabilidades. Ou seja. Esse tipo de aplicação possui variabilidades dinâmicas. de acordo com mudanças no contexto notificadas pela aplicação cliente. a sequência das operações necessárias para efetuar a reconfiguração de variabilidades dinâmicas. o DYMOS é notificado para que efetue reconfiguração nos serviços. ARQUITETURA E IMPLEMENTAÇÃO um produto de software por meio da seleção das variabilidades. de forma que as adaptações da aplicação sejam atendidas. Figura 3. É apresentado por meio da Figura 3.10.4. 2008).3. quando há uma mudança no contexto e a aplicação se adapta. No entanto. Por meio dos mecanismos de reconfiguração. Para tratar esse tipo de questão. exigindo que a arquitetura da LPS seja capaz de tratar tais variabilidades (Hallsteinsen et al. foi implementado no DYMOS mecanismos para reconfiguração de variabilidades dinâmicas.10 Reconfigurando Variabilidades Dinâmicas: Diagrama de Sequência 38 . as técnicas de LPS na sua forma tradicional não são adequadas para produtos cuja arquitetura precisa ser adaptada em tempo de execução.

uma 39 . Os módulo encontrados são ativados e. 2010). de modo que a funcionalidade seja provida (Yu and Reiff-Marganiec. latência. de acordo com a variante informada na notificação. foram implementados mecanismos que são responsáveis por operações de Descoberta de Serviços. que são configuradas a partir de uma composição de serviços.4. permitindo que a relação entre cliente e serviços não seja tratada de forma fixa ou acoplada. que são mantidas no Contexto de Variabilidades pelo componente ServiceContext.1. são recuperadas as suas configurações. um único serviço deve ser selecionado. utilizando as informações obtidas a partir do DV e DS. A notificação ocorre por meio de uma requisição assíncrona ao web service responsável por receber tais notificações. confiabilidade. dentre um conjunto de serviços.3 serão expostos mais detalhes sobre os web services disponíveis para a aplicação Client. a seleção de um serviço mais adequado (Khezrian et al. inclusive. Na Seção 3. A seleção de um serviço é feita com base em requisitos funcionais e requisitos não-funcionais e. a aplicação Client notifica o DYMOS sobre uma mudança no contexto. Por meio da configuração da variabilidade. após isso. Descoberta de Serviços Quando uma requisição por um serviço é efetuada.3. Inicialmente. Como exemplo de tais critérios. ARQUITETURA E IMPLEMENTAÇÃO Conforme é possível observar na Figura 3. É apresentada por meio da Figura 3. ou características mais básicas como uma simples verificação se o serviço está ativo e seleção por prioridade em caso de indisponibilidade. os serviços deverão estar disponíveis para utilização.. Uma vez que a notificação é recebida pelo componente ApplicationContext. Mecanismos de descoberta de serviços agregam características dinâmicas a uma solução de software. são identificados os serviços endereçados a ela e. a descrição de uma variabilidade consiste em um conjunto de variações. é possível citar fatores como uptime. a mesma é repassada ao ServiceContext para que possa ser tratada. são buscados no OSGi Container os respectivos módulos que são responsáveis por prover tais serviços.4.11. dentre um grande conjunto de serviços. utilizando os atributos service-spec e service-impl descritos no DS respectivamente como argumentos dos métodos “findBundleService” e “findBundleServiceImpl”. A utilização de mecanismos de descoberta de serviços permitem. Como já apresentado na Seção 3.10. 2008).4. uma questão que pode ser levantada é sobre como selecionar o serviço adequado. No contexto do DYMOS. acrescentar critérios que podem determinar. quantidade de pacotes perdidos. indicando qual o ponto de variação que foi afetado.

consiste em analisar um conjunto de critérios pré-definidos para que seja possível selecionar o serviço mais adequado para atender tal requisição. Estes critérios são definidos de acordo com as informações descritas no DS. que é demonstrada pelo item “1”. o item “2” é executado e é quando o componente ApplicationService a repassa para o componente ServiceContext. ARQUITETURA E IMPLEMENTAÇÃO visão geral sobre a interação entre os componentes envolvidos nestas operações.4. Os critérios adotados na implementação dos mecanismos de Descoberta de Serviços do DYMOS consistem na verificação de disponibilidade de um serviço e seleção de serviços alternativos de acordo com uma prioridade. 40 . uma operação de descoberta de serviços é iniciada a partir de uma requisição feita pela aplicação cliente. para que possa ser tratada.11.11 Descoberta de Serviços: Visão geral sobre a interação entre componentes De acordo com o que é exposto na Figura 3.3. demonstrado pelo item “3”. Figura 3. Após receber a requisição. O tratamento da requisição.12. como apresentado na Figura 3.

service4.impl.ws. onde é definida a implementação do serviço.ws.impl.cin.3.IGreetService</service-spec> </service> <service id="service4" service-impl="br.greetService.cin.ufpe.ws.cin.IGreetService</service-spec> </service> </services> Figura 3. onde é definido a especificação ou contrato do serviço.ws.cin.assert.ufpe. o “service-spec”.assert.greetService.Service1Impl"> <service-spec>br.ufpe.impl.greetService.12 Descoberta de Serviços: Serviços descritos para um exemplo prático Os atributos utilizados nas operações de descoberta de serviços são: o “serviceimpl”.assert.ws.IGreetService</service-spec> <alternative-service ref="service2" priority="3" /> <alternative-service ref="service3" priority="2" /> <alternative-service ref="service4" priority="1" /> </service> <service id="service2" service-impl="br.ufpe. É apresentado na Figura 3.cin.service2.ufpe.service1.assert.Service4Impl"> <service-spec>br.ws.ws. e o “priority” definido em “alternative-service”. que elenca serviços alternativos indicando uma prioridade para cada um.ufpe.greetService.4. 41 .ufpe.Service4Impl"> <service-spec>br.assert.assert.13 o diagrama que representa a sequência de funções executadas durante a operação de descoberta de serviços.IGreetService</service-spec> </service> <service id="service3"> <service-spec>br. ARQUITETURA E IMPLEMENTAÇÃO <?xml version="1.cin.assert.0"?> <services> <service id="service1" service-impl="br.cin.

de acordo com o serviço requisitado. “service-spec” e “alternativeservice” são utilizados para efetuar a seleção do serviço. são recuperadas as suas informações.13. os atributos “service-impl”.4. ela é repassada ao ServiceContext para que possa ser tratada. Inicialmente. utilizando as informações obtidas a partir do DS. onde é informado o ID do serviço requerido. a execução de uma operação de descoberta de serviço é iniciada quando há uma requisição por um serviço através do método “getEndpoint”. O principal objetivo desse tipo de operação é recuperar uma referência (endpoint) de um serviço que atenda a uma determinada funcionalidade.13 Descoberta de Serviços: Diagrama de Sequência Conforme é possível observar na Figura 3. que são mantidas em memória pelo componente ServiceContext.3. 42 . ARQUITETURA E IMPLEMENTAÇÃO Figura 3. Quando a requisição é recebida pelo componente ApplicationContext. para que seja possível utilizá-lo. Após recuperar tais informações.

remover ou atualizar dinamicamente um componente (Tan. Reconstruindo o ServiceContext com o ContextHotBuild Com o passar do tempo. caso aconteça uma falha no item i e o serviço não possa ser encontrado utilizando estes atributos. (iii) é efetuada uma busca por serviços que provêem uma implementação para a Especificação definida no atributo “service-spec”. Tais objetos são processados e como resposta é gerado um valor que corresponde a uma referência para o serviço selecionado. os serviços que estão em execução no OSGi Container e que não estão descritos no DS. Conforme elicitado por meio do requisito funcional RF6. é obtido um menor acoplamento entre o cliente e o serviço. respeitando a prioridade definida no atributo “priority” e considerando que os menores números são mais prioritários. Hot swapping e On-the-Fly Software Replacement são termos utilizados no contexto de evolução de software. 2006). Após encontrar e selecionar o serviço mais adequado. A resposta gerada. 1998). melhoria dos seus componentes. 2001. o componente ServiceContext interage com o OSGi Container a fim de identificar o bundle responsável por prover tal serviço. O mecanismo de Descoberta de Serviços implementado como parte do DYMOS oferece uma abstração entre o cliente e o serviço. Oreizy et al.3. permitindo adicionar. ARQUITETURA E IMPLEMENTAÇÃO Com o objetivo de encontrar o serviço mais adequado para atender a requisição recebida. Consequentemente. que obedece o formato “serviceEndpoint. ou por questões de adaptação do software para atender a novos requisitos (Alhazbi and Jantan. a implantação de forma facilitada de atualizações de serviços que já estão em execução ou de novos serviços. é enviada ao cliente que efetuou a requisição do serviço. que são utilizadas como critérios de seleção. o ServiceContext interage com o componente WSResolver informando o endereço onde o serviço está publicado. Essa abstração possibilita a existência de requisições por serviços informando um ID previamente mapeado com um conjunto de informações sobre o serviço. (ii) é efetuada uma busca por serviços alternativos. A sequência utilizada na seleção do serviço consiste em (i) buscar por um serviço que atenda à Especificação e Implementação definida no DS por meio dos atributos “service-spec” e “service-impl” respectivamente. e obtem como resposta as informações que constam no WSDL em forma de objetos Java. possibilitando inclusive.serviceName”. é necessária a existência 43 . que consiste em reconfigurações em tempo de execução.4. considerando inclusive.. caso aconteça uma falha no item ii e não seja possível selecionar um serviço. um software necessita ser atualizado por diferentes razões como resolução de bug.targetNamespace.

o componente ApplicationService foi implementado de forma a funcionar como uma fachada. 1995).4. resultam em um maior número de classes menores. Isto gera uma mudança no ciclo de vida dos componentes. Os subsistemas se tornam mais complexos a medida que evoluem e quando aplicados padrões. porém mais difícil de utilizar. em busca de atualizações nas informações descritas e.4. e no contexto do DYMOS. Dessa forma. o componente ApplicationService foi implementado utilizando o padrão de projeto Facade. o DYMOS faz uma nova leitura no DS e no DV por meio do ContextHotBuild. e consequentemente. estruturar um sistema em subsistemas ajuda a reduzir a complexidade.. No momento em que um novo componente é instalado. são executadas no OSGi Container operações de install e uninstall respectivamente. Facade) pode fornecer como comportamento padrão uma visão do sistema. Uma Fachada (em inglês. criando um isolamento 44 . Este mecanismo também provê uma facilidade para operações de implantação de componentes no OSGi Container. Dessa forma. foi desenvolvido como parte do DYMOS o ContextHotBuild. e inclusive de uma forma facilitada. reconstrói o contexto de serviços e variabilidades. Como o nome do padrão de projeto adotado sugere. 3. Com o objetivo de atender este requisito. que consiste em disponibilizar um diretório para implantação de componentes.. que é suficientemente boa para a maioria dos clientes (Gamma et al. quando componentes são inseridos ou removidos de tal diretório. O ContextHotBuild é responsável por capturar mudanças no ciclo de vida dos componentes instalados no OSGi Container. não exigindo o contato direto com o OSGi Container para instalação ou remoção de componentes por meio de linhas de comando. em especial quando o estado do componente é alterado para INSTALLED. minimizando a dependência entre eles. uma reconstrução no Contexto de Serviços e Variabilidades. 1995). Isso torna o subsistema mais reutilizável. em seguida.3. que permite o hot swapping de serviços e variabilidades.3 Componente ApplicationService De acordo com (Gamma et al. ARQUITETURA E IMPLEMENTAÇÃO de um mecanismo que permita a implantação de novos serviços e atualização dos descritores de serviços e variabilidades em tempo de execução. Este mecanismo permite a inclusão ou remoção de serviços e variabilidades sem a necessidade de interromper a execução do framework. de modo que variabilidades possam ser incluídas ou excluídas sem a necessidade de interromper a execução do framework.

Este componente foi implementado utilizando o iPOJO para obtê-lo na forma de bundle OSGi e o CXF DOGSi para expor suas funcionalidades por meio de web services. e por fim. que é mantido pela comunidade e distribuído sob a licença Apache. ARQUITETURA E IMPLEMENTAÇÃO entre os clientes e os demais componentes do framework. Um dos principais objetivos desse trabalho é efetuar um estudo sobre variabilidades dinâmicas em LPSOSSC e.4. Estas operações são disponibilizadas por meio de web services. As decisões arquiteturais basicamente consistiram em: escolha da plataforma OSGi que iríamos utilizar. é possível citar as mais conhecidas: o Equinox. Abaixo serão descritas com mais detalhes as principais decisões arquiteturais que permitiram projetar e implementar o DYMOS: Plataforma OSGi Por se tratar de um conjunto de especificações.4. que é um framework cujo princípio é suportar esse tipo de variabilidade nessa categoria de LPS. o Felix. qual seriam os critérios utilizados na operação de descoberta de serviços. A distribuição adotada como plataforma de execução do framework foi o Apa- 45 . de forma que. escolha do modelo de componentes que seria seguido para desenvolver os componentes da solução proposta. o OSGi possui diversas distribuições que são mantidas por diversas organizações. permite o reuso. e por esses motivos foi adotado como plataforma de execução. que é mantido pela Eclipse Foundation. Dentre essas distribuições. O OSGi oferece benefícios como redução na complexidade dos componentes. escolha da tecnologia que seria utilizada para expor os serviços na forma de web services. O desenvolvido do DYMOS foi baseado em tecnologias OSGi. 3. todas as requisições recebidas devem ser delegadas ao componente ServiceContext para que possam ser tratadas. foi desenvolvido o DYMOS. escolha da tecnologia que seria utilizada para tratar os descritores como objetos Java. que é mantido pela Makewave (Gatespace Telematics). O principal objetivo do componente ApplicationService é externalizar as operações de Reconfiguração de Variabilidades e Descoberta de Serviços.3.4 Decisões Arquiteturais e Conclusão Esta seção apresenta uma discussão sobre as decisões arquiteturais e como foi possível atender os Requisitos RFs e os RNFs elicitados. é reduzido o número de objetos com que os clientes precisam lidar. Dessa forma. como resultado. o Knoplerfish. que consiste em um conjunto de especificações para desenvolvimento de software Java na forma de módulos (bundles). atualizações e adaptações dinâmicas.

Esse framework foi adotado por ser compatível com o iPOJO e pelo fácil acesso a documentação por meio de material online.codehaus. Expor Serviços como Web Services Para expor Serviços como Web Services. como uma forma de atender o requisito não-funcional “RNF1” e facilitar o gerenciamento das informações durante a execução das operações. os principais modelos de componentes são o BluePrint. Dentre as características. outro fator que contribuiu para a adoção desse framework foi o suporte oferecido ao uso de serviços de uma forma distribuída. Atualmente.3. Por esse motivo. que consiste em um conjunto de bibliotecas para converter objetos Java em XML e vice-versa. Tratar informações descritas em XML As informações sobre os Serviços e Variabilidades são descritas na forma de XML.org/ 46 . o suporte a composição de serviços e controle do seu ciclo de vida. que inclui documentação online. O JAXB possibilitou a geração dos metamodelos de Serviços e Variabilidades a partir de estruturas definidas 3 http://xstream. No entanto. existiram alguns problemas de compatibilidade entre as bibliotecas pois ainda não existia uma versão compatível com OSGi. que estão em execução em diferentes instâncias da plataforma OSGi. fóruns e grupos de discussão. Estes fatores contribuíram para a escolha do iPOJO pois este se mostrou um modelo de componente que permite o desenvolvimento dos componentes de uma forma mais rápida e simples. foi decidido adotar o JAXB. ARQUITETURA E IMPLEMENTAÇÃO che Felix. que consiste em um conjunto de bibliotecas que são providas por meio do Java que possuem compatibilidade com a tecnologia OSGi. fóruns. Esses fatores influenciaram positivamente na escolha da ferramenta pois facilitou consideravelmente o aprendizado. grupos de discussão e tutoriais. foi adotado o iPOJO como modelo de componente pois ele possui características que não são suportadas pelos demais modelos. podemos citar a possibilidade de utilizar Java Annotations para efetuar a configuração dos serviços. Então. Dentre estas opções.4. agilizando a sua utilização. Inicialmente foi adotado o XStream3 . ou seja. foi adotado o CXF DOSGi.s Modelo de Componentes Os modelos de componentes consistem em especificações que foram seguidas para permitir o desenvolvimento dos componentes OSGi. Esta distribuição possui uma documentação de acesso fácil. Além disso. as informações precisam ser convertidas em objetos Java. Declarative Services e o iPOJO.

1 quais os requisitos são atendidos por cada componente e. enquanto permite uma configuração mais flexível. por meio de uma prioridade definida no DS. 2008). quais são os componentes que estão envolvidos na resolução de cada requisito. que pode ser medida por meio de métricas como confiabilidade. É possível visualizar na Tabela 3. Critérios de Seleção de Serviços Diversas abordagens se baseiam em requisitos nãofuncionais para efetuar uma seleção de serviço e um fator que pode influenciar tal seleção é a qualidade do serviço. Por fim. 47 . Estes critérios foram definidos com o objetivo de ser simples. Requisitos Funcionais e Requisitos Não-Funcionais Será apresentada no próximo capítulo (Capítulo 4). uma avaliação preliminar que demonstra a aplicação da abordagem proposta neste trabalho. tempo de resposta e reputação (Yu and Reiff-Marganiec.1 a relação entre Componentes. Requisitos Funcionais e Requisitos Não-Funcionais. ARQUITETURA E IMPLEMENTAÇÃO utilizando notações XSD.1 Relação entre Componentes. consiste na seleção de serviços com base na preferência do usuário. Como critérios de seleção de serviço.3. Requisitos Funcionais (RF) e Requisitos Não-funcionais (RNF) Componentes RF1 RF2 RF3 RF4 RF5 RF6 RF7 RF8 RF9 RNF1 RNF2 ApplicationService • • • ServiceDescriptor • • • VariabilityDescriptor • • • WSResolver • HotBuildContext ServiceContext • • • • • • • • • • • • • • • Tabela 3. inclusive. foram definidos dois critérios. onde o primeiro consiste na verificação de disponibilidade do serviço e o segundo. é apresentado por meio da Tabela 3.4.

utilizado no Departamento de Ciências da Computação da Universidade Federal do Ceará (UFC)..4 Uma Avaliação Preliminar Quem nunca cometeu um erro nunca tentou algo novo. Neste estudo foram utilizados dois produtos provenientes do “nível específico” da MobiLine. 4. nas seções consecutivas. —ALBERT EINSTEIN É apresentado neste capítulo uma avaliação preliminar que demonstra a aplicação da abordagem proposta neste trabalho. Um dos produtos é o GREat Tour. Levando em consideração um domínio amplo 48 . 2012). porém com menos funcionalidades. que trata-se de uma aplicação para o mesmo propósito. serão detalhadas as etapas executadas nesta avaliação. é preciso uma análise prévia do domínio a fim de identificar semelhanças e diferenças entre as aplicações (Pohl et al. A avaliação foi executada em dois produtos derivados da MobiLine. A abordagem proposta consiste em prover suporte a variabilidades dinâmicas em LPSOSSC por meio do DYMOS Framework. que é uma LPS aninhada cujo domínio é de aplicações móveis e sensíveis ao contexto (Marinho et al. O segundo produto é o CIn Tour. 2005). que trata-se de um Guia de Visitas Móvel e Sensível ao Contexto. que é utilizado no Centro de Informática (CIn) da Universidade Federal de Pernambuco (UFPE). A person who never made a mistake never tried anything new. Na próxima seção será feita uma breve apresentação sobre a MobiLine e.1 MobiLine A MobiLine é uma LPS multinível cujo domínio é o de aplicações móveis e sensíveis ao contexto. De modo a possibilitar o desenvolvimento de aplicações utilizando técnicas de LPS. São apresentados mais detalhes sobre a MobiLine na Seção 4.1..

Esta divisão é apresentada por meio da Figura 4. Um modelo de features é produzido após efetuar uma junção das features requeridas pelo domínio específico de negócio com as features selecionadas no nível base. a modelagem da LPS pode não ser bem sucedida. Para demonstrar o uso da abordagem proposta. 2012) De acordo com a abordagem adotada.1. Com o objetivo de tratar esta complexidade. o nível base é composto por funcionalidades mais gerais e comuns que estão presentes em aplicações móveis e sensíveis ao contexto. MOBILINE e complexo como o de aplicações móveis e sensíveis ao contexto.. Este Guia de Visitas trata-se de uma aplicação..4.1 Abordagem utilizada na MobiLine (Marinho et al. utilizada para 49 . executando em um dispositivo móvel. No nível específico.1. a abordagem adotada na MobiLine consiste em dividir a análise de domínio em dois níveis: nível base e nível específico. 2012) seleciona um domínio de negócio. As principais funcionalidades identificadas neste nível foram “ambiente de execução dinâmica”. o escopo é restrito a um domínio específico de negócio. que é o domínio de Guia de Visitas Móvel e Sensível ao Contexto. “adaptabilidade” e “sensibilidade ao contexto”. (Marinho et al. Figura 4.

as características do seu dispositivo móvel. as definições permitiram determinar “como” será efetuada a avaliação. parque. 2.2. As análises auxiliaram na identificação de “o que” necessita ser efetuado para permitir variabilidades dinâmicas no GREat Tour. Adicionalmente. seu perfil ou preferências. GREAT TOUR guiar visitantes em um ambiente desconhecido como museu. a execução da avaliação foi efetuada com base em um conjunto de análises e definições. definindo uma estratégia para efetuar a migração da implementação atual para um modelo de implementação compatível com OSGi. que abrange a localização do visitante. Serão apresentadas nesta seção as etapas executadas na avaliação do uso do DYMOS para permitir variabilidades dinâmicas no GREat Tour. O seu comportamento se adapta de acordo com o contexto atual do visitante.2 GREat Tour O GREat Tour é um Guia de Visitas Móvel e Sensível ao Contexto criado a partir da MobiLine. As etapas executadas consistem em um conjunto de análises e definições.2. A aplicação é executada no dispositivo móvel do visitante e fornece informações sobre os pesquisadores e ambientes do laboratório que são visitados. Análise da implementação dos artefatos referentes às features selecionadas. a fim de identificar as tecnologias utilizadas e verificar a compatibilidade com o OSGi. 4. 4.1 Análise e Definições Como já foi mencionado. 3. Esta aplicação foi implementada para auxiliar visitantes a conhecerem o laboratório de pesquisa e desenvolvimento do GREat (Grupo de Redes. Engenharia de Software e Sistemas) da Universidade Federal do Ceará. que serão detalhadas nas próximas seções. utilizando a abordagem proposta por meio do DYMOS.4. e informações a respeito de outras pessoas presentes na mesma sala em que o visitante se encontra. Análise do modelo de features do produto a fim de selecionar features e pontos de variação para serem utilizados na avaliação. 50 . Abaixo está destacado o conjunto de análises efetuadas: 1. ou uma cidade. Analisar os casos de incompatibilidade.

GREAT TOUR 4. 4. Será descrito nas próximas seções os resultados obtidos a partir da execução de cada análise.2 é apresentado de forma parcial o modelo de features do GREat Tour.2 GREat Tour: Modelo de Feature Parcial No modelo apresentado por meio da Figura 4. A notação utilizada para desenhar tal modelo foi proposta por (Czarnecki and Eisenecker. Por meio da Figura 4.2 é possível visualizar as features selecionadas para a avaliação.2 Analisando o Modelo de Features Esta etapa consistiu em analisar o modelo de features do GREat Tour com a finalidade de selecionar features e pontos de variação que seriam utilizados na avaliação da abordagem proposta. a fim de identificar os pontos que passarão por refatoração para que possibilite a compatibilidade com o DYMOS. Análise da implementação dos artefatos da aplicação cliente. Figura 4. De acordo com as análises efetuadas. foi possível elencar um conjunto de definições que guiaram esta avaliação.2.2.4. especificando como as etapas seriam executadas. 2000). Tais features consistem em funcionalidades referentes a 51 .

suas implementações. foi possível observar que suas funções são disponibilizadas na forma de Serviços Web. as tecnologias utilizadas e. que especifica o tipo de mídia que estará disponível para visualização.3 Analisando os Artefatos Nesta etapa. o vídeo como um tipo de mídia também é considerado uma feature. foi possível visualizar a relação entre features.1 Relação entre Features e Artefatos Adicionalmente. 4.org/axis/ 2 http://tomcat.org/ 52 . inicialmente foi necessário efetuar a identificação dos artefatos. De forma a possibilitar esta análise. foi efetuada uma análise na implementação dos artefatos referentes às features selecionadas. Isto foi possível por meio de uma inspeção não-sistemática nas implementações da aplicação. por ser uma feature opcional. que pode possuir um provedor local ou externo.2.apache. VideoService Video LocalVideoProviderService. Como resultado desta análise. 1 http://axis. por fim. Na próxima seção será descrita a análise efetuada sobre a implementação dos artefatos referentes às features selecionadas. de uma forma abrangente. de acordo com as features selecionadas. ImageService. artefatos e implementações. buscando nestas implementações a funcionalidades ligadas às features. que consistem em Modo de Acesso. não terá critérios de segurança para acesso. que é apresentada por meio da Tabela 4.2.apache. é possível sumarizar os pontos de variação.4. Tipo de Mídia disponível para Visualização e Provedor de Stream de Vídeo. O objetivo desta análise é identificar os artefatos. que pode ser Texto (Text). Dessa forma. GREAT TOUR Segurança (Privacy). É utilizado o Java como linguagem de programação. Imagem (Image) ou Vídeo (Video). verificar a compatibilidade com o OSGi. Features Artefatos Privacy LoginService Show Document TextService. que determina se o acesso a aplicação será concedido por meio de Autorização (Authorization) que. Apache Axis1 como framework para construção de web services e o Apache Tomcat2 como servidor web. ExternalVideoProviderService Tabela 4. por meio de uma análise nas implementações dos artefatos.1. a Visualização de Documentos (Show Document).

4. Dessa forma. VideoService (LocalVideoProviderService e ExternalVideoProviderService) não possuem implementações compatíveis com OSGi.. A análise efetuada sobre estas implementações permitiu identificar os principais métodos utilizados para prover uma determinada funcionalidade. foi utilizado o Apache Maven3 3. Será apresentado na próxima seção a estratégia adotada nesta atividade.0. em seguida. Nesta etapa foram analisados estes casos de incompatibilidade. 2011. de modo que sejam empacotadas em bundles diferentes. 3 http://maven. mantendo suas funcionalidades externalizadas por meio de Serviços Web. que permitiu a configuração dos metadados do artefato de uma forma simples. tornando necessário a implementação de um componente OSGi capaz de prover este tipo de acesso aos serviços que serão migrados. 2011).apache. conforme apresentado na Figura 4. ImageService.org/site/apache-felix-maven-bundle-plugin-bnd. foi definida uma estratégia para efetuar a portabilidade da implementação atual para um modelo de implementação compatível com OSGi. percebeu-se que todos os serviços utilizam acesso a banco de dados para prover suas funcionalidades. determinar quais são os métodos que irão compor a API do serviço e verificar a existência de interação desses artefatos com componentes que não têm compatibilidade com OSGi.4 com o plugin “maven-bundle-plugin”4 . GREAT TOUR Por fim. é necessário que as implementações dos artefatos relacionados a estas features sejam portadas para o modelo de componentes OSGi.2. foi observado que os artefatos LoginService.4. TextService.apache. de Castro Alves. Esta estratégia é considerada uma boa prática (best practice) e provê uma maior flexibilidade a aplicação (Hall et al.html 53 .org/ 4 http://felix. ou seja. não é possível efetuar a implantação desses serviços em um container OSGi.3. Para efetuar a geração dos artefatos em arquivos JAR. Como parte dos resultados obtidos por meio desta análise. concluímos que as implementações não possuem compatibilidade com OSGi pois não estão implementados na forma de bundles.2.4 Modularizando Serviços De acordo com a análise efetuada na etapa anterior. para permitir a reconfiguração dinâmica das features por meio do DYMOS. A estratégia utilizada para efetuar a portabilidade consiste em separar Interfaces (API) e Implementações.

GREAT TOUR Figura 4.1. Para isso.2.6. o acesso é feito por meio de JDBC (Java Database Connectivity) com o driver versão 5.4.org/javadoc/r4v42/org/osgi/service/jdbc/DataSourceFactory. No componente MySQLServiceProvider. conforme apresentado na Figura 4. Será apresentado na próxima seção detalhes sobre a implementação do componente responsável por prover acesso ao banco de dados.4.com/ 6 http://www.mysql. foi implementado apenas a criação de conexões do tipo DataSource pois as operações efetuadas nas implementações atuais do artefatos não necessitam de suporte a pool de conexões ou transações. MySQLServiceProvider É definido por meio do OSGi Service Platform Release 4 um conjunto de especificações que permite a criação de conexões a banco de dados utilizando JDBC.osgi. Estas especificações estão contidas na API DataSourceFactory6 e definem métodos para criação de três tipos de conexão: DataSource. foi criada a classe MySQLDataSourceFactory que provê uma implementação que segue a especificação de DataSourceFactory. 5 http://www.html 54 . ConnectionPoolDataSource e XADataSource.3 MySQLServiceProvider: Dependência entre o Serviço Provedor de Conexões e os demais Serviços Modularizados O banco de dados utilizado é o MySQL5 5.

o método responsável pela criação de objetos DataSource é o “createDataSource”.2.4 MySQLDataSourceFactory: Fábrica de conexões MySQL utilizando JDBC Conforme é apresentado na Figura 4.5. então é necessário estabelecer uma forma de inicializar e finalizar a execução de cada componente individualmente. em seguida.4. que é responsável por gerenciar o ciclo de vida do componente. 55 .4. Em OSGi. foi utilizado o iPOJO na modularização dos componentes. É apresentado por meio da Figura 4. o objeto criado é retornado. GREAT TOUR Figura 4. uma aplicação pode ser composta por diferentes componentes. As propriedades são acessadas e utilizadas na criação do objeto DataSource e. Nesta avaliação. Este método recebe como parâmetro um objeto do tipo Properties contendo as propriedades necessárias para configurar e estabelecer uma conexão com o banco de dados. as configurações do componente MySQLServiceProvider e sua instância.

GREAT TOUR Figura 4. a configuração do MySQLDataSourceFactory como um componente iPOJO. LoginService Conforme já mencionado anteriormente.6 a especificação do componente LoginService. de modo que sejam empacotadas em bundles diferentes. que consiste em separar Interfaces (API) e Implementações. foram identificados os principais métodos utilizados para prover a função de autenticação na aplicação.5. a estratégia utilizada na modularização dos serviços é considerada uma boa prática. A descrição da tag “instance” permite a configuração da instância do componente. Isso permitiu determinar os métodos que irão compor a API do componente LoginService.5 MySQLDataSourceFactory: Configuração iPOJO do Componente e sua Instância Conforme é possível observar na Figura 4. 56 .2. consiste na definição das tag’s “component” e “instance”. indicando as propriedades e valores necessários para a sua instanciação. Serão apresentados na próxima seção detalhes sobre a modularização do serviço referente ao artefato de Privacidade (Privacy). Como parte do resultado da análise das implementações. e que irá direcionar a sua implementação. A descrição da tag “component” é efetuada indicando o nome do componente por meio do atributo “name” e a classe que provê a sua implementação por meio do atributo “classname”. É apresentado por meio da Figura 4.4.

6.6 LoginService: Especificação Conforme apresentado na Figura 4. GREAT TOUR Figura 4.4.7 LoginService: Configuração parcial do arquivo POM A configuração do componente (bundle) é efetuada no arquivo POM. indicando que suas funcionalidades estarão disponíveis na forma de serviços web. Figura 4. apresentado na Figura 4. que recebe como parâmetro o login e o password do usuário.7. foi definido como “bundle”.7 a configuração parcial do arquivo POM (Project Object Model).2. Os 57 . a especificação do componente recebe a anotação “@WebService”. O tipo de empacotamento do artefato é definido por meio da tag “packaging”. É apresentado por meio da Figura 4. O principal método identificado para prover a funcionalidade de autenticação foi o “auth”. que é utilizado pelo Apache Maven para gerenciar as dependências entre artefatos e efetuar a geração dos bundles. que por se tratar de um componente OSGi.

GREAT TOUR atributos groupId e artifactId são utilizados para determinar a identidade do artefato. indicando um valor para o atributo SymbolicName e o pacote exportado. em conjunto com o DataSourceFactory.8. LoginServiceProvider Após a definição da especificação do componente LoginService. é necessário prover uma implementação que possibilite determinar um comportamento para cada função. É apresentado por meio da Figura 4.8 LoginServiceProvider: Uma implementação para o LoginService 58 . Figura 4. juntamente com a sua versão (version).2. um resultado parcial da migração da implementação atual do artefato de Autenticação para o modelo de componente OSGi.4. Essas configurações permitem o empacotamento do bundle que contém a especificação do componente LoginService. Por meio do plugin “maven-bundle-plugin” é feita a configuração dos metadados do bundle. A implementação do componente LoginServiceProvider obedece as mesmas regras e utiliza as mesmas bibliotecas.

O serviço que deverá ser injetado nesta dependência é o MySQLServiceProvider. foram atribuídas à implementação as anotações “@Component”. a conexão é finalizada por meio do método “closeConn()”. que corresponde a uma fábrica de conexões do tipo DataSource. Por meio do atributo “dsf”.JDBC_URL. a partir deste. Por fim. com true caso a autenticação seja validada ou false caso contrário. e “@WebService”.2.8. O método “closeConn()” é utilizado para finalizar a conexão. é efetuada uma consulta no banco de dados por meio de uma conexão obtida com o método “openConn()”. que recebe como parâmetro o login e o password do usuário e é responsável por verificar a sua autenticidade. Os detalhes sobre os métodos “openConn()” e “closeConn()” são apresentados por meio da Figura 4. Para estabelecer uma conexão com o banco de dados. na operação de autenticação. recebeu a anotação “@Requires”.JDBC_USER e DataSourceFactory. que indica que o componente é responsável por prover um serviço. como DataSourceFactory. GREAT TOUR Conforme apresentado na Figura 4. de acordo com o serviço disponível no contexto OSGi. que provê uma implementação para esta fábrica de conexões.4. DataSourceFactory. Para permitir essa verificação. Com isso. é acessado o método “createDataSource” passando as propridades como parâmetro. uma conexão é estabelecida e atribuída ao atributo “connection” para que possa ser utilizado pelo método “auth”. 59 . é obtido um objeto DataSource e.JDBC_PASSWORD. O atributo “dsf” do tipo DataSourceFactory. A verificação é efetuada e em seguida é retornado um valor do tipo boolean. que define que a implementação corresponde a um tipo de componente. o principal método identificado para prover a funcionalidade de autenticação foi o “auth”. que indica que o componente deve estar disponível na forma de serviço web. Esta anotação determina uma dependência entre os serviços e permite que o framework efetue a injeção desta dependência. Conforme mencionado anteriormente.9. “@Provides”. por meio do método “openConn()” foram atribuídos valores para propriedades que são utilizadas para criar a conexão.

cxf.9 LoginServiceProvider: Métodos para estabelecer e finalizar uma conexão com o banco de dados É apresentado por meio da Figura 4.10 as informações utilizadas na configuração da instância do serviço.4. A configuração é efetuada por meio da definição de propriedades. que será publicado como um Serviço Web.interfaces” denota as interfaces Java que devem estar disponíveis remotamente. GREAT TOUR Figura 4.exported.10. 60 .apache.ws” foi atribuído a esta propriedade para indicar que o serviço deve ser disponibilizado na forma de Serviço Web. as propriedades definidas são: “service.2.10 LoginServiceProvider: Configuração de Instância Conforme a Figura 4.exported. O valor “org. O valor “*” foi atribuído a esta propriedade para indicar que todas as interfaces registradas no contexto OSGi estarão disponíveis. Figura 4.configs” especifica o mecanismo utilizado para disponibilizar o serviço. atribuição nome e valores para cada uma. “service.

address” especifica o endereço em que o serviço deve estar disponível.4. Figura 4. O valor “0. o valor “9090” indica a porta onde o serviço está em execução e “loginService” representa o nome de acesso do serviço. o artefato será empacotado como um bundle 61 . O iPOJO efetua a criação da instância e o Apache CXF utiliza as informações atribuídas na configuração para efetuar a publicação do Serviço Web.0:9090/loginService” foi atribuído a esta propriedade. de acordo com a Figura 4.cxf. indicando o endereço do serviço.2.apache.0” do endereço determina que o serviço estará acessível através de todas as interfaces de rede. Por fim. é efetuado a configuração do arquivo POM de modo a permitir o gerenciamento das dependências do componente e a geração do bundle referente ao LoginServiceProvider.0.11 LoginServiceProvider: Configuração parcial do arquivo POM Conforme apresentado na Figura 4. GREAT TOUR “org.11.0.11.ws.0. O valor “http://0.0.

5 Descrevendo Serviços e Variabilidades Nesta etapa foi efetuada a descrição dos serviços e variabilidades que compõem a configuração do GREat Tour. 62 . GREAT TOUR OSGi.4. A descrição destes elementos permite o gerenciamento dos serviços de modo a suportar variabilidades dinâmicas.com/dhiegoabrantes/dymos-evaluation-ws”. É apresentada na Figura 4. indicando um valor para o atributo SymbolicName e. A migração dos demais artefatos descritos na Seção 4. A dependência entre os artefatos é estabelecida pois o componente LoginServiceProvider provê uma implementação para o componente LoginService. que contém a implementação do componente LoginService. indicando o groupId.2. 4. Essas configurações permitem o empacotamento do bundle referente ao componente LoginServiceProvider. Por meio da tag “dependency” é estabelecida uma dependência com o artefato LoginService. Por meio do plugin “maven-bundle-plugin” é feita a configuração dos metadados do bundle.3 para o modelo de componentes OSGi seguiu a mesma estratégia utilizada na implementação dos componentes LoginService e LoginServiceProvider. de acordo com mudanças no ambiente.2.12 a descrição dos serviços que compõem a configuração do produto.2. As implementações referentes a estes artefatos estão disponíveis em “https://github. efetuando reconfigurações em tempo de execução. artifactId e version do componente. por meio do atributo Private-Package é determinada a remoção da visibilidade do pacote onde está localizada a implementação do serviço. assim como ocorreu com o componente LoginService.

TextServiceImpl"> <service-spec>br.assertlab.assertlab.dymos.ws.cin.dymos. e.assertlab. que possui a especificação definida por meio da interface LoginService e a implementação provida pela classe LoginServiceImpl.assertlab.12.cin. “localVideoService”. “imageService”. que possui a especificação definida por meio da interface ImageService e a implementação provida pela classe ImageServiceImpl.ufpe.ws. que também possui a especificação definida por meio da interface VideoService e a implementação provida pela classe ExternalVideoProviderServiceImpl.ws.cin.cin.ufpe.ws.cin.dymos.ws.4.cin.assertlab.LoginService</service-spec> </service> <service id="textService" service-impl="br.ImageServiceImpl"> <service-spec>br.ws. 63 .LoginServiceImpl"> <service-spec>br.dymos.ufpe. “textService”.12 GREat Tour: Descritor de Serviços Conforme a Figura 4.cin.ufpe.ws.assertlab. GREAT TOUR <?xml version="1.ufpe.dymos.cin.VideoService</service-spec> </service> <service id="externalVideoService" service-impl="br.assertlab.impl.ufpe. De acordo com a mesma figura.dymos.assertlab.ufpe.cin.LocalVideoProviderServiceImpl"> <service-spec>br.impl. os serviços descritos são relacionados aos artefatos identificados a partir da análise do modelo de features do GREat Tour.ufpe.dymos.ImageService</service-spec> </service> <service id="localVideoService" service-impl="br.dymos.ws.ufpe.ws.ufpe. Com isso.0"?> <services> <service id="loginService" service-impl="br.impl. quando houver uma requisição pelo serviço “externalVideoService” e houver indisponibilidade.dymos. o DS é composto por “loginService”.TextService</service-spec> </service> <service id="imageService" service-impl="br. que possui a especificação definida por meio da interface VideoService e a implementação provida pela classe LocalVideoProviderServiceImpl. que possui a especificação definida por meio da interface TextService e a implementação provida pela classe TextServiceImpl.dymos. É atribuído ao serviço “externalVideoService” o “localVideoService” como serviço alternativo.2.VideoService</service-spec> <alternative-service ref="localVideoService" priority="1" /> </service> </services> Figura 4.ws. por fim.assertlab.ExternalVideoProviderServiceImpl"> <service-spec>br.cin.assertlab. o “externalVideoService”.impl.impl.

2.13. definindo “textMedia” e “imageMedia” como variantes.4. É apresentado por meio da Figura 4. GREAT TOUR o serviço “localVideoService” deve ser selecionado. a descrição das variabilidades presentes na configuração do GREat Tour. que foram sumarizados por meio da análise do modelo de features. o ponto de variação “showDocument” recebe- 64 . De acordo com esta análise. “Tipo de Mídia disponível para Visualização” e “Provedor de Stream de Vídeo”. descrita na Seção 4. foram descritos os pontos de variação “privacy”. As variabilidades estão descritas de acordo com as features do produto e seus pontos de variação. Cada um dos pontos de variação são associados a variantes. que está relacionado a feature “Privacy”. Conforme a Figura 4. que recebeu como ID o nome da feature respectiva.13 GREat Tour: Descritor de Variabilidades Os pontos de variação são descritos por meio da tag “variability”. que são descritas por meio da tag “variant”.13. os pontos de variação sumarizados consistem em “Modo de Acesso”.2. que está relacionado a feature “Show Document”.2. <?xml version="1. definindo “authentication” como uma variante.0"?> <variabilities> <variability id="privacy"> <variant id="authentication"> <service-ref ref="loginService" /> </variant> </variability> <variability id="showDocument"> <variant id="textMedia"> <service-ref ref="textService" /> </variant> <variant id="imageMedia"> <service-ref ref="imageService" /> </variant> </variability> <variability id="video"> <variant id="localVideo"> <service-ref ref="localVideoService" /> </variant> <variant id="externalVideo"> <service-ref ref="externalVideoService" /> </variant> </variability> </variabilities> Figura 4. “showDocument”. De acordo com o modelo de features.

Posteriormente. 4. e informações a respeito de outras pessoas presentes na mesma sala em que o visitante se encontra. De acordo com esta análise foi possível perceber a ausência de algumas features que estão presentes no GREat Tour como “Privacy” e “Video”. o que a torna uma aplicação de menor porte. 65 . que seria o provedor de stream de vídeo. 4. Será apresentado nesta seção as etapas executadas na avaliação do uso do DYMOS para permitir variabilidades dinâmicas no CIn Tour. necessitando apenas o ajuste dos Descritores de Serviços e Variabilidades. Na Seção 4. As etapas executadas serão detalhadas nas próximas seções. O seu comportamento se adapta de acordo com o contexto atual do visitante. que está relacionado a feature “Video”. A aplicação é executada no dispositivo móvel do visitante e fornece informações sobre os pesquisadores e ambientes do laboratório que são visitados.4. evidenciando que o CIn Tour possui um número menor de features. de acordo com a configuração do CIn Tour. na Seção 4. o “video”. CIN TOUR ria uma terceira variante. Esta aplicação foi implementada para auxiliar visitantes a conhecer o CIn (Centro de Informática) da Universidade Federal de Pernambuco. é possível ambos possuam features em comum. que abrange a localização do visitante.4 será detalhado a análise e adequação da aplicação para notificar o DYMOS sobre mudanças no ambiente e utilizar a função de descoberta de serviços. assim como o GREat Tour.1 Analisando o Modelo de Features Esta etapa consistiu em analisar o modelo de features do CIn Tour com a finalidade de identificar features e pontos de variação em comum com o modelo de features do GREat Tour.3. Dessa forma. como esta variante pode ser alternada entre um provedor local ou externo.3. as características do seu dispositivo móvel.3 CIn Tour O CIn Tour é um Guia de Visitas Móvel e Sensível ao Contexto criado a partir da MobiLine. foi decidido a decompor em um novo ponto de variação. definindo “localVideo” e “externalVideo” como variantes.5 será feita uma discussão sobre os resultados obtidos por meio desta avaliação. seu perfil ou preferências. é esperado como resultado desta avaliação a possibilidade de reuso dos artefatos migrados para o GREat Tour. Como o CIn Tour e o GREat Tour são derivados da mesma LPS. No entanto.

que consistem em funcionalidades referentes a Visualização de Documentos (Show Document). de acordo com estas features. Na próxima seção serão apresentadas as descrições dos serviços e variabilidades do CIn Tour. de acordo com os artefatos reutilizados do GREat Tour. que consiste no Tipo de Mídia disponível para Visualização. que pode ser Texto (Text) ou Imagem (Image).14 é possível visualizar as features em comum. Figura 4. CIN TOUR Por meio da Figura 4.14 CIn Tour: Modelo de Feature Parcial No modelo apresentado por meio da Figura 4. 66 . que especifica o tipo de mídia que estará disponível para visualização.3. Dessa forma.14 é apresentado de forma parcial o modelo de features do CIn Tour.4. de acordo com as features identificadas. é possível sumarizar um único ponto de variação.

67 . De acordo com esta análise.13.ufpe. efetuando reconfigurações em tempo de execução.4.ws. É apresentado na Figura 4.assertlab. de acordo com mudanças no ambiente.TextServiceImpl"> <service-spec>br.assertlab.dymos. descrita na Seção 4.ws.15.cin.cin.ImageServiceImpl"> <service-spec>br. que possui a especificação definida por meio da interface TextService e a implementação provida pela classe TextServiceImpl.assertlab.2 Descrevendo Serviços e Variabilidades Nesta etapa foi efetuada a descrição dos serviços e variabilidades que compõem a configuração do CIn Tour.dymos.3.ws. e “imageService”.3. os serviços descritos são relacionados aos artefatos ligados às features identificadas a partir da análise do modelo de features do CIn Tour.cin.TextService</service-spec> </service> <service id="imageService" service-impl="br.dymos.ImageService</service-spec> </service> </services> Figura 4.ufpe.dymos.1. CIN TOUR 4. o DS é composto por “textService”.15 CIn Tour: Descritor de Serviços Conforme a Figura 4.impl.ufpe.3. foi possível sumarizar apenas um ponto de variação que consiste em “Tipo de Mídia disponível para Visualização”.cin.ws. a descrição das variabilidades presentes na configuração do CIn Tour. A descrição destes elementos permite o gerenciamento dos serviços de modo a suportar variabilidades dinâmicas.15 a descrição dos serviços que compõem a configuração do produto. De acordo com a mesma figura.impl. que foram sumarizados por meio da análise do modelo de features.assertlab. As variabilidades estão descritas de acordo com as features do produto e seus pontos de variação. <?xml version="1.ufpe. É apresentado por meio da Figura 4.0"?> <services> <service id="textService" service-impl="br. que possui a especificação definida por meio da interface ImageService e a implementação provida pela classe ImageServiceImpl.

A utilização desta biblioteca permite a integração entre a aplicação cliente e o DYMOS.13. que consiste na reconfiguração de variabilidades dinâmicas e descoberta de serviços. definindo “textMedia” e “imageMedia” como variantes. na Seção 4. Como resultado desta análise.5 será feita uma discussão sobre os resultados obtidos por meio desta avaliação. foi necessário analisar as implementações da aplicação de modo a determinar como a adequação seria possibilitada. foi descrito o ponto de variação “showDocument”. que provê a possibilidade da aplicação cliente utilizar as funções providas pelo DYMOS. Inicialmente foi analisado a forma como ocorria a interação entre a aplicação cliente e os serviços. observou-se que a aplicação utiliza a plataforma Android e que para cada serviço utilizado existe uma classe correspondente. A biblioteca desenvolvida é considerada leve por ser composta basicamente por classes como “VariabilityContext”. que permite o suporte a reconfiguração de variabilidades dinâmicas e o “ServiceEndpointFactory”. a fim de utilizar as principais funcionalidades providas. ANALISANDO E INTEGRANDO A APLICAÇÃO CLIENTE <?xml version="1. Para permitir a integração entre a aplicação e o DYMOS. foi desenvolvida uma biblioteca Java. 4. que está relacionado a feature “Show Document”. 68 .4 será detalhado a análise e adequação da aplicação para notificar o DYMOS sobre mudanças no ambiente e utilizar a função de descoberta de serviços. Para efetuar a integração. Posteriormente.4.4.0"?> <variabilities> <variability id="showDocument"> <variant id="textMedia"> <service-ref ref="textService" /> </variant> <variant id="imageMedia"> <service-ref ref="imageService" /> </variant> </variability> </variabilities> Figura 4.4 Analisando e Integrando a Aplicação Cliente Será descrito nesta seção as etapas executadas para permitir a integração das aplicações cliente. Na Seção 4. denominada “DymosClientLib”. que permite o suporte a descoberta de serviços. com o DYMOS. GREat Tour e CIn Tour.16 CIn Tour: Descritor de Variabilidades Conforme a Figura 4.

4.4. ANALISANDO E INTEGRANDO A APLICAÇÃO CLIENTE

Por exemplo, a interação com o serviço de autenticação do usuário é intermediada pela
classe “LoginWS”. Também foi possível observar a utilização da biblioteca kSOAP7
para estabelecer a comunicação entre aplicação e serviço. Dessa forma, a classe “LoginWS” recebe requisições por meio de seus métodos e, utilizando o kSOAP, estabelece
uma comunicação com o serviço a fim de obter uma resposta para a requisição recebida.
Conforme é possível observar no item “1” da Figura 4.17, são declarados os atributos
referentes ao serviço. Estes atributos são utilizados para estabelecer uma comunicação
com o serviço e, de acordo com a figura, são definidos de uma forma fixa, por meio de
constantes. É demonstrado no item “2” desta mesma figura, a utilização destes atributos
na criação de instâncias de objetos da biblioteca kSOAP.

Figura 4.17 Aplicação Cliente: Declaração de constantes e Interação com Serviço

Conforme descrito na Seção 3.4.2, quando é executada uma operação de descoberta
de serviço, é obtido como resposta um valor que corresponde a uma referência para o serviço solicitado e que obedece o seguinte formato “serviceEndpoint;targetNamespace;serviceName”.
De modo a facilitar a manipulação das informações sobre a referência do serviço, o valor
obtido como resposta é encapsulado em um objeto. Este objeto é modelado pela classe
“ServiceEndpoint” presente na “DymosClientLib” e possui os atributos “endpoint”,
“namespace” e “serviceName”.
A integração com o DYMOS de modo a utilizar a funcionalidade de descoberta de
serviços foi possibilitada por meio da substituição das constantes declaradas na Figura
4.17 pela declaração do atributo “endpoint” do tipo “ServiceEndpoint”, conforme o
item “1” da Figura 4.18. De acordo com o item “2”, a referência para o serviço é atu7 https://code.google.com/p/ksoap2-android/

69

4.5. CONSIDERAÇÕES FINAIS

alizada antes de cada execução, utilizando o método “getEndpoint” da classe “ServiceEndpointFactory”, informando o ID do serviço requerido. Posteriormente, as informações são utilizadas para estabelecer uma comunicação com o serviço e executar uma
determinada operação.

Figura 4.18 Aplicação Cliente: Descoberta de Serviço por meio da biblioteca “DymosClientLib”

A integração com o DYMOS de modo a utilizar a funcionalidade de reconfiguração
de variabilidades foi possibilitada por meio dos métodos “activate” e “deactivate” da
classe “VariabilityContext”, informando o ID da variante afetada. É apresentado por
meio da Figura 4.19 um exemplo de utilização destes métodos, efetuando um reconfiguração de variabilidades por meio da ativação e desativação de features.

Figura 4.19 Aplicação Cliente: Reconfiguração de variabilidades por meio da biblioteca “DymosClientLib”

A utilização destes métodos foram inseridas em pontos de adaptação das aplicações
GREat Tour e CIn Tour.

4.5

Considerações Finais

Foi apresentado neste capítulo uma avaliação preliminar que demonstra a aplicação da
abordagem proposta neste trabalho em dois produtos derivados de uma mesma LPS,

70

4.5. CONSIDERAÇÕES FINAIS

o GREat Tour e o CIn Tour, de modo a permitir a reconfiguração de variabilidades
dinâmicas nestes produtos. Adicionalmente, foram demonstradas as etapas e definições
iniciais que guiaram a execução desta avaliação.
Os produtos utilizados nesta avaliação implementavam uma arquitetura de LPS que
não possuia suporte a tecnologia OSGi. Dessa forma, foi necessário um esforço inicial para efetuar a modularização das implementações, executando a portabilidade dos
serviços para um modelo de implementação compatível com OSGi.
Foi possível perceber a viabilidade na utilização da abordagem proposta para permitir reconfiguração de variabilidades dinâmicas, por meio de operações de Reconfiguração e Descoberta de Serviços. Adicionalmente, conclui-se que os serviços modularizados podem ser reutilizados por outros produtos da mesma LPS, facilitando a adoção
desta abordagem para outros produtos e proporcionando ganhos em custo e tempo de
entrega.
Serão apresentadas no próximo capítulo as considerações finais deste trabalho, destacando as principais contribuições e trabalhos futuros.

71

1 Contribuições Como resultado deste trabalho. uma plataforma de reconfiguração de variabilidades dinâmicas e descoberta de serviços para Linhas de Produto de Software Orientado a Serviços e Sensível ao Contexto. de uma forma desacoplada. Neste trabalho foram investigadas situações em que há reconfiguração de features que estão na aplicação cliente e que. utilizam serviços.5 Conclusão Um passo à frente e você não está mais no mesmo lugar One step forward and you are not in the same place —CHICO SCIENCE (Um Passeio No Mundo Livre. foi proposta uma solução para prover. é possível obter vantagens como Gerência de Variabilidade de uma forma leve e simples. para prover suas funcionalidades. é possível destacar como principais contribuições: • DYMOS Framework: Por meio do DYMOS Framework. Afrociberdelia) O paradigma de Linhas de Produto de Software Dinâmicas envolve aspectos sobre o desenvolvimento de Sistemas Sensíveis ao Contexto utilizando abordagens de Linhas de Produto de Software. de uma forma desacoplada e independente. A gerência de variabilidades dinâmicas é um desafio que está endereçado ao paradigma de Linhas de Produto de Software Dinâmicas e diversas abordagens são propostas e contribuem para a evolução deste paradigma. foi possível prover. 5. uma plataforma de reconfiguração de variabilidades dinâmicas e descoberta de serviços para Linhas de Produto de Software Orientado a Serviços e Sensível ao Contexto. 72 . Por meio da utilização do framework. Dessa forma.

de modo que possibilite a implementação de componentes responsáveis por selecionar um serviço de acordo com o seu próprio critério. • Avaliação Preliminar: A execução da Avaliação Preliminar nos permitiu averiguar a utilidade e efetividade da solução proposta neste trabalho. • Atualmente.2. que permite agregar critérios para a seleção do serviço mais adequado. que utiliza como critério de seleção a disponibilidade do serviço com base em uma prioridade definida pelo usuário.2 Trabalhos Futuros Algumas limitações de abordagens atuais são endereçadas neste trabalho. Este componente será utilizado para avaliar o item descrito anteriormente. • Pretende-se desenvolver um componente de descoberta e seleção de serviços com base em atributos de qualidade. também passaram a tratar reconfigurações de componentes. Como parte da avaliação. Então. modelar e implementar estes serviços seguindo o modelo de implementação OSGi. Planeja-se investigar a modularização da funcionalidade de Descoberta de Serviços em um novo componente. permite a importação e utilização de um serviço que está publicado e em execução em container OSGi diferentes. por meio do OSGi Distribuído. pretendemos avaliar o uso do DYMOS Framework na reconfiguração de variabilidades dinâmicas que endereçam serviços distribuídos. em seguida. DYMOS Framework permite a descoberta de serviços. Os Sistemas derivados da LPS MobiLine. Isto irá permitir a troca de componentes de descoberta de serviços em tempo de execução. foi necessário analisar implementações de serviços legados e. no entanto. além de continuar tratando reconfigurações comportamentais. possibilitando prover novos critérios de seleção sem afetar a execução da aplicação. TRABALHOS FUTUROS Mecanismo de Descoberta de Serviço. novas questões surgiram durante o tratamento destas limitações. foram adaptados para utilizar o DYMOS Framework e. Com isso. Funcionalidades Interoperáveis por meio de Serviços Web. 5. tais questões devem ser tratadas como trabalhos a serem executados no futuro: • O Apache CXF. de acordo com uma requisição. com isso. GREat Tour e CIn Tour. 73 .5.

2. G.. Context-aware autonomous web services in software product lines. 53 74 . (2010). S. Documenting software architectures: views and beyond. In Information and Communication Technologies.. SPLC’05. E. 15 Carter.. 17 Clements. (2012). tools. P. 2009. and Ramalho. 13. P. N. MA. 9. Cole. 2nd. (2011). 2006. Manning Publications Co. and Santana de Almeida. (2005).. and Northrop. S. Boston. Matos. 25th International Conference on. 43 Ali. and Jantan. 51 de Castro Alves. Inc. SEAA ’09. (2001). S.. IBM Press. CT. 45(10). ICTTA ’06. P. pages 740–741. 28 Czarnecki. V..0. Proceedings. R. In Software Engineering and Advanced Applications. M.. SpringerVerlag. A. Berlin. (2003). pages 70–81. 4. and Stafford. (2007). Heidelberg. In Proceedings of the 9th international conference on Software Product Lines. 1. N. 35th Euromicro Conference on. J. and Eisenecker. A view of the dynamic software product line landscape. The New Language of Business: SOA e Web 2. Addison Wesley.Referências Alferez. Modeling service oriented architectures of mobile applications by extending soaml with ambients. K. V. R. and applications. 36–41. 22 Alhazbi. Addison-Wesley Longman Publishing Co. D. P. 3 Alves. USA. 2011 15th International. and Pelechano.. pages 442–449. (2009). Little. Hallsteinsen. 1st edition. Extracting and evolving mobile games product lines. Borba. Computer. 27... 2003. (2011). and Hallsteinsen. 15 Bencomo. Generative programming: methods.. 2. 14 Bencomo. S. Lee. and Babar. N. U.. Greenwich. pages 61–68. G. OSGi in Depth. Garlan. L. L. (2006). 12. In Software Product Line Conference (SPLC)... USA. J. (2000). pages 100–109. Nord. 14 Clements. How dynamic is your dynamic software product line? In SPLC Workshops. Software Product Lines: Practices and Patterns.. pages 2889–2892. 15. volume 2. A. In Software Engineering. O. Multi-level mediator-based technique for classes hot swapping in java applications.

Johnson. Design patterns: elements of reusable object-oriented software. 19 75 . H.. R. C. P. (2013). and Pahl. P.. J. Manning Publication Co. 103–108. Prentice Hall PTR. 19 Erl.. Service-oriented technology and management: Perspectives on research and practice for the coming decade. M. Krogdahl.. 47(8). 2 Dhungana. A. 17. P.. pages 47–52. 3. J. A. J. Patterns: Service-Oriented Architecture and Web Services.-G. Addison-Wesley Longman Publishing Co. NJ. and Design. Kauffman. (2004). ipojo: an extensible service-oriented component framework. SOA Governance in Action: REST and Web Service architecture. 4. (1995). 7(4). J.. 16 Endrei. Electron. Luo. 2. and Layzell. 44 Garcia-Gonzalez. 21. In SPLC Workshops. (2010). T.. 2007. Shelter Island. NY 11964. (2007). D. Vayghan. J.. H. MA.. Upper Saddle River. R. V.. 16. Comte. 1. 18.. P. Domain-specific adaptations of product line variability modeling. Commun. A. T. SOA Principles of Service Design (The Prentice Hall Service-Oriented Computing Series from Thomas Erl). P. Inc. pages 238–251. Upper Saddle River. Ang. Negotiating in service-oriented environments. Helm. 28 Galster. 17 Erl. In Services Computing. 18. (2004). Boston. (2010). SCC 2007. Chua. (2007). Technology. USA. C. S.. Service registry: A key piece to enhance reuse in soa. USA. The Architecture Journal.REFERÊNCIAS Demirkan. pages 474–481. 19 Gamma. Appl.. Gacitua-Decar. Grünbacher... 24 Escoffier. Fill. T. IBM Redbooks. P.. E. 24. NJ. and Rabiser. Enhancing runtime variability in software product lines through service-orientation. 15 Dirksen. ACM. R. D. Karagiannis. 5. R. 2. M. J.. (2007).... P. Service-Oriented Architecture: Concepts. In Situational Method Engineering. (2005). and Maglio. USA. R. and Lalanda.. Rec. and Vlissides. 22. 17 Elfatatry.. M. Prentice Hall PTR. Commer. Arsanjani. IEEE International Conference on.... and Newling. (2008). Hall. 15. 356–376.

39 Kim.. 38 Istoan. NY. G. G. Washington. Dynamic software adaptation for service-oriented product lines. J. P. 2. (2010). S. USA. (2008). 19 Khezrian.. 41(4). 37 Hallsteinsen. M. Addison Wesley Longman Publishing Co. O’Reilly Media.. DEAS ’05. S. N. Manning Publications Co. (2011). 1. M.. Hinchey.. (2004). CT. USA. In Proceedings of the 2005 workshop on Design and evolution of autonomic application software. 15. In Proceedings of the 2009 Ninth IEEE International Conference on Computer and Information Technology .REFERÊNCIAS Gomaa.. H. Perrouin.. McCulloch... M. and Savage. J. A. 9 Gomaa. (2009). CA. and Jezequel. J. OSGi in Action: Creating Modular Applications in Java. 15. Munusamy. 24 76 . An evaluation of state-of-the-art approaches for web service selection. Park. E. 93–95. pages 885–889. 1st edition. IEEE Computer Society. and Floch. iiWAS ’10.–150. S... ACM. DC. Solberg. Using product line techniques to build adaptive systems. ACM. pages 35:1–35:8. W.. 1. H. USA. (2007). In Proceedings of the 15th International Software Product Line Conference. pages 193–198. Greenwich...Volume 02. 4. New York. and Park. New York. 27. S. Nain. 1. 2006 10th International.-M. 5. Computer.. S. R. and Hashimoto. Services. CIT ’09. Inc. In Proceedings of the 12th International Conference on Information Integration and Web-based Applications &#38. USA. and Schmid. D. Wan Kadir. K. Dynamic software product lines. M.. 2. Jeong. (2005). NY. 2. Redwood City. New York. pages 1–7. Mohebbi. S. K. Soa in Practice: The Art of Distributed System Design. K.. ACM. 4.. 24. USA. K. Stav. Dynamic software product lines for service-based systems. Pauls.. NY. In Software Product Line Conference. and Tabatabaei. 19 Josuttis. Volume 2.. K. H. (2006). 53 Hallsteinsen. Inc. From product lines to self-managed systems: an architecture-based runtime reconfiguration framework.. Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures. N. G. S. SPLC ’11. 15. (2011). Ibrahim. pages 10 pp. 23 Hall. USA..

Obbink. K. and Rommes. (2000). P.. (2002). Springer Berlin Heidelberg. security. Tyagi. Mao. (0). S. d. In J. 2 Linden.. Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering. 49–55. Rausch. (2003). F.REFERÊNCIAS Kon. Java Web Services Architecture. Monitoring. pages 121–143. F. 19 Microsoft Corporation (2005).. 23(2). and Robinson... S. IEEE. and Mathew. S.. and future for software architecture. J. 2009. Third IEEE International Conference on.a runtime testing approach. pages 186–197.. (2010). 13. W.. S. v. R... M. H. D. R. Sventek and G. L. and Schmid.putting both together. Service-oriented architectures and software product lines . G.. F. (2012). 29–31. and Campbell. Inc. 3. Viana... Maia. Yamane. J. (2012). 18 Niebuhr. 14 Marinho. Liu. and Aguiar. Lima. Andrade. and Cohen. volume 1795 of Lecture Notes in Computer Science... Werner. Engineering service-based dynamic software product lines. 13. 2. E. M.. Coulson. J. 19(4). E. Computer.. R. J. 3 Kruchten. 19 Medeiros. editors. J. Stevens. (2006). E. F. Achieving dependable component bindings in dynamic adaptive systems .. Teixeira. C. C. and dynamic configuration with the dynamictao reflective orb. B. Kotonya. present. Eliminating the adoption barrier. Schmid. In SPLC. T. Reichmann. NJ. M. R.. C. Software. The past. IEEE. Sople-de: An approach to design service-oriented product line architecture.. USA. In Self-Adaptive and Self-Organizing Systems. and Stafford. Software. S. Elsevier Science. 45(10).. (2008). D.. G... 48. 49 McGovern. Web services dynamic discovery (ws-discovery). M. 14 Krut. SASO ’09. Filho. L. Science of Computer Programming... J. V. 22–30. Middleware 2000. 16 Lee. Springer-Verlag New York. F. Dantas. 28 Krueger. 11. P.. Secaucus. J. A. M. 17. Magalhães. (2009). page 383.. Román. F. Rocha. Mobiline: A nested software product line for the domain of mobile and context-aware applications. Klein. 1 77 . 10. L.. (2007)..

18 Parra. Washington. Medvidovic. (2011). 34. Kyoto. J. M.. d. 3. Intelligent Systems and their Applications. Principles and Techniques. Introduction: Service-oriented computing. Quilici. F. ERCIM News. T. Böckle. C. Pukall. 24–28.. DC. J. Siegmund. An architecture-based approach to selfadaptive software. 54–62. N. Context awareness for dynamic serviceoriented product lines. and Taylor. B. S. Tailoring dynamic software product lines. 14 78 . R. Commun. Heimhigner. (2007).. G. 14. pages 177–186. Machado. NJ... H.1st International Workshop on Service Oriented Architectures and Product Lines (SOAPL ’07). USA. (2003). C. In Proceedings of 21st Brazilian Symposium on Software Engineering (SBES-XXI). M. Quinton. An approach to implement core assets in service-oriented product lines... Capucine: Context-aware serviceoriented product line for mobile apps. G. N. A. Medvidovic. A.. SPLC ’09. and Apel. 19 Ribeiro. 4. In Proceedings of the 13th International Software Product Line Conference. In In Proceedings of the 11th International Software Product Line Conference (SPLC ’07) . 48 Raatikainen. 16. Springer-Verlag New York. Pittsburgh. M. 3 Pohl. V. 1. 3–12. v.. USA. D. (2012). A. Johnson. C. 3 Rosenmüller.. D. and Duchien. Gorlick. and Duchien. (1999). Blanc. USA. Using dynamic reconfiguration and context notification for ubiquitous software development. P. 1. IEEE Computer Society. G. (2005). 14(3). (1998). L. Taylor.. Castro. Secaucus. 11. C. Software Product Line Engineering: Foundations. P.. N. 46(10). M. 22 Parra. IEEE. (2010).. (2009). 24 Papazoglou. PA. L. S. Architecture-based runtime software evolution.. M. D.. ICSE ’98. M. ACM. 2012(88). 2... 43 Oreizy. and Linden. 12. SIGPLAN Not. 47(3). R.. Carnegie Mellon University. 10. K. pages 219–235. 15. and Mannisto. R. In Proceedings of the 20th international conference on Software engineering... 13. N. and Wolf. and Georgakopoulos. 16. Inc. L. P. 21.. pages 131–140. (2007).REFERÊNCIAS Oreizy. X. Japan. Comparison of service and software product family modeling.. and Andrade... Rosenblum. 19 Rocha..

and Garcia. In In Proceedings of the 11th International Software Product Line Conference (SPLC ’07) . Ruiz-Cortés. M. and Khan. Silva. 3 79 ... Carleton University. Benavides. (2001). 81(3). San Francisco..REFERÊNCIAS Segura. C. USA. D. 43 Tiwari. Master’s thesis. A. NJ. (2007). USA. Nascimento. (2007). Rathore. F.. Japan.... L. 15. A. A. W. Journal of Systems and Software. C. Ottawa. Kyoto. Xmobile: A mb-uid environment for semiautomatic generation of adaptive applications for mobile devices. 19 Shaw. Product lines that supply other product lines: A service-oriented approach. and Garlan. R. Prentice-Hall. S. pages 1–10.. V. A. The Dynamic Aspects of Product Derivation in DSPL: a Systematic Literature Review. D. pages 466–473. G. <ce:title>Selected Papers from the 2006 Brazilian Symposia on Databases and on Software Engineering</ce:title>. S. Proceedings of the 2013 IEEE 14thInternational Conference on Information Reuse and Integration. 22 Smith. 382 – 394. In Software Engineering (CONSEG). Selecting requirement elicitation techniques for software projects. S. 28 Silva. P. 2011 International Conference on. D. Software architecture: perspectives on an emerging discipline. O. 26 Viana. F. (2011). Martins. 19 Tan. 15. L. Iqbal.. (2008). M. Japan. Service-oriented architecture (soa) and software product lines: Preimplementation decisions. Kyoto. 2. D. 26 Trujillo. pages 333–340. (2009). 2. S. P. Department of System and Computer Engineering. A survey on issues in non-functional requirements elicitation. In In Proceedings of the 13th International Software Product Line Conference (SPLC ’09) . CA. S. (2013). and Trinidad. Upper Saddle River.1st International Workshop on Service Oriented Architectures and Product Lines (SOAPL ’07). and Gupta. Inc.. A taxonomy of variability in web service flows.. A. 2012 CSI Sixth International Conference on. 19 Ullah. and Andrade.3st International Workshop on Service Oriented Architectures and Product Lines (SOAPL ’09). and Kaestner. M. Canada. S. (2012). R.. M. In Service Oriented Architectures and Product Lines (SOAPL ’07). (1996).. In Computer Networks and Information Technology (ICCNIT). 2. and Lewis. J. A. SwapBox: a Hot-Swapping Framework for Swappable JavaBeans.

22 Zi-yun. P. J.. 15 Ye. and Bourret. pages 999– 1002. K. (2007). Lalanda. Y. P. Supporting runtime system adaptation through product line engineering and plug-in techniques. 2. E. ICCBSS 2008.REFERÊNCIAS Wolfinger.. Moon. (2008). The 9th International Conference on. In Non Functional Properties and Service Level Agreements in Service Oriented Computing Workshop co-located with The 6th IEEE European Conference on Web Services. pages 1–3. pages 51–58. An approach for dynamically building and managing service-based applications. 19 Yu. (2010). 19. 2. 17 80 .. Dhungana. 47 Yu. R. Q.. Seventh International Conference on. 2011 International Conference on. In Services Computing Conference (APSCC). H.. volume 2. Kim. S. 39. In Composition-Based Software Systems. In Advanced Communication Technology.. In Computer and Management (CAMAN). D. H.. 2010 IEEE Asia-Pacific. Grunbacher. Reiter. and Ru-long. Non-functional property based service selection: A survey and classification of approaches. D. W. P. M. and Prahofer.. pages 21–30. An approach to designing serviceoriented product-line architecture for business process families.. 2008. and Reiff-Marganiec. (2008). 2. (2011). S. Efsm task scheduling model research in the soa integration platform. and Yeom.

Apêndice 81 .

A Componentes Descritores A.1 Descritor de Serviços Abaixo é apresentado a definição da estrutura de metadados referente ao Descritor de Serviços. <?xml version="1.org/2001/XMLSchema"> <xsd:element name="services"> <xsd:complexType> <xsd:sequence> <xsd:element maxOccurs="unbounded" minOccurs="1" ref="service" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="service"> <xsd:complexType> <xsd:sequence> <xsd:element name="service-spec" type="xsd:string" /> <xsd:element maxOccurs="unbounded" minOccurs="0" ref="alternative-service" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:string" use="optional" /> <xsd:attribute name="service-impl" type="xsd:string" use="optional" /> </xsd:complexType> </xsd:element> <xsd:element name="alternative-service"> <xsd:complexType> <xsd:attribute name="ref" type="xsd:string" use="optional" /> <xsd:attribute name="priority" type="xsd:string" use="optional" /> </xsd:complexType> </xsd:element> </xsd:schema> 82 .w3.0" encoding="ISO-8859-1"?> <xsd:schema xmlns:xsd="http://www.

<?xml version="1.2.org/2001/XMLSchema"> <xsd:element name="variabilities"> <xsd:complexType> <xsd:sequence> <xsd:element maxOccurs="unbounded" minOccurs="1" ref="variability" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="variability"> <xsd:complexType> <xsd:sequence> <xsd:element maxOccurs="unbounded" minOccurs="1" ref="variant" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:string" use="required" /> <xsd:attribute name="name" type="xsd:string" use="optional" /> </xsd:complexType> </xsd:element> <xsd:element name="variant"> <xsd:complexType> <xsd:sequence> <xsd:element maxOccurs="unbounded" minOccurs="1" ref="service-ref"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:string" use="required" /> <xsd:attribute name="name" type="xsd:string" use="optional" /> </xsd:complexType> </xsd:element> <xsd:element name="service-ref"> <xsd:complexType> <xsd:attribute name="ref" type="xsd:string" use="optional" /> </xsd:complexType> </xsd:element> </xsd:schema> 83 .0" encoding="ISO-8859-1"?> <xsd:schema xmlns:xsd="http://www.w3.A.2 Descritor de Variabilidades Abaixo é apresentado a definição da estrutura de metadados referente ao Descritor de Variabilidades. DESCRITOR DE VARIABILIDADES A.

DESCRITOR DE WSDL A.xmlsoap.3.xmlsoap.org/2001/XMLSchema" xmlns:wsdl="http://schemas. </xs:documentation> </xs:annotation> <xs:sequence> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xs:sequence> </xs:extension> 84 .w3.A. <xs:schema xmlns:xs="http://www. </xs:documentation> </xs:annotation> <xs:anyAttribute namespace="##other" processContents="lax" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tExtensibleDocumented" abstract="true"> <xs:complexContent> <xs:extension base="wsdl:tDocumented"> <xs:annotation> <xs:documentation> This type is extended by component types to allow elements from other namespaces to be added.org/wsdl/" targetNamespace="http://schemas.org/wsdl/" elementFormDefault="qualified"> <xs:complexType mixed="true" name="tDocumentation"> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xs:sequence> </xs:complexType> <xs:complexType name="tDocumented"> <xs:annotation> <xs:documentation> This type is extended by component types to allow them to be documented </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="documentation" type="wsdl:tDocumentation" minOccurs="0" /> </xs:sequence> </xs:complexType> <xs:complexType name="tExtensibleAttributesDocumented" abstract="true"> <xs:complexContent> <xs:extension base="wsdl:tDocumented"> <xs:annotation> <xs:documentation> This type is extended by component types to allow attributes from other namespaces to be added.3 Descritor de WSDL Abaixo é apresentado a definição da estrutura de metadados referente ao Descritor de WSDL.

DESCRITOR DE WSDL </xs:complexContent> </xs:complexType> <xs:element name="definitions" type="wsdl:tDefinitions"> <xs:key name="message"> <xs:selector xpath="wsdl:message" /> <xs:field xpath="@name" /> </xs:key> <xs:key name="portType"> <xs:selector xpath="wsdl:portType" /> <xs:field xpath="@name" /> </xs:key> <xs:key name="binding"> <xs:selector xpath="wsdl:binding" /> <xs:field xpath="@name" /> </xs:key> <xs:key name="service"> <xs:selector xpath="wsdl:service" /> <xs:field xpath="@name" /> </xs:key> <xs:key name="import"> <xs:selector xpath="wsdl:import" /> <xs:field xpath="@namespace" /> </xs:key> </xs:element> <xs:group name="anyTopLevelOptionalElement"> <xs:annotation> <xs:documentation> Any top level optional element allowed to appear more then once .any child of definitions element except wsdl:types.A. Any extensibility element is allowed in any place. </xs:documentation> </xs:annotation> <xs:choice> <xs:element name="import" type="wsdl:tImport" /> <xs:element name="types" type="wsdl:tTypes" /> <xs:element name="message" type="wsdl:tMessage"> <xs:unique name="part"> <xs:selector xpath="wsdl:part" /> <xs:field xpath="@name" /> </xs:unique> </xs:element> <xs:element name="portType" type="wsdl:tPortType" /> <xs:element name="binding" type="wsdl:tBinding" /> <xs:element name="service" type="wsdl:tService"> <xs:unique name="port"> <xs:selector xpath="wsdl:port" /> <xs:field xpath="@name" /> </xs:unique> </xs:element> </xs:choice> </xs:group> <xs:complexType name="tDefinitions"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleDocumented"> 85 .3.

DESCRITOR DE WSDL <xs:sequence> <xs:group ref="wsdl:anyTopLevelOptionalElement" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="targetNamespace" type="xs:anyURI" use="optional" /> <xs:attribute name="name" type="xs:NCName" use="optional" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tImport"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleAttributesDocumented"> <xs:attribute name="namespace" type="xs:anyURI" use="required" /> <xs:attribute name="location" type="xs:anyURI" use="required" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tTypes"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleDocumented" /> </xs:complexContent> </xs:complexType> <xs:complexType name="tMessage"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleDocumented"> <xs:sequence> <xs:element name="part" type="wsdl:tPart" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tPart"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleAttributesDocumented"> <xs:attribute name="name" type="xs:NCName" use="required" /> <xs:attribute name="element" type="xs:QName" use="optional" /> <xs:attribute name="type" type="xs:QName" use="optional" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tPortType"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleAttributesDocumented"> <xs:sequence> <xs:element name="operation" type="wsdl:tOperation" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required" /> </xs:extension> </xs:complexContent> </xs:complexType> 86 .3.A.

3.A. DESCRITOR DE WSDL <xs:complexType name="tOperation"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleDocumented"> <xs:sequence> <xs:choice> <xs:group ref="wsdl:request-response-or-one-way-operation" /> <xs:group ref="wsdl:solicit-response-or-notification-operation" /> </xs:choice> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required" /> <xs:attribute name="parameterOrder" type="xs:NMTOKENS" use="optional" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:group name="request-response-or-one-way-operation"> <xs:sequence> <xs:element name="input" type="wsdl:tParam" /> <xs:sequence minOccurs="0"> <xs:element name="output" type="wsdl:tParam" /> <xs:element name="fault" type="wsdl:tFault" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:sequence> </xs:group> <xs:group name="solicit-response-or-notification-operation"> <xs:sequence> <xs:element name="output" type="wsdl:tParam" /> <xs:sequence minOccurs="0"> <xs:element name="input" type="wsdl:tParam" /> <xs:element name="fault" type="wsdl:tFault" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:sequence> </xs:group> <xs:complexType name="tParam"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleAttributesDocumented"> <xs:attribute name="name" type="xs:NCName" use="optional" /> <xs:attribute name="message" type="xs:QName" use="required" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tFault"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleAttributesDocumented"> <xs:attribute name="name" type="xs:NCName" use="required" /> <xs:attribute name="message" type="xs:QName" use="required" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tBinding"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleDocumented"> 87 .

3. DESCRITOR DE WSDL <xs:sequence> <xs:element name="operation" type="wsdl:tBindingOperation" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required" /> <xs:attribute name="type" type="xs:QName" use="required" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tBindingOperationMessage"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleDocumented"> <xs:attribute name="name" type="xs:NCName" use="optional" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tBindingOperationFault"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleDocumented"> <xs:attribute name="name" type="xs:NCName" use="required" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tBindingOperation"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleDocumented"> <xs:sequence> <xs:element name="input" type="wsdl:tBindingOperationMessage" minOccurs="0" /> <xs:element name="output" type="wsdl:tBindingOperationMessage" minOccurs="0" /> <xs:element name="fault" type="wsdl:tBindingOperationFault" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tService"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleDocumented"> <xs:sequence> <xs:element name="port" type="wsdl:tPort" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="tPort"> <xs:complexContent> <xs:extension base="wsdl:tExtensibleDocumented"> <xs:attribute name="name" type="xs:NCName" use="required" /> <xs:attribute name="binding" type="xs:QName" use="required" /> 88 .A.

3. DESCRITOR DE WSDL </xs:extension> </xs:complexContent> </xs:complexType> <xs:attribute name="arrayType" type="xs:string" /> <xs:attribute name="required" type="xs:boolean" /> <xs:complexType name="tExtensibilityElement" abstract="true"> <xs:attribute ref="wsdl:required" use="optional" /> </xs:complexType> </xs:schema> 89 .A.