Interfejsy zewnętrzne – usługi sieciowe
3.3. Analiza szczegółowa Systemu
3.3.1. Moduł gromadzenia danych — Data Collection Module (DCM)
DCM jest modułem agentowego systemu wyszukiwania (ang. Agent-‐Based Search System – ABSS) odpowiedzialnym za nadzorowanie stanu metadanych w repozytoriach, aktualizację danych do centralnego repozytorium metadanych ABSS oraz wstępną analizę zasobów [10, 33].Rdzeniem DCM jest platforma agentowa powstała w oparciu o JADE-‐LEAP [16]. Agenci związani funkcjonalnie z realizacją zadań DCM to:
• Content Manager Agent (CMA) wraz z Collector Manager Agent (C2MA);
• Collector Agent (CA);
• Converter Agent (CV);
oraz agenci wchodzący standardowo w skład platformy JADE: • AMS (Agent Management System);
• DF ( Directory Facilitator).
Istotnym elementem DCM jest baza danych DB_LOMS zawierająca szczegółowe informa-‐ cje przetworzone przez agentów, a opisujące stan metadanych repozytoriów. Schemat struktury zależności pomiędzy komponentami DCM został przedstawiony na rys. 52.
Rysunek 52. Schemat komunikacji pomiędzy elementami składowymi DCM
Opis zadań agentów DCM został przedstawiony w tabeli 13.
Tabela 13: Zadania realizowane przez agentów DCM
agent realizowane zadania
CMA
Content Manager Agent
Jest kluczowym elementem DCM. Istnieje tylko jedna instancja tego agenta. CMA okresowo komunikuje się z AMS w celu weryWikacji repozytoriów dostęp-‐ nych w systemie. W przypadku pojawienia się nowego repozytorium CMA tworzy swoją kopię określaną jako C2MA i przekazuje jej informacje dotyczące nowego repozytorium.
C2MA
Collector Manager Agent
Stanowi kopię CMA dedykowaną do obsługi repozytorium. Pojedynczy C2MA przypisany jest tylko do jednego repozytorium. Jest odpowiedzialny za wysłanie odpowiedniego CA do kontenera zdalnego umieszczonego po stronie obsługiwa-‐ nego repozytorium, a następnie za komunikację z wysłanym tam CA. W przy-‐ padku odebrania danych od CA C2MA informację tę przetwarza i zapisuje do bazy DB_LOMS, a następnie informuje CV o pojawieniu się nowych rekordów w bazie.
CA
Collector Agent
Odpowiada za śledzenie zmian w LOM zgromadzonych po stronie danego repozytorium. Jest tworzony przez C2MA i przesyłany o ile jest taka możliwość do kontenera zdalnego po stronie danego repozytorium. Komunikacja z repozyto-‐ rium odbywa się poprzez OAI-‐PMH. Otryamane dane są wstępnie analizowane przez CA po stronie repozytorium, a następnie przesyłane do C2MA w postaci obiektów Javy.
CVA
Converter Agent
CV jest odpowiedzialny za analizę danych dostarczonych przez CA oraz wykona-‐ nie stosownej konwersji na potrzeby konkretnych metod wyszukiwania. Pojedynczy CVA realizuje konwersję dla pary: metoda wyszukiwania i język wyszukiwania. Tego typu organizacja zasobów została wprowadzone celem przyspieszenia wyszukiwania oraz faktu, iż często zasoby dostępne są w ograni-‐ czonej liczbie języków. Dane skonwertowane są zapisywane w bazie danych DB_METHODS wchodzącej w skład modułu zaawansowanego wyszukiwania informacji.
AMS
Agent Management System
Jest to główny agent platformy JADE odpowiedzialny za zarządzanie agentami i kontenerami tworzącymi spójną platformę agentową.
CMA komunikuje się z AMS w celu uzyskania informacji o kontenerach zdalnych i otrzymuje od niego aktualną informację dotyczącą stanu platformy agentowej a w szczególności kontenerów zdalnych przypisanych do repozytoriów oraz stanu agentów CA tam wysłanych. Informacja ta jest każdorazowo gromadzona w celu monitorowania zmian dzięki czemu CMA może reagować na takie stany jak: zgło-‐ szenie się nowego repozytorium, wyłączenie repozytorium czy problemy z agen-‐ tami CA w danym kontenerze zdanym.
DF
Directory Facilitator
Odpowiada za świadczenie usługi Yellow Pages pozwalającej uzyskać informacje o agentach które zarejestrowały się w usłudze. DF jest wykorzystywany w celu uzyskania listy wszystkich CVA dostępnych w systemie. Wywołanie metody: DFService.search() pozwala uzyskać stosowną listę agentów.
3.3.1.1. Szczegółowa struktura komunikacji pomiędzy lokalnymi a zdalnymi składowymi modułu
Moduł DCM oparty jest o kontener główny platformy JADE oraz kontenery poboczne które są oferowane jako pakiet do instalacji po stronie repozytorium metadanych syste-‐ mów LMS. W skład DCM wchodzą zarówno agenci statyczni oraz agenci mobilni. Celem DCM jest nadzór nad metadanymi, a następnie ich gromadzenie po stronie serwera na którym uruchomiony jest kontener główny. Dane zgromadzone poprzez DCM są prze-‐ twarzane w celu zapewnienia wydajnego wyszukiwania przez moduł ASM. DCM i ASM stanowią ABSS (Agent-‐Based Search System) który powstał w celu wskazania alterna-‐ tywy dla FS (Federated Search) oferowanych obecnie przez systemy rozproszonych repozytoriów platform e-‐learningowych. DCM kontroluje informacje o stanie repozyto-‐ riów wchodzących w skład federacji kontaktując się z systemem brokerskim. Rozwiąza-‐ nie to choć wydaje się być nadmiarowe zostało wprowadzone celem zapewnienia zaawansowanego wyszukiwania użytkownikom również z uwzględnieniem danych zgro-‐ madzonych
w systemach LMS nie wspierających platformy ABSS. Schemat pobierania danych (ang.
data harvesting) pomiędzy repozytoriami federacji, a DCM został przedstawiony na
rysunku 53. ! LOM HARVESTING autoryzacja OAI-PMH jicpABSS !"#$%" !"#$% &!''( )*+( !"#$% !"#$% !"#$%
Rysunek 53. Zależności pomiędzy federacją repozytoriów a systemem ABSS
W obu przedstawionych na rysunku scenariuszach istotną rolę pełni agent CMA (oraz jego dedykowane kopie: C2MA), który jest odpowiedzialny za cały proces obsługi repozytoriów, w tym transfer agenta CA i pobieranie stosownych metadanych. Z uwagi
na charakter systemu obsługiwane są również repozytoria nie wspierające platformy agentowej dlatego też agent CA może mieć charakter statyczny lub mobilny (Rys. 54).
! LMS SERVICE autoryzacja OA I-PMH OA I-PMH jicpABSS !"#$% !"#$%" CA &!'' ()* !"#$% !"#$% CA CMA
Rysunek 54. Architektura DCM z uwzględnieniem charakteru agentów CA
Scenariusze pobierania danych
Przeanalizowano trzy scenariusze pobierania danych:
• w oparciu o dane uzyskane z systemu brokerskiego (Brokerage System) i komunikację przez sieć w oparciu o protokół OAI-‐PMH;
• poprzez platformę agentową i wprowadzoną tam obsługę agentów (LMS service) oraz komunikację lokalną po stronie repozytorium w oparciu o OAI-‐PMH;
• jak wyżej ale w oparciu o serwis SparkOAI.
W pierwszym przypadku agent CMA pobiera informację o repozytoriach podłą-‐ czonych do Federacji komunikując się z systemem brokerskim. Następnie tworzeni są agenci CA reprezentujący każde z repozytoriów wchodzących w skład Federacji. Każdy agent CA wywołuje metody brokera w celu uzyskania od niego parametrów koniecznych do nawiązania połączenia z konkretnym repozytorium przez niego obsługiwanym. Każde repozytorium rejestrując się u brokera musi zostać uwierzytelnione poprzez wprowadzenie swoich parametry (np. nazwy i powiązanego z nim hasła). Uwierzytelnia-‐ nie (ang. authentication) dokonywane jest poprzez usługi web service, a komunikacja jest dodatkowo szyfrowana (w oparciu o SSL/TLS). Taki sam proces musi zostać wyko-‐ nany przez każdego agenta CA chcącego uzyskać dostęp do repozytorium. Jeśli uwierzy-‐ telnianie się powiedzie tworzona jest sesja, a token sesji jest zwracany jako wynik poprawnego uwierzytelnienia. W kolejnym etapie następuje autoryzacja której poprawny wynik zapewnia dostęp do zasobów repozytorium. W takim przypadku CA rozpoczyna proces pobierania danych poprzez OAI-‐PMH. Opisy obiektów niekoniecznie muszą dotyczyć zasobów zgromadzonych lokalnie lecz mogą wskazywać na inne lokacje w Federacji. Proces pobierania danych ma charakter selektywny pobierane są dane nowe lub te w których dokonano zmiany ewentualnie pobierana jest informacja o meta-‐ danych które zostały usunięte z repozytorium. Tylko w przypadku dodania nowego
repozytorium do federacji pobierane są wszystkie dane.
W dwóch pozostałych przypadkach komunikacja bazuje na serwisie LMS stano-‐ wiącym kontener zdalny platformy agentowej czyli części DCM. Komunikacja z brokerem w tym przypadku nie zachodzi.
Serwisy LMS i SparkOAI zapewniają dostęp do zasobów lokalnych agentowi mobilnemu CA po stronie repozytorium. SparkOAI stanowi implementację interfejsu OAI-‐PMH zapewniając bezpośredni dostęp do zasobów poprzez lokalne wywołanie metod.
Protokół OAI-‐PMH tworzy niezależny od języka programowania i systemu operacyjnego szkielet zapewniający dostęp do zasobów (metadata harvesting). Szkielet oparty jest o dwie klasy: Data Provider (dostawcy danych, pozwala udostępniać zasoby poprzez OAI-‐PMH) i Service Provider (dostawcy usług, zapewnia mechanizmy tworzenia usług opartych o pobieranie danych w oparciu o OAI-‐PMH)
Agent CA może pobierać dane lokalne zarówno o OAI-‐PMH realizowane poprzez zapyta-‐ nia protokołem HTTP (metody GET lub POST) jak i poprzez wykorzystywanie metod serwisu SparkOAI.