76.Struktura oprogramowania rozproszonego.

Transkrypt

1 76.Struktura oprogramowania rozproszonego. NajwaŜniejsze aspekty obiektowego programowania rozproszonego to: Współdziałanie (interoperability) modułów programowych na róŝnych maszynach. Wielokrotne wykorzystanie (reusability) modułów programowych. Standaryzacja de facto (przemysłowa) lub de iure (niezaleŝna). A tu mamy rysunek obrazujący samą strukturę oprogramowania i pewnie trzeba go wykuć: Aplikacje działające w środowisku rozproszonym mogą być napisane w róŝnych językach programowania. Interfejs do operacji zdalnych jest definiowany w specyficznym języku narzędzia programowania rozproszonego. Interfejs słuŝy do wygenerowania zestawu procedur w konkretnym języku programowania. 77.Elementy modelu klient serwer Interfejs generuje zestaw procedur w konkretnym języku programowania. Część tych procedur będzie wywoływana przez serwer tj. program świadczący usługę wykonania operacji. Inna część tych procedur będzie wykonywana przez klienta tj. program na komputerze zdalnym. Są to tzw. namiastki (stubs) operacji wykonywanych przez serwer. Namiastki Procedury stub maja prawie dokładnie taka samą liczbę i typy parametrów jak w deklaracji interfejsu, ale słuŝą wyłącznie do przekazania argumentów wywołania do serwera, a następnie odebranie wyników zdalnej procedury tam wykonanej. Kod odpowiedzialny za organizacje i konwersje przekazywanych danych (marshalling code) jest generowany automatycznie.

2 Serwer Procedury wygenerowane automatycznie dla serwera to takŝe marshalling code, ale w trakcie obsługi zlecenia następuje wywołanie implementacji tj. procedury, która faktycznie wykona operacje zdefiniowane w interfejsie. Stworzenie implementacji jest zadaniem programisty. Szkielet serwera jest tworzony automatycznie. Ograniczenia przesyłania parametrów Przesyłanie tablic wymaga kaŝdorazowo podania ich rozmiaru. Przesyłanie wskaźników i referencji nie ma sensu: róŝne przestrzenie adresowe serwera i klienta. Przesyłanie deskryptorów plików, uchwytów okien nie ma sensu: obiekty te maja charakter lokalny. Opakowywanie procedur Wrapping przystosowywanie istniejących procedur do pracy w środowisku rozproszonym. Repozytorium serwerów Specjalny proces serwerowy zarządzający katalogiem (repository) serwerów działających w danym systemie. Udostępnia klientom identyfikatory operacji wykonywanych przez poszczególne zarejestrowane serwery. Inne programy zarządzające serwisy (services): zawiadujące (Gronek napisał zawiadujące, ale moim zdaniem chodziło mu o zarządzające...) przesyłaniem komunikatów, prawami dostępu do obiektów, bezpieczeństwem, transakcjami. 78.Organizacja serwisów usług rozproszonych. Serwisy (services) programy zarządzające przesyłaniem komunikatów, prawami dostępu do obiektów, bezpieczeństwem, transakcjami. I tu znowu mamy rysunek:

3 79. Ogólne właściwości mechanizmu RPC. Tyle mamy od Gronka: RPC - Remote Procedure Call Mechanizm RPC został opracowany przez firmę Sun; obecnie znormalizowany przez ISO/IEC. Nie przystosowany do programowania obiektowego. Powszechnie stosowany w systemach Unix. Wspólny sposób reprezentacji podstawowych typów danych external Data Representation (XDR). RPC zawiera funkcje słuŝące do kodowania i dekodowania typów prostych, łańcuchów znaków, tablic, unii i wskaźników języka C w standardzie XDR. A oto co mówi Wiki na ten temat: Remote Procedure Call (RPC) to protokół zdalnego wywoływania procedur, stworzony przez Suna i swego czasu dość popularny na Uniksach, obsługiwany w bibliotekach języka Java, a współcześnie wypierany przez bardziej rozbudowane protokoły takie jak CORBA czy XML-RPC. Standard RPC zdefiniowany jest w RFC RPC uŝywa do kodowania danych formatu XDR (external Data Representation) zdefiniowanego w RFC Protokoły tego typu (jak RPC, CORBA, DCOM, czy XML-RPC) mają na celu ułatwienie komunikacji pomiędzy komputerami. Zazwyczaj wyglądało to tak: Serwer (czyli program oferujący usługi, np. drukowania) przez cały czas nasłuchuje na wybranym porcie, czy ktoś się z nim nie łączy. Klient (czyli program który potrzebuje jakiejś usługi od serwera na innym komputerze) nawiązuje z nim łączność poprzez sieć komputerową.

4 Klient wysyła swoje dane we wcześniej ustalonym przez programistów klienta i serwera formacie. Serwer realizuje usługę i odsyła potwierdzenie lub kod błędu. Protokoły powyŝsze same zapewniają cały powyŝszy mechanizm, ukrywając go przed klientem. MoŜe on nawet nie wiedzieć, Ŝe łączy się z innym komputerem - z punktu widzenia programisty zdalne wywołanie procedury serwera wygląda jak wywołanie dowolnej innej procedury z programu klienta. 80. Zastosowania i operacje wykonywane na strukturach XDR. XDR - External Data Representation XDR ma za zadanie zniwelować róŝnice w reprezentacji typów danych w róŝnych maszynach. RPC zawiera funkcje słuŝące do kodowania i dekodowania typów prostych, łańcuchów znaków, tablic, unii i wskaźników języka C w standardzie XDR. Dane są zapisywane/odczytywane z potoku XDR tj. strumienia bajtów. Potok XDR sposób przekazywania zakodowanych danych Dane są zapisywane w kwantach 4-bajtowych. (znowu te kwanty ) Dane w potoku znajdują się w kolejności wywołań funkcji je kodujących. Nie ma moŝliwości testowania typów danych w potoku kolejność dekodowania musi odpowiadać kolejności kodowania. Funkcje kodujące/dekodujące filtry XDR. Filtry XDR czyli te funkcje kodujące/dekodujące Operacje kodowania i dekodowania są wykonywane przez te same funkcje. Pierwszym argumentem filtru XDR jest zawsze wskaźnik na strukturę reprezentującą potok XDR. Liczba i typy pozostałych argumentów zaleŝą od typu kodowanych danych. Źródła danych potoków XDR Deskryptor pliku: kodowanie zapis do wskazanego pliku, dekodowanie na odczycie z pliku, tworzenie potoku funkcja xdrstdio_create. Obszar pamięci operacyjnej: kodowanie zapis do pamięci od wskazanego adresu, dekodowanie odczyt z pamięci, tworzenie potoku funkcja xdrmem_create. Dowolne źródło danych poprzez dostarczone z zewnątrz funkcje zapisu i odczytu: kodowanie wywołanie funkcji zapisującej dane, dekodowanie wywołanie funkcji dostarczającej dane, tworzenie potoku funkcja xdrrec_create

5 Tryb działania potoku Obowiązkowym parametrem funkcji tworzenia potoku jest tryb, w jakim będzie pracował potok XDR: XDR_ENCODE do kodowania danych, XDR_DECODE do dekodowania danych, XDR_FREE do zwalniania pamięci przydzielonej podczas dekodowania. Nagłówki filtrów XDR Nagłówki filtrów dla typów prostych języka C: bool_t xdr_type(xdr *pstream, type *pobject); gdzie type jest jednym z typów: char, int, long, float, double, void lub enum. Argument pobject wskazuje na kodowaną bądź dekodowaną zmienną. Podobnie wyglądają nagłówki filtrów dla łańcuchów znaków, tablic, unii i wskaźników (mogą one mieć większą liczbę argumentów, w zaleŝności od danego typu). Kodowanie struktur Dla wszystkich pól struktury, w kolejności definiowania wywoływane są odpowiednie filtry. Brak uniwersalnego filtru dla struktur. Definicji struktur dokonuje się w języku RPC. rpcgen program automatycznie generujący odpowiednie filtry dla struktur: tworzy plik nagłówkowy z definicjami struktur w języku C, oraz plik z kodem źródłowym stosownych filtrów.