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.
