Efektywność wybranych implementacji środowiska corba



Pobieranie 164,45 Kb.
Strona1/4
Data09.03.2018
Rozmiar164,45 Kb.
  1   2   3   4

Efektywność wybranych implementacji środowiska CORBA


Jacek Cała, Łukasz Czekierda

Zespół Systemów Rozproszonych


Katedry Informatyki Akademii Górniczo-Hutniczej


Al. Mickiewicza 30, 30-059 Kraków

tel.: 0-12 6173491

e-mail: {cala,luke}@ics.agh.edu.pl
Wrzesień 2001

1. Geneza badań


Zagadnienie komunikacji pomiędzy komputerami w sieci jest złożone i może być zrealizowane na wiele różnych sposobów, poczynając od tak niskiego poziomu jak interfejs gniazd (ang. socket) do zaawansowanych środowisk pełniących rolę platformy komunikacyjnej pomiędzy aplikacjami w sieci komputerowej (ang. middleware). Do najpopularniejszych standardów komunikacji aplikacji stosowanych w systemach rozproszonych należą RPC [10], RMI [8] i CORBA [1]. Dostarczają one oprócz protokołu komunikacyjnego także wiele użytecznych serwisów.

W ostatnich latach technologia CORBA osiągnęła poziom standardu de facto [7] Oprócz komercyjnych implementacji pojawiają się także produkty darmowe dostępne nawet w postaci źródłowej – jak na przykład omniORB [11] czy implementacja standardu CORBA obecna w języku Java z Sun Microsystems [8].

Zespół Systemów Rozproszonych Katedry Informatyki AGH od wielu lat, jako jeden z niewielu ośrodków akademickich w Polsce, zajmuje się środowiskami rozproszonymi, wśród których technologia CORBA jest stale w centrum uwagi. Do najważniejszych implementatorów tego standardu należy irlandzka firma IONA (www.iona.com), z którą Zespół współpracuje od długiego czasu uczestnicząc między innymi w ewaluacji nowych produktów. Ostatnio wykonane zostały testy porównawcze dwóch implementacji standardu CORBA: Orbix 3.01 [3] i Orbix 2000 [2] w zakresie szybkości przesyłania danych. Celem badań było dokonanie pomiaru czasu wykonań operacji zawartych w dostarczonym interfejsie IDL. Zawierał on łącznie kilkadziesiąt operacji przesyłających dane o różnej długości i stopniu skomplikowania – od typów prostych poprzez struktury i sekwencje aż do typu Any, co pozwalało na gruntowne zbadanie efektywności danej implementacji CORBA.

Oba testowane produkty pracują w środowisku C++. Naturalnym rozszerzeniem wykonanych testów było dokonanie podobnych pomiarów dla aplikacji CORBA pracujących w środowisku Java (jako drugim obecnie najpopularniejszym) i porównanie otrzymanych wyników. Efektem tych prac jest między innymi ten artykuł.

Jego celem jest przedstawienie pewnych danych ilościowych dotyczących czasu wykonania poszczególnych operacji w różnych konfiguracjach sprzętowo-programowych jak również analiza o charakterze bardziej jakościowym, mogąca pomóc Czytelnikowi w wybraniu najbardziej odpowiedniej w jego konkretnych warunkach implementacji standardu CORBA. W szczególności zamieszczone wyniki pozwalają podjąć decyzję odnośnie doboru języka programowania. Oczywiście decyzja taka powinna brać pod uwagę znacznie więcej kryteriów niż wyłącznie narzuty komunikacyjne, takich jak skalowalność systemu, dostępne serwisy czy koszt rozwiązania – jednak udzielenie odpowiedzi na wszystkie te pytania nie jest zamierzeniem niniejszego artykułu.

2. Wprowadzenie do standardu CORBA


Możliwość pracy w heterogenicznym systemie rozproszonym – zróżnicowanym pod względem zarówno systemowym (platforma sprzętowa i system operacyjny) jak i programistycznym (środowisko programistyczne) – należy zaliczyć do najważniejszych zalet technologii CORBA. Elastyczność ta powoduje, że procedura komunikacji pomiędzy komponentami tego systemu staje się złożona i wprowadza pewne nieuniknione narzuty czasowe w stosunku do komunikacji w środowisku jednolitym pod względem architektury.

Specyfikacja CORBA nakreślając ogólne wymagania odnośnie interfejsów poszczególnych elementów systemu pozostawia twórcom implementacji sporo swobody w realizacji środowiska, co pozwala na znacząco różną pod względem efektywnościowym ich konstrukcję. Tym samym prowadzenie badań porównawczych podobnych jak opisane w niniejszym artykule wydaje się jak najbardziej celowe.



W dalszej części tego punktu zostaną pokrótce opisane najważniejsze elementy występujące na drodze od wywołania operacji przez klienta do dotarcia jej do obiektu implementującego (serwanta). Efektywność ich realizacji wpływa na wydajność komunikacji w środowisku CORBA [5].



Rys. 1. Schematyczna komunikacja pomiędzy klientem i serwerem w architekturze CORBA

  1. Stub klienta. Dla określenia interfejsu pomiędzy klientem a serwerem używa się w standardzie CORBA specjalnego języka definiowania interfejsów – IDL (Interface Definition Language). Zarówno klient jak i obiekt implementujący ten interfejs mogą być zrealizowane w dowolnym z języków programowania, do których istnieje odwzorowanie (ang. mapping) IDL. Wynikiem kompilacji interfejsu IDL do konkretnego języka programowania jest uzyskanie pewnych elementów tego języka – w językach obiektowych jest to zbiór klas i typów pomocniczych – dołączanych do programu klienta i pełniących rolę lokalnego pośrednika (ang. proxy) obiektu implementującego interfejs1. Pozwala to realizować użytkownikowi wywołania zdalne w sposób analogiczny do wywołań lokalnych funkcji. Do najważniejszych funkcji podejmowanych przez stub należy serializacja i deserializacja danych.

  2. Serializacja (ang. marshaling) danych. Heterogeniczność środowiska przejawia się w różnorodności architektur sprzętu i systemów operacyjnych. Wynikająca z tego faktu różna reprezentacja podstawowych typów prostych implikuje konieczność istnienia wspólnej i jednolitej reprezentacji danych definiowanych w IDL. Standardem używanym w technologii CORBA jest CDR (Common Data Representation) – określający rozmiar i sposób rozmieszczenia poszczególnych struktur danych w przesyłanym strumieniu. Każdorazowo przed wysłaniem do sieci dowolnej porcji danych musi nastąpić ich konwersja do postaci CDR, a po stronie odbiorczej procedura odwrotna – deserializacja (ang. unmarshaling). Do poprawnej interpretacji odebranych danych wymagane jest istnienie dodatkowej opisującej je informacji – zawartej np. w interfejsie IDL (odmiennie niż ma to miejsce np. w RPC gdzie opis danych umieszczony jest w przesyłanym strumieniu).

  3. Object Request Broker (ORB). Pełni funkcję kanału służącego do niskopoziomowego przekazywania komunikatów pomiędzy klientem i serwerem. Do jego zadań należy m.in. znalezienie właściwego obiektu określonego przez referencję.

  4. Adapter obiektu. W odróżnieniu od ORBa, który posiada interfejs jednolity dla wszystkich implementacji CORBA i specyfikujący operacje wspólne dla klientów i serwerów, adapter obiektu jest związany jedynie z obiektem implementującym interfejs, zaś jego funkcje mogą być różne, umożliwiając dopasowanie go do wymagań aplikacji – na przykład pozwalając uzyskiwać dostęp do obiektów zgromadzonych w bazie danych. Adapter stanowi element pośredniczący pomiędzy ORBem a opisanym niżej skeletonem, do jego zadań należy przechwytywanie żądań skierowanych do obiektu i przekazywanie ich do skeletonu oraz m.in. generacja referencji obiektu i jego inkarnacja na żądanie klientów.

  5. Stub serwera (skeleton). Zadaniem skeletonu – odpowiednikiem stuba po stronie serwera – jest delegacja otrzymanego od adaptera obiektu wywołania do skojarzonego obiektu implementującego. Podobnie jak stub zajmuje się serializacją i deserializacją danych.



  1   2   3   4


©operacji.org 2019
wyślij wiadomość

    Strona główna