Ontologia

Kompozycję usług sieciowych można rozumieć, jako realizację złożonego celu przy pomocy wywoływania innych usług. Poprzez to, że usługi ukrywają swoją semantykę nie ma możliwości zapoznania się z tym, jak dana usługa działa. Jedyne, co jesteśmy w stanie zrobić, to otrzymanie od takiej usługi metodą interakcji sieciowej „deklarację zadziałania”. Tzn. otrzymujemy konkretne dane na wyjściu. W procesie tym pomaga określenie odpowiednich danych wejściowych. System PlanICS ustala, która z usług powinna być wywoływana, aby dane zadanie zostało zrealizowane.
Aby usługi dały się skomponować wymogiem jest żeby pracowały na wspólnej semantyce. Krótko mówiąc powinny być opisane za pomocą tego samego języka. W PlanICS zaprezentowano jednolite semantyczne opisy typów usług w postaci Ontologii. Innymi słowy Ontologia jest zbiorem konceptów. Terminy zdefiniowane w Ontologii posiadają tzw. atrybuty, czyli cechy, które mogą być połączone ze sobą związkami dziedziczenia. Dzięki temu utworzono drzewiastą strukturę danych. Każda z usług posiada swój własny opis w tym języku terminów. Istniejące usługi o takim samym opisie nazywa się klasą usługi lub implementacją usługi abstrakcyjnej. Usługa abstrakcyjna definiuje jedynie zachowanie danej usługi przy pomocy języka Ontologii.
Jednym z założeń definiowania atrybutów jest to, że są prymitywne. To znaczy, że obiekty nie mogą być zagnieżdżane w innych obiektach. Jedynie atrybuty mogą być dziedziczone z innych obiektów. Wszystkie prymitywne typy użyte w systemie PlanICS są podzbiorem typów zdefiniowanych w XML Schema Definition Datatypes. Typy zostały wymienione, a także opisane w tabeli nr 1.

Typy PlanICS Typy XSD Opis
Int Int Typ całkowitoliczbowy
Real Float Typ zmiennoprzecinkowy
dateTime dateTime Specyfikacja czasu
Boolean Boolean Może przyjmować wartości „true” lub „false”
String String Reprezentacja typu łańcuchowego
Reference Token Referencja do obiektu

Tak jak wcześniej wspomniano poszczególne klasy w Ontologii dziedziczą jedynie atrybuty. Rysunek niżej przedstawia przykład dzidzieczenia atrubutów.

Podstawą Ontologii użytej w systemie PlanICS jest klasa Thing. Klasa ta jest bez atrybutowa. Thing posiada trzech bezpośrednich potomków: Artifact, Service oraz Stamp.

Powyższe klasy są ze sobą ściśle powiązane. Gałąź klasy Artifact reprezentuje typy obiektów, na których działają usługi dostarczone z klasy Service.

Gałąź klasy Service odpowiada za modelowanie typów usług ze świata rzeczywistego. Klasa Service posiada zdefiniowane takie atrybuty jak: in, inout, out, pre-conditions, post-conditions. Zachowanie usług abstrakcyjnych jest definiowane przy pomocy trzech zbiorów, in, inout oraz out. Każdy ze zbiorów określa poszczególne zachowania, np. która usługa powinna zostać aktywowana.

  • Zbiór „in” definiuje obiekty, które dostarczają dane od użytkownika. Użytkownik określa dane wejściowe, czyli takie obiekty, które już posiada. Np. 100 €.
  • Zbiór „inout” informuje, że atrybuty obiektów zdefiniowanych w tym zbiorze ulegną zmianie. Np. obiekt klasy samochód posiada atrybut „zepsuty”. Na specjalne życzenie użytkownika systemu, stan tego atrybutu w proponowanym przez system planie ma zostać zmieniony na „sprawny”.
  • Zbiór „out” określa, jakie obiekty zostaną wyprodukowane przez daną usługę. Np. obiekty klasy Samochód lub nawigacja GPS.

Jak już wcześniej wspomniano zdefiniowane są także tzw. pre-conditions oraz post-conditions, czyli warunki wstępne i końcowe. Na ich podstawie system zamienia to, co użytkownik posiada, w to, co jest pożądane przez użytkownika.

  • Pre-conditions definiuje, jakie warunki muszą być spełnione, aby usługa została aktywowana.
  • Post-conditions określa, jakie warunki ze zbiorów inout, out zachodzące pomiędzy obiektami zostaną spełnione po wykonaniu aktywowanej wcześniej usługi.

Warto zaznaczyć, że zawarte w Ontologii opisy usług nie zawierają konkretnych wartości. Warunki, za pomocą których opisano działanie danej usługi definiują fakty ustawienia lub nieustawienia atrybutów oraz relacje zachodzące pomiędzy obiektami. Relacje są wyrażane w formie atrybutów referencyjnych.

Trzecia gałąź usług, czyli klasa Stamp zawiera pomocnicze typy obiektów. Stamp ma na celu potwierdzenie wykonania usługi. Ponadto wypisuje niektóre cechy takie jak np. cena, marka samochodu. Założono, że każda usługa produkuje dokładnie jeden obiekt, który jest typem reprezentowanym przez gałąź Stamp. Proces ten potwierdza wykonanie usługi. Klasa Stamp posiada zdefiniowane atrybuty takie jak: level, serviceClass oraz serviceId. Ich opis został zamieszczony w tabeli niżej.


Atrybut

Typ

Opis

Level Integer Jest to pozycja, jaką zajmuje usługa w sekwencji wyprodukowanego planu
serviceClass String Nazwa klasy usługi, która wyprodukowała obiekt stamp
serviceId Integer Unikalny identyfikator usługi, która wyprodukowała obiekt stamp

 

Wartości wszystkich atrybutów są przypisywane automatycznie podczas procesu planowania. Traktowane są, jako atrybuty wyłącznie od odczytu. Nie ma możliwości ich zmiany przez żadną inną usługę. Obiekty wyprodukowane przez jakąkolwiek usługę pochodzące z klasy Artifact posiadają ustawiony atrybut createdWithStamp. Atrybut ten jest referencją do usługi wyprodukowanej przez klasę Stamp.

Ontologia jest rozszerzana o inne klasy. Każda z nowowprowadzonych klas musi być potomkiem Service, Artifact lub Stamp, a dokładniej rzecz mówiąc dziedziczyć ich atrybuty. Nie ma żadnych ograniczeń na poziomie dziedziczenia atrybutów ani liczby nowych klas. Na rysunkach niżej przedstawiono poszczególne gałęzie Ontologii.

 

Przykładowy plik ontologi: pobierz