Architektury systemów rozproszonego przetwarzania danych

Pełen tekst

(1)Zeszyty Naukowe nr 764. 2007. Uniwersytetu Ekonomicznego w Krakowie. Pawe∏ Lula Katedra Informatyki. Tadeusz Wilusz Katedra Informatyki. Architektury systemów rozproszonego przetwarzania danych Streszczenie: w artykule, na podstawie dostępnych źródeł literaturowych, przedstawiono najważniejsze elementy współczesnych koncepcji budowy systemów rozproszonego przetwarzania danych. Główny nacisk położono na architekturę obiektów rozproszonych (OMG) i zbiór standardów CORBA. Obserwacja trendów rozwojowych współczesnych technologii informacyjnych nie pozostawia wątpliwości, że prezentowane w artykule rozwiązania można z dużym prawdopodobieństwem traktować jako najbliższą generację technologii systemów informacyjnych. Słowa kluczowe: systemy informacyjne, systemy informatyczne, systemy rozproszone, CORBA, ORB, architektura klient–serwer, architektura obiektów rozproszonych. 1 Wst´p Systemem rozproszonym nazywamy taki system, w którym przetwarzanie informacji jest wykonywane na kilku komputerach, a nie przydzielone do jednej maszyny. Komputery te mogą być istotnie oddalone geograficznie (od kilku metrów do dziesiątków tysięcy kilometrów – porównaj dane w tabeli 2). Przeciwieństwem systemów rozproszonych są systemy scentralizowane, które historycznie pojawiły się jako pierwsze. Lista współcześnie najważniejszych systemów da się sprowadzić do trzech pozycji. Są to:.

(2) Paweł Lula, Tadeusz Wilusz. 58. – systemy osobiste, które nie są rozproszone i są przeznaczone do pracy na komputerze osobistym lub stacji roboczej. Przykładami takich systemów są m.in. procesory tekstów, arkusze kalkulacyjne, systemy graficzne itd.; – systemy wbudowane, które działają na jednym procesorze lub na zintegrowanej grupie procesorów. Przykładami takich systemów są m.in. systemy sterowania sprzętem domowym, systemy sterujące przyrządami itd.; – systemy rozproszone, w których oprogramowanie systemowe działa na luźno zintegrowanej grupie współpracujących procesorów połączonych siecią. Przykładami takich systemów są m.in. systemy bankomatów, systemy rezerwacji, systemy pracy grupowej itd. Tabela 1. Zagadnienia projektowania systemów rozproszonych Zagadnienie projektowe. Opis. Identyfikacja zasobów. Zasoby systemu rozproszonego są rozmieszczone na różnych komputerach, należy więc opracować schemat nazewnictwa, aby użytkownicy mogli znajdować i wykorzystywać potrzebne im zasoby. Przykładem takiego schematu jest URL (Uniform Resource Locator – zunifikowany adres zasobu) służący do identyfikacji stron www. Jeśli nie zastosuje się znaczącego i powszechnie rozumianego schematu, to wiele zasobów będzie niedostępnych dla użytkowników systemu. Komunikacja. Powszechna dostępność sieci i efektywna implementacja jej protokołu komunikacyjnego TCP/IP oznacza, że jest to najskuteczniejszy sposób komunikacji komputerów w wypadku większości systemów rozproszonych. Tam, gdzie występują szczególne wymagania efektywnościowe, niezawodnościowe itd. można skorzystać z innych mechanizmów komunikacji. Jakość usług. Jakość usług oferowanych przez system odzwierciedla jego efektywność, dostępność i niezawodność. Mają na nią wpływ także inne czynniki, takie jak przydział procesów do procesorów systemu, rozproszenie zasobów w ramach systemu, sprzęt sieciowy i systemowy oraz zdolność systemu do adaptacji. Architektura oprogramowania. W architekturze oprogramowania opisuje się, w jaki sposób funkcjonalność programu użytkowego rozproszono na kilku logicznych komponentach oraz jak te komponenty rozproszono na procesorach. Wybór odpowiedniej architektury programu użytkowego jest zasadniczym warunkiem osiągnięcia pożądanej jakości usług. Źródło: [Sommerville 2003].. Obecnie łatwo jest rozróżnić te rodzaje systemów, ale dynamiczny rozwój szybkich sieci (zwłaszcza bezprzewodowych) zatrze te różnice w niedalekiej przyszłości. Przykładowo, w świecie szybkich sieci bezprzewodowych będzie łatwo.

(3) Architektury systemów rozproszonego…. 59. dynamicznie integrować z bardziej ogólnymi systemami produkty zawierające systemy wbudowane (np. elektroniczne terminarze). W zasadzie już teraz można zaryzykować tezę, że niemal wszystkie współczesne systemy są rozproszone. Dzieje się tak za sprawą Internetu, który powoduje, że najważniejsza ostoja systemów scentralizowanych, jaką współcześnie jest komputer osobisty, podłączona do Internetu może śmiało być traktowana w kategoriach elementu składowego systemu rozproszonego. Projektowanie i własności systemów rozproszonych w dużej mierze są takie same jak systemów scentralizowanych, ale istnieją także istotne różnice, których wszyscy zainteresowani współczesnymi systemami przetwarzania danych (a w szczególności specjaliści w zakresie inżynierii oprogramowania) winni być świadomi. Zagadnienia wskazywane w literaturze (por. [Colorouis, Dollimore, Kindberg 1998]), jako krytyczne dla projektowania systemów wymieniono w tabeli 1. Tematyka tego opracowania jest związana z ostatnim z wymienionych w powyższym zestawieniu zagadnień. Celem opracowania jest bowiem prezentacja podstawowych koncepcji stanowiących fundament współczesnej architektury systemów rozproszonych. W szczególności z punktu widzenia projektowania rozproszonych systemów gromadzenia i analizy danych istotnym jest wyeksponowanie najważniejszych różnic pomiędzy architekturą klient–serwer i architekturą obiektów rozproszonych, a w obrębie tej ostatniej najważniejszych zasad standardów CORBA. 2. Architektury wieloprocesorowe Najprostszym modelem systemu rozproszonego jest system wieloprocesorowy, składający się z kilku różnych procesów, które mogą (ale nie muszą) działać na oddzielnych procesorach. Ten model powszechnie występuje w wielkich systemach czasu rzeczywistego. Takie systemy zbierają informacje, na ich podstawie podejmują decyzje i wysyłają sygnały do efektorów, które oddziałują na środowisko systemu. Z logicznego punktu widzenia procesy zajmujące się zbieraniem informacji, podejmowaniem decyzji i sterowaniem efektorami mogłyby działać na jednym procesorze sterowanym przez moduł szeregujący. Użycie wielu procesorów poprawia efektywność i odporność systemu. Przydział procesów do procesorów może być zadany z góry (tak zwykle jest w systemach krytycznych) albo sterowany przez dyspozytora, który decyduje o przyznaniu procesowi procesora. Na rys. 1 w charakterze przykładu takiego systemu pokazano uproszczony model systemu kierowania ruchem drogowym. Zbiór rozproszonych detektorów zbiera informacje o natężeniu ruchu, przetwarza je lokalnie, po czym przesyła do centrum sterowania. Centrum sterownia wypracowane na podstawie otrzymanych informacji decyzje przekazuje w formie odpowiednich poleceń do oddzielnego.

(4) Paweł Lula, Tadeusz Wilusz. 60. procesu sterowania światłami. W rezultacie, w tym przykładzie, możemy mówić o trzech logicznie wydzielonych procesach (lub trzech grupach procesów), które działają na oddzielnych procesorach.. . .

(5) .

(6). .

(7) . Rys. 1. Przykład systemu wieloprocesorowego Źródło:opracowanie własne na podstawie [Sommerville 2003].. Systemy oprogramowania zbudowane z wielu procesów mogą, ale nie muszą być systemami rozproszonymi. Wynika to stąd, że historycznie wieloprocesorowość pojawiła się jako jedna z technologii zwiększania mocy obliczeniowej i wydajności systemów o architekturze scentralizowanej. W tabeli 2 przywołano klasyfikację systemów powstałych z określonego sposobu połączenia procesorów, która stara się doprecyzować znaczenie powszechnie używanych terminów dla funkcjonujących w praktyce systemów wieloprocesorowych. Tabela 2. Klasyfikacja systemów powstałych z połączenia procesorów Odległości między procesorami. Rozmieszczenie procesorów w obrębie jednego. Przykład. 0,1 m. pakietu. maszyny przepływowe. 1m. systemu. systemy wieloprocesorowe. 10 m. pomieszczenia. 100 m. budynku. 1 km. terenu firmy (np. uczelni). 10 km. miasta. 100 km. kraju. 1000 km. kontynentu. 10 000 km. planety. Źródło: [Tanenbaum 1998].. sieci lokalne. sieci dalekosiężne (rozległe) intersieci powstałe z połączenia sieci dalekosiężnych.

(8) Architektury systemów rozproszonego…. 61. 3. Podstawowe własnoÊci systemów rozproszonych Jako podstawowe zalety systemów rozproszonych najczęściej wymienia się sześć, następujących cech Colorouis, Dollimore, Kindberg 1998]: – współdzielenie zasobów – system rozproszony umożliwia współdzielenie zasobów sprzętowych i programowych umieszczonych na różnych komputerach w sieci, np. dysków, drukarek, plików, kompilatorów itd.1; – otwartość – ta cecha systemu charakteryzuje łatwość rozszerzania go o nowe nie należące do niego zasoby. Systemy rozproszone są otwarte i zwykle zawierają sprzęt i oprogramowanie różnych producentów; – współbieżność – w systemie współbieżnym kilka procesów może działać na różnych komputerach w tym samym czasie. Procesy te mogą (ale nie muszą) komunikować się podczas swojego działania; – skalowalność – moc i możliwości przetwarzania może wzrastać w miarę dodawania do systemu nowych zasobów, w szczególności komputerów. W praktyce skalowalność jest często ograniczona poprzez przepustowość sieci oraz (niekiedy) poprzez np. specyficzne protokoły wymiany informacji. Niemniej skalowalność systemu rozproszonego jest nieporównywalnie lepsza w stosunku do systemu scentralizowanego; – tolerancja błędów (odporność na awarie) – dostępność wielu komputerów oraz możliwość dublowania informacji (replikacje) oznacza, że systemy rozproszone powinny być odporne na pewne awarie zarówno sprzętowe, jak i programowe. Przykładowo, awaria węzła komunikacyjnego powoduje wygenerowanie innej trasy przepływu informacji. Zwykle całkowity zanik obsługi zdarza się jedynie w wypadku awarii sieci; – przezroczystość – polega na ukryciu przed użytkownikiem rozproszonej natury systemu. Przezroczystość ma istotne znaczenie przede wszystkim dla komfortu pracy użytkownika (pozwala korzystać z zasobów i usług systemu bez jakiejkolwiek potrzeby wnikania w szczegóły implementacyjne systemu) oraz dla niezawodności budowanego oprogramowania (m.in. dlatego, że potencjalne błędy użytkownika są dużo łatwiej poddają się kontroli na poziomie abstrakcji użytkowej systemu aniżeli na poziomie jego fizycznej implementacji). Warto przy tym zauważyć, że w wielu wypadkach udostępnienie użytkownikom pewnej wiedzy o organizacji systemu umożliwia im jednak lepsze korzystanie z jego zasobów. Powszechnie znanym przykładem przezroczystości jest Internet: klikając odnośnik na stronie www użytkownik nie musi wiedzieć, gdzie znajduje się odpowiadający mu zasób oraz jak i na czym jest zaimplementowany. 1 Współdzielenie zasobów może dotyczyć także scentralizowanej architektury systemu wielodostępnego, ale w takim wypadku wszystkie zasoby są oferowane przez menedżera zasobów takiego systemu..

(9) 62. Paweł Lula, Tadeusz Wilusz. Korzyści, jakie oferują systemy rozproszone mają swoją cenę, którą stanowi zwiększony stopień trudności w obrębie zagadnień wyspecyfikowanych niżej. Ponieważ w tych obszarach systemy o scentralizowanej architekturze sprawiają zdecydowanie mniej kłopotów, więc poniższą listę można traktować jako wykaz najważniejszych słabości systemów rozproszonych (w odniesieniu do systemów zcentralizowanych): – złożoność – systemy rozproszone, jako bardziej złożone od scentralizowanych, są trudniejsze do zaprogramowania i do administrowania. Zależą od własności sieci, np. jej przepustowości i czasu transmisji, co nie tylko utrudnia zaprojektowanie i realizację wielu algorytmów procesu przetwarzania, ale również pełne rozumienie zachowań systemu, a co za tym idzie jego testowanie. Przenoszenie zasobów z jednej części systemu do innej (replikacja) może przy tym drastycznie wpływać na efektywność systemu; – ochrona (zabezpieczenie) – system zcentralizowany może być skutecznie chroniony już na poziomie zabezpieczeń fizycznych i organizacyjnych („strażnik z karabinem”). System rozproszony z definicji musi być i jest dużo bardziej narażony na różnorodne zagrożenia (włamania, wirusy, sabotaż, odmowa płatności itd.) pojawiające się z wielu stron, które trudno zidentyfikować. To sprawia, że zarządzanie bezpieczeństwem systemu rozproszonego jest trudniejsze; – łatwość zarządzania – zarządzanie systemem rozproszonym jest niepomiernie trudniejsze niż zcentralizowanym wskutek tego, że konsekwencje różnych działań administracyjnych w systemie rozproszonym są trudniejsze do zidentyfikowania. Podobnie z przyczynami sytuacji anormalnych, w szczególności awarii (w sieci mogą być komputery rozmaitych typów i mieć różne wersje systemów operacyjnych, awarie jednej maszyny mogą rozszerzać się na inne maszyny i powodować niespodziewane konsekwencje); – nieprzewidywalność – system rozproszony jest nieprzewidywalny w swoim działaniu, ponieważ zakłócenia mogą być powodowane przez wiele przyczyn: małą przepustowość i awarię łączy, awarię komputerów, zbyt duże obciążenie danego serwera, lokalne decyzje administracji serwera itd. Przykładem „eksploatacyjnej” nieprzewidywalności systemu rozproszonego może być bardzo duża wariancja czasu odpowiedzi w systemie www, o czym doskonale wiedzą wszyscy jego użytkownicy. Z powyższej charakterystyki wynika, że podstawowym wyzwaniem przy projektowaniu systemów rozproszonych jest opracowanie projektu oprogramowania i sprzętu tak, aby miały pożądane cechy w ramach systemu rozproszonego i aby zmniejszyć kłopoty charakterystyczne dla architektur systemów rozproszonych. Jak do tej pory nie znaleziono uniwersalnego rozwiązania tak postawionego problemu, a funkcjonujące w praktyce rozwiązania dają się zaklasyfikować do jednej z następujących architektur rozproszenia:.

(10) Architektury systemów rozproszonego…. 63. – architektury klient–serwer – w tym podejściu system jest postrzegany jako zbiór usług oferowanych klientom, którzy z nich korzystają. W takich systemach odmiennie traktuje się serwery i klientów; – architektury obiektów rozproszonych – w tym podejściu nie istnieje rozróżnienie między klientami i serwerami. System jest postrzegany jako zbiór komunikujących się obiektów, których położenie jest nieistotne. Nie ma różnicy między dostawcą i użytkownikiem usług. Architektury te bazują na koncepcji oprogramowania pośredniczącego (middleware); – architektury sieci równorzędnych (peer-to-peer) – w tym przypadku wiele węzłów świadczy sobie wzajemne usługi poprzez bezpośrednie połączenie. Podobnie jak w architekturze obiektów rozproszonych nie ma wyraźnego podziału na usługodawców i usługobiorców. Każdy węzeł może być jednocześnie klientem i serwerem usług. Architekturę peer-to-peer będącą historycznie prekursorem architektury obiektów rozproszonych z epoki powstania i rozwoju lokalnych sieci komputerowych można współcześnie traktować jako szczególny rodzaj tej ostatniej. Dlatego też dalsze rozważania ograniczono do architektury klient–serwer i architektury obiektów rozproszonych. 4. Architektury klient–serwer W architekturze klient–serwer program użytkowy jest modelowany jako zbiór usług oferowanych przez serwery i zbiór klientów, którzy z tych usług korzystają. Klienci muszą znać dostępne serwery, ale zwykle nie muszą wiedzieć o istnieniu innych klientów. Klienci i serwery są oddzielnymi procesami, jak pokazano na rys. 2, który jest logicznym modelem rozproszonej architektury klient–serwer.. k2. k3. k7. k1 s4. k4. k5. s1. k8 s3. s2. k9. k6. k10 k11. Rys. 2. Architektura klient–serwer: si – proces serwera, kn – proces klienta Źródło: [Sommerville 2003]..

(11) Paweł Lula, Tadeusz Wilusz. 64. k3, k6 k1, k2. kk2. kk1. k4, k5 kk3. s1, s2, s3. s4 Sieć komputerowa. ks1. kk4. k7, k11. ks2. kk5. k8, k9, k10. Rys. 3. Komputery w sieci klient–serwer komputer serwera – komputer klienta Źródło: opracowanie własne.. Procesy i procesory systemu nie muszą być wzajemnie jednoznacznie przyporządkowane. Na rys. 3 pokazano fizyczną architekturę systemu z dwoma komputerami serwerów i pięcioma komputerami klientów. Mogą na nich działać procesy klientów i serwerów z rys. 2. Oznacza to, że terminy „klient” oraz „serwer” należy rozumieć jako odniesienia do logicznych procesów „usługobiorcy” i „usługodawcy”, a nie jako odniesienia do fizycznych komputerów, na których te procesy działają.. Warstwa prezentacji. Warstwa przetwarzania. Warstwa zarządzania danymi. Rys. 4. Warstwy programu użytkowego Źródło: [Sommerville 2003].. Projekt systemu klient–serwer powinien odzwierciedlać logiczną strukturę tworzonego programu użytkowego. Na rys. 4 pokazano jeden ze sposobów postrzegania programu użytkowego złożonego z trzech warstw. Warstwa prezentacji to inaczej warstwa interfejsu użytkownika. W warstwie przetwarzania.

(12) Architektury systemów rozproszonego…. 65. implementuje się logikę programu użytkowego. Warstwa zarządzania danymi jest odpowiedzialna za wszystkie operacje na danych (najczęściej przechowywanych w bazach danych). W systemie scentralizowanym nie ma potrzeby jawnego wydzielania tych warstw. Projektując system rozproszony, trzeba jednak wyraźnie je wyróżnić, ponieważ umożliwia to realizację funkcji każdej warstwy na różnych procesorach (komputerach). Korzystając z wprowadzonego warstwowego modelu aplikacji architektury klient–serwer można się przedstawić w sposób pokazany na rys. 5. Program użytkowy składa się wówczas z serwera (lub wielu identycznych serwerów) i zbioru klientów. Jak wynika z pokazanych schematów, możliwe są dwa podstawowe warianty architektury klient–serwer: – model cienkiego klienta2 – w tym modelu całość przetwarzania i zarządzania danymi ma miejsce na serwerze. Jedynym zadaniem klienta jest uruchomienie oprogramowania prezentacyjnego; – model grubego klienta – w tym modelu serwer odpowiada przede wszystkim za zarządzanie danymi. Oprogramowanie u klienta implementuje logikę programu użytkowego i kontakt z użytkownikiem systemu. W praktyce współczesnych systemów funkcja warstwy przetwarzania najczęściej jest realizowana wspólnie (w różnych proporcjach w zależności od konkretnych potrzeb) przez procesy zarówno po stronie klienta, jak i serwera. Stwarza to duże problemy projektowe..

(13) . . . . .

(14) . . Rys. 5. Uproszczone architektury trójwarstwowe z cienkim lub grubym klientem Źródło: [Sommerville 2003].. 2 Terminy „cienki klient” oraz „gruby klient”, pomimo pewnej niezgrabności językowej, są powszechnie używanymi terminami na gruncie polskojęzycznej terminolgii systemów rozproszonych z racji braku lepszych odpowiedników anglojęzycznych pierwowzorów, jakimi są terminy thin client oraz fat client..

(15) Paweł Lula, Tadeusz Wilusz. 66. Architektura z „cienkim klientem” jest najprostszym rozwiązaniem, które nader często jest wykorzystywane w scentralizowanych systemach odziedziczonych ewoluujących w kierunku architektur klient–serwer. Interfejs użytkownika tych systemów jest przenoszony na komputer osobisty, a program użytkowy działa jako serwer i obsługuje przetwarzanie użytkowe oraz zarządzanie danymi. Model cienkiego klienta może być również zaimplementowany tam, gdzie klienci są raczej prostymi urządzeniami sieciowymi, a nie komputerami osobistymi albo stacjami roboczymi. Na takim urządzeniu sieciowym działa przeglądarka sieci oraz interfejs użytkownika realizowany przez ten system. Najważniejszą wadą modelu cienkiego klienta jest duże obciążenie zarówno sieci (transmisją), jak i serwera (przetwarzaniem). Serwer odpowiada za wszystkie obliczenia, co może prowadzić do dużego ruchu sieciowego między klientem a serwerem. Współczesne komputery osobiste mają dużą moc obliczeniową, z której w modelu cienkiego klienta się nie korzysta. W modelu grubego klienta korzysta się natomiast z dostępnej mocy obliczeniowej na stacji roboczej i przekazuje klientowi zarówno przetwarzanie związane z logiką programu użytkowego, jak i prezentację. Serwer jest zasadniczo serwerem transakcji, który zarządza transakcjami w bazie danych. Dobrze znanym przykładem architektury tego typu są systemy bankomatów. Bankomat jest tam klientem, a serwerem jest komputer główny obsługujący bazę danych kont klientów.. Bankomat. Bankomat. Serwer kont klientów banku Monitor teleprztwarzania. Baza danych kont klientów banku. Bankomat. Bankomat. Oprogramowanie pośredniczące organizujące komunikację z odległymi klientami i szeregujące transakcje klientów celem przetwarzania ich przez bazę danych. Rys. 6. Sieć bankomatów jako przykład architektury klient–serwer Źródło: opracowanie własne na podstawie [Sommerville 2003].. Na rys. 6 przedstawiono taką sieć bankomatów. Warto zauważyć, że bankomaty nie łączą się bezpośrednio z bazą danych o klientach, ale z monitorem przetwarzania zdalnego. Jest to system klasy middleware, który zarządza komunikacją.

(16) Architektury systemów rozproszonego…. 67. z klientami zdalnymi i szereguje transakcje klientów przed przetwarzaniem ich w bazie danych. Zastosowanie transakcji szeregowych umożliwia odtworzenie systemu po awarii bez uszkadzania danych. W modelu grubego klienta przetwarzanie jest bardziej efektywne niż w wypadku modelu cienkiego klienta, zarządzanie systemem jest natomiast trudniejsze. Funkcjonalność programów użytkowych jest rozproszona po wielu różnych komputerach. Gdy konieczna jest zmiana oprogramowania użytkowego, trzeba wykonać ponowną instalację na każdym komputerze klienta. Jeśli w systemie są setki komputerów, to taka operacja może stanowić najistotniejszy koszt takiej poprawki. Pojawienie się Javy i ściąganych apletów3 umożliwiło opracowanie modelu klient–serwer, który leży gdzieś między modelem cienkiego klienta i modelem grubego klienta. Części oprogramowania przetwarzającego mogą być przekazane klientowi w postaci apletów Javy, co zmniejsza obciążenia serwera. Interfejs użytkownika jest budowany dla przeglądarki www, w której mogą działać aplety4.. .

(17) .

(18) .

(19)

(20) . . Rys. 7. Trójwarstwowa architektura klient–serwer Źródło: [Sommerville 2003].. Zasadnicza trudność dotycząca dwuwarstwowego podejścia klient–serwer polega na tym, że trzy warstwy logiczne (prezentacja, przetwarzanie użytkowe i zarządzanie danymi) muszą być przyporządkowane do dwóch systemów komputerowych. Mogą wystąpić kłopoty ze skalowalnością i efektywnością, gdy wybierzemy model cienkiego klienta, albo trudności z pielęgnacją, gdy zdecydujemy się na grubego klienta. Aby uniknąć tych kłopotów, można zastosować architekturę 3. Termin „aplet” jest zapożyczonym z języka angielskiego określeniem na skompilowany program , który może być uruchomiony w środowisku systemowym przeglądarki internetowej. Termin ten nie ma odpowiednika na gruncie polskojęzycznej terminologii informatycznej. 4 Warto zauważyć, że przeglądarki różnych producentów, a nawet różne wersje tej samej przeglądarki nie zawsze jednak wyświetlają te same strony w ten sam sposób. Technologie internetowe rozwijają się bardzo dynamicznie i może się zdarzyć, że na starszych komputerach użytkownik nie będzie miał możliwości uruchamiania programów w Javie. Powinno się zatem używać tego podejścia jedynie wówczas, gdy wiadomo, że tego typu problemy na pewno nie będą miały miejsca. Jest to sytuacja przejściowa i wszystko wskazuje, że postęp technologii XML w najbliższej przyszłości usunie wszelkie problemy tego rodzaju..

(21) Paweł Lula, Tadeusz Wilusz. 68. trójwarstwową (rys. 7). W tej architekturze prezentacja, przetwarzanie użytkowe i zarządzanie danymi są logicznie oddzielonymi procesami5. Internetowy system bankowy jest przykładem systemu, który można zaimplementować za pomocą architektury trójwarstwowej klient–serwer. Bankowa baza danych o klientach oferuje usługi zarządzania danymi. Serwer www zapewnia usługi użytkowe, takie jak udogodnienia do przelewania pieniędzy, generowania wyciągów, płacenia rachunków itd. Komputer użytkownika z przeglądarką sieci odgrywa rolę klienta. W efekcie dostajemy system pokazany na rys. 8..

(22) .

(23) .

(24) .

(25) .

(26) . !

(27) .

(28) .

(29). . Rys. 8. Architektura rozproszenia systemu bankowego w Internecie (portal www) Źródło: [Sommerville 2003].. Architektura trójwarstwowa w tym rozwiązaniu przede wszystkim umożliwia optymalizację przekazywania informacji między serwerem www a serwerem bazy danych. W szczególności komunikacja między tymi systemami nie musi być zgodna ze standardowymi protokołami Internetu, ale może bazować na szybszych protokołach komunikacyjnych niższego poziomu. Do wyszukiwania informacji w bazie danych korzystać można z efektywnych programów warstwy pośredniczącej (middleware), które umożliwiają zadawanie bazie danych pytań w języku SQL6. W niektórych przypadkach należy rozszerzyć model trójwarstwowy klient–serwer do wariantu wielowarstwowego, w którym system jest wzbogacany o dodatkowe serwery. Systemy wielowarstwowe mogą być zastosowane tam, gdzie programy 5 Architektura trójwarstwowa klient–serwer niekoniecznie oznacza, że są potrzebne trzy systemy komputerowe włączone do sieci. Jeden komputer serwera może obsługiwać zarówno przetwarzanie użytkowe, jak i zarządzanie danymi programu użytkowego jako dwa oddzielne logicznie serwery. Gdy jednak oczekiwania wzrosną, można będzie dość łatwo wyodrębnić przetwarzanie użytkowe i zarządzanie danymi, po czym uruchamiać je na oddzielnych procesorach. 6 SQL – (Structured Query Language) – strukturalny język zapytań..

(30) Architektury systemów rozproszonego…. 69. użytkowe muszą odczytywać i wykorzystywać dane z różnych baz danych. Serwer integracji zbiera rozproszone dane i przedstawia je programom użytkowym tak, jakby były wzięte z jednej bazy danych. Tabela 3. Typowe zastosowania różnych architektur klient–serwer Dwuwarstwowa architektura Systemy odziedziczone (legacy), gdzie oddzielenie przetwarzaz cienkim klientem nia i zarządzania danymi jest niepraktyczne. Aplikacje zorientowane na obliczenia, np. kompilatory, gdzie nie występuje lub jest bardzo mała interakcja z bazą danych. Aplikacje zorientowane na dane (przeglądanie i zadawanie pytań), gdzie nie występuje lub jest bardzo małe przetwarzanie. Dwuwarstwowa architektura Aplikacje, w których przetwarzanie jest zapewnione przez z grubym klientem wyspecjalizowane oprogramowanie klienta, np. MS Excel. Aplikacje ze złożonym przetwarzaniem (np. wizualizacją danych, przetwarzaniem multimediów). Aplikacje ze stabilną funkcjonalnością dla użytkownika, użyte w środowisku z dobrze określonym zarządzaniem. Trzywarstwowa lub wielowarstwowa architektura. Aplikacje o dużej skali z setkami lub tysiącami klientów. Aplikacje gdzie zarówno dane jak i aplikacje są ulotne (zmienne). Aplikacje integrujące dane z wielu rozproszonych źródeł.. Źródło: opracowanie własne na podstawie [Sommerville 2003].. Architektury trójwarstwowe klient–serwer i ich warianty wielowarstwowe, które rozdzielają przetwarzanie użytkowe między kilka serwerów, są ze swej natury bardziej skalowalne niż architektury dwuwarstwowe. Projektując systemy w architekturze klient–serwer należy sobie zdawać sprawę z tego, że wybór najbardziej odpowiedniej architektury jest wyborem wielokryterialnym. Sytuacje przedstawione w tym punkcie zostały krótko streszczone w tabeli 3. 5. Architektury obiektów rozproszonych W architekturze klient–serwer istnieje wyraźna asymetria pomiędzy klientem i serwerem; w szczególności, nie występuje tam komunikacja bezpośrednio pomiędzy klientami. Model taki dla wielu zastosowań jest mało elastyczny i zapewnia zbyt małą skalowalność. Architektura obiektów rozproszonych znosi podział na klientów i serwery. Brak podziału na klientów i serwery okazuje się być podejściem bardziej ogólnym do projektowania systemów rozproszonych. W tej architekturze (rys. 9) zasadniczymi komponentami systemu są obiekty oferujące interfejs do zbioru wykonywanych przez siebie usług. Inne obiekty mogą.

(31) Paweł Lula, Tadeusz Wilusz. 70. korzystać z tych usług bez logicznego podziału na klientów (odbiorców usług) i serwery (dostawców usług).. ol. oi. on. U(ol). U(oi). U(on). .... .. .... . szyna programowa. Rys. 9. Architektura obiektów rozproszonych oi – i-ty obiekt, U(oi) – usługa. świadczona przez i-ty obiekt Źródło: [Sommerville 2003].. Obiekty mogą być umieszczone na kilku komputerach w sieci; porozumiewają się wówczas za pośrednictwem warstwy programów pośredniczących7 (middleware). Taką warstwę oprogramowania pośredniczącego można traktować w kategoriach szyny programowej pełniącej funkcję pośrednika pomiędzy rozproszonymi obiektami składowymi systemu. Oferuje ona zbiór usług, które umożliwiają porozumiewanie się obiektów oraz dodawanie i usuwanie obiektów z systemu. Stąd też rozwiązanie o takiej architekturze nazwano pośrednikiem zleceń obiektowych. Jego rolą jest zapewnienie ciągłego interfejsu między obiektami. Do niewątpliwych zalet architektury obiektów rozproszonych można zaliczyć: – umożliwienie projektantowi odłożenie w czasie decyzji, gdzie i jak oferować usługi. Obiekty wykonujące usługi mogą działać w dowolnym węźle sieci. Rozróżnienie między modelami grubego i cienkiego klienta staje się więc bezprzedmiotowe i nie ma konieczności określania z góry, gdzie umiejscowić obiekty logiki użytkowej; – jest architekturą otwartych systemów, która umożliwia dodawanie nowych zasobów w miarę potrzeby; – system o tej architekturze jest elastyczny i skalowalny. Do obsługi rozmaitych obciążeń można utworzyć różne egzemplarze systemu z tym samym zbiorem usług oferowanych przez odrębne lub powielone obiekty. Gdy obciążenie systemu. 7. W literaturze polskojęzycznej termin middleware jest niekiedy tłumaczony jako „śródprogramy”..

(32) Architektury systemów rozproszonego…. 71. rośnie, można dodać nowe obiekty bez przerywania pracy innych obiektów systemowych; – w miarę potrzeby można dynamicznie zmienić konfigurację systemu przez migrację obiektów w sieci. Może to być niezbędne tam, gdzie liczbę żądań usług zmienia się rytmicznie zgodnie z pewnym wzorcem. Obiekty wykonujące usługi mogą przemieścić się na ten sam procesor, na którym działają obiekty żądające usług. Pozwala to poprawić efektywność systemu. W fazie projektowaniu systemów architektura obiektów rozproszonych może być wykorzystana na dwa sposoby: – jako model logiczny, który pomaga w ustaleniu struktury i organizacji systemu – w tym przypadku należy wyrazić funkcjonalność użytkową jedynie w kategoriach usług i ich kombinacji. Na tej podstawie należy następnie wypracować sposób oferowania tych usług przez kilka obiektów rozproszonych. Na tym poziomie abstrakcji zaprojektowane obiekty są gruboziarniste i wykonują usługi charakterystyczne dla określonej dziedziny. Przykładowo, w programie użytkowym do obsługi sprzedaży detalicznej mogą pojawić się obiekty do zarządzania magazynem, kontaktami z klientem, zamawianiem dóbr itd. Taki model logiczny może być później łatwo zrealizowany jako model implementacyjny;. . . . . .

(33) . Rys. 10. Architektura rozproszonego systemu eksploracji danych Źródło: opracowanie własne na podstawie [Sommerville 2003]..

(34) 72. Paweł Lula, Tadeusz Wilusz. – jako elastyczne podejście do implementacji systemów klient–serwer. W tym wypadku model logiczny systemu odpowiada architekturze klient–serwer, ale zarówno klienci, jak i serwery mają postać obiektów rozproszonych porozumiewających się za pośrednictwem szyny programowej. Umożliwia to łatwą zmianę systemu na przykład z dwuwarstwowego na wielowarstwowy. W tym wypadku klient lub serwer może być zaimplementowany nie jako jeden obiekt rozproszony, ale jako kilka mniejszych obiektów, z których każdy oferuje wyspecjalizowane usługi. Przykładem systemu, w którym architektura obiektów rozproszonych świetnie się sprawdza jest system eksploracji danych (Data Mining), który służy do wyszukiwania związków między danymi przechowywanymi w wielu różnych bazach danych (rys. 10). W tym przykładzie każda baza danych może być zamknięta wewnątrz obiektu rozproszonego z interfejsem do odczytu jej danych. Obiekty „integratory” odpowiadają za wykrywanie specyficznych związków pomiędzy danymi zawartymi we wszystkich bazach danych zasilających system. Z kolei obiekty „prezenter” porozumiewają się z integratorami i tworzą prezentacje albo raporty o wykrytych związkach. W takich rodzajach zastosowań architektura obiektów rozproszonych jest bardziej odpowiednia niż architektura klient–serwer z następujących powodów: – inaczej niż w wypadku np. systemów bankomatów, model logiczny systemu nie polega na zapewnieniu usługi i zarządzanie danymi nie jest w nim wydzielone; – taka architektura umożliwia zwiększenie liczby wykorzystywanych baz danych bez przerywania pracy systemu. Każda baza danych to po prostu kolejny obiekt rozproszony. Obiekty bazy danych mogą oferować uproszczony interfejs, który umożliwia kontrolę dostępu do danych. Bazy danych mogą znajdować się na różnych maszynach; – taka architektura umożliwia eksplorację nowych rodzajów związków przez dodanie nowych obiektów typu „integrator”. Co więcej, jeżeli różne oddziały firmy są zainteresowane różnymi związkami, to każdy z nich może rozszerzyć system przez dodanie nowych, swoich obiektów integratorów, które będą działały na ich komputerach. Taka zmiana nie wymaga wiedzy o integratorach używanych w innych miejscach. 6. CORBA Z rozważań przedstawionych w poprzednim punkcie wynika niezbicie, że implementacja architektury obiektów rozproszonych wymaga warstwy oprogramowania pośredniczącego (pośredników zleceń obiektowych) do obsługi komunikacji między obiektami rozproszonymi. Dzięki istnieniu takiej warstwy obiekty.

(35) Architektury systemów rozproszonego…. 73. systemu mogą być zrealizowane w różnych językach programowania, działać na różnych platformach, a ich nazwy nie muszą być znane wszystkim innym obiektom w systemie. W tym miejscu warto zauważyć, że programy warstw pośredniczących zaliczają się do oprogramowania ogólnego przeznaczenia, które raczej się kupuje niż specjalnie pisze. W charakterze przykładu może nam posłużyć oprogramowanie do obsługi komunikacji z bazą danych, monitory transakcyjne itp. Systemy rozproszone zwykle projektuje się używając metodologii projektowania obiektowo zorientowanego. Takie systemy składają się z luźno zintegrowanych niezależnych części, z których każda może bezpośrednio komunikować się z użytkownikami lub z innymi częściami systemu. Części systemu muszą często reagować na niezależne zdarzenia. Obiekty programowe odzwierciedlające te cechy, są więc naturalnymi abstrakcjami komponentów systemów rozproszonych. W chwili obecnej na rynku dostępne są cztery standardy oprogramowania middleware wspomagające projektowanie i budowę systemów rozproszonego przetwarzania danych. Są to: – CORBA (Common Object Request Broker Architecture) – jest zbiorem standardów zdefiniowanym przez OMG (Object Management Group). OMG jest konsorcjum firm8, do którego należą główni producenci, (na przykład Sun, Hewlett-Packard i IBM). Standardy CORBA definiują ogólne niezależne od maszyny podejście do rozproszonych obliczeń obiektowych; – DCOM (Distributed Component Object Model) – jest to standard firmy Microsoft zintegrowany z jej systemami operacyjnymi. Model rozproszonych obliczeń w DCOM jest mniej ogólny niż CORBA; – RMI (Remote Method Invocation) – oprogramowanie firmy Sun, dedykowane opracowywaniu systemów rozproszonego przetwarzania danych w środowisku Javy. Podobnie jak DCOM charakteryzują go pewne ograniczone w stosunku do standardu CORBA; – XML – standard zaproponowany dla Internetu przez www Consortium. Jest to najmłodszy z wymienionych standardów i nadal w fazie intensywnego rozwoju. Pozwala na semantyczną kwalifikację danych przechowywanych na serwerach www. Jego głównym przeznaczeniem jest automatyzacja procesu wymiany informacji w sieci Internet. Na obecnym etapie technologie związane z XML są również mniej elastyczne i ograniczone w stosunku do standardu CORBA. Wszystkie z wymienionych standardów w interesującym nas aspekcie koncentrują się na tym samym. Z danych literaturowych wykorzystanych w powyższej, 8. OMG powstała w 1989 r. Jej celem jest promowanie teorii oraz praktyki technologii obiektowych. Założycielami OMG było 13 liczących się przedsiębiorstw z branży software’owej. Obecnie do organizacji należy ponad 750 firm – producentów oprogramowania oraz sprzętu komputerowego. Organizacja zajmuje się opracowywaniem standardów pomagających w tworzeniu aplikacji obiektowych..

(36) Paweł Lula, Tadeusz Wilusz. 74. skrótowej charakterystyce dostępnych standardów wynika, że wśród nich CORBA oferuje najbardziej ogólny model budowy systemów rozproszonych i dlatego na jej przykładzie będzie opierać się dalsza charakterystyka zasad tworzenia systemów rozproszonych na bazie dostępnego na rynku oprogramowania. Na rys. 11 pokazano wizję rozproszonych aplikacji opracowaną w OMG jako element koncepcji OMA (Object Management Architekture – architektura zarządzania obiektami) (por. [Siegiel 1998])..

(37) !#

(38).

(39)

(40)

(41).

(42)

(43) .

(44)

(45)

(46)

(47) . "!. Rys. 11. Struktura rozproszonej aplikacji w standardzie CORBA Źródło: opracowanie własne na podstawie [Sommerville 2003].. Jak wynika z rys. 11 koncepcja ta zakłada, że w strukturze każdej rozproszonej aplikacji powinno się uwzględniać minimum następujące komponenty: – obiekty użytkowe zaprojektowane i zaimplementowane dla określonej aplikacji, – obiekty standardowe zdefiniowane przez OMG na użytek określonej dziedziny zastosowań9, – główne usługi CORBA związane z podstawowymi aspektami obliczeń rozproszonych, takie jak katalogi, zarządzanie zabezpieczeniami itd., – poziome udogodnienia CORBA (usługi), takie jak ułatwienia interfejsu użytkownika, zarządzanie systemem itd. Nazwa „udogodnienia poziome” świadczy o tym, że są one wspólne dla wielu dziedzin zastosowań; są zatem używane w wielu rozmaitych programach użytkowych.. 9. W tym celu powołano tzw. grupy tematyczne, których zadaniem jest określenie standardów obiektów dziedzinowych w finansach i ubezpieczeniach, handlu elektronicznym, opiece medycznej itd..

(48) Architektury systemów rozproszonego…. 75. Standardy CORBA realizują wszystkie aspekty tej wizji na podstawie czterech podstawowych elementów: – model obiektów użytkowych, w którym obiekty CORBA mają dobrze określony i niezależny od języka interfejs opisany w IDL (Interface Definition Language – język opisu interfejsów): – pośrednika zleceń obiektowych (Object Request Broker, ORB), który obsługuje żądania obiektów. ORB znajduje obiekt oferujący usługę, przygotowuje go na to żądanie, wysyła je do niego i przekazuje wynik żądającemu; – zbiór ogólnych usług obiektowych (najważniejsze przykłady to usługi katalogowe i transakcyjne); – zbiór wspólnych komponentów zbudowanych na bazie usług podstawowych. Mogą to być komponenty charakterystyczne dla konkretnej dziedziny (tzw. komponenty pionowe) albo komponenty ogólnego przeznaczenia dla wielu programów użytkowych. Interfejsy obiektów CORBA ustala się za pomocą standardowego, niezależnego od języka programowania języka opisu interfejsów (IDL). Gdy obiekt pragnie skorzystać z usług innego obiektu, dostaje się do nich przez interfejs IDL. Każdy obiekty CORBA mają unikatowe identyfikatory zwane IOR (Interoperable Object Reference) używane, gdy jeden z obiektów żąda usług innego. Pośrednik zleceń obiektowych zna obiekty żądające usług i ich interfejsy. ORB obsługuje komunikację między obiektami. Porozumiewające się obiekty nie muszą znać położenia innych obiektów ani wiedzieć czegokolwiek o ich implementacji. Interfejs IDL oddziela obiekty od ORB, co pozwala zmieniać zarówno szczegóły implementacyjne każdego z obiektów, jak i jego położenie w sposób niezauważalny dla innych obiektów systemu. Schemat na rys. 12 objaśnia podstawową zasadę komunikacji za pośrednictwem ORB i wyjaśnia istotę interfejsu wyspecyfikowanego w IDL. Obiekt wywołujący ma do dyspozycji namiastkę10 IDL, która zawiera definicję interfejsu obiektu oferującego żądaną usługę. Klient, zgłaszając chęć wykonania operacji na zdalnym obiekcie, wysyła odpowiednie żądanie do namiastki – reprezentanta obiektu CORBY po stronie klienta, a ta następnie angażuje w wykonanie zadania możliwości, jakie daje ORB uruchomiony na lokalnej maszynie. Ten z kolei dostarcza zlecenie obiektowi CORBY reprezentowanej przez tzw. szkielet, który uprzednio lokalizuje. Szkielet po dokonaniu translacji otrzymanego wywołania na rozpoznawany lokalnie format wywołuje odpowiednią metodę z implementacji obiektu. Wartość przez nią zwracana jest przez szkielet transformowana do postaci preferowanej przez klienta i przesyłana mu za pośrednictwem ORB. 10. Angielski termin stub w polskojęzycznej literaturze najczęściej pojawia się jako „namiastka” lub „pniak”..

(49) Paweł Lula, Tadeusz Wilusz. 76. . . . . !" !#! . .

(50) . Rys. 12. Schemat komunikacji obiektów za pośrednictwem ORB Źródło: [Sommerville 2003].. Warto zauważyć, że IDL jest uniwersalnym językiem specyfikacji interfejsu obiektowego zaprojektowanym przez organizację OMG. Język ten zachowuje wszystkie stosowane rozwiązania obiektowe – definiowanie pól atrybutów, metod, dziedziczenie itd. – znane z podstaw teorii programowania obiektowego. Następnie plik zawierający definicje IDL jest rzutowany na język programowania za pomocą odpowiednich kompilatorów zależnych od języka programowania. Aktualnie OMG dostarcza specyfikacje rzutowania na kilka podstawowych języków programowania: Java, C, C++, Ada, Cobol, Lisp, Python, PL/1, Smalltalk, XML. Składnia języka wzorowana jest na języku C++ i OMG deklaruje rozwój IDL wraz z rozbudową standardów języka C++. Pośrednicy zleceń obiektowych zwykle nie są implementowani jako oddzielne procesy, ale stanowią tzw. zręby, które konsoliduje się z implementacjami obiektów. W systemie rozproszonym każdy komputer, na którym działają obiekty rozproszone będzie więc miał własnego pośrednika zleceń obiektowych. Będzie on obsługiwał lokalne wywołanie obiektów tak, jak to opisano wyżej. Gdy pojawi się jednak żądanie usługi oferowanej przez obiekt zdalny, będzie konieczna komunikacja między pośrednikami ORB. Sytuacja taka pokazana jest na rys. 13. Jeśli żądana usługa jest na zdalnym komputerze, wówczas lokalny ORB za pomocą specjalnego protokołu komunikacyjnego IIOP11 (Internet Inter-ORB Protocol) bazującego na standardzie TCP/IP przesyła żądanie do ORB zlokalizowanego na maszynie docelowej. Odpowiedź również wędruje przez sieć. 11. OMG do komunikacji pomiędzy pośrednikami ORB systemów lokalnego i zdalnego specyfikuje protokół GIOP (Generic Inter-ORB Protocol – ogólny protokół komunikacji między ORB) zawierający standardowe komunikaty, które mogą być przesyłane przez pośredników ORB i służą do implementacji zdalnych wywołań obiektów oraz przekazywania informacji. Realizacja GIOP w środowisku sieci TCP/IP daje IIOP..

(51) Architektury systemów rozproszonego…. 77. . . . . ". ". ". ". #$ #%# . ! . #$ #%# .

(52) . ! .

(53) Sieć (protokół IIOP). Rys. 13. Sieciowa komunikacja obiektów rozproszonych Źródło: opracowanie własne.. Częścią standardu CORBY jest definicja całego zbioru usług wspomagających współdziałanie rozproszonych obiektów. Są one znane jako serwisy CORBY, w skrócie COS. W rzeczywistości są to po prostu standardowe obiekty CORBY (określane też jako Object Services) zdefiniowane przy użyciu interfejsów języka IDL jako części składowe serwisu ORB. Najważniejsze z nich zestawiono w tabeli 4. Tabela 4. Lista usług standardu CORBA Usługa. Opis. Object life cycle. definiuje sposób tworzenia, likwidowania, kopiowania i przenoszenia obiektów CORBY. Naming. definiuje zasady nazewnictwa obiektów CORBY. Events. definiuje sposób komunikacji między obiektami CORBY. Relationships. specyfikuje relacje między obiektami CORBY. Externalization. nadzoruje transformację obiektów CORBY w zewnętrznych środowiskach. Transactions. koordynuje dostęp do obiektów CORBY. Concurrency Control. gwarantuje synchronizację współbieżnego dostępu do obiektów CORBY. Property. wspomaga kojarzenie par typu nazwa–wartość z obiektami CORBY. Trader. wspomaga proces wyszukiwania obiektów CORBY na podstawie specyfikacji serwisów przez nie oferowanych. Query. wspomaga zapytania dotyczące obiektów CORBY. Źródło: opracowanie własne na podstawie materiałów dostępnych w Internecie http://www. brunel.ac.uk/~eestpvs/Courses/EE5038S/wrkshp4.pdf, http://courses.dce.harvard.edu/~cscie160/ corbaoverview.ppt.

(54) 78. Paweł Lula, Tadeusz Wilusz. 7. Proces budowy aplikacji rozproszonej w standardzie CORBA Na podstawie przedstawionej idei architektury obiektów rozproszonych można podstawowy schemat projektowania i implementacji obiektowo zorientowanej aplikacji zgodnej ze standardem CORBA przedstawić jako proces składający się z następujących kroków: 1. Definicja zdalnych interfejsów w IDL. 2. Kompilacja zdalnych interfejsów. Specyfikacje interfejsów zapisane w IDL są kompilowane do postaci użytecznej z poziomu wybranego języka programowania aplikacji (np. Javy). Przy okazji kompilator buduje namiastki i szkielety IDL, które pozwolą naszej aplikacji na komunikowanie się poprzez Internet. 3. Implementacja serwera. Kod po stronie serwera musi przede wszystkim zawierać implementacje metod deklarowanych w zdalnym interfejsie. Ponadto musi zawierać również fragment odpowiedzialny za uruchomienie serwisu ORB oraz oczekiwanie na nadesłanie ze strony klienta zlecenia wywołania którejś z usług (metod) interfejsu. Wygenerowane w poprzednim kroku pliki szkieletu łączy się z serwerową cześcią aplikacji. 4. Implementacja klienta. Po stronie klienta aplikacja powinna zawierać namiastki wygenerowane przez kompilator IDL w celu: – uruchomienia ORB, – zlokalizowania serwera za pomocą specjalnego serwisu nazw IDL, – pobrania referencji obiektu CORBY i wywołania jego metod. 5. Uruchomienie aplikacji. Krok ten sprowadza się już tylko do uruchomienia serwisu nazw, wystartowania serwera i uruchomienia programu klienta. 8. Podsumowanie Trwający już ponad 50 lat rozwój informatyki w kierunku pozwalającym w pełni zautomatyzować wszystkie procesy informacyjne pozwolił jej osiągnąć dojrzałą formę technologii znajdującej coraz szersze i coraz łatwiejsze (z uwagi na uniwersalność, a tym samym powszechność występowania) zastosowania. Ponieważ jest to technologia procesów informacyjnych w najszerszym tego słowa znaczeniu, więc rozwój jej zastosowań stwarza coraz silniejszą presję na tempo rozwoju samej technologii. Konkurencja na rynku technologii informatycznych spowodowała, że powiększanie możliwości nowo konstruowanych systemów informatycznych na gruncie technologii półprzewodnikowych zaczęło napotykać bariery fizyczne niemożliwe do przekroczenia. Dlatego w chwili obecnej trwają intensywne prace nad zamianą technologii półprzewodnikowej na inną, a w międzyczasie na znaczeniu istotnie zyskały wszelkie metody zwiększania możliwości.

(55) Architektury systemów rozproszonego…. 79. systemów informatycznych oparte na idei traktowania sieci „słabych” komputera w kategoriach równoległego, wirtualnego superkomputera. Drugi wymiar coraz bardziej konkurencyjnego rynku – walka o klienta – zaowocowała wyścigiem o względy nabywcy – wygodą, łatwością obsługi i dopasowaniem do zindywidualizowanych potrzeb to właśnie świat przedstawionych w artykule systemów obiektów rozproszonych. Chcąc na zakończenie możliwie krótko podsumować aktualny stan w tej dziedzinie, należy stwierdzić: – nieomal wszystkie nowoprojektowane i realizowane wielkie systemy są rozproszone. Ich oprogramowanie systemowe działa na luźno zintegrowanych grupach procesorów; – podstawowe zalety systemów rozproszonych to zdolność do współdzielenia zasobów, otwartość, współbieżność procesów, łatwa skalowalność, przezroczystość i duża odporność na lokalne awarie; – historycznie starsza architektura klient–serwer reprezentuje systemy rozproszone, których modelem jest zbiór usług oferowanych procesom klientów przez specjalizowane procesy usługowe (serwery). W takich systemach interfejs użytkownika działa zwykle u klienta, a zarządzanie danymi jest zawsze wykonywane przez współdzielony serwer. Aplikacja użytkowa może działać zarówno na komputerze klienta, jak i na komputerze realizującym proces serwera; – w architekturze obiektów rozproszonych to bardziej uogólnione podejście do modelowania świata zewnętrznego, w którym nie ma potrzeby rozróżnienia klientów i serwerów. Obiekty oferują ogólne usługi, które mogą być wywoływane przez inne obiekty. To podejście można w oczywisty sposób wykorzystać do implementacji systemów klient–serwer; – systemy obiektów rozproszonych muszą korzystać z warstwy programów pośredniczących do obsługi komunikacji obiektów oraz dodawania i usuwania obiektów z systemu. Na poziomie pojęciowym można postrzegać warstwę programów pośredniczących jako szynę programową, do której podłącza się obiekty; – CORBA jest najbardziej ogólnym zbiorem standardem budowy warstwy programów pośredniczących do obsługi architektur obiektów rozproszonych. Obejmuje definicje modelu obiektowego, pośrednika zleceń obiektowych i wspólnych usług. Jej przewaga np. nad RMI to przede wszystkim brak ograniczenia jeśli idzie o wybór narzędzi do implementacji systemu. Literatura Ben-Ari M. [1982], Principles of Concurrent Programming, Prentice-Hall. Colorouis G., Dollimore J., Kindberg T. [1998], Systemy rozproszone. Podstawy i projektowanie, WNT, Warszawa. Comer D.E. [2000], Sieci komputerowe i intersieci, WNT, Warszawa..

(56) 80. Paweł Lula, Tadeusz Wilusz. Roszczyk R. [1999], Technologia CORBA, „Pckurier” 25. Siegiel J. [1998], OMG Review: CORBA and OMA in Enterprise Computing, Communication of the ACM no. 41 (10). Silberschatz A., Galvin P.B. [2000], Podstawy systemów operacyjnych, WNT, Warszawa. Sommerville I. [2003], Inżynieria oprogramowania, WNT, Warszawa. Stevens W.W. [1990], Programowanie zastosowań sieciowych w systemie Unix, WNT, Warszawa. Vaskevitch D. [1995], Strategie Klient-Server, IDG Poland SA, Warszawa. Tanenbaum A.S. [1998], Sieci komputerowe, WNT, Warszawa. Architectures of Distributed Data Processing Systems The authors, utilising available publications, try to briefly submit a contemporary idea of construction of distributed data processing systems. The main emphasis has been put on the distributed objects architecture (OMG) and on the set of standards CORBA. Observation of development trends of contemporary information technologies delivers no doubt that the solutions presented in the paper can be – with high probability – regarded as an up-coming generation of information systems technologies. Key words: information systems, computer systems, distributed systems, CORBA, ORB, client-server architecture, distributed objects architecture..

(57)