Autoreferat rozprawy doktorskiej

Rozproszone środowisko programowania obiektowego

Oskar Świda

Styczeń 2000

Praca niniejsza przedstawia wyniki badań nad pewnym modelem środowiska rozproszonego dla programowania obiektowego.

Uwagi wstępne:

Systemy rozproszone cieszą się dużą popularnością ze względu na dwa fakty:

1) Rozpraszanie obliczeń - w przypadku, gdy zadanie obliczeniowe może być podzielone na kilka niezależnych części, równoległe ich wykonanie znacznie przyspiesza obliczenie. W tej dziedzinie doskonałe zastosowanie znajdują komputery równoległe, są to jednak maszyny bardzo drogie i nie zawsze korzyści wynikające z szybkich obliczeń równoważą koszt zakupu. Alternatywą dla maszyn równoległych są środowiska rozproszone. Koszt takiego rozwiązania jest znikomy, sieci komputerowe są łatwo dostępne (a zazwyczaj już istnieją), pozostaje zatem jedynie instalacja odpowiedniego oprogramowania.

2) Współdzielenie zasobów - część aplikacji wymaga rozpraszania danych w sieci komputerowej, czy to ze względu na ich wielkość (nie mieszczą się na jednej maszynie), czy też ze względu na wygodę użytkowników. Środowiska rozproszone pozwalają na korzystanie z rozproszonych danych, ukrywając przed użytkownikiem szczegóły ich fizycznego rozmieszczenia. Pozwala to na łatwe rozszerzanie i przemieszczanie zasobów.

Konstrukcja aplikacji rozproszonej musi zakładać pewien model wykonawczy, co z kolei rzutuje na sposób jej implementacji. W większości środowisk zakłada się, że wykonanie aplikacji rozproszonej jest realizowane przez zbiór wykonań pojedynczych programów sekwencyjnych (nazywanych procesami), przy czym programy te nie muszą być wykonywane na jednej maszynie. W związku z tym, pojawiają się kolejne problemy programistyczne, takie jak synchronizacja międzyprocesowa oraz komunikacja międzyprocesowa.

Istniejące narzędzia dla środowisk rozproszonych:

Inżynieria oprogramowania od lat próbuje wprowadzić pewne techniki ułatwiające tworzenie aplikacji. Jednym z takich rozwiązań (popularnym i niewątpliwie efektywnym) stało się programowanie obiektowe.

W latach 90 powstało kilka ciekawych narzędzi wspomagajacych obiektowe programowanie rozproszone. Do najważniejszych zaliczyć można chyba standard CORBA oraz pewne mechanizmy języka Java (Java Remote Method Invocation). Każde z tych środowisk umożliwia konstrukcję aplikacji rozproszonych, wprowadza jednak pewien obowiązujący model programowania. Zakładają one bowiem, iż obiekty wykorzystywane w programach rozproszonych dzielą się na dwie klasy: obiekty oferujące usługi (serwery) oraz obiekty korzystajace z takich usług (klienci). Co więcej, model taki silnie ogranicza możliwości serwera, sprowadzając jego działanie jedynie do realizacji żądań klientów.

Prototypowa implementacja będąca jednym z wyników badań, stanowi kolejny przykład zastosowania programowania obiektowego do tworzenia aplikacji rozproszonych, stosuje jednak inny model programistyczny.

Cel badań:

Celem pracy była implementacja innego niż w CORBie, czy Javie, modelu dla obiektowego programowania rozproszonego. Koncepcja została opracowana już w roku 1988 (praca magisterska B.Ciesielskiego złożona na Uniwersytecie Warszawskim), niemniej, pytanie czy możliwa jest realizacja takiego środowiska, pozostawało bez odpowiedzi.

Założenia badawcze:

Proponowany model środowiska zakłada, że żaden z obiektów nie jest wyróżniony, co więcej, każdy może być jednocześnie klientem i serwerem usług.

Wprowadzone zostały również dodatkowe założenia:

1) Aplikacja rozproszona jest zbiorem obiektów aktywnych (obiektów-procesów) wykonywa-nych niezależnie i niekoniecznie na pojedynczej maszynie. Każdy obiekt aktywny, to struktura posiadająca własności obiektu (atrybuty i metody) oraz klasycznego procesu (własny wątek).

2) Obiekty aktywne mogą być rozpraszane w sieci przez programistę tworzącego aplikację (nie rozmieszczamy ich automatycznie).

3) Każdy obiekt aktywny może oferować wykonanie swojej metody oraz żądać wykonania metod innych obiektów aktywnych.

4) Każdy obiekt aktywny jest w stanie dynamicznie określać swoje usługi - tzn. w trakcie wykonywania własnego wątku, obiekt-proces może określić, które spośród swoich metod zaoferuje innym klientom, a które zablokuje.

5) Nie ma żadnego dodatkowego mechanizmu synchronizacji i komunikacji między obiektami, a dokładniej, synchronizacja i komunikacja międzyprocesowa jest realizowana również przez wywoływanie metod obiektów, w ramach specjalnie opracowanego mechanizmu „obcego wywołania metody” (alien call).

Wyniki badań:

W ramach badań wykonano wiele prac implementacyjnych (lata 1995-98). Powstały trzy wersje środowiska na różnych platformach (SunOS, Novell NetWare oraz Linux). Doświadczenia zdobyte podczas kolejnych implementacji pozwoliły na skonstruowanie kompletnego systemu dla tworzenia obiektowych aplikacji rozproszonych – LOGLAN’96, składającego się z:

• Konsoli maszyny wirtualnej - oprogramowanie to pozwala na szybkie i łatwe określenie, które komputery w sieci będą wykorzystywane do wykonywania programu. W ten sposób użytkownik buduje WIRTUALNĄ MASZYNĘ WIELOPROCESOROWĄ.

• Rozbudowanego interpretera języka LOGLAN - interpreter ten pozwala na rozpraszanie obiektów aktywnych w maszynie wirtualnej. W trakcie konstrukcji programu, użytkownik może wskazać, na którym z węzłów maszyny będzie wykonywany dany obiekt aktywny.

• Zintegrowanego środowiska do pisania programów w języku LOGLAN - edytor z wbudo-wanym kompilatorem oraz interaktywną pomocą.

W części analitycznej uzyskano następujące rezultaty:

• Opracowano definicję pojęcia obiektu aktywnego, podano opis jego własności i zachowań.

• Przeprowadzono analizę implementacji i dowód poprawności względem specyfikacji.

• Wykonano analizę porównawczą mechanizmu „obcego wywołania metody” (alien call) z innymi mechanizmami komunikacji i synchronizacji.

• Przedstawiono analizę porównawczą systemu LOLGAN’96 (Maszyny Wirtualnej LOGLANu) z dwoma popularnymi środowiskami obiektowego programowania rozproszonego – CORBA i Java RMI.