QoS-control of Structured Parallel Computations: A Predictive Control Approach

Autores: G. Mencagli e M. Vanneschi
Publicado em: 2011 IEEE Third International Conference on Cloud Computing Technology and Science (CloudCom)
DOI:10.1109/CloudCom.2011.47

Esse artigo apresenta uma metodologia para modelagem de aplicações paralelas utilizando técnicas control-theoretic. Essa abordagem é oriunda da teoria de controle de sistemas indústriais. O objetivo aqui é permitir a adaptação em tempo de execução de aplicações paralelas. O conceito de adaptive parallel module (ParMod) é definido como uma unidade independente responsável pela execução de uma computação paralela que possui uma estratégia de adaptação definida. O módulo é dividido em duas partes: Operating Part que executa a computação em si; Control Part responsável pela implementação da estratégia de adaptação. Desta forma, a Control Part é responsável por monitorar o progresso da computação na Operating Part. A adaptação a ser realizada pode ser não-funcional, envolvendo alterações no grau de paralelismo, ou funcional, tratando da adaptação do código em ambientes heterogêneos. Em seguida, o artigo apresenta uma modelagem para o comportamento da Operating Part. É utilizado o conceito de estados baseados nos valores de variáveis internas, que são adaptados de acordo com medidas de perturbação no ambiente que resultam em entradas de controle por parte da Control Part. Apesar da modelagem ser generalista, no estudo de caso apresentado os autores escolheram o esqueleto de paralelismo Task-Farm, no qual não há interação entre as tarefas workers. Para modelar esse exemplo, usaram um tratamento estatístico no tempo médio de execução de cada etapa do Task-Farm. Também consideram que a adaptação não poderia considerar o prazo completo da execução. Cada mudança tinha horizonte de apenas alguns passos no futuro. Isso serviu para limitar o custo da adaptação. A execução de simulações em um cluster demonstrou que a solução apresentou resultados próximos ao algoritmo ótimo e superior a heurísticas com estratégia de reação pura. Os autores planejam no futuro expandir o trabalho para controlar grafos de computação com múltiplos módulos paralelos com cada um exibindo uma estratégia de controle própria.

Chunks and Tasks: A programming model for parallelization of dynamic algorithms

Autores: Emanuel H. Rubensson e Elias Rudberg
Publicado em: Parallel Computing Volume 40, Issue 7, July 2014, Pages 328–343
DOI:10.1016/j.parco.2013.09.006

Esse trabalho apresenta um modelo de programação paralelo e distribuído no qual o desenvolvedor só necessita dividir o algoritmos em tarefas e os dados de entrada em chunks, cabendo ao ambiente de execução tratar a distribuição dos mesmos. No início da execução, um programa mestre serial fatia a entrada em chunks, que são objetos somente leitura com identificador único. O usuário também define objetos tarefas, informando qual o tipo de chunk é esperado como entrada e qual vai ser produzido na saída. Um escalonador distribui as tarefas entre os recursos (cores ou máquinas) junto com seus respectivos chunks, que são a partição dos dados na qual a tarefa irá executar. Um tarefa, ao executar, pode produzir um novo chunk ou uma nova tarefa. Seja qual for o objeto gerado, ele é registrado no programa mestre. Esse registro não involve a transferência total do chunk, apenas seus meta-dados. Se a tarefa seguinte for executada no mesmo recurso, o chunk já está no local, não havendo transferência. Caso a tarefa que vai precisar do chunk gerado esteja em outro recurso, a transferência é feita diretamente entre o recurso que executou a tarefa geradora e o recurso que irá executar a tarefa que consome o chunk. A arquitetura define dois serviços em execução em cada worker, o Chunk Service e o Task Service. O primeiro cuida da transferência e registro dos chunks. O segundo cuida da sincronização entre as tarefas. Toda comunicação é feita por MPI. Como os chunks e tarefas podem ser criados e registrados dinamicamente, esse paradigma se encaixa muito bem na implementação de algoritmos paralelos recursivos e hierárquicos. Não há comunicação direta entre as tarefas, mas sim transferências de chunks, que podem exigir comunicação com o processo mestre antes de acontecer. O que é interessante no contexto de nuvens e elasticidade é que como uma tarefa pode gerar uma nova tarefa, dependendo de como foi definida, seria possível criar máquinas virtuais para essas novas tarefas. Haveria o overhead de criação, mas no lugar de criar uma por tarefa, poderia ser utilizado um pool de VMs para lidar com novas tarefas. Esse pool cresceria ou diminuiria observado a utilização das máquinas atuais. A limitação é que aplicações fortemente acopladas, de granularidade fina, talvez não se encaixem no modelo. Enfim, parece um misto de Bag-Of-Tasks e Map-Reduce, mas com a possibilidade de comunicação (com overhead) entre as tarefas pela transferência de chunks, caso seja necessário.

A Framework for Elastic Execution of Existing MPI Programs

Autores: A. Raveendran, T. Bicer e G. Agrawal
Publicado em: 2011 IEEE International Symposium on Parallel and Distributed Processing Workshops and Phd Forum (IPDPSW)
DOI:10.1109/IPDPS.2011.240

Esta proposta analisa as aplicações MPI como uma sequência de iterações. A cada número X de iterações, é avaliado o tempo médio de execução de uma iteração. Caso esse valor esteja acima do desejado pelo usuário, os processos são terminados, os valores das variáveis (estado da computação) são salvos em arquivos e a computação é reiniciada com um número maior de processos (VMs). O mesmo ocorre se o tempo de execução médio de uma iteração esteja muito abaixo do desejado pelo usuário, só que neste caso a computação é reiniciada com menos processos (VMs) para poupar custos. Uma possível contribuição seria imaginar “esqueletos” de estruturas de dados que facilitassem a consolidação e distribuição dos dados entre as adaptações.

Description: Semantic Annotation for Web Services

Autores: Holger Hausen, Rubén Lara, Axel Polleres, Jos de Brujin e Dumitru Roman
Publicado em: Semantic Web Services – Concepts, Technologies and Applications – Ed. Rudi Studer, Stephan Grimm and Andreas Abecker - Springer-Verlag Berlin Heidelberg 2007

Tecnologias de Web Services são um conjunto de padrões que formam um encapsulamento sobre componentes de software pré-existentes. A Web Services Description Language (WSDL) fornece meios de descrever operações que podem ser invocadas com suas saídas e entradas, seus nomes e seus pontos de ligação. Essas informações são suficientes para abstrair questões relativas ao sistema operacional e a linguagem de implementação utilizados em um componente específico. Porém, com essa tecnologia é possível apenas modelar a funcionalidade de um componente atribuindo a sua operação um identificador e aos seus dados um tipo definido por um schema XML. O modo de descrição atual de web services podem ajudar um desenvolvedor humano na utilização do serviço, mas para computadores a interpretação é limitada. Aspectos semânticos adicionais precisam ser modelados para permitir uma automação maior no uso de web services.

As principais tecnologias propostas para descrição semântica de web services são:

• Web Service Modeling Ontology (WSMO): uma iniciativa que busca criar uma ontologia para descrever vários aspectos relacionados a web services semânticos, com foco no problema de integração.

• OWL-S: busca permitir a automatização da descoberta, invocação, composição, inter-operação e monitoramento da execução de web services fornecendo descrições semânticas apropriadas de serviços.

• Semantic Web Services Framework (SWSF): um projeto recente que une aspectos da OWL-S e da Process Specification Language (PSL).

• WSDL-S: uma proposta minimalista que adiciona descrições semânticas em interfaces WSDL tradicionais.

Das propostas acima, WSMO e OWL-S são as mais maduras, ambas possuindo implementações reais de qualidade.

A WSMO descreve todos os aspectos relevantes relacionados a serviços gerais que são acessíveis através de uma interface web service com o objetivo principal de permitir a automatização (parcial ou total) das tarefas envolvidas (descoberta, invocação, composição, inter-operação e monitoramento da execução) nos escopos intra-institucionais e inter-institucionais da integração de web services. Possui quatro elementos principais: ontologias, serviços, objetivos e mediadores. Para definir a WSMO, foi utilizada a especificação Meta Object Facility (MOF), que define uma linguagem e framework abstratos para construção e gerência de meta-modelos neutro em relação a tecnologia de implementação. Existem quatro camadas arquiteturais na MOF: informação, modelo, meta-modelo e meta-meta-modelo. A WSMO corresponde a uma camada meta-modelo, enquanto todos os seus elementos constituintes são parte da camada de modelo e os dados atuais das instâncias são da camada de informação. Na definição do WSMO, foi assumido que cada atributo tem sua multiplicidade configurada para aceitar vários valores por padrão. Também foi considerado que alguns elementos da WSMO recebem atributos originados da união de vários tipos. O artefato de meta-modelagem MOF mais utilizado na definição de WSMO é o artefato Class (e por conseguinte, SubClass), em conjunto com seus atributos, os tipos dos atributos e sua multiplicidade.

Uma ontologia é uma especificação formal e explícita de uma conceitualização compartilhada. Apesar de existirem vários esforços de padronização para linguagens de ontologia, nenhuma delas tem a expressividade e propriedades computacionais desejadas para descrever web services em um nível de granularidade suficiente. O elemento WSMO designado por ontologia pode ter propriedades não-funcionais, outras ontologias importadas, mediadores, conceitos, relações, funções, instâncias e axiomas. Propriedades não-funcionais são utilizadas para descrever aspectos tais como autor, data de criação, linguagem de descrição, etc. Ontologias importadas permitem uma abordagem modular para o projeto de ontologias e podem ser empregadas sempre que não houver conflitos entre as fontes importadas. Quando existem conflitos, o uso de mediadores se torna necessário. Conceitos constituem os elementos básicos de uma terminologia acordada para algum domínio de problema. De uma perspectiva de alto nível, um conceito – descrito por uma definição de conceito – fornece atributos com nomes e tipos. Relações são utilizadas para modelar interdependências entre vários conceitos. Funções são relações especiais, com uma amplitude unária e um domínio n-ário, onde a amplitude especifica um valor de retorno. Instâncias são definidas explicitamente ou com uma ligação a uma base de dados. Axiomas são considerados expressões lógicas unidas com seus valores não-funcionais.

O elemento serviço da WSMO fornece um modelo conceitual para descrição em uma maneira explícita e unificada todos os aspectos para um serviço, incluindo suas propriedades não-funcionais, funcionalidade e interfaces. A palavra serviço é usada como a provisão de valor em algum domínio, como uma entidade de software capaz de recuperar algo de valor em meios de interação online com um provedor de serviços. WSMO permite uma visão unificada de um serviço; o valor que o serviço pode fornecer é capturado por sua capacidade e os meios de interação com o provedor de serviço para a execução do serviço, ou para negociação, são capturados pelas interfaces. Podemos então considerar que os principais elementos da descrição de um serviço são sua capacidade e o conjunto de interfaces onde estão descritas as coregrafias e orquestrações. A coreografia descreve como o serviço atinge sua capacidade através da interação com seu cliente; a orquestração especifica como o serviço atinge sua capacidade fazendo uso de outros serviços. O definição do elemento serviço ainda contém ontologias importadas, propriedades não-funcionais e mediadores que resolvem conflitos entre ontologias e serviços coordenados.

A funcionalidade fornecida por um dado serviço é descrita por sua capacidade; sendo expressa pelo estado do mundo antes da execução do serviço e o estado do mundo após a execução com sucesso do serviço. A capacidade como elemento possui os atributos comuns como propriedades não-funcionais, ontologias importadas e mediadores. Além desses, em especial existem as pré-condições, fatos assumidos, pós-condições e efeitos. Pré-condições especificam o estado necessário do espaço de informações antes da execução do serviço. Fatos assumidos descrevem o estado do mundo que é assumido antes da execução do serviço, mas ao contrário das pré-condições, fatos assumidos não são necessariamente checados pelo ambiente de execução. Pós-condições descrevem o estado do espaço de informação que é garantido ser atingido após a execução com sucesso do serviço. Efeitos descrevem o estado do mundo que é garantido ser atingido após execução de sucesso do serviço, sendo que novamente o serviço não fica encarregado de verificar.

Uma interface descreve como a funcionalidade de um serviço pode ser completada ao prover uma visão dual na competência operacional do serviço: coregrafia decompõe a capacidade em termos de interação com o serviço; orquestração decompõe a capacidade em termos de funcionalidade requiridas por outros serviços. A coregrafia define como se comunicar com o serviço para consumir sua funcionalidade. A orquestração define como a funcionalidade global é atingida pela cooperação de provedores de serviços mais elementares.

Objetivos são representações de metas que são atingidas através da execução do web service, eles podem ser descrições de serviços que potencialmente satisfazem as necessidades do usuário. Objetivos devem ser resolvidos pela seleção de serviços disponíveis que descrevem a provisão de serviço que satisfazem o objetivo. A descrição de objetivos possuem propriedades não-funcionais, ontologias importadas, mediadores, capacidades requisitadas e interfaces requisitadas. As capacidades requisitadas descrevem a capacidade que o usuário espera do serviço.

Mediadores lidam com a heterogeneidade, resolvendo possíveis incongruências entre recursos que devem ser inter-operáveis. Heterogeneidade geralmente surge em ambientes distribuídos. A abordagem adotada para mediação se baseia na descrição declarativa de recursos onde mecanismos para resolução de incongruências trabalham no nível semântico estrutura, permitindo a criação de meios de mediação genéricos e independentes de domínio. Existem quatro tipos de mediadores na WSMO. Mediadores OO resolvem incongruências entre ontologias e fornecem conhecimento do domínio mediado para o componente alvo. Um mediador GG liga objetivos, permitindo a criação de um novo objetivo a partir de objetivos pré-existentes, definindo assim ontologias de objetivos. Um mediador WG liga um web service a um objetivo, resolvendo incongruências terminológicas e declarando diferenças funcionais entre ambos. Um mediador WW é usado para estabelecer interoperabilidade entre web services que não são inter-operáveis a priori.

Um framework para descrição da semântica de web services precisa de uma base sólida em algum formalismo lógico. A Web Service Modeling Language (WSML) fornece uma especificação de uma família de linguagens para formalização de ontologias e web services, baseada no modelo conceitual WSMO. Existem cinco diferentes variantes na WSML. WSML-Core é baseada em lógica descritiva e a lógica de Horn, sendo a menos expressiva. WSML-DL é semelhante a OWL-DL. WSML-Flight é uma extensão de WSML-Core que adiciona uma linguagem de regras. WSML-Rule é uma extensão mais completa de WSML-Flight. WSML-Full é a mais completa, adicionando todas as características das lógicas de primeira ordem. Existem sua alternativas de criação de camadas, WSML-Core → WSML-DL → WSML-Full e WSML-Core → WSML-Flight → WSML-Rule → WSML-Full. Ambas alternativas existem para suportar exigências de sistemas mais orientados a lógica descritiva ou aqueles mais adequados a sistemas de regras.

OWL-S define uma ontologia superior para serviços composta por quatro elementos principais:

• Serviço: esse conceito serve como um ponto de referência para a declaração de web services; cada serviço é declarado criando uma instância de um conceito serviço.

• Perfil de Serviço: o perfil descreve o que o serviço faz em alto nível, descrevendo sua funcionalidade e outras propriedades não funcionais que são usadas para localizar serviços baseado na suas descrições semânticas.

• Modelo de Serviço: o modelo de um serviço descreve como ele atinge sua funcionalidade, incluindo a descrição detalhada dos seus processos constituintes.

• Ligação de Serviço: a ligação descreve como usar o serviço, isto é, como um cliente pode invocar o serviço.

O conceito serviço conecta o perfil, o modelo e a ligação de um dado serviço através das propriedades presents, descbribedBy e supports, respectivamente. WSMO explicitamente desconecta o ponto de vista do provedor e o ponto de vista do cliente; objetivos são definidos independentemente dos web services e são ligados através de mediadores WG.

Em OWL-S, o modelo de serviço representa como serviços funcionam, isto é, como inter-operar com o serviço. O serviço é visto como um processo e a classe ProcessModel é a raiz da definição. O modelo de processo descreve as propriedades funcionais do serviço, juntamente com detalhes dos seus processos constituintes (se o serviço for composto), descrevendo como interagir como o serviço. A descrição de funcionalidade é dividida em transformação de informação e mudança de estado, sendo expressa em termos de IOPE (input, output, preconditions, effects). A descrição de funcionalidade está em parte definida no perfil do serviço e o restante no modelo. Na WSMO, essa descrição se concentra apenas na capacidade do web service. Existem processos atômicos, simples e compostos. Os atômicos podem ser invocados, não possuem subprocessos e são executados em um único passo no ponto de vista do cliente. Processos simples não são invocáveis e são vistos como também executados em um único passo. Processos compostos são criados a partir da organização de outros processos, são utilizados estruturas de controle para definir seqüências de invocação e também controlar o fluxo de dados entre os serviços constituintes. Uma importante diferença entre OWL-S e WSMO é que a primeira apenas define o comportamento externamente visível dos web services, enquanto WSMO também modela como o serviço faz uso de outros serviços para fornecer sua funcionalidade.

O perfil do serviço descreve o propósito do serviço, tanto descrevendo o serviço fornecido pelo provedor e o serviço desejado pelo cliente. O perfil de um web service pode ser inserido em uma hierarquia, sendo essa classificação opcional. Serviços OWL-S podem ser posicionados em uma hierarquia pré-definida, enquanto serviços WSMO podem ser ligados a um objetivo usando um mediador WG. As propriedades não-funcionais são informadas no perfil. Na WSMO, qualquer um dos elementos principais podem ter propriedades não-funcionais, enquanto na OWL-S esse tipo de informação está apenas no perfil. A informação sobre funcionalidade presente no perfil também é dividida em transformação de informação e mudança de estado em conseqüência. O primeiro tipo é estudado ao se definir as entradas e saídas de um serviço, enquanto o segundo tipo é definido em termos de pré-condições e efeitos. Entradas e saídas em OWL-S descrevem que informações são requisitadas e qual informação é produzida pelo serviço. Entradas e saídas são modeladas como subclasses de um parâmetro, que por sua vez é um subclasse de uma variável SWRL com uma propriedade indicando a classe ou tipo de dados onde se encaixam os valores do parâmetro. Pré-condições são condições no estado do mundo que precisa ser verdadeiro para a execução com sucesso do serviço. Efeitos descrevem condições no estado do mundo que são verdadeiros após a execução do serviço. Eles são modelados como parte de um resultado. Um resultado tem inCondition, ResultBar, OutputBinding e Effect. O resultado é declarado no processo do serviço, sendo parte de um processo atômico. A mudança de estado é descrita em WSMO utilizando fatos assumidos e efeitos. O objetivo apenas define efeitos como o estado do mundo que é desejado. A relação entre entrada e saída, pré-condições e efeitos de um web service precisa ser capturada para descrever com precisão a funcionalidade.

A ligação em OWL-S fornece os detalhes de como acessar o serviço, mapeando de uma especificação de serviço abstrata para uma concreta. Essas ligações são associadas com processos atômicos definidos no modelo de serviço, apesar dessa associação não ser descrita no modelo apenas na ligação.

Pode-se afirmar que a linguagem OWL em conjunto com o vocabulário OWL-S formam a linguagem de especificação de web services OWL-S. Entretanto, é fato que OWL sozinha não é suficiente para a especificação do comportamento de web services. O maior problema é que OWL não permite encadear variáveis sobre predicados, o que torna impossível especificar o relacionamento entre a entrada e a saída, o que é necessário para descrever formalmente o comportamento de qualquer componente de software. Assim, OWL-S permite que o usuário escolha uma linguagem diferente para a especificação das pré-condições e efeitos. Entre as opções, estão SWRL, KIF e DRS.

Comentários:

O importante a ser levado desse capítulo é a relevância da utilização dos conceitos de entrada, saída, pré-condições e efeitos na descrição semânticas de web services. É uma idéia até intuitiva, sendo que as duas abordagens são bem semelhantes nesse quesito. WSMO pareceu mais completa e estrutura, mas talvez pela forma que foram apresentadas, acho que OWL-S aparenta ser mais fácil de utilizar. A sintaxe XML fez me sentir em casa, com muitas familiaridades. O fato de OWL-S ser definida pela mesma comunidade da DAML-OIL também ajuda. Os mediadores propostos pela WSMO é que são seu verdadeiro trunfo, pois combinam muito bem com o requisito de baixo acoplamento, levando a um modelo bem mais orientado a serviços. Fica para depois a decisão de qual usarei, se for usar um.

Goals and Vision: Combining Web Services with Semantic Web Technology

Autor: Chris Preist
Publicado em: Semantic Web Services – Concepts, Technologies and Applications – Ed. Rudi Studer, Stephan Grimm and Andreas Abecker - Springer-Verlag Berlin Heidelberg 2007

As tecnologias de web semântica trabalham em direção à uma web que seja interpretável por máquinas. Web Services, por outro lado, estão trabalhando em direção a um ambiente onde organizações podem fazer algumas de suas atividades acessíveis pela Internet. Os web services semânticos combinam essas duas tecnologias para possibilitar interação automática e dinâmica entre sistemas de software. É um meio de descrever serviços, possuindo habilidades em sua infra-estrutura para a descoberta dos serviços possibilitando a inter-operação. Entretanto, não é fornecido o raciocínio para decidir qual serviço é o procurado, qual fornecedor é o melhor, como negociar os parâmetros de um serviço e quais ações devem tomar quando um serviço é selecionado. Só é possível total automatização dessas tarefas com o uso de outras disciplinas da ciência da computação.

Formalmente, podemos definir serviço como o desempenho de algumas ações por uma entidade para fornecer algum valor ou ganho para outra entidade. O contexto de atuação do serviço determina o domínio de valor do serviço. A entidade que executa o serviço é denominada provedor enquanto a que recebe o benefício é chamada de consumidor. Um serviço concreto é um desempenho específico de ações em um intervalo de tempo determinado. Um serviço abstrato corresponde para algum conjunto ou classe de serviços concretos e nos permite discutir serviços hipotéticos sem precisão sobre todos os aspectos de implementação.

Um objetivo dos web services semânticos é fornecer uma representação processável por máquinas do serviço, em termos dos valores que ele possibilita. Isso é chamado de descrição do serviço. Algumas questões são levantadas para atingir tal objetivo. Primeiro, que linguagem formal será usada para descrever serviços? Segundo, que conceitos específicos e relações serão permitidas nas descrições e quais serão seus significados? É importante que os termos da ontologia permitam a especificação das ações do serviço, incluindo seus resultados, na terminologia do domínio de valor do serviço. Componentes de software que representam entidades são conhecidos como agentes, com um agente provedor representando um provedor de serviços e um agente consumidor representando um consumidor de serviços. Eles são chamados de agente em um sentido bem preciso, pois agem como representantes online de alguma entidade. É fácil confundir com agentes inteligentes, mas nesse contexto o termo agente englobam os inteligentes e qualquer outra representação em software de entidades.

O protocolo de comunicação entre entidades diferentes é geralmente chamado de coreografia. Uma coreografia determina restrições na ordenação das mensagens trocadas entre o provedor do serviço e o consumidor do serviço .Temos que quando a troca de mensagens ocorre de acordo com restrições de alguma coreografia, podemos concluir que se trata de uma conversação entre entidades que satisfaz a coreografia. Um dos objetivos dos web services semânticos é descrever diferentes coreografias que entidades podem utilizar para interagir em um formato processável por máquinas.

Uma orquestração é uma especificação interna ao agente que determina qual mensagem deve ser enviada em determinado momento, não necessariamente destinada a mesma entidade da mensagem anterior. Assim, a coreografia especifica o que é permitido às entidades, enquanto a orquestração especifica o que cada entidade irá de fato realizar. O ato de combinar e coordenar um conjunto de serviços é conhecido por composição de serviços. Quando um agente cliente está interagindo simultaneamente com vários provedores de serviços, uma orquestração pode especificar a seqüencia de mensagens com todos eles, incluindo dependências apropriadas. Há duas maneiras de especificar a orquestração. A mais direta, e menos flexível, é tomar decisões em tempo de projeto sobre quais provedores serão utilizados, codificando a lógica de integração no agente cliente. Uma maneira mais flexível é utilizar uma linguagem de workflow declarativa para descrever o processo de integrar as interações com os provedores escolhidos. Ter uma descrição explícita da orquestração de serviços em termos de alguma linguagem de processos tem uma vantagem extra. Significa que a orquestração pode existir independente do agente cliente, sendo transportada entre agentes como uma estrutura de dados. Não só o agente cliente pode ser capaz de gerar uma orquestração, qualquer entidade pode produzir uma, mostrando como vários serviços podem ser combinados para produzir um serviço mais complexo.

Em uma interação entre duas entidades, pode ser necessário alguma mediação. Há quatro tipos de mediação disponíveis: dados, ontologia, protocolo e processo. A mediação de dados consiste em transformações sintáticas entre os dados trocados pelo provedor e cliente. A mediação de ontologia consiste na resolução de ambigüidades e termos diferentes com o mesmo valor semântico, lembrando em parte o problema de merging. A mediação de protocolo consiste na mediação de coreografias, traduzindo as seqüências de mensagens das entidades até que estejam sincronizadas e de acordo com o objetivo. A mediação de processo é a mais complexa, pois consiste de mediar os interesses das entidades e dos processos internos. Seja qual for o tipo de mediação, ela será fortemente ligada ao grau de anotação semântica das mensagens e coreografias. Quanto maior a qualidade da anotação, maior a possibilidade de automatização das mediações.

O ciclo de vida do relacionamento entre o cliente e o provedor atravessa quatro fases: modelagem, descoberta, definição e entrega. Na fase de modelagem, tanto o cliente cria uma definição abstrata do serviço procurado como o provedor também estabelece uma definição abstrata dos serviços que oferece. Na fase de descoberta, se a descrição abstrata do cliente e a descrição do provedor são compatíveis de alguma forma, então ambas entidades podem prosseguir para a fase de definição do serviço. A fase de definição envolve capturar uma descrição abstrata do serviço de um provedor e refiná-la até que ela descreva um serviço específico que cumpre as necessidades do cliente. A entrega do serviço pode ocorrer de várias formas, correspondendo a realização de fato do serviço. Vários tipos de interações podem ocorrer nessa última fase, sendo que várias coreografias estão associadas. Uma coreografia de entrega de serviço cobre a troca de mensagens associada diretamente com a entrega do serviço, sendo muitas vezes o serviço sendo fornecido pela própria troca de mensagens. Uma coreografia de monitoramento cobre a troca de mensagens que permitem ao cliente receber informações do provedor sobre o progresso do serviço. Uma coregrafia de cancelamento/renegociação permite ao cliente cancelar ou alterar o serviço que está recebendo do provedor.

Uma micro-arquitetura é a arquitetura interna baseada em componentes de um entidade individual dentro de uma comunidade. Uma macro-arquitetura é a estrutura da comunidade, considerando cada entidade interna como uma caixa preta. Na macro-arquitetura, uma entidade de software pode desempenhar três papéis: agente cliente, agente provedor e agende provedor de descoberta. O agente cliente possui um modelo, em uma ontologia, do domínio do serviço e também tem um modelo do tipo de ações que podem ser tomadas (através de troca de mensagens) nesse domínio. O agente provedor fornece uma descrição dos serviços que hospeda em uma ontologia de domínio, também possuindo meios de gerar descrições mais concretas dos serviços precisos que ele pode entregar. O agente provedor de descoberta tem acesso as descrições dos serviços ofertados, juntamente com referências a agentes provedores capazes de fornecer tais serviços.

As interações na macro-arquitetura seguem a orientação do ciclo de vida.

1. Agente do provedor registra uma nova descrição de oferta de serviço: o agente provedor envia uma mensagem para o agente provedor de descoberta contendo uma oferta de serviço descrita na ontologia do agente de descoberta.

2. Agente do cliente descobre possíveis provedores: o agente cliente envia uma mensagem ao agente provedor de descoberta contendo uma descrição dos serviços procurados na ontologia do agente de descoberta.

3. O cliente e o provedor definem o serviço.

4. O serviço é entregado.

Devido a grande variedade de coregrafias possíveis durante a entrega, nesse estágio a mediação terá o papel mais importante. Para o propósito da arquitetura descrita, todo protocolo de coregrafia aplicado terá lugar no agente cliente.

A micro-arquitetura de cada agente não precisa seguir uma arquitetura padrão em toda a comunidade. No núcleo do agente cliente, temos a lógica da aplicação responsável pela tomada de decisão relacionada a qual serviço selecionar e como utilizá-lo. Seu primeiro papel é definir a descrição de requisitos do serviço que precisa. O componente de definição e descoberta é responsável por gerenciar a descoberta e coregrafias definidas dos serviços. O componente de abstração da mensagem realizar mediação de dados. Quando recebe uma mensagem, traduz seu conteúdo em informação semântica de acordo com uma ontologia e o armazena na base de conhecimento. Também acessa a mesma base para gerar mensagens de saída de acordo com a ontologia. O componente de entrega fica responsável pela mediação de protocolo, lidando com as coregrafias de acordo com instruções da lógica de aplicação. No agente provedor, como já foi definido que ele não tratará mediação, podemos ter uma estrutura mais simples. Não temos a abstração de mensagens e nem a base de conhecimento, sendo que por não lidar com mediações, seus componentes podem ser bem mais restritos.

Comentários:

Um pouco vago, porém o final valeu a pena pela definição da arquitetura. Com certeza, os conceitos levantados nesse capítulo serão importantes nos posteriores.

Semantics-Assisted Problem Solving on the Semantic Grid

Autores: Liming Chen, Nigel Richard Shadbolt, Feng Tao, Carole Goble, Colin Puleston and Simon J. Cox
Publicado em: Computational Intelligence, Volume 21, Number 2, 2005

Grades computacionais fornecem um conjunto extensível de serviços e permitem a composição e decomposição rápida de tais serviços em confederações transientes de várias maneiras de forma que tarefas maiores do que aquelas permitidas pelos componentes individuais possam ser completadas. Existe uma separação crucial entre os projetos atuais de grades e a visão de e-Science, onde há um alto grau de facilidade e automatização, sendo que existem colaborações flexíveis e computações de escala global. A grade semântica busca suportar toda a riqueza da e-Science ao considerar seus requisitos através do uso para recursos da Grade em seu sentido mais amplo. Tecnologias de conhecimento avançado são relacionadas com a gerência de conhecimento científico na grade em termos de uma atividade de ciclo de vida orientada ao conhecimento que varia desde aquisição de conhecimento até modelagem, recuperação, reuso, publicação e manutenção. Engineering Design Search and Optimisation (EDSO) é o processo onde modelagem e análise são utilizadas para recuperar projetos aprimorados. O objetivo da e-Science em EDSO é explorar a computação distribuída de larga escala das grades juntamente com seus recursos de dados, ambos inacessíveis no primeiro momento, para engenharia de projetos.

No framework apresentado, informação e conhecimento sobre um domínio específico são adquiridos, modelados e representados utilizando uma variedade de técnicas e formalismos, que podem incluir ontologias, regras de produção e outras informações relacionadas ao domínio. Engenharia e gerência de conhecimento tentam tratar seis desafios do ciclo de vida do conhecimento: aquisição, modelagem, recuperação, reuso, publicação e manutenção. Ao contrário de práticas tradicionais de engenharia de conhecimento que concentram em capacidades separadas, esse framework trata cada problema individual em maneira muito mais coordenada para que os resultados de uma parte do trabalho possam ser usados de maneira apropriada. As ontologias são parte fundamental na interação e inter-operação das atividades de conhecimento. Também é adotada uma abordagem orientada a serviços para gerência distribuída de conhecimento. Todas as atividades relacionadas ao consumo e fornecimento do conhecimento são implementadas como serviços. Um framework modular em camadas faz a gerência de conhecimento robusta e escalar. Apesar de interagirem, as interações das atividades de manipulação de conhecimento não são fortemente acopladas.

Um conjunto básico de serviços tem sido considerado indispensável para as grades semânticas. São os seguintes:

• Serviços de ontologia fornecem acesso aos conceitos, suas propriedades e relacionamentos em um modelo de dados ontológico.

• Serviços de anotação associam recursos da grade com suas interfaces semânticas e meta-dados através de ontologias para agregar semântica a tais recursos.

• Serviços de publicação de conhecimento são responsáveis pela disponibilização de conhecimento na grade para reuso.

• Serviços de inferência fornecem capacidades de raciocínio sobre várias entidades de conhecimento nos repositórios.

O portal de conhecimento, o ponto de entrada para o sistema de gerência integrado de conhecimento, possibilita uma infra-estrutura de segurança para autenticação e autorização, fazendo com que o conhecimento seja usado e atualizado de maneira controlada.

Resolução de problemas na grade consiste em descobrir serviços e compô-los em um workflow. Para a maioria das disciplinas científicas, um workflow é tanto específico ao domínio quanto ao problema. A seleção apropriada de serviços em um determinado ponto do workflow geralmente depende dos resultados dos serviços executados anteriormente. Desta forma, não é prático especificar, a priori, a seqüência precisa dos serviços para um problema. Descoberta semântica de serviços geralmente utiliza meta-dados semânticos de um perfil de serviço tais como autor, organização, algoritmo utilizado, versão e utilização para criar um critério de busca para o recurso buscado. Um motor de inferência baseado em lógica descritiva irá realizar inferências sobre recursos de grade semânticos para descobrir aqueles que estão de acordo com seus objetivos de busca. Quando um workflow é construído, cada vez que um serviço é adicionado os usuários podem obter a informação semântica da saída gerada. Utilizando essa saída, é possível que um raciocinador de DL consiga realizar buscas semânticas no repositório de serviços, retornando uma lista de serviços compatíveis. Devemos observar que também é comum o caso onde há muitos serviços disponíveis para uma tarefa e cada serviço pode ter diferentes desempenhos em diversas configurações. Em resumo, resolução de problemas baseada em semântica pode ajudar a descobrir os serviços necessários de maneira precisa e tem a vantagem de fornecer orientação específica em múltiplos níveis de granularidade durante a composição de serviços.

Um ambiente de resolução de problemas (Problem Solving Environment - PSE) baseado em grade tenta abstrair as complexidades de acessar a grade fornecendo um conjunto de ferramentas completo de alto nível projetado para resolver determinado tipo de problema. O projeto GEODISE (Grid Enabled Optimisation and Design Search in Engineering) possui estabelecido um PSE com vários módulos de funcionalidade. O módulo dos serviços de ontologia fornecem um mecanismo para usuários acessarem e utilizarem qualquer ontologia na Web. O módulo de serviços de computação semânticos abriga todos os tipos de recursos EDSO tais como ferramentas computacionais e algoritmos que podem usados para alcançar uma tarefa específica. A descoberta de serviços é feita através da Semantics-based Web Search Engine (SWSE).

O componente básico do PSE em estudo é o ambiente de construção de workflow (Workflow Construction Environment – WCE). Os seus principais componentes são:

• Navegador de Serviços Classificados: apresenta uma hierarquia de serviços classificados em termos da ontologia de serviços EDSO.

• Orientador de Workflows: fornece orientação na composição e configuração de serviços baseadas nas informações semânticas.

• Monitor de Estado: monitora a construção do workflow.

• Raciocinador Ontológico: realiza inferências no repositório de conhecimento para auxiliar a composição, descoberta e configuração de serviços.

• Editor de Configuração de Serviço: é um formulário baseado em ontologias criado dinamicamente que contém os atributos dos serviços e seus valores.

• Editor de Composição de Serviço: um ambiente de trabalho gráfico para composição de serviço.

Durante os processos de construção de workflow, uma vez que o serviço é descoberto e adicionado a um workflow no Editor de Composição de Serviço, o Monitor de Estado irá coletar e manter informações sobre a entrada e saída do serviço. O estado atual do workflow será transmitido ao Orientador de Workflow, que irá fazer uso do Raciocinador Ontológico para realizar inferências sobre o repositório de conhecimento. Orientações relevantes tais como qual serviço deve ser o próximo ou como escolher um parâmetro para configuração do serviço serão retornadas para o WCE. Usuários podem selecionar um dos serviços sugeridos e configurá-los de acordo com as recomendações. Repetindo esse processo um workflow pode ser construído rapidamente. O poder do PSE vem da abordagem de resolução de problemas baseada em semântica, que extrai e explora o conhecimento do domínio incorporado nas descrições semânticas dos recursos para a composição e configuração dos mesmos.

Para o estabelecimento do GEODISE PSE, um estudo detalhado do domínio foi feito para a criação de ontologias e regras de produção. Os recursos no GEODISE geralmente são funções do MATLAB, cujas descrições semânticas são geradas ao relacionar meta-dados do recurso e sua interface com conceitos do domínio EDSO. Os serviços de ontologia consistem de um modelo de dados para a ontologia EDSO, um servidor de ontologia que permite aos outros módulos acesso aos conceitos e suas propriedades, um raciocinador (FaCT) e um conjunto de APIs do usuário que servem como interface entre as aplicações e a ontologia. Os serviços de anotação são acessados através de uma interface gráfica que permite ao usuário relacionar conceitos da ontologia com com os recursos. Um repositório de conhecimento foi definido de maneira centralizada, em vez de manter as descrições semânticas na mesma localização dos recursos. Tal escolha foi feita para facilitar o caráter dinâmico da criação de organização virtuais. A descoberta de serviços também é feita através de uma interface, procurando por instâncias baseadas na ontologia do domínio.

Comentário:

Um artigo bem legal, que mostra uma grade semântica em funcionamento onde os meta-dados não servem apenas para a descoberta, mas também para a composição de workflows. Na verdade a composição é um processo bem simples, onde para cada passo que o usuário acrescenta, são apresentadas sugestões para próximos passos além de formulários para personalização de parâmetros.

Algo mais interessante está na seção de trabalhos futuros. Há uma discussão sobre a diferença entre a grade de conhecimento e a grade semântica. A grade de conhecimento tem como objetivo fornecer um ambiente de aplicações sustentável e inteligente na Internet que permita a indivíduos e aplicações integrantes das organizações virtuais capturar, publicar, compartilhar e reusar recursos de conhecimento explícitos. Ela é construída agregando e sintetizando conhecimento de dados através de mineração e métodos de referências, permitindo a sistemas de busca fazerem referências, responder perguntas e tirar conclusões de grandes quantidades de dados. A diferença parecer ser que a grade semântica tem como alvo a criação e povoamento de semântica e conhecimento enquanto a grade de conhecimento está mais preocupada na extração, inferência e mineração de conhecimento oriundo da grade. Podemos dizer que a grade semântica é uma camada de suporte a grade de conhecimento, sendo essa última muito mais próxima do usuário em termos de abstração.

Wings for Pegasus: Creating Large-Scale Scientific Applications Using Semantic Representations of Computational Workflows

Autores: Yolanda Gil, Varun Ratnakar, Ewa Deelman, Gaurang Mehta, Jihie Kim
Publicado em: Proceedings of the Nineteenth Conference on Innovative Applications of AI (IAAI-07) , 2007

Este artigo descreve uma nova abordagem para criação de workflows que usa representações semânticas para descrever compactamente aplicações científicas complexas de maneira independente, para então gerar workflows de processamento para conjuntos de dados e por fim mapeá-los em recursos computacionais disponíveis. Workflows fornecem uma representação efetiva que captura como recursos heterogêneos podem ser configurados para uma grande variedade de propósitos e facilitam a gerência da execução de atividades em ambientes distribuídos.

A criação e validação de workflows é uma tarefa desafiadora. Várias técnicas já foram estudas, entre elas técnicas de planejamento em IA que produzem workflows através de buscas no espaço de possíveis combinações. Neste trabalho, são definidos três passos para a criação de workflows. Primeiro, é necessária a criação de modelos que estruturam o workflow de forma independente dos dados. Segundo, são criadas instâncias que detalham quais serão os dados utilizados. O último passo é a criação de um workflow executável, que detalha quais são as réplicas de dados que serão usadas e suas localizações, as máquinas onde a computação irá ocorrer e a movimentação de dados apropriada entre as localizações distribuídas. A solução apresentada é chamada de Wings, que usada em conjunto o sistema Pegasus, fornece uma solução completa de sistemas de workflows. Wings é um sistema de criação de workflows que usa representação semântica e técnicas de planejamento para suportar a criação de modelos e instâncias de workflows, que serão submetidas ao Pegasus para criar workflows executáveis.

A solução clássica para a criação de workflows é o uso de linguagens de scripting. O problema dessa abordagem é a falta de escalabilidade e tolerância a falhas, sendo necessário conhecimento íntimo do sistema de execução. O cenário ideal seria a especificação do workflow em termos do tipo de computação a serem realizadas e os tipos de dados a serem criados, mas independente da escolha dos hospedeiros e outros recursos alocados para execução. A abordagem apresentada utiliza representações semânticas de workflows para que:

• Modelos de workflows e suas instâncias sejam objetos semânticos.

• Coleções de dados seja especificadas com descrições intencionais em modelos de workflow e transformadas em descrições extensas em instâncias de workflow.

• Descrições intencionais de coleções de computações ofereçam abstrações apropriadas para a estrutura repetitiva dos workflows.

Representações de workflows devem suportar a criação de descrições detalhadas de novos dados produzidos antes da execução do componente que necessite deles, para assim o sistema possa detectar sua pré-existência evitando computações desnecessárias. Também é necessário que as representações facilitem o monitoramento da execução e a recuperação de falhas.

No Wings, modelos e instâncias são objetos semânticos da mesma forma que seus componentes (nós), as ligações entre eles e os dados que são gerados. Dados são representados como arquivos individuais que podem ser agrupados em coleções. Computações (códigos) são representados como componentes de workflow. Nós representam os componentes a serem executados. Uma ligação em um modelo transporta dados, o tipo de dados sendo transportado deve ser consistente com os dados de saída do nó de origem e com os dados de entrada do nó de destino. Todos esses integrantes são representados em uma ontologia de referência em OWL.

Comentários:

Um artigo interessante mostrando mais de perto o funcionamento do Wings. Acho que ainda será necessário dá uma olhada mais de perto no próprio software para ter uma idéia mais firme de como funciona o sistema.

From Data to Knowledge to Discoveries: Scientific Workflows and Artificial Intelligence

Autora: Yolanda Gil
Publicado em: IOS Press Scientific Programming ,Volume 16, Number 4, 2009

A experimentação computacional trouxe avanços para quase todas as disciplinas da ciência moderna. Melhorias em análise de dados, simulação, geração e validade de hipóteses foram cruciais para várias conquistas recentes. Para aprimorar a estrutura de computação atual, a tecnologia de workflow tem sido explorada para isolar o pesquisador dos detalhes da execução em ambientes distribuídos complexos.

A infra-estrutura computacional atual de suporte a ciência surgiu de ambientes onde computadores de alto desempenho residiam em ambientes controlados, sendo o acesso remoto gerenciado crucial para a utilização da comunidade científica. Tornou-se eficiente em escalabilidade e em compartilhamento distribuído, onde temos atualmente as grades e os sistemas peer-to-peer. Porém, com o passar dos anos, avanços na infra-estrutura de hardware não refletiam com o mesmo impacto na produção científica. O volume de informações produzido e a rapidez com que novos dados eram adquiridos entraram em contraste com o número aproximadamente constante de cientistas em atividade. Logo, novas soluções mais automáticas se tornaram necessárias. O argumento é que ao capturar análise científica explicitamente em estruturas de dados declarativas conhecidas como workflows será facilitado o desenvolvimento de novas ferramentas que permitam aos cientistas lidar com a enorme quantidade de dados produzidas pelos recursos computacionais. Outro dividendo desejável será a facilidade de reprodução de processos científicos complexos, algo que atualmente não é fácil já que a coordenação da execução geralmente não é centralizada, envolvendo vários pesquisadores, cada um com sua própria fonte de dados.

Aplicações científicas podem ser muito complexas, unindo artefatos de software pertencentes a diferentes gerações de tecnologia. É comum encontrar tais aplicações sendo realizadas através de linguagens de scripting que especificam os dados e programas a serem executados, escalonando recursos computacionais e a movimentação de dados. Essa abordagem tem suas desvantagens. Primeiro, modificações são custosas e propensas a erro. Segundo, scripts precisam de intervenção humana para informar localização de dados e realizar a gerência de execução. Terceiro, falhas de execução precisam de intervenção manual para recuperação. Quarto, mudanças de recursos ou fontes de dados precisam de modificações extensas nos scripts. Quinto, a quantidade de código para lidar com informações sobre o estado da execução é grande. Por último, o pesquisador precisa aprender a programar nessas linguagens. Workflows surgem como um profundo aprimoramento dos scripts tradicionais. Eles representam declarativamente os componentes ou códigos que precisam ser executados em uma aplicação complexa, assim como as dependências de dados entre esses componentes.

O sistema Pegasus gerencia o mapeamento e a execução de workflows em recursos compartilhados distribuídos que podem ser altamente heterogêneos. Utiliza descrições de requisitos de cada um dos componentes e descobre máquinas disponíveis no ambiente que satisfazem os requisitos. Leva em consideração tempos de fila ao escolher entre recursos adequados e agrupa tarefas de workflow em um único trabalho para melhorar o desempenho da execução. Também gerência novos dados gerados movendo-os para a próxima tarefa que irá usá-los e registrando-os em catálogos. Faz uso de gerenciamento de réplicas. Inclui diversos algoritmos para otimizar a seleção de recursos não apenas baseado no desempenho das tarefas mas também no diminuição do tempo de fila e movimentação de dados. Outra técnica de otimização é a eliminação de tarefas do workflow se os dados a serem produzidos já existem no ambiente.

Taverna é um sistema voltado para workflows de bioinformática. Fornece um framework para integração de componentes e isola os usuários da diversidade de mecanismos de acesso (Web Services, Java RMI, REST). Possui uma linguagem de definição simples e intuitiva. Um desafio para esse tipo de serviço é a inexistência de descrição semântica para os dados de saída e entrada. Para superar tal carência, workflows podem incluir alguns passos para conversão de dados. O ambiente FreeFluo é utilizado para executar os workflows, sendo que tal ambiente possui um sistema de recuperação de falhas embutido.

Podemos resumir os benefícios chave dos workflows em:

• Automação da execução: gerência de dados e execução são lidados de maneira automática, incluindo mecanismos de recuperação de falhas.

• Gerência de recursos distribuídos: seja submetendo trabalhos para máquinas remotas ou invocando serviços de terceiros, workflows gerenciam computações distribuídas.

• Gerência de computações paralelas: paralelismo é representado do grafo de fluxos de dados.

• Exploração sistemática do espaço de parâmetros.

• Gerência de evolução das aplicações: aplicações em workflow são modulares por projeto, logo a evolução da aplicação é mais gerenciável.

• Armazenamento do histórico de execução.

• Reprodutibilidade de alta fidelidade com baixo custo.

A ciência cada vez mais caminha para uma visão complexa de "sistemas de sistemas", onde a interdisciplinaridade é regra, não exceção. Ampla escala significa aumentar a precisão ou resolução de uma solução para um determinado modelo físico. Amplo escopo significa aumentar a complexidade física do modelo de problema. Na interdisciplinaridade, temos uma prioridade para amplo escopo em contraste com ampla escala, que tem tem sido a maior motivação para avanços em infra-estrutura. As novas complexidades para essa mudança de paradigma não são atendidas pelas soluções tradicionais de aumento de poder de processamento e armazenamento do hardware. As novas preocupações são a integração de aplicações e recursos entre si. O comportamento, geralmente ligado a aplicações, é definido pelo nível de conhecimento disponível. Os mecanismos são importantes para implementar os comportamentos, porém são irrelevantes para a definição de tarefas do sistema, pois a escolha do mecanismo não afeta o comportamento do sistema.

A camada de conhecimento de um sistema inteligente está relacionada com a caracterização do sistema em termos de suas respostas para requisições ou objetivos e qual conhecimento é utilizado para atingi-los. Em contraste, a camada simbólica está ligada a implementação dos mecanismos de conhecimento e raciocínio que são usados para explorá-lo. A capacidade dos sistemas de workflow em mapear e executar workflows está ligada com a arquitetura no nível simbólico. A camada de conhecimento de um sistema de workflow estaria ligada aos tipos de tarefas que podem ser alcançadas pelo cientistas.

Os seguintes níveis de abstração estão presentes na especificação de workflows:

1. Execução: especifica recursos de execução.

2. Computação: especifica passos computacionais.

3. Dados: dados de entrada.

4. Método: processos de alto nível.

5. Resultados: produtos desejados.

Níveis com identificadores mais altos utilizam informações de níveis inferiores. O nível 1 corresponde a linguagens de scripts. Taverna e Pegasus são capazes de definir workflows de nível 2 e 3. Quanto maior o nível, menor é a quantidade de informações que o usuário deve informar sobre a infra-estrutura. Sistemas que processam workflows de nível 5 são capazes de responder perguntas de alto nível, semelhantes aos questionamentos entre seres humanos. A camada de conhecimento engloba os níveis de 3 a 5. A camada simbólica trata dos dois níveis inferiores. O objetivo é desenvolver sistemas que recebem workflows e requisições descritas nos níveis mais altos e sejam capazes de automatizar a elaboração dos workflows nos níveis mais baixos. Os níveis mais altos dizem respeito aos comportamentos que o sistema pode exibir e o conhecimento necessário para atingir tais comportamentos. Considerando a camada de conhecimento, desconsideramos a programação paralela e os sistemas distribuídos, sendo relevante considerara inteligência artificial como capacitadora de novas habilidades.

Wings é um sistema de workflows que recebe descrições abstratas de análises do usuário e utiliza conhecimento sobre o projeto do experimento, componentes, dados e workflows existentes para elaborar, validar e gerar automaticamente workflows que possuem o detalhamento necessário para execução no sistema Pegasus. Wings assume que todos os componentes, dados e suas propriedades podem ser organizados em hierarquias e possuem restrições associadas a seu uso adequado. Wings usa raciocinadores OWL para descobrir se certo componente pode ser usado para processar um conjunto de dados com determinadas propriedades, se é possível para um componente gerar dados com características específicas e para verificar se os dados podem fluir entre dois componentes de acordo com suas restrições. Se um cientista está criando um workflow interativamente, Wings verifica que todos os fluxos de dados é consistente com as restrições do componentes. Wings também pode selecionar dados de entrad a obedecendo as restrições expressadas no workflow e se várias bases satisfazem as restrições, vários workflows podem ser gerados. Além disso, também é possível orientar a definição do workflow através de restrições nos dados de saída.

As vantagens de uma camada de conhecimento em sistemas workflow são as seguintes:

• Automatização da geração de workflow e da verificação repetitiva de restrições: durante a geração de workflows, um algoritmo pode formular centenas de buscas sobre componentes e dúzias de buscas para verificar restrições sobre dados. Um sistema com mais conhecimento pode automatizar essas tarefas.

• Exploração sistemática do espaço de projeto do experimento: como o resultado é informado com mais detalhes semânticos, o sistema pode vasculhar quais possíveis experimentos chegariam ao mesmo objetivo.

• Validação de workflows: a partir de um rascunho de workflow, o sistema pode verificar se os resultados seriam coerentes.

• Geração automática de meta-dados para novos produtos: já que o sistema possui descrições semânticas das transformações realizadas nos dados, ele pode utilizar tais descrições para qualificar as propriedades de seus novos produtos de dados.

• Garantias maiores de boa proveniência dos dados: o sistema pode incluir conhecimento sobre workflows bem formados já conhecidos previamente que podem ser reutilizados sobre novos dados.

• Reprodutibilidade correta e reuso: as restrições dos componentes e dados de um workflow podem ser checados para garantir seu reuso correto.

Outras possibilidades para melhoria da geração automática de workflow incluem : decomposição hierárquica de tarefas, seleção entre implementações de software de componentes baseada em recursos de execução disponíveis e a seleção dinâmica de componentes baseada em informações obtidas da execução de passos anteriores.

Workflows devem ser objetos de discussão científica, e sua descrição deve ser usada para capturar formalmente um novo método ou processo de análise descoberto durante projeto e testes detalhados. Para adquirir tal importância, descrições de workflow devem se tornar mais próximas da camada de conhecimento e assim mais representativas das preocupações científicas do que detalhes de baixo nível. Uma área relacionada e importante de pesquisa futura baseada na camada de conhecimento é o aprendizado através da utilização de workflows com o objetivo de melhorar e adaptar o comportamento do sistema. Não será necessário supor que os usuários definam modelos reutilizáveis manualmente. Um sistema poderia aprender modelos reutilizáveis observando regularidades e generalizando relatórios de execução provenientes de uma comunidade de pesquisadores. Pode ser imaginado um futuro onde o aprendizado de workflows levaria a novas descobertas científicas feitas pelo sistema.

Os humanos não devem ser gargalos para avanços científicos quando tarefas rotineiras podem ser automatizadas. Workflows podem ser utilizados para automatizar processos para descoberta heurística e detecção de padrões. Através da geração e eliminação sistemática de hipóteses, workflows podem explorar fenômenos cada vez mais complexos. Workflows para detecção de padrões e descoberta devem ser desenvolvidos para processar grande quantidade de dados e extrair fenômenos de interesse potencial. Workflows também pode servir de base para o desenvolvimento de interfaces de interação (portais, aplicações GUI, etc) dinâmicas e mais adequadas para as exigências dos nossos desafios da ciência moderna.

Comentários: Artigo interessante. Acho que a autora conseguiu formalizar bem o que já foi atingido por ambientes de workflow, além de levantar o que pode ser aprimorado nesses sistemas com o auxílio de uma camada de conhecimento. Das perspectivas mais interessantes, acho que a idéia de que o sistema pode aprender e criar novos workflows que levem a descobertas inovadores parece ser o mais interessante.

Automating Experiments Using Semantic Data on a Bioinformatics Grid

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?

Semantics and Knowledge Grids: Building the Next-Generation Grid

Autores: Mario Cannataro, Domenico Talia
Publicado em: IEEE Intelligent Systems, Janeiro/Fevereiro 2004

Assim como a Web está movendo seu foco de informação e comunicação para um infra-estrutura de entrega de conhecimento, as grades estão se distanciando de apenas computação e gerência de dados para uma infra-estrutura de conhecimento ubíqua global. Essa mudança de direção se deve ao fato que hoje a humanidade produz mais dados do que é capaz de processar, sendo que a maioria do conteúdo das bases de dados tendem a ocupar grande espaço e serem acessados apenas esporadicamente, sem por isso perderem importância. As grades semânticas e os serviços de descoberta de conhecimento permitem a abstração das complexidades de utilização da grade e soluções como a OGSA e arquiteturas P2P podem torná-la mais eficiente.

A Web Semântica permite a elaboração de informação com mais qualidade e precisão, permitindo o processamento automático por agentes e melhorando a iteração humana. Boa parte da pesquisa feita nessa área está voltada para a definição de linguagens para ontologias e ferramentas para melhor defini-las. As grades semânticas são aplicações das tecnologias de Web Semântica em grades. A OGSA integra aos web services tradicionais algumas qualidades importantes para as grades. O mais importante seria a manutenção de informações de estado, que permitem a gerência de recursos abstraídos por serviços.

Peer-to-Peer é um conjunto de tecnologias e metodologias que permitem a um conjunto de computadores colaborarem em uma rede de iguais (peers) sem coordenação central. Do ponto de vista das grades, os aspectos mais interessantes das redes P2P são a escalabilidade, configuração automática, gerência autonômica, descoberta de recursos dinâmica e tolerância à falhas.

As principais características que as grades devem adquirir são: gerência e descoberta de conhecimento, modelagem semântica de seus componentes, computação ubíqua, criação dinâmica de organizações virtuais e configuração automática.

Comentário:

Artigo muito fraco na minha humilde opinião. Muito fácil pegar as tecnologias do momento e juntar toda em um pacote e vender como a onda do futuro. Não traz nada de realmente concreto e novo para as grades.

Artificial Intelligence and Grids: Workflow Planning and Beyond

Autores: Yolanda Gil, Ewa Deelman, Jim Blythe, Carl Kesselman, and Hongsuda
Publicado em: IEEE Intelligent Systems, Janeiro/Fevereiro 2004

As grades computacionais permitem a criação de organizações virtuais multi-institucionais onde seus membros podem compartilhar seus recursos de maneira coordenada visando a colaboração para resolver determinado problema. Hoje essa tecnologia faz isso muito bem, sendo que a gerência de recursos dispersos geograficamente é possível, especialmente quando esses se tratam de computadores de alto desempenho ou grandes bases de dados. Entretanto, novos desafios começam a surgir. Primeiro, há a necessidade de se conceber por demanda aplicações científicas de larga escala que fazem uso de repositórios de componentes científicos especializados para criar novos resultados. Segundo, toda a produção de software científico em grades pode ser utilizado por outros setores da sociedade, porém adaptações são necessárias para tornar esse cenário real.

Descrições e modelos de alto nível são mais adequados para desenvolver aplicações mais complexas e escaláveis. Entretanto, a grade oferece um modelo rígido de gerência, baseado em descrições sintáticas e esquemas estáticos que não garantem. Captura de conhecimento deve ser feita de maneira mais inteligente, utilizando semântica sempre que possível e possibilitando a realização de inferências. Melhorias em usabilidade podem atrair usuários que não tem conhecimento nos detalhes do middleware de grade ou disposição para aprendê-los. Robustez está associada à captura de conhecimento, pois a criação de workflows inteligentes pode ajudar a restaurá-los em caso de falha ou evitá-las ao prever situações futuras. Para otimizar o acesso, suporte para novas tecnologias para definição de políticas de segurança escaláveis é crucial. Todas essas características contribuem para uma maior escalabilidade, pois permitem um fluxo de conhecimento maior sobre grade, aumentando a utilização eficiente de novos recursos. A palavra da ordem é adaptação, já que aplicações que executam durante longos períodos não podem confiar apenas em informações adquiridas quando são iniciadas, pois o ambiente de grade é dinâmico e competitivo.

Técnicas de planejamento em IA (inteligência artificial) permite mapear as possíveis alternativas de componentes para uma aplicação em um espaço de soluções que representa o custo benefício da execução. Logo, podemos definir o problema de geração de workflow como um problema de planejamento em IA onde os objetivos são as informações que se espera serem produzidas e os operadores (atuadores?) são os componentes da aplicação. A entrada para tal sistema são uma representação do estado atual do ambiente, uma representação declarativa do estado objetivo e uma biblioteca de operadores que o escalonador pode usar para mudar seu estado. Cada operador tem suas pré-condições e seus efeitos. O escalonador busca por um conjunto ordenado de operadores que irá transformar o estado atual em direção a um que satisfaça o estado objetivo. Cara parâmetro dos operadores contém o host onde o componente será executado, algumas restrições e os arquivos de entrada. O plano retornado constitui-se de um workflow completo.

A arquitetura proposta prevê a existência de gerentes de workflow. Entre suas atribuições, estão supervisionar a execução e desenvolvimento dos workflows criados, coordenar intersecções entre workflows, garantir a aplicação de políticas de justiça. Trabalhando em conjunto, teremos raciocinadores atuam sobre dados semânticos criando novas informações para aperfeiçoar a atuação dos gerentes de workflow. Caberá ao usuário prover especificações de alto nível os resultados desejados e suas restrições. O gerente de workflow formará um esboço em alto nível do workflow que será refinado com a ajuda dos raciocinadores até atingir o nível ideal para execução. O refinamento não necessita ser homogêneo, sendo que fases intermediárias e finais podem ser refinadas à medida que as fases iniciais se encerram, produzindo resultados e novas informações para o gerente e os raciocinadores.

As duas questões principais a serem respondidas:

Que mecanismos podem mapear requisitos abstratos de usuários em comandos distribuídos executáveis que coordenam vários serviços distribuídos heterogêneos e recursos com capacidades apropriadas para atingir esses requisitos?

Que mecanismos podem gerenciar e coordenar os recursos disponíveis permitindo uso e acesso global eficiente dada a escala e complexidade das aplicações possíveis com essa infra-estrutura heterogênea e distribuída?

Comentário:

Um bom artigo relatando como se usar sistemas multi-agentes distribuídos para a construção e adaptação de workflows em grades computacionais. Não é mencionado explicitamente, mas a necessidade de utilizar semântica e meta-dados na grade é crucial para o funcionamento do sistema.