Web Services para Computação de Alto Desempenho

Transcrição

1 Web Services para Computação de Alto Desempenho Clarissa C. Marquezan 1, Alexandre Carissimi 1, Philippe O. A. Navaux 1 1 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal Porto Alegre RS Brazil {clarissa, asc, navaux}@inf.ufrgs.br Abstract. Middlewares are commonly used to solve heterogeneity problems. They are able to provide high abstraction levels so that it can hide the complexity of the systems. Some middlewares, like CORBA, RMI, DCOM, etc, were proposed over past years. However, none of them achieved the really dissociation from their underlying systems, which causes problems to deal with interoperability. Since 2001, Web services have been appearing as an indeed solution for interoperability, transparency and platform/language independency. The established high performance computing systems present high levels of heterogeneity, distribution and a great amount of tools to be used. Thus, these kind of systems behavior as a good scenario to profit Web service technology. The goal of this work is to present the Web service technology and how it is used on high performance computing (HPC), considering: clusters, grids and multiple clusters. Resumo. Para solucionar os problemas de hetereogeneidade é necessário o emprego de middlewares que abstraiam toda a complexidade dos sistemas. Alternativas, como middlewares baseados em CORBA, RMI, DCOM, entre outros, foram propostas ao longo dos anos. Entretanto, essas tecnologias não conseguiram atingir de fato a dissociação da infra-estrutura das quais faziam parte. A partir de 2001, Web services começaram a surgir como tecnologia capaz de prover efetivamente transparḙncia, interoperabilidade, independḙncia de linguagem e plataforma. Os sistemas de computação de alto desempenho atuais apresentam um alto grau de heterogeneidade, distribuição e uma grande diversidade de ferramentas. Desta forma, este cenário apresenta-se como um terreno propício para a aplicação de Web services. Este minicurso tem como objetivo apresentar as características de Web services e como essa tecnologia é empregada no contexto de alto desempenho, considerando: clusters, grids and múltiplos clusters. 1. Introdução Sistemas distribuídos estão presentes em vários segmentos da sociedade, abrangendo uma quantidade ampla de áreas de conhecimento, compreendendo pesquisa e negócios dentro e fora da computação. Cada qual com um determinado objetivo, como por exemplo, o comércio eletrônico (e-business ou e-commerce). Neste tipo de negócio, o objetivo é manter os sistemas o maior tempo possível em funcionamento, além de tentar integrar os diferentes sistemas de fornecedores e compradores para obtenção de maiores lucros. Um sistema de e-commerce não disponível, acarreta perdas financeiras para a empresa. Em contra-partida a esses tipos de sistemas voltados para empresas, existem sistemas distribuídos cuja finalidade é manter uma rede de dados e serviços para seus usuários

2 (no caso professores, alunos e funcionários). Enfim, são inúmeros os tipos de sistemas distribuídos e sua aplicação cotidiana. Um sistema distribuído é caracterizado por componentes de software e de hardware, localizados em computadores interligados por uma rede, que se comunicam e coordenam suas ações através de troca de mensagens [Coulouris et al. 2005]. A principal motivação para a construção de um sistema distribuído é o compartilhamento de recursos. O termo recurso é muito vago, mas retrata muito bem a variedade de coisas que podem ser compartilhadas através de uma rede. Um recurso pode ser uma impressora, um disco, arquivos de dados, programas executáveis, banco de dados, etc. A Internet e as intranets corporativas são exemplos de sistemas distribuídos bastante próximos de nosso dia a dia. Uma forma bastante comum de tratar a complexidade de um sistema distribuído é trabalhar com modelos. Basicamente, um modelo serve para compreender o funcionamento de um sistema, determinando quais são as principais entidades que o compõem, como elas interagem entre si, quais os fatores que afetam o comportamento individual ou coletivo dessas entidades e propriedades do sistema quanto aos desafios de desenvolvimento de sistemas distribuídos [Coulouris et al. 2005]. O objetivo é tornar explícitas as suposições relevantes sobre o sistema modelado fazendo generalizações a respeito do que é ou não possível. Um middleware é um modelo conveniente aos programadores de aplicações distribuídas, oferecendo uma série de blocos básicos para a construção de softwares [Coulouris et al. 2005]. Uma característica relevante de um middleware, é a capacidade que ele apresenta para mascarar a heterogeneidade de um sistema oferecendo uma visão uniforme do mesmo através da descrição comportalmental do sistema e de interfaces de programação independentes de plataforma (uma combinação qualquer de hardware e de sistema operacional). Os sistemas de alto desempenho (HPC - High Performance Computing) apresentam uma série de características muito próximas aos sistemas distribuídos, como por exemplo, a capacidade de lidar com recursos heterogêneos, que na maioria das vezes são distribuídos por diferentes domínios administrativos, o que leva a problemas de segurança. Como cada vez mais existem sistemas HPC formados por centenas e milhares de elementos, isso se reflete em questões de escalabilidade e tolerância a falhas. Da mesma forma que existem middlewares para modelar serviços e oferecer uma abstração das especificidades dos componentes e dos serviços em um sistema distribuído, em HPC, também tem-se buscado o desenvolvimento de ambientes e ferramentas baseadas em middlewares para mascararem os detalhes de mais baixo nível para seus usuários (tipicamente desenvolvedores de aplicações), fornecendo um nível de abstração mais alto. São exemplos dessa abordagem, o uso do Globus Toolkit [Foster 2006], HPC2N [Elmroth et al. 2005], entre outros. A definição de middlewares para sistemas HPC e as tecnologias envolvidas na sua implementação são o foco de muitas pesquisas. O foco deste trabalho é mostrar como a tecnologia Web service é utilizada para construção de middlewares de sistemas HPC. No contexto desse trabalho, entende-se por sistemas HPC, clusters [Buyya 1999], grids [Foster et al. 2001] e múltiplos clusters [Barreto et al. 2000, Aumage 2002]. Para que se possa explorar, devidamente, o foco deste trabalho, torna-se necessário a introdução de alguns conceitos básicos, descritos a seguir.

3 1.1. Conceitos Fundamentais Cluster - Um cluster, ou agregado, é um tipo de sistema de processamento distribuído que consiste em uma coleção de nodos computacionais independentes, sem memória compartilhada, interconectados entre si [Buyya 1999]. Os clusters aproveitam a ampla disponibilidade, no mercado de massa, de componentes de interconexão de redes e de computadores de baixo custo. Esses componentes são ditos de prateleira ou commodity off-the-shelf - COTS. Assim, os nodos podem ser construídos e configurados a partir de computadores comuns, com sistemas operacionais convencionais, e interconectados por redes montadas a partir de interfaces e equipamentos de interconexão também comuns, como hubs e switches Ethernet. Entretanto, também existem componentes e nodos dedicados a construção de clusters onde é possível se encontrar nodos fisicamente instalados dentro de um único gabinete ou em gabinetes separados. No primeiro caso, os nodos são interconectados por barramentos dedicados e/ou proprietários de alto desempenho e, no segundo caso, por redes de alta banda passante como, por exemplo, Myrinet, Infiniband). A arquitetura típica de um cluster é aquela conhecida como Beowulf [Buyya 1999], que é composto por um front-end e de vários nodos, não impondo um arquitetura fixa, o que garante uma grande liberdade quanto à escolha e à distribuição de processadores, memória, rede e armazenamento secundário. Os clusters Beowulf são dedicados à execução de tarefas de computação de alto desempenho. O front-end é o único computador fisicamente conectado à Internet ou à rede institucional, e é o computador que os usuários devem acessar para submeterem tarefas. Os nodos são máquinas dedicadas à execução de tarefas do cluster e estão interconectados por uma rede local (LAN) interna. Grid - um grid, ou grade computacional, é um sistema distribuído voltado para o compartilhamento controlado de recursos computacionais heterogêneos e pertencentes a diferentes instituições. Este tipo de sistema utiliza uma estrutura de middleware para fornecer aos seus usuários uma abstração de máquina virtual ou imagem única de sistema [Foster et al. 2001]. A fim de se compreender o conceito da computação em grid, pode-se fazer uma analogia à rede elétrica (electric grid) [CERN 2006]. Esta rede disponibiliza energia sob demanda, sendo que os usuários desconhecem os detalhes sobre a origem da energia e qual a complexidade da malha de transmissão e distribuição. De modo semelhante, a grade computacional (grid) disponibiliza computação sob demanda, e o usuário desconhece detalhes como especificações dos sistemas de computação (software, hardware e rede) utilizados e a complexidade de gerenciamento dos recursos computacionais. Considerando os aspectos mencionados até agora, é possível afirmar que nem todo sistema distribuído é um grid, mas todo grid é um sistema distribuído. Então, faz-se necessário um conjunto de critérios para decidir se um determinado sistema é ou não um grid. Ian Foster [Foster 2002] aponta uma lista de três requisitos que devem ser satisfeitos simultaneamente para que um sistema distribuído seja considerado um grid. O primeiro é a ausência de gerenciamento central. Todo o gerenciamento em grid deve ser feito de forma distribuída, o que favorece a escalabilidade e a tolerância a falhas. O segundo é o fornecimento de qualidade de serviço (QoS - quality of service). Por último, um grid deve fazer uso de protocolos abertos e padronizados para facilitar a interoperabilidade. Para atender esses requisitos é necessário definir e implementar um middleware. Múltiplos Clusters - Nem todos os centros de pesquisa e instituições em geral, que possuem múltiplos clusters, aderem ao cenário de grids para aumentar o seu potencial de processamento, armazenamento, etc. Não é raro que em uma mesma instituição existam

4 vários clusters que possuem seu funcionamento completamente isolado um do outro. Esta situação geralmente acontece, porque na maioria das vezes esses clusters são adquiridos em diferentes pontos do tempo. Existem trabalhos no sentido de integrar os diferentes clusters como se eles formassem uma única máquina, o que se chamou de sistemas multiclusters [Barreto et al. 2000]. Multiclusters podem ser encarados sob a visão dos usuários que utilizam os recursos ou sob a visão do administrador desses clusters. No caso dos usuários, a idéia de multicluster faz com que seja necessária a criação de ferramentas que proporcionem o suporte para a comunicação entre os diferentes clusters de forma transparente. No caso de gerenciamento de múltiplos clusters, não é preciso a existência dessa infra-estrutura de comunicação. Basta que se tenha acesso aos diferentes clusters e que as operações realizadas nos diferentes clusters sejam o mais uniformes possível. Arquitetura orientada a serviço - Mais conhecida por seu acrônimo SOA, derivado do inglês service-oriented architecture, é uma forma de oferecer suporte a serviços de tecnologia de informação [Jones 2005]. Um serviço é uma implementação auto-contida de uma função com uma interface bem definida. Um aspecto importante dessa definição é a clara separação entre a interface e a implementação de um serviço. Isto é uma característica desejável quando se busca interoperabilidade, transparência de localização e fraco acoplamento entre consumidores e provedores de serviços. A comunicação entre eles é feita através de troca de mensagens. Na verdade, SOA é um modelo que não impõem nenhum tipo de tecnologia para sua implementação. Atualmente, a tecnologia Web service é a mais utilizada para implementar sistemas baseados em SOA. A vantagem de utilizar Web services está principalmente na força dos padrões que os regem Organização Para compreender as vantagens da tecnologia Web service em HPC é preciso primeiramente saber exatamente como ela funciona, quais seus componentes e pontencialidades. Esta descrição é realizada na seção 2. A contextualização de onde se utiliza Web services em sistemas HPC é apresentada na seção 3, onde serão abordadas especificações como por exemplo OGSA e WSRF que são os pilares de middlewares para grids. Na seção 4, são descritos dois estudos de casos de sistemas HPC que empregam a tecnologia de Web services. O primeiro deles é o Globus Toolkit 4 (GT4), empregado como padrão de facto no contexto de grids. O segundo é um ambiente voltado para o cenário de multiplos clusters, Integrated Cluster Environment (ICE) [Marquezan et al. 2006], desenvolvido pelo Grupo de Processamento Paralelo e Distribuído (GPPD) do Instituto de Informática da UFRGS, dentro do projeto FINEP Java-WSPAD. Por fim, na seção 5, conclúi-se com um breve resumo e com as tendências atuais do uso de Web services para implementação de middlewares de sistemas HPC. 2. Web services: conceitos, protocolos e uso O desenvolvimento de sistemas capazes de conversar entre si e com outros sistemas sempre foi um desafio para a computação. Tecnologias como CORBA, DCOM, Remote Method Invocation (RMI), etc., foram propostas para tentar prover essa funcionalidade. No entanto, a almejada interoperabilidade dos sistemas não foi alcançada de fato. Devido às restrições dessas tecnologias elas só são capazes de conversar naturalmente entre si, sendo o processo de conversão de objetos entre elas muito oneroso. Com o surgimento de XML (extended Markup Language) tornou-se possível a utilização de um formato padrão

5 para troca de informações, independente de plataforma e de linguagem. A popularização do XML e suas características abriram oportunidade para o desenvolvimento de padrões capazes de transportar informações entre as diferentes plataformas. A Microsoft juntamente com a UserLand iniciaram as pesquisas nesta área, sendo seguidos por outras empresas como HP, IBM, Sun Microsystems, etc. O resultado das pesquisas no desenvolvimento de protocolos baseados em XML foi a especificação do XML-RPC (baseado em XML e HTTP) e SOAP (baseado em XML e diversos protocolos de comunicação). Esta evolução dos formatos de representação das informações e de protocolos de comunicação serviram como ponto de partida para a especificação de Web services (WS). Analisados de forma simples, Web services são mais uma tecnologia para a tão sonhada integração de sistemas. No entanto, o ponto que os diferencia é a forma como são construídos, pois utilizam de padrões da Internet e independentes de plataforma. Esta característica confere aos Web services o potencial de interoperabilidade que nenhuma outra tecnologia até hoje proposta conseguiu atingir. Alguns dos principais aspectos que definem um Web service são: serem construídos sobre XML; serem orientados a mensagens; em sua essência são distribuídos; possuem baixo índice de acoplamento; são baseados em componentes; são stateless; podem ser localizados dinamicamente. Existem várias interpretações incorretas para o que exatamente são Web services. Werner Vogels em [Vogels 2003] apresenta os conceitos incorretos mais comuns sobre Web services. Dentre eles, pode-se destacar a confusão feita entre essa tecnologia e outras relacionadas com objetos distribuídos, como por exemplo CORBA e DCOM. Web services não são objetos distribuídos, isto é, não é realizada nenhuma invocação remota de métodos, não existem referências para objetos, não existe uma estrutura de garbage collection, etc. Eles lidam apenas com documentos XML e o encapsulamento de documentos. Normalmente, Web services também são definidos como chamadas de procedimentos remotos (RPC - Remote Procedure Call). Essa afirmação também não está correta. Através de interações que simulam o comportamento RPC é possível fazer com que um Web service se comporte como tal, mas isto requer um conjunto de regras fixas que definem a forma de codificação dos documentos XML dos elementos que estão emulando esse tipo de funcionamento. Enfim, em sua essência eles lidam com a manipulação de documentos XML, os quais descrevem informações que serão utilizadas pelos provedores de serviços e pelos seus consumidores. Web services baseam-se em uma arquitetura SOA. Neste tipo de arquitetura existem os seguintes componentes: consumidor do serviço, provedor de serviços e registro de serviços, os quais são ilustrados na Figura 1. Apesar de possuir três componentes, é possível a criação e utilização de Web services bem simples, que não necessitam a descrição do serviço, publicação e descoberta [Jones 2005]. Eles são formados apenas pelos consumidores e os provedores. A seguir são descritos cada um dos elementos da arquitetura Web service e seus relacionamentos. O Provedor de Serviços é o componente responsável pela criação de um Web service. É tarefa do provedor de serviço a descrição, de forma padronizada, de cada serviço criado e a sua disponibilização em registros centralizados e públicos. Estas tarefas garantem que um Web service será compreendido por qualquer instituição que deseje utilizá-lo, e que essa instituição poderá encontrá-lo através de mecanismos de procura de Web services.

6 Figura 1. Arquitetura Web service O Consumidor de Serviços representa a entidade que vai utilizar um Web service criado por um provedor de serviços. É importante ressaltar que um consumidor de serviços é capaz de obter as informações necessárias para a vinculação a um serviço a partir da descrição realizada pelo provedor desse serviço. Para tanto ele realiza uma consulta em um registro que contém essas informações. O Registro de Serviços é a entidade com a qual tanto o provedor de serviços, como o consumidor de serviços interagem. Os provedores de serviços publicam seus serviços neste repositório para que os consumidores consigam encontrá-los e vincularemse a eles. O registro de serviços é essencialmente um repositório baseado em XML. O registro provê dois tipos de APIs: Inquiry API e Publish API. Inicialmente a tecnologia Web service foi explorada na troca de informações entre empresas através da Internet. Entretanto suas características e, principalmente, sua capacidade de interoperabilidade fizeram com que, rapidamente (cerca de 4 anos), eles começassem a ser utilizados em diversos contextos da computação, como por exemplo: gerenciamento de redes [de Lima et al. 2006], [Alexopoulos and Soldatos 2005], banco de dados [Brambilla et al. 2005], computação ubíquoa [Issarny et al. 2005] e sistemas de alto desempenho [Huang et al. 2006], [Foster et al. 2005a]. A palavra chave da tecnologia Web service é interoperabilidade, e seu escopo de aplicação abrange todos os sistemas que necessitam desta característica. A seguir são detalhadas as questões técnicas relacionadas a Web services, como por exemplo, os padrões utilizados para construção de tais serviços, a descrição de algumas especificações e drafts ligados a Web services, assim como a composição de serviços de mais alto nível através de metodologias de coreografia e orquestração de Web services mais primitivos. Essas questões técnicas ligadas a Web services serão posteriormente verificadas nos cenários de alto desempenho que serão descritos nas seções 3 e Tecnologias Padrão em Web services: SOAP, WSDL e UDDI No intuito de melhor compreender de como Web services são formados as tecnologias SOAP, WSDL e UDDI serão apresentadas a seguir. Essas tecnologias são os padrões de facto para criação de Web services [Curbera et al. 2002].

7 SOAP - Simple Object Access Protocol O SOAP é um protocolo baseado em XML, voltado para a troca de informação entre diferentes pontos inseridos em um ambiente distribuído. O protocolo SOAP pode ser utilizado em uma grande variedade de sistemas de mensagens e pode ser transmitido por diversos protocolos. Com o apoio tanto dos detentores das diversas plataformas fechadas, como da comunidade open-source, o protocolo SOAP 1.1 foi essencial para o início do processo de desenvolvimento dos Web services. Sendo que, em meados de 2001, várias empresas começavam a realmente obter interoperabilidade entre suas aplicações. Atualmente o protocolo SOAP está na versão SOAP 1.2 [Mitra 2003], e ela define a informação baseada em XML que pode ser usada para troca de informações estruturadas e tipadas entre ambientes descentralizados e distribuídos. SOAP é basicamente um protocolo stateless, que possui o paradigma de troca de mensagens baseado em one-way. Isto é, as mensagens transmitidas através do protocolo SOAP não são requisições que necessitam respostas. Elas são simplesmente mensagens que contém dados a serem enviados a um receptor. Entretanto, o SOAP possibilita a construção de padrões de interações complexos, como por exemplo requisição/resposta, ou requisição/múltiplas-respostas. A especificação SOAP define 3 grandes partes, descritas a seguir. Especificação do envelope SOAP - Define regras específicas para o encapsulamento dos dados que serão transmitidos. Isto inclui dados específicos de aplicações, tais como nome de operações, parâmetros ou valores de retorno. Além disso, é possível inserir informações de quem é o responsável por processar as informações contidas no envelope, e no caso da ocorrência de erros é possível determinar como as mensagens de erro serão codificadas. Regras de codificação de dados - Para a troca de dados é preciso que as máquinas envolvidas estejam de acordo com a regra que será utilizada para codificar tipos de dados específicos. Devido a essa necessidade, SOAP possui seu próprio conjunto convenções para codificação de tipos de dados. Grande parte dessas convenções são baseadas na especificação XML Schema da W3C. Convenções para RPC - É a definição de um sistema simples de mensagens para representar, a partir de mensagens one-way, os mecanismos de requisição/resposta. Isso permite que a aplicação de um cliente especifique o nome de um procedimento remoto, seus parâmetros e receba a resposta da aplicação servidora. Essa definição foi denominada SOAP-RPC (SOAP Remote Procedure Call). Uma mensagem SOAP possui uma estrutura simples, contendo basicamente os seguintes componentes: envelope, cabeçalho e corpo (como apresentado na Figura 2). O envelope é o elemento obrigatório de uma mensagem SOAP, que designa o escopo da mensagem através da definição da versão utilizada. Ao contrário do que ocorre em HTML e XML, a versão em SOAP é definida pelo espaço de nomes utilizado. Sendo ele o responsável por especificar os elementos e os atributos SOAP. O cabeçalho é um componente opcional, podendo haver mais de um cabeçalho em uma mesma mensagem SOAP (Figura 2). Esse componente é definido no esquema do envelope SOAP. Ele proporciona uma solução flexível para a inserção de metadados relacionados à mensagem SOAP ou a inserção de novas extensões na especificação básica do SOAP. Os metadados são informações de como a mensagem SOAP deve ser proces-

8 Figura 2. Estrutura da Mensagem SOAP sada, ou informações que qualificam ou não o processador SOAP para executá-las. Um exemplo de utilização de cabeçalhos em mensagens SOAP é a utilização de metadados relacionados a timestamp, prioridade ou o destinatário da mensagem. A inserção de um cabeçalho não pode comprometer a capacidade de processamento da mensagem SOAP, isto é, se um nodo SOAP não é capaz de entender o conteúdo de um cabeçalho ele deverá continuar processando a mensagem. Entretanto, pode-se forçar os processadores SOAP a interpretar o conteúdo de um cabeçalho. Neste caso se um nodo não compreender seu conteúdo ele irá parar o processamento da mensagem. No exemplo de cabeçalho da Figura 2, inseriu-se a informação de timestamp da mensagem enviada, sendo o elemento sinc um metadado referente à informação de sincronização. Imaginando o caso de uma troca de mensagem de sincronização em um cluster, é interessante que o nodo que recebeu essa informação processe o cabeçalho a fim de saber se os nodos estão realmente sincronizados. O corpo de uma mensagem SOAP é quem realmente possui o conteúdo que deverá ser processado no receptor SOAP apropriado. Ele é um elemento obrigatório em qualquer mensagem. Devido à flexibilidade do protocolo SOAP, o corpo da mensagem pode servir para diversos propósitos. Por exemplo pode servir para transmissão de documentos XML ou então para a chamada de um procedimento remoto, através das convenções SOAP- RPC. Em uma mensagem podem existir mais de um corpo, assim como podem existir vários cabeçalhos. Entretanto, o funcionamento dessas múltiplas entradas do corpo SOAP é diferenciado. A primeira entrada é a que realmente contém o RPC ou o documento XML literal, as outras entradas possuirão referências que dão suporte para a primeira entrada. No exemplo da Figura 2 é apresentado o corpo de uma mensagem SOAP utilizando

9 document-style messaging [Mitra 2003] para a transmissão de um documento XML. Imaginando uma ferramenta de gerenciamento de cluster que apresente as informações relativas a carga de cada um dos nodos, tem-se nesse exemplo o corpo SOAP formado pelas informações que dizem respeito aos processos que estão executando em um determinado nodo do cluster WSDL - Web Services Description Language WSDL provê um modelo e um formato XML para descrever Web services. Essa tecnologia permite que exista uma separação na descrição de funcionalidades abstratas oferecidas por um serviço dos detalhes concretos da descrição do mesmo, como por exemplo de que forma e onde as funcionalidades do serviço são oferecidas. Atualmente, existem duas versões: WSDL 1.1 [Christensen et al. 2001] que é amplamente utilizada e a WSDL 2.0 [Chinnici et al. 2006] recentemente liberada pela W3C. A recomendação WSDL descreve 3 componentes básicos de Web services: Tipos de dados- Para atingir o nível de abstração requerido em WSDL, é preciso que o documento WSDL inclua um container abstrato para o armazenamento das definições dos tipos de dados utilizados dentro do Web service. Na grande maioria dos casos, esses containers incluem uma instância de um documento XML Schema. Da mesma forma que as entradas do corpo de uma mensagem SOAP podem ser definidas em nível de aplicação utilizando espaço de nomes, WSDL também provê o mesmo mecanismo de separação para especificar a linguagem em que os tipos de dados estão definidos. Operações - Cada operação WSDL descreve uma interface abstrata para o comportamento ou ação oferecida por um Web service. Dentro de cada operação WSDL pode-se especificar parâmetros de entrada e saída, além de correlacioná-los com os tipos de dados definidos dentro do documento WSDL. Protocolos de Ligação - WSDL descreve os protocolos das camadas inferiores. WSDL não ignora os protocolos que estão abaixo dele, nem considera que somente um tipo de tecnologia é utilizada nessas camadas inferiores. Ele permite que esses protocolos sejam especificados. Esta flexibilidade permite que desenvolvedores, ou outro software que utilize as descrições WSDL, possam prover diferentes protocolos de ligação concretos para as operações abstratas definidas em WSDL. A Figura 3 apresenta a estrutura de um documento WSDL. Para compreender o processo de descrição de um Web service através de WSDL, é apresentado, na Figura 3, um exemplo da descrição de um serviço com estilo SOAP-RPC responsável pela instalação de novas imagens do sistema operacional nos nodos de clusters. Será considerado o uso do protocolo SOAP. Devido ao fato das mensagens SOAP utilizarem os tipos de dados simples não foi necessária a utilização do elemento type no documento WSDL. Os documentos WSDL utilizam um conjunto de definições conhecidas para descrever um serviço, as quais são dividas em dois grupos: concretas e abstratas. As definições concretas são formadas por elementos que definem as especificidades de como acessar, através da rede, as funcionalidades que estão sendo descritas. Ou seja, definem a URL, o tipo de protocolo (por exemplo SOAP ou XML-RPC) e protocolos de camadas inferiores (por exemplo, HTTP ou SMTP). Existem 3 principais elementos nas definições

10 Figura 3. Exemplo de WSDL concretas: (i) service, especifica os terminais de um Web service; (ii) port, especifica o endereço de um terminal e o elemento de ligação para ser usado com o endereço (o conceito de porta utilizado em WSDL não é o mesmo conceito utilizado em TCP/IP); e (iii) binding especifica um protocolo de transporte e o formato dos dados para as operações e mensagens abstratas definidas para um tipo de porta abstrata. As definições abstratas são formadas por elementos que correspondem às típicas documentações de API. Esses elementos são: (i) porttype, constitui uma coleção de operações que compõem o Web service, atuando como se fosse uma API para esse serviço; (ii) message é responsável por agrupar os parâmetros de uma mensagem, seja ela one-way, ou uma requisição, ou uma resposta; (iii) part, define o tipo de dado de cada parâmetro da mensagem, utilizando os tipos de dados pertencentes a esquemas prédefinidos (esquemas padrão do XML, WSDL, tipos de ligação SOAP, HTTP ou MIME) ou então os definidos pelos usuários e especificados dentro do documento WSDL; (iv) type, descreve todos os tipos de dados utilizados no documento WSDL. Para fazer a ligação entre esses dois grupos existe uma terceira definição, denominada operation, cuja função é fazer o mapeamento das definições abstratas para as definições concretas. Sob a perspectiva abstrata, o elemento operation define os métodos de um Web service. Isto significa que para cada método de um serviço existirá uma operação associada. Sob a perspectiva concreta as operações definem quais os pro-

11 tocolos que serão utilizados nas camadas inferiores. As operações também descrevem o comportamento que o método de um Web service pode assumir na rede, no que diz respeito a forma como esse método recebe e envia dados UDDI - Universal Description Discovery and Integration UDDI é uma especificação técnica para descrição, descoberta e integração de Web services. Essa tecnologia permite que instituições publiquem e encontrem Web services Em sua essência, UDDI é composto por 2 partes. A primeira parte diz respeito à especificação técnica para a construção de um diretório distribuído de negócios e Web services, onde os dados são armazenados em um formato XML específico e a especificação UDDI inclui APIs detalhadas para a busca de dados cadastrados e para a distribuição de novos dados. A segunda parte consiste no Registro de Negócios UDDI (UDDI Business Registry), uma implementação completamente operacional da especificação UDDI. Em UDDI, as informações descritas são geralmente divididas em 3 categorias principais, apresentadas a seguir. White Pages (Páginas Brancas) - Essa categoria contém informações referentes a: nomes e endereços de negócios, informação para contato, nome do Web site, DUNS (Data Universal Numbering System) ou algum outro número de identificação; Yellow Pages (Páginas Amarelas) - Contém informações relacionadas ao tipo de negócio, localização e produtos; Green Pages (Páginas Verdes) - Essa categoria contém informações técnicas sobre os Web services. Geralmente, isso inclui um ponteiro para uma especificação externa e um endereço para a invocação do Web service. UDDI não está restrito a descrever Web services em SOAP. Pelo contrário, ele pode ser usado para descrever qualquer tipo de serviço, como por exemplo serviços CORBA e Java RMI. A tecnologia UDDI utiliza os próprios padrões empregados em Web services (SOAP e WSDL) para cumprir com suas funcionalidades de registro e disponibilização de serviços. Sendo que esta característica garante sua universalidade Especificações WS-* O avanço no interesse da utilização de Web services, principalmente por empresas como por exemplo Microsoft, IBM, Bea Systems, IONA Systems, e também por organizações como W3C, OASIS e DMTF, entre outras, fez com que diversas especificações baseadas em Web service surgissem para melhorar as interações entre as aplicações, e em última instância entre as organizações. Algumas dessas especificações são apresentadas a seguir. WS-Reliability/WS-ReliableMessaging - É um padrão da OASIS [Iwasa et al. 2004] que especifica um protocolo baseado em SOAP para a troca de mensagens com garantia de entrega, sem duplicação e garantia da ordem da entrega das mensagens. Esse padrão é definido no header do envelope SOAP, o que o torna independente dos protocolos das camadas inferiores. WS-Security (WSS) - Padrão da OASIS [Lawrence et al. 2006] que descreve melhoramentos nas trocas de mensagens SOAP com o objetivo de prover integridade e confidencialidade para as mensagens.

12 WS-ResourceFramework (WSRF) - Draft da OASIS [Banks 2006] cujo objetivo é a definição de um framework genérico para a modelagem e acesso persistente a recursos utilizando Web services. Através desse framework a definição e implementação de um serviço e seu gerenciamento e integração a outros serviços pode ser feito de forma mais fácil. Um de suas características explorada em sistemas HPC é a capacidade de tornar Web services stateful. WS-Coordination - Também referenciada como WS-Coordination Framework (WS- CF) ou WS-Coordination Application Framework (WS-CAF), é um draft da OA- SIS [Little et al. 2005]. A principal característica dessa especificação é a capacidade de registrar um Web service como um participante de uma determinada função que está sendo executada em um determinado contexto, fazendo com que os Web services de mais baixo nível possam ser coordenados/compostos para prover serviços de mais alto nível. WS-BusinessActivity - Especificação da OASIS [Newcomer et al. 2006] que define o tipo de composição de atividades de negócios. Deve ser utilizada juntamente com a especificação WS-Coordination. WS-Notification (WSN) - Especificação da OASIS [Niblett and Graham 2005] que tenta padronizar a forma como os Web services interagem quando utilizam notificações e eventos. Junto a ela, foram definidas outras especificações: WS- Topics, WS-Base Notification, WS-Brokered Notification e WS-Notification Policy. WS-Eventing - Em paralelo ao trabalho realizado pela OASIS, a W3C também está desenvolvendo a especificação WS-Eventing [Box et al. 2006] para lidar com interações de notificações e eventos entre Web services. WS-Addressing - Especificação submetida à W3C [Box et al. 2004] pelas empresas como BEA Systems, IBM, Microsoft, SAP e SUN. O WS-Addressing define mecanismos para endereçamento de Web services e de mensagens. O objetivo é a construção de uma camada de informação inferior padronizada que possa ser processada independentemente do meio de transporte e da aplicação. WS-Attachments - Draft da W3C [Nielsen and Ruellan 2002] que especifica as bases para a criação de bindings SOAP que transmitem anexos dentro do envelope da SOAP, e provê as referências para estes anexos. WS-Enumeration - Especificação submetida por empresas para a W3C [Alexander et al. 2006] que descreve um protocolo SOAP genérico para enumeração de seqüências de elementos XML, os quais são indicados para transferência de logs, filas de mensagens e outros tipos de informações lineares. WS-Management - Padrão estabelecido pelo DMTF (Distributed Management Task Force) [DMTF 2006]. O objetivo dessa especificação é promover a interoperabilidade entre aplicações de gerenciamento e recursos gerenciados. Esse objetivo é atingido através da identificação de um conjunto básico de Web services e dos requerimentos de uso dentre todos os sistemas de gerenciamento. De posse dessas informações, torna-se possível disponibilizar um conjunto de operações que são centrais para o sistema de gerenciamento como um todo. WS-Distributed Management (WSDM) - Padrão da OASIS [OASIS 2006] que permite o gerenciamento de aplicações construídas utilizando Web services. A versão do WSDM 1.1 utiliza as especificações WS-Addressing, WS-Resource Framework e WS-Notifications. Os trabalhos da OASIS estão sendo feitos em paralelo aos trabalhos do DMTF. A especificação WSDM é dividida em outras duas: MOWS

13 (Management of Web Services), que descreve formas de gerenciamento de Web services, e MUWS (Management Using Web Services), que descreve maneiras de gerenciamento de recursos em geral utilizando para tanto Web services. Existem especificações que ainda não estão sob a guarda de organizações como a OASIS ou W3C. Em geral, essas especificações são mantidas e incentivadas por empresas, como pro exemplo: Microsoft, IBM, BEA Systems, Sun Microsystems, entre outras, ou então por instituições de pesquisa. Algumas dessas especificações são: WS-Discovery [Beatty et al. 2005], WS-Federation [GroB; et al. 2005], WS-Policies [Anderson 2006], WS-Replication [Salas et al. 2006], etc. Muitas das especificações geradas pelas empresas e pela academia já estão sendo adotadas pelas plataformas utilizadas em computação de alto desempenho, principalmente naquelas relacionadas a grids. Na seção 4.1 pode-se verificar o emprego de algumas delas no toolkit Globus, o qual apresenta-se como uma referência para criação de infra-estruturas de grid Composição de Web services Com o avanço nas pesquisas relacionadas a Web services, e a crescente utilização dessa tecnologia, tornou-se evidente a capacidade que esses elementos apresentam para composição de serviços [Curbera et al. 2003]. Através de diferentes Web services básicos pode-se criar serviços de mais alto nível. Por exemplo, considerando-se um cenário de múltiplos clusters onde um usuário deseja lançar uma aplicação em diferentes cluster, a qual utiliza uma biblioteca paralela específica. Caso essa biblioteca não esteja instalada em todos os clusters, pode-se pensar na criação de um mecanismo de submissão de aplicações em múltiplos clusters que seja capaz de conversar com serviços de instalação automatizada de softwares, para em conjunto proverem a infra-estrutura solicitada pelo usuário. A composição de Web services abre um campo de desenvolvimento de novas aplicações bastante grande. Para dar um suporte melhor a este tipo de utilização de Web services, foram definidas especificações e padrões de composição. Basicamente existem duas maneiras de compor Web services: utilizando orquestração, ou então coreografia. A orquestração de Web services baseia-se na existência de um processo principal que coordena as interações entre os Web services, descrevendo como eles vão interagir e definindo a ordem de execução. Nesta abordagem, a composição é controlada sob a perspectiva de uma das partes envolvida. Uma especificação utilizada, hoje em dia, é Web Services Business Process Execution Language (WSBEL) [Arkin et al. 2004]. Na coreografia de Web services têm-se um paradigma mais colaborativo, sendo que cada parte envolvida no processo é capaz de descrever todos os momentos de suas interações. A especificação WS Choreography Description Language (WS-CDL) [Kavantzas et al. 2004] é um draft da W3C que define uma linguagem baseada em XML que descreve as colaborações ponto a ponto entre os integrantes do sistema. Através da composição de Web services pode-se atingir níveis de serviços mais sofisticados. No contexto de computação de alto desempenho, pode-se pensar na utilização de composição de serviços de mais baixo nível para poder oferecer aos usuários mais facilidade de desenvolvimento de aplicações, quem sabe unificando o modelo de programação em grid com o modelo Service-oriented computing (SoC) [Bichler and Lin 2006].

14 3. Web Services Aplicado a Computação de Alto Desempenho Como apresentado na seção 1, neste trabalho são considerados como sistemas de alto desempenho clusters, grids e múltiplos clusters. Web services, como caracterizados na seção 2, têm como principal característica lidar com a interoperação entre sistemas heteregêneos. Partindo desse ponto, pode-se dizer que a utilização de Web services em clusters não é muito natural e justificável. Em geral, este tipo de sistema HPC possui um conjunto fechado de ferramentas que não necessitam de interoperabilidade, são restritos a um domínio administrativo, não existe uma heterogeneidade no software utilizado dentro de um cluster que justifique a utilização de mecanismos que promovam a transparência. Em contrapartida, ambientes de grids são um terreno fértil para a utilização de Web services, pois, em geral, os grids são constituídos por recursos pertencentes a diferentes instituições com diferentes domínios administrativos, ferramentas, plataformas, etc. Esses recursos devem ser disponibilizados de alguma forma para os usuários desse grid. Além disso, é preciso a descoberta dos serviços providos e de quais são as suas características (interface), assim como a geração automática de códigos consumidores a partir das descrições descobertas. Tudo isso deve ser feito considerando um ambiente extremamente heterogêneo e distribuído. A interoperabilidade torna-se praticamente obrigatória, e uma forma de atingí-la é ser compatível com padrões abertos e bem aceitos. Web service atende todos estes requisitos e, desta forma, apresenta-se como uma tecnologia altamente indicada para ser utilizada no cenário de grids. Sendo que esta tendência é verificada na prática, visto que existe um volume muito grande de pesquisas e uma quantidade considerável de especificações que têm surgido, e que servem para aproximar a tecnologia Web service de grids. Ainda existe a possibilidade de utilização desta tecnologia no contexto de múltiplos clusters. De certa forma, é possível considerar este contexto como uma simplificação do cenário de grid, pois em comum eles apresentam a heterogeneidade e a necessidade de prover mecanismos de transparência e interoperabilidade para seus usuários e aplicações finais. Entretanto, em múltiplos clusters, não existe a necessidade de localização de recursos, qualidade de serviço, entre outras características de grid que acarretam uma carga de controle bastante grande. A vantagem de utilizar Web services em múltiplos clusters está na uniformização das operações realizadas nos clusters e na abstração das especificidades das ferramentas instaladas nos diferentes clusters. A maior parte dos trabalhos de pesquisas de utilização de Web services em sistemas HPC concentram-se no escopo de grids, onde eles são realmente necessários. Tendo em vista esta realidade, esta seção vai mostrar quais as iniciativas de utilização de Web services em grids, apresentando elementos como por exemplo: OGSA, OGSI e WSRF Web Services e Grids O problema real e específico que está por trás do conceito de grid é o compartilhamento coordenado de recursos e resolução de problemas em organizações virtuais dinâmicas multi-institucionais [Foster et al. 2001]. Para entender esse problema é necessário compreender a noção de entidade, comunidade ou organização, da computação em grid. As organizações são compostas por usuários e recursos, e podem ser físicas ou virtuais. Uma organização física é um domínio administrativo que pode ser uma universidade, uma empresa, um órgão do governo, ou até mesmo uma residência. Uma organização virtual é

15 um conjunto de usuários e recursos, construída sobre uma coleção de integrantes de diferentes organizações físicas e controlada por regras de compartilhamento. Os usuários, os recursos e as regras podem mudar a qualquer momento e, por isso, uma organização virtual é dita dinâmica e multi-institucional. O compartilhamento pode significar acesso direto a computadores, software, arquivos, dados, entre outros, conforme for necessário por resoluções colaborativas de problemas e estratégias de outsourcing (terceirização). Nos últimos anos, a base para arquitetura de grids, e para seus padrões, têm sido a adoção de um modelo orientado a serviços, utilizando para tanto a tecnologia Web service. Considerando isso, Ian Foster [Foster et al. 2002] propõem o Open Grid Services Architecture (OGSA), uma arquitetura que descreve como os mecanismos de um grid podem ser implementados usando uma arquitetura SOA. O objetivo é integrar as tecnologias de grid com os mecanismos de Web services existentes. Nesta arquitetura foi introduzida a noção de grid services (serviços de grid), os quais são Web services que implementam um determinado conjunto de interfaces padronizadas para resolver os problemas inerentes à computação em grid. Tais serviços são definidos pela especificação Open Grid Services Infrastructure (OGSI) [Tuecke et al. 2003]. Com a evolução da tecnologia Web services, a especificação OGSI (dentro da arquitetura OGSA) está sendo substituída pela especificação Web Services Resource Framework (WSRF), fato este que marca a convergência das pesquisas em grid e em Web services [Foster et al. 2005a]. A seguir, esses elementos serão apresentados com maiores detalhes OGSA e OGSI As especificação OGSA e OGSI foram, originalmente, definidas pela organização Global Grid Forum (GGF). Atualmente, são mantidas pela organização Open Grid Forum (OGF), a qual é resultante da fusão das organizações Enterprise Grid Alliance (EGA) e GGF. De acordo com Ian Foster et. al [Foster et al. 2005b], o foco da arquitetura OGSA é prover: gerenciamento de informações, gerenciamento de SLA (Service Level Agreement), framework de segurança, uma interface unificada, gerenciamento de execução, framework de otimização, monitoramento e análise, gerenciamento de recursos. De forma geral, pode-se dizer que a arquitetura OGSA está dividida em quatro camadas: aplicação, OGSA, OGSI e Web services [Coulouris et al. 2005] (Figura 4). A camada de aplicação representa as aplicações do usuário, que são grid services para aplicações específicas. A camada OGSA é a responsável por um serviço de segurança, um serviço de gerenciamento e monitoramento de recursos e um serviço de diretório. O serviço de segurança da OGSA trata de problemas como autenticação, autorização, criptografia de dados, single sign-on e delegação de credenciais. O serviço de gerenciamento e monitoramento de recursos cuida da submissão de tarefas, das consultas a estados de serviços, do gerenciamento de falhas, do controle de tempo de vida dos serviços e de questões de qualidade de serviço, (Quality of Service - QoS) como reserva de recursos. O serviço de diretório permite a descoberta de grid services com base em suas características. A camada OGSI é a infra-estrutura de serviços básicos que podem ser utilizados pela camada superior, OGSA. OGSI (versão 1.0) é uma especificação que define um conjunto de convenções e extensões para o uso de WSDL e esquemas XML para possibilitar o uso de Web services stateful. Mais detalhadamente, fazem parte da especificação OGSI: um conjunto de extensões WSDL, algumas das quais são análogas as suportadas

16 Figura 4. Open Grid Services Architecture no WSDL versão 2.0; construções WSDL e operações padronizadas para representação, consulta, e atualização de service data (metadados e estado dos dados) de um serviço; construção de Grid Service Handle e Grid Service Reference usados para o endereçamento de grid services; definição de informações de falhas comuns pertencentes a operações, estas definições compreendem a especificação de um esquema XML básico e a associação de semânticas para as mensagens de falhas WSDL, fazendo com que a interpretação dessas falhas seja comum a todas as operações; essa abordagem define um formato básico para as mensagens de falha sem modificar o modelo WSDL de mensagens de falha; conjunto de operações para criação e destruição de grid services que provê mecanismos de destruição explícitos e implícitos (gargabe collection); conjunto de operações para a criação e uso de coleções de Web services heterogêneos; mecanismos para requisição de notificações assíncronas das alterações nos valores dos elementos relacionados com service data. Segundo Ian Foster et. al [Foster et al. 2005a], a evolução das especificações Web services, como por exemplo, WS-Addressing, WS-Notifications, e o próprio WSRF, fizeram com que a comunidade Web service começasse a questionar a especificação OGSI, sendo destacados os pontos descritos a seguir. Muitos elementos em uma única especificação - OGSI não possui uma separação clara entre as definições que permita sua adoção incremental. Por exemplo, eventos de notificação são úteis independentemente de serem atrelados ao conceito de service data. A utilização de metadados é um conceito útil que não precisa ser expressa através de service data. As especificações WSRF e WS-Notifications solucionaram essas críticas através do particionamento da OGSI 1.0 em diversas outras especificações, as quais permitem uma maior flexibilidade no seu uso. Apresenta problemas de compatibilidade com as ferramentas de Web services e XML - OGSI 1.0 faz um uso muito intensivo de especificações XML não utilizadas largamente. Em contrapartida, a especificação WSRF faz o uso de esquemas XML padronizados e que são conhecidos pelo desenvolvedores, e pelas

17 ferramentas existentes. Ao invés de estender a definição do elemento porttype do WSDL 1.1, a especificação WSRF define meios de fazer anotações nesse elemento para associar o modelo de informações XML dos recursos às operações Web services. Este procedimento é uma forma de construção legal dentro da linguagem WSDL 1.1. Possui enfoque muito orientação a objetos - A especificação OGSI 1.0 modela um recurso stateful como um Web service que encapsula o estado do recurso juntamente com a identidade e as informações de tempo de vida do recurso. Isto causa confusões, pois Web services não guardam estados e não possuem instâncias. Além disso, existem implementações de Web services que não suportam a criação e destruição dinâmica de serviços. Para resolver este problema, a WSRF redefiniu as camadas OGSI, para prover clara distinção entre serviço e as entidades stateful que operam sobre esse serviço. Na WSRF essas entidades são chamadas de WS-Resources e também foram formalizados os relacionamentos entre Web services e os recursos stateful através do uso convencionado da especificação WS- Addressing. Pressão para uso das capacidades da WSDL 2.0 sem prover extensões na WSDL Os autores da OGSI 1.0 utilizaram construções do draft WSDL 2.0. No entanto, atrasos na publicação dessa especificação fizeram com que se tornasse difícil a utilização da OGSI devido a falta de compatibilidade entre as ferramentas e ambientes de execução de Web services existentes. 1 Tendo em vista o cenário de evolução das especificações Web services e as dificuldades de utilização práticas da especificação OGSI 1.0, surgiram cada vez mais pesquisas que promoveram a convergência de Web services e especificações de grid. Atualmente, os grid services definidos na arquitetura OGSA não se baseiam mais na especificação OGSI, mas sim a WSRF, a qual será apresentada a seguir WS-Resource Framework - WSRF A especificação WSRF está ligada a criação, endereçamento, inspeção e gerenciamento do tempo de vida de recursos stateful. Este framework provês mecanismos para expressar estados e recursos stateful e codifica o relacionamento entre Web services e recursos stateful em termos de implied resource pattern, que representam um conjunto de convenções que utilizam tecnologias Web services, mais especificamente, XML, WSDL e WS-Addressing. Um recurso stateful que participa de um implied resource pattern é denominado como WS-Resource. De forma mais simplificada um WS-Resource pode ser definido como a junção de um Web service com um recurso [Sotomayor 2005]. O WSRF é composto por cinco especificações [Banks 2006], mas também está relacionado com outras duas especificações: WS-Notification e WS-Addressing. A seguir são descritas as especificações Web services que compõem o WSRF. WS-ResourceProperties - Estabelece como um WS-Resource pode ser associado à descrição de uma interface de um Web service, como serão as trocas de mensagens para recuperação, alteração e remoção das propriedades dos WS-Resources. WS-ResourceLifetime - Define os mecanismos para a destruição de WS-Resources, incluindo as trocas de mensagens que permitem a requisição da destruição imediata de recursos, ou através de mecanismos baseados em escalonamento de tempo. 1 A especificação WSDL 2.0 foi liberada somente em março de 2006.

18 WS-ResourcesRenewableReferences - Define um ponto de referência do WS- Addressing convencional, com informações relacionadas a políticas de atualização do ponto de referência quando este se tornar inválido. WS-ServiceGroup - Define uma interface para coleções heterogêneas de Web services. WS-BaseFaults - Especifica tipos básico de falha XML para ser utilizado no retorno de falhas entre as trocas de mensagens entre Web services. Como apontado por outros trabalhos [Humphrey et al. 2005b], [Humphrey et al. 2004] [Rodriguez et al. 2006], WSRF apresenta-se como uma especificação que veio para reestruturar a forma de especificação e implementação de grid services. Ele é encarado como a evolução da especificação OGSI. A Tabela 1 apresenta o mapeamento das estruturas de construção de grid services da OGSI para as estruturas da WSRF. OGSI Grid Service Reference Grid Service Handel Handle Resolver porttype Service Data definition Grid Service lifetime Notification portypes Factory porttype Service Group porttypes Base fault Type WSRF WS-Addressing endpoint reference WS-Addressing endpoint reference e WS-RenewableReferences WS-RenewableReferences WS-ResourceProperties WS-ResourceLifeCycle WS-Notification Tratado como patterns WS-ServiceGroup WS-BaseFaults Tabela 1. Mapeamento de construções OGSI para WSRF Segundo Ian Foster et. al [Foster et al. 2005a], o framework WSRF possui duas vantagens em relação a OGSI. A primeira está relacionada com a questão de padrões XML. De acordo com o autor, WSRF explora melhor do que a OGSI os padrões XML, e Web services, como por exemplo o WS-Addressing. Desta forma, torna-se mais fácil implementar o WSRF nas ferramentas e ambientes de execução de Web services que estão surgindo, e melhor utilizar os padrões que estão em constante desenvolvimento nesta tecnologia. A segunda vantagem diz respeito a questão de melhor entendimento de termos e construções ligadas a infra-estruturas de grids. A terminologia e a forma de construção dos elementos empregada na especificação OGSI causava desentendimentos em membros da comunidade de grid e de Web services, pois gerava uma noção errada de que para a implementação da especificação OGSI seria necessário fazer com que os Web services se tornassem estruturas mais onerosas. A adoção de WSRF faz com que fique mais claro que não é este o objetivo da utilização de Web services. O que se deseja é que eles sejam utilizados para permitir a manipulação de recursos stateful. Além das pesquisas citadas neste minicurso, existem várias outras que apontam outras vantagens da utilização de WSRF para implementação de grid services ao invés de utilizar OGSI. Além disso, esta transição já está sendo incorporada nos middlewares de grid, por exemplo, o Globus Toolkit versão 4 já possui sua implementação baseada em WSRF.

19 4. Estudos de caso Nesta seção serão apresentados dois estudos de caso sobre a utilização de Web services em ambientes de alto desempenho. O objetivo é identificar como essa tecnologia é utilizada nestes sistemas, e quais especificações e padrões de Web services eles já incorporaram. O primeiro estudo de caso apresenta o toolkit de grid Globus, e o segundo estudo de caso é o ambiente ICE, voltado para múltiplos clusters Caso 1: Grids - Globus O toolkit Globus vem sendo desenvolvido desde o final dos anos 90, tendo como organização que o gerencia o Globus Alliance. Com as pesquisas e o desenvolvimentos de padrões e especificações, que buscam resolver os problemas de sistemas distribuídos, como por exemplo, transparência, extensibilidade, interoperabilidade, etc, foram disponibilizadas 4 versões desse toolkit. A partir da versão 3 é que alguns dos conceitos definidos no OGSA passaram a fazer parte. Sendo que na versão 4 já encontram-se os conceitos e definições do OGSA e do WSRF. Segundo Borja Sotomayor [Sotomayor 2005] o Globus Toolkit v4 (GT4) não é uma implementação do OGSA. Ele possui a implementação de alguns dos serviços definidos no OGSA. Além disso, o GT4 possui a implementação completa do WSRF. A Figura 5 apresenta a estrutura sobre a qual são desenvolvidas aplicações para grids no GT4. Figura 5. Visão das camadas que compõem GT4 Para o desenvolvimento de aplicações de grid são necessários serviços de alto nível, capazes de abstrair toda a complexidade heterogeneidade existente neste cenário. O GT4 é uma infra-estrutura de grid que provê esse tipo de serviço de mais alto nível para os usuários. Como apresentado na Figura 5, os usuários definem suas aplicações utilizando apenas os serviços providos pelo GT4, sem saber sobre quais padrões ou mecanismos essa plataforma está implementada. Para que o GT4 seja capaz de prover os serviços de mais alto nível, é necessária a utilização de mecanismos que permitam que os serviços sejam stateful, ou seja, que o estado dos serviços seja armazenado de alguma forma. As definições de serviços OGSA precisam da existência de serviços stateful, no entanto, Web

20 services são por natureza stateless, ou seja, não guardam o estado dos serviços. Para conferir a capacidade de armazenamento de estados dos serviços existe a especificação WSRF. Como ilustrado na Figura 5, o GT4 está implementado utilizando as definições do OGSA e diretamente as definições WSRF, sendo que o OGSA está implementado sobre as especificações WSRF. No nível mais baixo existem as especificações ligadas diretamente a Web services. Entretanto, nem todo o GT4 está construído utilizando elementos baseados em Web services. Existem os componentes ditos non-ws, que são implementados sobre outros tipos de tecnologias, como apresentado na Figura 6. Figura 6. Módulos do GT4 [Ananthakrishnan et al. 2005] Dentre os serviços providos pelos módulos do GT4, existem aqueles que são de grande importância. O módulo GRAM (Grid Resource Application and Management) é composto por Web services que definem a inicialização, monitoramento e gerenciamento da execução de computações espalhadas em computadores remotos. Um exemplo prático de uso desse módulo é encontrado com o MPICH-G2, onde a biblioteca paralela utiliza os serviços do GRAM para ajudar no escalonamento de sub-tarefas entre os diversos computadores. Segundo Rachana Ananthakrishnan et. al [Ananthakrishnan et al. 2005] os serviços de notificação, baseados nos padrões WS-Notification e WSRF, permeiam todos os componentes do GT4. Como nem todos os componentes desse toolkit suportam estas especificações, também foram desenvolvidos agregadores (compositores) de serviços que podem ser utilizados para coletar informações de componentes WS como também de componentes non-ws. Esses agregadores estão nos módulos: Index, que implementa o registro de serviços; e o Trigger, que implementa um filtro de dados de eventos. O padrão WS-Security é utilizado nos módulo referentes a segurança do GT4. Atualmente o GT4 possui suporte para o desenvolvimento de serviços baseados nas linguagens Java, C e Phyton (pygridware). A Tabela 2 apresenta um resumo da comparação entre as implementações do GT4 realizada por Humphrey et. al

21 Figura 7. Módulos do GT4 [Foster 2006] [Humphrey et al. 2005a]. Como critério de comparação, foi considerada a capacidade que essas implementações (entre outras apresentadas no artigo) apresentam de prover as principais características das especificações Web services utilizadas no desenvolvimento de grid services no GT4. GT4-Java GT4-C GT4-Python WS-Security (Password profile) Sim Não Progredindo WS-Security (X.509 profile) Sim Progredindo Sim WS-SecureConversation Sim Não Progredindo Persistência de WS-Resources Sim Sim Sim WS-ResourceLifetime Sim Sim Sim WS-ResourceProperties Sim Sim Sim WS-ServiceGroup Sim Sim Sim WS-BaseFaults Sim Sim Sim WS-BaseNotification Sim Consumidor Sim WS-BrokeredNotification Parcial Não Não WS-Topics Parcial Parcial Parcial Tabela 2. Comparação entre implementações do GT4 No intuito de facilitar as atividades de desenvolvimento de novos serviços, baseados no GT4, foi definido um container de Web services desse toolkit [Foster 2006], o qual é apresentado na Figura 7. Através das classes desse container os usuários podem utilizar os serviços já disponibilizados pelo GT4 (Web Services WSRF GT4) ou então desenvolverem seus próprios serviços utilizando as especificações básicas de Web services (WSDL, SOAP e WS-Security, este último é indispensável em todos os serviços do GT4); ou então implementações de especificações mais especializadas (WS-Addressing, WS-Notification, WSRF) para disponibilizar e gerenciar informações sobre o estado dos serviços, de recursos e das atividades das aplicações. A possibilidade de desenvolvimento de serviços customizados e aplicações que utilizem serviços de mais alto nível no GT4 propicia o surgimento de novos modelos de aplicações para grids, onde a composição de serviços de mais baixo nível possa ser utilizada para prover serviços de mais alto nível. É possível que aplicações típicas de alto desempenho, como por exemplo, simulações climáticas, de solos, entre outras, não se

22 adaptem diretamente a esse novo modelo de computação em grid, assim como é possível que as bibliotecas de comunicação de alto desempenho tenham que prover esses mecanismos de abstração da infra-estrutura de serviços para seus usuários finais, fazendo com que estes continuem as utilizando com total transparência. É importante notar que também existe a questão de se garantir um bom desempenho na execução das aplicações, mesmo em um ambiente de grid. Para tanto, ainda são necessários estudos que revelem qual o impacto da abordagem de computação orientada serviços (SoC) nas aplicações. As pesquisas atuais indicam que este é um caminho que pode oferecer um alto grau de interoperabilidade entre as aplicações e organizações, alta distribuição de processamento e troca de informações. Entretanto é preciso um estudo mais detalhado sobre a questão de quais aplicações de alto desempenho podem realmente tirar proveito desta estrutura de serviços Caso 2: Múltiplos Clusters - ICE A heterogeneidade é a característica que permeia o ambiente de múltiplos clusters. Para gerenciar e acessar os recursos deste cenário, é preciso, primeiramente, lidar com as diferentes ferramentas instaladas em cada um do clusters. Esta heterogeneidade passa a ser uma dificuldade enfrentada por seus usuários, pois eles têm que aprender a lidar com cada uma dessas ferramentas para desempenharem suas atividades. Assim como no cenário de grids, Web services podem ser utilizados no cenário de múltiplos clusters para tratar a heterogeneidade, provendo transparência, interoperabilidade e independência de plataforma. Visando prover um ambiente de gerenciamento e acesso de múltiplos clusters baseado em Web services, foi definido e implementado o ambiente ICE - Integrated Cluster Environment [Marquezan et al. 2006]. A Figura 8 ilustra o cenário de múltiplos clusters considerado no desenvolvimento do ambiente ICE. Figura 8. Ambiente de utilização do ICE O ICE, até o momento, foi desenvolvido utilizando as funcionalidade mais básicas de Web services, ele não trata com registro e descobrimento de serviços dinamica-

23 mente. Essas informações são configuradas através do portal Web que serve como sistema de front-end do ambiente ICE. Como apresentado na Figura 8, foram desenvolvidos os provedores e consumidores de serviços voltados para o gerenciamento de clusters. Atualmente, o ambiente possui serviços de monitoramento de recursos, de submissão de aplicações e upload de arquivos. Através desses serviços é possível acessar diferentes tipos de ferramentas, como por exemplo: Ganglia [Sacerdoti et al. 2003] e Performance Co-Pilot [Silicon Graphics 2006], para monitoramento de recursos; e OpenPBS [NASA 2006], OAR[Capit et al. 2005] e SGE [Gentzsch 2001] para submissão de aplicações. A Figura 9 apresenta a interface Web para administração dos Web services disponibilizados, atualmente, no ambiente ICE. Nela é presentada a lista de serviços disponibilizados em três clusters: labtec, LCP e frontal-minuano. Figura 9. Portal ICE com a lista de Web services utilizados atualmente Através da adoção de Web services, pôde-se desenvolver um ambiente extensível, transparente e interoperável, o qual permite que seus usuários lidem com os recursos de múltiplos clusters em um nível de abstração mais alto. Em termos de especificações e padrões de Web services, o ambiente ICE utiliza aqueles disponibilizados e implementados no Apache Axis [Axis 2005], uma ferramenta de desenvolvimento de Web services. Essa ferramenta possui suporte para os padrões WS-Security, WS-Addressing (utilizado no desenvolvimento do ambiente ICE), WS-Attachment (utilizado para o serviço de upload de arquivos), WS-Reability, entre outros. Os próximos passos no desenvolvimento do ambiente ICE, são a incorporação de novos serviços de clusters, e empregar a composição de serviços. A experiência da utilização de Web services no cenário de múltiplos clusters mostrou-se interessante, visto que, mesmo sendo utilizado em um cenário bem mais controlado do que o contexto de grids, pôde-se tirar proveito das capacidades de abstração das camadas inferiores, da uniformização das operações e da transparência que a tecnologia Web service proporciona. Existem outros trabalhos no contexto de múltiplos clusters que apontam na direção do emprego desta tecnologia para construção de middlewares, como por exemplo a ferramenta HPC2N [Elmroth et al. 2005].