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).

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

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

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

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

Działanie systemów rozproszonych - zależy nie tylko od serwerów ale i od lokalizacji komputerów w sieci.

DNS ⇒ przykład serwerów rozproszonych.

Sprzęt - 2 grupy maszyn:

• wieloprocesowy - to takie, które mają wspólną pamięć fizyczną i logiczną





• wielokomputery - każda z jednostek ma własną pamięć





2 rodzaje połączeń tych jednostek:

• szynowa - ma wady - tylko 1 jednostka może korzystać





• przełączane - kluczowane





Wieloprocesory

Wieloprocesor szynowy





Inne metody łączenia jednostek centralnych (procesorów) z pamięcią:

• wybierak krzyżowy - wadą - wiele kluczy co jest chore





• sieć przełączająca omega - mniej kluczy





Oprogramowanie - czyli system operacyjny - zarządca zasobów.

2 rodzaje:

• luźno powiązane

• ściśle powiązane - pula zasobów

wieloprocesorowy - RSO - rozproszone systemy operacyjne - również wielokomputerowy ale homogeniczny

wielokomputerowy - SSO - sieciowy system operacyjny

warstwa pośrednia

system wieloprocesorowy - opiera się na systemie jednoprocesorowym

tryb jądra - tryb użytkownika

uruchomione programy - to procesy

wątki

mechanizmy bezpieczeństwa - SEMAFOR

operacja na semaforze jest niepodzielna - wykonuje albo całość albo nic

monitor

Buforowanie i blokowanie





Możliwość blokowania i buforowania przy przekazywaniu komunikatów.





SSO - Sieciowe systemy operacyjne





Ogólna struktura sieciowego systemu operacyjnego.

RPC - zdalne wywołanie procedur





Kapsułkowanie - enkapsulacja

URL




1. Co to jest warstwa pośrednia - podaj przykład.

WYKŁAD 2 13.10.2007

Serwer - program, który wykonuje pewne usługi.

Klient -

Zachowanie - „zamówienie - odpowiedź”









Protokół bezpołączeniowy UDP (datagramy).

Protokół połączeniowy TCP









two − tiered application

Trzy poziomy:

• poziom - to co użytkownik widzi - poziom interfejsu użytkownika

• poziom - poziom przetwarzania [funkcje aplikacji]

• poziom - poziom danych





Str 52

JSP

↑

Java

Architektury wielopiętrowe

Architektura (fizycznie) dwupiętrowa - [ang. (physically) two-tiered architecture] - dwa rodzaje maszyn ⇒ klientów i serwery





Rys. Alternatywne organizacje klient-serwer

1. pozostawienie w maszynie klienta jedynie części interfejsu użytkownika zależnej od terminalu i przekazanie aplikacjom zdalnego sterowania prezentacją ich danych

2. umieszczenie całego oprogramowania interfejsu użytkownika po stronie klienta - czyli dokonanie podziału aplikacji na przednią (czołową) część graficzną, która komunikuje się z resztą aplikacji (pozostającą na serwerze) za pośrednictwem protokołu zależnego od aplikacji - w tym modelu część przednia nie przetwarza niczego oprócz tego, co jest niezbędne do prezentowania interfejsu aplikacji

3. przeniesienie na czoło część aplikacji - jest to sensowne wówczas, gdy aplikacja korzysta z formularza, który należy w całości wypełnić przed dalszym przetwarzaniem - część przednia może wtedy sprawdzić poprawność i spójność formularza i w razie potrzeby konwersować z użytkownikiem - innym przykładem jest edytor tekstu, w którym podstawowe funkcje redagowania działają po stronie klienta na lokalnie i podręcznie przechowywanych danych (czyli na danych w pamięci operacyjnej), natomiast bardziej złożone czyn ności pomocnicze (jak sprawdzanie poprawności ortograficznej i gramatycznej) są wykonywane po stronie serwera

4. maszyna klienta jest komputerem osobistym lub stacją roboczą i jest podłączona siecią do rozproszonego systemu plików lub bazy danych - zasadniczo większa część aplikacji działa po stronie maszyny klienta, lecz wszystkie operacje na plikach lub wpisach bazy danych prowadzą do serwera

5. sytuacja, w której dysk lokalny klienta zawiera część danych - np. w czasie przeglądania Sieci klient będzie stopniowo budował na dysku lokalnym wielką pamięć odręczną ostatnio odwiedzanych stron WWW

Współczesne architektury

Rozproszenie pionowe [ang. vertical distribution]

Architektury wielopiętrowe klient-serwer są bezpośrednią konsekwencją podziału aplikacji na interfejs użytkownika, komponenty przetwarzania i poziom danych. Różne piętra odpowiadają bezpośrednio logicznej organizacji programów użytkowych. W wielu środowiskach handlowych przetwarzanie rozproszone jest równoważne z organizowaniem aplikacji klient-serwer w architekturę wielopiętrową. Ten rodzaj rozproszenia określamy mianem rozproszenia pionowego - znamienną jego cechą jest to, że otrzymuje się je przez rozmieszczanie logicznie odmiennych składowych na różnych maszynach. Jest to pojęcie pokrewne koncepcji fragmentacji pionowej, stosowanej w rozproszonych, relacyjnych bazach danych, a oznaczającej tam podział tabel według kolumn i rozproszenie ich między wiele maszyn (Onzu i Valduriez [337]).

Rozproszenie poziome [ang. horizontal distribution]

W rozproszeniu tego typu klient lub serwer może być fizycznie podzielony na logicznie równoważne części, przy czym każda część przetwarza własny udział całego zbioru danych, równoważąc w ten sposób obciążenia.

Jako przykład popularnego rozproszenia poziomego rozważmy serwer Sieci, zwielokrotniony na kilku maszynach w sieci lokalnej.





Rys. Przykład poziomego rozproszenia usługi WWW

Każdy serwer ma ten sam zbiór stron WWW i przy każdym uaktualnieniu strony kopia jest umieszczana natychmiast na każdym serwerze. Nadchodzące zamówienie jest przekazywane do serwera na zasadzie rotacyjnej (ang. round-robin).

Okazuje się, że ta postać rozproszenia poziomego może być skuteczna w odniesieniu do bardzo popularnych stanowisk Sieci, przy założeniu dostępności dostatecznej szerokości pasma.

Rozproszenie partnerskie (równorzędne) [ang. peer-to-peer distribution] [P2P]

Klienci mogą być również rozproszeni. W prostych aplikacjach o charakterze wzajemnej współpracy możemy nawet mieć do czynienia z brakiem jakiegokolwiek serwera lub jego funkcje zostaną ograniczone do lokalizacji pozostałych klientów.

Może się na przykład zdarzyć, że użytkownik szuka kontaktu z innym użytkownikiem, po czym obaj inicjują działanie tej samej aplikacji, żeby rozpocząć sesję. Trzeci klient może skontaktować się z dowolnym z tych dwóch użytkowników i znów zainicjować to samo oprogramowanie użytkowe.

Zdalne wywołanie procedury - RPC

Wiele systemów rozproszonych oparto na jawnej wymianie komunikatów między procesami.

ROZPROSZONE SYSTEMY KOMPUTEROWE

zaliczenie

13

APLIKACJA

PREZENTACJA

SESJA

TRANSPORT

SIEĆ

ŁĄCZA DANYCH

FIZYCZNA

TCP / IP

• ⇑

4 3

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

CPU

CPU

3

4

5

1

→

←

liczba bajtowa

CPU

CPU

MEMORY

CPU

CPU

CPU

M

M

M

CPU

CPU

CPU

M

M

CPU

CPU

CPU

M

M

CPU

CPU

CPU

CPU

cache

cache

cache

cache

pamięć

podręczna

ona przechowuje kopie

MEMORY

Moduły pamięci

Jednostki centralne

P

M

M

M

M

P

P

P

Punkt przełączający

Jednostki centralne

P

P

P

P

Moduły pamięci

M

M

M

M

Przełącznik 2 na 2

Możliwy punkt synchronizacji

Sieć

Bufor odbiorcy

Bufor nadawcy

Odbiorca

Nadawca

S3

S1

S4

S2

Wspólna globalna przestrzeń adresowa

8

7

6

5

4

3

2

1

0

11

12

13

14

9

10

15

a) strony przestrzeni adresowej rozproszone między maszynami

CPU 1

CPU 4

CPU 3

CPU 2

0

2

5

9

1

3

6

8

10

4

7

11

12

14

13

15

pamięć

b) sytuacja po odwołaniu się przez CPU 1 do strony 10

CPU 1

CPU 2

CPU 3

CPU 4

0

2

5

9

10

1

3

6

8

c) sytuacja, w której strona 10 jest tylko do czytania i używa się zwielokrotnienia

CPU 1

CPU 2

CPU 3

CPU 4

0

2

5

9

10

1

3

6

8

10

4

4

7

7

11

11

12

12

14

14

13

13

15

15

Rozproszona pamięć dzielona

Usługi sieciowego systemu operacyjnego

Usługi sieciowego systemu operacyjnego

Aplikacje rozproszone

Jądro

Jądro

Jądro

Sieć

Maszyna A

Maszyna B

Maszyna C

Usługi sieciowego systemu operacyjnego

K

S

przetwarzanie danych

DEMON

USŁUGA

(Windows)

to samo

SYN

SYN, ACK (SYN)

ACK (SYN)

[synchronizacja]

żądanie

można powtórzyć

nie można powtórzyć

[ I poziom ]

[ II poziom ]

[ III poziom ]

np. do przeglądarki

Generator HTML

Generator zapytań

BDA

wyniki

Maszyna klienta

a)

b)

c)

d)

e)

Interfejs użytkownika

Interfejs użytkownika

Aplikacja

Baza danych

Baza danych

Baza danych

Baza danych

Baza danych

Aplikacja

Aplikacja

Baza danych

Aplikacja

Interfejs użytkownika

Interfejs użytkownika

Interfejs użytkownika

Interfejs użytkownika

Aplikacja

Aplikacja

Maszyna serwera

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

Osłona obsługująca nadchodzące zamówienia

Dyski

Zamówienia obsługiwane na zasadzie rotacyjnej

Zwielokrotnione serwery Sieci

zawierające te same strony WWW

Internet

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ć

---