UNIVERSIDADE FEDERAL DA BAHIA
INSTITUTO DE MATEMÁTICA
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
Marco Antonio Santos Almeida Filho
Portabilidade de Serviços Web Semânticos na
Computação na Nuvem através do OWL-S
Composer
Salvador
2013.1
Marco Antonio Santos Almeida Filho
Portabilidade de Serviços Web Semânticos
na Computação na Nuvem através do
OWL-S Composer
Monografia apresentada ao Curso de
graduação em Ciência da Computação,
Departamento de Ciência da Computação,
Instituto de Matemática, Universidade Federal da Bahia, como requisito parcial para
obtenção do grau de Bacharel em Ciência da
Computação.
Orientadora: Daniela Barreiro Claro
Salvador
2013.1
RESUMO
A necessidade de recursos sob medida, baixo custo e maior disponibilidade fez com que a
indústria e a academia começassem a migrar as suas aplicações e documentos para a nuvem.
De forma análoga, o uso de Serviços Web para realizar os mais diversos tipos de tarefa continua em crescimento, mais especificamente os Serviços Web Semânticos, que além de reduzir a
ambiguidade entre serviços, também permitem a composição entre serviços de modo semântico
abrindo a possibilidade para um maior conjunto de tarefas e facilitando que um cliente alcance
um objetivo final com maior praticidade. É comum que clientes utilizem mais de um provedor
de nuvem ao mesmo tempo para atender aos seus requisitos, contudo, a falta de padrões existentes para publicação de serviços entre os diversos provedores de nuvem é um dos fatores que
dificultam o uso da nuvem para publicação de Serviços Web Semânticos. Publicar um mesmo
serviço em nuvens diferentes implica em interferência do usuário para a publicação em cada
uma das nuvens. O OWL-S Composer é um plug-in para a plataforma Eclipse com o objetivo de
modelar composições de Serviços Web Semânticos de forma visual. Neste contexto, o presente
trabalho visa implementar sobre o OWL-S Composer uma interface que intermedia a relação
cliente e nuvem para tornar a etapa de publicação de Serviços Web Semânticos em nuvens um
processo mais simples e intuitivo.
Palavras-chave: Serviços Web Semânticos, Computação em Nuvem, Interoperabilidade
entre nuvens, Serviço em Nuvem Unificado, OWL-S Composer, Eclipse
ABSTRACT
Industry and academy started to move their applications and documents to the clouds based
on their needs of a on-demand, low cost and ubiquitous environment. Analogously, the use
of Web Services to perform various tasks continues to grow, specifically the Semantic Web
Services, that in addition to reducing the ambiguity it also allows the composition between
services which opens un the possibility to work with a larger set of tasks and make it easier
for a client to reach their final goal with ease. It is common that clients use more than one
cloud provider at a time in order to attend their requirements however the lack of patterns to
publish services between the cloud providers hampers the use of Web Services on the cloud.
Publishing a service on any cloud implies on the user interference for each cloud being used to
publish. The OWL-S Composer is a plug-in for the Eclipse platform and it is used to visually
model Semantic Web Services compositions. This work aims to implement over the OWL-S
Composer a interface that mediates between client and cloud to make the publishing of Semantic
Web Services on the cloud a more simple and intuitive process.
Keywords: Semantic Web Services, Cloud Computing, Interoperability between clouds,
Unified Cloud Service, OWL-S Composer, Eclipse
SUMÁRIO
Lista de Figuras
Lista de Tabelas
Lista de abreviaturas e siglas
1
2
3
4
Introdução
9
1.1
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.2
Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.3
Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Serviços Web Semânticos
12
2.1
OWL-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2
Arquitetura Orientada a Serviços . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3
Composição de Serviços Web Semânticos . . . . . . . . . . . . . . . . . . . .
16
Computação em nuvem
17
3.1
Características essenciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2
Modelos de serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.3
Modelos de implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.4
Provedores de serviços em nuvem . . . . . . . . . . . . . . . . . . . . . . . .
21
Serviços Web Semânticos em nuvem
23
4.1
24
Portabilidade e interoperabilidade entre nuvens . . . . . . . . . . . . . . . . .
5
6
Trabalhos relacionados
27
5.1
VRESCo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.2
Multi-cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
Interoperabilidade para o OWL-S Composer
30
6.1
Histórico do OWL-S Composer . . . . . . . . . . . . . . . . . . . . . . . . .
30
6.2
Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
6.3
Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
6.4
Projeto Estrutural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
6.4.1
Nuvens utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
6.4.2
Arquitetura do OWL-S Composer 4.0 . . . . . . . . . . . . . . . . . .
34
Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
6.5
7
Experimentos e Resultados
7.1
8
38
1o experimento: Divulgação e avaliação do OWL-S Composer para Mestrado e
Graduação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
7.1.1
Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
7.2
2o experimento: Publicação de um projeto na Amazon e no Eucalyptus . . . . .
41
7.3
3o experimento: Divulgação e testes realizados pela Empresa Júnior de Informática da UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
7.3.1
45
Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusão
46
8.1
Dificuldades encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
8.2
Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
Referências Bibliográficas
48
LISTA DE FIGURAS
2.1
Ontologia Service do OWL-S (MARTIN et al., 2004). . . . . . . . . . . . . . .
14
2.2
Arquitetura Orientada a Serviços. . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3
Diferença entre orquestração e coreografia (MICHELS, 2009). . . . . . . . . .
16
3.1
Modelos de serviço de computação na nuvem (ZHANG; CHENG; BOUTABA,
2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.1
Ciclo de vida de um Serviço Web (FERREIRA, 2010). . . . . . . . . . . . . .
23
4.2
Esquema de interoperabilidade entre nuvens (BHUKYA REETA SONY A.L,
2012). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.1
Modelo de metadados para um serviço (HUMMER et al., 2011). . . . . . . . .
28
6.1
Evolução da arquitetura do OWL-S Composer . . . . . . . . . . . . . . . . . .
30
6.2
Exemplo de composição feita pela interface do OWL-S Composer . . . . . . .
31
6.3
Arquitetura do OWL-S Composer 4.0 . . . . . . . . . . . . . . . . . . . . . . .
35
7.1
Seleção do projeto a ser pré-publicado . . . . . . . . . . . . . . . . . . . . . .
42
7.2
Seleção das nuvens e pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
7.3
Inserção de credenciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
7.4
Publicando com o plugin da Amazon para Eclipse . . . . . . . . . . . . . . . .
43
7.5
Página do serviço desenvolvido publicado na amazon . . . . . . . . . . . . . .
44
LISTA DE TABELAS
3.1
Comparativo entre public cloud e data center convencional (ARMBRUST et
al., 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
LISTA DE ABREVIATURAS E SIGLAS
ABFR
Advanced Back & Forward Recovery,
p. 30
API
Application Programming Interface,
p. 33
EMF
Eclipse Modeling Framework Project,
p. 32
GEF
Graphical Editing Framework,
p. 32
GMF
Graphical Modeling Framework,
p. 32
IOPE
entrada e saída, pré-condições, efeitos,
p. 19
JET
Java Emitter Templates,
p. 33
MAPE-K
Monitor, Analyse, Plan, Execute, Knowledge,
p. 22
MDR
Monitoramento, Diagnóstico e Recuperação,
p. 40
MVC
Model-View-Controller,
p. 32
OWL
Ontology Web Language,
p. 11
OWL-S
Ontology Web Language for Service,
p. 18
QoS
Qualidade do serviço,
p. 19
SAWSDL
Semantic Annotations for WSDL,
p. 18
SHIWS
Self-healing Integrator for Web Services,
p. 27
SOA
Arquitetura Orientada à Serviços,
p. 15
SOAP
Simple Object Access Protocol,
p. 15
SWS
Serviços Web Semânticos,
p. 11
UDDI
Universal Description, Discovery and Integration,
p. 16
WSDL
Web Services Description Language,
p. 15
WSMO
Web Service Modeling Ontology,
p. 18
WTP
Web Tool Plugin,
p. 31
XML
eXtensible Markup Language,
p. 15
9
1
INTRODUÇÃO
A computação nas nuvens se tornou uma tendência significante com alguns especialistas
esperando que ela remodele o mercado de tecnologia de informação (LEAVITT, 2009). Fatores
que fazem com que a academia e o mercado migrem suas atividades para a nuvem se devem
à sua capacidade em prover recursos sob demanda de maneira escalável, segura e de vaixo
custo. Aliado à isso, os serviços em nuvem podem ser acessados em uma gama de dispositivos,
incluindos PCs, laptops e smartphones.
Desde a introdução da Web Semântica (LEE; HENDLER; LASSILA, 2001) criou-se um
interesse em prover serviços automáticos para atender necessidades de usuários que variam de
modo significativo em sua complexidade. Estes serviços podem ser desde consulta do clima
para o fim de semana, até classificação de documentos através de mineração de dados. Para
evitar falsos cognatos e promover composições automáticas de serviços, os Serviços Web Semânticos foram criados, e desta forma, é possível utilizar por exemplo, serviços que buscam
pela palavra “banco” e diferenciem o “banco” de agência financeira para o “banco” de assento.
Para prover Serviços Web Semânticos mais complexos foi utilizado o conceito de composição de serviços (CLARO; ALBERS; HAO, 2005). Esta composição permite que clientes
utilizem mais de um serviço por vez. Assim, empresas podem desenvolver mais serviços que
atendam uma necessidade isolada, mas que ao serem compostos podem fornecer uma diversidade de funcionalidades. As composições são feitas por meio de linguagens como OWL-S
(MARTIN et al., 2004). Prover a clientes buscar e selecionar esses serviços também é um tema
importante e o OWL-S facilita esse processo de descoberta e selecão, pois incorpora informações adicionais, não ambíguas e interpretáveis computacionalmente.
Unir Serviços Web Semânticos e computação nas nuvens é permitir que clientes tenham a
possibilidade de publicar, buscar, compor e executar serviços através de uma arquitetura escalável, segura e de baixo custo.
10
1.1
MOTIVAÇÃO
Por ter um desenvolvimento rápido e disperso, a computação em nuvem ainda não é uma
tecnologia padronizada. Esta falta de padrões dificulta a tarefa de publicação de um mesmo
Serviço Web Semântico em nuvens diferentes. Aliado a isso, é comum que clientes utilizem
serviços de diferentes provedores simultaneamente (PARAMESWARAN; CHADDHA, 2009).
Para tornar esses serviços em serviços portáveis seria necessário uma interface que intermedie
cliente e nuvem, tornando o manejo do ciclo de vida de um Serviço Web Semântico uma tarefa
simples e intuitiva, independente da nuvem utilizada.
Para solucionar esse problema nasce o conceito de Serviço em Nuvem Unificado (Unified
Cloud Service), cujo objetivo é permitir que clientes a publiquem em qualquer tipo de nuvem
com suporte à publicação de sites de Serviços promovendo a interoperabilidade entre nuvens.
O plug-in OWL-S Composer 3.1 (ALVES, 2011) para a plataforma Eclipse (FOUNDATION, 2013) permite de maneira simples e prática a manipulação do ciclo de vida de Serviços
Web Semânticos em servidores convencionais. Através de uma modelagem de composições de
maneira visual, o plug-in elimina longas tarefas de descrição composições. O OWL-S Composer
3.1 é capaz de publicar, buscar, compor e monitorar Serviços Web Semânticos.
1.2
PROPOSTA
A publicação de Serviços Web Semânticos ainda é um processo custoso, devido às diferenças existentes entre os provedores de nuvem. No caso em que um cliente tenha um repositório
de Serviços Web Semânticos em uma nuvem e deseje migrar esse repositório para outro provedor será necessário alterar parte do código e os documentos existentes.
Para automatizar a tarefa de publicação de serviços na nuvem, independente de provedor
é necessário criar uma camada intermediária que torne o processo de publicação de serviços
transparente para o cliente.
Apesar de ser possível publicar Serviços Web Semânticos em nuvem, é necessário realizar
muitos passos para permitir que a publicação seja concluída e a etapa de configuração está propensa a erros. Além disso, migrar os serviços para outra nuvem implica em grande esforço por
parte do usuário, muitas vezes sendo necessário reescrever o projeto inteiramente. Diante disso,
a proposta presente neste trabalho é atualizar o plug-in OWL-S Composer, criando um Serviço
em Nuvem Unificado que possibilite clientes a trabalharem com um conjunto de provedores de
11
nuvem mais comuns no mercado e na academia.
Para identificar em que tipo de trabalho focar no futuro são realizadas pesquisas com estudantes de graduação e de mestrado para avaliarem o textitplug-in, suas funcionalidades, pontos
fortes e pontos fracos.
1.3
ESTRUTURA DO TRABALHO
Este trabalho está organizado em oito capítulos distribuídos da seguinte forma: o capítulo
2 introduz a fundamentação teórica deste trabalho, apresentando os Serviços Web Semânticos,
suas tecnologias básicas e uma arquitetura orientada a serviços; o capítulo 3 aborda sobre a
computação na nuvem, suas características essenciais e os provedores mais comuns; o capítulo
4 descreve como é possível e para que serve a integração entre Serviços Web Semânticos e computação em nuvem; no capítulo 5 são vistos os trabalhos relacionados com a presente proposta
assim como as suas vantagens e desvantagens; o capítulo 6 é focado no OWL-S Composer, as
funcionalidades presentes e a arquitetura para lidar com a portabilidade e no capítulo 7 são apresentados os experimentos e resultados alcançados; por fim, no capítulo 8 está a conclusão do
trabalho com as dificuldades enfrentadas e sugestões de trabalhos que podem ser desenvolvidos
no futuro.
12
2
SERVIÇOS WEB SEMÂNTICOS
Atualmente, grande parte do conteúdo da Web está dirigido para a leitura humana, não para
computadores extraírem significados. A Web Semântica é uma maneira de extrair conteúdo
relevante de páginas Web, em um ambiente onde agentes de software navegam entre páginas
realizando tarefas complexas para os seus respectivos usuários. A proposta da Web Semântica
não é ser uma área separada da Web e sim uma extensão desta, em que as informações são
fornecidas de maneira mais organizada, possibilitando uma melhor interação entre humanos e
computadores (LEE; HENDLER; LASSILA, 2001).
Existem diversas tecnologias para se trabalhar com a Web Semântica como RDF, RDFS,
SHOE, DAML-ONT, OIL, DAML+OIL, DAML-L e OWL (ALVES; CLARO, 2012). Por outro
lado, a indústria propõe o uso de Serviços Web para transformar a Web de um estado passivo
(repositório de documentos estáticos) para um estado dinâmico (repositório de serviços dinâmicos). Esse estado dinâmico pode ser auziliado pela atuação independente da máquina para
satisfação da necessidade do usuário, necessitando que a Web seja mais descritiva em seu conteúdo existente, ou seja é necessário a adição de semântica ao conteúdo. Contudo, os padrões
para Serviços Web como WSDL, UDDI, XLANG, WSFL, ebXML e WS-BPEL não são de
todo orientados à semântica (SIVASHANMUGAM et al., 2003) e por isso surgiram diversos
projetos como por exemplo: Ontology Web Language for Service (OWL-S) (MARTIN et al.,
2007), WSMO (Web Service Modeling Ontology) (LAUSEN; POLLERES; ROMAN, 2005) e
o Semantic Annotations for WSDL (SAWSDL) (KOPECKY et al., 2007). É nesse contexto que
surgem os Serviços Web Semânticos (SWS) (WANG; ZHANG; SUNDERRAMAN, 2004).
O plugin OWL-S composer, estendido pelo presente trabalho, utiliza a linguagem OWL-S
(Ontology Web Language for Services). Essa linguagem se baseia na OWL (Web Ontology
Language) que por sua vez utiliza o XML para marcação e descrição de serviços. Detalhes
sobre essa linguagem serão vistos na seção seguinte.
Ao reduzir os limites de uma requisição de usuário para uma única operação automática, as
linguagens para descrever Serviços Web baseadas em ontologias tem um enorme potencial para
13
negócios na Web. Essas linguagens permitem que Serviços Web se adaptem às mudanças no
conteúdo das mensagens ou no protocolo de interação. Não apenas isso, mas essas linguagens
permitem a criação de serviços sob demanda (PAOLUCCI; SYCARA, 2003).
2.1
OWL-S
Movidos pelo movimento para o desenvolvimento da nova geração da Web que autores
em (MARTIN et al., 2004) desenvolveram uma linguagem chamada Ontology Web Language
for Service (OWL-S). Esta pode ser descrita como uma linguagem para descrever serviços,
refletindo no fato de que provê um vocabulário padrão que pode ser utilizado em outros aspectos
da linguagem OWL para criar descrição de serviços.
A linguagem OWL-S tem como principais objetivos: (1) prover um framework de propósito
geral para descrever Serviços Web; (2) oferecer suporte a automação de gerenciamento de serviços e uso por parte de agentes de software; (3) construir, de forma integral, sobre os padrões
para Serviços Web existentes e nos padrões existentes para a Web Semântica; e (4) ser abrangente o suficiente para comportar todas as etapas do ciclo de vida de um serviço (MARTIN et
al., 2007).
A estrutura de ontologia de serviços do OWL-S é motivada pela necessidade de se compreender três aspectos essenciais de um serviço. Esses três pontos são ServiceProfile, ServiceModel, ServiceGrounding (MARTIN et al., 2004):
• ServiceProfile.
Referência para as funcionalidades de um serviço. Adequado para as situações onde um
agente de busca de serviços necessita determinar se um serviço satisfaz as suas necessidades. Nesta forma de representação inclui uma descrição do que deve ser alcançado
pelo serviço, limitações na aplicabilidade do serviço e na qualidade do serviço (QoS) , e
requisitos que o usuário do serviço deve satisfazer para usar o serviço de forma exitosa.
• ServiceModel.
Indica a um cliente como usar um serviço, detalhando o conteúdo semântico das requisições, as condições necessárias para que resultados particulares aconteçam e, quando
necessário, a sequência de passos que levam para esses resultados. Em casos de serviços
não triviais (aqueles que são compostos de diversos passos em uma só chamada) esse
detalhamento pode ser usado por um agente de busca de serviços em pelo menos quatro
maneiras: (1) realizar uma análise mais profunda se determinado serviço satisfaz as ne-
14
cessidades; (2) compor descrições de serviços de vários serviços para realizar uma tarefa
específica; (3) durante o curso de execução de um serviço, coordenar as atividades dos
diferentes participantes; (4) monitorar a execução do serviço.
• ServiceGrounding.
Especifíca os detalhes de como um agente pode acessar um serviço. Tipicamente um
ServiceGrounding irá especificar um protocolo de comunicação, formatos de mensagem,
e outros detalhes específicos do serviço como números de portas usados para contactar
um serviço. Além disso, o ServiceGrounding deve especificar, para cada tipo de entrada
ou saída semântica definida no ServiceModel, uma maneira livre de ambiguidades para
realizar troca de dados, isto é, o emprego técnicas de serialização.
Na Figura 2.1 se vê uma classe Service que serve como ponto de referência para um Serviço
Web. Onde uma instância de Service existirá para cada Serviço criado. Cada instância de um
Serviço Web apresenta (presents) uma descrição de ServiceProfile, é descrita por uma descrição
de ServiceModel e suporta (supports) uma descrição de ServiceGrounding. É necessário levar
em consideração dois aspectos sobre a cardinalidade dessa ontologia: um serviço pode ser
descrito por no máximo um ServiceModel e estar associado a exatamente um ServiceGrounding.
Figura 2.1: Ontologia Service do OWL-S (MARTIN et al., 2004).
2.2
ARQUITETURA ORIENTADA A SERVIÇOS
A Arquitetura Orientada a Serviços (SOA) é um paradigma para organizar e utilizar entidades distribuídas que podem estar sob controle de domínios diferentes (MACKENZIE et al.,
2006).
15
O uso de SOA não está diretamente relacionada e nem dependente dos Serviços Web. Contudo, os benefícios da SOA são mais evidentes ao serem usados em Serviços Web (MICHELS,
2009), entre eles: distribuição, heterogeneidade, dinamismo, transparência e orientação a processos. Na Figura 2.2 o fluxo de processos relacionados à arquitetura é apresentado. O Provedor
do Serviço desenvolve e publica uma funcionalidade no Repositório de Serviço (1). Quando disponível, o serviço no Repositório de Serviço está pronto para ser localizado pelo Solicitante do
Serviço (2). A chamada para utilizar o serviço é feita do Solicitante do Serviço para o Provedor
do Serviço (3).
Figura 2.2: Arquitetura Orientada a Serviços.
Com o crescimento de uma arquitetura orientada a serviços, aumenta a necessidade de se
ter entidades responsáveis pela integração de serviços. Essas entidades intermediam e coordenam a execução dos processos. Para que os Serviços Web usem todo o seu potencial e sejam
beneficiados pela arquitetura SOA é necessário que estas entidades tornem possíveis interações
síncronas e assíncronas e com manutenção de estado (stateful). Nesse caso dois termos são
utilizados para expressar a coordenação de processos entre serviços: orquestração e coreografia
(MICHELS, 2009). A orquestração é um processo que pode interagir com processos internos e
externos, representada pelo ponto de vista do coordenador (aquele que tem o controle do processo). A coreografia, por sua vez, é um processo mais colaborativo, em que cada uma das
partes envolvidas descreve o seu papel no processo de interação.
A Figura 2.3 ilustra as diferenças entre os dois conceitos recém apresentados. A orquestração é centralizada na interação dos serviços na perspectiva do coordenador, enquanto a coreografia é usada mais para ordenação de mensagens e não há a necessidade de um coordenador.
2.3
COMPOSIÇÃO DE SERVIÇOS WEB SEMÂNTICOS
O processo de composição de Serviços Web é realizado quando nenhum serviço atômico
(que realiza uma tarefa específica) ou composto disponível é capaz de realizar uma requisição,
16
Figura 2.3: Diferença entre orquestração e coreografia (MICHELS, 2009).
mas a composição desses serviços atômicos e compostos disponíveis e torna esse processo
factível (KUMAR; MISHRA, 2008).
Uma composição de Serviços Web pode ser alcançada de duas maneiras: estática e dinâmica. Uma composição estática se trata de uma especificação na forma de um script (na
notação XML). Esse script essencialmente lista os diversos serviços a serem executados e específica como os resultados da execução de um serviço são mapeados em entrada de outros.
Essa é uma funcionalidade importante para manter serviços com um propósito específico. De
maneira similar, a composição dinâmica se diferencia pelo seu script de composição ser gerade
em tempo de execução (NANDIGAM; GUDIVADA; KALAVALA, 2005).
Uma composição de Servicos Web Semânticos não é muito diferente da composição de
Serviços Web convencionais, contudo, os primeiros possuem a característica especial para permitir a identificação de conceitos definidos em domínio e dessa forma é possível realizar uma
composição mais eficaz e com menor probablididade de erros quando comparada com a forma
sem significado agregado.
Uma grande quantidade de técnicas de composição têm sido desenvolvidas por pesquisadores e a escolha da técnica de composição mais apropriada ao processo afeta o resultado da
composição. Uma escolha apropriada para composição de Serviços Web Semânticos é capaz
de reduzir custos, tempo e esforço, além de produzir melhores resultados (KUMAR; MISHRA,
2008).
17
3
COMPUTAÇÃO EM NUVEM
O termo computação em nuvem e seus termos associados sofrem de uma falta de definição
largamente aceita, pois são termos recentes e definidos mais pelo uso que pelos documentos
escritos. Alguns fornecedores de serviços em nuvem utilizam definições diferentes para os
mesmos termos (ARMBRUST et al., 2010). No presente trabalho serão seguidos as definições
propostas pelo Instituto Nacional de Padrões e Tecnologias (NIST) dos Estados Unidos (MELL;
GRANCE, 2011).
A computação na nuvem é um modelo que visa permitir de maneira onipresente, conveniente e sob demanda acesso a uma série de recursos computacionais configuráveis (exemplos:
redes, servidores, armazenamento, aplicações e serviços) que podem ser disponibilizados e liberados com esforço de gerenciamento mínimo ou interação com provedor de serviços. Esse modelo é composto por cinco características essenciais, três modelos de serviços e quatro modelos
de implantação (MELL; GRANCE, 2011). As definições da NIST permanecem em rascunho,
mas as suas definições já são largamente utilizadas pela academia (CHEN; PAXSON; KATZ,
2010)(ZHANG; CHENG; BOUTABA, 2010)(VOOSLUYS; BROBERG; BUYYA, 2011).
3.1
CARACTERÍSTICAS ESSENCIAIS
Para caracterizar um serviço de nuvem, cinco aspectos básicos devem ser cumpridos pelo
provedor do serviço. Estes aspectos estão definidos à seguir.
• Serviços sob demanda.
Um cliente pode de forma unilateral prover capacidades computacionais, como tempo
de servidor e capacidade de armazenamento conforme necessário automaticamente, sem
necessidade de interação humana com cada provedor de serviço.
• Amplo acesso à rede.
Funcionalidades estão disponíveis na rede e podem ser acessados por mecanismos pa-
18
drões que promovem o uso de plataformas a nível de cliente (exemplos: telefones, tablets,
notebooks e estações de trabalho).
• Pool de recursos.
Os recursos computacionais do provedor estão agrupados para servir consumidores usando
um modelo com múltiplos clientes, com diferentes recursos físicos e virtuais atribuídos
de acordo com a demanda do cliente. Existe uma independência da localização do serviço, já que o cliente não tem controle ou conhecimento sobre o local exato dos recursos
providos, mas é capaz de especificar em um nível maior de abstração (exemplos: país,
estado ou data center).
• Elasticidade rápida.
Funcionalidades podem ser providas ou liberadas, algumas vezes automaticamente, para
escalar rapidamente a demanda externa ou interna. Para a perspectiva do consumidor as
funcionalidades disponíveis geralmente aparecem como ilimitadas e podem ser apropriadas em qualquer quantidade a qualquer momento.
• Serviços sob medida.
Sistemas em nuvem automaticamente controlam e otimizam o uso de recursos ao alavancar uma funcionalidade de medição (geralmente paga por uso) em algum nível apropriado de abstração. Uso de recursos podem ser monitorados, controlados, e reportados,
provendo transparência para ambos provedor e cliente.
3.2
MODELOS DE SERVIÇO
De maneira geral a arquitetura de um ambiente de computação em nuvem é dividido em
quatro camadas para três modelos de serviço (ZHANG; CHENG; BOUTABA, 2010). A Figura
3.1 ilustra esses três modelos e os exemplifica.
• Software as a Service (SaaS).
A funcionalidade disponibilizada para o cliente está vinculada ao uso das aplicações disponibilizadas pelo provedor da infraestrutura de nuvem. As aplicações são acessíveis por
diversos disposítivos a nível de cliente (exemplos: navegador Web, um programa). Neste
modelo de serviço o cliente não tem controle sobre as camadas de infraestrutura inferiores
como rede, servidores, sistemas operacionais, armazenamento, etc.
• Platform as a Service (PaaS).
Neste modelo o cliente é capaz de hospedar na nuvem aplicações criadas ou adquiridas
19
Figura 3.1: Modelos de serviço de computação na nuvem (ZHANG; CHENG; BOUTABA,
2010).
pelo cliente. Essas aplicações devem ser feitas utilizando linguagens de programação,
bibliotecas, serviços e ferramentas suportadas pelo provedor. Similar ao modelo anterior,
o cliente de um provedor PaaS não tem acesso à rede, servidores, sistemas operacionais ou
armazenamento, porém tem controle sobre as aplicações implantadas e suas respectivas
configurações disponibilizadas pelo ambiente de hospedagem de aplicações.
• Infrastructure as a Service (IaaS).
A funcionalidade disponibilizada para o cliente é para prover procesamento, armazenamento, redes e outros recursos computacionais onde o cliente pode implantar e executar
software de forma arbitrária, podendo incluir sistemas operacionais e aplicações. O cliente não gerencia ou controla as camadas inferiores de infraestrutura, mas possui controle
sobre sistemas operacionais, armazenamento, e aplicações implantadas e possivelmente
controle limitado sobre os componentes de rede (exemplo: firewalls).
Comparada aos modelos tradicionais de hospedagem, a arquitetura da computação em nuvem é mais modular. O baixo acoplamento entre as camadas permite que cada camada se desenvolva separadamente. Essas características fazem com que a computação em nuvem suporte
um largo número de requisitos de aplicações com um mínimo de esforço (ZHANG; CHENG;
BOUTABA, 2010).
Ambientes de desenvolvimento em nuvem são implementados nos topos dos serviços de
infraestrutura para oferecer funcionalidades de desenvolvimento e implantação de aplicações.
20
Neste nível vários modelos de programação, bibliotecas, APIs e editores de mashups 1 possibilitam a criação de um variedade de negócios. Uma vez implantadas essas aplicações podem ser
consumidas por usuários (VOOSLUYS; BROBERG; BUYYA, 2011).
É possível que um provedor de um PaaS seja executado sobre um outro provedor IaaS,
mas atualmente são geralmente as mesmas organizações que provêm os mesmos serviços. Por
isso, essas organizações são chamadas de provedores de nuvem ou provedores de infraestrutura
(ZHANG; CHENG; BOUTABA, 2010).
3.3
MODELOS DE IMPLANTAÇÃO
No momento de decidir em qual ambiente em nuvem operar é necessário ter em mente
qual é o tipo de implantação a ser feita. Alguns provedores de serviços estão interessados em
diminuir o custo operacional, outros focam em confiabilidade e segurança (ZHANG; CHENG;
BOUTABA, 2010). Existem quatro maneiras de implantar uma infraestrutura em nuvem, cada
uma com suas vantagens e desvantagens.
• Private cloud.
A infraestrutura é disponibilizada para uso exclusivo de uma única organização composta
por múltiplos clientes. Pode pertencer, ser gerenciada e operada pela própria organização,
um terceiro ou uma combinação de ambos.
• Community cloud.
Esse modelo de implantação é para uso exclusivo de uma comunidade específica de clientes de organizações que compartilham interesses (exemplos: missões, requisitos de
segurança, políticas). Pode pertencer, ser gerenciada e operada por uma ou mais das
organizações da comunidade, um terceiro ou a combinação de ambos.
• Public cloud.
Disponibilizada para uso aberto do público. Pode pertencer, ser gerenciado e operado por
um empreendimento, uma academia ou instância do governo ou a combinação destes.
Existe sobre as premissas do provedor da nuvem.
• Hybrid cloud.
Esta infraestrutura é uma composição de duas ou mais infraestruturas de nuvem distintas
(private, community, public) que permanecem como entidades únicas, mas que se mantém
conectadas por uma tecnologia padrão que permite portabilidade.
1 http://pipes.yahoo.com/pipes/
21
Vantagem
Public cloud
Aparência de recursos computacionais
Sim
infinitos sob demanda
Eliminação de um compromisso
Sim
antecipado por usuários
Possibilidade de pagar por uso de
Sim
recursos computacionais em um base
de tempo pequena conforme necessário
Economias de escala devido a grandes
Sim
data centers
Maior utilização de multiplexação de
Sim
cargas de trabalho de diferentes
organizações
Simplifica operação e aumento de
Sim
utilização via virtualização de recursos
Data center
Não
Não
Não
Parcial
Depende da organização
Não
Tabela 3.1: Comparativo entre public cloud e data center convencional (ARMBRUST et al.,
2010)
A Tabela 3.1 compara as vantagens de uma nuvem pública com um data center convencional. Neste comparativo é exaltada a flexibilidade oferecida pelo uso de nuvens, especialmente
pelo uso de recursos sob demanda.
3.4
PROVEDORES DE SERVIÇOS EM NUVEM
Computação em nuvem surgiu recentemente como um paradigma para gerenciar e entregar
serviços pela Internet. O aumento da computação em nuvem está rapidamente modificando o
cenário da tecnologia da informação (ZHANG; CHENG; BOUTABA, 2010). Existem uma diversidade de provedores de nuvem oferecendo uma quantidade variada de serviços que variam
desde análise de dados até recuperação de desastres (perda de arquivos) e o seu uso varia de
acordo com a necessidade do cliente. Serviços como Dropbox, um diretório de arquivos hospedado na nuvem, por exemplo, são utilizados por pesquisadores e estudantes para trabalharem
de forma colaborativa em tarefas e projetos (KAISERSWERTH et al., 2012).
Alguns dos provedores de serviços em cloud mais comuns estão listados a seguir:
• Amazon Web Services (http://aws.amazon.com/) - Fornece um conjunto de ferramentas,
bibliotecas e API’s próprias para executar qualquer tipo de tecnologia que execute sobre
uma infraestrutura particular;
• CloudBees (http://www.cloudbees.com) - Possui invólucro para desenvolvimento de aplicações Web em Java;
22
• Eucalyptus (http://www.eucalyptus.com) - É um software open source e gratuito para a
criação de nuvens privadas. Utiliza uma API compatível com o Amazon Web Services
possibilitando a migração entre esses serviços;
• Force.com (http://www.force.com/) - Especializada em aplicações do tipo CRM e voltadas para o gerenciamento de clientes, empresas, etc;
• Google App Engine (http://appengine.google.com) - Possui invólucro para desenvolvimento de aplicações Web em Java e Python;
• Heroku (http://www.heroku.com) - Possui ferramentas, bibliotecas e API’s próprias para
execução de aplicações desenvolvidas em Ruby on Rails;
• Microsoft Azure (http://www.windowsazure.com/) - Possui ferramentas, bibliotecas e
API’s próprias para executar aplicações desenvolvidas em .NET.
23
4
SERVIÇOS WEB SEMÂNTICOS
EM NUVEM
Serviços Web Semânticos possuem um ciclo de vida similar a um Serviço Web publicado
em servidores tradicionais. A Figura 4.1 apresenta os seis passos essenciais para garantir o
reúso, alta disponibilidade e execução de um Serviço Web.
Figura 4.1: Ciclo de vida de um Serviço Web (FERREIRA, 2010).
As etapas de publicação, descoberta, seleção e invocação foram discutidas na Seção 2.2. A
etapa de composição é responsável por interligar serviços em um fluxo de execução, na qual
a saída de uma operação serve como entrada para uma nova solicitação. São denominados
serviços compostos aqueles que possuem mais de um serviço envolvido na execução. Por fim,
a etapa de monitoramento é responsável por avaliar a execução da composição e atuar visando
aumentar a confiabilidade nas execuções.
Algumas pequenas adaptações são contudo necessárias para Serviços Web em nuvem. A
publicação, descoberta, composição e monitoramento de serviços possuem características especiais que devem ser consideradas.
Para publicar serviços na nuvem é necessário publicá-los no formato de PaaS. Algumas das
24
plataformas que disponibilizam esse tipo de serviço foram descritas na seção 3.4. Para publicar
um projeto de Serviços Web em diferentes provedores de nuvem é uma tarefa complexa, devido
a falta de padrões existentes. Um dos grandes desafios da publicação em nuvem se deve ao fato
de que não há um padrão que se torna totalmente dependente da PaaS utilizada. É importante
ressaltar que um serviço disponibilizado em um PaaS não necessariamente o torna um SaaS,
já que para que este seja um SaaS é necessário que este possua características intrínsecas da
computação em nuvem, como a utilização de recursos sob demanda (ALVES; CLARO, 2012).
Na etapa de descoberta de participantes de uma composição, a ferramenta que produz a
composição necessita ter conhecimento em que nuvem estão hospedadas as ontologias dos serviços disponíveis. Ter conhecimento de onde estão esses serviços se faz ainda mais importante
no processo de monitoramento e recuperação de serviços falhos.
Existem cenários nos quais os serviços conhecidos em uma nuvem não são capazes de realizar a requisição de um usuário, mas existem serviços conhecidos em uma segunda nuvem
que, ao serem interligados com os serviços da primeira são capazes de realizar tal tarefa. O
estudo de (ROSENBERG et al., 2009) sugere uma camada de software intermediária chamada
CaaS (Composition as a Service ), responsável por realizar tarefas de integração de serviços.
Atualmente, modelos de CaaS fornecem ao cliente um plug-in que provê recomendações aos
usuários e coleta feedbacks. Esse plug-in age em nome do usuário para detectar os seus requisitos e redirecioná-los para o serviço de CaaS (BLAKE; TAN; ROSENBERG, 2010).
Para o uso do CaaS não é necessário que serviços estejam publicados em um mesmo repositório. Num ambiente desses, seja a composição feita de maneira manual (o usuário seleciona
a ordem de composição que achar mais conveniente) ou automática (o plug-in seleciona a ordem da composição), devem ser levados em consideração em como realizar a composição mais
econômica, visando a utilização de menor número de acesso em nuvens (pois é custosa em
respeito à taxa a ser paga, tempo de execução e interconexão entre as nuvems) (ZOU et al.,
2010). No caso de falhas o raciocínio é o mesmo. É preferível que o serviço escolhido para ser
substituído esteja hospedado em uma nuvem já utilizada na composição.
4.1
PORTABILIDADE E INTEROPERABILIDADE ENTRE
NUVENS
A portabilidade é a capacidade de um sistema em ser utilizado em diferentes ambientes. Enquanto que a interoperabilidade é a capacidade que sistemas tem em interagir (PETCU, 2011).
A importância destes dois termos num ambiente de nuvem está ligada à necessidade dos clientes
25
em: (1) publicar em diferentes provedores sem a necessidade de realizar extensas modificações
no software desenvolvido e (2) interagir com serviços dispostos em nuvens diferentes fornecendo os recursos de ambas as nuvens simultaneamente.
O desafio para a portabilidade e interoperabilidade de Serviços Web Semânticos na nuvem
está ligado à falta de padrões entre as nuvens. Em pouco tempo existirão softwares legados
hospedados nas nuvens e migrar essa plataforma para outra nuvem implica muitas vezes em
rescrevê-lo muitas vezes por inteiro, o que impacta na economia da organização. Um plano
economicamente razoável seria construir a nova aplicação na nova nuvem e ao mesmo tempo
permitindo uma comunicação com a aplicação legada (BHUKYA REETA SONY A.L, 2012).
A Figura 4.2 representa um esquema de interoperabilidade.
Figura 4.2: Esquema de interoperabilidade entre nuvens (BHUKYA REETA SONY A.L, 2012).
A flexibilidade de se comunicar e expor os componentes na lógica de negócio presentes nos
Serviços Web fazem com que seja uma alternativa interessante para interoperabilidade entre
nuvens. Uma das formas de realizar essa comunicação é através do modelo SOAP (Simple Object Access Protocol ) ou através do modelo REST (REpresentational State Transfer ). Ambas
oferecem grande suporte à comunicação de aplicações em nuvens.
• SOAP.
SOAP é um protocolo para troca de mensagens formatadas em XML pela Internet. É fundamentalmente um modelo de comunicação que garante que a comunicação remetentedestinatário seja coerente. O desenho do SOAP é para prover um protocolo de comunicação independente e abstrato capaz de conectar dois ou mais negócios ou dois ou mais
sítios de negócios remotos. Isso significa que sistemas podem utilizar quaisquer combinação de software e hardware desde que suporte tecnologias para a Internet como .NET
e J2EE (NEWCOMER, 2002).
• REST
Originalmente introduzida como um estilo arquitetural para construir sistemas de hipermídia de larga escala, o modelo REST serve serve como modelo de comunicação entre
26
serviços utilizando o protocolo HTTP e seus verbos (GET, POST, PUT, DELETE) para
troca de mensagens. Possui quatro princípios tecnológicos: identificação de recursos através de uma URI ; interface uniforme, onde são utilizados os verbos HTTP; mensagens
auto-descritivas, conteúdo é separado do cabeçalho de forma que a resposta possa ter
vários formatos (HTML, XML, PDF, etc.); interações com manutenção de estado (stateful), os estados são transferidos entre requisições (mudanças de URI, cookies, formulários
escondidos) (PAUTASSO; ZIMMERMANN; LEYMANN, 2008).
Diversas técnicas estão sendo investigadas para alcançar a interoperabilidade na nuvem. No
cenário atual os Serviços Web são uma alternativa efetiva para alcançar tal objetivo (BHUKYA
REETA SONY A.L, 2012).
27
5
TRABALHOS RELACIONADOS
Apesar de ser uma área de pesquisa recente, interoperabilidade e portabilidade de Serviços
Web Semânticos publicados na nuvem já existem alguns trabalhos que estão relacionados à
proposta deste trabalho. Dos quais, dois foram destacados: VRESCo (HUMMER et al., 2011)
e Multi-cloud (ZOU et al., 2010).
5.1
VRESCO
VRESCo (Vienna Runtime Environment for Service-oriented Computing) (HUMMER et
al., 2011) é um framework desenvolvido em cima de cinco componentes: consulta, notificação,
publicação, gerenciamento e composição. O sistema é construído em C# e faz uso da Windows
Communication Foundation (WCF) para realizar a interação cliente-servidor. O protocolo de
mensagem utilizado é o SOAP.
O framework usa um modelo de metadados para descrever as funcionalidades dos Serviços
Web permitindo também a adição de précondições e póscondições que necessitam ser realizados
quando uma determinada funcionalidade é executada. A Figura 5.1 representa o mapeamento
entre o modelo de metadados de um serviço e o serviço propriamente dito. Serviços são mapeados em categorias (Category), a operação de um serviço é uma implementação concreta da
funcionalidade (Feature) e os parâmetros de uma operação são representados por conceitos de
dados (Data Concept). Em (ROSENBERG et al., 2009) são adicionados ao VRESCo a possibilidade de compor e executar Serviços Web disponibilizados na nuvem em forma de SaaS.
A linguagem para realizar esta composição é chamada de VRESCo Composition Language
(VCL).
Além disso, o framework provê uma linguagem de consulta própria, a VRESCo Querying
Language (VQL) . A VQL é baseada nas categorias, funcionalidades e parâmetros do mapeamento de modelos de metadados discutidos anteriormente e utiliza um conjunto de critérios
para buscar por serviços correspondentes.
28
Figura 5.1: Modelo de metadados para um serviço (HUMMER et al., 2011).
As vantagens de se usar o VRESCo estão ligadas ao ambiente unificado para especificação,
provisão e composição de serviços, deixando com que desenvolvedores de Serviços Web Semânticos trabalhem com apenas um framework para gerenciar o ciclo de vida dos serviços. Por
outro lado, (1) o fluxo de composição usado pela ferramenta necessita ser feito manualmente,
tornando custosa a inserção de novos serviços; (2) a dificuldade em automatizar o processo,
visto que a intervenção humana faz-se necessária para o processo de composição (inserção,
remoção e troca de serviços); (3) a linguagem VQL não utiliza descrição semântica, um dos
principais fatores para impedir a composição automática.
5.2
MULTI-CLOUD
O Multi-Cloud (ZOU et al., 2010) é um framework que, similar ao VRESCo, visa trabalhar
com a composição de Serviços Web em ambientes que utilizam múltiplas nuvens. As estratégias
utilizadas para minimizar a quantidade de provedores de nuvens para realizar uma determinada
tarefa é através do uso de análise combinatorial e planejamento de Inteligência Artificial.
O processo para composição dos serviços em nuvem se inicia com a requisição dos usuários,
definindo as descrições iniciais e o objetivo através de ontologias. Em seguida, é selecionada a
combinação de nuvens apropriada para alcançar o objetivo. As composições são então convertidas em um domínio e um problema onde finalmente um planejador de composições executa e
encontra uma plano de composição que satisfaça as requisições do usuário.
Para selecionar a combinação de nuvens são propostos três diferentes métodos: (1) combinação de todas as nuvens, (2) combinação de nuvem base e (3) combinação inteligente de
29
nuvens. No primeiro caso, todas as nuvens são dispostas como entradas para realizar uma composição. Na combinação de nuvem base, são reduzidos os números de nuvens envolvidas ao
se usar combinação, e por fim, o método de combinação inteligente que ao mesmo tempo que
otimiza a quantidade de nuvens envolvidas na combinação, também reduz a complexidade para
alcançar esta solução.
Essa ferramenta tem algumas vantagens sobre o VRESCo, como a composição de forma
automática e eficiente e uso de semântica; uso do OWL-S para especificação do serviço, que
é uma linguagem mais comum para descrição de serviços. O protótipo contudo ainda não
está disponível para uso ou teste de terceiros, não tem integração com outros ambientes de
desenvolvimento e também não permitem ao usuário selecionar serviços de forma manual, caso
seja do interesse deste.
Diferentemente deste trabalho, os autores em (HUMMER et al., 2011) desenvolveram o
ambiente em C#, tornando necessária a implantação da nuvem em uma máquina Windows,
deixando o usuário limitado em termos de escolha de tecnologia. Isso se deve ao fato de que
o ambiente VRESCo é um ambiente completo com linguagens próprias para realizar diferentes
tarefas, mas isso pode dificultar a adoção, pois para migrar para outro sistema implicaria ter
que implementar todo o sistema. O presente trabalho foi desenvolvido como um plug-in para a
IDE Eclipse permitindo que o usuário utilize o software em qualquer sistema em que o Eclipse
possa ser instalado. Além disso, o OWL-S Composer utiliza as nuvens disponíveis no mercado
para publicar serviços desenvolvidos em Java, permitindo que projetos de Serviços Web sejam
publicados em uma gama maior de nuvens.
Já a implementação do Multi-cloud (ZOU et al., 2010) utiliza o OWL-S para realizar as
composições, porém apesar de trabalhar com Serviços Web Semânticos em nuvem ela não
realiza tarefas de publicação de serviços e nem é integrada a outras ferramentas, ambas soluções
implementadas neste trabalho.
A contribuição realizada neste trabalho foi feita sobre a ferramenta OWL-S Composer, pois
esta executa em um ambiente robusto que auxilia a lidar com o ciclo de vida de uma composição
de Serviços Web Semânticos em uma nuvem. Ela é integrada com o Eclipse, o que permite
maior comodidade para desenvolver e publicar serviços em apenas um ambiente. O objetivo
principal deste trabalho é permitir ao OWL-S Composer atuar de maneira interoperável entre
provedores de nuvem. O OWL-S Composer, seus componentes e as propostas de evolução estão
descritos no capítulo 6.
30
6
INTEROPERABILIDADE PARA O
OWL-S COMPOSER
Esse capítulo introduz a ferramenta OWL-S Composer, evidenciando os pontos mais relevantes para o desenvolvimento da versão 4.0 da ferramenta. O objetivo principal desta versão é
prover ao usuário maior facilidade para publicar Serviços Web Semânticos em nuvens distintas
através de um ambiente unificado.
6.1
HISTÓRICO DO OWL-S COMPOSER
O OWL-S Composer é um plug-in para a IDE Eclipse, cujo objetivo é prover ferramentas
para a produção, busca, publicação e monitoramento de Serviços Web Semânticos. Criado em
2008 pelo grupo FORMAS (Formalismos e Aplicações Semânticas) da Universidade Federal
da Bahia, o plugin continua em desenvolvimento visando melhorar a experiência na criação e
gerenciamento de Serviços Web Semânticos. Três versões principais foram lançadas do OWL-S
Composer, cada uma com um conjunto de funcionalidades. A Figura 6.1 apresenta a evolução
do plug-in dividido em versões com os respectivos módulos.
Figura 6.1: Evolução da arquitetura do OWL-S Composer
A versão 1.0 do OWL-S Composer (FONSECA; CLARO; LOPES, 2009) foi desenvolvida
31
com o objetivo de prover ao usuário uma maneira de realizar composições de Serviços Web
Semânticos de forma gráfica utilizando a linguagem para composição de serviços OWL-S. O
fato de ser desenvolvido como um plug-in para a plataforma Eclipse permitiu a integração com
outras tarefas e ferramentas relacionadas à criação e manutenção de serviços.
O OWL-S Composer 2.0 (SENA, 2009) é o produto da incorporação da ferramenta OWL-S
Discovery (AMORIM, 2009) no Eclipse, ferramenta esta capaz de realizar descoberta semântica
de Serviços Web atômicos. É agregada a essa versão do OWL-S Composer a capacidade de descoberta de Serviços Web similarmente semânticos (inclusive composições) àqueles modelados
de forma manual.
Agregar mecanismos de auto-cura foi o objetivo principal da versão 3.0 do OWL-S Composer (FERREIRA, 2010). O suporte a execução de Serviços Web Semânticos exigiu um ambiente
que permitisse uma maior confiabilidade nas suas composições. Aliado a isso, a versão 3.1 recebeu uma atualização para permitir que Serviços Web Semânticos tivessem o seu ciclo de vida
executado em nuvem (ALVES, 2011).
A Figura 6.2 ilustra um exemplo de composição sendo modelada através da interface do
OWL-S Composer.
Figura 6.2: Exemplo de composição feita pela interface do OWL-S Composer
32
6.2
CONTRIBUIÇÕES
Para a elaboração deste trabalho foram traçadas duas linhas de contribuição. A primeira
se refere a atualização do plug-in OWL-S Composer para a versão 4.0 com a adição de uma
interface genérica que permita a usuários a publicar Serviços Web Semânticos em um provedor
de nuvem de modo mais simples. A segunda se refere à contribuição voltada para a validação
da ferramenta desenvolvida. Para tal, cursos foram ministrados para públicos distintos com o
objetivo de avaliar a manipulação desta ferramenta para o ambiente em nuvem.
A versão 4.0 do OWL-S Composer permite a publicação em dois provedores distintos de
nuvem (Amazon Web Services e Eucalyptus) além de disponibilizar um ambiente para o acoplamento de novos provedores. Detalhes sobre a implementação estão descritos na Seção 6.4.
O OWL-S Composer foi atualizado para executar numa versão mais recente do Eclipse, o
Eclipse Helios (3.6.2). Como o plug-in é uma ferramenta open source o seu código fonte foi
movido para a plataforma GitHub1 que disponibiliza hospedagem do código assim como espaço
para colaboração de outros desenvolvedores à plataforma.
Devido a algumas alterações feitas na versão 3.1 do OWL-S Composer surgiram algumas
inconsistências no sistema que foram corrigidos para a versão 4.0. Além disso, alguns estudantes de mestrado que assistiram ao curso sobre o plug-in colaboraram na correção de alguns bugs
presentes.
6.3
AMBIENTE
Dois conjuntos de bibliotecas foram fundamentais para o desenvolvimento do plug-in: bibliotecas externas independentes do Eclipse (JAX-SA, OWL-S API, OWL-S Discovery) e o
Eclipse Modeling Framework (GMF, GEF, EMF, JET). Esse módulos são vistos na Figura 6.1.
Para que o OWL-S Composer funcione corretamente é aconselhável utilizar as mesmas versões
explicitadas.
• Eclipse Modeling Framework (EMF) (EMF, 2009)
Biblioteca capaz de gerar código para construir ferramentas a partir de um modelo de
dados. Isso implica que o plugin é capaz de gerar código a partir de um diagrama e
vice-versa. No caso do OWL-S Composer, o OWL-S é utilizado para gerar o documento
OWL-S (em sua versão 1.1) a partir do diagrama de composição. A versão do EMF
1 https://github.com/FORMAS/OWL-S-Composer
33
utilizada é a 2.5.0.
• Graphical Editing Framework (GEF) (GEF, 2013)
O GEF é um framework que provê ferramentas para criar editores gráficos no Eclipse.
Possui três componentes para a realização das tarefas. Draw2d, para renderizar os gráficos; GEF (MVC), biblioteca fornecida para criação do editor gráfico através da arquitetura Model View Controller (MVC) que facilita tanto na integração dos modelos gráficos
como na legibilidade e manutenabilidade do código; Zest, é um conjunto de ferramentas baseados em Draw2d que implementam a camada de visualização (View) do GEF. O
GEF oferece as ferramentas necessárias para que o OWL-S Composer defina composições
através de elementos gráficos. A versão utilizada do GEF é a 3.5.1.
• Graphical Modeling Framework (GMF) (GMF, 2010)
Componente que integra EMF e GEF, o GMF permite que o mapeamento entre diagrama
e código seja feito de forma visual. O OWL-S Composer utiliza o GMF para mapear a
modelagem da composição com os elementos do documento OWL-S. A versão utilizada
do GMF é a 1.2.0.
• Java Emitter Templates (JET) (JET, 2007)
Para aplicações que tem seu desenvolvimento baseado em modelos (Model Driven Development) o JET é comumente utilizado como um gerador de código. Através de templates
em Java Server Pages (JSP) o OWL-S Composer gera código Java através do diagrama de
composições. A versão utilizada do JET é a 1.1.0.
A versão do Eclipse utilizada para se realizar a implementação do plug-in foi o Eclipse
Helios 3.6.
Como ferramentas independentes do Eclipse estão o (1) JAX-SA (BABIK, 2013), que realiza anotações semânticas e permite a geração correspondente de documentos WSDL para
OWL-S, conversão opcional no OWL-S Composer, já que este pode importar OWL-S existentes
para realizar a composição de serviços; (2) OWLS-API (MINDSWAP, 2007) é uma biblioteca
que fornece o necessário para manejar documentos OWL-S, como leitura, escrita e execução de
serviços compostos.
34
6.4
6.4.1
PROJETO ESTRUTURAL
NUVENS UTILIZADAS
Para a criação da interface unificada de serviços em nuvem foi necessário selecionar uma
amostra de provedores de nuvem em que o OWL-S Composer pudesse interagir. Foram selecionados ao todo dois provedores: (1) Amazon Web Services (AWS) (AWS, 2013) e (2) Eucalyptus
(EUCALYPTUS, 2013).
O Amazon Web Services foi escolhido como um dos provedores de nuvem a serem implementados pelo seu amplo uso no mercado, além de ter uma facilidade para se publicar Serviços
Web através de um plug-in para Eclipse. Enquanto isso, o Eucalyptus foi escolhido por ser
um provedor de nuvem open source utilizado tanto por empresas quanto por instituições acadêmicas. Além disso, o Eucalyptus é parcialmente compatível com o Amazon Web Services,
implementando suas funcionalidades de forma similar à API da Amazon para facilitar a migração de aplicaçãoes entre essas nuvens.
6.4.2
ARQUITETURA DO OWL-S COMPOSER 4.0
A Figura 6.3 apresenta a arquitetura do OWL-S Composer 4.0. O retângulo representado
pelo círculo de número 1 representa a arquitetura da versão 3.1 do plug-in e suas funcionalidades. O que é acrescido na versão 4.0 é a interface para lidar com múltiplos provedores de
nuvem chamada Unified Cloud Service e os Cloud Services que são implementações da interface com as particularidades de cada nuvem. Conforme informado na Seção 6.4.1, apenas dois
Cloud Services foram implementados na versão 4.0, contudo, a implementação de novos Cloud
Services se torna uma tarefa mais simples, visto que será necessário implementar sobre a interface Unified Cloud Service que fornece um “mapa” das funções necessárias para se publicar na
nuvem.
6.5
IMPLEMENTAÇÃO
Para permitir que o OWL-S Composer auxilie na publicação de Serviços Web Semânticos
na nuvem é necessário conhecer as peculiaridades da nuvem ao se publicar um serviço. Para
a Amazon e Eucalyptus são necessários a criação/edição de três arquivos e uma biblioteca,
descritos a seguir.
• A biblioteca JAX-WS
35
Figura 6.3: Arquitetura do OWL-S Composer 4.0
Java API for XML Web Services (JAX-WS) (GLASSFISH, 2013) é uma API em Java
para criação de Serviços Web. O uso da biblioteca se deve ao protocolo de comunicação escolhido para os serviços que é o SOAP que por sua vez é baseado no XML. A
partir de anotações feitas nas classes e métodos criados a API é capaz de gerar o arquivo de descrições do Serviço Web (WSDL). Essa biblioteca deve se situar na pasta
WebContent/WEB-INF/lib do projeto.
• web.xml
O arquivo web.xml é um arquivo que descreve aplicações para publicação. Por padrão
em um projeto para publicação de Serviços Web no Eclipse, esse arquivo fica hospedado
na pasta WebContent/WEB-INF. Ele indica quais os Serviços Web disponíveis através da
tag <servlet> e os mapeia em urls através da tag <servlet-mapping>. A listagem 6.1
é um exemplo de arquivo web.xml para uma suposta aplicação que disponibiliza Serviços
Web que informam a temperatura.
Para que o JAX-WS delegue para onde as futuras requisições devem apontar é necessário
que um ouvinte (listener) seja registrado na aplicação. É o caso do WSServletContextListener que irá criar um objeto que irá delegar as rotas definidas no arquivo sun-jaxws.xml
que será abordado no item seguinte.
<?xml version="1.0" encoding="UTF-8"?>
<web−app>
<display−name>AWSWeatherSOAPServer</display−name>
<welcome−file−list>
<welcome−file>index.jsp</welcome−file>
</welcome−file−list>
<listener>
36
<listener−class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</
listener−class>
</listener>
<servlet>
<description>Temperature</description>
<display−name>WeatherInfo</display−name>
<servlet−name>WeatherInfo</servlet−name>
<servlet−class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet−class>
<load−on−startup>1</load−on−startup>
</servlet>
<servlet−mapping>
<servlet−name>WeatherInfo</servlet−name>
<url−pattern>/WeatherInfoService</url−pattern>
</servlet−mapping>
</web−app>
Listagem 6.1: Exemplo de arquivo web.xml
• sun-jaxws.xml
Hospedado na mesma pasta que o web.xml, o sun-jaxws.xml é um arquivo que indica
como acessar e qual é a implementação de um determinado Serviço Web. Essas informações são utilizadas pelo listener para delegar as requisições ao Serviço Web correto.
Cada Serviço Web é descrito através de um endpoint informando características como
nome (name), implementação (implementation) e padrão da URL (url-pattern). É importante ressaltar que, para que a aplicação funcione corretamente o atributo name do sunjaxws.xml seja igual à tag servlet-name do web.xml assim como o atributo url-pattern do
sun-jaxws.xml seja similar à tag url-pattern do web.xml.
A listagem 6.2 é um exemplo de arquivo sun-jaxws.xml para uma suposta aplicação que
informa o clima.
<?xml version="1.0" encoding="UTF-8"?>
<endpoints xmlns='http://java.sun.com/xml/ns/jax-ws/ri/runtime' version='
2.0'>
<endpoint name='WeatherInfo' implementation='com.example.WeatherInfo'
url−pattern='/WeatherInfoService' />
</endpoints>
Listagem 6.2: Exemplo de arquivo sun-jaxws.xml
37
• Awscredentials.properties
Este arquivo fica hospedado ao lado da pasta src do projeto. Compõe as duas chaves de
acesso necessárias para publicar na nuvem denotadas por accessKey e secretKey. Essas
chaves provem a autenticação do usuário ao executar a ação de publicação.
Como o plug-in da Amazon para Eclipse realiza uma quantidade extensa de tarefas para
publicar projetos (criação de instância, de máquina virtual e configuração básica da instância),
optou-se realizar uma etapa de pré-publicação do projeto. Assim, o cliente terá a possibilidade
de verificar como o projeto se comporta antes de ser publicado em nuvem.
Para implementar a versão 4.0 do OWL-S Composer não foi necessário realizar nenhuma
modificação na versão anterior do plug-in. Apenas se estendeu o pacote owls.cloud com o conjunto de funcionalidades necessárias para realizar a pré-publicação. Foram criadas duas funcionalidades AWSCloudService e EucalyptusCloudService que implementam a interface UnifiedCloudService.
A listagem 6.3 mostra a implementação da classe AWSCloudService para a funcão prepareToPublish(). Essa função prepara a aplicação para ser publicada na Amazon, ou seja, o conjunto
de características exigidas pela Amazon para publicar um projeto. A rotina para a publicação
no Eucalyptus é a mesma, já que são provedores compatíveis.
public void prepareToPublish() {
importJaxWs();
updateCredentials();
updateWebXml();
updateJaxWsXml();
}
Listagem 6.3: Sequência de tarefas necessárias para preparar um projeto Amazon para
publicação
38
7
AVALIAÇÕES E PROVA DE
CONCEITO
Esse capítulo apresenta os três principais experimentos realizados para validar o presente
trabalho, o OWL-S Composer 4.0 e a análise dos respectivos resultados alcançados.
7.1
1a ESTUDO DE CASO: AVALIAÇÃO E EXPLORAÇÃO
DO OWL-S COMPOSER PARA MESTRADO E GRADUAÇÃO
Para aproximar os estudantes da Universidade Federal da Bahia (UFBA) com o OWL-S
Composer foi realizado um trabalho de divulgação do plug-in através de apresentações1 ministrados para alunos de mestrado em Ciência da Computação e bacharelado em Sistemas de
Informação.
Estas apresentações tinham como objetivos introduzir o plug-in, suas funcionalidades e
uso, convidar os estudantes a oferecem modificações e avaliar a ferramenta na perspectiva do
usuário. Foram realizados no total dois cursos de duas horas cada, expondo o OWL-S Composer
e suas funcionalidades para os estudantes num tutorial passo a passo. O caso utilizado foi uma
aplicação com dois Serviços Web: um para conversão de Celsius para Kelvin e outra de Kelvin
para Fahrenheit. Ao final os alunos deveriam produzir uma composição Celsius para Fahrenheit
utilizando as funcionalidades oferecidas pelo OWL-S Composer.
Ao final de cada apresentação foi realizada uma avaliação2 sobre as funcionalidades presentes no plug-in, a satisfação dos usuários e a importância de certas características a serem
implementadas para a cloud. Através de algumas técnicas da abordagem Goal Question Metrics (GQM) (BASILI; CALDIERA; ROMBACH, 1994), foi possível determinar quais são as
funcionalidades mais importantes para o sucesso da ferramenta. Além disso, com os resultados
1 http://homes.dcc.ufba.br/
dclaro/download/mate15/OWL-S%20Composer.pdf
2 https://docs.google.com/forms/d/1Z-rQVd4KAKwcmiz1WdUw-_W-9YUeTmbZDgCWO2_Q6D8/viewform
39
da avaliação é possível traçar objetivos e indicadores para as próximas iterações da ferramenta.
O questionário foi dividido em quatro partes: (1) Autoavaliação sobre os conhecimentos
em Serviços Web, (2) Avaliação do OWL-S Composer, (3) Relevância das funcionalidades e
(4) Importância de funcionalidades na nuvem. No primeiro ponto foi feito apenas um questionamento sobre o conhecimento do avaliador sobre Serviços Web e composição de serviços.
Para definir quais são os requisitos mínimos para uma ferramenta de composição de Serviços
Web foram utilizados os critérios descritos em (CHAFLE et al., 2007), (FONSECA; CLARO;
LOPES, 2009) e (SENA et al., 2010). A seguinte lista descreve os critérios a serem avaliados:
1. Funcionalidade de um Serviço Web *: O ambiente onde o plug-in está instalado deve
possuir a funcionalidade de criar um Serviço Web ou deve possuir plug-ins que realizem
esta tarefa;
2. Funcionalidade da composição de Serviços Web: O ambiente deve ser permitir lidar
com a composição de serviços web desde a sua criação até a execução desta composição;
3. Usabilidade: A interface deve possuir botões e menus que facilitam o desenvolvimento
da composição de serviços;
4. Integração: A ferramenta deve permitir a criação de composições de Serviços Web em
um único ambiente integrado sem a necessidade de recorrer a diversos recursos e ambientes para se ter uma composição de Serviços Web;
5. Legibilidade: Os arquivos *.OWL-S gerados, tanto na conversão do WSDL como na
geração a partir do diagrama de composição devem ser legíveis e reutilizáveis pela ferramenta sem necessidade de manipulação por conta do usuário;
6. Grau de Similaridade: A ferramenta deve ser capaz de descobrir serviços baseados no
grau de similaridade semântica;
7. Análise Global *: Em um aspecto geral, o plug-in auxilia usuários a manejarem composições de Serviços Web.
Os critérios em asterisco (*) se referem a pontos considerados apenas no item 2 da avaliação
(Avaliação do OWL-S Composer). Na avaliação sobre a importância de funcionalidades para a
composição de Serviços Web em nuvem foram considerados os seguintes itens:
1. Portabilidade: O plug-in deve possuir uma funcionalidade que permita a publicação de
Serviços Web em diferentes provedores de nuvem (Google, Amazon, Eucalyptus);
40
2. Interoperabilidade: O plug-in deve permitir que Serviços Web se comuniquem de modo
interoperável, ou seja, independente de qual provedor de nuvem estejam hospedados;
3. Descoberta de serviços: O plug-in deve permitir a descoberta de Serviços Web similares
em nuvens distintas;
4. Usabilidade: O plug-in deve permitir a publicação, composição e descoberta de serviços
em nuvem de uma maneira fácil e transparente para o desenvolvedor;
7.1.1
RESULTADOS
Ao final do curso todos os alunos conseguiram realizar a composição, apesar de que ainda
existiam alguns bugs que interviram no avanço de alguns alunos que tiveram que ser auxiliados. Após essa aula, alguns alunos de mestrado contribuiram com a correção de alguns erros
existentes na ferramenta, correções estas agregadas na versão 4.0 do OWL-S Composer.
O relatório completo da avaliação realizada pelos estudantes de mestrado e graduação segue
nos Anexos I e Anexos II deste trabalho. No entanto, a análise destes resultados é feita a seguir.
Vale lembrar que no momento em que o primeiro experimento foi realizado as funcionalidades
de publicação em nuvem do OWL-S Composer 4.0 não estavam prontas e portanto os estudantes
não utilizaram esta parte da plataforma.
Observou-se que 54% da turma de mestrado possuía algum conhecimento em composição
de serviços e 7% já conhecia o OWL-S Composer enquanto que na turma de graduação, nenhum
aluno tinha quaisquer tipo de conhecimento sobre composição de serviços ou já tinha ouvido
falar sobre o plug-in. 83% da turma de graduação tinha conhecimento sobre Serviços Web.
O critério considerado mais importante por ambas as turmas foi a interface, ponto que o
plug-in deixou a desejar devido a alguns erros que são apresentados sem qualquer mensagem
de erro, dificultando ao usuário a possibilidade de realizar correções. Essas mensagens de erro
foram atualizadas por alguns estudantes de mestrado, que agregaram mensagens às notificações
do OWL-S Composer. Nas duas turmas, 60% considerou que a interface é um item importante
e 28% como muito importante, enquanto que 56% dos avaliadores consideraram a ferramenta
como fraca no critério interface.
Em características como funcionalidade de composição de serviços e integração a ferramenta superou as expectativas dos alunos. Isso se deve ao fato de que o OWL-S Composer
está embutido no Eclipse e utiliza os recursos que a IDE fornece para o desenvolvimento de
plug-ins, facilitando não apenas o desenvolvimento, mas o uso por parte dos usuários.
41
De um ponto de viste geral o software teve uma boa aceitação tanto por parte dos alunos de
mestrado quanto por parte dos alunos de graduação. 85% dos alunos de mestrado consideraram
o OWL-S Composer como uma boa ferramenta para a composição de Serviços Web, enquanto
que na turma de graduação 45% o consideraram como muito boa e outros 45% como boa.
Na perspectiva cloud, os itens que tiveram mais média foram portabilidade e usabilidade.
Na escala de 0 a 4 esses itens tiveram média de 3.53 e 3.75 e na turma de graduação 3.44 e 3.44.
A inclusão da portabilidade na nuvem já é o objetivo do presente trabalho, mas a melhoria da
usabilidade da ferramenta pode ser tema de um trabalho futuro.
7.2
PROVA DE CONCEITO: PUBLICAÇÃO DE UM PROJETO NA AMAZON E NO EUCALYPTUS
Para fazer a publicação na Amazon e no Eucalyptus é necessário utilizar o plug-in da Amazon para Eclipse. Este plug-in oferece um conjunto de serviços para gerenciar uma nuvem,
entre eles a publicação de projetos em uma instância da Amazon. É possível configurar esse
plug-in para publicar no Eucalyptus também. Para fazer isso é necessário adicionar o conteúdo da listagem 7.1 no arquivo region.xml encontrado no workspace do Eclipse, no diretório
./metadata/.plugins/com.amazonaws.eclipse.core.
<region>
<displayname>EucalyptusCC</displayname>
<systemname>ecc−1</systemname>
<flag−icon>flags/usa.png</flag−icon>
<min−toolkit−version>1.1.0.0</min−toolkit−version>
<services>
<service name="S3">http://communitycloud.eucalyptus.com:8773/services/Walrus/</service>
<service name="IAM">http://communitycloud.eucalyptus.com:8773/services/Euare/</service>
<service name="EC2">http://communitycloud.eucalyptus.com:8773/services/Eucalyptus/</
service>
<service name="AutoScaling">http://communitycloud.eucalyptus.com:8773/services/
AutoScaling/</service>
<service name="CloudWatch">http://communitycloud.eucalyptus.com:8773/services/
CloudWatch/</service>
</services>
</region>
Listagem 7.1: Exemplo de arquivo web.xml
42
A etapa de pré-publicação do OWL-S Composer se resume em três etapas: (1) Seleção do
projeto, (2) Seleção das nuvens e pacotes e (3) Inserção das credenciais. A Figura 7.1 mostra
como inicializar a tarefa de pré-publicação.
Figura 7.1: Seleção do projeto a ser pré-publicado
A Figura 7.2 mostra o wizard de pré-publicação. Nesta tela são escolhidas as nuvens onde
o projeto é publicado e também os pacotes onde estão os Serviços Web. O Cloud Service irá
iterar sobre os arquivos *.java presentes nesse pacote e irá atualizar (ou criar, caso não existam)
os arquivos web.xml e sun-jaxws.xml abordados na Seção 6.5 como requisitos necessários para
publicação na nuvem.
A janela para inserção de credenciais para o Eucalytpus é vista na Figura 7.3. As credenciais
de um projeto ficam guardadas ao lado da pasta src e são usadas tanto pela Amazon como pelo
Eucalyptus para autenticar o usuário e permitir a publicação do projeto em uma instância.
Por fim, após gerados os arquivos, é necessário selecionar o projeto e invocar o plugin da
Amazon para o Eclipse e selecionar a função Deploy to AWS Elastic Beanstalk, demonstrado
pela Figura 7.4. Essa mesma função é utilizada para realizar a publicação no Eucalyptus. Uma
janela será aberta para configurar o servidor e baseado na chave ativa em suas credenciais é que
será apresentado os serviços disponíveis da Amazon ou do Eucalytpus. Ao final da publicação
é necessário executar o projeto no servidor escolhido e o navegador embutido no Eclipse irá
mostrar a página com os Serviços Web.
43
Figura 7.2: Seleção das nuvens e pacotes
Figura 7.3: Inserção de credenciais
Figura 7.4: Publicando com o plugin da Amazon para Eclipse
44
A Figura 7.5 ilustra a página de descrição do serviço após ser publicado na Amazon.
Figura 7.5: Página do serviço desenvolvido publicado na amazon
7.3
2o ESTUDO DE CASO: AVALIAÇÃO E TESTES REALIZADOS PELA EMPRESA JÚNIOR DE INFORMÁTICA DA UFBA
Com o objetivo de avaliar se a versão 4.0 do OWL-S Composer reduz o tempo utilizado
por desenvolvedores de Serviços Web, uma outra apresentação, com moldes similares ao primeiro experimento foi realizada. Nesta apresentação contudo, a ferramenta já estava completa
e corrigida.
Este curso teve uma quantidade menor de participantes comparada ao primeiro experimento. Seis integrantes da empresa júnior participaram com o objetivo de investigar se a etapa
de pré-publicação diminui o tempo geral para a publicação de serviços na cloud. A partir desse
objetivo as perguntas foram realizadas: “Qual o tempo para a publicação de aplicações?” e
“Quão satisfatório é esse tempo de publicação?”. Dessas perguntas são extraídos alguns indicadores como o tempo total de publicação (tempo atual - tempo antigo) e o índice de satisfação
com o tempo de desenvolvimento.
O projeto foi desenvolvido em duas etapas: Publicar na Amazon com o OWL-S Composer
e sem o OWL-S Composer. A ordem escolhida para realizar o experimento se deve ao fato
45
que o projeto desenvolvidos pelos integrantes da empresa júnior são os mesmos, usando apenas
técnicas diferentes. Isso significa que ao desenvolver sem o uso do plug-in eles terão a vantagem
de conhecer o algoritmo para desenvolver a aplicação, mas os resultados obtidos mostraram que
independente disso, o OWL-S Composer se mostrou mais eficiente.
A aplicação construída para esse projeto foi o conversor de temperatura. Dois serviços deveriam ser implementados: Kelvin para Fahrenheit e Celsius para Kelvin. Além disso, foi aplicado
o mesmo questionário do primeiro experimento para avaliar a ferramenta OWL-S Composer.
7.3.1
RESULTADOS
O Anexo III apresenta o relatório com os resultados do questionário e da avaliação. As
conclusões retiradas do experimentos estão expostas a seguir.
O tempo médio gasto pelos integrantes da empresa júnior para desenvolver e publicar o
software conversor de temperatura sem o OWL-S Composer é de 19 minutos e 38 segundos,
enquanto que a mesma aplicação utilizando o plug-in tem um tempo médio de 13 minutos e
18 segundos. A melhoria de aproximadamente seis minutos, uma economia média de 32%, se
deve ao tempo gasto com as tarefas de configuração da aplicação. Esse valor tende a aumentar
à medida que a quantidade de serviços cresce. Um outro fator que reduziu o tempo total para
publicação se deve a injeção de erros por parte do usuário. Ao utilizar a ferramenta esses erros
são eliminados.
Com relação ao índice de satisfação, 67% dos avaliadores se mostraram muito satisfeitos
com a economia de tempo para a publicação dos projetos.
46
8
CONCLUSÃO
O uso de Serviços Web Semânticos em nuvem ainda é uma área de pesquisa recente e
ainda falta estudos e ferramentas para o desenvolvimento desta. Prover ferramentas para realizar tarefas que lidam com o ciclo de vida de um Serviço Web Semântico são importantes por
eliminarem etapas que podem ser automatizadas, acelerando todo o processo. Um dos esforços
para se lidar com serviços em nuvem é manter um ambiente que seja interoperável, ou seja, que
Serviços Web publicados em nuvens diferentes tenham capacidade de se comunicar através de
composições.
Este trabalho propôs uma nova versão do OWL-S Composer capaz de lidar com publicação
de serviços em nuvens distintas com quantidade mínima de configuração, deixando tudo a cargo
de uma interface que liga cliente e provedor. A versão 4.0 do OWL-S Composer permite que
Serviços Web Semânticos sejam publicados nas nuvens da Amazon e Eucalyptus de forma conveniente. A versão corrente do plug-in assim como as anteriorem estão disponíveis na página
do SourceForge1 e o código fonte está hospedado no GitHub2 .
8.1
DIFICULDADES ENCONTRADAS
Um dos desafios para a realização deste trabalho foi com a tecnologia utilizada, especialmente com os módulos externos comentados no Capítulo 5. A falta de suporte e documentação
para uso de tais tecnologias dificultou o desenvolvimento. O OWL-S Composer também utiliza
internamente alguns plug-ins antigos que necessitam ser atualizados, assim como a versão do
Eclipse utilizada. No momento em que este trabalho foi escrito a versão mais atual do Eclipse
é a 4.2.2 de 2013, enquanto o plug-in utiliza a 3.5.1 de 2010.
1 https://sourceforge.net/projects/owl-scomposer/
2 https://github.com/FORMAS/OWL-S-Composer
47
8.2
TRABALHOS FUTUROS
Com a publicação de Serviços Web Semânticos em nuvem, este trabalho possibilita um
conjunto de novas funcionalidades para o OWL-S Composer 4.0, listados à seguir:
• A composição de Serviços Web Semânticos em nuvens distintas, isso implica na busca e
seleção de serviços em nuvens distintas;
• A descoberta de Serviços Web Semânticos similares em nuvem, facilitando a etapa de
seleção;
• Permitir que composições automáticas sejam feitas em nuvens distintas;
• Aprimorar o mecanismo de busca utilizado, a fim de considerar Pré-Condições e Efeitos;
• A atualização, revisão da arquitetura e documentação das ferramentas utilizadas no OWLS Composer, visando facilitar o trabalho de desenvolvimento de futuras funcionalidades
no plug-in.
48
REFERÊNCIAS BIBLIOGRÁFICAS
ALVES, F.; CLARO, D. B. Semantic web service composition on cloud (composição de
serviços web semânticos em nuvem). In: Minicursos da XIV Escola Regional de Informática
Bahia, Alagoas e Sergipe. Juazeiro/BA: UNIVASF, 2012. cap. 1, p. 97–128.
ALVES, F. de O. Uma composição de serviços em nuvem tolerante a falhas através do owl-s
composer. Trabalho de Conclusão de Curso (Graduação) - Universidade Federal da Bahia:
Orientadora: Daniela Claro. 2011.
AMORIM, R. Um algoritmo hibrido para descoberta de serviços web semânticos. Trabalho
de Conclusão de Curso (Graduação) - Universidade Federal da Bahia: Orientadora: Daniela
Claro. 2009.
ARMBRUST, M.; FOX, A.; GRIFFITH, R.; JOSEPH, A. D.; KATZ, R.; KONWINSKI, A.;
LEE, G.; PATTERSON, D.; RABKIN, A.; STOICA, I.; ZAHARIA, M. A view of cloud
computing. Commun. ACM, ACM, New York, NY, USA, v. 53, n. 4, p. 50–58, Abril 2010.
ISSN 0001-0782. Disponível em: <http://doi.acm.org/10.1145/1721654.1721672>.
AWS. Amazon Web Services. 2013. Disponível em: <http://aws.amazon.com/>.
BABIK, M. JAX-SA. Março 2013. Disponível em: <http://sourceforge.net/projects/jax-sa/>.
BASILI, V. R.; CALDIERA, G.; ROMBACH, H. D. The goal question metric approach.
Encyclopedia of software engineering, v. 2, n. 1994, p. 528–532, 1994.
BHUKYA REETA SONY A.L, G. M. D. P. On web services based cloud interoperability.
International Journal of Computer Science Issues, IJCSI, v. 9, n. 1, p. 232–236, Setembro
2012. ISSN 1694-0814. Disponível em: <http://doi.acm.org/10.1145/1721654.1721672>.
BLAKE, M.; TAN, W.; ROSENBERG, F. Composition as a service [web-scale workflow].
Internet Computing, IEEE, v. 14, n. 1, p. 78–82, 2010. ISSN 1089-7801.
CHAFLE, G.; DAS, G.; DASGUPTA, K.; KUMAR, A.; MITTAL, S.; MUKHERJEA, S.;
SRIVASTAVA, B. An integrated development enviroment for web service composition. IEEE
International Conference on Web Services, p. 839–847, 2007.
CHEN, Y.; PAXSON, V.; KATZ, R. H. What’s New About Cloud Computing Security? [S.l.],
Agosto 2010.
CLARO, D. B.; ALBERS, P.; HAO, J.-K. Approaches of web services composition.
International Conference on Enterprise Information Systems, p. 208–213, Maio 2005.
EMF. Eclipse Modeling Framework. Junho 2009. Disponível em:
<http://www.eclipse.org/modeling/emf/>.
49
EUCALYPTUS. Eucalyptus. 2013. Disponível em: <http://www.eucalyptus.com/>.
FERREIRA, M. Integração de mecanismo de self-healing ao owl-s composer. Trabalho de
Conclusão de Curso (Graduação) - Universidade Federal da Bahia: Orientadora: Daniela
Claro. 2010.
FONSECA, A. de A.; CLARO, D. B.; LOPES, D. C. P. Gerenciando o desenvolvimento de
uma composição de serviços web semânticos através do owl-s composer. In: Proceedings of
the 5th Brazilian Symposium of Information Systems (SBSI2009). [S.l.: s.n.], 2009.
FOUNDATION, T. E. Eclipse. 2013. Último acesso em 25 de junho de 2013. Disponível em:
<http://www.eclipse.org/>.
GEF. Graphical Editing Framework. Março 2013. Disponível em:
<http://www.eclipse.org/gef/>.
GLASSFISH. JAX-WS. 2013. Disponível em: <http://jax-ws.java.net/>.
GMF. Graphical Modeling Framework. Fevereiro 2010. Disponível em:
<http://www.eclipse.org/modeling/gmp/>.
HUMMER, W.; MICHLMAYR, A.; ROSENBERG, F.; DUSTDAR, S.; HUMMER, W.;
MICHLMAYR, A.; DUSTDAR, S. Vresco - vienna runtime environment for service-oriented
. [S.l.]: Springer, 2011. cap. 11, p. 299–324.
computing. In:
JET. Java Emitter Templates. Junho 2007. Disponível em:
<http://www.eclipse.org/modeling/m2t/?project=jet#jet>.
KAISERSWERTH, M.; BRIAN, O.; BRUNSCHWILER, T.; DILL, H.; CHRIST, H.;
FALSAFI, B.; FISCHER, M.; GRIVAS, S. G.; GIOVANOLI, C.; GISI, R. E.; GUTMANN,
R.; KüNDIG, M.; LEINEN, S.; MüLLER, W.; OESCH, D.; REDLI, M.; REY, D.; RIEDL,
R.; SCHäR, A.; SPICHIGER, A.; WIDMER, U.; WIGGINS, A.; ZOLLINGER, M. Cloud
Computing. [S.l.], Novembro 2012.
KOPECKY, J.; VITVAR, T.; BOURNEZ, C.; FARRELL, J. Sawsdl: Semantic annotations for
wsdl and xml schema. IEEE Internet Computing, v. 11, n. 6, p. 60–67, 2007.
KUMAR, S.; MISHRA, R. B. Trs: System for recommending semantic web service
composition approaches. In: Information Technology, 2008. ITSim 2008. International
Symposium on. [S.l.: s.n.], 2008. v. 2.
LAUSEN, H.; POLLERES, A.; ROMAN, D. Web service modeling ontology (wsmo). W3C
Member Submission, Junho 2005. Último acesso em 06 de maio de 2013. Disponível em:
<http://www.w3.org/Submission/WSMO/>.
LEAVITT, N. Is cloud computing really ready for prime time? Computer, IEEE Computer
Society Press, Los Alamitos, CA, USA, v. 42, n. 1, p. 15–20, jan. 2009. ISSN 0018-9162.
Disponível em: <http://dx.doi.org/10.1109/MC.2009.20>.
LEE, T.; HENDLER, J.; LASSILA, O. The semantic web. Scientific American, v. 284, n. 5, p.
34–43, 2001.
50
MACKENZIE, C.; LASKEY, K.; MCCABE, F.; BROWN, P. F.; METZ, R. Reference
Model for Service Oriented Architecture. August 2006. Disponível em: <https://www.oasisopen.org/committees/download.php/19679/>.
MARTIN, D.; BURSTEIN, M.; HOBBS, J.; LASSILA, O.; MCDERMOTT, D.; MCILRAITH,
S.; NARAYANAN, S.; PAOLUCCI, M.; PARSIA, B.; PAYNE, T.; SIRIN, E.; SRINIVASAN,
N.; SYCARA, K. OWL-S Semantic Markup for Web Services. Novembro 2004. Disponível em:
<http://www.w3.org/Submission/OWL-S/>.
MARTIN, D.; BURSTEIN, M.; MCDERMOTT, D.; MCILRAITH, S.; PAOLUCCI, M.;
SYCARA, K.; MCGUINNESS, D. L.; SIRIN, E.; SRINIVASAN, N. Bringing semantics
to web services with owl-s. World Wide Web, Kluwer Academic Publishers, Hingham,
MA, USA, v. 10, n. 3, p. 243–277, Setembro 2007. ISSN 1386-145X. Disponível em:
<http://dx.doi.org/10.1007/s11280-007-0033-x>.
MELL, P.; GRANCE, T. The NIST Definition of Cloud Computing. Setembro 2011. Disponível
em: <http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf>.
MICHELS, P. H. Coreografia de serviços web. Trabalho de Conclusão de Curso (Graduação em
Sistemas de Informação) - Universidade Federal de Santa Catarina. Orientador: Renato Fileto.
2009. Disponível em: <http://projetos.inf.ufsc.br/arquivos_projetos/projeto_621/artigo.pdf>.
MINDSWAP. Maryland Information and Network Dynamics Lab Semantic Web Agents
Project. 2007. Disponível em: <http://www.mindswap.org/2004/owl-s/api/>.
NANDIGAM, J.; GUDIVADA, V. N.; KALAVALA, M. Semantic web services. J. Comput. Sci. Coll., Consortium for Computing Sciences in Colleges,
USA, v. 21, n. 1, p. 50–63, Outubro 2005. ISSN 1937-4771. Disponível em:
<http://dl.acm.org/citation.cfm?id=1088791.1088801>.
NEWCOMER, E. Understanding Web Services: XML, WSDL, SOAP and UDDI. [S.l.]:
Addison-Wesley Longman Publishing, 2002.
PAOLUCCI, M.; SYCARA, K. Autonomous semantic web services. Internet Computing,
IEEE, v. 7, n. 5, p. 34–41, 2003. ISSN 1089-7801.
PARAMESWARAN, A.; CHADDHA, A. Cloud interoperability and standardization. SETLabs
Briefings, v. 7, n. 7, p. 19–26, 2009.
PAUTASSO, C.; ZIMMERMANN, O.; LEYMANN, F. Restful web services vs. "big"’ web
services: making the right architectural decision. In: Proceedings of the 17th international
conference on World Wide Web. New York, NY, USA: ACM, 2008. (WWW ’08), p. 805–814.
ISBN 978-1-60558-085-2. Disponível em: <http://doi.acm.org/10.1145/1367497.1367606>.
PETCU, D. Portability and interoperability between clouds: Challenges and case study. In:
ABRAMOWICZ, W.; LLORENTE, I.; SURRIDGE, M.; ZISMAN, A.; VAYSSIèRE, J. (Ed.).
Towards a Service-Based Internet. [S.l.]: Springer Berlin Heidelberg, 2011, (Lecture Notes in
Computer Science, v. 6994). p. 62–74. ISBN 978-3-642-24754-5.
ROSENBERG, F.; LEITNER, P.; MICHLMAYR, A.; CELIKOVIC, P.; DUSTDAR, S.
Towards composition as a service - a quality of service driven approach. In: Data Engineering,
2009. ICDE ’09. IEEE 25th International Conference on. [S.l.: s.n.], 2009. p. 1733–1740.
ISSN 1084-4627.
51
SENA, V. A. Incorporação da similaridade semântica no owl-s composer. Trabalho de
Conclusão de Curso (Graduação) - Universidade Federal da Bahia: Orientadora: Daniela
Claro. 2009.
SENA, V. A.; CLARO, D. B.; AMORIM, R.; LOPES, D. Similaridade semântica na
composição de sistemas de informação através dos serviços web. In: VI Simpósio Brasileiro de
Sistemas de Informação (SBSI 2010). [S.l.: s.n.], 2010.
SIVASHANMUGAM, K.; VERMA, K.; SHETH, A.; MILLER, J. Adding Semantics to Web
Services Standards. 2003.
VOOSLUYS, W.; BROBERG, J.; BUYYA, R. Introduction to Cloud Computing, in Cloud
Computing: Principles and Paradigms. [S.l.]: Wiley, 2011.
WANG, H.; ZHANG, Y. qing; SUNDERRAMAN, R. Soft semantic web services agent. In:
Proceedings of NAFIPS 2004. [S.l.: s.n.], 2004. p. 126–129.
ZHANG, Q.; CHENG, L.; BOUTABA, R. Cloud computing: state-of-the-art and research
challenges. Journal of Internet Services and Applications, Springer London, v. 1, n. 1, p. 7–18,
Maio 2010. ISSN 1867-4828. Disponível em: <http://dx.doi.org/10.1007/s13174-010-00076>.
ZOU, G.; CHEN, Y.; XIANG, Y.; HUANG, R.; XU, Y. Ai planning and combinatorial
optimization for web service composition in cloud computing. In: Proceedings of the
International Conference on Cloud Computing and Virtualization. [S.l.: s.n.], 2010.
ANEXO I
Relatório da avaliação do OWL-S Composer por alunos do Mestrado
em Ciência da Computação da Universidade Federal da Bahia.
Informações sobre a avaliação
Data de realização: 24/07/2013
Número de avaliadores: 13
Versão do OWL-S Composer: 3.1
Seção 1. Informações do avaliador
Questão realizada como autoavaliação para mensurar o conhecimento dos
participantes em Serviços Web, Serviços Web Semânticos e OWL-S Composer.
Em uma escala de 0 a 4, determinar o conhecimento de Serviços Web, onde:
0. Eu não conhecia nada de Serviços Web antes de trabalhar com a ferramenta;
1. Eu conhecia pouco de Serviços Web;
2. Eu conhecia pouco de composição de Serviços Web;
3. Eu conhecia muito de composição de Serviços Web;
4. Eu já conhecia a ferramenta o OWL-S Composer.
Número de respostas Conhecimento em Serivços Web 8 7 6 5 4 3 2 1 0 0 1 2 Resposta 3 4 Seção 2. Presença das funcionalidades do plug-in x Importância das
funcionalidades numa ferramenta para composição de Serviços Web
Os quesitos desta seção comparam as funcionalidades presentes no OWL-S
Composer com a importância das mesmas em uma ferramenta compositora de
serviços. Algumas questões foram feitas apenas para avaliar o plug-in. Tais questões
estão marcadas com um asterisco (*).
Todas as questões desta seção variam de uma escala de 0 a 4, onde:
0. Não aplica ou não tem conhecimento;
1. Inadequada ou ausente;
2. Fraca;
3. Boa;
4. Muito boa.
Critério Interface:
A interface possui botões e menus que facilitam o desenvolvimento da
composição de serviços?
Número de respostas Interface 10 9 8 7 6 5 4 3 2 1 0 OWL-­‐S Composer Importância 0 1 2 Resposta 3 4 Critério Funcionalidade de um Serviço Web *:
O ambiente tem a funcionalidade de criar um serviço web a partir de outros
plugins já existentes na ferramenta?
Número de respostas Funcionalidade de um Serviço Web 9 8 7 6 5 4 3 2 1 0 0 1 2 3 4 Resposta Critério Funcionalidade da composição de Serviços Web:
O ambiente permite lidar com a composição de serviços web desde a sua
criação até a execução desta composição? Há menus que facilitam esta criação?
Número de respostas Funcionalidade na composição de Serviços Web 10 8 6 OWL-­‐S Composer 4 Importância 2 0 0 1 2 Resposta 3 4 Critério Usabilidade:
A ferramenta é de fácil manuseio para a criação de composições de serviços
web? É possível utilizar controles da composição, tais como sequence, split, na
ferramenta facilmente?
Usabilidade Número de respostas 7 6 5 4 3 OWL-­‐S Composer 2 Importância 1 0 0 1 2 3 4 Resposta Critério Integração:
A ferramenta permite criar composições de serviços web em um único
ambiente integrado ou é necessário o uso de diversos ambientes para se ter uma
composição de serviços web?
Número de respostas Integração 10 9 8 7 6 5 4 3 2 1 0 OWL-­‐S Composer Importância 0 1 2 Resposta 3 4 Critério Legibilidade:
Os arquivos *.OWL-S gerados, tanto na conversão do WSDL como na
geração a partir do diagrama de composição, são legíveis? Eles puderam ser
reutilizados na ferramenta? Houve necessidade de manipulá-los manualmente?
Número de respostas Legibilidade 10 9 8 7 6 5 4 3 2 1 0 OWL-­‐S Composer Importância 0 1 2 3 4 Resposta Critério Grau de Similaridade:
A ferramenta permite descobrir serviços baseados no grau de similaridade
semântica?
Grau de Similaridade 4.5 Número de respostas 4 3.5 3 2.5 OWL-­‐S Composer 2 1.5 Importância 1 0.5 0 0 1 2 Resposta 3 4 Critério Análise Global *:
Em geral, o plug-in auxilia o usuário a manejar composições de Serviços
Web?
Análise Global Número de respostas 12 10 8 6 4 2 0 0 1 2 3 4 Resposta Seção 3. Relevância de funcionalidades para o OWL-S Composer na
nuvem
O conjunto de questões utilizado nesta seção visa compreender a relevância de
certas funcionalidades para uma ferramenta capaz de realizar composição de Serviços
Web em nuvem.
Nesse contexto, as questões utilizam uma escala de 0 a 4, onde:
0. Não aplica ou não tem conhecimento;
1. Irrelevante;
2. Moderadamente relevante;
3. Relevante;
4. Muito relevante.
Critério Publicação portável:
É relavante ter uma funcionalidade que permite a publicação em diferentes
provedores de nuvem (Google, Amazon, Eucalyptus)? Isso facilita o desenvolvimento
de Cloud Services?
Portabilidade 9 Número de respostas 8 7 6 5 4 3 2 1 0 0 1 2 3 4 Resposta Critério Interoperabilidade entre nuvens:
É relevante para o plugin criar uma interface interoperável onde serviços
possam interagir com serviços publicados em outras nuvens?
Interoperabilidade 9 Número de respostas 8 7 6 5 4 3 2 1 0 0 1 2 Resposta 3 4 Critério Descoberta de serviços:
É importante que o plugin permita descobrir serviços similares em nuvens
distintas?
Descoberta de Serviços Web 9 Número de respostas 8 7 6 5 4 3 2 1 0 0 1 2 3 4 Resposta Critério Usabilidade:
É importante que o plugin permita publicar, compor e descobrir serviços em
nuvem de uma maneira fácil e transparente para o desenvolvedor?
Usabilidade 10 Número de respostas 9 8 7 6 5 4 3 2 1 0 0 1 2 Resposta 3 4 ANEXO II
Relatório da avaliação do OWL-S Composer por alunos do
Bacharelado em Sistemas de Informação da Universidade Federal da
Bahia.
Informações sobre a avaliação
Data de realização: 31/07/2013
Número de avaliadores: 12
Versão do OWL-S Composer: 3.1
Seção 1. Informações do avaliador
Questão realizada como autoavaliação para mensurar o conhecimento dos
participantes em Serviços Web, Serviços Web Semânticos e OWL-S Composer.
Em uma escala de 0 a 4, determinar o conhecimento de Serviços Web, onde:
0. Eu não conhecia nada de Serviços Web antes de trabalhar com a ferramenta;
1. Eu conhecia pouco de Serviços Web;
2. Eu conhecia pouco de composição de Serviços Web;
3. Eu conhecia muito de composição de Serviços Web;
4. Eu já conhecia a ferramenta o OWL-S Composer.
Número de respostas Conhecimento em Serivços Web 12 10 8 6 4 2 0 0 1 2 Resposta 3 4 Seção 2. Presença das funcionalidades do plug-in x Importância das
funcionalidades numa ferramenta para composição de Serviços Web
Os quesitos desta seção comparam as funcionalidades presentes no OWL-S
Composer com a importância das mesmas em uma ferramenta compositora de
serviços. Algumas questões foram feitas apenas para avaliar o plug-in. Tais questões
estão marcadas com um asterisco (*).
Todas as questões desta seção variam de uma escala de 0 a 4, onde:
0. Não aplica ou não tem conhecimento;
1. Inadequada ou ausente;
2. Fraca;
3. Boa;
4. Muito boa.
Critério Interface:
A interface possui botões e menus que facilitam o desenvolvimento da
composição de serviços?
Interface Número de respostas 8 7 6 5 4 OWL-­‐S Composer 3 Importância 2 1 0 0 1 2 Resposta 3 4 Critério Funcionalidade de um Serviço Web *:
O ambiente tem a funcionalidade de criar um serviço web a partir de outros
plugins já existentes na ferramenta?
Funcionalidade de um Serviço Web Número de respostas 6 5 4 3 2 1 0 0 1 2 3 4 Resposta Critério Funcionalidade da composição de Serviços Web:
O ambiente permite lidar com a composição de serviços web desde a sua
criação até a execução desta composição? Há menus que facilitam esta criação?
Número de respostas Funcionalidade na composição de Serviços Web 10 8 6 OWL-­‐S Composer 4 Importância 2 0 0 1 2 Resposta 3 4 Critério Usabilidade:
A ferramenta é de fácil manuseio para a criação de composições de serviços
web? É possível utilizar controles da composição, tais como sequence, split, na
ferramenta facilmente?
Usabilidade Número de respostas 8 7 6 5 4 OWL-­‐S Composer 3 Importância 2 1 0 0 1 2 3 4 Resposta Critério Integração:
A ferramenta permite criar composições de serviços web em um único
ambiente integrado ou é necessário o uso de diversos ambientes para se ter uma
composição de serviços web?
Integração Número de respostas 8 7 6 5 4 OWL-­‐S Composer 3 Importância 2 1 0 0 1 2 Resposta 3 4 Critério Legibilidade:
Os arquivos *.OWL-S gerados, tanto na conversão do WSDL como na
geração a partir do diagrama de composição, são legíveis? Eles puderam ser
reutilizados na ferramenta? Houve necessidade de manipulá-los manualmente?
Legibilidade Número de respostas 8 7 6 5 4 OWL-­‐S Composer 3 Importância 2 1 0 0 1 2 3 4 Resposta Critério Grau de Similaridade:
A ferramenta permite descobrir serviços baseados no grau de similaridade
semântica?
Grau de Similaridade Número de respostas 6 5 4 3 OWL-­‐S Composer 2 Importância 1 0 0 1 2 Resposta 3 4 Critério Análise Global *:
Em geral, o plug-in auxilia o usuário a manejar composições de Serviços
Web?
Análise Global Número de respostas 6 5 4 3 2 1 0 0 1 2 3 4 Resposta Seção 3. Relevância de funcionalidades para o OWL-S Composer na
nuvem
O conjunto de questões utilizado nesta seção visa compreender a relevância de
certas funcionalidades para uma ferramenta capaz de realizar composição de Serviços
Web em nuvem.
Nesse contexto, as questões utilizam uma escala de 0 a 4, onde:
0. Não aplica ou não tem conhecimento;
1. Irrelevante;
2. Moderadamente relevante;
3. Relevante;
4. Muito relevante.
Critério Publicação portável:
É relavante ter uma funcionalidade que permite a publicação em diferentes
provedores de nuvem (Google, Amazon, Eucalyptus)? Isso facilita o desenvolvimento
de Cloud Services?
Portabilidade Número de respostas 6 5 4 3 2 1 0 0 1 2 3 4 Resposta Critério Interoperabilidade entre nuvens:
É relevante para o plugin criar uma interface interoperável onde serviços
possam interagir com serviços publicados em outras nuvens?
Interoperabilidade 9 Número de respostas 8 7 6 5 4 3 2 1 0 0 1 2 Resposta 3 4 Critério Descoberta de serviços:
É importante que o plugin permita descobrir serviços similares em nuvens
distintas?
Descoberta de Serviços Web 9 Número de respostas 8 7 6 5 4 3 2 1 0 0 1 2 3 4 Resposta Critério Usabilidade:
É importante que o plugin permita publicar, compor e descobrir serviços em
nuvem de uma maneira fácil e transparente para o desenvolvedor?
Usabilidade 10 Número de respostas 9 8 7 6 5 4 3 2 1 0 0 1 2 Resposta 3 4 ANEXO III
Relatório da avaliação do OWL-S Composer por integrantes da
Empresa Júnior de informática da Universidade Federal da Bahia.
Informações sobre a avaliação
Data de realização: 13/08/2013
Número de avaliadores: 6
Versão do OWL-S Composer: 4.0
Seção 1. Comparativo de tempo de publicação usando o OWL-S
Composer 4.0
Através do desenvolvimento de uma aplicação que disponibilizam Serviços
Web de conversão de temperatura, os avaliadores preencheram um formulário para
comparar a diferença entre o tempo de publicação usando a tarefa de pré-publicação
realizada pelo OWL-S Composer e sem utilizá-la. A tabela à seguir apresenta os
resultados desse experimento.
Com OWL- S Composer
Sem OWL-S Composer
Avaliador 1
10:00
16:20
Avaliador 2
12:40
17:15
Avaliador 3
14:20
18:45
Avaliador 4
13:40
18:30
Avaliador 5
15:10
20:25
Avaliador 6
14:00
26:30
Média dos Candidatos
13:18
19:38
Foi questionado o índice de satisfação dos avaliadores com relação à economia de
tempo devido ao uso do plug-in. O seguinte gráfico retrata os resultados.
Número de respostas Satisfação com economia de tempo 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 1 2 3 4 5 Resposta Seção 2. Informações do avaliador
Questão realizada como autoavaliação para mensurar o conhecimento dos
participantes em Serviços Web, Serviços Web Semânticos e OWL-S Composer.
Em uma escala de 0 a 4, determinar o conhecimento de Serviços Web, onde:
0. Eu não conhecia nada de Serviços Web antes de trabalhar com a ferramenta;
1. Eu conhecia pouco de Serviços Web;
2. Eu conhecia pouco de composição de Serviços Web;
3. Eu conhecia muito de composição de Serviços Web;
4. Eu já conhecia a ferramenta o OWL-S Composer.
Número de respostas Conhecimento em Serivços Web 3.5 3 2.5 2 1.5 1 0.5 0 0 1 2 3 4 Resposta Seção 3. Presença das funcionalidades do plug-in x Importância das
funcionalidades numa ferramenta para composição de Serviços Web
Os quesitos desta seção comparam as funcionalidades presentes no OWL-S
Composer com a importância das mesmas em uma ferramenta compositora de
serviços. Algumas questões foram feitas apenas para avaliar o plug-in. Tais questões
estão marcadas com um asterisco (*).
Todas as questões desta seção variam de uma escala de 0 a 4, onde:
0. Não aplica ou não tem conhecimento;
1. Inadequada ou ausente;
2. Fraca;
3. Boa;
4. Muito boa.
Critério Interface:
A interface possui botões e menus que facilitam o desenvolvimento da
composição de serviços?
Interface Número de respostas 7 6 5 4 3 OWL-­‐S Composer 2 Importância 1 0 0 1 2 3 4 Resposta Critério Funcionalidade de um Serviço Web *:
O ambiente tem a funcionalidade de criar um serviço web a partir de outros
plugins já existentes na ferramenta?
Funcionalidade de um Serviço Web Número de respostas 3.5 3 2.5 2 1.5 1 0.5 0 0 1 2 Resposta 3 4 Critério Funcionalidade da composição de Serviços Web:
O ambiente permite lidar com a composição de serviços web desde a sua
criação até a execução desta composição ? Há menus que facilitam esta criação?
Número de respostas Funcionalidade na composição de Serviços Web 7 6 5 4 3 OWL-­‐S Composer 2 Importância 1 0 0 1 2 3 4 Resposta Critério Usabilidade:
A ferramenta é de fácil manuseio para a criação de composições de serviços
web? É possível utilizar controles da composição, tais como sequence, split, na
ferramenta facilmente?
Usabilidade Número de respostas 6 5 4 3 OWL-­‐S Composer 2 Importância 1 0 0 1 2 Resposta 3 4 Critério Integração:
A ferramenta permite criar composições de serviços web em um único
ambiente integrado ou é necessário o uso de diversos ambientes para se ter uma
composição de serviços web?
Integração Número de respostas 7 6 5 4 3 OWL-­‐S Composer 2 Importância 1 0 0 1 2 3 4 Resposta Critério Legibilidade:
Os arquivos *.OWL-S gerados, tanto na conversão do WSDL como na
geração a partir do diagrama de composição, são legíveis? Eles puderam ser
reutilizados na ferramenta? Houve necessidade de manipulá-los manualmente?
Legibilidade Número de respostas 7 6 5 4 3 OWL-­‐S Composer 2 Importância 1 0 0 1 2 Resposta 3 4 Critério Grau de Similaridade:
A ferramenta permite descobrir serviços baseados no grau de similaridade
semântica?
Grau de Similaridade Número de respostas 7 6 5 4 OWL-­‐S Composer 3 Importância 2 1 0 0 1 2 3 4 Resposta Critério Análise Global *:
Em geral, o plug-in auxilia o usuário a manejar composições de Serviços
Web?
Análise Global Número de respostas 6 5 4 3 2 1 0 0 1 2 Resposta 3 4 Seção 4. Relevância de funcionalidades para o OWL-S Composer na
nuvem
O conjunto de questões utilizado nesta seção visa compreender a relevância de
certas funcionalidades para uma ferramenta capaz de realizar composição de Serviços
Web em nuvem.
Nesse contexto, as questões utilizam uma escala de 0 a 4, onde:
0. Não aplica ou não tem conhecimento;
1. Irrelevante;
2. Moderadamente relevante;
3. Relevante;
4. Muito relevante.
Critério Publicação portável:
É relavante ter uma funcionalidade que permite a publicação em diferentes
provedores de nuvem (Google, Amazon, Eucalyptus)? Isso facilita o desenvolvimento
de Cloud Services?
Portabilidade Número de respostas 6 5 4 3 2 1 0 0 1 2 Resposta 3 4 Critério Interoperabilidade entre nuvens:
É relevante para o plugin criar uma interface interoperável onde serviços
possam interagir com serviços publicados em outras nuvens?
Interoperabilidade 4.5 Número de respostas 4 3.5 3 2.5 2 1.5 1 0.5 0 0 1 2 3 4 Resposta Critério Descoberta de serviços:
É importante que o plugin permita descobrir serviços similares em nuvens
distintas?
Descoberta de Serviços Web 4.5 Número de respostas 4 3.5 3 2.5 2 1.5 1 0.5 0 0 1 2 Resposta 3 4 Critério Usabilidade:
É importante que o plugin permita publicar, compor e descobrir serviços em
nuvem de uma maneira fácil e transparente para o desenvolvedor?
Usabilidade Número de respostas 3.5 3 2.5 2 1.5 1 0.5 0 0 1 2 Resposta 3 4