ZESZYTY NAUKOWE PO LITEC H N IK I ŚLĄSKIEJ Seria: INFORMATYKA z. 30
1996 Nr kol. 1315
Jakub SZYMASZEK
Aleksander LAURENTOW SKI Krzysztof ZIELIŃSKI
SY ST E M M O N I T O R O W A N I A
H E T E R O G E N IC Z N Y C H P R O G R A M O W O O B IE K T O W Y C H Ś R O D O W I S K
R O Z P R O S Z O N Y C H
.Streszczenie. A rtykuł omawia prototypowy system m onitorow ania i w izualiza
cji aplikacji rozproszonych, zrealizowanych na podstawie modelu w spółdziałania komponentów uruchomionych w różnych środowiskach rozproszonych. System ten, zwany M ODIMOS, jest rozszerzalny, tzn. umożliwia łatw ą adaptację wielu środowisk dla swoich potrzeb. System stosuje różne m etody zarządzania infor
macją dla ograniczenia strum ienia i złożoności danych wejściowych,
A MONITORING SYSTEM FOR SOFTWARE HETEROGENEOUSE DISTRIBUTED OBJECT-BASED ENVIRONMENTS
Summary. This paper describes a prototype tool, called M anaged O bject-based D istributed M onitoring System . MODIMOS is a project aimed a t developm ent of an adaptable platform for visualization of distributed applications, b u ilt of in teroperating heterogeneous components. MODIMOS is expandable, allowing to add new m onitored environm ents. It employs various m anagem ent m echanism s to cope w ith gathered inform ation size and complexity.
Praca częściowo fin ansow ana w ram ac h gran tu K B N nr 8 S503 015 06.
UN MONITEUR POUR LES ENVIRONS HÉTÉROGÉNIQUES OBJET ORIENTÉS REPARTÍS
Résumé. C et article décrit un système prolotypique d ’observation e t visualisa
tion des applications hétérogcniques objet orientées repartis, qui sont réalisées par un m odèle de coopération des com posants qui m archent dans les environemen!- différents. C et systèm e, appelé MODIMOS (Managed O bject-based Distribute!
M onitoring System ) facilite l’adaptation de plusieurs environem ents. Il adapte les m éthodes différentes de gestion d ’inform ation, pour lim iter le flux et la complexité de donneées.
1. W s t ę p
Nie istn ieją uniw ersalne system y inform atyczne i aplikacje rozw iązujące dowolny pro- blcm użytkownika w jego środowisku. Każdy problem najlepiej (najszybciej, najprościej) d aje się rozwiązać w ram ach określonego m odelu przetw arzania. Na przykład oblicza najlepiej dokonywać w językach i modelach imperatywnych (np. w językach FORTRAN C, C + + ) , podczas gdy m oduły decyzyjne najprościej i najbardziej elegancko zdefinio
wać m ożna w językach deklaratywnych (np. oferowanych przez Lisp czy Prolog). Wśród środowisk program ow ania rozproszonego w sieciach komputerowych powstało w ostatnie!
latach wiele systemów reprezentujących różne modele przetwarzania. M ożna tu wymienit system y STR A ND , PVM , P4, ANSA, SR, Em erald, PCN , czy środowiska zgodne ze stan
dardem COR BA . Nierealne je st również dążenie do uniformizacji środowisk sprzętowych!
programowych różnych organizacji czy pojedynczych użytkowników, których systemy in
form atyczne prędzej, czy później zaczną współpracować. Stąd wniosek, że istniejące ora przyszłe system y i aplikacje użytkowników są niejako „skazane" na współpracę. Uważamy, że przyszłe zaawansowane system y inform atyczne będą się składać ze współpracujących»
sobą m odułów napisanych i uruchomionych w różnych językach i środowiskach. Prototyp?
takich system ów ju ż powstały w ram ach projektów badawczych [6, 7] i będziemy je tu da lej nazywać system am i heterogenicznymi programowo. Ich nieuniknioną właściwością J®'
d u ża złożoność, zwłaszcza n a w stępnym etapie badań nad ich konstrukcją i zastosowaniem S tąd wynika konieczność budowy odpowiednich systemów śledzenia i wizualizacji takio aplikacji. Niniejszy artykuł omawia prototypowy system tego typ u , służący do monito
rowania i wizualizacji heterogenicznych programowo, obiektowych aplikacji i środowi rozproszonych. System ten , zwany MODIMOS (Managed Object-based D istributed Mo
nitoring System ), je s t aktualnie realizowany w K atedrze Inform atyki AGH.
System monitorowania heterogenicznych programowo obiektowych środowisk ... 195 Większość istniejących narzędzi monitorowania i wizualizacji nie nadaje się do środowisk obiektowych [16, 12]. Inne są najczęściej ograniczone do pojedynczego środowiska progra
mowania [13] lub w ogóle nie działają w system ach równoległych i rozproszonych [14, 11].
Poza tym nie przewidują one współpracy komponentów wew nątrz system u heterogenicz
nego programowo, a ich architektura m a często charakter zam knięty, tzn. nie są przysto
sowane do łatwej rozbudowy, poszerzania o nowe środowiska m onitorowane. MODIMOS spełnia te wymagania. Jego użytkownik może obserwować stru k tu rę obiektowej aplikacji rozproszonej, jej fizyczne odwzorowanie na kom putery w sieci oraz zachowanie i dynam ikę jej komponentów. Dzięki tem u system może służyć do w ykryw ania nierównego rozdziału lub przeciążenia zasobów i ułatwiać ich wyważanie i dystrybucję. MODIM OS je st syste
mem otwartym, łatw ym do rozbudowy, tzn. środowiska spełniające określone w ym agania mogą być stosunkowo łatwo zaadaptowane do współpracy z system em . YV ten sposób MODIMOS może poszerzać zbiór różnych środowisk, których kom ponenty je st w s ta nie monitorowąć, a trzeb a pam iętać, że środowisk tych je st już sporo i wciąż pow stają nowe. Otwarta koncepcja system u je st możliwa dzięki jego ustrukturalizow anej, wielowar
stwowej architekturze. Definiuje ona podstawowe interfejsy oraz protokoły komunikacji, sprzęgające poszczególne warstwy ze sobą. Dotyczy to zarówno instrum entacji m onitoro
wanego kodu, jak i m echanizm u przechwytywania i interpretacji zdarzeń, mechanizmów i technik współdziałania oraz stosowanych baz danych. Otw artość system u jest możliwa również dzięki zastosowaniu najnowszych technik inżynierii oprogramowania, takich jak ramy [4] (ang. frameworks) i wzorce projektowe [5] (ang. design pattem s).
Kluczem do efektywnego śledzenia i wizualizacji dużych i złożonych system ów, ja kimi niewątpliwie są rozproszone środowiska programowo heterogeniczne, je s t nawigacja zorientowana na problem , umożliwiająca użytkownikowi takie zarządzanie strum ieniem informacji, by mógł ograniczyć ją do minim um niezbędnego dla rozw iązania aktualnego problemu. Stąd nacisk położony w system ie MODIMOS n a mechanizm y selekcji istotnej i filtrowania nieistotnej inform acji. Mechanizmy te są (lub będą) zaim plem entow ane na kilku poziomach system u. MODIMOS pracuje w dwu trybach: off-Iine, umożliwiającym analizę pliku ze śladem działania aplikacji, oraz on-line, kiedy system nasłuchuje zdarzeń z sieci i dzięki tem u praca monitorowanej aplikacji analizowana je st na bieżąco.
Niniejszy artykuł jest podzielony następująco: w sekcji 2 opisana je st arch itek tu ra systemu. Sekcja 3 om awia Uniwersalny Model Obliczeniowy (UM O), przyjęty dla po
trzeb projektu. W sekcji 4 przybliżone są mechanizmy współpracy różnych komponentów t środowisk programowych. Sekcja 5 skupia się n a m etodach wizualizacji. A rtykuł kończy podsumowanie.
Rys. 1. Wielowarstwowa architektura system u MODIMOS Fig. 1. MODIMOS m ulti-layer architecture
2. A r c h ite k t u r a s y s t e m u
Jak ju ż wspominano, MODIMOS umożliwia jednoczesną i jednolitą pod względem lo
gicznym obserwację kilku środowisk programistycznych (lub aplikacji zbudowanej z kom
ponentów działających w tych s'rodowiskach). By to osiągnąć, zaprojektow ano wielowar
stwową architekturę pokazaną na rysunku .
W arstwę Środowisk tworzą odpowiednio zaadaptow ane obiektowe środowiska progra
m ow ania rozproszonego. Praktycznie każde środowisko tego typu może być zaadaptowane na potrzeby system u MODIMOS pod w arunkiem, że dostarcza podstawowe mechanizm;
komunikacji ze św iatem zewnętrznym (np. gniazdka - ang. sockels) oraz jego model obli
czeniowy zawiera się w Uniwersalnym Modelu Obliczeniowym MODIMOS (patrz sekcji 3). W arstw a Środowisk składa się z dwóch poziomów: Poziomu Monitorowanych Aplikacji i Poziomu Lokalnych Monitorów, Poziom pierwszy tw orzą obiekty aplikacji użytkownika których kod źródłowy został zinstrum entowany przez odpowiednie preprocesory. Instm m en tacja polega głównie na dodaniu tzw. funkcji zawiadamiających. Funkcje tc zbierajt inform acje o zdarzeniach, które miały miejsce w śledzonej aplikacji i zawiadam iają o id zajściu lokalne monitory. M onitory tc to specjalne obiekty środowiska, w którym działają
System monitorowania heterogenicznych programowo obiektowych środowisk ... 197 mające dwa podstawowe zadania: filtrację strum ienia zdarzeń wg przyjętych reguł oraz przesianie wybranych zdarzeń przez W arstwę W spółdziałania do M onitora Globalnego,
Środowiska m ogą posiadać jeden lub więcej lokalnych monitorów, w zależności od swych właściwości i rozm iaru aplikacji. Ograniczanie strum ienia danych wejściowych jest możliwe dzięki zastosowaniu odpowiednich reguł filtracji n a obu poziomach W arstwy Środowisk. Zespól reguł tworzy strategię filtracji. Na Poziomie M onitorowanych Aplika
cji użytkownik definiuje reguły za pom ocą odpowiednich przełączników preprocesorów, pozwalających np. pom inąć generację zdarzeń określonego typu lub zdarzeń dotyczących określonych obiektów. Z kolei n a Poziomie Lokalnych Monitorów możliwe je st ustawianie podobnych reguł przy urucham ianiu danego m onitora lub w trakcie pracy za pom ocą spe
cjalnego interfejsu zarządzania. Lokalne m onitory mogą oczywiście spełniać wiele d o d a t
kowych funkcji pomocniczych, jak kom presja danych czy translacja form atów kodowania, w zależności od potrzeb użytkownika i właściwości danego środowiska. W środowiskach usług zamkniętych (jak np. SR [2]) lokalne m onitory są skonsolidowane z zasadniczą apli
kacją, powstają i są niszczone wraz z nią. Z kolei w środowiskach otw artych, ja k np. ANSA [1] czy CORBA [3], lokalne m onitory są publicznie dostępnymi serwerami, urucham ianym i niezależnie na żądanie użytkownika.
Kolejna warstwa architektury systemu MODIMOS to W arstwa W spółdziałania. Ma ona na celu zapewnienie uniwersalnej i ogólnej platform y współdziałania kom ponentów systemu heterogenicznego programowo, jakim jest sam MODIMOS. W arstw a ta , dzięki rozwiązaniom strukturalnym (patrz sekcja 4) i odpowiedniemu protokołowi komunika
cyjnemu [9] umożliwia współpracę monitorów lokalnych różnych środowisk z M onitorem Globalnym (GM). GM przechw ytuje zdarzenia nadchodzące z całego system u m onitoro
wanego, zbiera inform ację o śledzonych jednostkach i ich stanie w specjalnej bazie danych, zw. Modelem W ewnętrznym . Model ten odzwierciedla chwilową stru k tu rę i stan tej części jednostek (obiektów) aplikacji, które wg działającej aktualnie strategii nie są pom inięte (odfiltrowane). M onitor Globalny współpracuje ze znajdującym się w W arstwie P rezen
tacji Graficznym Interfejsem Użytkownika (GUI). Interfejs ten służy do graficznej repre
zentacji struktury i stanu monitorowanej aplikacji oraz dostarcza użytkownikowi m etod dodatkowych metod selekcji napływającej informacji.
3. U n iw e r s a ln y M o d e l O b lic z e n io w y
System monitorowania danego środowiska programowego powinien być oparty na jego modelu obliczeniowym, tzn. śledzenie i wizualizacja powinny dotyczyć jednostek tego m o
delu. Tymczasem MODIMOS jest z założenia przeznaczony do zastosowania dla potrzeb w'*du, często znacznie różniących się, obiektowych środowisk program ow ania rozproszo
nego. Różnice między nimi dotyczą również modeli obliczeniowych. Stąd wynikła po
trzeb a opracow ania uniwersalnego modelu, na którym system MODIMOS mógłby być oparty. W tym celu przeanalizowano modele obliczeniowe najważniejszych dostępnych środowisk obiektowych i wyprowadzono wniosek, że ów uniwersalny, abstrakcyjny model powinien być nadzbiorem (unią) istniejących modeli. Takie podejście gw arantuje, że wszy
stkie m ożliwe w praktyce poziomy abstrakcji będą obecne w modelu uniwersalnym. Model te n nazwano Uniwersalnym Modelem Obliczeniowym (UM O), choć należy pamiętać, ii dotyczy on jedynie obiektowych środowisk rozproszonych.
A plikacja w obiektowym środowisku programowym składa się najczęściej, n a poziomie logicznym, z pewnej grupy niezależnych, komunikujących się ze sobą obiektów. Uniwer
salny Model Obliczeniowy definiuje jednak więcej poziomów abstrakcji, a mianowicie:
środowisko, aplikację, kontener, obiekt, interfejs, m etodę i wywołanie. Odwzorowanie tych abstrakcyjnych jednostek w konkretne pojęcia wybranej grupy środowisk pokazuje ta b e la . By dane środowisko mogło być monitorowane w system ie M ODIM OS, jego model obliczeniowy powinien zawierać się w UMO.
T abela 1.
Przykładowe odwzorowanie UMO J e d n o s t k a
a b s tr a k c y j n a
Ś ro d o w isk o
ANSA SR Orbix
aplikacja — program —
kontener kapsuła m aszyna w irtualna proces obiekt obiekt zasób, globalium obiekt interfejs interfejs specyfikacja interface
m etoda operacja operacja m etoda
wywołanie wywołanie wywołanie wywołanie
Poniżej przytoczono krótki opis poszczególuych jednostek abstrakcyjnych.
Ś ro d o w is k o . Przez środowisko jest rozumiany działający system wykonawczy (ang. nin- tim e system ), um ożliwiający uruchomienie obiektów (zasobów) definiowanych prze*
użytkownika.
A p lik a c ja . Pojęcie aplikacji nie jest tru d n e do zdefiniowania w środowiskach zamkniętych ja k np. SR. Tw orzą ją ta m wszystkie obiekty i zasoby zdefiniowane przez użytkownika w danym program ie, najczęściej wraz z dedykowaną instancją środowiska dla id wykonania. Inaczej m a się spraw a ze środowiskami otw artym i, jak np. ANSA czf
System monitorowania heterogenicznych programowo obiektowych środowisk ... 199 CORBA, gdzie działają ogólnie dostępne serwery usług, urucham iane i wykorzysty
wane przez różnych użytkowników. Nie d a się tam zakreślić granic m iędzy apli
kacjami w sposób arbitralny czy autom atyczny. Jedynie dany użytkownik je st w stanie zdefiniować zasoby, wchodzące w skład jego aplikacji.
K ontener. Kontenery to obszary pamięci dzielone przez obiekty w nich rezydujące. Za
zwyczaj kontenery są im plementowane przez procesy systemu operacyjnego.
Obiekt. Definicja obiektu jest tradycyjna i powszechnie znana. Przypom nim y tylko, żc w niektórych s'rodowiskac.h (np. ANSA) obiekt może mieć więcej niż jeden interfejs.
Interfejs. Interfejs definiuje m etody i atrybuty, których obiekt dostarcza dla użytku innych obiektów.
M etoda. M etoda to operacja wchodząca w skład interfejsu obiektu. MODIMOS rozróżnia i pozwala śledzić osobno instancje m etod każdego obiektu, czyli w istocie wątki w y
konania związane z daną operacją.
W ywołanie. Wywołanie jest abstrakcyjnym pojęciem reprezentującym stan, w którym obiekt-klient wywołuje usługę (m etodę) z interfejsu obiektu-serw era. Sum aryczna liczba wywołań pow inna być równa liczbie instancji m etod w aplikacji. Takie podejście umożliwia spójne i sym etryczne śledzenie i wizualizację komunikacji w obiektowym system ie rozproszonym.
Z każdym elementem Uniwersalnego Modelu Obliczeniowego związna je st p ara kom plementarnych zdarzeń: utworzenie i zniszczenie danego elem entu. Z darzenia te są ra portowane przez funkcje zaw iadam iające do lokalnych monitorów i stam tąd dalej do Mo
nitora Globalnego. S tąd z każdą jednostką UMO związane są dwie funkcje notyfikujące.
Zbiór funkcji zaw iadam iających jest w sposób uniwersalny opisany interfejsem m onitoro
wania w języku IDL ( Inlerfact Definition Language) [3], co um ożliwia łatwe przenoszenie do różnych języków i środowisk. Interfejs ten definiuje zarówno interfejsy m onitorujące wszystkich lokalnych m onitorów, jak i M onitora Globalnego.
Aby rozszerzyć system MODIMOS o nowe środowisko należy:
• przeanalizować jego model obliczeniowy i znaleźć jego odwzorowanie do UMO,
• dokonać translacji interfejsu monitorow ania (funkcji zaw iadam iających) na język programowania danego środowiska,
• napisać odpowiedni preprocesor instrum entujący kod źródłowy aplikacji w danym środowisku
• zaimplementować m onitor(y) lokalny(e) na podstawie interfejsu m onitorow ania
• zaim plem entow ać fragm ent podsystem u komunikacji w W arstwie Współdziałania Osobny problem w system ach heterogenicznych programowo stanowi unikalna iden
tyfikacja obiektów. Każde środowisko posiada własny, niekom patybilny z innymi, sy
stem identyfikacji. Tym czasem w aplikacji heterogenicznej programowo, a zwłaszcza w system ie m onitorow ania, istnieje potrzeba istnienia globalnie unikalnych identyfika
torów. M ożna rozwiązać ten problem , wykorzystując oryginalne identyfikatory z po
szczególnych środowisk i trakując je jako ciągi bajtów , ew. uzupełnione krótkim i przedro
stkam i, nadającym i im globalną unikalność. Takie identyfikatory „ n a tu raln e” są jednak długie i stosowanie ich jako kluczy przeszukiwań w wielu typach baz danych powodowałoby nieefektywność operacji wyszukania i zapisu. Stąd w system ie MODIMOS zastosowano
„sztuczne” identyfikatory o stru k tu rze hierarchicznej, tworzone przez kod instrumentujący specjalnie n a potrzeby system u. Identyfikator hierarchiczny składa się z komponentów, z których każdy odpow iada pewnem u poziomowi logicznemu TJMO i zawiera liczbę in
stancji elem entów danego poziomu w elemencie nadrzędnym . Taki typ identyfikatora, kodowany binarnie lub znakowo, znacznie uspraw nia operacje na niektórych typach bar danych, stosowanych w projekcie (patrz sekcja 5).
4. M e c h a n iz m y w s p ó łd z ia ła n ia
M onitorowane środowiska z reguły charakteryzują się odm iennym i rozwiązaniami ar
chitektonicznym i, a kom unikacja między obiektam i aktywnym i w danym środowisku od
bywa się zgodnie ze specyficznym dla niego protokołem. Powoduje to, żc nawiązani?
bezpośredniej komunikacji między m onitorowanymi aplikacjami a Globalnym Monitorem je st niemożliwe. Rozwiązanie tego problem u polega na wprowadzeniu do architektury sy
stem u m onitorow ania specjalnej W arstwy W spółdziałania, której zadaniem je st zapewnie
nie uniwersalnego mechanizm u wywołania odległych operacji pomiędzy lokalnymi monito
ram i, aktyw nym i w poszczególnych środowiskach, a GM. Podsystem komunikacji Warstwy W spółdziałania m oże być zrealizowany jedną z dwu przedstawionych poniżej metod.
B u d o w a o d p o d s ta w m e c h a n iz m u k o m u n ik a c y jn e g o , dedykowanego dla War
stwy W spółdziałania, opartego na jednym z prym ityw nych interfejsów komunikacyjnych, takich jak np. mechanizm gniazdek (ang. sockets).
Z a s to s o w a n ie łą c z ą c e g o śro d o w isk a ro z p ro s z o n e g o (ang. glue environment), ta
kiego ja k O rbix [10], ANSA [1] lub ToolTalk, dostarczającego, oprócz mechanizmów komu
nikacyjnych, szereg dodatkowych usług, takich jak: lokalizacja serwerów, kojarzenie Żądau klientów z ofertam i serwerów (ang. trading), rozsyłanie wywołali (ang. dispatc.hing), itf Koncepcję w ykorzystania środowiska łączącego przedstawiono na rys. 2.
N ajw iększą zaletą pierwszego z tych rozwiązali jest jego prostota, k tó ra pociąga U
System monitorowania heterogenicznych programowo obiektowych środowisk 201
Rys. 2. W arianty realizacji W arstwy W spółdziałania Fig. 2. V ariants of Interoperability Layer architecture
sobą dużą efektywność - transm isja danych między lokalnymi m onitoram i a Globalnym Monitorem jest bezpośrednia i możliwe jest wysłanie dużej ilości komunikatów w je d n o st
ce czasu. Takie rozwiązanie u trudnia jednak konfigurowanie W arstwy W spółdziałania, a wszystkie potrzebne do tego mechanizmy m uszą być zaprojektow ane i wykonane od podstaw.
W drugim rozwiązaniu komunikaty przesyłane są za pom ocą mechanizm u wywołań odległych operacji, dostarczanego przez środowisko łączące. Zwalnia to program istę z ko
nieczności pracochłonnej im plem entacji własnej infrastruktury komunikacyjnej (modułów odbierających i wysyłających, buforujących i interpretujących kom unikaty). Możliwe jest także wykorzystanie mechanizmów konfiguracji, dostępnych w środowisku łączącym.
Pozwala to na rckonfigurację Warstwy W spółdziałania podczas pracy system u. Drugie rozwiązanie zapewnia także pożądaną strukturalizację Warstwy W spółdziałania. Pew ną wadą jest natom iast mniejsza, w stosunku do prymitywnych mechanizmów kom unikacyj
nych, efektywność przetw arzania. Jednakże opisywany system m a z założenia umożliwiać przede wszystkim selektywną obserwację monitorowanych środowisk, a więc ilość przesy
łanej informacji jest zazwyczaj znacznie zredukowana przez użytkownika.
Łączące środowisko rozproszone musi zostać zintegrowane ze sTodowiskami m onito
rowanymi, Najlepszym rozwiązaniem byłaby konstrukcja obiektu-bram y [S] (ang. gale- uay), który byłby aktywny jednocześnie w środowisku łączącym i w danym środowisku monitorowanym (w ariant III na rys. 2). Oznacza to, że taki obiekt mógłby wysyłać i odbierać wywołania z obu tych s'rodowisk. Niestety, wiele środowisk nie dopuszcza ta kiej możliwości.
Alternatywne rozwiązanie polega na zaprojektowaniu i im plem entacji obiektu-w tyczki
(ang. plug), który je st aktywowany w środowisku łączącym i reprezentuje w nim dane środowisko monitorowane. W tyczka odbiera od lokalnych m onitorów w danym środowisku polecenia wywołań odległych operacji i dokonuje ich konwersji do form atu środowiska łączącego. Środowisko łączące umożliwia komunikację wtyczek z GM, pozwala na lokali
zację GM i przekazuje do niego wywołania operacji.
Zostały wyróżnione dw a możliwe warianty konstrukcji wtyczek i ich komunikacji z lo
kalnym i m onitoram i. W ybór jednego z nich zależy od cech, jakie posiada dane środowisko monitorowane.
R o z w ią z a n ie z u ż y c ie m g n ia z d e k . Komunikacja między lokalnymi monitorami a w tyczką realizowana je s t w oparciu o mechanizm gniazdek (wariant 1 n a rys. 2). Rozwiązanie to powinno być stosowane wtedy, gdy dane środowisko nie oferuje wątków ani innego me
chanizm u pozwalającego n a im plem entację komunikacji asynchronicznej. Wówczas musi być stosowany m echanizm zdarzeniowy oparty n a sygnałach. Przykładem środowisk wy
m agających stosowania powyższej m etody są S trand i PCN.
R o z w ią z a n ie z o b ie k te m - r e p r e z e n ta n te m (ang. proxy). W komunikacji między lo
kalnymi m onitoram i a wtyczką pośredniczy specjalny obiekt aktywny w danym środowisku m onitorow anym , reprezentujący w nim GM (w ariant II n a rys. 2). M onitory lokalne ko
m unikują się z reprezentantem za pomocą mechanizmu wywołania właściwego dla danego środowiska, natom iast komunikacja reprezentanta z wtyczką odbywa się za pomocą me
chanizm u gniazdek.
W arstwa W spółdziałania system u MODIMOS została zrealizowana przy wykorzysta
niu środowiska łączącego, którego rolę pełni system Orbix. Dotychczas do warstwy w spółdziałania dołączono dwa środowiska monitorowane: ANSA i SR. W celu ich integra
cji ze środowiskiem łączącym zastosowano mechanizm wtyczek i reprezentantów (wariant II n a rys. 2).
5. G lo b a ln y M o n ito r i W a r stw a P r e z e n t a c j i
W arstw a prezentacji system u monitorowania realizuje dwie niezależne funkcje: do
starcza interfejs pozwalający na zarządzanie system em oraz jest odpow iedzialna za Wi
zualizację zdarzeń zachodzących w monitorowanych środowiskach. Aplikacje działają®
w poszczególnych środowiskach składają sie z elementów tworzących stru k tu rę hierar chiczną, k tó rą m ożna opisać zarówno modelem obliczeniowym danego środowiska, j?-‘;
i U niwersalnym M odelem Obliczeniowym wspólnym dla wszystkich środowisk. Informa
cje o aktualnym stanie monitorowanych elementów oraz o wiążących je zależnościach są grom adzone w Globalnym M onitorze i zapisywane w bazie danych, zwanej Model®
W ew nętrznym (M W ). Każdy monitorowany element je st reprezentowany przez pewi®
System monitorowania heterogenicznych programowo obiektowych środowisk 203 obiekt Modelu W ewnętrznego. W dowolnym momencie pracy system u logiczna stru k tura powiązań obiektów M odelu Wewnętrznego odpowiada stru k tu rze m onitorowanych elementów.
Dla implementacji MW kluczowe znaczenie m a wybór odpowiedniej stru k tu ry danych zapewniającej dużą efektywność operacji wyszukiwania, w stawiania i usuwania obiektów reprezentujących monitorow ane elementy. Jednoczes'nie należy zauważyć, że wybór stru k tury danych zależy silnie od założeń, jakie zostały narzucone n a identyfikatory m onito
rowanych elementów. Na przykład, jeśli stosowane są identyfikatory hierarchiczne, to powinna zostać w ybrana stru k tu ra danych w ykorzystująca ten fakt w celu zwiększenia efektywności wymienionych wyżej operacji.
Z tego powodu, a także w celu umożliwienia łatwego testow ania różnych stru k tu r d a nych, GM został skonstruowany w sposób pozwalający na łatwą w ym ianę struktury' d a
nych wykorzystywanej w MW. Wykonano szereg imlementacji MW opartych na różnych strukturach, takich jak tablice rozproszone, R-drzewa oraz stru k tu ry drzewiasto-listowe.
Wykorzystano przy tym gotowe komponenty dostępne w bibliotekach obiektowych, takich jak Tools.h-f+ i Booch Com ponents oraz struktury zaimplementowane własnoręcznie.
Obecnie przeprowadzane są pom iary efektywności przetw arzania zrealizowanych im ple
mentacji, mające na celu wybór najlepszej struktury danych dla poszczególnych rodzajów identyfikatorów.
Informacje gromadzone w MW są na bieżąco przetw arzane i wyświetlane przez interfejs graficzny. Powstawanie nowych obiektów w MW, niszczenie oraz zm iany stanu obiektów już istniejących, powodowane przez odpowiednie zmiany w monitorowanych aplikacjach, są wizualizowane przez interfejs graficzny. Ponieważ monitorowane elem enty (oraz obiekty MW) tworzą stru k tu rę hierarchiczną (drzewiastą), zadaniem o kluczowym znaczeniu je st opracowanie efektywnej m etody wizualizacji drzew. Ponadto, ze względu na stosunkowo dużą liczbę obiektów gromadzonych w MW, konieczne je st dostarczenie użytkownikowi wygodnych i efektywnych mechanizmów wyboru interesujących go fragmentów stru k tu ry monitorowanych elementów.
Wizualizowane elem enty są reprezentowane na ekranie w postaci figur geom etrycz
nych. Atrybuty każdej figury (kształt, kolor) zależą od rodzaju wizualizowanego ele
mentu (tj. jego poziomu w UMO). W ykonanie określonej akcji n a figurze powoduje wyświetlenie sczególowych informacji o elemencie (np. o jego fizycznym położeniu). W i
zualizacja hierarchicznej stru k tu ry elementów może być zrealizowana przy użyciu gra
fiki trójwymiarowej (np. drzew stożkowych [15]) albo w przestrzeni dwuwymiarowej.
W pierwszej wersji system u zastosowano reprezentację dwuwymiarową. W yróżniono przy fyin dwa rodzaje tej reprezentacji: drzew iastą (rys. 3 a) i skrzynkową (rys. 3 b), różniące sl? między sobą sposobem oznaczania powiązań między węzłami. W reprezentacji drzewia
stej, która jest stosowana w obecnej wersji system u, relacja ojciec-syn jest reprezentow ana
przez linie, łączące odpowiednie figury. W reprezentacji skrzynkowej figury reprezentujące węzły dzieci są um ieszczane wewnątrz figur reprezentujących węzły ojców.
Rys. 3. Dwie m etody dwuwymiarowej reprezentacji stru k tu r hierarchicznych:
a) drzew iasta i b) skrzynkowa
Fig. 3. Two m ethods of tree’s presentation: a) tree-like and b) box-like
Pom im o stosowania mechanizmów filtracji w niższych warstwach system u MODIMOi liczba elementów reprezentowanych w M W może być n a tyle duża, że ich efektywna wizu
alizacja będzie niepożądana lub nawet niemożliwa. Dlatego warstwa prezentacji dostarcz»
m achanizm y selekcji, pozwalające na redukcję rozmiarów drzewa wyświetlanego na ekra nie. Dwie podstawowe m etody selekcji to selekcja pozioma i pionowa. Selekcja poziomi (rys. 4) polega na eliminacji w ybranych poziomów aktualnie wys'wietlanego drzewa (tj usunięcie z ekranu figur reprezentujących elementy określonego poziomu UMO, np. in
terfejsów albo kontenerów). Selekcja pionowa (rys. 5) umożliwia natom iast usunięcie wy
branych poddrzew aktualnie wyświetlanego drzewa. Pozwala więc na usunięcie z ekranu inform acji o nieintercsujących dla obserwatora elementach i ich zawartości (np. figury re
prezentującej nieintcresujący użytkownika kontener wraz ze wszystkimi jego obiektami) Oprócz mechanizmów wyboru elementów warstwa prezentacji pozwala na maskowa
nie wizualiowanych zdarzeń. Możliwe opcje o praktycznym znaczeniu to np.: ig n o ro w a n ie
wszystkich zdarzeń (tj. zam rożenie obrazu aktualnie wyświetlanego w oknie), ignoro
wanie zdarzeń dotyczących tworzenia nowych elementów (tj. ograniczenie obserwacji®
elementów aktualnie wizualizowanych).
O pisane mechanizmy selekcji i filtracji mogą okazać się niewystarczające w sytua- cji, gdy użytkownik chce obserwować jednocześnie różne części monitorowanej struktur) elem entów . Dlatego interfejs graficzny pozwala na jednoczesną obserwacje dowolnyć fragmentów stru k tu ry MW w różnych oknach. W każdym z nich może być wyświetla®
dowolne poddrzewo (lub jego fragm ent) hierarchii reprezentowanej w MW. Dany elenie»1
System monitorowania heterogenicznych programowo obiektowych środowisk ... 205
e le m e n ty w iz u a liz o w a n e
Rys. 4. Selekcja pozioma Fig. 4. Horizontal selection
Rys. 5. Selekcja pionowa Fig. 5. Vertical selection
może być jednocześnie reprezentowany w wielu różnych oknach. Zm iana korzenia ak tu al
nie wyświetlanego podrzew a polega n a wyborze jednej z figur widocznych w danym oknie, która staje się nowym korzeniem.
6. Podsum ow anie
W artykule przybliżono projekt MODIMOS - prototypow y system m onitorow ania i wizualizacji heterogenicznych programowo, obiektowych aplikacji rozproszonych. Z re
alizowano już zasadniczy zrąb projektu: W arstwę Środowisk, W spółdziałania i M onitor Globalny wraz z kilkom a wersjami Modelu Wewnętrznego. Obecnie trw ają prace nad im plementacją interfejsu graficznego na podstaw ie obiektowej biblioteki Fresco i środowiska graficznego X-Window. W rozwiązaniu tym każdy elem ent Modelu W ewnętrznego będzie mógł być reprezentowany przez wiele obiektów przedstaw iających figury lub okna. W po
czątkowej wersji system u GM oraz interfejs graficzny będą zintegrowane w jednym pro
cesie. W przyszłości natom iast zostanie wykorzystane jedno z rozproszonych środowisk w celu oddzielenia tych modułów. Wówczas obiekty graficzne będą jednocześnie obiektami środowiska rozproszonego. Pozwoli to n a tworzenie wielu instancji interfejsu graficznego fizycznie oddalonych od M onitora Globalnego i da możliwość jednoczesnej obserwacji zm ian w monitorowanej aplikacji przez wielu użytkowników.
LITERATURA
[1] ANSAware 4.0 - Application Program m er’s Manual, APM Ltd. Cam bridge, 1992.
[2] Andrews G.R., a t el.: An overview of the SR language and im plem entation, ACM Trans, on Progr. Languages and System s, 10( 1 ):51—86, January 1988.
[3] Draft Com mon O bject Request Broker A rchitecture Revision 1.1, OMG Report 91- 12-1, OMG Inc., 1991.
[4] C am pbell R., Islam N.: A Technique for D ocum enting the Fram ew ork of an Object- O riented System , Proc. ]W O O S ’92, IEEE Com puter Society Press, Los Alamitos, CA, Septem ber 1992.
[5] G am m a E., Helm R ., Johnson R., Vlissides J.: Design Patterns: Elements o f Object- O riented Software Architecture, Addison-Wesley, 1994.
[6] N ierstrasz 0 . , Gibbs S., and Tsichritzis D.: Com ponent-O riented Software Develop
m ent, Comm, o f the ACM , 35(9): 160—165, Septem ber 1992.
[7] Udell J ., Com poncnlw are, Byte vol. 19 no.5, pp. 46-56, May 1994.
[8] Uszok A., Czajkowski G., Zieliński K.: Interoperability Gateway Construction for O bject-O riented D istributed System s, Proc. o f the 6th Nordic Workshop on Pro
gramming Environm ent Research, Lund, Sweden, T R of th e Lund University, June 1994.
[9] Czajkowski G., Uszok A., Zielinski K.: D istributed Declarative System s as Parts of Cooperating Software Environm ents, Proc. o f the IC L P ’9Ą Post-Conference Wor
kshop on Integration o f Declarative Paradigms, S anta M argerita, Italy, Ju n e 1994.
[10] T he O rbix A rchitecture, IONA Technologies Ltd., 1993.
[11] Jerding D .F. and Stasko J.T .: Using Visualization to Foster O bject-O riented Pro
gram U nderstanding, Georgia In stitu te of Technology, T R GIT-GVU-94-33.
[12] Reed D.A., A ydt R.A., Noe R .J., Roth P.C., Shields K.A., Schwartz B., Tavera Ł.F.:
Scalable Perform ance Analysis: T he Pablo Performance Analysis Environment, k Proc. o f the Scalable Parallel Libraries Conference, IEEE C om puter Society Press, 1993.
System monitorowania heterogenicznych programowo obiektowych środowisk 207 [13] Jamrozik H., Roisin C., Santana M.: A Graphical Debugger for O bject-O riented
Distributed Program s, Proc. T O O L S ’91, pp. 117-128, July 1991.
[14] Pauw W.De, Helm R., K imelman D. Vlissides J.: Visualizing the Behavior of O bject- Oriented System s, Proc. OOPSLA ’93, ACM Press pp. 32G-337, SIGPLA N, W ashing
ton D.C, O ctober 1993.
[15] Vion-Dury J.Y ., Santana M.: V irtual Images: Interactive Visualization of D istribu
ted O bject-O riented System s, Proc. O O P S L A ’94, P ortland USA, O ctober 1994.
[16] Miller B.P., Clark M., Hollingsworth J., K ierstead S., Lim S., Torzewski T.: IPS-2:
The Second Generation of a Parallel Program M easurem ent System , IE E E Transac
tions on Parallel and Distributed System s 1, 2 (April 1990), pp. 206-217.
Recenzent: Dr hab. inż. Tadeusz Czachórski
Wpłynęło do Redakcji 2 1 grudnia 1995.
Abstract
The next decade will bring radical changes to the way we perform inform ation pro
cessing, as applications composed of m any cooperating distributed subsystem s, exploiting different com putational paradigm s, become more common. This situation increases sub
stantially dem ands in th e area of. system m anagem ent, correctness analysis, u nderstan
ding, debugging and perform ance evaluation. Managed O bject-based D istributed M oni
toring System (MODIM OS) is a project aimed a t development of an ad ap tab le platform for visualization of distributed applications, built of interoperating heterogeneous com po
nents. In other words, th e system serves for monitoring and visualization of applications built of many cooperating com ponents, w ritten in different com puting environm ents. M O
DIMOS is expandable, allowing to add new monitored environm ents. It em ploys various management mechanisms to cope w ith gathered inform ation size and complexity. T h e expandability of MODIM OS architecture has been proved by successful integration of ANSA, SR and Orbix w ithin the Interoperability Layer [8]. This provided th e m ajor feedback for the applied technical solutions and proved correctness of this layer’s con
cept. This paper describes also th e m ulti-layer architecture of th e system (Fig. 1) and th e Possible visualization schemes (Fig. 3).
