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.