UNIVERSIDADE FEDERAL DA BAHIA

Transcrição

1 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 13.1

2 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 13.1

3 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

4 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

5 SUMÁRIO Lista de Figuras Lista de Tabelas Lista de abreviaturas e siglas 1 Introdução Motivação Proposta Estrutura do trabalho Serviços Web Semânticos 1.1 OWL-S Arquitetura Orientada a Serviços Composição de Serviços Web Semânticos Computação em nuvem Características essenciais Modelos de serviço Modelos de implantação Provedores de serviços em nuvem Serviços Web Semânticos em nuvem Portabilidade e interoperabilidade entre nuvens

6 5 Trabalhos relacionados VRESCo Multi-cloud Interoperabilidade para o OWL-S Composer Histórico do OWL-S Composer Contribuições Ambiente Projeto Estrutural Nuvens utilizadas Arquitetura do OWL-S Composer Implementação Experimentos e Resultados o experimento: Divulgação e avaliação do OWL-S Composer para Mestrado e Graduação Resultados o experimento: Publicação de um projeto na Amazon e no Eucalyptus o experimento: Divulgação e testes realizados pela Empresa Júnior de Informática da UFBA Resultados Conclusão Dificuldades encontradas Trabalhos futuros Referências Bibliográficas 48

7 LISTA DE FIGURAS.1 Ontologia Service do OWL-S (MARTIN et al., 4) Arquitetura Orientada a Serviços Diferença entre orquestração e coreografia (MICHELS, 9) Modelos de serviço de computação na nuvem (ZHANG; CHENG; BOUTABA, 1) Ciclo de vida de um Serviço Web (FERREIRA, 1) Esquema de interoperabilidade entre nuvens (BHUKYA REETA SONY A.L, 1) Modelo de metadados para um serviço (HUMMER et al., 11) Evolução da arquitetura do OWL-S Composer Exemplo de composição feita pela interface do OWL-S Composer Arquitetura do OWL-S Composer Seleção do projeto a ser pré-publicado Seleção das nuvens e pacotes Inserção de credenciais Publicando com o plugin da Amazon para Eclipse Página do serviço desenvolvido publicado na amazon

8 LISTA DE TABELAS 3.1 Comparativo entre public cloud e data center convencional (ARMBRUST et al., 1)

9 LISTA DE ABREVIATURAS E SIGLAS ABFR Advanced Back & Forward Recovery, p. 3 API Application Programming Interface, p. 33 EMF Eclipse Modeling Framework Project, p. 3 GEF Graphical Editing Framework, p. 3 GMF Graphical Modeling Framework, p. 3 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. MDR Monitoramento, Diagnóstico e Recuperação, p. 4 MVC Model-View-Controller, p. 3 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. 7 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

10 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, 9). 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, 1) 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, 5). 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., 4). 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.

11 1 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, 9). 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, 11) para a plataforma Eclipse (FOUNDA- TION, 13) 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. 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

12 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 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.

13 1 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, 1). 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, 1). 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., 3) e por isso surgiram diversos projetos como por exemplo: Ontology Web Language for Service (OWL-S) (MARTIN et al., 7), WSMO (Web Service Modeling Ontology) (LAUSEN; POLLERES; ROMAN, 5) e o Semantic Annotations for WSDL (SAWSDL) (KOPECKY et al., 7). É nesse contexto que surgem os Serviços Web Semânticos (SWS) (WANG; ZHANG; SUNDERRAMAN, 4). 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

14 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, 3)..1 OWL-S Movidos pelo movimento para o desenvolvimento da nova geração da Web que autores em (MARTIN et al., 4) 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; () 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., 7). 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., 4): 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-

15 14 cessidades; () 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.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.1: Ontologia Service do OWL-S (MARTIN et al., 4).. 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., 6).

16 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, 9), entre eles: distribuição, heterogeneidade, dinamismo, transparência e orientação a processos. Na Figura. 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 (). A chamada para utilizar o serviço é feita do Solicitante do Serviço para o Provedor do Serviço (3). Figura.: 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, 9). 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.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..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,

17 16 Figura.3: Diferença entre orquestração e coreografia (MICHELS, 9). mas a composição desses serviços atômicos e compostos disponíveis e torna esse processo factível (KUMAR; MISHRA, 8). 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, 5). 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, 8).

18 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., 1). No presente trabalho serão seguidos as definições propostas pelo Instituto Nacional de Padrões e Tecnologias (NIST) dos Estados Unidos (MELL; GRANCE, 11). 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, 11). As definições da NIST permanecem em rascunho, mas as suas definições já são largamente utilizadas pela academia (CHEN; PAXSON; KATZ, 1)(ZHANG; CHENG; BOUTABA, 1)(VOOSLUYS; BROBERG; BUYYA, 11). 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-

19 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. 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, 1). 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

20 19 Figura 3.1: Modelos de serviço de computação na nuvem (ZHANG; CHENG; BOUTABA, 1). 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, 1). 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.

21 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, 11). É 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, 1). 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, 1). 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

22 1 Vantagem Public cloud Data center Aparência de recursos computacionais Sim Não infinitos sob demanda Eliminação de um compromisso Sim Não antecipado por usuários Possibilidade de pagar por uso de Sim Não recursos computacionais em um base de tempo pequena conforme necessário Economias de escala devido a grandes Sim Parcial data centers Maior utilização de multiplexação de Sim Depende da organização cargas de trabalho de diferentes organizações Simplifica operação e aumento de Sim Não utilização via virtualização de recursos Tabela 3.1: Comparativo entre public cloud e data center convencional (ARMBRUST et al., 1) 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, 1). 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., 1). Alguns dos provedores de serviços em cloud mais comuns estão listados a seguir: Amazon Web Services ( - Fornece um conjunto de ferramentas, bibliotecas e API s próprias para executar qualquer tipo de tecnologia que execute sobre uma infraestrutura particular; CloudBees ( - Possui invólucro para desenvolvimento de aplicações Web em Java;

23 Eucalyptus ( - É 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 ( - Especializada em aplicações do tipo CRM e voltadas para o gerenciamento de clientes, empresas, etc; Google App Engine ( - Possui invólucro para desenvolvimento de aplicações Web em Java e Python; Heroku ( - Possui ferramentas, bibliotecas e API s próprias para execução de aplicações desenvolvidas em Ruby on Rails; Microsoft Azure ( - Possui ferramentas, bibliotecas e API s próprias para executar aplicações desenvolvidas em.net.

24 3 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, 1). As etapas de publicação, descoberta, seleção e invocação foram discutidas na Seção.. 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

25 4 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, 1). 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., 9) 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, 1). 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., 1). 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, 11). A importância destes dois termos num ambiente de nuvem está ligada à necessidade dos clientes

26 5 em: (1) publicar em diferentes provedores sem a necessidade de realizar extensas modificações no software desenvolvido e () 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, 1). A Figura 4. representa um esquema de interoperabilidade. Figura 4.: Esquema de interoperabilidade entre nuvens (BHUKYA REETA SONY A.L, 1). 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 JEE (NEWCOMER, ). 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

27 6 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, 8). 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, 1).

28 7 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., 11) e Multi-cloud (ZOU et al., 1). 5.1 VRESCO VRESCo (Vienna Runtime Environment for Service-oriented Computing) (HUMMER et al., 11) é 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., 9) 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.

29 8 Figura 5.1: Modelo de metadados para um serviço (HUMMER et al., 11). 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; () 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. MULTI-CLOUD O Multi-Cloud (ZOU et al., 1) é 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, () combinação de nuvem base e (3) combinação inteligente de

30 9 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., 11) 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., 1) 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.

31 3 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. 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 8 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. do OWL-S Composer (FONSECA; CLARO; LOPES, 9) foi desenvolvida

32 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. (SENA, 9) é o produto da incorporação da ferramenta OWL-S Discovery (AMORIM, 9) 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. do OWL-S Composer (FERREIRA, 1). 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, 11). A Figura 6. ilustra um exemplo de composição sendo modelada através da interface do OWL-S Composer. Figura 6.: Exemplo de composição feita pela interface do OWL-S Composer

33 3 6. 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. 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. 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.). Como o plug-in é uma ferramenta open source o seu código fonte foi movido para a plataforma GitHub 1 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.. 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, 9) 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

34 33 utilizada é a.5.. Graphical Editing Framework (GEF) (GEF, 13) O GEF é um framework que provê ferramentas para criar editores gráficos no Eclipse. Possui três componentes para a realização das tarefas. Drawd, 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 Drawd 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 Graphical Modeling Framework (GMF) (GMF, 1) 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... Java Emitter Templates (JET) (JET, 7) 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 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, 13), 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; () OWLS-API (MINDSWAP, 7) é uma biblioteca que fornece o necessário para manejar documentos OWL-S, como leitura, escrita e execução de serviços compostos.

35 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, 13) e () Eucalyptus (EUCALYPTUS, 13). 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 ARQUITETURA DO OWL-S COMPOSER 4. A Figura 6.3 apresenta a arquitetura do OWL-S Composer 4.. 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. é 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., 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

36 35 Figura 6.3: Arquitetura do OWL-S Composer 4. Java API for XML Web Services (JAX-WS) (GLASSFISH, 13) é 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." encoding="utf-8"?> <web app> <display name>awsweathersoapserver</display name> <welcome file list> <welcome file>index.jsp</welcome file> </welcome file list> <listener>

37 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. é um exemplo de arquivo sun-jaxws.xml para uma suposta aplicação que informa o clima. <?xml version="1." encoding="utf-8"?> <endpoints xmlns=' version='.'> <endpoint name='weatherinfo' implementation='com.example.weatherinfo' url pattern='/weatherinfoservice' /> </endpoints> Listagem 6.: Exemplo de arquivo sun-jaxws.xml

38 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. 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 Unified- CloudService. A listagem 6.3 mostra a implementação da classe AWSCloudService para a funcão prepare- ToPublish(). 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: publicação Sequência de tarefas necessárias para preparar um projeto Amazon para

39 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. e a análise dos respectivos resultados alcançados a ESTUDO DE CASO: AVALIAÇÃO E EXPLORAÇÃO DO OWL-S COMPOSER PARA MESTRADO E GRA- DUAÇÃ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ções 1 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ção 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 dclaro/download/mate15/owl-s%composer.pdf

40 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, () 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., 7), (FONSECA; CLARO; LOPES, 9) e (SENA et al., 1). 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;. 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 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);

41 4. 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; 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. 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. 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, 6% considerou que a interface é um item importante e 8% 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.

42 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 a 4 esses itens tiveram média de 3.53 e 3.75 e na turma de graduação 3.44 e 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. PROVA DE CONCEITO: PUBLICAÇÃO DE UM PRO- JETO 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..</min toolkit version> <services> <service name="s3"> <service name="iam"> <service name="ec"> service> <service name="autoscaling"> AutoScaling/</service> <service name="cloudwatch"> </services> </region> CloudWatch/</service> Listagem 7.1: Exemplo de arquivo web.xml

43 4 A etapa de pré-publicação do OWL-S Composer se resume em três etapas: (1) Seleção do projeto, () 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. 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.

44 43 Figura 7.: Seleção das nuvens e pacotes Figura 7.3: Inserção de credenciais Figura 7.4: Publicando com o plugin da Amazon para Eclipse