GRID GATEWAY








W niniejszym opisie prezentujemy koncepcję integracji systemy LW z zewnętrznym środowiskiem, jakim jest Grid. Projektując moduł odpowiedzialny za integrację - nazwany modułem Grid Gateway Module (GGM) - podjęto próbę stworzenia uniwersalnego rozwiązania pozwalającego nie tylko na podłączanie systemu typu Grid, ale także dowolnych innych systemów. W związku z tym moduł GG został podzielony na dwie funkcjonalne części, co prezentuje poniższy rysunek.


Ogólny schemat modułu Grid Gateway
Ogólny schemat modułu Grid Gateway



Pierwsza z części to moduł VLab GG, który jest odpowiedzialny za komunikację z innymi modułami LW oraz konwersję zadania do postaci akceptowanej przez
GG. Natomiast moduł GG odpowiedzialny jest za utworzenie opisu zadania, który jest zgodny z wymogami systemów zewnętrznych. W naszym przypadku będzie to środowisko typu Grid. Jak już wspomniano wcześniej istnieje możliwość dołączenia dowolnego systemu zewnętrznego. W tym celu należy rozszerzyć GG o plugin, którego zadaniem będzie tłumaczenie opisu zadania.

MODUŁ VLAB GG

Moduł VLab GG jest odpowiedzialny za komunikację z pozostałymi modułami Laboratorium Wirtualnego. Jednakże jego głównym zadaniem jest mapowanie zadania, które ma być przesłane z LW do Gridu. Zadanie jest tłumaczone na postać pośrednią i wysyłane do modułu GG, który w zależności o tego do jakiego systemu zewnętrznego zadanie ma być wysłane dokonuje odpowiedniej translacji. Dzięki takiemu podejściu moduły bezpośrednio związane z LW nie muszą być zmieniane. Nowe rodzaje translacji mogą być dynamicznie dołączane do modułu GG.
Algorytm mapowania zadania LW do postaci pośredniej został oparty na mechanizmie refleksji, który pozwala na dynamiczne tworzenie obiektów i wywoływanie metod na tych obiektach. Reguły translacji zapisane są w XML'u zgodnie z specjalnie zaprojektowanym schematem, który zostanie przedstawiony poniżej. Zadanie w WL opisane jest zgodnie z definicją zasobu Resource Description Schema (ang. RDS), tak więc translacja, o której mowa ma za zadanie przekształcić strukturę RDS, w strukturę pośrednią.



Struktura translacji
Struktura translacji



Na rysunku powyżej widać schemat blokowy przedstawiający operację translacji. Model powyżej dotyczy tylko jednej właściwości w opisie RDS, tak więc plik zawierający opis reguł mapujących będzie zawierał tyle linii, ile właściwości należy przemapować. Klucz RDS przedstawia właściwość, element w opisie zadania, którego wartość zostanie przepisana do obiektu reprezentowanego przez łańcuch metod po prawej stronie strzałki. Widać więc, że zaproponowany model pozwala nam na dokonanie dowolnego mapowania. Ponadto zmiany w strukturze modelu danych wymagają jedynie dostrojenia reguł mapujących. Cały mechanizm jest więc rozwiązaniem, które można wykorzystać także w innych przedsięwzięciach. Reguła translacyjna zapisana w języku XML wygląda następująco:

kluczRds=listaMetod
listaMetod=:argument_1@typ_argumentu1;argument_2@typ_argumentu2; ... | metoda 2 | ...


Każda metoda zdefiniowana jest przez dowolną, skończoną listę argumentów, każdy z argumentów definiuje także typ danych jaki reprezentuje. Metoda, jako argumenty może przyjmować stałe wartości, bądź wartości zdefiniowane w innych klasach. Z tego powodu rozszerzono definicje argumentu o możliwość definiowania stałych. Dostępne są następujące możliwości:

1. %stała@typ_argumentu np. %FILE_TYPE@pl.psnc.vlab.Constant
- pod wartość klucza zostanie podstawiona wartość stałej pl.psnc.vlab.Constant.FILE_TYPE

2. $wartość@typ_argumentu np. $17.67@java.lan.Float
- pod wartość klucza zostanie podstawiona wartość 17.67



MODUŁ GG

Moduł GG jest centralnym elementem złącza pomiędzy systemem LW a środowiskiem Grid. Jego główną odpowiedzialność stanowi przyjmowanie od opisanego wyżej modułu VLab GG zleceń zadań opisanych w ustalonym formacie pośrednim i przekazywanie ich do środowiska Grid. Poza tym moduł ma za zadanie przyjmować od środowiska Grid notyfikacje o zmianach statusu zadań i przekazywanie ich do VLab GG. Te relacje pomiędzy modułami pokazano ogólnie na rysunku
"Ogólny schemat modułu Grid Gateway".



SCHEMAT BLOKOWY

GG zaprojektowano tak, że możliwe jest połączenie go z dowolnym systemem zewnętrznym, pod warunkiem że ten drugi udostępnia odpowiedni język definicji zadań, np. w postaci XML Schema. Definicja zadania we wspomnianym formacie pośrednim jest tłumaczona na język właściwy dla systemu zewnętrznego i przekazywana do niego. Schemat blokowy tego przekształcenia pokazano na rysunku poniżej.


Schemat blokowy modułu Grid Gateway
Schemat blokowy modułu Grid Gateway



Połączenie 1 wskazuje na operację zlecenia zadania w postaci pośredniej z modułu VLab GG do modułu GG. Moduł GG wybiera system zewnętrzny, do którego trafi zadanie i tłumaczy jego definicję na język właściwy dla tego systemu. Następnie zleca zadanie do wybranego systemu (3).
Połączenie 4 wskazuje na operację przekazania notyfikacji o zmianie statusu zadania z systemu zewnętrznego do modułu GG. Moduł GG przekazuje ją następnie do modułu VLab GG, który jest odpowiedzialny za przekazanie jej dalej do modułu monitoringu systemu LW (2).




JĘZYK POŚREDNI DEFINICJI ZADAŃ

Dla potrzeb ogólności i niezależności opisu zadań, stworzono język ich opisu zwany dalej GGJDL (grid gateway job definition language). Format ten jest wykorzystywany na styku modułów VLab GG i GG i składa się ze zbioru klas pozwalających na opisanie poszczególnych elementów definicji zadania, takich jak program, dane i środowisko wykonania oraz ograniczenia czasowo-zasobowe.



FUNKCJONALNOŚĆ MODUŁU

Jak już wspomniano, podstawowe funkcje modułu GG to zlecanie zadań i przetwarzanie notyfikacji. Pozostałe funkcje modułu to:
  • monitorowanie zadania w systemie zewnętrznym na żądanie;
    możliwe jest odpytanie systemu zewnętrznego o informacje takie jak maszyna wykonująca,
    czas rozpoczęcia, czas zakończenia, bieżący status,
  • usuwanie zadania.