1. Zdefiniować i opisać pojęcie systemów rozproszonych (przezroczystość, otwartość i skalowalność).

Def.

System rozproszony jest to zestaw niezależnych komputerów, sprawiający na jego użytkownikach wrażenie jednego, logicznie zwartego systemu.

Definicja ta ma dwa aspekty:

1. dotyczy sprzętu - maszyny są autonomiczne,

2. odnosi się do oprogramowania - użytkownicy uważają, że mają do czynienia z jednym systemem

Cechy systemów rozproszonych:

• Przezroczystość − pozwala ukryć przed użytkownikami różnice między poszczególnymi komputerami i sposoby ich komunikowania się (jego procesy i zasoby są fizycznie rozproszone na wielu komputerach) - system rozproszony potrafi prezentować się swoim użytkownikom i aplikacjom tak, jakby był był tylko jednym systemem komputerowym.

• przezroczystość dostępu - ukrywanie różnic w reprezentacji danych i sposobie dostępu do zasobu

przykład − aby wysłać liczbę całkowitą ze stacji roboczej z procesorem Intel do maszyny Sun SPARC, musimy wziąć pod uwagę, że przy przesyłaniu Intel porządkuje bajty w formacie najpierw najmłodszy bajt oraz to, że procesor SPARC używa formatu najpierw bit najstarszy

przykład - system rozproszony mógłby mieć systemy komputerowe, pracujące pod nadzorem różnych systemów operacyjnych, z których każdy używa własnej konwencji nazywania plików - różnice w konwencjach nazewniczych oraz w sposobie manipulowania na plikach powinny być ukryte przed użytkownikami i aplikacjami

• przezroczystość położenia - ukrywanie położenia zasobu (jako użytkownik nie jestem w stanie powiedzieć gdzie są zasoby) - oznacza, że użytkownicy nie mogą określić, w którym miejscu systemu zasób jest ulokowany fizycznie - w osiąganiu przezroczystości położenia ważną rolę odgrywa nazewnictwo;

przezroczystość położenia możemy uzyskać, przydzielając zasobom tylko nazwy logiczne, tzn. nazwy, w których położenie zasobu jest zakodowane niejawnie;

przykład - przykładem takiej nazwy jest lokalizator URL http://www.prenhall.com/index.html - który nie podaje żadnych wskazówek co do lokalizacji głównego serwera Sieci wydawnictwa Prentice Hall - lokalizator URL nie zawiera również żadnych przesłanek odnośnie do tego, czy index.html zawsze znajdował się w danym miejscu, czy może ostatnio go tam przeniesiono

• przezroczystość wędrówki - ukrywanie możliwości przeniesienia zasobu w inne miejsce (ukrywanie faktu, ze zasób którego używam był w innym miejscu niż teraz)

zasoby możemy przenosić bez wpływania na sposób kontaktowania się z nimi

• przezroczystość przemieszczania - ukrywanie możliwości zmiany położenia zasobu w trakcie jego używania

przykład - możliwość kontynuowania pracy bez jakichkolwiek (nawet chwilowych) wyłączeń przez ruchomych użytkowników, korzystających z bezprzewodowych laptopów podczas przenoszenia się z miejsca na miejsce

• przezroczystość zwielokrotnienia - ukrywanie faktu zwielokrotnienia zasobu (wielość kopii, które są identyczne) - zasoby możemy zwielokrotniać, żeby zwiększyć dostępność lub poprawić działanie, umieszczając kopie blisko miejsca ich użycia - żeby ukryć zwielokrotnienie przed użytkownikami, jest niezbędne, aby wszystkie kopie (repliki) miały te same nazwy - wobec tego system powinien również z zasady zapewniać też przezroczystość położenia, ponieważ w przeciwnym razie nie można by odwoływać się do kopii w różnych miejscach

• przezroczystość współbieżności - ukrywanie tego, że zasób może być dzielony przez kilku rywalizujących użytkowników (ukrywanie faktu, że wielu użytkowników korzysta z tego samego zasobu)

przykład - dwóch niezależnych użytkowników może przechowywać swoje pliki w tym samym serwerze plików lub sięgać po te same tabele we wspólnej bazie danych - istotne jest, aby żaden użytkownik nie dostrzegł, że drugi używa tego samego zasobu

• przezroczystość awarii - ukrywanie awarii i rekonstrukcji zasobu - oznacza, że użytkownik nie zauważa, że zasób (o którym być może nigdy nie słyszał) odmawia poprawnej pracy or5az że system dokonuje następnie usunięcia skutków uszkodzenia (rekonstrukcji)

główna przeszkoda w maskowaniu awarii leży w niezdolności rozróżnienia między zasobem nieoperatywnym a skrajnie powolnym

przykład - przy kontaktowaniu się z zajętym serwerem Sieci przeglądarka może odliczyć zakładany czas oczekiwania i zgłosić, że strona WWW jest niedostępna - w tej sytuacji użytkownik nie może stwierdzić, czy serwer rzeczywiście jest nieczynny

• przezroczystość trwałości - ukrywanie tego, czy zasób (programowy) jest w pamięci operacyjnej, czy też na dysku

przykład - wiele obiektowych baz danych umożliwia bezpośrednie wywoływanie metod na przechowanych obiektach - poza sceną serwer bazy danych kopiuje najpierw stan obiektu z dysku do pamięci głównej, wykonuje operację i (być może) zapisuje stan z powrotem w pamięci pomocniczej - użytkownik jest nieświadom przemieszczania przez serwer stanu między pamięcią podstawową a pomocniczą

• Otwartość - system nazywa się otwartym kiedy protokoły są standaryzowane

Otwarty system rozproszony oferuje usługi zgodnie ze standaryzowanymi regułami, opisującymi ich składnię i semantykę [Semantyka (gr. σημαντικός, semantikós, istotne znaczenie, od sema, znak) to dyscyplina badająca relacje pomiędzy znakami a przedmiotami, do których się one odnoszą. Semantyka zajmuje się badaniem znaczenia słów, czyli interpretacją znaków oraz interpretacją zdań i wyrażeń języka.].

przykład - w sieciach komputerowych reguły standardowe rządzą formatem, treścią i znaczeniem wysyłanych i odbieranych komunikatów - reguły takie są sformalizowane w protokołach - w systemach rozproszonych usługi są na ogół określane za pośrednictwem interfejsów, które często wyraża się w języku opisu interfejsu (ang. Interface Definition Language - IDL)

Definicje interfejsów, zapisane w języku IDL, prawie zawsze dotyczą tylko składni usług - mówiąc inaczej - określają one dokładnie nazwy dostępnych funkcji wraz z typami ich parametrów, wartości powrotnych, możliwych do zgłoszenia wyjątków itd.

Trudną częścią jest precyzyjne określenie, na czym mają polegać te usługi, czyli semantyka interfejsów.

W praktyce specyfikacje te podaje się po prostu nieformalnie, za pomocą środków dostępnych w języku naturalnym.

Poprawnie sformułowana definicja interfejsu umożliwia dowolnemu procesowi wymagającemu pewnego interfejsu porozumiewanie się z innym procesem, udostępniającym ten interfejs. Umożliwia ona również opracowanie przez dwóch niezależnych wykonawców zupełnie różnych implementacji tych interfejsów, co prowadzi do dwóch odrębnych, identycznie działających systemów rozproszonych. Właściwe specyfikacje są zupełne (kompletne) i neutralne. Zupełność oznacza, że wszystko, co jest niezbędne do budowy, zostało rzeczywiście określone. Liczne definicje interfejsu w ogóle nie sa zupełne, toteż twórca jest zmuszony dodawać szczegóły dotyczące implementacji. Równie ważne jest, aby specyfikacje nie narzucały niczego w kwestii wykonania - powinny być neutralne. Kompletność i neutralność są istotne ze względu na zdolność do współdziałania i przenośność.

Zdolność do współdziałania (ang. interoperability) charakteryzuje stopień, w jakim dwie implementacje systemów lub komponenty pochodzące do różnych wytwórców potrafią współistnieć i współpracować, opierając się na wzajemnych usługach, określonych wspólnym standardem.

Przenośność (ang. portability) charakteryzuje stopień, do jakiego z aplikacji opracowanej dla systemu rozproszonego A można skorzystać bez zmian w systemie rozproszonym B, który realizuje te same interfejsy co A.

Kolejnym ważnym celem systemu rozproszonego jest elastyczność systemu - co oznacza, że powinien on być łatwy do skonfigurowania z różnych składowych, być może pochodzących od różnych producentów. Dodawanie nowych komponentów, lub ich wymiana, również powinno przebiegać łatwo i bez naruszania istniejących składowych. Innymi słowy, otwarty system rozproszony powinien być też rozszerzalny. W systemie elastycznym powinno być dość łatwo dodawać części, które działają pod różnymi systemami operacyjnymi, lub nawet wymienić cały system plików (wielu wie z codziennej praktyki, że o osiąganiu elastyczności łatwiej mówić, niż tego dokonać).

• Skalowalność - w jaki sposób zmieni się efektywność po jego rozszerzeniu (czy nie ma wąskich gardeł) [bottleneck]

Skalowalność systemu możemy mierzyć w co najmniej trzech różnych wymiarach:

• system możemy skalować pod względem jego rozmiaru - przez co należy rozumieć, że możemy łatwo dodawać do niego więcej użytkowników i zasobów

• system skalowalny geograficznie to system, w którym, użytkownicy i zasoby mogą znajdować się daleko od siebie

• system może być skalowalny pod względem administracyjnym - co oznacza, że zarządzanie nim pozostaje łatwe, chociaż rozciąga się on na wiele niezależnych jednostek administracyjnych

Niestety, system skalowalny w jednym z tych wymiarów często traci na efektywności w miarę wzrastania jego skali.

Problemy skalowalności:

• pod względem jego rozmiaru - jeśli zachodzi konieczność zwiększenia liczby użytkowników lub zasobów, to często zaczynami mieć do czynienia z ograniczeniami scentralizowanych usług, danych i algorytmów

Pomysł	Przykład
Usługi scentralizowane	Jeden serwer dla wszystkich użytkowników
Dane scentralizowane	Jedna, bezpośrednio dostępna książka telefoniczna
Algorytmy scentralizowane	Wyznaczanie trasy na podstawie pełnej informacji

usługi - przy wzroście liczby użytkowników serwer może stać się wąskim gardłem

dane - rozporządzanie jedną bazą danych spowodowałoby przeładowanie wszystkich dochodzących do bazy i wychodzących z niej linii komunikacyjnych

algorytmy - „o godzinie 12:00 wszystkie maszyny powinny zanotować rozmiary swych kolejek wyjściowych”

• geograficzna - systemy rozproszone zaprojektowane dla sieci lokalnych oparte są na komunikacji synchronicznej - w tej postaci komunikacji strona zamawiająca usługę, ogólnie nazywana klientem, blokuje się aż do otrzymania odpowiedzi - ta metoda (dobrze sprawdzająca się w sieciach lokalnych) w sieciach rozległych wydłuża komunikację z kilkuset mikrosekund do setek milisekund

kolejnym problemem utrudniającym skalowalność geograficzną jest to - że komunikacja w sieciach rozległych jest z natury zawodna i w praktyce zawsze odbywa się od punktu do punktu (w przeciwieństwie do sieci lokalnych, które z reguły zapewniają niezawodne środki komunikacji - oparte na rozgłaszaniu, co znacznie ułatwia budowanie systemów rozproszonych)

• pod względem administracyjnym - trudnym problemem jest kwestia skalowania systemu rozproszonego na wiele niezależnych domen administracyjnych - podstawowym problemem są sprzeczności w zasadach użytkowania zasobów (i wnoszenia opłat), zarządzania i bezpieczeństwa

2. Zdefiniować i omówić pojecie warstwy pośredniej. Podać przykłady oprogramowania warstwy pośredniej.

Warstwa pośrednia - warstwa oprogramowania , umieszczona logicznie między warstwą wyższą, złożoną z użytkowników i aplikacji, a warstwą położoną pod spodem, złożoną z systemów operacyjnych.

Aby umożliwić użycie różnych komputerów i sieci przy jednoczesnym sprawianiu wrażenia jednego systemu, systemy rozproszone często są organizowane za pomocą właśnie tej warstwy oprogramowania. Taki system często nazywany jest oprogramowaniem warstwy pośredniej.

Oprogramowanie warstwy pośredniej [ang. middleware]





Rys. 2.1. System rozproszony zorganizowany jako warstwa pośrednia oprogramowania. Warstwa pośrednia rozciąga się ponad wieloma maszynami (skrót SO [ang. OS] oznacza system operacyjny)

Przykład:

• Rozważamy sieć stacji roboczych w jednostce organizacyjnej jakiegoś uniwersytetu lub przedsiębiorstwa. Osobiste stacje robocze poszczególnych użytkowników mogą być uzupełnione pulą procesorów w Sali maszyn, mnie należących do żadnego z użytkowników, lecz przydzielanych im dynamicznie, stosownie do potrzeb. System taki mógłby mieć jeden system plików, dostępny na wszystkich maszynach w ten sam sposób, za pomocą jednakowych nazw. Ponadto, gdy użytkownik wprowadzi polecenie, system mógłby poszukać najlepszego miejsca do jego wykonania - być morze na komputerze użytkownika, lecz niewykluczone, że na stacji roboczej należącej do kogoś innego lub na jednym z nieprzydzielonych procesorów w Sali maszyn. Jeśli tego rodzaju system, rozpatrywany w całości, wygląda i działa jak klasyczny system jednoprocesorowy z podziałem czasu (tj. system z wieloma użytkownikami), to można go nazwać systemem rozproszonym.

• Rozważamy system roboczego przepływu informacji, który realizuje automatyczne przetwarzanie zamówień. Taki system jest zazwyczaj użytkowany przez osoby z kilku działów, być może zlokalizowanych w różnych miejscach

3. Scharakteryzować trzypiętrową architekturę klient-serwer. Podać jej przykłady.

Architektura (fizycznie) trzypiętrowa - [ ang. (physically) three-tiered architecture ]

Serwer musi niekiedy zachowywać się jak klient.





Rys. 3.1. Przykład serwera zachowującego się jak klient.

W tej architekturze programy tworzące część poziomu przetwarzania rezydują w osobnym serwerze, lecz mogą być ponadto w pewnym stopniu rozproszone miedzy maszyny klienta i serwera.

Typowym przykładem zastosowania architektury trzypiętrowej jest przetwarzanie transakcji. W tym wypadku osobny proces (zwany monitorem transakcji) koordynuje wszystkie transakcje na (być może) różnych serwerach danych.

4. Co to są namiastki klienta i serwera - do czego służą.

Zdalne wywołanie procedury powinno być z założenia jak najbardziej podobne do wywołania lokalnego. Innymi słowy, chcemy, aby RPC było przezroczyste - wywołujący procedurę nie powinien być świadomy, że procedura wywołana wykonuje się na innej maszynie − i na odwrót. Przyjmijmy, że program ma czytać dane z pliku. Programista umieszcza w kodzie wywołanie read, aby otrzymać dane. W tradycyjnym (jednoprocesorowym) systemie podprogram read zostaje wydobyty z biblioteki przez konsolidator i wstawiony do programu wynikowego. Jest to krótka procedura, zwykle zrealizowana za pomocą odpowiedniego wywołania systemowego read. Mówiąc inaczej procedura read. jest rodzajem interfejsu między kodem użytkownika a lokalnym systemem operacyjnym.

Chociaż w treści read następuje wywołanie systemowe, procedura jest wywoływana przez umieszczenie parametrów na stosie (rys. 4.1. b)).Programista nie wie zatem, że procedura read w rzeczywistości robi coś skrycie.

Przezroczystość RPC osiągamy w podobny sposób, Jeśli read jest w rzeczywistości procedurą zdalną (tzn. taką, która będzie wykonywana na maszynie serwera plików), to w bibliotece umieszczamy inną wersję procedury read, zwaną namiastką klienta (ang. client stub). Jej wywołanie, tak jak w przypadku procedury oryginalnej, odbywa się według schematu (rys. 4.1. b)).





Rys. 4.1. Przekazywanie parametrów w lokalnym wywołaniu procedury: a) stos przed wywołaniem funkcji read; b) stos w czasie wykonywania wywołanej procedury

Podobnie jak procedura oryginalna, wywołuje ona system operacyjny. W odróżnieniu natomiast od procedury oryginalnej nie prosi ona systemu operacyjnego o dostarczenie danych. Zamiast tego pakuje parametry do komunikatu i zamawia jego wysłanie do serwera (rys. 4.2.). Po wykonaniu operacji send namiastka klienta wywołuje operację receive i blokuje się w oczekiwaniu na odpowiedź.





Rys. 4.2. Zasada działania RPC - między programem klienta a programem serwera

Kiedy komunikat dochodzi do serwera, wtedy system operacyjny serwera przekazuje go do namiastki serwera (ang. server stub). Zazwyczaj namiastka serwera znajduje się w stanie oczekiwania na nadejście komunikatu wskutek uprzedniego wykonania operacji receive. Namiastka serwera rozpakowuje parametry z komunikatu i wywołuje procedurę serwera w zwykły sposób (jak na rys. 4.1.). Z punktu widzenia serwera zachodzi to tak, jakby klient wywołał ją bezpośrednio - parametry i adres powrotu znajdują się w odpowiednim miejscu na stosie, wszystko wygląda zwyczajnie. Serwer wykonuje swoje zadanie, po czym zwraca wynik do wywołującej go procedury w normalny sposób. Na przykład w wypadku procedury read serwer zapełni danymi bufor wskazany przez jej drugi parametr. Bufor ten będzie się znajdował wewnątrz namiastki serwera.

Gdy namiastka serwera otrzyma powrotem sterowanie po wykonaniu procedury, zapakuje wynik (bufor) do komunikatu i wykona operację send, aby zwrócić go klientowi. Następnie przejdzie z powrotem do początku własnej pętli, aby wykonać operację receive i oczekiwać na następne zamówienie.

Po powrocie komunikatu do maszyny klienta system operacyjny klienta poznaje, że jest on zaadresowany do procesu klienta (w istocie do jego namiastki, ale system operacyjny nie może tego rozróżnić). Komunikat przekopiowuje się do czekającego na to bufora i proces klienta zostaje odblokowany. Namiastka klienta bada komunikat, rozpakowuje wyniki, kopiuje je do procedury wywołującej i kończy działanie w zwykły sposób. Gdy procedura wywołująca przejdzie do wykonania następnej instrukcji po wywołaniu read, jedynym widocznym dla niej skutkiem będą udostępnione dane. W żaden sposób nie rozróżni ona, że praca została wykonana zdalnie, a nie przez lokalny system operacyjny.

Na przedstawionym poziomie rozważań usługi zdalne polegają na wykonywaniu zwykłych (tj. lokalnych) wywołań procedur, bez wywoływania operacji send i receive. Wszystkie szczegóły przekazywania komunikatów są ukryte w procedurach bibliotecznych, tak samo jak tradycyjne biblioteki skrywają detale wykonywania wywołań systemowych.

Podsumowanie

Zdalne wywołanie procedury odbywa się w następujących krokach:

1. Procedura klienta wywołuje namiastkę klienta w zwykły sposób.

2. Namiastka klienta buduje komunikat i wywołuje lokalny system operacyjny (SO).

3. SO klienta posyła komunikat do zdalnego SO.

4. Zdalny SO przekazuje komunikat namiastce serwera.

5. Namiastka serwera rozpakowuje parametry i wywołuje serwer.

6. Serwer wykonuje zadanie i zwraca wynik namiastce.

7. Namiastka serwera pakuje wynik do komunikatu i wzywa swój lokalny SO.

8. SO serwera wysyła komunikat do SO klienta.

9. SO klienta przekazuje komunikat namiastce klienta.

10. Namiastka rozpakowuje wynik i zwraca go klientowi.

Zysk netto wszystkich tych kroków ma polegać na takiej zamianie lokalnego wywołania namiastki klienta - wykonywanego przez procedurę klienta - na lokalne wywołanie procedury serwera, żeby ani klient, ani serwer nie uświadamiali sobie kroków pośrednich.

5. Opisać wywołanie RPC - synchroniczne, asynchroniczne, asynchroniczne odroczone i jednokierunkowe.

Synchroniczne wywołanie RPC

Po wywołaniu zdalnej procedury klient blokuje się aż do zwrócenia odpowiedzi (Rys. 5.1. a)).

Kroki:

1. Klient pyta serwer (zdalna procedura)

2. Serwer przygotowuje wynik - klient czeka

3. Serwer odpowiada, klient przyjmuje odpowiedź

4. Klient kontynuuje działanie

(na przykład zmiana hasła w systemie)

Asynchroniczne wywołanie RPC - dzięki niemu klient kontynuuje działanie natychmiast po wydaniu zamówienia RPC.

Serwer wysyła odpowiedź do klienta, gdy tylko otrzyma zamówienie RPC, a dopiero potem wywołuje zamówiona procedurę. Odpowiedź ta działa jak potwierdzenie dla klienta, że serwer zamierza przetworzyć RPC. Klient podejmuje pracę bez dalszego blokowania, zaraz po otrzymaniu potwierdzenia od serwera.





Rys. 5.1. Interakcja między klientem a serwerem a) w tradycyjnym wywołaniu RPC; b) przy użyciu asynchronicznego RPC

Asynchroniczne wywołania RPC mogą się też przydać wtedy, kiedy odpowiedź będzie udzielana, lecz klient nie jest gotów na nią czekać, nic nie robiąc w tym czasie.

Odroczone synchroniczne RPC - połączenie dwu asynchronicznych wywołań RPC

Klient najpierw wywołuje serwer, aby wręczyć mu spis nazw komputerów do odszukania, i po potwierdzeniu przez serwer otrzymania tego spisu - działa dalej. Drugie wywołanie jest wykonywane przez serwer, który wywołuje klienta, aby przekazać mu znalezione adresy.





Rys. 5.2. Klient i serwer współpracujący za pośrednictwem dwóch asynchronicznych wywołań

Jednokierunkowe wywołania RPC

Klient kontynuuje działania natychmiast po wysłaniu zamówienia do serwera. Inaczej mówiąc, klient nie czeka na potwierdzenie przyjęcia zamówienia przez usługodawcę. Problemem w tym rozwiązaniu jest niepewność klienta co do przetworzenia jego zamówienia w wypadku niegwarantowania niezawodności.

6. Zdefiniować pojęcie wątku - jakie są jego wady i zalety.

Wątek jest bardzo podobny do procesu w tym sensie, że również może być rozpatrywany jako wykonanie (części) programu na procesorze wirtualnym. W przeciwieństwie do procesów nie podejmuje się tu starań o osiągnięcie wysokiego stopnia przezroczystej współbieżności, gdyby miało to pogorszyć efektywność. Dlatego system wątków z reguły utrzymuje tylko minimum informacji, które umożliwia dzielenie jednostki centralnej przez kilka wątków. W szczególności na kontekst wątku składa się zazwyczaj niewiele więcej niż kontekst jednostki centralnej wraz z pewnymi innymi informacjami do zarządzania wątkami. System wątków może utrzymywać informację o tym, że wątek jest aktualnie zablokowany na zmiennej typu muteks (wzajemnego wykluczania), aby nie wybierać go do wykonania. Informacje, które nie są niezbędnie konieczne do zarządzania wieloma wątkami, na ogół pomijamy. Z tego względu ochrona danych przed niewłaściwym dostępem przez wątki w obrębie jednego procesu spoczywa w całości na twórcach aplikacji.

Z poziomu użytkownika:

• zalety:

• tworzenie i likwidowanie wątków odbywa się tanim kosztem

• możliwość przełączania kontekstu często za pomocą zaledwie kilku rozkazów - w zasadzie należy tylko przechować rejestry jednostki centralnej, po czym umieścić w nich poprzednio przechowane wartości wątku, do którego następuje przełączenie - nie trzeba zmieniać odwzorowań pamięci, wyzbywać się zawartości buforów stron (TBL), dokonywać rozliczeń wykorzystania jednostki centralnej - przełączanie kontekstu wątku jest wykonywane wówczas, gdy dwa wątki wymagają synchronizacji, na przykład przy wchodzeniu do sekcji danych dzielonych

• wady:

• natychmiastowe zablokowanie całego procesu przy blokowanym odwołaniu do systemu przez któryś z jego wątków, co jest równoznaczne z zablokowaniem innych wątków procesu

7. Krótko scharakteryzować wirtualną maszynę Javy - co to jest i do czego służy.

8. Co to są i jak są wykorzystywane aplety i serwlety.

9. Co to jest pośrednik i jakie jest jego zadanie w RMI.

Podczas wiązania klienta z obiektem rozproszonym do przestrzeni adresowej klienta zostaje załadowana implementacja interfejsu obiektu zwana pośrednikiem (ang. proxy).

Pośrednik jest odpowiednikiem namiastki klienta w systemach RPC. Jedyną rzeczą jaką wykonuje, jest przetaczanie wywołań metod do komunikatów i odwrotne przetaczanie odpowiedzi do klienta. Rzeczywisty obiekt rezyduje w maszynie serwera, w której udostępnia ten sam interfejs co na maszynie klienta. Nadchodzące zamówienia wywołań są najpierw przekazywane do namiastki serwera, często nazywanej szkieletem (ang. skeleton), która dokonuje ich odwrotnego przetoczenia, nadając im postać poprawnych wywołań metod w interfejsie obiektu. Namiastka serwera odpowiada również za przetaczanie odpowiedzi i przekazywanie komunikatów z odpowiedziami do pośrednika po stronie klienta.





Rys. 9 Ogólna organizacja obiektu zdalnego z pośrednikiem po stronie klienta

10. Co to jest i do czego służy CORBA.

CORBA (ang. Common Object Request Broker Architecture) - powszechna architektura pośrednika zamówień obiektowych.

CORBA jest nie tyle systemem rozproszonym co jego specyfikacją. Specyfikacje te zostały opracowane przez konsorcjum Object Management Group (OMG).

Globalna architektura CORBA przystaje do modelu wzorcowego OMG. Model składa się z czterech grup elementów architektonicznych, połączonych tzw. pośrednikiem zamówień obiektowych (ang. Object Request Broker - ORB). Pośrednik ORB tworzy trzon każdego systemu rozproszonego CORBA; odpowiada za umożliwianie komunikacji między obiektami i ich klientami, ukrywając aspekty dotyczące rozproszenia i heterogeniczności. W wielu systemach ORB jest realizowany w postaci bibliotek oferujących podstawowe usługi komunikacyjne, które łączy się z aplikacjami klienta i serwera.





Rys. 10.1 Globalna architektura CORBA

Oprócz obiektów budowanych jako części konkretnych aplikacji w modelu wzorcowym, są również wyodrębnione udogodnienia CORBA (ang. CORBA facilities). Udogodnienia są zbudowane na zasadzie zestawów usług obiektowych (ang. CORBA services) i podzielone na dwie różne grupy.

Udogodnienia poziome (ang. horizontal facilities) składają się z wysokopoziomowych usług ogólnego przeznaczenia, które są niezależne od dziedziny zastosowań. Obecnie należą do nich:

• obsługa interfejsów użytkownika,

• zarządzanie informacją,

• zarządzanie systemem,

• zarządzanie zadaniami (którego używa się do definiowania systemów przepływu prac).

Udogodnienia pionowe (ang. vertical facilities) składają się z usług wysokiego poziomu, ukierunkowanych na konkretną dziedzinę zastosowań, jak:

• handel elektroniczny,

• bankowość,

• produkcja itd.

W standardzie CORBA przyjęto model obiektu zdalnego. W tym modelu implementacja obiektu znajduje się w przestrzeni adresowej serwera. Na uwagę zasługuje fakt, że w specyfikacjach CORBA nigdzie nie mówi się wyraźnie, że obiekty muszą być realizowane jako obiekty zdalne. Praktycznie wszystkie systemy CORBA udostępniają tylko ten model. Ponadto specyfikacje często sugerują, że obiekty rozproszone są rzeczywiście obiektami zdalnymi.

Obiekty i usługi są określane w języku opisu interfejsu CORBA (ang. Interface Definition Language - IDL). CORBA IDL jest podobny do innych języków opisu interfejsu pod względem dostarczania szczegółowej składni do wyrażania metod i ich parametrów. W języku CORBA nie możemy opisać semantyki. Interfejs jest zbiorem metod, a obiekty określają, który interfejs realizują.

Specyfikacje interfejsu możemy podawać tylko za pomocą języka IDL.

Zważywszy, że standard CORBA jest zorganizowany jako zbiór klientów i serwerów obiektów, ogólna budowa systemu CORBA wygląda tak jak na rysunku 10.2.





Rys. 10.2. Ogólna organizacja systemu CORBA

U podłoża każdego procesu w standardzie CORBA - klienta lub serwera - występuje pośrednik ORB. Pośrednika ORB najlepiej jest rozpatrywać jako system wykonawczy, który odpowiada za obsługę podstawowej komunikacji między klientem a serwerem. Ta podstawowa komunikacja gwarantuje, że wywołanie jest wysyłane do obiektu serwera i odpowiedź jest przekazywana z powrotem do klienta.

Z perspektywy procesu ORB oferuje niewiele usług. Są to:

• manipulowanie odniesieniami obiektowymi - odniesienia takie na ogół zależą od konkretnego pośrednika ORB - ORB będzie więc oferować operacje przetaczania i odwrotnego przetaczania odniesień obiektowych, aby można je było wymieniać między procesami, oraz operacje porównania odniesień;

• inne operacje oferowane przez pośrednika ORB dotyczą początkowego odnajdywania usług dostępnych dla procesu - ogólnie biorąc, pośrednik umożliwia uzyskanie początkowego odniesienia do obiektu realizującego konkretną usługę CORBA - na przykład, żeby skorzystać z usług nazewniczych, proces musi wiedzieć, jak się do nich odwołać

Zdarzają się sytuacje, w których statycznie zdefiniowane interfejsy są nieosiągalne dla klienta. Zamiast tego musi on określić w fazie wykonywania, jak powinien wyglądać interfejs do konkretnego obiektu i zestawić zamówienie wywołania danego obiektu. W tym celu CORBA udostępnia klientom interfejs wywołań dynamicznych (ang. Dynamic Invocation Interface - DII), który umożliwia im budowanie zamówienia wywołania w fazie wykonywania.

Dynamiczne konstruowanie zamówień wywołań będzie możliwe wówczas, gdy proces potrafi rozeznać w fazie wykonywania, jak ma wyglądać interfejs. CORBA oferuje magazyn interfejsów (ang. interface repository), który mieści definicje wszystkich interfejsów. Magazyn interfejsów możemy uważać za część systemu CORBA, która pomaga w sprawdzaniu typów w fazie wykonywania.

Przy każdej kompilacji definicji interfejsu kompilator IDL przypisuje interfejsowi identyfikator magazynowy. Taki identyfikator służy za podstawę odzyskiwania definicji interfejsu z magazynu.

Oprócz magazynu interfejsów system CORBA z reguły oferuje też magazyn implementacji. Z założenia magazyn implementacji zawiera wszystko, co jest potrzebne do realizacji i uaktywniania obiektów.

Usługi CORBA:

• obsługa kolekcji - zapewnia środki grupowania obiektów w listy, kolejki, stosy, zbiory - w jakimś sensie obsługa kolekcji jest bliska tego, co zazwyczaj oferują biblioteki klas w językach programowania obiektowego;

• obsługa zapytań - udostępniająca środki do budowy zbiorów obiektów nadających się do odpytywania za pomocą deklaratywnego języka zapytań - zapytanie może zwrócić odniesienie do obiektu lub do zbioru obiektów - obsługa zapytań poszerza obsługę kolekcji o zaawansowane zapytania - od obsługi kolekcji różni się tym, że ta druga oferuje różne typy kolekcji;

• obsługa sterowania współbieżnością - umożliwia ona zaawansowane mechanizmy blokowania, za pomocą których klienci mogą uzyskiwać wspólny dostęp do obiektów - tę usługę możemy wykorzystać do realizowania transakcji, oferowanych jako oddzielna usługa;

• obsługa transakcji - umożliwia klientowi definiowanie ciągu uaktywnień metod wielu obiektów w ramach jednej transakcji - obsługiwane są transakcje płaskie i zagnieżdżone;

• obsługa zdarzeń (środki komunikacji asynchronicznej z użyciem zdarzeń) - dzięki której klienci i obiekty mogą podlegać przerwaniom na okoliczność wystąpienia określonego zdarzenia;

• obsługa powiadomień - zaawansowane środki komunikacji asynchronicznej, opartej na zdarzeniach;

• uzewnętrznianie - usługa, która zajmuje się przetaczaniem obiektów w taki sposób, aby dało się je zapamiętać na dysku lub wysłać siecią - możemy ją porównać z szeregowaniem oferowanym przez Javę, które umożliwia zapisywanie obiektów do strumienia danych w postaci ciągu bajtów;

• obsługa cyklu eksploatacyjnego - udostępnia środki do tworzenia, likwidowania, kopiowania i przemieszczania obiektów - kluczowym pomysłem jest fabryka obiektów, czyli specjalny obiekt używany do tworzenia innych obiektów;

• obsługa licencji - umożliwia budowniczym obiektów dołączanie licencji do ich obiektów i egzekwowanie konkretnych zasad licencjonowania;

• usługi nazewnicze - za pomocą których można nadawać obiektom nazwy czytelne dla człowieka, odwzorowywane na identyfikatory obiektów;

• obsługa właściwości - dzięki niej klienci mogą kojarzyć z obiektami pary (atrybut, wartość) - zauważmy, że te atrybuty nie są częścią stanu obiektu, lecz są używane do opisu obiektu - innymi słowy, dostarczają one informacji o obiekcie, nie są natomiast jego częścią;

• obsługa wymiany handlowej - która umożliwia obiektom ogłaszanie swoich ofert (za pomocą ich interfejsów), a klientom umożliwia znajdywanie usług przy użyciu specjalnego języka, który służy do opisywania ograniczeń;

• obsługa trwałości - oferuje udogodnienia dotyczące przechowywania informacji na dysku w postaci obiektów zmagazynowanych - ważnym zagadnieniem jest tutaj dostarcznie przezroczystości trwałości - klient nie musi jawnie przesyłać danych obiektu zmagazynowanego miedzy dyskiem a dostępną pamięcią operacyjną;

• obsługa zależności (oferuje środki jawnego wiązania dwu lub więcej obiektów) - tworząca w istocie zaplecze organizowania obiektów zgodnie ze schematem pojęciowym, podobnie jak się to czyni w bazach danych;

• usługi bezpieczeństwa - zapewniają uwierzytelnianie, upoważnianie, kontrolowanie, bezpieczną komunikację, niezaprzeczalność i administrowanie;

• obsługa czasu - uzyskiwanie aktualnego czasu w określonych przedziałach błędu.

11. Co to jest interfejs (pojęcie programistyczne) - jaką rolę pełni w rozproszonym systemie komputerowym (w aspekcie organizacyjnym).

W systemach rozproszonych usługi są na ogół określane za pośrednictwem interfejsów, które często wyraża się w języku opisu interfejsów (IDL). Definicje interfejsów, zapisane w języku IDL, prawie zawsze dotyczą tylko składni usług. Mówiąc inaczej, określają one dokładnie nazwy konkretnych funkcji, wraz z typami ich parametrów, wartości powrotnych, możliwych do zgłoszenia wyjątków itd. Trudna częścią jest precyzyjne określenie, na czym mają polegać te usługi, czyli semantyka interfejsów.

Poprawnie sformułowana definicja interfejsu umożliwia dowolnemu procesowi wymagającemu pewnego interfejsu porozumiewanie się z innym procesem, udostępniającym ten interfejs. Umożliwia ona również opracowanie przez dwóch niezależnych wykonawców zupełnie różnych implementacji tych interfejsów co prowadzi do dwóch odrębnych, identycznie działających systemów rozproszonych. Właściwe specyfikacje są zupełne (kompletne) i neutralne. Zupełność oznacza, że wszystko, co jest niezbędne do budowy, zostało rzeczywiście określone.

Interfejs jest zbiorem metod, a obiekty określają, który interfejs realizują.

Standardowe interfejsy ułatwiają też przenoszenie aplikacji na inną maszynę.

Przykładem interfejsu jest kolejka komunikatów.

Interfejs jest tak jakby klasą (abstrakcyjną) określającą metody obiekty ale nie mówią jak one działają.

Interfejs jest prostym opisem funkcjonalności. Zawiera informacje o tym jak wywoływać poszczególne usługi i czego się po nich spodziewać. Nie interesuje nas samo działanie programu a jedynie to jakie dane mamy mu dostarczyć i jakie dostaniemy w odpowiedzi. Interfejs oddziela nas od samego programu. Dzięki temu modyfikacje mechanizmów komponentu nie wymagają wprowadzania zmian w tych elementach systemu, które korzystają z jego usług.

12. Czego dotyczy i na czym polega przetaczanie parametrów.

Przetaczaniem parametrów nazywamy pakowanie parametrów do komunikatu.

Występuje ono przy przetaczaniu parametrów od klienta do serwera, oraz wyników z serwera do klienta. Problemem przetaczania jest kolejność przekazywania bitów (czy od najmłodszego, czy od najstarszego) Str 76 rys 2.8

13. Na czym polega wędrówka kodu. Co to jest silna i słaba przenośność - podać przykłady.

Wędrówka kodu polega na przenoszeniu działającego programu z jednej maszyny na drugą maszynę w celu wykonania kodu na innej maszynie niż była pierwotnie. Dodatkowym celem jest odciążenie maszyn przeciążanych.

Silna przenośność to przenoszenie wszystkich 3 elementów kodu

• segment kodu - to część która zawiera zbiór rozkazów wykonujących dany kod

• segment zasobów - zawiera odniesienia do zasobów zewnętrznych potrzebnych procesowi takich jak pliki, drukarki, inne urządzenia, procesy itd.

• segment wykonania - jest używany do przechowywania aktualnego stanu wykonywanego procesu, na który składają się dane prywatne stos i licznik rozkazów

Absolutnym min wędrówki kodu jest zapewnienie tylko słabej przenośności. W tym modelu należy przesłać tylko segment kodu i, być może, jakieś dane inicjujące. Cechą charakterystyczną słabej przenośności jest to, że przeniesiony program zawsze wykonuje się od początku (np.: aplety Javy).

Słaba przenośność jest łatwo stosowana w systemach heterogenicznych.

W porównaniu ze słaba przenośnością w systemach zapewniających silną przenośność możemy też przesyłać segment wykonania.

Charakterystyczna cechą silnej przenośności jest możliwość zatrzymania wykonywanego procesu, przeniesienia go na inną maszynę i dalszego wykonywania od miejsca, w którym go wstrzymano. Jest widoczne, że silna przenośność jest znacznie ogólniejsza niż przenośność słaba lecz również znacznie trudniejsza do realizacji.

Przykładem systemu z silną przenośnością jest D'Agents

14. Co to jest i do czego służy stos wędrówki.

Stos wędrówki dotyczy wędrówki kodu w systemach heterogenicznych gdzie pojawia się problem silnej przenośności (segment wykonania), gdyż część stosu może zawierać informację zależne od platformy (np.: wartości rejestrów).

Rozwiązaniem - jest następujące działanie:

• Wędrówka kodu może nastąpić tylko w określonych punktach wykonywania programu.

• Do wędrówki może dojść tylko przy wywoływaniu kolejnego podprogramu.

• System utrzymuje własną kopie stosu programu, ale w sposób niezależny od maszyny - kopię tę nazywamy stosem wędrówki.

Stos wędrówki jest aktualizowany przy wywoływaniu podprogramu lub wówczas gdy sterowanie powraca z podprogramu.

15. Wyjaśnić pojęcia związane z DCE (wiązanie, język opisu interfejsu, punkt końcowy, serwer katalogów).

DCE - (ang. Distributing Computing Enviroment) - rozproszone środowisko obliczeniowe

Będący rodzajem RPC wykorzystujący IDL (język opisu interfejsu).

Serwer katalogów uczestniczy w procesie usługi katalogowej, która służy do orientacji w położeniu wszystkich zasobów systemu, usługi katalogowe umożliwiają procesowi zamawianie zasobu bez uwzględniania miejsca jego położenia.

Serwer katalogów zawiera listę i fizyczną lokalizację katalogów.

Wiązanie - nawiązana łączność pomiędzy oprogramowaniem klienta i serwera przez system RPC (DCE) który automatycznie lokalizuje usługodawcę. Może on również obsłużyć transport komunikatów w obu kierunkach, dzieląc je na kawałki i składając wg potrzeb.

Język opisu interfejsu - IDL - zawiera definicję interfejsu. Jest spoiwem łączącym wszystko w modelu klient-serwer, dopuszcza on deklaracje procedur w postaci bardzo przypominającej prototypy funkcji w języku ANSI C. Pliki IDL mogą także zawierać definicje typu, deklaracje stałych oraz inne informacje potrzebne do poprawnego przetaczania parametrów i wyników.

Punkt końcowy - to inaczej port na serwerze służący do komunikacji klienta z serwerem, wykorzystywany w RPC. Jest używany przez SO serwera do rozróżniania komunikatów adresowanych do różnych procesów. Proces zwany demonem DCE utrzymuje w systemie DCE na każdej maszynie serwera tablicę par (serwer, punkt końcowy).

Rys 2.15 /str 88

ROZPROSZONE SYSTEMY KOMPUTEROWE

zaliczenie

20

jego zadaniem ukrycie tych maszyn w sieci

Usługi warstwy pośredniej oprogramowania

Aplikacje rozproszone

PC

PC

PC

Sieć

Maszyna A

Maszyna B

Maszyna C

⇐

1

2

3

4

5

2

3

4

5

1

→

←

liczba bajtowa

Zwrócenie wyniku

Zwrócenie danych

Zamówienie danych

Żądana operacja

Serwer

bazy danych

Serwer

aplikacji

Interfejs

użytkownika

(prezentacja)

Czekanie na wynik

Czekanie na dane

Czas

SO

SO

SO

Zmienne lokalne programu głównego

nbytes

buf

fd

Zmienne lokalne funkcji read

Adres powrotu

Zmienne lokalne programu głównego

Wskaźnik stosu

a)

b)

Czekanie na wynik

Klient

Serwer

Zamówienie

Odpowiedź

Wywołanie procedury lokalnej i zwrócenie wyników

Czas

Wywołanie procedury zdalnej

Powrót z wywołania

Wywołanie procedury zdalnej

Powrót z wywołania

Zamówienie

Odpowiedź

Klient

Czekanie na wynik

Serwer

Wywołanie procedury lokalnej i zwrócenie wyników

Czas

Klient

Czekanie na akceptację

Wywołanie procedury zdalnej

Powrót z wywołania

Zamówienie

Zamówienie akceptacji

Wywołanie procedury lokalnej

Serwer

Czas

Klient

Czekanie na akceptację

Przerwanie u klienta

Wywołanie procedury zdalnej

Powrót z wywołania

Zamówienie

Serwer

Zamówienie akceptacji

a)

b)

Wywołanie procedury lokalnej

Zamówienie wyników

Potwierdzenie

Czas

Wywołanie klienta za pomocą asynchronicznego RPC

Maszyna klienta

Maszyna serwera

SO klienta

SO serwera

Klient

Serwer

Pośrednik

Szkielet

Klient wywołuje metodę

Interfejs ten sam co obiektu

Szkielet wywołuje taką samą metodę w obiekcie

Obiekt

Stan

Metoda

Interfejs

Przetoczone wywołanie jest przekazywane siecią

Sieć

Obiekty aplikacji

Wspólne usługi obiektowe

Udogodnienia

pionowe

(zależne od dziedziny)

Udogodnienia

poziome

(ogólnego przeznaczenia)

Pośrednik zamówień obiektowych

Maszyna klienta

Maszyna serwera

Aplikacja klienta

Realizacja obiektu

Statyczny pośrednik IDL

Interfejs ORB

Interfejs wywołań dynamicznych

ORB klienta

Lokalny SO

Interfejs wywołań dynamicznych

Interfejs ORB

Szkielet

Adapter obiektu

ORB serwera

Lokalny SO

Sieć

---