Autores: Chris Wroe, Carole Goble, Mark Greenwood, Phillip Lord Simon Miles, Juri Papay, Terry Payne, and Luc Moreau.
Publicado em: IEEE Intelligent Systems, Janeiro/Fevereiro 2004.
Vivemos em uma época onde a pesquisa feita com ajuda de computadores tem trazido agilidade e precisão nunca antes atingidas com experimentos em laboratórios. Entretanto, apesar da mudança do meio de experimentação, a metodologia científica continua a mesma. A partir de uma entrada inicial, os dados são tratados em vários estágios de processamento, gerando vários conjuntos intermediários antes do resultado final. Um caso típico é a bioinformática, onde experimentos precisam passar dados através de vários programas em seqüencia. Geralmente a saída de um processo não está formatada para servir de entrada para o processo seguinte. Nesse caso o cientista é responsável por realizar as transformações necessárias. Apesar de cansativa e com tendência a erros, tal manipulação pode ser útil na elaboração de hipóteses e avaliação de cenários diversos.
O conceito de workflow formaliza tentativas anteriores de representação de metodologias experimentais. Logo, um workflow seria uma conjunto de serviços que invocados em certa ordem realizam a computação esperada. Porém, essa definição tem problemas. Ela limita a portabilidade e escalabilidade, sendo suscetível a retirada ou modificação de qualquer um dos serviços componentes. O compartilhamento de workflows torna-se comprometido e descrições tão precisas podem também levar a concorrência por recursos quando mais de uma cópia de um workflow entra em execução no mesmo ambiente.
Ao abstrair o workflow, podemos construir modelos representando o tipo ou classe de serviço a ser invocado em cada estágio experimental, sem detalhar qual instância do serviço deve ser utilizada. Para usar um modelo, as representações abstratas dos serviços são instanciadas de acordo com os serviços reais disponíveis e o fluxo de dados é gerenciado para garantir a interoperabilidade entre os serviços.
Prática de e-science pode ser descrita como ciclo de vida do experimento. Inicialmente, há um objetivo geral de testar uma hipótese ou integrar novas descobertas com conhecimento existente. Antes e durante o experimento, o cientista deve tomar decisões sobre a granularidade de cada sub-tarefa no projeto do experimento, garantindo assim que cada tarefa não tem ambigüidades e seja realizável. As decisões envolvem decompor objetivos de alto nível em tarefas mais simples e escolher a classe de serviço mais apropriada para completar cada tarefa. No caso de mais de dois serviços fornecerem acesso ao mesmo tipo de funcionalidade, pode não haver garantias que possuam a mesma interface. Para lidar com tal diversidade, precisamos de um estágio extra no qual modificamos o projeto base do experimento para acomodar os detalhes de cada interface selecionada. O nome desse processo é harmonização de workflow.
O projeto myGrid desenvolveu quatro componentes para suportar o ciclo de vida. O cientista interage, personaliza e escolhe serviços, workflows e dados através de um workbench. Esse por sua vez serve como cliente para dois componentes, utilizados para descobrir workflows e serviços que podem servir para instanciá-lo. O componente de visão personalizada permite ao cientista personalizar a descrição do serviço anexando meta-dados que serão unificados em um framework RDF. O componente de busca semântica possui meta-dados expressos em OWL, o que permite alguma agilidade ao lidar com definições que evoluem com o passar do tempo. Uma vez descoberto e construído, o workflow é executado pelo ambiente de execução FreeFluo, que tem suporte a algumas linguagens de descrição de workflow. Esse ambiente pode executar a harmonização através de interação com o usuário ou, se possível, automaticamente ao analisar os meta-dados disponíveis.
Inicialmente, a idéia de que seria possível resolução e harmonização automática de workflows através da anexação de uma quantidade simples e homogênea de meta-dados a cada serviço. Resultados mostraram que o cientista precisa de pelo menos sete tipos de meta-dados em pontos específicos no ciclo de vida.
Na criação do workflow, inicialmente o usuário não deve ser limitado pela existência ou não do serviço. Os serviços específicos não são detalhados, o usuário deve fornecer meta-dados que permitam escolhe entre classes de serviços. Dentre os serviços de uma classe, um seria escolhido para realizar a etapa. Tais classes pertencem a uma ontologia de descrição do serviços, sendo o uso de restrições a prática utilizada para agrupar serviços similares.
A resolução do workflow assume que as classes para tarefas comuns contenham mais de um serviço. Logo, para realizar a escolha entre serviços diferentes que realizam a mesma função, o usuário deve considerar algum critério adicional. Por exemplo, dois serviços com a mesma função podem ter desempenho e custo monetário diferente. Os dados sobre a experiência de outros usuários com o mesmo serviço também podem ser avaliados. Todos esses critérios de resolução de workflow podem ser considerados antes da execução ou durante ela, sendo o último caso o mais desejável, já que as decisões levariam em conta informações mais precisas sobre o estado da grade. A resolução também pode ser feita manualmente ou de forma automática. Apesar de o desejado ser uma resolução automática, nem sempre isso é possível, pois nem todos os serviços podem ter todos os meta-dados para tal. Então o sistema deve permitir resolução manual sempre que os meta-dados não foram suficientes para uma escolha que não altere o resultado final.
Harmonização de workflow permite garantir que o serviço escolhido em uma classe será capaz de iniciar a execução. Há duas diferenças possíveis entre dois serviços de funcionalidade idêntica: mapeamento do formato da entrada/saída e mapeamento da invocação para operações de baixo nível. A harmonização de formato serve para adequar os dados informados com os necessários para a entrada do serviço, assim como os dados trocados entre os serviços. Para tal, podem ser criados nossos serviços intermediários, porém é importante que eles não interfiram no resultado final da computação.
A invocação necessária para o workflow pode ser de alto nível mesmo após a resolução. Para dado serviço atendê-la, é preciso invocar um conjunto de métodos do serviço em certa ordem. Veja que temos reproduzido o problema inicial, trata-se de um "pequeno" workflow dentro do conjunto maior de operações. Várias soluções para esse problema foram propostas. A abolição da diversidade de todos os serviços de uma grade é uma opção, assim como exigir que cada serviço tenha um fragmento já formatado e resolvido de workflow. Outra maneira seria a criação de plugins para cada tipo de provedor de serviços.
A harmonização deve ocorrer imediatamente após a resolução. Se a resolução for durante tempo de execução, assim deve ser a harmonização. É importante notar que nesse estágio a resolução automática é mais importante, pois a intervenção humana a essa altura necessita de detalhes da implementação da grade, algo que se deseja afastar do usuário.
Os sete tipos de meta-dados necessários são:
Uma descrição conceptual do serviço, escrita pelo fornecedor.
Meta-dados de configuração para suportar uma tarefa particular.
Uma descrição histórico descrevendo como o serviço foi utilizado no passado.
Uma descrição operacional.
Um modelo de invocação.
Uma interface para o serviço.
Uma definição para o formato de dados.
O maior desafio em aberto continua sendo como lidar de maneira adequada com meta-dados estruturados, incluindo serviço adequados para manipulá-los. Tal desafio envolve não apenas os usuários, mais também serviços de recuperação automática de conhecimento.
Comentário:
Ótimo artigo. Muito interessante, serve como um levantamento do que já é possível na criação e manipulação de workflows em grades computacionais semânticas. Apesar de ser muito atrelado ao projeto myGrid, já é possível tirar algumas conclusões gerais. Seria interessante saber de onde eles tiraram os tipos de meta-dados necessários para a execução facilitada de workflows, foi apenas da experiência de uso ou de alguma teoria maior sobre base de conhecimento?
Post a Comment
Nenhum comentário:
Postar um comentário