DYMOS QOS: UMA ABORDAGEM PARA SELEÇÃO
DE SERVIÇOS EM TEMPO DE EXECUÇÃO EM
LINHAS DE PRODUTO DE SOFTWARE DINÂMICAS
por
Jackson Raniel Florencio da Silva
Dissertação de Mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE 2014
Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
Jackson Raniel Florencio da Silva
DYMOS QOS: UMA ABORDAGEM PARA SELEÇÃO
DE SERVIÇOS EM TEMPO DE EXECUÇÃO EM
LINHAS DE PRODUTO DE SOFTWARE DINÂMICAS
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Vinicius Cardoso Garcia
RECIFE 2014
Dissertação de mestrado apresentada por Jackson Raniel Florencio da Silva ao programa de Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título Dymos QoS: Uma Abordagem para Seleção
de Serviços em Tempo de Execução em
Linhas de Produto de Software Dinâmicas, orientada pelo Prof. Vinicius Cardoso Garcia e aprovada pela banca examinadora formada pelos professores:
———————————————————————– Prof. Kiev Santos Gama
Centro de Informática / UFPE
———————————————————————– Profa. Rossana Maria de Castro Andrade
Departamento de Computação / UFC
———————————————————————– Prof. Vinicius Cardoso Garcia
Centro de Informática / UFPE
RECIFE 2014
Dedico esta dissertação a todas as pessoas que se sacrificaram junto comigo nos momentos em que necessitei ser ausente.
Agradecimentos
Utilizar palavras para expressar sentimentos tão vastos na forma de agradecimento é uma tarefa difícil para mim. Nenhum conjunto de códigos e seus respectivos significados semânticos podem expressar um pedaço da minha alma. No entanto coloco aqui o meu esforço em fazê-lo de maneira singela ao mesmo tempo que extremamente sincera.
Agradeço primeiro ao Pai do Céu que sempre me protegeu, me guiou e atendeu aqueles pedidos que fiz da forma como julgou ser melhor. Sua bondade e graça é tamanha a ponto de me amar imensamente mesmo eu não sendo um exemplo de filho. Por isso reservo a Ele este primeiro lugar nos meus agradecimentos.
A partir de agora os meus agradecimentos não seguem uma ordem de importância, visto que apenas vou agradecer aqueles que representam uma extensão do amor divino aqui na terra. Sendo assim, agradeço aos meus pais, avós e irmã por me devotarem tanto amor desde a minha mais tenra idade, além de me acompanhar a cada passo dado e me ensinar tanto a cada dia.
Agradeço àquela que em breve será a minha companheira eterna por estar ao meu lado nos últimos sete anos construindo dia-a-dia um relacionamento de duas pessoas em apenas uma entidade. Este amor revelado na forma de amizade, companheirismo, dedicação e tantas outras facetas foi meu arrimo durante muitos momentos.
Agradeço, por fim, ao meu orientador por ter me guiado durante esta caminhada. Assim como agradeço ao Centro de Informática da Universidade Federal de Pernambuco por todo apoio estrutural que me foi dado durante a realização desse trabalho.
Omnia Vincit Amor. —VIRGÍLIO (70 a.c. - 19 a.c.)
Resumo
A produção industrial antes de Taylor era essencialmente manufatureira e focada em produtos únicos. O Taylorismo e seus estudos de tempos e movimentos levaram para a indústria a ideia de padronização dos produtos. Ford, tempos depois, inventou a linha de produtos, onde a partir de então foi possível produzir em massa reduzindo o tempo de entrega do produto e seus custos. No que tange a indústria de software, esta apresenta tanto uma produção manufatureira quanto em massa que gera produtos que são denotados segundoPOHL; BöCKLE; LINDEN (2005) como software individual e software standard: uma clara influência do fordismo na concepção do paradigma de Linhas de Produto de Software (SPL). No entanto, este paradigma de desenvolvimento não foi concebido para suportar mudanças nos requisitos de usuários em tempo de execução. Diante deste problema, a academia tem desenvolvido e proposto maneiras de estender o paradigma de SPL de forma a permitir que essas reconfigurações dinâmicas do softwaresejam suportadas. Surgiram deste esforço as Linhas de Produto de Software Dinâmicas (DSPL) (HALLSTEINSEN et al.,2008). Levando em consideração este cenário, objetiva-se nesta pesquisa contribuir com a área de DSPL apresentando uma nova maneira de pensar quais características de uma DSPL devem ser ligadas em tempo de execução a um produto com base em uma análise que mensura e valida atributos de qualidade em níveis de serviços especificados pelo usuário. Para tanto foi necessária a revisão da literatura existente em busca de meios de analisar atributos de qualidade de serviços em tempo de execução em DSPL e o desenvolvimento exploratório de uma abordagem de reconfiguração da DSPL utilizando-se das características dinâmicas do OSGi como base em tal análise. Com a finalidade de validar a abordagem proposta, a mesma foi testada exploratoriamente em uma DSPL para o domínio de guia de visitas móveis e sensível ao contexto, onde pode-se verificar a assertividade desta. Ao final da validação exploratória pode-se observar a efetividade da abordagem proposta na DSPL na qual foi aplicada. No entanto, faz-se necessário a execução de testes estatísticos para comprovar a hipótese de que esta efetividade demonstrada é válida para outras DSPLs de outros domínios.
Palavras-chave: Linhas de Produto de Software. SPL. SPL Dinâmica. DSPL. Qualidade de Serviços.
Abstract
The industrial production before Taylor was essentially focused on manufacturing and unique products. The Taylorism and his time and motion studies had led to the industry the idea of standardization of products. Ford, sometime later, invented the product line which from then on was possible to mass produce by reducing the delivery time and product costs. Regarding the software industry, it presents both a manufacturing and mass production that generates products that are denoted for Pohl et al. (2005) as individual software and standard software: a clear influence of Fordism in the design paradigm of Software Product Lines (SPL). However, this development paradigm was not designed to support changing requirements of users at runtime. Faced with this problem, the academy has developed and proposed ways to extend the paradigm of SPL in order to enable such dynamic reconfigurations of software. From this effort emerged the Dynamics Software Product Lines (DSPL) (Hallsteinsen et al., 2008). Considering this scenario, the objective of this dissertation is to contribute to this research area presenting a new way of thinking which features a DSPL should be connected at runtime to a product based on an analysis that measures and validates quality attributes in service levels specified by the user. For this, it was necessary to review the existing literature searching means of analyzing service quality attributes at runtime in DSPL and an exploratory development of an approach for reconfiguration of DSPL using dynamic features OSGi based. In order to validate the proposed approach , it was tested in a mobile and context-aware DSPL, where we can verify this assertiveness. At the end of the exploratory validation we can observe the effectiveness of the proposed approach in DSPL in which it was applied. However, it is necessary to perform statistical evidence for the hypothesis that this demonstrated effectiveness is valid for other areas DSPLs other tests.
Lista de Figuras
1.1 Cenário do Problema . . . 15
2.1 Distribuição Anual de Estudos a Respeito de Derivação Dinâmica . . . 23
2.2 MADAM Platform Architecture (HALLSTEINSEN et al.,2006) . . . 24
3.1 DYMOS - Diagrama de Pacotes (OLIVEIRA MARTINS,2013) . . . 31
3.2 DYMOS - Diagrama de Sequência - Reconfiguração de Serviços (OLIVEIRA MAR-TINS,2013) . . . 33
3.3 DYMOS - Diagrama de Sequência - Descoberta de Serviços (OLIVEIRA MAR-TINS,2013) . . . 34
3.4 DYMOS QoS - Diagrama de Pacotes . . . 36
3.5 DYMOS QoS - Diagrama de Sequência - Descoberta de Serviços . . . 36
4.1 GreatTour - Modelo de Features . . . 41
4.2 Cin Tour - Modelo de Features . . . 42
4.3 Tempo de Resposta . . . 46
Lista de Tabelas
4.1 Valores de QoS . . . 44
4.2 Capacidades Máximas e Atuais . . . 46
4.3 Custo . . . 46
4.4 Desempenho do Dymos QoS . . . 47
Lista de Acrônimos
-DOP Delta Oriented Programing
DSPL Linha de Produtos de Software Dinâmica SPL Linha de Produtos de Software
OSGi Open Service Gateway Initiactive SCM Computação Orientada a Serviço SOA Arquitetura Orientada a Serviço SEI Software Engineering Institute
Sumário
1 Introdução 13
1.1 Motivação . . . 14
1.2 Problemática e Objetivo . . . 15
1.2.1 Métodologia . . . 16
1.3 Visão Geral da Solução . . . 17
1.4 Escopo Negativo . . . 17
1.5 Organização da Dissertação . . . 17
2 Revisão da Literatura 19 2.1 Computação Orientada a Serviços . . . 19
2.2 Qualidade de Serviços . . . 20
2.3 Linhas de Produto de Software . . . 21
2.3.1 O Estado da Arte em Derivação Dinâmica . . . 22
2.3.1.1 Estudos em Derivação Dinâmica . . . 23
2.4 A Interação entre SOC e DSPL . . . 28
2.5 Conclusões . . . 29 3 DYMOS QoS 30 3.1 Análise Exploratória . . . 30 3.1.1 Operações do DYMOS . . . 32 3.2 Intervenção Exploratória . . . 34 3.2.1 Seleção de Serviços . . . 38 3.3 Conclusões . . . 39 4 Avaliação 40 4.1 Validação Exploratória . . . 40
4.2 Avaliação Estatística Descritiva . . . 45
4.3 Conclusões . . . 48 5 Conclusão 49 5.1 Contribuições . . . 50 5.2 Limitações . . . 50 5.3 Trabalhos Futuros . . . 51 Referências 53
13 13 13
1
Introdução
- Quarenta e dois [...] Eu verifiquei cuidadosamente e não há dúvida de que a resposta é essa. Para ser franco, acho que o problema é que vocês jamais souberam qual é a pergunta. —DOUGLAS ADAMS (O Guia do Mochileiro das Galáxias)O legado deixado por Ford com a criação da linha de produtos modificou os meios de pensar a atividade industrial. No que tange à indústria de software, esta, apresenta tanto uma produção manufatureira quanto em massa que gera produtos que são denotados segundoPOHL; BöCKLE; LINDEN(2005) como software individual e software standard.
Denota-se, neste contexto, uma clara influência do fordismo na concepção do paradigma de Linhas de Produto de Software (SPL). Neste paradigma os produtos de software são criados a partir de um conjunto comum de características, diferenciando-se entre si pelo gerenciamento de um conjunto de características variáveis que diferenciam cada produto.
O paradigma SPL é tradicionalmente divido em duas fases: a fase de Engenharia de Linha de Produtos e a fase de Engenharia do Produto. Na primeira fase são definidas e implementadas todas as características que estarão presentes em todos os produtos chamadas de core assets, assim como as características variáveis que podem ou não estar em um produto da SPL. Durante a fase de Engenharia de Produto, são selecionadas para compor o produto além dos core assets as características variáveis que atendem a determinados requisitos de usuários que justificam a sua escolha para a composição do produto.
O ato de selecionar o conjunto de características que irão compor o produto e construí-lo para ser entregue é chamado de derivação de produto. Sendo assim, este paradigma de desenvolvimento não foi concebido para suportar mudanças nos requisitos de usuários em tempo de execução. Diante deste problema, a academia tem desenvolvido e proposto maneiras de estender o paradigma de SPL, de forma a permitir que essas reconfigurações dinâmicas do softwaresejam suportadas. Surgiram deste esforço as Linhas de Produto de Software Dinâmicas
1.1. MOTIVAÇÃO 14
(DSPL) (HALLSTEINSEN et al.,2008).
1.1
Motivação
O projeto Ubstructure1mantém a MobiLine, que é uma DSPL para aplicações móveis sensíveis ao contexto dividida em dois níveis de abstração: base e específico. O nível base possui características comuns a aplicações móveis e sensíveis ao contexto. Já o nível específico é composto por características que pertencem a um determinado domínio de negócio (MARINHO et al.,2012).
Esta SPL é composta por dois produtos: o GREat Tour e o Cin Tour, que são guias de visitas móveis sensíveis ao contexto derivados da MobiLine. Ambos são executados a partir de dispositivos que possuem o sistema operacional Android e fornecem informações sobre os pes-quisadores e os ambientes do laboratório do grupo de pesquisas GREat da Universidade Federal do Ceará e do Centro de Informática da Universidade Federal de Pernambuco, respectivamente.
Estes aplicativos utilizam informações contextuais, como a localização, o perfil e as preferências do usuário visitante. Assim como as requisições desencadeadas por este e as características (features) do dispositivo móvel para adaptar seu próprio comportamento. Parte das características do produto que variam em tempo de execução e os core assets da SPL estão presentes nos dispositivos móveis, enquanto outras características que variam em tempo de execução são ligadas ao produto a partir do acesso a serviços Web.
Dentre os objetivos do projeto Ubstructure está a criação de um mecanismo de adaptação automático que em tempo de execução selecione características da aplicação. Estas estarão habilitadas para o usuário adaptá-las segundo o contexto no qual a aplicação está inserida. Onde, o funcionamento deste mecanismo pode variar desde baseado em regras de condição ou até mesmo ser modelado como um problema de otimização.
O contexto varia entre tipos de aplicações e seus respectivos domínios. Na MobiLine considera-se contexto tanto o ambiente físico no qual o dispositivo móvel está inserido, quanto as informações a respeito do estado do próprio dispositivo. Estas informações são coletadas a partir dos sensores do dispositivo, sendo a localização geográfica adquirida a partir da câmera ou do sensor de sinais NFC.
O estudo deOLIVEIRA MARTINS(2013) abordou a problemática do mecanismo de reconfiguração e a descoberta de serviços criando uma ferramenta chamada DYMOS framework. Este atua sempre que uma reconfiguração que ocorre no lado cliente exigindo reconfigurações nos serviços no lado servidor. No entanto, este estudo seleciona os serviços no lado servidor de forma arbitraria, sem realizar nenhuma análise nos serviços que irão compor a DSPL. O que é tratado no trabalho como fora de escopo e possível trabalho futuro.
Por outro lado, como apresentado em mais detalhes na Seção 2, a literatura de DSPL não apresenta uma forma de selecionar as características que irão compor a linha de produto
1.2. PROBLEMÁTICA E OBJETIVO 15
em tempo de execução com base nas preferências do usuário. Esta análise não aborda apenas a conformidade funcional como também a qualidade das característica apresentadas.
1.2
Problemática e Objetivo
A Figura 1.1 representa o cenário hipotético que exemplifica a problemática abordada neste estudo. Como relatado anteriormente os produtos da MobiLine requisitam em tempo de execução as informações contextuais (coletadas por sensores ou do status do próprio dispositivo) e recebem estímulos do usuário que junto com essas informações definem quais adaptações em tempo de execução devem ocorrer.
Figura 1.1: Cenário do Problema
Quando uma adaptação ocorre no dispositivo móvel duas situações podem ser desenca-deadas: a) a requisição a um web service presente e ativo no lado servidor; ou b) a requisição a um web service ausente ou inativo no lado servidor.
Para a situação a), ao encontrar o serviço os produtos da MobiLine o consomem como há de se esperar. No tocante a situação b), a partir da criação do DYMOS, quando o serviço não é encontrado, o framework é responsável por procurar um serviço para substituir o que está indisponível de acordo com uma ordem de prioridade. Caso nenhum dos serviços organizados por prioridade esteja disponível, qualquer serviço que atenda a interface requisitada pela aplicação mobile é disponibilizado para consumo.
1.2. PROBLEMÁTICA E OBJETIVO 16
No entanto,ALFEREZ; PELECHANO(2011) argumentam que web services são execu-tados em ambientes complexos e heterogêneos e considerando este fato é apropriado que existam mecanismos de adaptação de acordo com mudanças contextuais que efetuem reconfigurações que aumentem a qualidade do serviço prestado. Enquanto que, paraLIN et al.(2010), do ponto de vista empresarial é fortemente desejável maximizar a qualidade de um serviço prestado levando em consideração os diversos entendimentos de o que é qualidade do ponto de vista de diferentes clientes.
Diante disto, o objetivo geral desta dissertação é:
Propor uma abordagem de seleção em tempo de execução das características que irão compor uma DSPL com base em uma análise de seus respectivos atributos de qualidade
Na busca em atingir este objetivo geral foram definidos três objetivos específicos: a) Revisar a literatura a fim de identificar as maneiras pelas quais a derivação dinâmica em DSPL ocorre; b) Desenvolver um método para a avaliação da qualidade e seleção dos serviços em tempo de execução; c) Avaliar a performance da abordagem proposta.
1.2.1
Métodologia
Esta dissertação é baseada na perspectiva filosófica positivista. Nesta perspectiva, as avaliações realizadas para a abordagem proposta no objetivo geral observam variáveis que terão sempre os mesmos valores em observações distintas realizadas por pesquisadores diferentes. Para que isto seja possível todos os passos seguidos em direção aos objetivos específicos são descritos e os valores das variáveis de observação disponibilizados. Para que os objetivos específicos fossem alcançados foi necessário estabelecer os métodos pelos quais este estudo seria guiado. Estes métodos foram escolhidos de acordo com a natureza de cada objetivo específico.
O objetivo específico “a)” é contemplado no Capítulo 2. Trata-se de um estudo bibliográ-fico feito com base em revisões da literatura estruturadas já publicadas. Procura-se nesta parte bibliográfica do estudo apresentar os principais conceitos abordados neste estudo, bem como estabelecer o estado da arte para a área de derivação dinâmica em DSPL.
O relato das etapas referentes ao objetivo específico “b)” está presente no Capítulo 3 e na primeira parte do Capítulo 4. Devido a quantidade de conhecimento sistematizado a respeito de derivação dinâmica de produtos, optou-se pelo uso de métodos exploratórios como forma de atingir esse objetivo. Sendo assim, optou-se pela realização de uma análise, uma intervenção e uma validação exploratória para a satisfação desse objetivo específico.
A fim de atender ao objetivo específico “c)”, descrito no Capítulo 4, optou-se por um abordagem quantitativa. Esta abordagem é expressa na forma de uma avaliação de performance da abordagem proposta, fazendo uso da descrição estatística das variáveis de controle e dos resultados observados.
1.3. VISÃO GERAL DA SOLUÇÃO 17
1.3
Visão Geral da Solução
Para alcançar o objetivo geral desta dissertação a abordagem proposta porOLIVEIRA MAR-TINS(2013) foi ampliada passando a ser chamada de DYMOS QoS. Esta solução proposta consiste de uma aplicação desenvolvida em linguagem JAVA e Open Service Gatway Initiative (OSGi) que avalia individual e coletivamente os atributos de qualidade de serviço disponível para a reconfiguração da SPL em tempo de execução.
São levados em consideração enquanto atributos de qualidade para a seleção dos serviços em tempo de execução: o custo da utilização de um serviço, as capacidades atuais e totais de carga dos serviços e o tempo de resposta. Como critérios de desempate, são utilizados os atributos de qualidade de disponibilidade e confiabilidade.
A partir desta contribuição é possível modificar a situação b) apresentada na Seção 1.2 e ilustrada na Figura 1.1, de modo que a seleção do serviço que substituirá o que está indisponível deixa de ocorrer de acordo com a prioridade arbitrada. E passa a acontecer de acordo com a qualidade dos serviços disponíveis no momento da requisição. Fica eleito o serviço que apresentar a maior pontuação fornecida pelo framework DYMOS QoS. Ainda como efeito dessa contribuição, torna-se possível um terceiro cenário onde a requisição por um serviço retorna sempre um serviço ótimo para determinado nível de serviço requerido.
1.4
Escopo Negativo
Alguns tópicos que se relacionam com o objetivo desta pesquisa ou seus objetos não são influenciados e não influenciam a mesma. Sendo assim, estão fora do escopo do presente trabalho alguns tópicos como a especificação e implementação de agentes, sejam estes de hardware ou de software, que responsabilizem-se pela monitoração do contexto onde os produtos da DSPL estão inseridos.
Assume-se, neste estudo, que existem regras de contexto e derivação de produtos deter-minadas. Sendo assim, a criação de tais regras é considerada como fora do escopo abordado. Da mesma maneira, não são abordadas técnicas de precificação, regras de estabelecimento de preços ou prazo de vigência para os mesmos.
Os serviços utilizados neste trabalho possuem atributos de qualidade que servem como insumos para a avaliação dos mesmos. No entanto, o monitoramento de quebra de acordos de nível de serviço ou de qualquer garantia a respeito dos valores desses atributos de qualidade também são considerados como fora de escopo.
1.5
Organização da Dissertação
O restante desta dissertação está organizada em quatro capítulos. O Capítulo 2 trata dos conceitos básicos relacionados a área de SPL além de apresentar o Estado da Arte em derivação
1.5. ORGANIZAÇÃO DA DISSERTAÇÃO 18
dinâmica e explorar as deficiências desta temática de pesquisa.
O Capítulo 3 trata do desenvolvimento da abordagem proposta. Este capítulo inicia com a descrição do funcionamento do DYMOS, sobretudo no que diz respeito ao seu mecanismo de descoberta de serviços. A segunda parte deste capítulo trata de apresentar as modificações realizadas no framework com a criação dos componentes que são responsáveis pela análise da qualidade dos serviços em tempo de execução.
No Capítulo 4 é demonstrada uma avaliação que valida o DYMOS QoS utilizando os produtos da MobiLine. É apresentado ainda, uma avaliação de performance para o framework. Por fim, o Capítulo 5 encerra esta dissertação sumarizando os passos demonstrados nos capítulos anteriores e relatando o desfecho que foi possível concluir com relação a abordagem proposta. É apresentado neste capítulo as limitações, contribuições e uma lista de trabalhos futuros.
19 19 19
2
Revisão da Literatura
O que nos traz finalmente ao momento da verdade, em que a falha fundamental é definitivamente expressa e a anomalia revela ser tanto o começo quanto o fim. —MATRIX (Diálogo entre Neo e o Arquiteto)
Serão explorados nesse capítulo os conceitos utilizados nesta dissertação. Para tanto, o capítulo inicia com uma breve explanação a respeito dos conceitos fundamentais da Computação Orientada a Serviços (SOC). Em seguida são apresentados conceitos relacionados a abordagem SPL e então o estabelecimento do Estado da Arte em derivação dinâmica. Finaliza-se, então com uma explanação crítica a respeito da interação entre DSPL e SOC.
2.1
Computação Orientada a Serviços
Enquanto paradigma computacional, SOC utiliza serviços como elementos fundamentais para o desenvolvimento de software estruturados em uma Arquitetura Orientada a Serviços (SOA). Na perspectiva deMENDONçA et al. (2013) este paradigma emergiu no intuito de oferecer maior eficiência à provisão de recursos computacionais utilizando componentes diversos de infraestrutura como servidores web e bancos de dados.
É de encargo da SOA determinar os meios pelos quais os serviços devem ser organiza-dos, construídos e gerenciados. SOA fundamenta-se na utilização de serviços como unidades fundamentais, suas respectivas descrições e nas operações de publicação, descoberta, seleção e
vinculação (PAPAZOGLOU; GEORGAKOPOULOS,2003).
As arquiteturas orientadas a serviços são utilizadas por proverem benefícios como reusabilidade, flexibilidade, interoperabilidade (ERL, 2007) através dos princípios de baixo acoplamento, contrato entre serviços, descoberta de serviços e granularidade alta ou pequena quantidade de requisições ao serviço para o desempenho de uma funcionalidade. Onde o baixo acoplamento diz respeito ao número de dependências entres os serviços e é alcançado a partir da modularização dos serviços fazendo com que sejam acessados através de contratos.
2.2. QUALIDADE DE SERVIÇOS 20
Dentro deste contexto, os clientes (serviços e aplicações que utilizam as funcionalidades providas por um outro serviço) aderem aos contratos de comunicação, definidos por um ou mais serviços. Estes contratos consistem de uma descrição das funcionalidades, características e formatos de dados do serviço. São utilizados, assim, normalmente formatos padronizados como contratos a exemplo de XML, WSDL e XSD, como afirmaERL(2005).
Sendo assim, a descoberta de serviços ocorre sempre a partir da especificação descritiva dos mesmos (contrato), permitindo a sua localização e identificação. Ambas podem ocorrer a partir do Universal Descriptor, Discovery and Integration (UDDI) ou Uniform Resource Identifier (URI), sendo utilizados diretamente por um cliente ou por um mecanismo de descoberta de serviço (JOSUTTIS,2007).
A modularidade e reutilização providas pelo uso de SOC e SOA permitem que serviços sejam disponibilizados para a utilização de terceiros ou em sistemas diferentes dos sistemas para os quais estes foram desenvolvidos. No âmbito de transações comerciais eventualmente é desejável que a qualidade do serviço (QoS) oferecido seja aferida para que sejam garantidas, por exemplo, cláusulas contratuais como a quantidade de resposta a uma determinada requisição por segundo.
A utilização de SOC na Web manifesta-se na forma de Web services que é um tipo específico de serviço que é identificado por uma URI (PAPAZOGLOU; GEORGAKOPOULOS, 2003). Algumas características comuns a web services que são utilizadas para a aferição de sua qualidade foram elencadas porD’AMBROGIO(2006), são elas: latência, demanda, rede, controle de acesso, encriptação, disponibilidade e confiabilidade.
2.2
Qualidade de Serviços
Um serviço Web pode ter várias implementações oferecidas por diferentes provedores. Estas implementações têm a mesma funcionalidade mas podem ter diferentes valores para os seus atributos de QoS. Sendo assim, alguns critérios de qualidade podem ter melhores valores em uma implementação do serviço e alguns piores em comparação a outras implementações (TANG; AI,2010).
Mais precisamente, um serviço Web pode ser identificado por duas propriedades: fun-cionalidade e qualidade. Funfun-cionalidade é o que o software pode oferecer e é tipicamente representado por um conjunto de operações providas pelo serviço. Já a qualidade diz respeito a o quão bem um provedor de serviços pode fazer a entrega das funcionalidades deste (YU et al., 2010a).
O termo “qualidade” é utilizado para representar juízos de valor e por isso é um termo de significado vago. No entanto,DEORA et al.(2006) argumenta que em SOC a qualidade é normalmente vista segundo as perspectivas de conformidade e reputação. Dentro da primeira perspectiva, a qualidade é vista como um sinônimo de atendimento a especificações como tempo de reposta, custo e largura de banda. Já na perspectiva de qualidade enquanto reputação,
2.3. LINHAS DE PRODUTO DE SOFTWARE 21
trabalha-se com a percepção de um usuário a respeito de um serviço em geral.
PAPAKOS; CAPRA; ROSENBLUM(2010) defendem que em aplicações cliente em dispositivos móveis sofrem com mudanças de contexto que podem incluir mudanças nos recursos do dispositivo, em variáveis ambientais e nas preferências do usuário em tempo de execução. Sendo assim, o nível de QoS exigido inicialmente pelo ambiente podem não estar de acordo com as capacidades do dispositivo em seu contexto atual resultando em um desperdício de recursos e um alto custo monetário.
Existe um conjunto de técnicas utilizadas para a seleção e composição de serviços em tempo de execução. Dentre elas a utilização de algorítimos genéticos como utilizado porTANG; AI(2010). Em seus estudos,YU; LIN(2004,2005) utilizaram uma abordagem combinatória de seleção de serviços para uma composição de serviços estruturados como um pipeline simples e uma abordagem utilizando Grafos Acíclicos Direcionados (DAG) onde cada caminho possível no gráfico retorna uma seleção e composição de servições diferentes.
Em abordagens combinatórias, algorítimos de busca exaustiva ou de solução para o problema da mochila do alpinista (MKCP) podem ser utilizados. O primeiro caso consiste em comparar as seleções ou composições possíveis com base nos critérios de qualidade escolhidos. Este algorítimo sempre retorna a solução ótima apesar de apresentar um grande consumo de tempo e memória. Já o seleciona os serviços a serem compostos pesos que são retirados de características não funcionais dos serviços.
Nas abordagens DAG algorítimos que buscam por todas os caminhos possíveis de seleção de serviços para composição no grafo para que posteriormente seja definido a partir de uma análise combinatória quais serviços melhor atendem a uma determinada restrição de qualidade. Outro algorítimo que pode ser utilizado é o Constrained Bellman-Ford (CBF) que é um algorítimo de busca em largura que seleciona um nó a cada nível do grafo de acordo com a restrição de qualidade imposta. Pode ser utilizado ainda o algorítimo Constrained Shortest Path (CSP) que funciona basicamente como o CBF, apesar de ordenar topologicamente os nós do grafo no primeiro passo de sua execução.
Existem ainda abordagens de seleção de serviços criadas para cenários específicos como é o caso do estudo doPAPAKOS; CAPRA; ROSENBLUM(2010), que criou um mecanismo para descoberta de serviços em nuvem para dispositivos móveis. Ou ainda um framework em duas fases para seleção baseada em qualidade de serviços que utiliza uma linguagem de consulta para localizar, retornar e montar planos de execução desses serviços (YU et al.,2010b).
2.3
Linhas de Produto de Software
Custo, reusabilidade e time-to-marketing são aspectos que preocupam os fabricantes de software. Por outro lado, a gerência de configuração de software torna-se cada vez mais complexa à medida que aumentam as possibilidades de combinações de características (features) de um software. O paradigma de Linhas de Produto de Software (SPL) vai de encontro a este problema
2.3. LINHAS DE PRODUTO DE SOFTWARE 22
criando produtos de software a partir de um conjunto comum de características. O gerenciamento da configuração ocorre com as variabilidades e as comonalidades entre os membros da linha de produto de software.
Segundo o Software Engineering Institute (SEI)1, SPL é um conjunto de sistemas inten-sivos de software que compartilham um conjunto comum e gerenciado de funcionalidades que satisfazem necessidades específicas de um segmento ou missão particular de mercado e que são desenvolvidos a partir de um conjunto comum de recursos principais (Core Assets) de maneira prescrita. Os benefícios em adotar o paradigma SPL depende do contexto no qual ele é aplicado. Alguns dos benefícios mais comuns são a redução do custo e do time-to-marketing promovido pela reutilização dos core assets dos softwares da linha.
Não obstante, variações dinâmicas em requisitos dos usuários e no ambiente no qual o software está inserido em tempo de execução tornam-se cada vez mais frequentes, por isso existe uma demanda crescente por sistemas capazes de se adaptar automaticamente ao encontrar essas condições. Em 2008,HALLSTEINSEN et al.(2008) publicou um estudo que descreveu o conceito de Dynamic Software Product Lines (DSPL). Estas linhas de produto diferem das outras por não gerenciarem a variabilidade durante a fase de design do software, mas em tempo de execução.
Uma DSPL representa normalmente cinco características: a) variabilidade dinâmica, b) a ligação (binding)de elementos da DSPL muda durante o ciclo de vida da aplicação, c) pontos de variação mudam em tempo de execução, d) mudanças inesperadas no contexto e e) são desenvolvidas para um contexto ou ambiente específico no lugar de um segmento de mercado (HALLSTEINSEN et al.,2008).
Opcionalmente, DSPLs podem ser sensíveis ao contexto a sua volta (PARRA; BLANC; DUCHIEN,2009;ALI; CHITCHYAN; GIORGINI,2009;ALFEREZ; PELECHANO,2011), possuir propriedades autonômicas ou de auto-adaptação (ABBAS; ANDERSSON; WEYNS, 2011;CETINA; FONS; PELECHANO,2008;ABBAS,2011) e tomada automática de decisão. Estas características compõem um desafio para um modelo de desenvolvimento de SPLs que gerencia a variabilidade fora da fase de design.
2.3.1
O Estado da Arte em Derivação Dinâmica
Na perspectiva de MORESI(2003), o Estado da Arte apresenta a partir da literatura já publicada o que já se sabe sobre determinado tema, quais as lacunas existentes e onde se encontram os principais entraves teóricos ou metodológicos. No que diz respeito a derivação dinâmica, vários pesquisadores têm desenvolvido uma quantidade significante de estudos para investigar aspectos relacionados a reconfiguração de SPL em tempo de execução, que é tratada como parte da derivação do produto chamada derivação dinâmica (PARRA; BLANC; DUCHIEN, 2009).
2.3. LINHAS DE PRODUTO DE SOFTWARE 23
Apesar do termo DSPL ter sido detalhadamente descrito emHALLSTEINSEN et al. (2008), pelo menos quatro estudos abordaram a temática e trataram da derivação dinâmica anteriormente (KIM; JEONG; PARK,2005;GOMAA; SALEH,2006;HALLSTEINSEN et al., 2006;LEE,2006). A partir da utilização dos mesmos critérios descritos porSILVA et al.(2013) pode-se observar uma crescente, apesar de pequena, produção bibliográfica no decorrer dos anos abordando a temática de derivação dinâmica (Figura 2.1).
No entanto,BUREGIO; ALMEIDA; MEIRA(2010) afirma que para a área de DSPL a maior parte das contribuições estão relacionadas a proposição de soluções, em sua maioria concentradas no desenvolvimento de metodologias. Ao mesmo tempo que não são comuns de serem encontrados relatos de experiência e pesquisas que possam avaliar a aplicabilidade dos conceitos de DSPL no contexto industrial. Estas constatações são reforçadas no estudo deSILVA et al.(2013), no que tange aos estudos a respeito de derivação dinâmica levando à conclusão de que o campo de estudo está ainda em formação.
Figura 2.1: Distribuição Anual de Estudos a Respeito de Derivação Dinâmica
A seguir são apresentados estudos publicados entre os anos de 2005 e 2013 que apresenta-ram contribuições relevantes para a área de derivação dinâmica em DSPL em ordem cronológica. O objetivo desta apresentação é expressar a evolução das técnicas de derivação dinâmica ao longo do tempo.
2.3.1.1 Estudos em Derivação Dinâmica
KIM; JEONG; PARK(2005) desenvolveram, para um contexto de uma DSPL de jogos para dispositivos móveis, um framework de reconfiguração arquitetural em tempo de execução que gerencia a reconfiguração dinâmica para ambientes embarcados. A solução proposta faz uso de uma linguagem específica de domínio para descrever o sistema de maneira estática e uma linguagem para descrever modelos arquiteturais que especificam as regras que informam quais componentes devem ser adicionados ou removidos da arquitetura do produto.
A abordagem “Dynamic Client Application Customization” (DAC) criada porGOMAA; SALEH(2006) é baseada na customização dos objetos da interface com o usuário em tempo de execução baseada em features selecionadas e valores de variáveis parametrizadas. Esta abordagem consiste de uma arquitetura de SPL customizável baseada no padrão arquitetural
2.3. LINHAS DE PRODUTO DE SOFTWARE 24
cliente/servidor, onde a aplicação cliente contém apenas objetos de interface com o usuário e um objeto customizador. A aplicação do servidor contém todos os web services responsáveis por prover as funcionalidades do sistema e o suporte ao banco de dados.
Na DAC, a seleção de features direciona a customização dinâmica da arquitetura e a implementação da linha de produto para a derivação da aplicação. Durante a modelagem da linha de produto as features e suas dependências são descritas em um modelo (feature model). Durante a engenharia da aplicação, features são selecionadas pelo engenheiro de aplicação e utilizadas para customizar dinamicamente a arquitetura e implementação da aplicação.
HALLSTEINSEN et al.(2006) criaram a abordagem MADAM para construção de siste-mas adaptativos. O foco da abordagem está em sistesiste-mas distribuídos acessados por dispositivos móveis onde a derivação dinâmica ocorre a partir de uma arquitetura de referência. A plataforma arquitetural que suporta a abordagem pode ser vista na Figura 2.2. O núcleo dessa arquitetura (Core) é composto por um middleware entre os componentes e a plataforma, e oferece serviços para o gerenciamento de componentes, instâncias e recursos. O Context Manager é responsável por monitorar um conjunto de contextos relevantes no ambiente do sistema enviando e reunindo informações que são utilizadas pelo Adaptation manager.
O Adaptation manager é responsável por avaliar o impacto das mudanças no contexto sobre a aplicação e determinar quando uma adaptação deve ser efetuada, selecionando as va-riantes que melhor atendem as novas necessidades impostas pelo contexto. O configurador (Configurator) é responsável por realizar a configuração inicial da aplicação e as reconfigura-ções, observando quais variantes devem ser instanciadas e desativadas para alcançar o estado determinado pelo Adaptation manager.
Figura 2.2: MADAM Platform Architecture (HALLSTEINSEN et al.,2006)
Em uma abordagem orientada a features e sistemática de desenvolver core assets re-configuráveis dinamicamente,LEE (2006) desenvolvera um reconfigurador que acumula as funções de monitorar e gerenciar a configuração de um produto em tempo de execução. Este autor acredita que a derivação dinâmica pode ser realizada agrupando features em unidades de
2.3. LINHAS DE PRODUTO DE SOFTWARE 25
binde utilizando um reconfigurador que considera contextos (quando configurar), estratégias de reconfiguração (como reconfigurar) e ações de reconfiguração (o que reconfigurar).
Baseado no paradigma SPLCETINA; FONS; PELECHANO(2008) criou um método para desenvolver sistemas pervasivos dinamicamente adaptáveis. Neste estudo afirma-se que a reconfiguração autônoma do produto pode ser realizada estendendo a abordagem do paradigma SPL reutilizando a análise de escopo, características em comum e variabilidades. A reutilização desta análise é utilizada como entrada para um reconfigurador que em tempo de execução utiliza o conhecimento contido nesta para realizar a derivação dinâmica.
WOLFINGER et al.(2008) em uma abordagem que utiliza plugins como features no domínio de sistemas ERP2, faz uso de variáveis parametrizadas para adaptar o produto em tempo de execução. O primeiro artefato a ser gerado para a utilização dessa abordagem é o conjunto de componentes em forma de plugin. Então uma ferramenta chamada DecisionKing é empregada para gerar um modelo de variabilidades e outra ferramenta de nome ProjectKing permite que sejam criados cenários para configurações específicas modelo de variabilidades. Assim, um guia de configuração processa os modelos de variabilidades com seus respectivos cenários e apresenta as possíveis decisões a serem tomadas em uma interface amigável para o usuário do software. Por fim, um mecanismo de descoberta na plataforma de plugins permite ligar e desligar os componentes baseando-se nas decisões do usuário.
PUKALL; SIEGMUND; CAZZOLA(2009) desenvolveu a metodologia chamada “Feature-oriented Runtime Adaptation” que permite a atualização de programas em tempo de execução através da evolução dos recursos de uma SPL de forma dinâmica. Toda a metodologia é baseada em substituições de classes em Java utilizando “Java HotSwap” e reimplementação do corpo de métodos.
O relacionamento entre SPL e computação orientada a serviço foi claramente utilizado porYU; LALANDA; BOURRET(2010) ao apresentarem uma metodologia para a construção de aplicações baseadas em serviços para ambientes heterogêneos e dinâmicos. A metodologia é dividida nas fases de engenharia de domínio, engenharia de aplicação e tempo de execução. É proposto um processo de desenvolvimento centrado em domínios e orientado a arquitetura inspirada em SPL. É na fase de tempo de execução que, através de composição de serviços dinâmica, acontece a reconfiguração.
Foi provado ser possível realizar uma derivação dinâmica a partir do compilador Java no estudo deSUNKLE; PUKALL(2010). Este estudo utilizou o FeatureJ, que é uma abordagem de implementação de SPL, com uma representação de features e variabilidades como se fossem tipos de uma linguagem de programação. Esta representação é utilizada como entrada para a derivação do produto em tempo de compilação e execução. JáGüNTHER; SUNKLE(2010) apresentaram uma maneira de modelar, implementar features, realizar a composição dinâmica destas em tempo de execução e modificar a SPL e suas variantes utilizando a linguagem de programação Ruby.
2.3. LINHAS DE PRODUTO DE SOFTWARE 26
No âmbito de sistemas de cuidados com a saúde, CARVALHO; LOQUES; MURTA
(2010) desenvolveu uma abordagem para gerenciamento dinâmico de variabilidades baseada em contratos arquiteturais. Estes contratos, especificados na linguagem CBabel, são instanciados em tempo de execução de acordo com as variações no contexto.
LEE; KOTONYA(2010) é uma continuação do estudo realizado pelo mesmo autor(LEE, 2006) onde é descrita uma possível solução para a derivação dinâmica que relaciona uma análise orientada a features e um framework orientado e sensível a qualidade dos serviços de um SPL. Os autores acreditam que features podem ser mapeadas em serviços.
ALFEREZ; PELECHANO(2011) desenvolveu um método para projetar e implementar web servicesautônomos e sensíveis ao contexto em SPL. Os autores argumentam que se web servicesforem caracterizados por features, então a ativação e desativação de features em tempo de execução pode guiar a reconfiguração autonômica de composição de serviços a depender de mudanças no contexto. Neste caso, os produtos são uma composição de serviços. Para que seja possível uma composição de serviços, os autores sugerem a criação de um modelo de composição feito a partir de um diagrama UML de atividades. Este modelo ilustra os web services e os fluxos de sequência entre eles que estabelece a ordem na qual cada web services deve ser ativado.
GOMAA; HASHIMOTO(2011) descreve uma arquitetura para a adaptação dinâmica de produtos de uma SPL baseado em SOA. Esta arquitetura contém um serviço de monitoramento que verifica continuamente o estado do sistema em execução e o encaminha para o serviço de calibragem, que percebendo uma situação no contexto que necessite de uma ação envia uma requisição ao dispositivo de seleção dinâmica de features. Este dispositivo determina se existe a necessidade de mudanças na configuração que está sendo executada. Ele determina dinamicamente as modificações necessárias para o modelo de features da aplicação e envia a nova seleção de features para o serviço de gerenciamento de mudança. Fica a cargo do serviço de gerenciamento de mudanças determinar a diferença entre a nova seleção de features e a original, determinar os componentes e conectores que precisar sem adicionados ou removidos e gerar uma sequência de comandos de adaptação que correspondem as mudanças que precisam ser efetuadas.
Em (PARRA et al., 2011), os autores propuseram uma abordagem unificada com o objetivo de dar suporte a todo o ciclo de desenvolvimento de software. A abordagem considera que a criação do produto inicial é realizada através de adaptações no projeto. Uma vez criado e entregue o produto pode ser objeto de adaptações dinâmicas. A abordagem, que utiliza adaptação a partir de aspectos, é feita em duas entidades principais. A primeira é um metamodelo unificado de aspectos utilizados para definir tanto adaptações em tempo de projeto quanto em tempo de execução.A segunda é uma plataforma que realiza de modo transparente as adaptações expressadas no metamodelo unificado.
Esses modelos ligam cada feature em particular com um conjunto de componentes opcionais que podem fazer parte do produto. Cada modelo contém as informações necessárias para a composição, incluindo: a) as localizações modificadas pela feature, b) os elementos a
2.3. LINHAS DE PRODUTO DE SOFTWARE 27
serem adicionados e c) o conjunto de modificações a serem realizadas para que esses elementos possa ser adicionados.
ROSENMüLLER et al.(2011) apresentaram em seu estudo transformações de código para integrar o bind estático e dinâmico de features em SPLs a nível de modelagem e implemen-tação. Esta abordagem permite que desenvolvedores mudem flexivelmente o tempo de bind de cada feature usando o mesmo código como base. As unidades de bind são geradas estaticamente para reduzir a sobrecarga do processo de derivação dinâmica. Os autores garantem a composição segura do bind dinâmico utilizando regras de composição descritas em um modelo de features que contém as regras de reconfiguração que representam as transformações de código que são utilizadas para a criação das unidades de bind dinâmico.
SHEN et al.(2011) propuseram um método orientado a features para suportar recon-figuração de variabilidades em tempo de execução. Neste estudo é introduzido o conceito de modelo de funções, que é um nível intermediário entre as variantes das features e suas respecti-vas implementações. Durante o processo de adaptação a reconfiguração da feature variante é mapeado no modelo de funções. Neste contexto as funções relacionadas com as variabilidades podem ser adaptadas para estar disponíveis ou indisponíveis quando a reconfiguração em tempo de execução é realizada. Como as funções não podem ser removidas da aplicação em execução, o gerenciamento dessas interações com as funções mapeadas apoia a reconfiguração.
DAMIANI; PADOVANI; SCHAEFER(2012) apresentam para este campo de estudo os conceitos de Delta Oriented Programing (DOP). Um produto em particular em uma DOP SPL é gerado aplicando-se as modificações contidas em módulos delta adequados para um núcleo de sistema, que podem sempre ser assumido como vazio. O gráfico de reconfiguração define quais configurações o sistema pode adaptar em tempo de execução e descreve como objetos alocados na pilha precisam ser realocados.
O estudo deBARESI; MILANO(2012) demonstra uma maneira de enriquecer as com-posições da Business Process Execution Language (BPEL) com o gerenciamento dinâmico de varabilidades. A solução proposta utiliza a Common Variability Language (CVL) para aumentar os processos BPEL com variabilidades, que torna possível a criação de DSPLs e uma versão dinâmica da BPEL para gerenciar e executá-las.
Em 2013, dois estudos a respeito da derivação dinâmica foram concluídos pelo “Advanced System and Software Engineering Research Technologies Lab”(AssertLabs): no primeiro (SILVA et al., 2013), dentre outras coisas, pode-se verificar que no contexto de DSPLs orientadas a serviço existem algumas abordagens para a reconfiguração desses serviços em tempo de execução com base em atributos de qualidade. No entanto, nenhuma dessas abordagens utiliza acordos de nível de serviços ou demonstra evidências de que podem ser reutilizadas em DSPLs de domínios distintos.
O segundo estudo foi uma dissertação de mestrado (OLIVEIRA MARTINS,2013), onde foi desenvolvido o DYMOS framework com o propósito de gerenciar variabilidades dinâmicas em SPL orientadas a serviços e sensíveis ao contexto. Este framework possibilita que serviços
2.4. A INTERAÇÃO ENTRE SOC E DSPL 28
sejam adicionados ou removidos da configuração do produto em tempo de execução por meio de mecanismos de auto-implantação, de modo que o funcionamento do sistema não seja afetado e que tais modificações sejam aplicadas e reconhecidas imediatamente. Possui também um mecanismo de descoberta de serviços, que provê uma abstração entre o cliente e o serviço, permitindo efetuar orquestração de serviços e agregar critérios para a seleção do serviço mais adequados, de acordo com uma requisição.
2.4
A Interação entre SOC e DSPL
Pelo fato de SOC e SPL serem paradigmas utilizados com certa frequência pela comuni-dade de reuso de software não é difícil encontrar na literatura estudos bem sucedidos que tratam serviços como features, onde a determinação de quais serviços vão compor o produto é feita através do modelo de features selecionado para cada produto a ser derivado. No entanto, este mapeamento estático de serviços, não atende aos requisitos de dinamicidade de uma DSPL.
É notório que SOA segue um abordagem de reuso e composição de serviços enquanto SPL, apesar de ter como benefício a reutilização, corresponde a uma abordagem de construção e decomposição (PARRA; BLANC; DUCHIEN,2009). Porém as características antagônicas desses paradigmas (composição e decomposição) não são conflitantes já que a composição de serviços em uma SPL tradicional ocorre em um momento pré-derivação e a decomposição ocorre no momento da derivação do produto.
Desta forma, DSPLs tradicionais podem também não apresentar dificuldades quanto a este antagonismo. Não obstante, certamente este problema afetará uma DSPL orientada a serviço que precisa decidir com base em alguma análise (Ex.: prioridade, resposta ao contexto e QoS) quais serviços devem ser plugados em tempo de execução. Visto que derivação (decomposição) e composição estão ocorrendo no mesmo momento.
Exemplos de como essa questão é tratada podem ser vistos, por exemplo, no estudo realizado porYU; LALANDA; BOURRET(2010), a DSPL orientada a serviços faz a análise de quais serviços compõem o produto unicamente verificando a disponibilidade dos serviços. Adicionalmente, o estudo deLEE(2006) apresenta uma DSPL orientada a serviços onde as featuressão mapeadas em serviços. Esta DSPL realiza uma análise e um planejamento em tempo de execução baseados em mudanças contextuais para definir quais features, e consequentemente, quais serviços devem compor o produto.
Em um estudo de cunho exploratório posterior (LEE; KOTONYA,2010) esta abordagem é modificada fazendo com que a análise em tempo de execução seja feita com base em acordos de nível de serviço impostos pela linha de produto. Onde, assim como nos estudos deALFEREZ; PELECHANO(2011) eGOMAA; HASHIMOTO(2011), sempre que ocorre uma quebra no acordo de nível de serviço, o framework procura por outro serviço que satisfaça as condições desejadas. Não foram expressas no estudo detalhes sobre quais seriam essas condições (atributos de QoS) ou como a negociação é feita.
2.5. CONCLUSÕES 29
2.5
Conclusões
Este capítulo explanou os conceitos relacionados a SOC, SPL e o estabelecimento do Estado da Arte a respeito da derivação dinâmica e sua interação com SOC. A partir disto, conclui-se que: é ausente na literatura estudos que atendam ao cenário motivacional descrito na Seção 1.1, ou seja, que definam os serviços que vão compor a DSPL orientada a serviço com base em uma análise de atributos de QoS realizada a cada requisição do usuário.
O próximo capítulo apresenta a construção de uma abordagem ferramental para tratar esta lacuna. A abordagem baseia-se na extensão do framework DYMOS, acrescendo-lhe a capacidade de avaliar e selecionar serviços com base em atributos de qualidade.
30 30 30
3
DYMOS QoS
Esse caminho não há outro Que por você faça —SKANK (Acima do Sol)
Estudos exploratórios são realizados geralmente em áreas onde há pouco conhecimento acumulado e sistematizado, como é o caso da área de derivação dinâmica em DSPL relatado no Seção 2. Este tipo de estudo também possui uma natureza de sondagem e não comporta hipóteses que todavia podem surgir no final da pesquisa (MORESI,2003).
Este capítulo apresenta uma análise e intervenção exploratória realizadas no DYMOS, que é um mecanismo de reconfiguração e descoberta de serviços apresentado e desenvolvido por OLIVEIRA MARTINS(2013). Cada uma das fases desse estudo exploratório são apresentadas a seguir.
Vale ressaltar que o framework DYMOS trabalha com features em dois níveis de abstração distintos. No primeiro nível estas features são compostas de uma chamada a um serviço no lado cliente da aplicação e um contrato existe no lado servidor. No segundo nível de abstração as featuressão todas alternativas e implementadas como serviços Web.
Portanto, a fim de evitar mal entendidos, as features de primeiro nível serão tratadas por este nome, enquanto as do segundo nível serão tratadas como serviços ou serviços Web. Ainda assim, o framework possui um serviço Web chamado “ApplicationService” que assim como os outros elementos da arquitetura exibida na Seção 3.1 será tratado apenas como componente.
3.1
Análise Exploratória
O framework DYMOS está estruturado como apresentado na Figura 3.1. Essa arquitetura apresenta um serviço Web chamado “ApplicationService”, o componente “ServiceContext”, o contêiner OSGi e três elementos descritores: o “ServiceDescriptor” que descreve o que pode ser plugado em tempo de execução ao produto da SPL, o “VariabilityDescriptor” que descreve os pontos de variação e, finalmente, o “WSDescriptor” que descreve o WSDL de cada serviço Web.
3.1. ANÁLISE EXPLORATÓRIA 31
Figura 3.1: DYMOS - Diagrama de Pacotes (OLIVEIRA MARTINS,2013)
O “ServiceDescriptor” utiliza um arquivo XML como o apresentado no trecho de código 3.1 para descrever os serviços. Este XML contém uma lista de campos estruturados para cada serviço Web como um campo “Id” fazendo o papel de identificador exclusivo, os campos “servi-ceSpec” e “serviceImpl” que contém os valores que identificam a interface e uma implementação para o serviço. Cada descrição de serviço tem, opcionalmente, uma lista de serviços alternativos que possuem uma referência para outro serviço Web.
Listing 3.1: XML de Serviços do DYMOS
<?xml version="1.0"?>
<services> ...
<service id="imageService"
service-impl="com.assertLab.imageServiceImpl"> <service-spec>com.assertLab.imageService</service-spec>
<alternative-service ref="imageService1" priority="1" /> </service>
<service id="imageService1"
service-impl="com.assertLab.imageService1">
<service-spec>com.assertLab.imageService</service-spec> </service>
...
</services> </variabilities>
A estrutura de metadados de variabilidade utilizada pelo “VariabilityDescriptor”, apre-sentado no trecho de código 3.2, define uma lista de variabilidades com uma identificação (ID) do atributo “id”, um nome através do atributo “name” e um conjunto de variantes. Desta forma, uma variante consiste em um ID e um nome de um conjunto de referências a serviços. Este
3.1. ANÁLISE EXPLORATÓRIA 32
conjunto de referências é responsável por manter os serviços ativos quando a variação estiver ativada.
Listing 3.2: XML de Serviços do DYMOS
<?xml version="1.0"?>
<variabilities>
<variability id="accessMode"> <variant id="infraredMode">
<service-ref ref="hiService" /> </variant>
</variability> <variability>
<variant id="batteryHalfLife">
<service-ref ref="imageService" /> </variant>
</variability> </variabilities>
O “WSDescriptor” é usado para operações de descoberta de serviços e sua principal função, de acordo com um determinado serviço disponível, é descrever os atributos que não são descritos pelo “ServiceDescriptor”. E que são específicos para cada implementação de um serviço como “ServiceName”, “PortType” ou “Target Namespace”. Assim, “WSDescriptor” permite maior flexibilidade ao framework, acrescentando características dinâmicas e levemente acopladas.
O componente “ServiceContext” faz uso de todos os componentes descritores. A utiliza-ção destes componentes permite ao “ServiceContext” obter todas as informações descritas na forma de objetos Java, auxiliando-o no gerenciamento de variabilidade e serviços descritos. Esta gestão utiliza as informações sobre a variabilidade e serviços para manipular o contêiner OSGi.
O componente ApplicationService foi implementado para funcionar como uma fachada, criando um isolamento entre o cliente e os outros componentes da estrutura. Assim, reduziu-se o número de objetos que os clientes necessitam lidar. O objetivo principal do componente é expor operações, permitindo, assim, a descoberta de serviço e a gestão de variabilidade.
3.1.1
Operações do DYMOS
O “ServiceContext” é o componente responsável pelas principais operações do DYMOS: reconfiguração de variabilidades, descoberta de serviços e “ContextHotBuild”. A reconfiguração de variabilidades ocorre em resposta a uma variação no contexto no lado cliente da aplicação que resulta em uma reconfiguração. Em seguida, o DYMOS a partir da sua operação de reconfiguração adapta o contexto dos serviços (lado servidor) para atender a necessidade da reconfiguração no lado cliente. A sequência desta operação pode ser visualizada na Figura 3.3.
3.1. ANÁLISE EXPLORATÓRIA 33
Figura 3.2: DYMOS - Diagrama de Sequência - Reconfiguração de Serviços (OLIVEIRA MARTINS,2013)
A operação de descoberta de serviços utiliza como critério de seleção de serviços Web a prioridade descrita para cada serviço alternativo no XML de serviços utilizado pelo componente “ServiceDescriptor” e a disponibilidade do mesmo no contêiner OSGi. A seleção é direcionada pelos atributos “service-impl”, “service-spec” e “priority”, que é definido no “alternative-service”.
Esta operação inicia-se no lado cliente da SPL a partir da invocação do método “getEnd-Point” do “ApplicationService” (ver Figura 3.2). O método em questão recebe como parâmetro o ID do serviço desejado que é passado para o “SeviceContext”, onde a requisição é tratada com base nas informações passadas pelo “ServiceDescriptor”. Logo, o ID passado como parâmetro deve ser o ID de um serviço descrito no XML de serviços.
É de responsabilidade do “ServiceContext” enviar requisição ao contêiner OSGi uti-lizando como base os atributos “service-ref”, “service-impl” e “alternative-service” com a finalidade de encontrar um serviço que seja satisfatório para a invocação feita ao método “ge-tEndPoint”. O processo de seleção do serviço Web ocorre em três fases:
busca por um serviço Web que satisfaça a especificação e implementação definida nos atributo “service-spec” e o “service-Impl”;
busca por um serviço alternativo, levando em consideração a prioridade definida no atributo “priority”;
3.2. INTERVENÇÃO EXPLORATÓRIA 34
desejada.
A execução das fases de seleção, apresentadas anteriormente, é sequencial. No entanto só acontecerá a execução de uma fase subsequente caso a fase anterior seja incapaz de encontrar um serviço adequado. Após a seleção do serviço Web, o “ServiceContext” interage com o componente WSDescriptor passando como parâmetro o endereço onde o serviço selecionado encontra-se e recebendo como resposta o end point, o name space e o nome do serviço. Estes dados são retornados para o lado cliente da DSPL.
Figura 3.3: DYMOS - Diagrama de Sequência - Descoberta de Serviços (OLIVEIRA MARTINS,2013)
Outra operação do DYMOS é a “ContextHotBuild”. Esta é a operação responsável pelas operações de bind em tempo de execução. Todos os serviços Web que são tratados pela DSPL como features de segundo nível estão empacotados em bundles OSGi, tornando possível que eles sejam ativados e desativados, plugados e desplugados da DSPL sem a necessidade de que o software seja recompilado. Sendo assim, fica sob a responsabilidade do componente “OSGi Container” gerenciar a operação de “ContextHotBuild” a partir do gerenciamento do ciclo de vida dos bundles.
3.2
Intervenção Exploratória
Visto que, na perspectiva deKHEZRIAN et al.(2010), por um lado a descoberta de serviços permite que a relação entre cliente e serviços não seja tratada de forma fixa ou acoplada,
3.2. INTERVENÇÃO EXPLORATÓRIA 35
com vistas à seleção de um serviço mais adequado baseado em critérios estabelecidos. Por outro lado, a descoberta de serviços no DYMOS apesar de efetiva pode não ser a ideal ao considerar apenas um critério para a seleção dos serviços.
É importante pontuar que a utilização da prioridade como critério único além de limitar a descoberta de serviços a torna arbitrária e delega ao engenheiro de software a responsabilidade de determinar qual serviço deve ser plugado ao produto em tempo de execução na fase de design da aplicação. Este cenário pode caracterizar uma perda de dinamicidade para a DSPL. Com base nesta observação e no intuito de atingir o objetivo de propor uma abordagem de seleção em tempo de execução das características que irão compor uma DSPL e com base em uma análise de seus respectivos atributos de qualidade, propõe-se estender o DYMOS, passando a denomina-lo de DYMOS QoS.
A proposta de extensão consiste em modificar a situação b) apresentada na Seção 1.2. Nesta situação a seleção de serviço para substituir o serviço indisponível ocorre de acordo com a prioridade arbitrada. Propõe-se que a seleção de serviços ocorra de acordo com a qualidade dos serviços disponíveis no lado servidor no momento em que a solicitação é realizada no lado cliente.
Assim, será selecionado o serviço que tiver a maior pontuação fornecida pelo DYMOS QoS. Esta nova abordagem torna possível que uma terceira situação ocorra, onde sempre que realizada uma requisição a um serviço no lado cliente, o serviço retornado será sempre o que tiver a melhor avaliação dos atributos de qualidade no nível de serviço exigido.
Para tanto, dois novos componentes foram adicionados a arquitetura do DYMOS: o “ServiceLevelProvider” e o “Broker”, como pode ser visualizado na Figura 3.4. O primeiro armazena informações contextuais sobre os serviços Web de forma estruturada em um arquivo XML e atualiza essas informações de acordo com as mudanças que ocorrem no contexto. O componente “Broker” é responsável por analisar os atributos de qualidade para cada serviço em tempo de execução durante a descoberta de serviços.
A fim de que seja possível ao “Broker” realizar essa análise, o componente “ServiceLe-velProvider” armazena em um XML alguns atributos de qualidade, tais como nível de serviço, capacidade máxima, a capacidade atual, tempo de resposta e custo. A análise do “Broker” calcula a utilidade (YU; LIN,2005) de cada serviço no nível de serviço escolhido e envia esta informação para o componente “ServiceContext”, que continua sendo o principal responsável pelo processo de descoberta de serviços.
Esta intervenção requer uma modificação no componente “ServiceContext” de modo que durante a execução do método “findAlternativeService” a prioridade descrita no XML de serviços deve ser desconsiderada, os atributos de qualidade de cada serviço devem ser recuperadas e a utilidade de cada serviço deve ser calculada.
A Figura 3.5 ilustra como essa modificação afeta a sequência da execução do processo de descoberta de serviços. Ao perceber que a implementação do serviço requisitado não está presente no contêiner OSGi, o “ServiceContext” requisita ao “ServiceLevelProvider” a lista dos
3.2. INTERVENÇÃO EXPLORATÓRIA 36
Figura 3.4: DYMOS QoS - Diagrama de Pacotes
Figura 3.5: DYMOS QoS - Diagrama de Sequência - Descoberta de Serviços
serviços alternativos com seus respectivos valores para os atributos de qualidade estruturados dentro de objetos “AlternativeServiceQoS”.
3.2. INTERVENÇÃO EXPLORATÓRIA 37
Os atributos de qualidade têm valores distintos para cada serviço em cada nível de serviço, como é apresentado no Código 3.3 que representa o XML de atributos de qualidade utilizado pelo “ServiceLevelProvider”. Os atributos de qualidade dos serviços utilizados nessa abordagem são: custo, capacidade máxima e atual, nível, tempo de resposta, confiabilidade e disponibilidade.
Listing 3.3: XML de Atributos de Qualidade ... <serviceLevel id="1"> <cost>2,07</cost> <curCapacity>0</curCapacity> <level>1</level> <maxCapacity>42</maxCapacity> <name>imageService1</name>
<responseTime>23379</responseTime>
<serviceSpec>com.assertLab.imageService</serviceSpec> </serviceLevel> <serviceLevel id="2"> <cost>0,29</cost> <curCapacity>38</curCapacity> <level>2</level> <maxCapacity>48</maxCapacity> <name>imageService1</name>
<responseTime>44639</responseTime>
<serviceSpec>com.assertLab.imageService</serviceSpec> </serviceLevel>
...
Apesar da nomenclatura dos atributos de qualidade dizer muito a respeito dos mesmos, estes não são suficientes para evitar interpretações distintas. Por isso, vale ressaltar que o atributo de custo representa o custo de um determinado serviço em um dado nível de serviço. Esta abordagem não determina como o custo do serviço deve ser definido, possibilitando a utilização do DYMOS QoS de acordo com diversos modelos de precificação.
Os atributos de capacidade máxima e atual representam respectivamente quantos clientes ao mesmo tempo podem utilizar e quantos estão utilizando um serviço em um determinado nível de serviço. O atributo nível refere-se ao nível de serviço ao qual os demais atributos de qualidade pertencem. O atributo de tempo de resposta armazena o valor de qual tempo de resposta em microssegundos deve ser esperado de um serviço no nível de serviço em questão.
Os atributos de nome e especificação do serviço, tem função meramente identificadora. Enquanto os atributos de confiabilidade e disponibilidade são baseados em dados históricos. O valor do primeiro é incrementado sempre que o serviço requisitado responde a uma requisição em
3.2. INTERVENÇÃO EXPLORATÓRIA 38
tempo igual ou menor ao especificado no atributo de tempo de resposta e decrementado quando ocorre o contrário. O atributo de disponibilidade é incrementado sempre que uma requisição a um serviço tem uma resposta e decrementado quando o serviço se mostra indisponível.
3.2.1
Seleção de Serviços
De acordo com o que já foi explanado, o componente “Broker” é responsável por realizar as análises dos atributos de qualidade dos serviços Web. O “Broker” do DYMOS QoS é derivado das abordagens deCHEN; YU; LIN(2003);YU; LIN (2004,2005), onde cada provedor de serviços Web oferece diversos níveis de serviço para cada funcionalidade.
Nesta abordagem fica sob a responsabilidade do “Broker” coletar as informações a res-peito dos candidatos a provedores de serviço. Para tanto, este componente, apanha as definições de serviço e nível de serviço dos clientes e então realiza uma verificação nos compromissos de qualidade oferecidos pelos serviços.
O “Broker” utiliza uma função para a otimização da seleção dos serviços Web chamada porYU; LIN(2004,2005) de função de utilidade. Esta função é baseada em um conjunto de parâmetros que englobam informações estáticas (nível de serviço), as necessidades de qualidade do lado cliente e a capacidade dinâmica do servidor (carga).
Para que seja possível o entendimento da função de utilidade algumas definições precisam ser esclarecidas. A primeira delas é que serviços Web que oferecem a mesma funcionalidade podem ter características não funcionais distintas. O conjunto desses serviços que oferecem a mesma funcionalidade é chamado de classe de serviço e denotado por S, sendo cada serviço de uma classe denotado individualmente por s. O nível de serviço oferecido por um único serviço Webé denotado por l. A confiabilidade é uma restrição de qualidade a respeito do atraso no
provimento de um serviço denotada por R.
Cada serviço Web tem suas próprias definições. O número de níveis de serviço que cada serviço Web oferece é obtido a partir da definição L(s) e o tempo de serviço é denotado por e(s, l). As definições adotadas a respeito da carga de cada serviço são Cmax(s, l) e Ccur(s, l), onde o primeiro denota a capacidade máxima e o segundo a carga atual em um determinado nível de serviço. Por fim, o custo para cada nível de serviço é denotado por c(s, l).
A função de utilidade toma as decisões de seleção com base na função de benefício (Equação 3.1), que por sua vez baseia-se na carga do serviço. A função é utilizada para que os serviços selecionados tenham uma baixa carga, oferecendo assim menores tempos de resposta reais. Isso implica em um balanceamento global das cargas dos serviços evitando sobrecargas.
b(s, l) =Cmax(s, l) −Ccur(s, l) Cmax(s, l) 3.1
A função de utilidade pode ser vista na Equação 3.2, onde wbe wc são os pesos de um benefício de custo, b(s, l) e c(s, l) são os benefícios e os custos, escolhendo serviço s no nível de l, avgbe avgc são o benefício médio e o custo médio para os serviços disponíveis no nível de
3.3. CONCLUSÕES 39
serviço escolhido, e, finalmente, stdbe stdcsão o desvio padrão de benefício e custo. O objetivo dessa função é maximar o benefício e minimizar o custo no momento de uma seleção de serviço.
F(s, l) = wb∗ ( b(s, l) − avgb stdb ) + wc∗ (1 − c(s, l) − avgc stdc ) 3.2
3.3
Conclusões
Este capítulo tratou da análise e intervenção exploratória realizadas para contribuir com os objetivos deste estudo apresentando um entendimento do processo de descoberta de serviços do DYMOS e a classificação das features utilizadas por este. Partindo desta análise foi possível construir uma abordagem de descoberta de serviços com base na análise de atributos de QoS.
A análise implementada para a seleção de serviços é fundamentada na idéia de que um componente pode atuar como mediador avaliando a necessidade do cliente e encontrando um serviço que melhor se enquadre nesta necessidade. O trabalho do componente mediador (“Broker”) é regido pela relação custo-benefício especificada na forma de funções matemáticas definidas porYU; LIN(2004,2005). O próximo capítulo trata da de uma validação realizada com a abordagem aqui proposta para demonstrar a sua efetividade. Assim como é relatada uma avaliação da performance da mesma.
