A OWL-S (Martin, Burstein et al., 2004) surge do projecto DARPA Agent Markup Language – DAML (DAML, 2000) e foi submetida ao W3C em Novembro de 2004 na versão 1.1. A OWL-S é uma ontologia para a descrição de Web Services baseada em OWL que oferece aos fornecedores de Web Services um conjunto de construtores de linguagens de marcação, para descrever propriedades e capacidades dos Web Services, de uma forma inequívoca e interpretável por agentes de software. A utilização do OWL-S nos Web Services facilita a automatização de tarefas com estes, incluindo a descoberta, execução, composição e inter- operação.
Para que a semântica de Web Services se torne uma realidade, a linguagem de marcação deve ser descritiva suficientemente de forma a que um agente de software possa determinar o seu
significado. Por isso a OWL-S foi desenvolvida para ser capaz de fornecer a automatização da descoberta, invocação, composição e inter-operação de Web Services. A OWL-S irá permitir aos utilizadores e agentes de software localizar, seleccionar, executar, compor e monitorizar
Web Services de um modo automático.
A estruturação da ontologia OWL-S é dividida conceptualmente em quatro sub-ontologias de forma a descrever três características de conhecimento sobre os serviços:
− “o que faz o serviço?” – para responder a esta pergunta é utilizada a ontologia
Profile. Para capturar esta perspectiva, cada instância da classe Service apresenta
através da propriedade presents uma classe ServiceProfile;
− “como é utilizado?” – quem descreve esta informação é a ontologia Process. Esta perspectiva é capturada pela classe ServiceModel. Instâncias da classe Service usam a propriedade describedBy para se referir à classe ServiceModel do serviço;
− “como se interage com ele?” – quem contém essas informações é a ontologia
Grounding. Fornece detalhes sobre o serviço (ex: formato das mensagens,
protocolo de transporte, endereços). Instâncias da classe Service tem uma propriedade supports que se refere à classe ServiceGrounding.
A quarta ontologia Service contém o conceito Service que junta os conceitos ServiceProfile,
ServiceModel e ServiceGrounding, através das propriedades presents, describedBy e supports,
como ilustra a Figura 4.4.
As classes que identificam cada uma das sub-ontologias são: a classe ServiceProfile que identifica a sub-ontologia Profile, ServiceModel que identifica a sub-ontologia Process e
ServiceGrounding que identifica a sub-ontologia Service Grounding.
Na restante secção serão apresentadas com mais pormenor cada uma das sub-ontologias enunciadas anteriormente.
4.4.1.1 Profile
A sub-ontologia Profile especifica como o serviço se anuncia ao mundo. Fornece informações que permitem a descoberta e verificação por agentes de software. Isto é, diz o que faz o serviço, quais os requisitos para ser executado com sucesso, quais as suas limitações e pode fornecer características para avaliar a qualidade de serviço (QoS). Esta sub-ontologia foi modelada para fornecer três tipos de informações: (1) informações sobre a organização que fornece o serviço; (2) a função que o serviço fornece, inclui informação sobre as entradas e os resultados que ele produz; quais os pré-requisitos para executar o serviço e os efeitos que se pode esperar com a sua execução; (3) descrição sobre as propriedades do serviço, como por exemplo a categoria do serviço segundo o sistema de classificação UNSPSC (UNSPSC, 1998), avaliação da qualidade do serviço, entre outros.
A informação essencial que no perfil do serviço vai ter um papel chave durante o processo de descoberta de serviços é a especificação da funcionalidade do serviço. A funcionalidade do serviço é descrita através da descrição das entradas/saídas/pré-condições/efeitos (IOPE). Os dois primeiros representam informação de transformação e o dois últimos representam informação de alteração de estado. Na Tabela 4.1 são apresentadas as propriedades da sub- ontologia profile que permitem cria o perfil de um serviço OWL-S.
Tabela 4.1 – Propriedades da sub-ontologia Profile.
Propriedades Descrição resumida
presents Descreve a relação entre a instância do serviço e a instância do perfil. Basicamente diz o que o serviço é descrito através de um perfil presentedBy É o inverso da propriedade anterior
ServiceName Nome do serviço que é oferecido textDescription Breve descrição sobre o serviço
contactInformation Informação sobre os responsáveis do serviço hasParameter Parâmetro do serviço (inclui entradas e saídas) hasInput Entradas do serviço
hasOutput Saídas do serviço hasPrecondition Pré-condições do serviço
hasResult Especifica um dos resultados do serviço
serviceParameter Lista expansível de propriedades que podem acompanhar uma descrição do perfil
serviceCategory Referência a uma ontologia ou taxonomia de serviços serviceParameterName É o nome do parâmetro actual
sParameter Aponta para um valor de uma parâmetro que pertence a uma ontologia OWL
categoryName Nome da categoria actual taxonomy Referência a uma taxonomia
Value Aponta para um valor numa taxonomia Code Código associado a uma taxonomia
serviceClassification Define um mapeamento para uma ontologia de serviços, como uma especificação NAICS (NAICS, 1992)
serviceProduct Define o mapeamento para uma ontologia de produtos, como uma especificação UNSPSC
Um serviço OWL-S pode ter zero ou mais perfis, isto é zero ou mais instâncias da classe
Figura 4.5 – Classes e propriedades da sub-ontologia Profile (Martin, Burstein et al., 2004).
4.4.1.2 Process
A ontologia Process tem como objectivo descrever como o serviço trabalha. Para isso descreve as entradas, saídas, pré-condições e resultados da execução do serviço. A principal utilização do Service Model é permitir a invocação, publicação, composição, monitorização e recuperação (caso a execução de um serviço falhe) de um Web Service. O modelo de serviço vê a iteração de um serviço como um processo. É importante referir que um processo não é um programa a ser executado, mas antes uma especificação dos modos como um cliente interage com o serviço. A Figura 4.6 mostra as classes e propriedades do modelo de processo.
Um processo envolve pelo menos duas partes: o cliente e o serviço. Ambos são referidos como participantes e são directamente ligados ao processo usando a propriedade
hasParticipant. As entradas e saídas especificam a transformação de dados produzido pelo
processo e estão ligadas ao processo através da utilização das propriedades hasInput e
hasOutput. As entradas especificam a informação que o processo necessita para a sua
execução e podem vir directamente do cliente ou de outro serviço. As saídas especificam a informação que é gerada após a execução. A presença de uma pré-condição significa que o processo não pode ser executado a não ser que esta seja satisfeita. As pré-condições estão ligadas aos processos através da propriedade hasPrecondition. A execução do processo pode provocar a alteração de estado e a geração de informação por parte do Web Service. Essas
saídas e efeitos estão ligadas ao processo através da propriedade hasResult.
Figura 4.6 – Ontologia do modelo de processo (Martin, Burstein et al., 2004).
Existem três tipos de processos identificados pelo OWL-S: (1) processo atómico, que corresponde às acções que um serviço pode realizar numa única iteração; (2) processo simples, que apenas fornece um mecanismo de abstracção para fornecer múltiplas vistas (modo de utilização) do mesmo processo, vistas estas que podem ser usadas para fornecer uma vista diferente de um processo atómico; (3) processo composto, é um processo que pode ser decomposto noutros processos (compostos, simples ou atómicos. São construídos a partir de processos atómicos e/ou simples e através do uso de construtores de controlo (Tabela 4.2), mais a informação adicional sobre o fluxo de dados (ex: que saídas são encaminhas para determinadas entradas).
Tabela 4.2 – Construtores de controlo OWL-S.
Construtores Descrição resumida dos construtores de controlo
Sequence Conjunto de processos a serem executados sequencialmente Split Conjunto de processos a serem executados concorrentemente Split+Join Consiste numa execução concorrente com um ponto de sincronização
de processos
Choise Invoca para execução um único controlo de um grupo de construtores de controlo
Any-Order Permite a execução aleatória de componentes de processos, mas não concorrentemente
If-Then-Else
Estrutura de controlo, que tem as propriedades ifCondition, then e else. Significa testar a condição e se verdadeira então Verdadeiro senão Falso
Iterate
Estrutura de controlo que executa diversas vezes um processo. Não faz referência a quantas iterações são feitas, quando acabar/finalizar ou retomar uma pausa
Repeat-While Iteração enquanto um determinada condição é falsa ou verdadeira Repeat-Until Semelhante ao anterior
Existe uma relação entre as sub-ontologias Profile e Process. Como já foi dito, a Profile consiste na descrição do serviço para o anunciar, mas após este ser seleccionado essa descrição não é mais utilizada. Em vez disso, o cliente vai usar a sub-ontologia Process para controlar a iteração com o serviço. Embora a Profile e a Process tenham papeis diferentes durante a transacção com o Web Service, elas são representações diferentes do mesmo serviço. É natural esperar que as IOPEs de uma sejam reflectidas nas IOPEs da outra.
4.4.1.3 Grounding
A ontologia Grounding fornece o vocabulário para ligar a descrição conceptual do serviço especificado pelas sub-ontologias Profile e Process aos detalhes da implementação. Fazem parte desses detalhes os protocolos de comunicação, formato das mensagens e portas utilizadas para o contactar. Estas informações indicam o modo como um agente pode aceder a um serviço.
O ServiceGrounding estabelece a ponte entre o Semantic Web Service e uma implementação concreta do Web Service descrito em WSDL. O mapeamento entre o ServiceGrounding do serviço OWL-S e a descrição WSDL é feita de acordo com três regras :
− cada entrada de um AtomicProcess é mapeada numa mensagem de entrada de uma operação WSDL. O mesmo se passa para as saídas, cada saída de um
AtomicProcess é mapeada a uma mensagem de saída da operação WSDL;
− as entradas e saídas do processo atómico OWL-S podem ser descritas utilizando tipos de dados XML Schema ou um conceito OWL (ex. classes OWL).
A OWL-S permite o mapeamento de um processo atómico numa operação WSDL e as suas entradas e saídas em mensagens WSDL. Quando é feito este mapeamento podem acontecer duas situações: (1) essas entradas e/ou saídas são do tipo de dados simples do XML Schema (ex. string, inteiros) e o mapeamento é directo; (2) se forem tipos de dados complexos (ex. estruturados) há necessidade de usar transformações XSLT nesse mapeamento, para fazer a transformação dos dados representados em OWL para o XML Schema utilizado na WSDL. Por exemplo, quando se pretende transformar uma descrição WSDL que utilize estruturas complexas em XML Schema para uma descrição OWL-S cuja estrutura terá que ser transformada numa ontologia. Embora WSDL seja a única tecnologia definida em grounding para a OWL-S, no entanto, esta última não está restrita apenas à WSDL como tecnologia de serviços, e deve ser percebida como uma ontologia genérica para descrição de serviços que é extensível a outros mecanismos de grounding.
4.4.1.4 Criar um Serviço OWL-S
Em (Alesso, 2006) é descrito o processo de criação de um Web Service Semântico utilizando a OWL-S através de cinco passos fundamentais:
1. descrever a funcionalidade que o serviço oferece – o modelo de processo fornece a descrição declarativa para as propriedades do serviço;
2. descrever o grounding de cada processo atómico – deve-se relacionar cada processo atómico com o seu grounding;
3. descrever composição de processo atómicos – descrever o processo composto que é uma composição de processos atómicos;
4. descrever o processo simples para o serviço (opcional);
5. descrever o perfil do serviço que é parcialmente preenchido pelas propriedades já declaradas no primeiro passo.