Documente Academic
Documente Profesional
Documente Cultură
Recife, Agosto/2013
Recife, Agosto/2013
iii
Agradecimentos
Inicialmente eu agradeo a Deus, por ter me permitido chegar at aqui e cumprir com
sucesso os meus objetivos. Apenas ele sabe o quo desgastante [e prazerosa] foi esta
jornada.
Agradeo a meus pais Carlos e Branca, por todo o esforo e dedicao incomensurveis para me prover o melhor, dentro de seus limites. A minha irm Mirella, pelos
momentos de pacincia quando eu estava em momentos de stress. Eu amo vocs.
Agradeo a minha namorada, Marta Soraya, pela pacincia, companheirismo, apoio,
fora e motivao que sempre me proporcionou. Sem voc, tudo seria mais difcil. Ou
simplesmente no seria.
Agradeo aos inesquecveis amigos dos CInFuturo: Paulo Fernando, Airton Pereira,
Lenin Abadi, Marco Andr, Thiago Vieira, Rodolfo Arruda, Adriano Tito, Bruno Felipe e Hlio Rodrigues. Senhores, que a nossa amizade seja eterna! Obrigado pelos
momentos de descontrao!
Agradeo aos amigos Jackson Raniel e Ren Gadelha, por estarem presentes quando
mais precisei e, simplesmente, por serem amigos verdadeiros!
Agradeo aos demais amigos, com quem compartilhei momentos de aprendizado e
de aperreios em disciplinas, artigos e projetos: Fernando Selleri, Joo Emanoel (Joo
de Tuta), Jamilson Batista, Ivan Samuel, Kelliton Brito (KBrito) e Fernando Carvalho
(Fish).
Agradeo aos companheiro de AP Jlio Cesar (Pastor Jlio) e Rodrigo pelo companheirismo e tirao de onda durante o tempo que convivemos no mesmo AP. Que
vocs casem primeiro!!! hahaha
Agradeo aos Professores Silvio Meira (Engenharia de Software), Augusto Sampaio
(PLP), Fbio Queda (Metodologia de Pesquisa e Systematic Literature Review), Paulo
Borba e Fernando Castor (Arquitetura de Software), e Srgio Soares (Engenharia de
Software Experimental).
Agradeo aos meus Orientadores Vinicius Garcia e Uir Kulesza pela pacincia durante todo este processo de aprendizado e lapidao do conhecimento. Obrigado por
todas as contribuies construtivas e por acreditarem no meu trabalho. Obrigado por
no me darem de comer e me ensinarem a caar!
Agradeo a Profa. Rossana Andrade e ao Prof. Kiev Gama por aceitarem compor a
banca examinadora da minha defesa de mestrado.
Por fim, agradeo a Universidade Federal de Pernambuco e a todos que a compe.
iv
Resumo
notrio o surgimento de ambientes cada vez mais dinmicos, exigindo sistemas mais
flexveis, de forma que componentes possam ser plugados ou desplugados durante o seu
ciclo de vida, inclusive em tempo de execuo. Para atender estes requisitos, necessrio
que decises sobre possveis adaptaes e variaes do produto possam ser tomadas em
tempo de execuo. Sistemas Sensveis ao Contexto atendem a esse propsito, sendo
capazes de adaptar-se em tempo de execuo de acordo com mudanas no ambiente,
obedecendo um conjunto de regras.
Quando tcnicas de Linhas de Produto de Software (LPS) so aplicadas no desenvolvimento de sistemas adaptativos, tais decises podem resultar na configurao de um
novo produto. Em uma LPS tradicional, um produto derivado de acordo com sua configurao, que ocorre na fase de design e consiste na seleo de features que iro compor
o produto, remoo das features que no faro parte do produto e ligao dos pontos de
variao.
Linhas de Produto de Software Dinmicas extendem o conceito convencional de LPS
abordando aspectos dinmicos, provendo uma abordagem para tratar variabilidades que
precisam ser manipuladas em tempo de execuo.
Quando alinhamos paradigmas como Sistemas Sensveis ao Contexto, Arquitetura
Orientada a Servios e LPS, podemos enfrentar alguns desafios. O sistema derivado de
uma LPS composto por features e pontos de variao. Considerando que o modelo de
Arquitetura Orientada a Servios segue o padro arquitetural Cliente-Servidor, podemos
ter um cenrio em que as features que compem o produto no lado cliente podem enderear uma composio de servios. Dessa forma, os pontos de variao podem sofrer
variabilidades de acordo com mudanas no contexto, exigindo a execuo de reconfiguraes nos servios de modo a atender tais variabilidades. As abordagens propostas
atualmente no oferecem um suporte para esse tipo de problema ou so incipientes, estando em fases iniciais de pesquisa.
Neste trabalho apresentado um estudo sobre variabilidades dinmicas em Linhas
de Produto de Software Orientadas a Servios e Sensveis ao Contexto, innvestigando
especificamente situaes quando features que endeream um ou mais servios so reconfiguradas no lado cliente, requerendo reconfiguraes nos servios, no lado servidor.
Palavras-chave: sistemas adaptativos, arquitetura orientada a servios, linhas de produto de software dinmicas, reconfigurao dinmica, variabilidade dinmica
vi
Abstract
It is well known that the onset of more and more dynamic environments requires more
flexible systems, so that components can be unplugged or plugged during their life cycle,
including at run time. To meet these requirements, it is necessary that decisions on
possible adaptations and variations of the product can be made at runtime. Contextaware Systems (CAS) meets this purpose, being able to adapt at run time according to
changes in the environment, obeying a set of rules.
When Software Product Line (SPL) techniques are applied in the development of
adaptive systems, such decisions may result in the setting of a new product. In a traditional SPL, a product is derived according to its configuration, which occurs in the design
phase, and consists of selecting features that will make the product, removing features
that are not part of the product and the binding of variation points.
DSPL extends the conventional concept of SPL addressing dynamic aspects, providing an approach to address variability that needs to be manipulated at runtime. When
paradigms such as CAS, SOA and SPL align, we face some challenges. The system
derived from an SPL is composed of variation points and features. Whereas the model of SOA follows the Client-Server architectural pattern, we have a scenario in which
the features that make the product on the client side can address a service composition.
Thus, the variation points may suffer from variabilities according to changes in context,
demanding the execution of reconfigurations services to meet such variability. The proposed approaches do not currently offer support for this type of problem or are incipient,
being in the early stages of research.
This work presents a study of variability dynamics in LPSOSSC, investigating specific situations where features that address one or more services are reconfigured, requiring
reconfiguration on the server side.
Keywords: adaptive system, service-oriented architecture, dynamic software product
line, dynamic reconfiguration, dynamic variability, runtime variability
vii
Lista de Figuras
1.1
2.1
2.2
2.3
2.4
2.5
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
.
.
.
.
.
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
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
60
61
63
64
66
67
68
69
70
70
ix
Lista de Tabelas
3.1
4.1
47
52
Lista de Acrnimos
AOS
COS
DS
Descritor de Servios
DV
Descritor de Variabilidades
WSR
ELPS
JAXB
LPS
LPSD
LPSOS
Contexto
RF
Requisito Funcional
RNF
Requisito No-Funcional
SSC
WSDL
XML
xi
Sumrio
Introduo
1.1 Motivao . . . . . . . . .
1.2 Problemtica . . . . . . .
1.3 Viso Geral da Soluo . .
1.4 Escopo Negativo . . . . .
1.5 Organizao da Dissertao
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Reviso da Literatura
2.1 Linhas de Produto de Software: Uma viso geral . . . . . . .
2.1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Engenharia de Linha de Produto de Software . . . . .
2.1.3 Modelos de Adoo de Linhas de Produto de Software
2.1.4 Linhas de Produto de Software Dinmicas . . . . . . .
2.2 Computao Orientada a Servios: Uma viso geral . . . . . .
2.2.1 Arquiteturas Orientadas a Servios . . . . . . . . . . .
Motivao . . . . . . . . . . . . . . . . . . . . . . . .
Princpios e Papis . . . . . . . . . . . . . . . . . . .
2.2.2 Linhas de Produto Orientadas a Servios . . . . . . .
2.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
DYMOS Framework
3.1 Viso Geral da Soluo . . . . . . . . . . . . . . . . . . . . . .
3.2 Elicitao de Requisitos . . . . . . . . . . . . . . . . . . . . . .
3.3 Tecnologias Utilizadas . . . . . . . . . . . . . . . . . . . . . .
3.4 Arquitetura e Implementao . . . . . . . . . . . . . . . . . . .
3.4.1 Componentes Descritores . . . . . . . . . . . . . . . .
Descritor de Servios . . . . . . . . . . . . . . . . . . .
Descritor de Variabilidades . . . . . . . . . . . . . . . .
Web Service Resolver . . . . . . . . . . . . . . . . . .
3.4.2 Componente ServiceContext . . . . . . . . . . . . . . .
Reconfigurando Variabilidades Dinmicas . . . . . . . .
Descoberta de Servios . . . . . . . . . . . . . . . . . .
Reconstruindo o ServiceContext com o ContextHotBuild
3.4.3 Componente ApplicationService . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
5
7
8
.
.
.
.
.
.
.
.
.
.
.
9
9
10
11
13
14
15
16
16
17
19
21
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
26
27
28
29
31
33
35
36
37
39
43
44
xii
3.4.4
4
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
48
50
50
51
52
53
54
56
58
62
65
65
67
68
70
Concluso
5.1 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
72
73
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Referncias
74
Apndice
81
A Componentes Descritores
A.1 Descritor de Servios . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Descritor de Variabilidades . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Descritor de WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
82
83
84
xiii
1
Introduo
1.1
Motivao
notrio o surgimento de ambientes cada vez mais dinmicos, exigindo sistemas mais
flexveis, de forma que componentes possam ser plugados ou desplugados durante o seu
ciclo de vida, inclusive em tempo de execuo (Kim et al., 2005; Niebuhr et al., 2009).
Para atender estes requisitos, necessrio que decises sobre possveis adaptaes e
variaes do sistema possam ser tomadas em tempo de execuo. Sistemas Sensveis
ao Contexto (SSCs) atendem a esse propsito, sendo capazes de adaptar-se em tempo
de execuo de acordo com mudanas no ambiente, obedecendo um conjunto de regras
(Hallsteinsen et al., 2006; Kim et al., 2005; Oreizy et al., 1999).
Quando tcnicas de Linha de Produto de Software (LPS) so aplicadas no desenvolvimento de sistemas adaptativos, tais decises podem resultar na configurao de um
novo produto. Em uma LPS tradicional, um produto derivado de acordo com sua configurao, que ocorre na fase de design ou de implementao (Rosenmller et al., 2011) e
consiste na seleo de features que iro compor o produto, remoo das features que no
faro parte do produto e ligao dos pontos de variao (Alferez and Pelechano, 2011).
No entanto, no domnio de sistemas adaptativos, decises sobre quais so as features que
iro compor o produto podem estar ligadas a algum atributo ou caracterstica do ambiente, requerendo que a LPS seja dinmica, de modo que tais decises possam ser adiadas
da fase de desenvolvimento para a fase de execuo (Galster, 2010; Hallsteinsen et al.,
1.1. MOTIVAO
2008). Neste contexto, diversas pesquisas (Dhungana et al., 2007; Hallsteinsen et al.,
2006; Kim et al., 2005; Wolfinger et al., 2008), de diferentes reas, tm investigado
sobre a utilizao de abordagens de LPS no desenvolvimento de sistemas adaptativos.
Linhas de Produto de Software Dinmicas (LPSDs) (Hallsteinsen et al., 2008) estendem o conceito convencional de Linhas de Produto de Software abordando aspectos dinmicos e provendo uma abordagem para tratar variabilidades que precisam ser
manipuladas em tempo de execuo (Bencomo et al., 2012). LPSDs efetuam bind1 e
unbind2 de pontos de variao em tempo de execuo. Com isso, introduzido o conceito de variabilidade dinmica, possibilitando que o produto derivado de uma LPS seja
reconfigurado em tempo de execuo (Bencomo et al., 2010).
Tecnologias orientadas a servios possuem caractersticas que so requeridas por
muitas LPS (Yu et al., 2010), provendo uma estrutura dinmica e desacoplada, de modo
que possibilite obter mais flexibilidade e maior poder de adaptao a novos cenrios (Ye
et al., 2007). Este tipo de tecnologia utilizado para o desenvolvimento de software
como servio, resultando em componentes com baixo acoplamento e interoperabilidade
entre linguagens e plataformas (Demirkan et al., 2008). Com o objetivo de construir
artefatos de software cada vez mais reutilizveis, diversas abordagens (Galster, 2010;
Raatikainen and Mannisto, 2007; Segura et al., 2007; Smith and Lewis, 2009; Trujillo
and Kaestner, 2007) tm investigado o uso do modelo de Arquitetura Orientada a Servios (AOS) para este propsito. Com isso, surge o conceito de Linha de Produto de
Software Orientado a Servios (LPSOS) (Krut and Cohen, 2008), unindo prticas de
orientao a servios a LPS, para construir aplicaes customizadas, de acordo com
um segmento especfico de mercado. Este modelo de arquitetura possui caractersticas
dinmicas e flexveis que podem ajudar a obter uma gerncia de variabilidades mais
otimizada (Galster, 2010).
LPSOS representa uma categoria de LPSD, que desenvolvida seguindo uma arquitetura orientada a servios e, do ponto de vista da Engenharia de Linha de Produto de
Software (ELPS), possvel perceber benefcios como o suporte contnuo a mudanas
no contexto e a possibilidade de combinar servios em vrias configuraes, simplificando a implantao de pontos de variao que, por exemplo, embora utilizem a mesma
base de servios, necessitam passar por adaptaes para atender a diferentes requisitos
(Lee et al., 2012). Portanto, importante a existncia de tcnicas de engenharia de software que apoie o desenvolvimento de sistemas com baixo acoplamento, dinmicos e
1 associao
2 dissociao
1.2. PROBLEMTICA
1.2
Problemtica
1.2. PROBLEMTICA
1.3
De modo a permitir variabilidades dinmicas em LPSOSSCs, foi proposto e desenvolvido o DYMOS Framework. apresentado por meio da da Figura 1.1, a forma como o
DYMOS est disposto em relao as demais tecnologias utilizadas.
O DYMOS prov, de uma forma desacoplada, uma plataforma de reconfigurao de
variabilidades dinmicas e descoberta de servios para Linhas de Produto de Software
Orientado a Servios e Sensvel ao Contexto. O DYMOS oferece algumas vantagens
como: possibilidade de Gerncia de variabilidades de uma forma leve e simples, permitindo que servios sejam adicionados ou removidos da configurao do produto em
tempo de execuo por meio de mecanismos de auto-implantao, de modo que o funcionamento do sistema no seja afetado e que tais modificaes sejam aplicadas e reconhecidas imediatamente; Mecanismo de Descoberta de Servio, que prov uma abstrao
entre o Cliente e o Servio, permitindo agregar critrios para a seleo do servio mais
adequado, de acordo com uma requisio; As principais funcionalidades do DYMOS
esto dispostas na forma de servios web e, por meio destes, obtida a caracterstica de
interoperabilidade, permitindo que o framework seja utilizado por aplicaes desenvolvidas em outras plataformas.
De acordo com (Gomaa and Hashimoto, 2011), possvel classificar uma reconfigurao em tempo de execuo como comportamental, arquitetural ou reconfigurao
de componentes. Uma adaptao comportamental ocorre quando o comportamento do
sistema alterado, mantendo a mesma estrutura e arquitetura. Uma adaptao arquitetural ocorre quando a arquitetura do sistema impactada diretamente pela adaptao.
Uma adaptao de componentes envolve uma substituio de um componente por outro
que implemente a mesma interface. O tipo de reconfigurao executada pelo DYMOS
se trata de reconfigurao de componentes.
O framework foi desenvolvido de forma modular utilizando tecnologias OSGi3 . Como
forma de obter componentes modularizados, foi utilizado o iPOJO4 , que um framework
para desenvolvimento de componentes orientados a servio para compor sistemas modulares que requerem adaptaes em tempo de execuo (Escoffier et al., 2007). Como
3 http://www.osgi.org
4 http://felix.apache.org/site/apache-felix-ipojo.html
plataforma de execuo, utilizado o framework Apache Felix5 , que uma implementao do OSGi Service Platform. Para expor funcionalidades por meio de servios web,
utilizado o OSGi Distribudo6 , que um subprojeto do Apache CXF7 .
Mecanismo de Descoberta de Servios responsvel por prover operaes de descoberta de servios. Essas operaes possibilitam a recuperao de referncias (endpoint) de acesso a servios, informando o ID atribudo na descrio do servio.
Este mecanismo deve selecionar o servio mais adequado, de acordo com o ID
informado e, em seguida, deve ser retornado o endpoint do servio para que possa
ser utilizado pelo cliente. Com isso, servios podem ser inseridos ou removidos a
qualquer momento, sem haver a necessidade de alterao de cdigo no cliente ou
no servidor.
Os itens Descritor de Servios e Descritor de Variabilidades so utilizados pelos
mecanismos de Reconfigurao e Descoberta de Servios, de modo que as operaes
de reconfigurao e descoberta de servios sejam efetuadas de acordo com cada uma
das descries. De modo a permitir os Descritores de Servios e de Variabilidades, foi
definida e disponibilizada uma sintaxe baseada em XML, que dever ser utilizada para
especificar cada um dos itens.
As operaes de reconfigurao e descoberta de servios que so providas respectivamente pelo Mecanismo de Reconfigurao de Servios e Mecanismo de Descoberta de Servios, esto disponveis por meio de Servios Web. O Servio Web referente
operaes de reconfigurao permite que o framework seja notificado sobre mudanas
no contexto, atendendo ao item i, mencionado na Seo 1.2
Uma descrio mais detalhada sobre a soluo proposta apresentada no Captulo
3.
1.4
Escopo Negativo
1.5
Organizao da Dissertao
2
Reviso da Literatura
O silncio um amigo verdadeiro que nunca trai.
Silence is a true friend who never betrays.
CONFUCIUS
2.1
A ELPS tem seus princpios inspirados em fbricas de automveis, que possuiam produtos com um custo mais interessante quando produzidos em massa do que quando
produzidos de forma individual. Estas fbricas 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).
Uma linha de produto pode ser definida como um grupo de sistemas de software que
compartilham um conjunto de caractersticas em comum e que satisfazem as necessidades especficas de um segmento de mercado. Este grupo de sistemas so desenvolvidos com base em um conjunto de core assets, que so documentos, especificaes,
componentes e outros artefatos de software que possam ser reutilizados durante o desenvolvimento de cada sistema de software que compe a linha de produto (Clements and
Northrop, 2001).
O objetivo da ELPS explorar partes comuns em um conjunto de sistemas, enquanto
gerencia as partes variveis, permitindo o desenvolvimento de uma famlia de sistemas
de uma forma rpida e com baixo custo quando comparado ao desenvolvimento de um
sistema separadamente (Gomaa, 2004). demonstrado por meio da Figura 2.1 uma
comparao entre o custo de produo de um nico produto e o custo de produo de
vrios produtos.
Figura 2.1 Custos do desenvolvimento de uma Linha de Produto. Adaptado de (Linden et al.,
2007)
2.1.1
Motivao
Existem diversas razes para desenvolver uma famlia de produtos utilizando o paradigma de ELPS. Este paradigma proporciona muitos benefcios e, de acordo com (Pohl
et al., 2005), estes benefcios consistem em:
Uma vez que muitos produtos so desenvolvidos com base em um conjunto de
core assets comuns, o custo de desenvolvimento e tempo de entrega de produtos individuais so reduzidos consideravelmente. No entanto, exigido um
investimento inicial e um longo perodo de tempo para desenvolver os core assets
que sero reutilizados durante o desenvolvimento de cada produto.
10
2.1.2
11
Conforme possvel observar na Figura 2.2, as fases consistem no Desenvolvimento de core assets, Desenvolvimento do Produto e Gerenciamento.
Desenvolvimento de core assets esta atividade equivalente Engenharia de Domnio.
Nesta etapa so produzidos um conjunto de core assets, um plano de produo e
12
2.1.3
13
2.1.4
Quando tcnicas de Linha de Produto de Software (LPS) so aplicadas no desenvolvimento de sistemas adaptativos, tais decises podem resultar na configurao de um novo
produto. Em uma LPS tradicional, um produto derivado de acordo com sua configurao, que ocorre na fase de design ou de implementao (Rosenmller et al., 2011) e
consiste na seleo de features que iro compor o produto, remoo das features que no
14
faro parte do produto e ligao dos pontos de variao (Alferez and Pelechano, 2011).
No entanto, no domnio de sistemas adaptativos, decises sobre quais so as features
que iro compor o produto podem estar ligadas a algum atributo ou caracterstica do
ambiente, requerendo que a LPS seja dinmica, de modo que tais decises possam ser
adiadas da fase de desenvolvimento para a fase execuo (Galster, 2010; Hallsteinsen
et al., 2008). Nesse contexto, diversas pesquisas (Dhungana et al., 2007; Hallsteinsen
et al., 2006; Kim et al., 2005; Wolfinger et al., 2008), de diferentes reas, tm investigado
sobre Linhas de Produto de Software Dinmicas (LPSDs), que consiste na utilizao de
abordagens de LPS no desenvolvomento de sistemas adaptativos.
O termo Linhas de Produto de Software Dinmicas (em ingls, Dynamic Software
Product Lines, ou DSPL) foi introduzido em 2008 por (Hallsteinsen et al., 2008). O
autor apresenta um novo conceito que utiliza abordagens de LPS para construir sistemas
que podem ser adaptados em tempo de execuo, de acordo com requisitos do usurio e
mudanas no ambiente.
Linhas de Produto de Software Dinmicas (LPSDs) (Hallsteinsen et al., 2008) estendem o conceito convencional de Linhas de Produto de Software abordando aspectos
dinmicos, provendo uma abordagem para tratar variabilidades que precisam ser manipuladas em tempo de execuo (Bencomo et al., 2012). LPSDs efetuam bind e unbind
de pontos de variao em tempo de execuo. Com isso, introduzido o conceito de
variabilidade dinmica, possibilitando que o produto derivado de uma LPS seja reconfigurado em tempo de execuo (Bencomo et al., 2010).
LPSD um termo relativamente novo e diversas pesquisas esto em evoluo. Na
Seo 2.3 sero apresentados os principais trabalhos relacionados nossa abordagem e,
por fim, ser feita uma discusso sobre as vantagens apresentadas por nossa proposta.
2.2
15
orientada a servios em conjunto com abordages de LPS. Com isso, surge o conceito de
LPSOS (Krut and Cohen, 2008), unindo abordagens de orientao a servios a LPS, para
construir aplicaes customizadas, de acordo com um segmento especfico de mercado.
2.2.1
16
Flexibilidade e Agilidade: constantemente os sistemas de software precisam passar por modificaes para atender novos requisitos, que so requeridos por novas
exigncias de mercado (Carter, 2007). Por isso, a arquitetura do sistema de software deve ser reconfigurvel, de uma forma simples. As caractersticas do modelo
de AOS permitem um melhor alinhamento entre o sistemas de software e as necessidades de mercado por meio da integrao de novos servios e reuso de servios
existentes, possibilitando responder rapidamente a possveis mudanas nos requisitos (Endrei et al., 2004).
Integrao e Interoperabilidade: servios podem ser desenvolvidos de forma independente e ento so compostos com outros servios a fim de prover funcionalidades de uma aplicao que pode ser facilmente adaptada a novos requisitos
e, por meio da interoperabilidade, servios heretogneos so facilmente integrados, permitindo a troca de mensagem entre estes (Erl, 2005; Zi-yun and Ru-long,
2011).
O modelo de arquitetura orientada a servios normalmente definido com base em
um conjunto de princpios (Erl, 2005). Sero apresentados na prxima seo os princpios que so diretamente relacionados com este modelo de arquitetura.
Princpios e Papis
Conforme mencionado anteriormente, o modelo de arquitetura orientada a servios
definido com base em um conjunto de princpios que apoiam suas caractersticas. Os
princpios que so diretamente relacionados com este modelo de arquitura so:
Acoplamento: este princpio se refere ao nmero de dependncias entre servios.
O baixo acoplamento obtido por meio do uso de padres e contratos de servios
entre clientes e provedores, que permitem a interao dos servios utilizando interfaces bem definidas. O princpio do acoplamento tambm afeta outro atributos
de qualidade como a modificabilidade e reusabilidade da aplicao (McGovern
et al., 2003).
Contrato de Servio: servios aderem a contratos de comunicao, definidos por
um ou mais servios. Neste contrato so definidos formato de dados, regras e
caractersticas dos servios e suas funcionalidades. Para permitir estas definies,
so utilizados formatos padronizados como XML, WSDL e XSD (Erl, 2005; Dirksen, 2013).
17
Conforme a Figura 2.3, os papis consistem em: Cliente (Service Consumer), Provedor de Servio (Service Provider), Registro e Descoberta de Servios (Service Registry)
e o Contrato de Servio (Service Contract). Tambm possvel observar nesta mesma
figura, os relacionamentos entre os papis elencados acima.
1 http://uddi.xml.org
18
Cliente: pode ser uma aplicao, um servio ou outra entidade de software que
necessita acessar o servio. Este acesso pode ser possibilitado diretamente por
meio do URI (Uniform Resource Identifier) ou por meio da descoberta de servios,
utilizando o registro de servio (Josuttis, 2007).
Provedor de Servio: a entidade que recebe e processa as requisies efetuadas
pelo Cliente. Esta entidade pode ser uma aplicao legada, um componente ou
outra entidade de software que expe sua interface como servio (Josuttis, 2007),
provendo uma implementao para um especificao ou contrato de servio. As
informaes sobre provedores de servios so publicadas no registro de servios
(McGovern et al., 2003).
Registro de Servio: entidade responsvel por manter as informaes sobre contratos de servios e provedores. Esta entidade pode ser utilizada para implementao de atributos de qualidade de servios como disponibilidade e modificabilidade
(Garcia-Gonzalez et al., 2010).
Contrato de Servios: por meio do contrato de servio especificado a forma
como o Cliente ir interagir com o Provedor do Servio. Este contrato especifica
o formato das mensagens, condies para acessar o Provedor do servio e pode
descrever atributos de qualidade (Erl, 2005; McGovern et al., 2003).
2.2.2
19
20
2.3
Trabalhos Relacionados
Durante o desenvolvimento deste trabalho foi possvel identificar alguns trabalhos relacionados. Estes trabalhos so descritos abaixo:
(Parra et al., 2009) prope uma Linha de Produto Dinmica, Orientada a Servio e
Sensvel ao Contexto denominada CAPucine. Esta linha de produto possui uma abordagem orientada a modelos e dividida em dois processos para a execuo da derivao do
produto. No primeiro processo, todas as features selecionadas so associadas ao artefato
que corresponde ao modelo parcial do produto, que composto e transformado para gerar o produto. O segundo processo referente a adaptaes dinmicas, que so efetuadas
utilizando o FraSCAti2 . O FraSCAti uma plataforma de Arquitetura de Componentes
Orientados a Servio (em ingls, Service Component Architecture, ou SCA) com propriedades dinmicas que permite operaes de bind e unbind de componentes em tempo
de execuo.
2 http://frascati.ow2.org/
21
(Yu et al., 2010) prope uma abordagem que dividida em trs fases e une conceitos
de LPS a COS para desenvolver composies dinmicas de servios. A primeira fase
da abordagem consiste em especificar a arquitetura da linha de produto, efetuando a
sua integrao com o modelo de variabilidades. A segunda fase consiste em definir
composies de servios, que devem seguir a arquitetura da linha de produto. A terceira
fase consiste em criar e manter de forma autnoma a aplicao construda com base na
arquitetura da linha de produto.
(Alferez and Pelechano, 2011) prope uma abordagem para projetar e implementar
Web Services Sensveis ao Contexto em uma famlia de sistemas. A abordagem proposta apoiada pelo (MoRE-WS), que uma plataforma de reconfigurao guiada por
modelos, onde so utilizados modelos de variabilidades como polticas de adaptao
para gerar e executar de forma automtica o plano de reconfigurao.
A partir destes trabalhos foram identificadas algumas limitaes na tentativa de apliclos no cenrio de LPSOSSC que seguem o modelo de AOS utilizando o padro arquitetural Cliente-Servidor (Erl, 2007), onde features que compem o produto no lado cliente
podem enderear uma composio de servios.
Uma limitao encontrada no trabalho proposto por (Parra et al., 2009) diz respeito
a complexidade da abordagem, que dificulta a sua utilizao em sistemas de pequeno
porte ou que esto na fase inicial da adoo do paradigma de LPS. No trabalho proposto
por (Alferez and Pelechano, 2011), foi possvel observar uma limitao que consiste
em considerar um servio como uma nica feature, efetuando adaptaes dinmicas por
meio da substituio de seus provedores. Neste caso, no so tratadas as features que
so compostas no apenas por servios, mas tambm por outros artefatos que utilizam
tais servios para prover suas funcionalidades.
Por fim, conforme colocado por (Silva et al., 2013), os reconfiguradores utilizados
pelas abordagens atuais, inclusive (Yu et al., 2010), apresentam um forte acoplamento
com sua respectiva LPSD.
No prximo captulo (Captulo 3) ser apresentada a soluo proposta neste trabalho,
detalhando como a soluo trata as limitaes descritas nesta seo.
22
3
DYMOS Framework
Seja uma referncia em qualidade. Algumas pessoas no esto
acostumadas com um ambiente em que a excelncia esperada.
Be a yardstick of quality. Some people arent used to an environment
where excellence is expected.
STEVE JOBS
3.1
O DYMOS prov, de uma forma desacoplada, uma plataforma de reconfigurao de variabilidades dinmicas e descoberta de servios para Linhas de Produto de Software Orientado a Servios e Sensvel ao Contexto. O DYMOS oferece algumas vantagens como:
possibilidade de Gerncia de Variabilidades de uma forma leve e simples, permitindo
que servios sejam adicionados ou removidos da configurao do produto em tempo de
execuo por meio de mecanismos de auto-implantao, de modo que o funcionamento
do sistema no seja afetado e que tais modificaes sejam aplicadas e reconhecidas imediatamente; Mecanismo de Descoberta de Servio, que prov uma abstrao entre o
Cliente e o Servio, permitindo agregar critrios para a seleo do servio mais adequado, de acordo com uma requisio; As principais funcionalidades do DYMOS esto
dispostas na forma de servios web e, por meio destes, obtida a caracterstica de interoperabilidade, permitindo que o framework seja utilizado por aplicaes desenvolvidas
em outras plataformas.
De acordo com (Gomaa and Hashimoto, 2011), possvel classificar uma reconfigurao em tempo de execuo como comportamental, arquitetural ou reconfigurao
de componentes. Uma adaptao comportamental ocorre quando o comportamento do
23
sistema alterado, mantendo a mesma estrutura e arquitetura. Uma adaptao arquitetural ocorre quando a arquitetura do sistema impactada diretamente pela adaptao.
Uma adaptao de componentes envolve uma substituio de um componente por outro
que implemente a mesma interface. O tipo de reconfigurao executada pelo DYMOS
se trata de reconfigurao de componentes.
O DYMOS foi desenvolvido de forma modular utilizando tecnologias OSGi, com
a finalidade de permitir variabilidades dinmicas em Linhas de Produto de Software
Orientado a Servios e Sensvel ao Contexto (LPSOSSCs). apresentado por meio da
Figura 1.1, a forma como o DYMOS est disposto em relao as demais tecnologias
utilizadas.
Como forma de obter componentes modularizados, foi utilizado o iPOJO, que um
framework para desenvolvimento de componentes orientados a servio para sistemas dinamicamente adaptveis (Escoffier et al., 2007). Como plataforma de execuo, foi utilizado o framework Apache Felix, que uma implementao do OSGi Service Platform.
Para expor funcionalidades atravs de servios web, foi utilizado o OSGi Distribudo,
que um subprojeto do Apache CXF.
Dessa forma, faz-se necessrio um framework que seja responsvel por tratar reconfiguraes de tais variabilidades. De acordo com (Erl, 2007), o modelo de AOS segue o
padro arquitetural Cliente-Servidor. Ento, como o cliente e o servidor so executados
em ambientes diferentes, necessrio que o DYMOS seja capaz de (i) receber notificaes sobre mudanas no contexto, para que (ii) reconfiguraes possam ser efetuadas.
SSCs so flexveis, dinmicos e se adaptam em tempo de execuo de acordo com
mudanas no ambiente, obedecendo um conjunto de regras (Hallsteinsen et al., 2006;
Kim et al., 2005; Oreizy et al., 1999). Quando mudanas ocorrem, reconfiguraes so
executadas, tornando disponvel ou indisponvel um ou mais servios, compondo uma
plataforma de servios dinmica. Considerando que os servios estaro em execuo
em uma plataforma com caractersticas dinmicas, necessrio um (iii) mecanismo de
descoberta de servios, que insira uma camada de abstrao entre o cliente, o servidor e
o servio requisitado.
Com isso, espera-se que haja um menor no acoplamento e maior flexibilidade, visto
que no devem existir requisies para um servio especfico, de forma fixa, mas para
um servio que atenda a uma determinada especificao. O mecanismo de descoberta
de servios deve ser responsvel por selecionar e prover uma referncia (endpoint) para
o servio mais adequado.
Na Seo 1.2 foi apresentada a problemtica tratada na abordagem proposta neste
24
trabalho e foram elencados os itens i, ii e iii que, respectivamente, endeream as funcionalidades de recebimento de notificaes sobre mudanas no contexto, reconfigurao
de variabilidades e descoberta de servios. Com o objetivo de abordar estes itens, os
seguintes artefatos foram desenvolvidos em forma de componentes como parte da soluo:
Descritor de Servios permite descrever servios, indicando um ID (identificador), especificaes, implementaes e regras que so aplicadas quando a operao de
descoberta de servio solicitada. Quando h uma requisio, tais regras devem
ser utilizadas a fim de selecionar o servio adequado.
Descritor de Variabilidades permite descrever variabilidades, indicando pontos de variao. A descrio consiste na atribuio de um ID e um mapeamento entre
pontos de variao e um ou mais servios.
Mecanismo de Reconfigurao de Servios responsvel por reconfigurar os servios para atender a mudanas no ambiente. A reconfigurao feita em termos
de ativao ou desativao de um ou mais servios, tornando-os disponveis ou
indisponveis para utilizao. Este componente atende ao item ii, mencionado na
Seo 1.2.
Mecanismo de Descoberta de Servios responsvel por prover operaes de descoberta de servios. Essas operaes possibilitam a recuperao de referncias (endpoint) de acesso a servios, informando o ID atribudo na descrio do servio.
Este mecanismo deve selecionar o servio mais adequado, de acordo com o ID
informado e, em seguida, deve ser retornado o endpoint do servio para que possa
ser utilizado pelo cliente. Com isso, servios podem ser inseridos ou removidos a
qualquer momento, sem haver a necessidade de alterao de cdigo no cliente ou
no servidor. Este componente atende ao item iii, mencionado na Seo 1.2.
Os itens Descritor de Servios e Descritor de Variabilidades so utilizados pelos
mecanismos de Reconfigurao e Descoberta de Servios, de modo que as operaes
de reconfigurao e descoberta de servios sejam efetuadas de acordo com cada uma
das descries. De modo a permitir os Descritores de Servios e de Variabilidades, foi
definida e disponibilizada uma sintaxe baseada em XML, obedecendo um meta-modelo.
Esta sintaxe dever ser utilizada para especificar cada um dos itens.
As operaes de reconfigurao e descoberta de servios que so providas respectivamente pelo Mecanismo de Reconfigurao de Servios e Mecanismo de Desco-
25
berta de Servios, esto disponveis atravs de servios web. O servio web referente a
operaes de reconfigurao, permite que o framework seja notificado sobre mudanas
no contexto, atendendo ao item i, mencionado na Seo 1.2.
Nas prximas sees deste captulo sero apresentados mais detalhes sobre a soluo
proposta neste trabalho.
3.2
Elicitao de Requisitos
Nesta seo sero apresentados os requisitos elicitados para o desenvolvimento do DYMOS Framework.
Elicitao de Requisitos o processo identificao das necessidades de um determinado domnio de negcio. Este processo executado com o apoio de usurios, clientes e
stakeholders1 (Tiwari et al., 2012). Os requisitos de um sistema so categorizados como
Requisitos Funcionais (RFs) ou Requisitos No-Funcionais (RNFs). por meio de RFs
que as funcionalidades so elencadas, descrevendo as operaes que o sistema deve prover. Os RNFs elencam restries de qualidade que so atribudas aos RFs (Ullah et al.,
2011).
Analisando a problemtica descrita na Seo 1.2 e o objetivo proposto neste trabalho,
foi possvel elicitar os Requisitos Funcionais (RFs) e Requisitos No-Funcionais (RNFs)
do framework proposto. Os requisitos esto detalhados abaixo:
RF1 necessrio prover uma forma de descrever servios, variabilidades e mapeamento entre estes.
RF2 A aplicao cliente composta por features que podem ser ativadas ou desativadas
de acordo com mudanas no ambiente. Dessa forma, o DYMOS deve prover um
mecanismo que possibilite receber notificaes sobre mudanas na composio
das features na aplicao cliente.
RF3 necessrio o desenvolvimento de um mecanismo capaz de tratar a notificaes
sobre mudanas na composio das features, identificando as variabilidades que
sero afetadas.
RF4 O DYMOS deve ser capaz de efetuar reconfiguraes na plataforma de servios
de acordo com as variabilidades identificadas no RF3.
1 Pessoa
26
RF5 O DYMOS deve prover um mecanismo para descoberta de servios, de modo que
quando houver uma requisio por um determinado servio, seja retornada uma
referncia para o servio mais adequado.
RF6 necessria a existncia de um mecanismo que permita a implantao de novos
servios e atualizao dos descritores de servios e variabilidades em tempo de
execuo, de modo que variabilidades possam ser includas ou excludas sem a
necessidade de interromper a execuo do DYMOS.
RF7 Para possibilitar a descoberta de servios, o mecanismo deve receber o ID atribudo
ao servio no descritor e, e acordo com este, o servio mais adequado deve ser
selecionado.
RF8 Deve existir a possibilidade de mapear servios alternativos, que devem ser utilizados em caso de indisponibilidade do servio principal.
RF9 A seleo do servio adequado deve acontecer de acordo com uma prioridade, que
atribuda na descrio do servio.
RNF1 O RF1 deve ser contemplado por meio de uma linguagem baseada em XML.
Os descritores devem ser tratados como meta-dados e convertidos em objetos,
e devem ser utilizados no gerenciamento das reconfiguraes e descobertas de
servios.
RNF2 O RF2 deve estar disponvel por meio de servios web.
3.3
Tecnologias Utilizadas
apresentado por meio da Figura 1.1, a forma como o DYMOS est disposto em relao
s demais tecnologias utilizadas. Nesta seo apresentada uma breve descrio sobre
cada uma das delas.
OSGi O framework OSGi define um conjunto de especificaes que permitem o desenvolvimento de modulares em Java, provendo um maior controle sobre a estrutura
do cdigo e gerenciamento dinmico do ciclo de vida dos componentes. Este
framework permite que componentes sejam instalados, inicializados, encerrados,
atualizados e desinstalados sem a necessidade de reiniciar a aplicao (de Castro Alves, 2011; Hall et al., 2011).
27
Apache Felix uma distribuio open-source, mantida pela Apache Foundation com o
apoio da comunidade. Este framework implementa a verso 4.x da especificao
OSGi Service Platform e utilizado como plataforma de execuo de aplicaes
OSGi.
iPOJO um modelo de componente orientado a servio que tem como objetivo simplificar o desenvolvimento de aplicaes OSGi. O iPOJO permite o desenvolvimento
de componentes orientados a servio para compor sistemas modulares que requerem adaptaes em tempo de execuo (Escoffier et al., 2007).
OSGi Distribudo (em ingls, Distributed OSGi ou DOSGi) um subprojeto do
Apache CXF. O DOSGi fornece uma implementao de referncia com base em
Web Services, que segue a especificao OSGi Remote Services e permite que
aplicaes OSGi sejam implantadas na forma de servios web.
Alm das tecnologias mencionadas acima, tambm foi utilizado o JAXB2 (Java Architecture for XML Binding). O JAXB consiste em um conjunto de bibliotecas Java que
permitem a converso de XML em objetos Java e vice-versa.
A utilizao das tecnologia mencionadas nesta seo possibilitou o desenvolvimento
da soluo proposta neste trabalho. A Seo 3.4 descrever com mais detalhes a escolha
destas tecnologias e onde cada uma delas foram utilizadas.
3.4
Arquitetura e Implementao
28
observar na figura, os principais componentes so o ServiceContext, o VariabilityDescriptor, o ServiceDescriptor, o WSResolver e o ApplicationService, que externaliza as
funcionalidades de descoberta de servios e reconfigurao de variabilidades por meio
de web services.
3.4.1
Componentes Descritores
29
Conforme possvel observar na Figura 3.2, so definidos mtodos getObjectDescriptors que possuem diferentes parmetros, provendo vrias formas de entrada de dados, onde o tipo de retorno T representa o tipo do elemento descrito. Alm desses
mtodos, o descritor tambm prov um mtodo para efetuar uma converso inversa, de
objeto Java para XML.
30
31
32
<?xml version="1.0"?>
<services>
<service id="dataBaseAccessService"
service-impl="br.ufpe.cin.assert.ws.dataAccess.impl.DataBaseAccessServiceImpl">
<service-spec>br.ufpe.cin.assert.ws.dataAccess.IDataAccessService</service-spec>
<alternative-service ref="fileAccessService" priority="1" />
</service>
<service id="fileAccessService"
service-impl="br.ufpe.cin.assert.ws.dataAccess.impl.FileAccessServiceImpl">
<service-spec>br.ufpe.cin.assert.ws.dataAccess.IDataAccessService</service-spec>
</service>
<service id="dataEncryptService"
service-impl="br.ufpe.cin.assert.encrypt.ws.dataEncrypt.impl.EncryptServiceImpl">
<service-spec>br.ufpe.cin.assert.encrypt.ws.dataEncrypt.IDataEncryptService</service-spec>
</service>
<service id="authService">
<service-spec>br.ufpe.cin.assert.auth.ws.IAuthService</service-spec>
</service>
</services>
33
servar na Figura 3.6 que uma Variabilidade possui: uma Identificao (ID), por meio do
atributo id; uma nome , por meio do atributo name; e um conjunto de variaes
(Variant). Uma Variant composta por um ID, um nome e um conjunto de Referncia
para Servios.
34
<?xml version="1.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>
35
3.4.2
Componente ServiceContext
Uma vez que os Servios esto descritos e mapeados nas descries de Variabilidades por meio de Composio de Servios, as informaes sobre tais descries devem
ser utilizadas no gerenciamento das Variabilidades, em tempo de execuo. O Componente ServiceContext responsvel por manter tais informaes em memria, de modo
que seja possvel utiliz-las durante as operaes de Reconfigurao de Variabilidades e
Descoberta de Servios. Durante o decorrer desta seo mecionaremos os termos Contexto de Servios e Contexto de Variabilidades, que respectivamente significam os
servios descritos e as variabilidades descritas, ambos em memria. apresentado por
meio da Figura 3.9 uma viso sob uma perspectiva de dependncia entre o ServiceContext e os demais componentes, indicando a relao entre eles atravs de importao e
exportao de pacotes (packages).
36
Figura 3.9 Componente ServiceContext: Uma viso sob uma perspectiva de dependncia entre
componentes
37
38
39
Figura 3.11 Descoberta de Servios: Viso geral sobre a interao entre componentes
De acordo com o que exposto na Figura 3.11, uma operao de descoberta de servios iniciada a partir de uma requisio feita pela aplicao cliente, que demonstrada
pelo item 1. Aps receber a requisio, o item 2 executado e quando o componente ApplicationService a repassa para o componente ServiceContext, para que possa
ser tratada. O tratamento da requisio, demonstrado pelo item 3, consiste em analisar
um conjunto de critrios pr-definidos para que seja possvel selecionar o servio mais
adequado para atender tal requisio.
Os critrios adotados na implementao dos mecanismos de Descoberta de Servios
do DYMOS consistem na verificao de disponibilidade de um servio e seleo de
servios alternativos de acordo com uma prioridade. Estes critrios so definidos de
acordo com as informaes descritas no DS, como apresentado na Figura 3.12.
40
<?xml version="1.0"?>
<services>
<service id="service1"
service-impl="br.ufpe.cin.assert.ws.service1.impl.Service1Impl">
<service-spec>br.ufpe.cin.assert.ws.greetService.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.cin.assert.ws.service2.impl.Service4Impl">
<service-spec>br.ufpe.cin.assert.ws.greetService.IGreetService</service-spec>
</service>
<service id="service3">
<service-spec>br.ufpe.cin.assert.ws.greetService.IGreetService</service-spec>
</service>
<service id="service4" service-impl="br.ufpe.cin.assert.ws.service4.impl.Service4Impl">
<service-spec>br.ufpe.cin.assert.ws.greetService.IGreetService</service-spec>
</service>
</services>
Os atributos utilizados nas operaes de descoberta de servios so: o serviceimpl, onde definida a implementao do servio; o service-spec, onde definido a
especificao ou contrato do servio; e o priority definido em alternative-service,
que elenca servios alternativos indicando uma prioridade para cada um. apresentado
na Figura 3.13 o diagrama que representa a sequncia de funes executadas durante a
operao de descoberta de servios.
41
Conforme possvel observar na Figura 3.13, a execuo de uma operao de descoberta de servio iniciada quando h uma requisio por um servio atravs do mtodo
getEndpoint, onde informado o ID do servio requerido. O principal objetivo desse
tipo de operao recuperar uma referncia (endpoint) de um servio que atenda a uma
determinada funcionalidade, para que seja possvel utiliz-lo.
Quando a requisio recebida pelo componente ApplicationContext, ela repassada ao ServiceContext para que possa ser tratada, utilizando as informaes obtidas a
partir do DS. Inicialmente, de acordo com o servio requisitado, so recuperadas as suas
informaes, que so mantidas em memria pelo componente ServiceContext. Aps
recuperar tais informaes, os atributos service-impl, service-spec e alternativeservice so utilizados para efetuar a seleo do servio.
42
Com o objetivo de encontrar o servio mais adequado para atender a requisio recebida, o componente ServiceContext interage com o OSGi Container a fim de identificar
o bundle responsvel por prover tal servio. A sequncia utilizada na seleo do servio
consiste em (i) buscar por um servio que atenda Especificao e Implementao definida no DS por meio dos atributos service-spec e service-impl respectivamente;
caso acontea uma falha no item i e o servio no possa ser encontrado utilizando estes
atributos, (ii) efetuada uma busca por servios alternativos, respeitando a prioridade
definida no atributo priority e considerando que os menores nmeros so mais prioritrios. caso acontea uma falha no item ii e no seja possvel selecionar um servio, (iii)
efetuada uma busca por servios que provem uma implementao para a Especificao definida no atributo service-spec, considerando inclusive, os servios que esto
em execuo no OSGi Container e que no esto descritos no DS.
Aps encontrar e selecionar o servio mais adequado, o ServiceContext interage com
o componente WSResolver informando o endereo onde o servio est publicado, e obtem como resposta as informaes que constam no WSDL em forma de objetos Java.
Tais objetos so processados e como resposta gerado um valor que corresponde a
uma referncia para o servio selecionado. A resposta gerada, que obedece o formato
serviceEndpoint;targetNamespace;serviceName, enviada ao cliente que efetuou a
requisio do servio.
O mecanismo de Descoberta de Servios implementado como parte do DYMOS
oferece uma abstrao entre o cliente e o servio. Essa abstrao possibilita a existncia
de requisies por servios informando um ID previamente mapeado com um conjunto
de informaes sobre o servio, que so utilizadas como critrios de seleo. Consequentemente, obtido um menor acoplamento entre o cliente e o servio, possibilitando
inclusive, a implantao de forma facilitada de atualizaes de servios que j esto em
execuo ou de novos servios.
Reconstruindo o ServiceContext com o ContextHotBuild
Com o passar do tempo, um software necessita ser atualizado por diferentes razes como
resoluo de bug, melhoria dos seus componentes, ou por questes de adaptao do
software para atender a novos requisitos (Alhazbi and Jantan, 2006). Hot swapping
e On-the-Fly Software Replacement so termos utilizados no contexto de evoluo de
software, que consiste em reconfiguraes em tempo de execuo, permitindo adicionar,
remover ou atualizar dinamicamente um componente (Tan, 2001; Oreizy et al., 1998).
Conforme elicitado por meio do requisito funcional RF6, necessria a existncia
43
de um mecanismo que permita a implantao de novos servios e atualizao dos descritores de servios e variabilidades em tempo de execuo, de modo que variabilidades
possam ser includas ou excludas sem a necessidade de interromper a execuo do framework.
Com o objetivo de atender este requisito, foi desenvolvido como parte do DYMOS
o ContextHotBuild, que permite o hot swapping de servios e variabilidades. O ContextHotBuild responsvel por capturar mudanas no ciclo de vida dos componentes
instalados no OSGi Container, e no contexto do DYMOS, em especial quando o estado
do componente alterado para INSTALLED.
No momento em que um novo componente instalado, o DYMOS faz uma nova leitura no DS e no DV por meio do ContextHotBuild, em busca de atualizaes nas informaes descritas e, em seguida, reconstri o contexto de servios e variabilidades. Este
mecanismo tambm prov uma facilidade para operaes de implantao de componentes no OSGi Container, que consiste em disponibilizar um diretrio para implantao
de componentes. Dessa forma, quando componentes so inseridos ou removidos de tal
diretrio, so executadas no OSGi Container operaes de install e uninstall respectivamente. Isto gera uma mudana no ciclo de vida dos componentes, e consequentemente,
uma reconstruo no Contexto de Servios e Variabilidades.
Este mecanismo permite a incluso ou remoo de servios e variabilidades sem a
necessidade de interromper a execuo do framework, e inclusive de uma forma facilitada, no exigindo o contato direto com o OSGi Container para instalao ou remoo
de componentes por meio de linhas de comando.
3.4.3
Componente ApplicationService
44
3.4.4
Esta seo apresenta uma discusso sobre as decises arquiteturais e como foi possvel
atender os Requisitos RFs e os RNFs elicitados. As decises arquiteturais basicamente
consistiram em: escolha da plataforma OSGi que iramos utilizar; escolha do modelo de
componentes que seria seguido para desenvolver os componentes da soluo proposta;
escolha da tecnologia que seria utilizada para expor os servios na forma de web services; escolha da tecnologia que seria utilizada para tratar os descritores como objetos
Java; e por fim, qual seriam os critrios utilizados na operao de descoberta de servios.
Um dos principais objetivos desse trabalho efetuar um estudo sobre variabilidades
dinmicas em LPSOSSC e, como resultado, foi desenvolvido o DYMOS, que um
framework cujo princpio suportar esse tipo de variabilidade nessa categoria de LPS.
O desenvolvido do DYMOS foi baseado em tecnologias OSGi, que consiste em um
conjunto de especificaes para desenvolvimento de software Java na forma de mdulos
(bundles). O OSGi oferece benefcios como reduo na complexidade dos componentes,
permite o reuso, atualizaes e adaptaes dinmicas, e por esses motivos foi adotado
como plataforma de execuo.
Abaixo sero descritas com mais detalhes as principais decises arquiteturais que
permitiram projetar e implementar o DYMOS:
Plataforma OSGi Por se tratar de um conjunto de especificaes, o OSGi possui diversas distribuies que so mantidas por diversas organizaes. Dentre essas
distribuies, possvel citar as mais conhecidas: o Equinox, que mantido pela
Eclipse Foundation; o Knoplerfish, que mantido pela Makewave (Gatespace Telematics); o Felix, que mantido pela comunidade e distribudo sob a licena
Apache.
A distribuio adotada como plataforma de execuo do framework foi o Apa-
45
che Felix. Esta distribuio possui uma documentao de acesso fcil, que inclui
documentao online, fruns, grupos de discusso e tutoriais. Esses fatores influenciaram positivamente na escolha da ferramenta pois facilitou consideravelmente
o aprendizado, agilizando a sua utilizao.s
Modelo de Componentes Os modelos de componentes consistem em especificaes
que foram seguidas para permitir o desenvolvimento dos componentes OSGi. Atualmente, os principais modelos de componentes so o BluePrint, Declarative Services e o iPOJO.
Dentre estas opes, foi adotado o iPOJO como modelo de componente pois ele
possui caractersticas que no so suportadas pelos demais modelos. Dentre as
caractersticas, podemos citar a possibilidade de utilizar Java Annotations para
efetuar a configurao dos servios, o suporte a composio de servios e controle
do seu ciclo de vida. Estes fatores contriburam para a escolha do iPOJO pois
este se mostrou um modelo de componente que permite o desenvolvimento dos
componentes de uma forma mais rpida e simples.
Expor Servios como Web Services Para expor Servios como Web Services, foi adotado o CXF DOSGi. Esse framework foi adotado por ser compatvel com o iPOJO
e pelo fcil acesso a documentao por meio de material online, fruns e grupos de
discusso. Alm disso, outro fator que contribuiu para a adoo desse framework
foi o suporte oferecido ao uso de servios de uma forma distribuda, ou seja, que
esto em execuo em diferentes instncias da plataforma OSGi.
Tratar informaes descritas em XML As informaes sobre os Servios e Variabilidades so descritas na forma de XML. Ento, como uma forma de atender o requisito no-funcional RNF1 e facilitar o gerenciamento das informaes durante a
execuo das operaes, as informaes precisam ser convertidas em objetos Java.
Inicialmente foi adotado o XStream3 , que consiste em um conjunto de bibliotecas
para converter objetos Java em XML e vice-versa. No entanto, existiram alguns
problemas de compatibilidade entre as bibliotecas pois ainda no existia uma verso compatvel com OSGi. Por esse motivo, foi decidido adotar o JAXB, que
consiste em um conjunto de bibliotecas que so providas por meio do Java que
possuem compatibilidade com a tecnologia OSGi. O JAXB possibilitou a gerao dos metamodelos de Servios e Variabilidades a partir de estruturas definidas
3 http://xstream.codehaus.org/
46
RF1 RF2 RF3 RF4 RF5 RF6 RF7 RF8 RF9 RNF1 RNF2
ApplicationService
ServiceDescriptor
VariabilityDescriptor
WSResolver
HotBuildContext
ServiceContext
Ser apresentada no prximo captulo (Captulo 4), uma avaliao preliminar que
demonstra a aplicao da abordagem proposta neste trabalho.
47
4
Uma Avaliao Preliminar
4.1
MobiLine
48
4.1. MOBILINE
49
4.2
GREat Tour
4.2.1
Anlise e Definies
Como j foi mencionado, a execuo da avaliao foi efetuada com base em um conjunto
de anlises e definies. As anlises auxiliaram na identificao de o que necessita ser
efetuado para permitir variabilidades dinmicas no GREat Tour, utilizando a abordagem
proposta por meio do DYMOS. Adicionalmente, as definies permitiram determinar
como ser efetuada a avaliao.
Abaixo est destacado o conjunto de anlises efetuadas:
1. Anlise do modelo de features do produto a fim de selecionar features e pontos de
variao para serem utilizados na avaliao.
2. Anlise da implementao dos artefatos referentes s features selecionadas, a fim
de identificar as tecnologias utilizadas e verificar a compatibilidade com o OSGi.
3. Analisar os casos de incompatibilidade, definindo uma estratgia para efetuar a
migrao da implementao atual para um modelo de implementao compatvel
com OSGi.
50
4.2.2
Esta etapa consistiu em analisar o modelo de features do GREat Tour com a finalidade de
selecionar features e pontos de variao que seriam utilizados na avaliao da abordagem
proposta. Por meio da Figura 4.2 apresentado de forma parcial o modelo de features do
GREat Tour. A notao utilizada para desenhar tal modelo foi proposta por (Czarnecki
and Eisenecker, 2000).
No modelo apresentado por meio da Figura 4.2 possvel visualizar as features selecionadas para a avaliao. Tais features consistem em funcionalidades referentes a
51
Segurana (Privacy), que determina se o acesso a aplicao ser concedido por meio de
Autorizao (Authorization) que, por ser uma feature opcional, no ter critrios de segurana para acesso; a Visualizao de Documentos (Show Document), que especifica o
tipo de mdia que estar disponvel para visualizao, que pode ser Texto (Text), Imagem
(Image) ou Vdeo (Video); o vdeo como um tipo de mdia tambm considerado uma
feature, que pode possuir um provedor local ou externo.
Dessa forma, de acordo com as features selecionadas, possvel sumarizar os pontos de variao, que consistem em Modo de Acesso, Tipo de Mdia disponvel para
Visualizao e Provedor de Stream de Vdeo.
Na prxima seo ser descrita a anlise efetuada sobre a implementao dos artefatos referentes s features selecionadas.
4.2.3
Analisando os Artefatos
Nesta etapa, foi efetuada uma anlise na implementao dos artefatos referentes s features selecionadas. O objetivo desta anlise identificar os artefatos, suas implementaes,
as tecnologias utilizadas e, por fim, verificar a compatibilidade com o OSGi.
De forma a possibilitar esta anlise, inicialmente foi necessrio efetuar a identificao dos artefatos. Isto foi possvel por meio de uma inspeo no-sistemtica nas implementaes da aplicao, de uma forma abrangente, buscando nestas implementaes
a funcionalidades ligadas s features.
Como resultado desta anlise, foi possvel visualizar a relao entre features, artefatos e implementaes, que apresentada por meio da Tabela 4.1.
Features
Artefatos
Privacy
LoginService
LocalVideoProviderService, ExternalVideoProviderService
Tabela 4.1 Relao entre Features e Artefatos
Adicionalmente, por meio de uma anlise nas implementaes dos artefatos, foi possvel observar que suas funes so disponibilizadas na forma de Servios Web. utilizado o Java como linguagem de programao, Apache Axis1 como framework para
construo de web services e o Apache Tomcat2 como servidor web.
1 http://axis.apache.org/axis/
2 http://tomcat.apache.org/
52
4.2.4
Modularizando Servios
De acordo com a anlise efetuada na etapa anterior, foi observado que os artefatos LoginService, TextService, ImageService, VideoService (LocalVideoProviderService e ExternalVideoProviderService) no possuem implementaes compatveis com OSGi, ou
seja, no possvel efetuar a implantao desses servios em um container OSGi.
Nesta etapa foram analisados estes casos de incompatibilidade, em seguida, foi definida uma estratgia para efetuar a portabilidade da implementao atual para um modelo
de implementao compatvel com OSGi. A estratgia utilizada para efetuar a portabilidade consiste em separar Interfaces (API) e Implementaes, de modo que sejam empacotadas em bundles diferentes. Esta estratgia considerada uma boa prtica (best
practice) e prov uma maior flexibilidade a aplicao (Hall et al., 2011; de Castro Alves, 2011). Para efetuar a gerao dos artefatos em arquivos JAR, foi utilizado o Apache
Maven3 3.0.4 com o plugin maven-bundle-plugin4 , que permitiu a configurao dos
metadados do artefato de uma forma simples.
A anlise efetuada sobre estas implementaes permitiu identificar os principais mtodos utilizados para prover uma determinada funcionalidade, determinar quais so os
mtodos que iro compor a API do servio e verificar a existncia de interao desses
artefatos com componentes que no tm compatibilidade com OSGi. Como parte dos
resultados obtidos por meio desta anlise, percebeu-se que todos os servios utilizam
acesso a banco de dados para prover suas funcionalidades, tornando necessrio a implementao de um componente OSGi capaz de prover este tipo de acesso aos servios que
sero migrados, conforme apresentado na Figura 4.3.
3 http://maven.apache.org/
4 http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
53
O banco de dados utilizado o MySQL5 5.6, o acesso feito por meio de JDBC
(Java Database Connectivity) com o driver verso 5.1.
Ser apresentado na prxima seo detalhes sobre a implementao do componente
responsvel por prover acesso ao banco de dados.
MySQLServiceProvider
definido por meio do OSGi Service Platform Release 4 um conjunto de especificaes
que permite a criao de conexes a banco de dados utilizando JDBC. Estas especificaes esto contidas na API DataSourceFactory6 e definem mtodos para criao de trs
tipos de conexo: DataSource, ConnectionPoolDataSource e XADataSource.
No componente MySQLServiceProvider, foi implementado apenas a criao de conexes do tipo DataSource pois as operaes efetuadas nas implementaes atuais do
artefatos no necessitam de suporte a pool de conexes ou transaes. Para isso, foi
criada a classe MySQLDataSourceFactory que prov uma implementao que segue a
especificao de DataSourceFactory, conforme apresentado na Figura 4.4.
5 http://www.mysql.com/
6 http://www.osgi.org/javadoc/r4v42/org/osgi/service/jdbc/DataSourceFactory.html
54
55
Conforme possvel observar na Figura 4.5, a configurao do MySQLDataSourceFactory como um componente iPOJO, consiste na definio das tags component
e instance. A descrio da tag component efetuada indicando o nome do componente por meio do atributo name e a classe que prov a sua implementao por
meio do atributo classname. A descrio da tag instance permite a configurao
da instncia do componente, indicando as propriedades e valores necessrios para a sua
instanciao.
Sero apresentados na prxima seo detalhes sobre a modularizao do servio
referente ao artefato de Privacidade (Privacy).
LoginService
Conforme j mencionado anteriormente, a estratgia utilizada na modularizao dos
servios considerada uma boa prtica, que consiste em separar Interfaces (API) e Implementaes, de modo que sejam empacotadas em bundles diferentes. Como parte do
resultado da anlise das implementaes, foram identificados os principais mtodos utilizados para prover a funo de autenticao na aplicao. Isso permitiu determinar os
mtodos que iro compor a API do componente LoginService, e que ir direcionar a sua
implementao. apresentado por meio da Figura 4.6 a especificao do componente
LoginService.
56
Conforme apresentado na Figura 4.6, a especificao do componente recebe a anotao @WebService, indicando que suas funcionalidades estaro disponveis na forma
de servios web. O principal mtodo identificado para prover a funcionalidade de autenticao foi o auth, que recebe como parmetro o login e o password do usurio.
apresentado por meio da Figura 4.7 a configurao parcial do arquivo POM (Project
Object Model), que utilizado pelo Apache Maven para gerenciar as dependncias entre
artefatos e efetuar a gerao dos bundles.
57
58
Conforme apresentado na Figura 4.8, foram atribudas implementao as anotaes @Component, que define que a implementao corresponde a um tipo de componente; @Provides, que indica que o componente responsvel por prover um servio; e @WebService, que indica que o componente deve estar disponvel na forma
de servio web. O atributo dsf do tipo DataSourceFactory, que corresponde a uma fbrica de conexes do tipo DataSource, recebeu a anotao @Requires. Esta anotao
determina uma dependncia entre os servios e permite que o framework efetue a injeo desta dependncia, de acordo com o servio disponvel no contexto OSGi. O servio
que dever ser injetado nesta dependncia o MySQLServiceProvider, que prov uma
implementao para esta fbrica de conexes.
Conforme mencionado anteriormente, o principal mtodo identificado para prover
a funcionalidade de autenticao foi o auth, que recebe como parmetro o login e
o password do usurio e responsvel por verificar a sua autenticidade. Para permitir
essa verificao, efetuada uma consulta no banco de dados por meio de uma conexo
obtida com o mtodo openConn(). A verificao efetuada e em seguida retornado
um valor do tipo boolean, com true caso a autenticao seja validada ou false caso
contrrio. Por fim, a conexo finalizada por meio do mtodo closeConn().
Os detalhes sobre os mtodos openConn() e closeConn() so apresentados por
meio da Figura 4.9. Para estabelecer uma conexo com o banco de dados, por meio do
mtodo openConn() foram atribudos valores para propriedades que so utilizadas para
criar a conexo, como DataSourceFactory.JDBC_URL, DataSourceFactory.JDBC_USER
e DataSourceFactory.JDBC_PASSWORD. Por meio do atributo dsf, acessado o mtodo createDataSource passando as propridades como parmetro. Com isso, obtido
um objeto DataSource e, a partir deste, uma conexo estabelecida e atribuda ao atributo connection para que possa ser utilizado pelo mtodo auth, na operao de
autenticao. O mtodo closeConn() utilizado para finalizar a conexo.
59
Figura 4.9 LoginServiceProvider: Mtodos para estabelecer e finalizar uma conexo com o
banco de dados
60
org.apache.cxf.ws.address especifica o endereo em que o servio deve estar disponvel. O valor http://0.0.0.0:9090/loginService foi atribudo a esta propriedade,
indicando o endereo do servio. O valor 0.0.0.0 do endereo determina que o
servio estar acessvel atravs de todas as interfaces de rede, o valor 9090 indica a porta onde o servio est em execuo e loginService representa o nome
de acesso do servio.
O iPOJO efetua a criao da instncia e o Apache CXF utiliza as informaes atribudas na configurao para efetuar a publicao do Servio Web. Por fim, de acordo
com a Figura 4.11, efetuado a configurao do arquivo POM de modo a permitir o
gerenciamento das dependncias do componente e a gerao do bundle referente ao LoginServiceProvider.
61
OSGi, assim como ocorreu com o componente LoginService. Por meio da tag dependency estabelecida uma dependncia com o artefato LoginService, indicando o groupId, artifactId e version do componente. A dependncia entre os artefatos estabelecida
pois o componente LoginServiceProvider prov uma implementao para o componente
LoginService.
Por meio do plugin maven-bundle-plugin feita a configurao dos metadados
do bundle, indicando um valor para o atributo SymbolicName e, por meio do atributo
Private-Package determinada a remoo da visibilidade do pacote onde est localizada a implementao do servio. Essas configuraes permitem o empacotamento do
bundle referente ao componente LoginServiceProvider, que contm a implementao do
componente LoginService.
A migrao dos demais artefatos descritos na Seo 4.2.3 para o modelo de componentes OSGi seguiu a mesma estratgia utilizada na implementao dos componentes
LoginService e LoginServiceProvider. As implementaes referentes a estes artefatos
esto disponveis em https://github.com/dhiegoabrantes/dymos-evaluation-ws.
4.2.5
Nesta etapa foi efetuada a descrio dos servios e variabilidades que compem a configurao do GREat Tour. A descrio destes elementos permite o gerenciamento dos
servios de modo a suportar variabilidades dinmicas, efetuando reconfiguraes em
tempo de execuo, de acordo com mudanas no ambiente. apresentada na Figura
4.12 a descrio dos servios que compem a configurao do produto.
62
<?xml version="1.0"?>
<services>
<service id="loginService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.LoginServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.LoginService</service-spec>
</service>
<service id="textService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.TextServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.TextService</service-spec>
</service>
<service id="imageService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.ImageServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.ImageService</service-spec>
</service>
<service id="localVideoService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.LocalVideoProviderServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.VideoService</service-spec>
</service>
<service id="externalVideoService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.ExternalVideoProviderServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.VideoService</service-spec>
<alternative-service ref="localVideoService" priority="1" />
</service>
</services>
Conforme a Figura 4.12, os servios descritos so relacionados aos artefatos identificados a partir da anlise do modelo de features do GREat Tour. De acordo com a
mesma figura, o DS composto por loginService, que possui a especificao definida
por meio da interface LoginService e a implementao provida pela classe LoginServiceImpl; textService, que possui a especificao definida por meio da interface TextService e a implementao provida pela classe TextServiceImpl; imageService, que
possui a especificao definida por meio da interface ImageService e a implementao
provida pela classe ImageServiceImpl; localVideoService, que possui a especificao definida por meio da interface VideoService e a implementao provida pela classe
LocalVideoProviderServiceImpl; e, por fim, o externalVideoService, que tambm
possui a especificao definida por meio da interface VideoService e a implementao
provida pela classe ExternalVideoProviderServiceImpl. atribudo ao servio externalVideoService o localVideoService como servio alternativo. Com isso, quando
houver uma requisio pelo servio externalVideoService e houver indisponibilidade,
63
Os pontos de variao so descritos por meio da tag variability, que recebeu como
ID o nome da feature respectiva. Cada um dos pontos de variao so associados a
variantes, que so descritas por meio da tag variant.
Conforme a Figura 4.13, foram descritos os pontos de variao privacy, que
est relacionado a feature Privacy, definindo authentication como uma variante;
showDocument, que est relacionado a feature Show Document, definindo textMedia e imageMedia como variantes.
De acordo com o modelo de features, o ponto de variao showDocument recebe-
64
ria uma terceira variante, que seria o provedor de stream de vdeo. No entanto, como esta
variante pode ser alternada entre um provedor local ou externo, foi decidido a decompor em um novo ponto de variao, o video, que est relacionado a feature Video,
definindo localVideo e externalVideo como variantes;
Na Seo 4.4 ser detalhado a anlise e adequao da aplicao para notificar o
DYMOS sobre mudanas no ambiente e utilizar a funo de descoberta de servios.
Posteriormente, na Seo 4.5 ser feita uma discusso sobre os resultados obtidos por
meio desta avaliao.
4.3
CIn Tour
O CIn Tour um Guia de Visitas Mvel e Sensvel ao Contexto criado a partir da MobiLine, assim como o GREat Tour. Esta aplicao foi implementada para auxiliar visitantes a conhecer o CIn (Centro de Informtica) da Universidade Federal de Pernambuco.
A aplicao executada no dispositivo mvel do visitante e fornece informaes
sobre os pesquisadores e ambientes do laboratrio que so visitados. O seu comportamento se adapta de acordo com o contexto atual do visitante, que abrange a localizao
do visitante, seu perfil ou preferncias, as caractersticas do seu dispositivo mvel, e informaes a respeito de outras pessoas presentes na mesma sala em que o visitante se
encontra.
Ser apresentado nesta seo as etapas executadas na avaliao do uso do DYMOS
para permitir variabilidades dinmicas no CIn Tour. Como o CIn Tour e o GREat Tour
so derivados da mesma LPS, possvel ambos possuam features em comum. Dessa
forma, esperado como resultado desta avaliao a possibilidade de reuso dos artefatos
migrados para o GREat Tour, necessitando apenas o ajuste dos Descritores de Servios
e Variabilidades, de acordo com a configurao do CIn Tour.
As etapas executadas sero detalhadas nas prximas sees.
4.3.1
Esta etapa consistiu em analisar o modelo de features do CIn Tour com a finalidade de
identificar features e pontos de variao em comum com o modelo de features do GREat
Tour. De acordo com esta anlise foi possvel perceber a ausncia de algumas features
que esto presentes no GREat Tour como Privacy e Video, evidenciando que o CIn
Tour possui um nmero menor de features, o que a torna uma aplicao de menor porte.
65
Por meio da Figura 4.14 apresentado de forma parcial o modelo de features do CIn
Tour, de acordo com as features identificadas.
66
4.3.2
Nesta etapa foi efetuada a descrio dos servios e variabilidades que compem a configurao do CIn Tour. A descrio destes elementos permite o gerenciamento dos servios de modo a suportar variabilidades dinmicas, efetuando reconfiguraes em tempo
de execuo, de acordo com mudanas no ambiente. apresentado na Figura 4.15 a
descrio dos servios que compem a configurao do produto.
<?xml version="1.0"?>
<services>
<service id="textService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.TextServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.TextService</service-spec>
</service>
<service id="imageService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.ImageServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.ImageService</service-spec>
</service>
</services>
Conforme a Figura 4.15, os servios descritos so relacionados aos artefatos ligados s features identificadas a partir da anlise do modelo de features do CIn Tour. De
acordo com a mesma figura, o DS composto por textService, que possui a especificao definida por meio da interface TextService e a implementao provida pela classe
TextServiceImpl; e imageService, que possui a especificao definida por meio da
interface ImageService e a implementao provida pela classe ImageServiceImpl;
apresentado por meio da Figura 4.13, a descrio das variabilidades presentes na
configurao do CIn Tour. As variabilidades esto descritas de acordo com as features
do produto e seus pontos de variao, que foram sumarizados por meio da anlise do
modelo de features, descrita na Seo 4.3.1. De acordo com esta anlise, foi possvel
sumarizar apenas um ponto de variao que consiste em Tipo de Mdia disponvel para
Visualizao.
67
<?xml version="1.0"?>
<variabilities>
<variability id="showDocument">
<variant id="textMedia">
<service-ref ref="textService" />
</variant>
<variant id="imageMedia">
<service-ref ref="imageService" />
</variant>
</variability>
</variabilities>
Conforme a Figura 4.13, foi descrito o ponto de variao showDocument, que est
relacionado a feature Show Document, definindo textMedia e imageMedia como
variantes;
Na Seo 4.4 ser detalhado a anlise e adequao da aplicao para notificar o
DYMOS sobre mudanas no ambiente e utilizar a funo de descoberta de servios.
Posteriormente, na Seo 4.5 ser feita uma discusso sobre os resultados obtidos por
meio desta avaliao.
4.4
Ser descrito nesta seo as etapas executadas para permitir a integrao das aplicaes cliente, GREat Tour e CIn Tour, com o DYMOS, a fim de utilizar as principais
funcionalidades providas, que consiste na reconfigurao de variabilidades dinmicas e
descoberta de servios. Para permitir a integrao entre a aplicao e o DYMOS, foi
desenvolvida uma biblioteca Java, denominada DymosClientLib, que prov a possibilidade da aplicao cliente utilizar as funes providas pelo DYMOS.
A biblioteca desenvolvida considerada leve por ser composta basicamente por classes como VariabilityContext, que permite o suporte a reconfigurao de variabilidades
dinmicas e o ServiceEndpointFactory, que permite o suporte a descoberta de servios. A utilizao desta biblioteca permite a integrao entre a aplicao cliente e o DYMOS. Para efetuar a integrao, foi necessrio analisar as implementaes da aplicao
de modo a determinar como a adequao seria possibilitada.
Inicialmente foi analisado a forma como ocorria a interao entre a aplicao cliente e os servios. Como resultado desta anlise, observou-se que a aplicao utiliza a
plataforma Android e que para cada servio utilizado existe uma classe correspondente.
68
69
alizada antes de cada execuo, utilizando o mtodo getEndpoint da classe ServiceEndpointFactory, informando o ID do servio requerido. Posteriormente, as informaes so utilizadas para estabelecer uma comunicao com o servio e executar uma
determinada operao.
Figura 4.18 Aplicao Cliente: Descoberta de Servio por meio da biblioteca DymosClientLib
Figura 4.19 Aplicao Cliente: Reconfigurao de variabilidades por meio da biblioteca DymosClientLib
4.5
Consideraes Finais
Foi apresentado neste captulo uma avaliao preliminar que demonstra a aplicao da
abordagem proposta neste trabalho em dois produtos derivados de uma mesma LPS,
70
71
5
Concluso
Um passo frente e voc no est mais no mesmo lugar
One step forward and you are not in the same place
CHICO SCIENCE (Um Passeio No Mundo Livre, Afrociberdelia)
5.1
Contribuies
72
Mecanismo de Descoberta de Servio, que permite agregar critrios para a seleo do servio mais adequado, de acordo com uma requisio; Funcionalidades
Interoperveis por meio de Servios Web.
Avaliao Preliminar: A execuo da Avaliao Preliminar nos permitiu averiguar a utilidade e efetividade da soluo proposta neste trabalho. Como parte
da avaliao, foi necessrio analisar implementaes de servios legados e, em
seguida, modelar e implementar estes servios seguindo o modelo de implementao OSGi. Os Sistemas derivados da LPS MobiLine, GREat Tour e CIn Tour,
foram adaptados para utilizar o DYMOS Framework e, com isso, alm de continuar tratando reconfiguraes comportamentais, tambm passaram a tratar reconfiguraes de componentes.
5.2
Trabalhos Futuros
73
Referncias
Alferez, G. and Pelechano, V. (2011). Context-aware autonomous web services in software product lines. In Software Product Line Conference (SPLC), 2011 15th International, pages 100109. 1, 4, 15, 22
Alhazbi, S. and Jantan, A. (2006). Multi-level mediator-based technique for classes
hot swapping in java applications. In Information and Communication Technologies,
2006. ICTTA 06. 2nd, volume 2, pages 28892892. 43
Ali, N. and Babar, M. (2009). Modeling service oriented architectures of mobile applications by extending soaml with ambients. In Software Engineering and Advanced
Applications, 2009. SEAA 09. 35th Euromicro Conference on, pages 442449. 3
Alves, V., Matos, P., Cole, L., Borba, P., and Ramalho, G. (2005). Extracting and evolving mobile games product lines. In Proceedings of the 9th international conference
on Software Product Lines, SPLC05, pages 7081, Berlin, Heidelberg. SpringerVerlag. 14
Bencomo, N., Lee, J., and Hallsteinsen, S. O. (2010). How dynamic is your dynamic
software product line? In SPLC Workshops, pages 6168. 2, 15
Bencomo, N., Hallsteinsen, S., and Santana de Almeida, E. (2012). A view of the
dynamic software product line landscape. Computer, 45(10), 3641. 2, 15
Carter, S. (2007). The New Language of Business: SOA e Web 2.0. IBM Press. 17
Clements, P. and Northrop, L. (2001). Software Product Lines: Practices and Patterns.
Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. 9, 12, 13, 14
Clements, P., Garlan, D., Little, R., Nord, R., and Stafford, J. (2003). Documenting software architectures: views and beyond. In Software Engineering, 2003. Proceedings.
25th International Conference on, pages 740741. 28
Czarnecki, K. and Eisenecker, U. (2000). Generative programming: methods, tools, and
applications. Addison Wesley. 51
de Castro Alves, A. (2011). OSGi in Depth. Manning Publications Co., Greenwich, CT,
USA, 1st edition. 27, 53
74
REFERNCIAS
Demirkan, H., Kauffman, R. J., Vayghan, J. A., Fill, H.-G., Karagiannis, D., and Maglio,
P. P. (2008). Service-oriented technology and management: Perspectives on research
and practice for the coming decade. Electron. Commer. Rec. Appl., 7(4), 356376. 2
Dhungana, D., Grnbacher, P., and Rabiser, R. (2007). Domain-specific adaptations of
product line variability modeling. In Situational Method Engineering, pages 238251.
2, 15
Dirksen, J. (2013). SOA Governance in Action: REST and Web Service architecture.
Manning Publication Co., Shelter Island, NY 11964. 17
Elfatatry, A. and Layzell, P. (2004). Negotiating in service-oriented environments. Commun. ACM, 47(8), 103108. 16
Endrei, M., Ang, J., Arsanjani, A., Chua, S., Comte, P., Krogdahl, P., Luo, M., and
Newling, T. (2004). Patterns: Service-Oriented Architecture and Web Services. IBM
Redbooks. 17
Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR, Upper Saddle River, NJ, USA. 17, 18, 19
Erl, T. (2007). SOA Principles of Service Design (The Prentice Hall Service-Oriented
Computing Series from Thomas Erl). Prentice Hall PTR, Upper Saddle River, NJ,
USA. 3, 4, 16, 18, 22, 24
Escoffier, C., Hall, R., and Lalanda, P. (2007). ipojo: an extensible service-oriented
component framework. In Services Computing, 2007. SCC 2007. IEEE International
Conference on, pages 474481. 5, 24, 28
Galster, M. (2010). Enhancing runtime variability in software product lines through
service-orientation. In SPLC Workshops, pages 4752. 1, 2, 15, 19
Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design patterns: elements
of reusable object-oriented software. Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA. 44
Garcia-Gonzalez, J., Gacitua-Decar, V., and Pahl, C. (2010). Service registry: A key
piece to enhance reuse in soa. The Architecture Journal, 21. 19
75
REFERNCIAS
Gomaa, H. (2004). Designing Software Product Lines with UML: From Use Cases
to Pattern-Based Software Architectures. Addison Wesley Longman Publishing Co.,
Inc., Redwood City, CA, USA. 9
Gomaa, H. and Hashimoto, K. (2011). Dynamic software adaptation for service-oriented
product lines. In Proceedings of the 15th International Software Product Line Conference, Volume 2, SPLC 11, pages 35:135:8, New York, NY, USA. ACM. 5, 23
Hall, R., Pauls, K., McCulloch, S., and Savage, D. (2011). OSGi in Action: Creating
Modular Applications in Java. Manning Publications Co., Greenwich, CT, USA, 1st
edition. 27, 53
Hallsteinsen, S., Stav, E., Solberg, A., and Floch, J. (2006). Using product line techniques to build adaptive systems. In Software Product Line Conference, 2006 10th
International, pages 10 pp.150. 1, 2, 4, 15, 24, 37
Hallsteinsen, S., Hinchey, M., Park, S., and Schmid, K. (2008). Dynamic software
product lines. Computer, 41(4), 9395. 1, 2, 15, 38
Istoan, P., Nain, G., Perrouin, G., and Jezequel, J.-M. (2009). Dynamic software product
lines for service-based systems. In Proceedings of the 2009 Ninth IEEE International
Conference on Computer and Information Technology - Volume 02, CIT 09, pages
193198, Washington, DC, USA. IEEE Computer Society. 19
Josuttis, N. (2007). Soa in Practice: The Art of Distributed System Design. OReilly
Media, Inc. 19
Khezrian, M., Wan Kadir, W. M. N., Ibrahim, S., Mohebbi, K., Munusamy, K., and
Tabatabaei, S. G. H. (2010). An evaluation of state-of-the-art approaches for web
service selection. In Proceedings of the 12th International Conference on Information
Integration and Web-based Applications & Services, iiWAS 10, pages 885889,
New York, NY, USA. ACM. 39
Kim, M., Jeong, J., and Park, S. (2005). From product lines to self-managed systems:
an architecture-based runtime reconfiguration framework. In Proceedings of the 2005
workshop on Design and evolution of autonomic application software, DEAS 05,
pages 17, New York, NY, USA. ACM. 1, 2, 4, 15, 24
76
REFERNCIAS
Kon, F., Romn, M., Liu, P., Mao, J., Yamane, T., Magalhes, L., and Campbell, R.
(2000). Monitoring, security, and dynamic configuration with the dynamictao reflective orb. In J. Sventek and G. Coulson, editors, Middleware 2000, volume 1795 of
Lecture Notes in Computer Science, pages 121143. Springer Berlin Heidelberg. 3
Kruchten, P., Obbink, H., and Stafford, J. (2006). The past, present, and future for
software architecture. Software, IEEE, 23(2), 2230. 28
Krueger, C. (2002). Eliminating the adoption barrier. Software, IEEE, 19(4), 2931. 13,
14
Krut, R. and Cohen, S. (2008). Service-oriented architectures and software product lines
- putting both together. In SPLC, page 383. 2, 16
Lee, J., Kotonya, G., and Robinson, D. (2012). Engineering service-based dynamic
software product lines. Computer, 45(10), 4955. 2
Linden, F. J. v. d., Schmid, K., and Rommes, E. (2007). Software Product Lines in
Action: The Best Industrial Practice in Product Line Engineering. Springer-Verlag
New York, Inc., Secaucus, NJ, USA. 10, 11, 13, 14
Marinho, F. G., Andrade, R. M., Werner, C., Viana, W., Maia, M. E., Rocha, L. S.,
Teixeira, E., Filho, J. B. F., Dantas, V. L., Lima, F., and Aguiar, S. (2012). Mobiline: A
nested software product line for the domain of mobile and context-aware applications.
Science of Computer Programming, (0). 3, 48, 49
McGovern, J., Tyagi, S., Stevens, M., and Mathew, S. (2003). Java Web Services Architecture. Elsevier Science. 17, 19
Medeiros, F. M. (2010). Sople-de: An approach to design service-oriented product line
architecture. 19
Microsoft Corporation (2005). Web services dynamic discovery (ws-discovery). 18
Niebuhr, D., Rausch, A., Klein, C., Reichmann, J., and Schmid, R. (2009). Achieving
dependable component bindings in dynamic adaptive systems - a runtime testing approach. In Self-Adaptive and Self-Organizing Systems, 2009. SASO 09. Third IEEE
International Conference on, pages 186197. 1
77
REFERNCIAS
Oreizy, P., Medvidovic, N., and Taylor, R. N. (1998). Architecture-based runtime software evolution. In Proceedings of the 20th international conference on Software engineering, ICSE 98, pages 177186, Washington, DC, USA. IEEE Computer Society.
43
Oreizy, P., Gorlick, M., Taylor, R., Heimhigner, D., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D., and Wolf, A. (1999). An architecture-based approach to selfadaptive software. Intelligent Systems and their Applications, IEEE, 14(3), 5462. 1,
4, 24
Papazoglou, M. P. and Georgakopoulos, D. (2003). Introduction: Service-oriented computing. Commun. ACM, 46(10), 2428. 16, 18
Parra, C., Blanc, X., and Duchien, L. (2009). Context awareness for dynamic serviceoriented product lines. In Proceedings of the 13th International Software Product
Line Conference, SPLC 09, pages 131140, Pittsburgh, PA, USA. Carnegie Mellon
University. 21, 22
Parra, C. A., Quinton, C., and Duchien, L. (2012). Capucine: Context-aware serviceoriented product line for mobile apps. ERCIM News, 2012(88). 3
Pohl, K., Bckle, G., and Linden, F. J. v. d. (2005). Software Product Line Engineering:
Foundations, Principles and Techniques. Springer-Verlag New York, Inc., Secaucus,
NJ, USA. 3, 10, 11, 12, 13, 14, 34, 48
Raatikainen, M., M. V. and Mannisto, T. (2007). Comparison of service and software
product family modeling. In In Proceedings of the 11th International Software Product Line Conference (SPLC 07) - 1st International Workshop on Service Oriented
Architectures and Product Lines (SOAPL 07), Kyoto. Japan. 2, 15, 16, 19
Ribeiro, H. B. G. (2010). An approach to implement core assets in service-oriented
product lines. 19
Rocha, L. S., Castro, C., Machado, J., and Andrade, R. (2007). Using dynamic reconfiguration and context notification for ubiquitous software development. In Proceedings
of 21st Brazilian Symposium on Software Engineering (SBES-XXI), pages 219235. 3
Rosenmller, M., Siegmund, N., Pukall, M., and Apel, S. (2011). Tailoring dynamic
software product lines. SIGPLAN Not., 47(3), 312. 1, 14
78
REFERNCIAS
Segura, S., Benavides, D., Ruiz-Corts, A., and Trinidad, P. (2007). A taxonomy of
variability in web service flows. In Service Oriented Architectures and Product Lines
(SOAPL 07), Kyoto. Japan. 2, 15, 19
Shaw, M. and Garlan, D. (1996). Software architecture: perspectives on an emerging
discipline. Prentice-Hall, Inc., Upper Saddle River, NJ, USA. 28
Silva, J. R. F., Silva, F. A. P., Nascimento, L. M., Martins, D. A. O., and Garcia, V. C.
(2013). The Dynamic Aspects of Product Derivation in DSPL: a Systematic Literature
Review. Proceedings of the 2013 IEEE 14thInternational Conference on Information
Reuse and Integration, pages 466473. 22
Smith, D. and Lewis, G. (2009). Service-oriented architecture (soa) and software product
lines: Preimplementation decisions. In In Proceedings of the 13th International Software Product Line Conference (SPLC 09) - 3st International Workshop on Service
Oriented Architectures and Product Lines (SOAPL 09), San Francisco, CA, USA. 2,
19
Tan, L. (2001). SwapBox: a Hot-Swapping Framework for Swappable JavaBeans. Masters thesis, Department of System and Computer Engineering, Carleton University,
Ottawa, Canada. 43
Tiwari, S., Rathore, S., and Gupta, A. (2012). Selecting requirement elicitation techniques for software projects. In Software Engineering (CONSEG), 2012 CSI Sixth
International Conference on, pages 110. 26
Trujillo, S., A. S. and Kaestner, C. (2007). Product lines that supply other product lines:
A service-oriented approach. In In Proceedings of the 11th International Software
Product Line Conference (SPLC 07) - 1st International Workshop on Service Oriented Architectures and Product Lines (SOAPL 07), Kyoto. Japan. 2, 15, 19
Ullah, S., Iqbal, M., and Khan, A. (2011). A survey on issues in non-functional requirements elicitation. In Computer Networks and Information Technology (ICCNIT),
2011 International Conference on, pages 333340. 26
Viana, W. and Andrade, R. M. (2008). Xmobile: A mb-uid environment for semiautomatic generation of adaptive applications for mobile devices. Journal of Systems
and Software, 81(3), 382 394. <ce:title>Selected Papers from the 2006 Brazilian
Symposia on Databases and on Software Engineering</ce:title>. 3
79
REFERNCIAS
Wolfinger, R., Reiter, S., Dhungana, D., Grunbacher, P., and Prahofer, H. (2008). Supporting runtime system adaptation through product line engineering and plug-in techniques. In Composition-Based Software Systems, 2008. ICCBSS 2008. Seventh International Conference on, pages 2130. 2, 15
Ye, E., Moon, M., Kim, Y., and Yeom, K. (2007). An approach to designing serviceoriented product-line architecture for business process families. In Advanced Communication Technology, The 9th International Conference on, volume 2, pages 999
1002. 2, 19
Yu, H. Q. and Reiff-Marganiec, S. (2008). Non-functional property based service selection: A survey and classification of approaches. In Non Functional Properties and
Service Level Agreements in Service Oriented Computing Workshop co-located with
The 6th IEEE European Conference on Web Services. 39, 47
Yu, J., Lalanda, P., and Bourret, P. (2010). An approach for dynamically building and
managing service-based applications. In Services Computing Conference (APSCC),
2010 IEEE Asia-Pacific, pages 5158. 2, 19, 22
Zi-yun, D. and Ru-long, W. (2011). Efsm task scheduling model research in the soa
integration platform. In Computer and Management (CAMAN), 2011 International
Conference on, pages 13. 17
80
Apndice
81
A
Componentes Descritores
A.1
Descritor de Servios
82
A.2
Descritor de Variabilidades
83
A.3
Descritor de WSDL
84
85
86
87
88
89