Semantyczny rejestr usług sieciowych

- autor: tsissput

Cel projektu

Pomysł na semantyczny opis i wyszukiwanie usług sieciowych nie jest nowy, ale jak dotąd nie powstało rozwiązanie, które spotkałoby się z powszechną akceptacją.  Powodów takiego stanu rzeczy należy upatrywać przede wszystkim w skomplikowanym i trudnym w opisie modelu Big Web Services opartym na protokole SOAP. Sprowadza się on w zasadzie do zdalnego wywoływania metod za pośrednictwem rozbuchanego, nadmiarowego i pod wieloma względami dublującego funkcjonalność protokołów transportowych (np. HTTP) formatu XML, co wiąże się z nieograniczoną dowolnością wykonywanych operacji.  Każda próba wzbogacenia takich usług o informację semantyczną wymaga zarówno dodatkowego powiększenia i tak już „ciężkiej” koperty SOAPowej, jak też bardzo indywidualnego podejścia do semantycznego opisu każdej usługi z osobna.

W związku z powyższym, zdecydowaliśmy się ograniczyć zakres projektu do usług zgodnych z paradygmatem REST. Pozwala to na wprowadzenie swojego rodzaju „wspólnego mianownika” dla opisywanych usług, który wynika ze ściśle określonego związku architektury usług z wykorzystanym protokołem transportowym (praktycznie zawsze HTTP lub HTTPS). Ogromnym ułatwieniem jest tu porzucenie potencjalnie nieskończonej (w przypadku usług typu Big Web Services) przestrzeni możliwych operacji, na rzecz tej, którą tworzą metody protokołu HTTP. Ponadto, w przypadku usług RESTowych, mamy pewność, że zakres operacji jest jasno określony przez adres URL zasobu. Nie jest konieczne wnikanie w ciało żądania by określić na jakich danych wykonujemy jakąś czynność.

Należy wspomnieć, że sam paradygmat REST jest pojęciem o bardzo wysokim poziomie abstrakcji i sam w sobie nie definiuje żadnych szczegółów implementacji usług. W projekcie zakładamy zgodność usług z jego konkretną interpretacją opartą na protokole HTTP, a mianowicie z architekturą zorientowaną na zasoby (ang. Resource Oriented Architecture – ROA). Termin ten został zaproponowany przez Leonarda Richardsona i Sama Ruby’ego w książce Semantic Web Services (wyd. O’Reilly).

verbs

Kolejną rzeczą, na którą należy zwrócić uwagę jest fakt, że koncepcja globalnych rejestrów usług nie zyskała powszechnej aprobaty. Samo skłonienie setek niezależnych podmiotów do utrzymywania takich rejestrów jest zadaniem trudnym. Opracowując nasze rozwiązanie nie kierowaliśmy się ambicjami stworzenia takiego rejestru. Nasza aplikacja jest przeznaczona do użytku w zastosowaniach lokalnych, na skalę pojedynczych przedsiębiorstw czy systemów informatycznych

Semantyka

Ograniczenie się do opisu usług RESTowych pozwoliło na opracowanie stosunkowo nieskomplikowanej ontologii opisującej architekturę zorientowaną na zasoby. Do opisu każdej usługi potrzeba w ogólności trzech elementów:

  • Ontologii REST-HTTP opisującej pojęcia związane z ROA, takie jak: zasób, adres URL, nagłówek HTTP, ciało odpowiedzi, operacja tworzenia zasobu, metoda GET, etc.
  • Ontologii dziedzinowej opisującej biznesową interpretację zasobów. Pojęcia w niej zawarte to na przykład: pacjent, kolejka na badanie, wpis w karcie, grupa krwi, etc. Należy tu wspomnieć, że w ogólności każda usługa może być opisana przy pomocy dowolnej liczby ontologii dziedzinowych, które mogą być łączone w celu poszerzenia opisu semantycznego.
  • Ontologii opisującej konkretną usługę zawierającej przede wszystkim instancje klas zdefiniowanych w pozostałych ontologiach.

Pozwala to na elastyczne mapowanie udostępnianych przez usługi zasobów w kontekście ROA na abstrakcyjne zasoby opisane w ontologiach.

Zakłada się ponadto, że każdy złożony zasób (na przykład Lekarz) interpretowany jako instancja pewnej klasy z ontologii, składa się z pewnej liczby podzasobów atomowych o typach prostych reprezentowanych przy pomocy typowanych literałów.  Zarówno zasoby złożone, jak i atomowe, są wiązane w stosunku 1:1 z pojęciami z ontologii dziedzinowej.

Oto kilka przykładów zapytań w języku naturalnym, które można wyrazić przy pomocy opisanego powyżej zestawu ontologii:

  • Znajdź usługę, która umożliwia pobranie kolekcji pacjentów leczonych na zapalenie płuc bez podawania dodatkowych parametrów
  • Znajdź usługę, która pozwoli na utworzenie nowego zasobu oznaczającego pojęcie pacjent w kontekście kolejki na badanie rentgenowskie, przy założeniu że znam PESEL, imię i nazwisko pacjenta.
  • Dysponuję numerem książeczki ubezpieczeniowej pacjenta. Jakich jeszcze parametrów potrzebuję by wykonać zapytanie tworzące zasób reprezentujący tego pacjenta przy pomocy usługi X?

Implementacja rejestru

Oczywiście sama ontologia to za mało by wykorzystać takie zapytania w praktyce. Dokonaliśmy implementacji usługi RESTowej pozwalającej na wgrywanie ontologii i udostępniającej końcówkę SPARQL  wykorzystywaną do wykonywania zapytań do ontologii.

Wykorzystaliśmy w tym celu bibliotekę Apache Jena udostępniającą interfejsy do manipulacji danych semantycznych i ich przechowywania w bazie danych oraz silnik SPARQL. Interfejst REST usługi oparto na bibliotece Jersey implementującej standard JAX-RS. Widoki stworzono w technologii JSP.

semreg2

Plany na przyszłość

Opracowana aplikacja stwarza szereg interesujących możliwości. Dzięki semantycznemu opisowi publikowanych usług możliwe jest tworzenie klientów aplikacyjnych, które zamiast jawnie wywoływać konkretne usługi posiadać będą jedynie zdefiniowaną w sposób deklaratywny informację o tym jaką operację należy wykonać i na jakim zasobie. Dzięki wykorzystaniu rejestru, potrzebna będzie jedynie informacja o tym, na jakie pojęcie w dziedzinie biznesowej przekłada się dany zasób.

Łatwo sobie wyobrazić sytuację, w której klient pobiera listę dostępnych usług oraz wymaganych przez nie parametrów, a następnie odpytuje rejestr w celu znalezienia usług udostępniających dane, które są potrzebne jako parametry żądania. Jeszcze prostszym zadaniem jest kompozycja formularzy HTML pozwalających na wprowadzenie wymaganych przez usługi danych przez użytkownika. Potencjalnym klientem rejestru jest rozwijany na Politechnice Poznańskiej silnik procesów biznesowych ROsWeL (ang. Resource Oriented Workflow Language).

roswelLogoWidePlainBlack50pxhi

Korzystanie z rejestru zostałoby znacznie ułatwione gdyby opis usług w językach RDF i OWL był generowany w pewnym stopniu automatycznie. Można to zrealizować przy pomocy biblioteki opartej o mechanizm adnotacji w języku Java, w sposób podobny do tego, w jaki na podstawie adnotacji JAX-RS lub JAX-WS generowane są dokumenty WADL i WSDL. W gestii programisty usług pozostałoby wtedy tylko umieszczenie odpowiednich adnotacji semantycznych obok adnotacji JAX-RS definiujących parametry i typy obiektów zwracanych przez usługi.

Powyższe założenia zamierzamy zrealizować w ramach pracy magisterskiej.

Tomasz Niedźwiedź i Paweł Pawłowski

Reklamy

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

%d blogerów lubi to: