Efektywnosc wybranych implementacji srodowiska CORBA

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].
komputer klienta
komputer serwera
serwant
klient
skeleton
stub
adapter obiektu
Object Request Broker
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
W przypadku komunikacji z użyciem technologii CORBA w ramach jednego komputera i jednej przestrzeni
adresowej najczęściej ta konstrukcja nie występuje.
1
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.
3. Środowisko testowe
W niniejszym punkcie zostały opisane scenariusze testowe i warunki prowadzenia
badań efektywności wybranych implementacji środowiska CORBA. Przedstawiona
charakterystyka platformy sprzętowej i programowej pozwala zorientować się, jakie
wymagania ze względu na zasoby komputerów stawiają poszczególne implementacje.
Do badań użyto opracowany przez firmę IONA interfejs zawierający wszystkie typy
niezbędne do gruntownego przetestowania implementacji środowiska CORBA.
3.1 Scenariusze testowe
Pomiary dokonane zostały dla dwóch odmiennych modeli testowych. W pierwszym
komunikacja klienta z serwerem odbywała się poprzez sieć komputerową. W drugim zarówno
klient jak i serwer uruchomione były na jednej maszynie (rys. 2).
Komputer 1
Klient
Komputer 2
Serwer
Komputer 1
Klient
Serwer
Sieć lokalna
Rys. 2. Dwa scenariusze prowadzenia testów środowisk CORBA. Po lewej model z transmisją przez sieć,
po prawej transmisja wewnątrzmaszynowa
Takie dwa sposoby pomiaru pozwoliły zbadać zachowanie się w środowiska CORBA w
typowych dla niego warunkach pracy tj. z wykorzystaniem sieci komputerowej i porównać te
wyniki z otrzymanymi dla pracy w warunkach rzadziej spotykanych. Umożliwiło to
stwierdzić jaki wpływ wywiera transmisja w sieci na czas wykonania operacji, a ponadto
zauważyć wymagania co do zasobów systemowych, stawiane przez poszczególne
implementacje.
3.2 Platforma sprzętowa i programowa
Prowadzone testy są kontynuacją badań wykonanych dla firmy IONA, których celem było
porównanie platformy Orbix 3.01 z Orbix 2000. Orbix 2000 jest całkowicie nową
implementacją specyfikacji CORBA stworzoną jako środowisko w pełni modularne
zbudowane w oparciu o architekturę IONA ART (Adaptive Runtime Technology) [4]. Tę
samą architekturę wykorzystuje implementacja Orbix 2000 dla języka Java, co uzasadnia
przeprowadzenie testów porównawczych dla obu tych środowisk. Wszystkie powyższe
implementacje IONA są produktami komercyjnymi, celowe więc wydawało się porównanie
tych produktów z implementacją dostępną darmowo. Podsumowując, podczas testów
wykorzystywano następujące implementacje specyfikacji CORBA:
 Orbix 3.01 z odwzorowaniem IDL do C++,
 Orbix 2000 wersja 1.21 z odwzorowaniem IDL do C++,
 Orbix 2000 wersja 2.0 beta z odwzorowaniem IDL do języka Java,
 CORBA zawarta w środowisku JDK 1.4.
Porównaniu podlegać więc będą dwie implementacje CORBA z odwzorowaniem IDL do
C++ i dwie z odwzorowaniem do języka Java.
Do testów wybrane zostały trzy komputery oznaczane w dalszej części artykułu jako ,
 i  należące do tej samej lokalnej sieci komputerowej, lecz różniące się architekturą
sprzętową i programową. Pozwoliło to zbadać wpływ uwarunkowań systemowych na
efektywność poszczególnych implementacji. Opis parametrów tych komputerów znajduje się
w tabeli 1.
Tabela 1.
Opis parametrów komputerów wykorzystywanych podczas testów
Symbol
komputera
Typ komputera
Procesor(y)



Sun Enterprise 3000
Sun Ultra 1
Sun Ultra 1
3 x UltraSPARC 400 MHz
1 x UltraSPARC 140 MHz
1 x UltraSPARC 140 MHz
Wielkość
Sterownik
pamięci
sieciowy
RAM
1,5 GB
Eth 100 Mb/s
64 MB
Eth 10 Mb/s
64 MB
Eth 10 Mb/s
System
operacyjny
Solaris 2.8
Solaris 2.8
Solaris 2.7
MTU
interfejsu
loopback [B]
8232
8232
8232
Konfiguracja komputera  wyposażonego w starszą wersję systemu operacyjnego
(Solaris 2.7) nie pozwoliła na uruchomienie środowiska Orbix 2000 ani w wersji C++, ani
Java; na maszynie tej testowane więc były tylko Orbix 3.01 oraz implementacja pochodząca z
JDK 1.4. Otrzymano w ten sposób 26 różnych konfiguracji sprzętowo-programowych
pracujących w homogenicznym środowisku CORBA. Przykładowo dla implementacji Orbix
3.01 testowane były następujące konfiguracje sprzętowe: , , , ,
, , , , , gdzie pierwszy symbol oznacza komputer klienta, a
drugi komputer serwera. Z badań wyłączono testy w środowiskach heterogenicznych –
pomiędzy różnymi implementacjami specyfikacji CORBA – co znacząco ułatwiło analizę
wyników.
3.3 Interfejs testowy
Testowy moduł IDL Benchmark opracowano w taki sposób, aby umożliwić zbadanie
wydajności przesyłania możliwie szerokiej grupy typów. Znajdują się w nim definicje kilku
podlegających przesyłaniu typów użytkownika – struktury, unii, interfejsu oraz sekwencji;
fragmenty pliku benchmark.idl z ich definicjami przedstawione są w tabelach 2, 3, 4 i 5.
Moduł definiuje ponadto trzy interfejsy z operacjami do transferu danych. Każdy z nich
zawiera po cztery operacje służące do testowania danego typu; zmienna tego typu zawsze jest
jedynym parametrem operacji, przykładowo:

void short_in_t(in short s);
przesłanie wartości typu short od klienta do serwera

void short_inout_t(inout short s);
przesłanie wartości typu short od klienta do serwera z możliwością jej zmiany w
serwerze

void short_out_t(out short s);
przesłanie wartości typu short od serwera do klienta

short short_ret_t();
przesłanie wartości typu short od serwera do klienta jako wartości zwracanej operacji
Tabela 2.
Definicja unii u1
Tabela 3.
enum discrim1 { e1, e2, e3 };
interface I
{
void foo();
short bar (in short s);
double d ();
};
union u1
switch (discrim1)
{
case e1: short s;
case e2: long l;
case e3: char c;
};
Tabela 4.
Definicja struktury s2
struct s2
{
short s;
long l;
long long ll;
unsigned short us;
unsigned long ul;
float f;
double d;
char c;
string st;
boolean b;
octet o;
any a;
};
Tabela 5.
typedef
typedef
typedef
typedef
typedef
Definicja interfejsu I
Definicja sekwencji
sequence<short> ShortSeq_UB;
sequence<float, 65536> FloatSeq_64K;
sequence<string> StringSeq_UB;
sequence<octet, 1048576> OctetSeq_1M;
sequence<any> AnySeq_UB;
typedef sequence<UserTypes::s2> S2Seq_UB;
Poszczególne interfejsy zawierały operacje służące przesyłaniu zmiennych następujących
typów:
1. Interfejs BasicTester
 Wbudowane typy proste CORBA takie jak: char, short, double, octet.
 Typ łańcuchowy (string).
 Typ Any.
2. Interfejs UserTypeTester – struktura s2, unia u1 oraz interfejs I (tab. 2, 3, 4).
3. Interfejs SequenceTester – sekwencje (tab. 5), zarówno o ograniczonej
maksymalnej długości (ang. bounded) jak i nielimitowane składające się z elementów
będących:
 typami prostymi,
 strukturami s2,
 zmiennymi Any.
3.4 Metoda prowadzenia pomiarów
Wszystkie operacje z interfejsu IDL miały domyślny atrybut twoway, dzięki czemu
możliwe było dokonywanie pomiaru po stronie klienta – bezpośrednio przed i bezpośrednio
po wykonaniu operacji. Do pomiaru czasu wykorzystano standardową funkcję
gettimeofday, która odmierza czas z dokładnością do 1 mikrosekundy. (W środowisku
Java do wywołania jej niezbędne było skorzystanie z mechanizmu JNI). Sam czas
dokonywania pomiaru nie zaburza wyniku, gdyż trwa około 1 s (a więc jest co najmniej trzy
rzędy wielkości krótszy niż mierzone wartości) i w związku z tym został zaniedbany. Od
wyniku pomiaru odejmowano – tam, gdzie to było możliwe – czas przetwarzania danych po
stronie serwera. W celu zwiększenia jakości otrzymanych wyników każdy z testów
powtarzany był 200 razy. Na etapie opracowywania wyników odrzucane były wartości
znacznie przewyższające pozostałe rezultaty, których występowanie spowodowane było
najczęściej chwilowymi zmianami obciążenia sieci lub serwerów.
4. Analiza wyników badań
Otrzymane wyniki pozwolą określić różnice w wydajności testowanych implementacji
standardu CORBA. Istotne przy tym jest, że pomiary wykonywane były przy współpracy
serwera z pojedynczym klientem w warunkach laboratoryjnych (tj. przy wyeliminowaniu
możliwie szerokiej gamy czynników zakłócających pracę sieci oraz komputerów testowych).
Pozwoliło to w dokładny sposób zbadać czasy wykonania operacji, z drugiej jednak strony,
warunki pracy programów testujących odbiegały znacząco od warunków normalnej
eksploatacji oprogramowania CORBA, przez co zostało pominięte wiele innych czynników
mających wpływ na wydajność implementacji.
4.1 Wyniki uzyskane dla typów prostych
Rysunek 3 przedstawia wykres zależności czasu wykonania operacji (z atrybutem in)
przesłania wartości typu short od zastosowanego środowiska i komputerów, na których
pracował klient i serwer. Typ short wybrany został w opracowaniu jako reprezentant całej
grupy typów prostych; wyniki dla pozostałych typów prostych były bardzo zbliżone.
Zachowanie takie spowodowane jest przez podobną serializację typów prostych oraz zbliżony
rozmiar danych nie przekraczający rozmiaru MTU ani dla interfejsu loopback, ani dla
Ethernet.
14,00
Orbix 3.01
Orbix 2000 C++
12,00
Java 1.4
Orbix 2000 Java
czas wykonania [ms]
10,00
8,00
6,00
4,00
2,00
0,00









komputer klienta - komputer serwera
Rys. 3. Czas wykonania operacji przesłania wartości (z atrybutem in) typu short w zależności od
konfiguracji sprzętowej i programowej
Z przedstawionego rysunku można jednoznacznie stwierdzić, że wydajność
implementacji środowiska CORBA dla języka C++ jest większa niż tych dla języka Java.
Stosunek
wydajności
jest
szczególnie
duży
przy
wykonaniu
połączenia
wewnątrzmaszynowego (,  oraz ). Jest to spowodowane dużym
obciążeniem maszyny generowanym przez dwa środowiska Javy pracujące jednocześnie.
Efekt ten jest szczególnie zauważalny na komputerach  oraz , które są wyposażone w
stosunkowo niewielkie zasoby. Wyjaśnienia wymaga również nieco gorsza wydajność
komputera  w stosunku do . Jak wspomniano wcześniej, maszyna  wyposażona została
w starszą wersję systemu operacyjnego, przez co niemożliwe było uruchomienie na niej
środowisk Orbix 2000. Podczas testów na komputerze  uruchomiono mniejszą ilość
serwerów, na skutek czego dostępnych było więcej zasobów pamięci i procesora. Rysunek 3
pokazuje więc także wpływ obciążenia generowanego przez środowiska CORBA na pracę
systemu. W przypadku implementacji dla Javy mniejsza ilość zasobów spowodowała dość
znaczne zmniejszenie wydajności (patrz  oraz  dla Java 1.4).
4.2 Wyniki uzyskane dla typów złożonych
Rezultaty otrzymane dla typów złożonych mają bardzo zbliżony charakter do tych
osiągniętych przy transmisji danych prostych. W szczególności dotyczy to przesyłania
łańcuchów znaków czy sekwencji. Rysunek 4 przedstawia omawianą zależność dla transmisji
łańcucha znaków o przykładowej długości 36 kB. To, co wyraźnie odróżnia te rezultaty od
przedstawionych na rysunku 2, to zwiększenie wydajności transmisji wewnątrzmaszynowych
w stosunku do przesyłania w sieci (z wyjątkiem środowiska Orbix 2000 dla języka Java, które
wyraźnie odbiega wydajnością od pozostałych). Wpływ na taką tendencję ma opóźnienie
generowane przez transmisję większej ilości danych w sieci. Warto zauważyć również, że
podobnie jak dla typów prostych stosunek wydajności poszczególnych implementacji
środowiska CORBA dla przesyłania w sieci pozostaje niemal niezmieniony.
120,00
Orbix 3.01
Orbix 2000 C++
100,00
Java 1.4
Orbix 2000 Java
czas wykonania [ms]
80,00
60,00
40,00
20,00
0,00









komputer klienta - komputer serwera
Rys. 4. Zależność czasu wykonania operacji przesłania łańcucha znaków o długości 36 kB z atrybutem
in od rodzaju środowiska dla różnych konfiguracji sprzętowych
Dokonano także gruntownych testów operacji przesyłających łańcuchy znaków i
sekwencji. Zgodnie z przewidywaniami czas wykonania operacji przesłania danych jest
zależny liniowo od ich rozmiaru. Wśród czterech testowanych środowisk implementujących
standard CORBA tylko Orbix 2000 dla Javy wykazywał niestabilne zachowanie przy
przesyłaniu ciągów danych.
Na rysunku 5 przedstawiono zależność czasu wykonania operacji transmisji (z
atrybutem in) łańcucha znaków w zależności od długości łańcucha dla implementacji Orbix
2000 w wersji Java. Przesyłanie danych w sieci nie wykazało żadnych nieprzewidzianych
efektów, inaczej jest natomiast z operacją wykonywaną z ramach jednego komputera. W tym
przypadku omawiana zależność jest funkcją prostokątną o okresie 16 kB. Podobne
zachowanie się środowiska Orbix 2000 dla Javy obserwowano podczas przesyłania
sekwencji. Efekt ten został dokładnie opisany i przedstawiony firmie IONA do konsultacji.
400,00

350,00



czas wykonania [ms]
300,00
250,00
200,00
150,00
100,00
50,00
0,00
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
długość łańcucha [4 kB]
Rys. 5. Zależność czasu wykonania operacji przesłania łańcucha znaków (atrybut in) od długości
łańcucha dla środowiska Orbix 2000 w wersji Java
Kolejna grupa testów obejmowała efektywność przesyłania struktur danych
zagnieżdżonych w zmiennej typu Any. Jak należało zakładać, czas wykonania operacji jest
liniowo zależny od poziomu zagnieżdżenia. W przypadku implementacji w języku Java
pojawiają się nieco zaskakujące rezultaty (rysunek 6). Przesłanie wartości typu prostego
umieszczonej w Any jest szybsze niż bezpośrednie przesłanie wartości, bez zagnieżdżenia w
Any. Takie zachowanie się spowodowane jest tym, że pomiar czasu wykonania operacji dla
wartości typu Any nie uwzględniał czasu insercji2. Implementacje w języku Java
przygotowują zapewne dane do transmisji już w czasie insercji do Any. Przedstawione
kilkumilisekundowe przyspieszenie dla typów prostych jest niezauważalne przy przesyłaniu
dużej ilości danych w zależności od zagnieżdżenia w Any. Na rysunku 7 pokazano tę samą,
co poprzednio, zależność z tym, że przesyłaną wartością była sekwencja struktur s2 o
długości 2000 (w strukturze ulokowany był łańcuch znaków o długości 40 B oraz wartość
typu short umieszczona w Any). W tym przypadku we wszystkich implementacjach
przesłanie wartości bezpośrednio bez zagnieżdżenia w Any jest szybsze. Ponadto każde
kolejne zagnieżdżenie daje bardzo niewielki przyrost czasu wykonania – co dobrze świadczy
o efektywności operacji insercji.
W zależności od programisty może ona przebiegać w różny sposób: dane do insercji mogą pochodzić
bezpośrednio ze zmiennej, ale także np. ze strumienia danych. Ponadto celem badań było jedynie ustalenie czasu
wykonania operacji, insercja znalazła się więc poza pomiarem czasu.
2
800,00
bez zagnieżdżenia
1-krotne zagnieżdżenie
700,00
3-krotne zagnieżdżenie
5-krotne zagnieżdżenie
czas wykonania [ms]
600,00
500,00
400,00
300,00
200,00
100,00
0,00
Orbix 3.01
Orbix 2000 dla C++
JDK 1.4
Orbix 2000 dla Javy
rodzaj środowiska
Rys. 6. Zależność czasu wykonania operacji przesłania (z atrybutem in) wartości typu short od
poziomu zagnieżdżenia danych w Any i rodzaju środowiska CORBA
Wszystkie prezentowane dotychczas rezultaty odnosiły się do operacji transmisji
danych z atrybutem in. Przeprowadzone badania obejmowały także pozostałe sposoby
przesyłania (z atrybutem out, inout oraz przez wartość zawracaną), które wykazywały
zależności podobne do opisanych wyżej. Ponadto jak należało się spodziewać operacje
przesyłania danych z atrybutem in i out są symetryczne. Oznacza to, że szybkość wykonania
operacji z atrybutem in dla pary komputerów np.  jest niemal taka sama jak operacji z
atrybutem out dla pary . Pełniejsze zestawienie przedstawiono w tabeli 6, gdzie dla
poszczególnych implementacji zestawiono wyniki przesłania sekwencji oktetów o długości
25000.
Tabela 6.
in
out
Porównanie czasów przesłania sekwencji oktetów o długości 25000 w zależności od kierunku
transmisji danych i mocy obliczeniowej komputerów dla testowanych środowisk
Orbix 3.01


26,93 ms 30,67 ms
30,81 ms 27,09 ms
Orbix 2000 dla C++


23,16 ms 27,83 ms
25,17 ms 23,72 ms
Java 1.4


26,32 ms 30,91 ms
30,31 ms 26,36 ms
Orbix 2000 dla Javy


119,92 ms 119,73 ms
119,95 ms 119,79 ms
8,00
bez zagnieżdżenia
7,00
2-krotne zagnieżdżenie
4-krotne zagnieżdżenie
6-krotne zagnieżdżenie
czas wykonania [ms]
6,00
5,00
4,00
3,00
2,00
1,00
0,00
Orbix 3.01
Orbix 2000 C++
Java 1.4
Orbix 2000 Java
rodzaj środowiska
Rys. 7. Zależność czasu wykonania operacji (z atrybutem in) przesłania sekwencji struktur o długości
2000 od poziomu zagnieżdżenia w Any i rodzaju środowiska CORBA
5. Podsumowanie
Zaprezentowane wyniki badań i tabele obrazują wybrane najistotniejsze i najciekawsze
rezultaty, które pozwalają zorientować się w jakości testowanych środowisk. Pozostałe
otrzymane wyniki mają charakter bardzo zbliżony do przedstawionych, co pozwala stwierdzić
jednoznacznie, że implementacje dla języka C++ są wydajniejsze od implementacji dla języka
Java. Środowisko Orbix 2000 dla Javy (wersja beta) jest najsłabszym produktem z
testowanych i wyraźnie odstaje od trzech pozostałych implementacji, a niestabilne
zachowanie się zmniejsza dodatkowo jego przydatność. Mimo, że otrzymane wyniki
wykazują lepsze rezultaty dla implementacji języka C++, warto zwrócić uwagę na środowisko
pochodzące z JDK 1.4. Czasy wykonania operacji otrzymane dla implementacji firmy Sun są
ok. 50% gorsze od implementacji Orbix 2000 dla C++, jednak łatwość programowania i
przejrzystość kodu w języku Java mogą w niektórych przypadkach wystarczająco
wynagrodzić słabszą wydajność.
Przeprowadzone testy wykazały, że obie testowane implementacje standardu CORBA
dla języka C++ są znacząco szybsze podczas pracy klienta i serwera na jednym komputerze.
Istotny jest również fakt, że obciążenie generowane przez środowisko uruchomieniowe Java
powodowało spadek wydajności wykonania testowanych operacji, co jest szczególnie
zauważalne podczas pracy aplikacji testowej na komputerach z mniejszą ilością zasobów – 
i . Ze względu jednak na przeznaczenie środowiska CORBA do pracy w sieci, wydaje się
mieć to mniejsze znaczenie.
6. Literatura
1.
2.
3.
4.
Object Management Group, The Common Object Request Broker: Architecture and
Specification, 1998.
IONA Technologies, Orbix2000 Programmer’s Guide, IONA Technologies PLC, 2000.
IONA Technologies, Orbix C++ Programmer’s Guide, IONA Technologies PLC, 1999.
IONA Technologies, IONA Adaptive Runtime Technology,
http://www.iona.com/products/arthome.htm
5.
M. Henning, S. Vinoski, Advanced CORBA Programming with C++, Addison-Wesley,
1999.
6. G. Clarke, R. Kempson, Introduction to the Design and Analysis of Experiments, Arnold,
Londyn, 1997.
7. A. Zeliaś, Metody statystyczne, Polskie Wydawnictwo Ekonomiczne, 2000.
8. Object Management Group, Model Driven Architecture, 2000;
http://www.omg.org/mda/papers.htm
9. The Source for Java Technology, Sun Microsystems; http://java.sun.com
10. W.R. Stevens, Programowanie zastosowań sieciowych w systemie Unix, WydawnictwaNaukowo Techniczne, Warszawa 1996.
11. OmniORB, Free High Performance CORBA 2 ORB from AT&T Laboratories
Cambridge; http://www.uk.research.att.com/omniORB