• Nenhum resultado encontrado

3 O M´ etodo de Certifica¸ c˜ ao de

3.2.2 Dimens˜ ao Base

A primeira dimens˜ao do m´etodo de certifica¸c˜ao ´e denominada dimens˜ao base. Esta dimens˜ao tem como objetivo certificar que as invoca¸c˜oes de servi¸cos web semˆanticos con- tidas na defini¸c˜ao do workflow est˜ao sendo usadas em conformidade com suas defini¸c˜oes. A an´alise considera a compatibilidade dos argumentos da invoca¸c˜ao do servi¸co em rela¸c˜ao aos parˆametros formais dados na defini¸c˜ao do servi¸co, a qual ´e decidida com base no grau de similaridade semˆantica entre os conceitos ontol´ogicos associados aos argumentos e aos parˆametros formais.

O contexto no qual este trabalho est´a inserido n˜ao ´e controlado, ou seja, a defini¸c˜ao dos servi¸cos semˆanticos ´e dada pelos provedores dos servi¸cos, ao passo que a defini¸c˜ao do workflow ´e dada por um agente distinto. Dessa forma, a verifica¸c˜ao precisa considerar os diferentes nomes de identificadores usados para nomear os parˆametros do servi¸co e para nomear os argumentos na invoca¸c˜ao do servi¸co. Para resolver esta incompatibilidade de nomenclatura entre os parˆametros e os argumentos, definiu-se um mapeamento entre eles considerando cada invoca¸c˜ao de servi¸co.

O mapeamento define um conjunto de pares associando os identificadores usados na defini¸c˜ao do servi¸co web semˆantico e os identificadores usados na invoca¸c˜ao do servi¸co. Os pares de identificadores (i.e., hiddef, idinvi) s˜ao determinados a partir da an´alise da

similaridade semˆantica entre os conceitos associados aos identificadores. O grau de si- milaridade semˆantica requerido para estabelecer o mapeamento entre os identificadores (iddef e idinv) ´e Exato ou Plugin.

Defini¸c˜ao 3.2.1 (Mapeamento da Invoca¸c˜ao) Dados dois conjuntos de identificado-

res IDdef e IDinv representando, respectivamente, os identificadores da defini¸c˜ao do

servi¸co S e os identificadores da invoca¸c˜ao do servi¸co S, define-se a no¸c˜ao de mape-

amento da invoca¸c˜ao do servi¸co S como uma fun¸c˜ao Si

inv : IDdef → IDinv, tal que

Sinvi =(iddef, idinv) | SimT(T ype(iddef), T ype(idinv)) ∈ {Exato, P lugin}

onde a fun¸c˜ao T ype : ID → NC representa o conceito primitivo associado ao identificador.

A fun¸c˜ao Si

inv denota o mapeamento da i-´esima invoca¸c˜ao do servi¸co S no workflow.

O intervalo de valores assumidos para o ´ındice “i” (i.e., [1..n]) ´e dependente do n´umero de invoca¸c˜oes do servi¸co S aparecendo no workflow.

Defini¸c˜ao 3.2.2 (Invoca¸c˜ao Certificada) Uma invoca¸c˜ao de servi¸co S ´e certificada

se sua fun¸c˜ao de mapeamento Si

inv associada ´e injetiva.

A defini¸c˜ao acima expressa que uma invoca¸c˜ao de servi¸co ´e certificada se todos os parˆametros formais da defini¸c˜ao do servi¸co web semˆantico (invocado) possuem um ar- gumento correspondente na invoca¸c˜ao do servi¸co. A propriedade injetora da fun¸c˜ao de mapeamento garante que todas as entradas/sa´ıdas requeridas/produzidas pela execu¸c˜ao do servi¸co s˜ao providas na invoca¸c˜ao do servi¸co.

Se todas as invoca¸c˜oes de servi¸cos web semˆanticos contidas no workflow s˜ao certifi- cadas, pode-se concluir que o workflow ´e certificado na base, conforme estabelecido pela defini¸c˜ao a seguir.

Defini¸c˜ao 3.2.3 (Workflow certificado na base) Um workflow W ´e certificado na base se cada invoca¸c˜ao de servi¸co aparecendo em W ´e certificada.

Resumidamente, a certifica¸c˜ao da dimens˜ao base pode ser descrita pelo seguinte pro- cedimento:

• Para cada invoca¸c˜ao de servi¸co S aparecendo no workflow, o algoritmo computa o grau de similaridade semˆantica dos pares de conceitos dados por IDdef× IDinv (i.e.,

todas as combina¸c˜oes poss´ıveis entre os conceitos usados como parˆametros formais do servi¸co IDdef e como argumentos da invoca¸c˜ao IDinv).

• O grau de similaridade semˆantica entre os conceitos ´e computado pelo servi¸co de inferˆencia de subsun¸c˜ao de conceitos provido pelo raciocinador DL, produzindo como resultado um dos graus de similaridade semˆantica dados na defini¸c˜ao 3.1.3 (i.e.,

Exato, Plugin, Subsume ou Disjunto).

• O conjunto de pares de conceitos com grau de similaridade semˆantica computado como Exato ou Plugin (conforme defini¸c˜ao 3.2.1), produz o mapeamento Si

inv para

a i-´esima invoca¸c˜ao do servi¸co S.

• Ap´os o estabelecimento dos mapeamentos de cada invoca¸c˜ao de servi¸co, o algoritmo determina se dimens˜ao base ´e certificada ou n˜ao, verificando a propriedade injetora do mapeamento associado a cada invoca¸c˜ao de servi¸co (conforme defini¸c˜oes 3.2.2 e 3.2.3 ).

1 o n t o l o g y ecommerce = ” h t t p : / / l o c a l h o s t : 1 8 0 8 0 / semanticPEWS/ o n t o l o g i e s /eCommerce . owl ” 2 3 // c o n c e i t o s 4 c o n c e p t C r e d e n t i a l = ecommerce :”# C r e d e n t i a l ” 5 c o n c e p t S e s s i o n = ecommerce :”# S e s s i o n ” 6 c o n c e p t R e g i s t e r e d = ecommerce :”# R e g i s t e r e d ” 7 8 // v a r i a v e i s 9 v a r i a b l e s e s s i o n ofType S e s s i o n 10 v a r i a b l e c r e d ofType C r e d e n t i a l 11 v a r i a b l e r e g ofType R e g i s t e r e d 12 13 // d e f i n i c a o dos s e r v i c o s web s e m a n t i c o s

14 s e r v i c e s i g n I n = ” h t t p : / / . . . / semanticPEWS/ s e r v i c e s / ecommerce / s i g n I n S e r v i c e . owl ”

15 s e r v i c e c r e a t e A c c t = ” h t t p : / / . . . / semanticPEWS/ s e r v i c e s / ecommerce / c r e a t e A c c t S e r v i c e . owl ”

16 17 // pre−c o n d i c a o da e s p e c i f i c a c a o 18 @pre[ ] 19 20 // d e f i n i c a o do w o r k f l o w 21 c r e a t e A c c t (< c r e d >, <s e s s i o n >) ; 22 s i g n I n (< c r e d >, <s e s s i o n >) 23 24 // pos−c o n d i c a o da e s p e c i f i c a c a o 25 @post[ ]

Figura 9: Workflow com as se¸c˜oes de declara¸c˜ao para verifica¸c˜ao da dimens˜ao base. Considere o workflow definido na Figura 9. O workflow ´e definido pela composi¸c˜ao se- quencial de duas invoca¸c˜oes de servi¸cos (createAcct e signIn), al´em das se¸c˜oes preliminares referentes `as declara¸c˜oes de ontologias, conceitos, vari´aveis e servi¸cos web semˆanticos.

Neste caso, a fun¸c˜ao createAcctinv define o mapeamento dos parˆametros formais da

defini¸c˜ao do servi¸co createAcct e dos argumentos da invoca¸c˜ao. O mapeamento ´e re- presentado pelo conjunto de pares ordenados {(c, cred), (s, session)}. Este conjunto de pares ordenados ´e computado a partir da an´alise do grau de similaridade semˆantica entre os pares IDdef × IDinv aparecendo como entradas do servi¸co e, tamb´em para os pares

aparecendo como sa´ıdas do servi¸co. Neste exemplo, como a entrada e a sa´ıda do servi¸co

createAcct s˜ao definidas apenas por um parˆametro, o produto cartesiano dos parˆametros

de ambos (entrada e sa´ıda) ´e formado por um ´unico par ordenado, i.e., {(c, cred)} e {(s, session)}.

Dessa forma, basta computar o grau de similaridade semˆantica entre estes pares or- denados para concluir se a fun¸c˜ao createAcctinv ´e injetiva ou n˜ao. Para o par ordenado

{(c, cred)}, tem-se que Type(c)=Credential e Type(cred)=Credential. Aplicando a fun¸c˜ao SimT para este par ordenado, obtˆem-se trivialmente que

SimT(Credential, Credential) = Exato

Type(session)=Session. Aplicando a fun¸c˜ao SimT para este par ordenado, obtˆem-se que

SimT(ClosedSession, Session) = P lugin

devido ao relacionamento hier´arquico ClosedSession ⊑ Session existente entre os con- ceitos, o qual ´e inferido a partir do axioma de equivalˆencia Session ≡ OpenSession ⊔ ClosedSession definido na terminologia. Assim, a partir deste conjunto de pares ordena- dos, conclui-se que a fun¸c˜ao createAcctinv ´e injetiva (defini¸c˜ao 3.2.2).

Aplicando-se o mesmo racioc´ınio para a invoca¸c˜ao do servi¸co signIn, conclui-se que a fun¸c˜ao signIninv tamb´em ´e injetiva. Portanto, uma vez que todas as invoca¸c˜oes s˜ao

certificadas (conforme defini¸c˜ao 3.2.3), conclui-se que o workflow da Figura 9 ´e certificado na base.

Considera¸c˜oes A certifica¸c˜ao desta dimens˜ao baseia-se, essencialmente, na an´alise da compatibilidade semˆantica entre os conceitos ontol´ogicos associados aos argumentos usados na invoca¸c˜ao e os parˆametros formais do servi¸co. A compatibilidade entre os parˆametros e argumentos ´e definida com base na similaridade semˆantica entre eles, a qual baseia-se no relacionamento de subsun¸c˜ao (hierarquia) entre os conceitos dados pelas defini¸c˜oes terminol´ogicas da base de conhecimento.

A certifica¸c˜ao da dimens˜ao base propicia maior flexibilidade na invoca¸c˜ao dos servi¸cos web semˆanticos, uma vez que n˜ao requer que os argumentos da invoca¸c˜ao sejam informa- dos na mesma ordem que os parˆametros do servi¸co foram definidos. Al´em da flexibiliza¸c˜ao na ordem dos argumentos e parˆametros, ´e poss´ıvel certificar invoca¸c˜oes de servi¸cos envol- vendo conceitos sintaticamente distintos, por´em semanticamente compat´ıveis, atrav´es do emprego do racionador DL para computar a rela¸c˜ao de subsun¸c˜ao entre os conceitos.

Documentos relacionados