Wprowadzenie do systemów rozproszonych i

Języki i środowiska programowania
systemów rozproszonych
Wykładowca: Tomasz Kowalski
Wykład 1
Wprowadzenie do
systemów rozproszonych
i rozproszonych baz
danych
Wykłady przygotowane na
podstawie materiałów
prof. Kazimierza Subiety
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 1
2011
Co to jest system rozproszony?
 Systemem rozproszonym nazywamy taki system, w którym
przetwarzanie informacji odbywa się na wielu komputerach, często
znacznie oddalonych geograficznie (od kilku metrów do dziesiątków
tysięcy kilometrów).
• Przeciwieństwem jest system izolowany lub scentralizowany.
 Obecnie właściwie wszystkie systemy są rozproszone.
• Ogromnym katalizatorem rozproszenia systemów jest Internet.
 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óry specjalista inżynierii oprogramowania musi być świadomy.
 Tendencja do budowy systemów rozproszonych jest pochodną rozbudowy
tanich, szybkich, uniwersalnych i niezawodnych sieci komputerowych.
 Przykłady systemów rozproszonych: sieć bankomatów, system rezerwacji
biletów, system pracy grupowej, itd.
 Nową jakość do tematu systemów rozproszonych wnoszą sieci P2P (PeerTo-Peer) oraz technologie gridowe (grid computing).
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 2
2011
Zalety systemów rozproszonych (1)
 Podział zasobów: system rozproszony pozwala dzielić zasoby sprzętowe i
programowe pomiędzy wielu użytkowników pracujących na różnych
komputerach pracujących w sieci.
 Otwartość: jest ona definiowana jako zdolność systemu do dołączania
nowego sprzętu, oprogramowania i usług.
• Najlepiej na platformach sprzętowych i systemach operacyjnych
dostarczanych przez różnych dostawców.
 Współbieżność: w systemie rozproszonym wiele procesów może działać
w tym samym czasie na różnych komputerach w sieci.
• Procesy te mogą komunikować się podczas swego 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.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 3
2011
Zalety systemów rozproszonych (2)
 Tolerancja błędów: Dostępność wielu komputerów oraz
umożliwienie zdublowania informacji (replikacje) oznacza, że
rozproszony system jest tolerancyjny w stosunku do pewnych
błędów zarówno sprzętowych jak i programowych.
• Np. awaria węzła komunikacyjnego powoduje wygenerowanie innej trasy
przepływu informacji.
 Przezroczystość: Oznacza ukrycie przed użytkownikiem
szczegółów rozproszenia, np. gdzie ulokowane są zasoby lub jak są
one fizycznie zaimplementowane, pod jakim systemem pracują, itd.
• Przezroczystość ma zasadnicze znaczenie dla komfortu działania
użytkownika oraz dla niezawodności budowanego oprogramowania.
• Niekiedy, np. dla celów optymalizacyjnych, użytkownik może zrezygnować z
pełnej przezroczystości.
• Przykładem przezroczystości jest Internet: klikając w aktywne pole na stronie
WWW nie interesujemy się, gdzie znajduje się odpowiadająca mu strona,
oraz jak i na czym jest zaimplementowana.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 4
2011
Wady systemów rozproszonych
 Złożoność: systemy rozproszone są trudniejsze do zaprogramowania i do
administrowania niż systemy scentralizowane.
• Zależą od własności sieci, np. jej przepustowości i czasu transmisji, co utrudnia
zaprojektowanie i zrealizowanie wielu algorytmów i procesów przetwarzania.
 Ochrona: Dla systemu scentralizowanego wystarcza w zasadzie strażnik z
karabinem. System rozproszony nie może być chroniony w ten sposób,
przez co może być narażony na różnorodne ataki (włamania, wirusy,
sabotaż, odmowa płatności, itd.) z wielu stron, które trudno
zidentyfikować.
 Zdolność do zarządzania: jest ona utrudniona 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.
 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.; patrz WWW.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 5
2011
Krytyczne zagadnienia projektowe dla systemów
rozproszonych
 Identyfikacja zasobów: zasoby są podzielone pomiędzy wiele komputerów,
w związku z czym schematy ich nazywania muszą być zaprojektowane tak,
aby użytkownicy mogli zidentyfikować interesujące ich zasoby.
• Przykładem takiego schematu jest URL znany z WWW.
 Komunikacja: może być zaprojektowana w sposób uniwersalny, na bazie
np. protokołu internetowego TCP/IP.
• Niektóre wymagania dotyczące szybkości, kosztu, niezawodności lub
bezpieczeństwa mogą prowadzić do specjalnych technik komunikacyjnych.
 Jakość obsługi: odzwierciedla wydajność systemu, jego dostępność i
niezawodność.
• Podlega ona wielu czynnikom, w szczególności, przypisaniu zadań do
procesorów, optymalności geograficznego podziału danych, itd.
 Architektura oprogramowania: opisuje ona w jaki sposób funkcjonalności
systemu są przypisane do logicznych i fizycznych komponentów systemu.
Wybór dobrej architektury przesądza o spełnieniu kryterium jakości obsługi.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 6
2011
Popularne architektury rozproszenia
 Klient-serwer: rozproszony system ma wyróżniony węzeł zwany serwerem,
oraz szereg podłączonych do niego węzłów zwanych klientami.
• Związek nie jest symetryczny: serwer wykonuje usługi zlecane przez klientów,
nie może im odmówić i nie może im zlecić wykonanie usług.
 Klient-multi-serwer: podobnie jak dla architektury klient-serwer, ale
istnieje wiele serwerów, np. WWW.
 Koleżeńska (peer-to-peer, P2P): wiele węzłów świadczy sobie wzajemne
usługi poprzez bezpośrednie połączenie; nie ma wyraźnego podziału na
usługodawców i usługobiorców.
• Np. Gnutella, NXOR, Napster, Kazaa; JXTA jako narzędzie do P2P.
• Komercyjny buzz dookoła P2P.
 Architektura oparta na oprogramowaniu pośredniczącym (middleware):
nie występuje podział na klientów i serwery, np. CORBA i WebServices.
 Architektury gridowe: wirtualny komputer sumujący zasoby wielu
komputerów w sposób przezroczysty dla użytkowników.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 7
2011
Co to jest rozproszona baza danych?
distributed database
 Termin ten jest powtarzany w wielu kontekstach, często bez
przypisywania mu konkretnego, technicznego znaczenia.
 Czy to, że z pewnego systemu można dostać się do danych innego
odległego systemu jest wystarczającym wyróżnikiem rozproszonej bazy
danych?
 Dla wielu zastosowań cecha ta jest istotna, ale:
 Rozproszona baza danych musi spełniać określone kryteria dotyczące
spójności, bezpieczeństwa, zintegrowania i wygody użytkowników.
 Możliwość dostania się do danych innego systemu (np. poprzez pakiety
oparte o technologie ODBC, JDBC, .NET, CORBA, J2EE, WebServices)
oznacza wyłącznie ustanowienie niezbędnej bazy technicznej.
 Fakt ten nie przesądza jednak o tym, czy zachodzą dostateczne warunki
dla sprawnego, efektywnego oraz niezawodnego wykorzystywania
danych.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 8
2011
Podstawowe pojęcia związane z rozproszeniem
 Rozproszona baza danych: zbiór składający się z wielu logicznie ze sobą
powiązanych elementów bazy danych, oddalonych geograficznie i
połączonych ze sobą poprzez sieć komputerową.
 System zarządzania rozproszoną bazą danych (SZRBD):
oprogramowanie umożliwiające połączenie rozproszonych zasobów w
jedną całość, utrzymanie spójność zasobów oraz udostępnianie ich
użytkownikom przy założeniu przezroczystości rozproszenia.
 Dane są przechowywane w wielu miejscach - węzłach sieci.
 Rozproszona baza danych jest bazą danych, a nie kolekcją plików, które
mogą być indywidualnie przechowywane w każdym węźle sieci
komputerowej.
 SZRBD posiada pełną funkcjonalność systemu zarządzania
scentralizowaną BD.
• Nie jest to system zarządzania rozproszonymi plikami, ani też wyłącznie
system przetwarzania transakcji.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 9
2011
Przykład rozproszonej bazy danych
 Rozproszona baza danych dla linii lotniczych (biuro obsługi klienta w
Warszawie może dostać się do danych linii lotniczych w Sydney, Tokio,
Paryżu, i setkach innych miast).
 Jeżeli w każdym miejscu organizacja bazy danych, środki manipulacji,
reguły dostępu, itd. byłyby inne, to praca byłaby bardzo utrudniona, o ile
w ogóle możliwa.
 Zatem konieczne są:
• standardy w zakresie połączenia (protokoły),
• standardy w zakresie organizacji danych i dostępu do danych,
• moduły dla odwzorowania pewnej specyficznej bazy danych na format
oczekiwany przez danego klienta,
• przezroczystość rozproszenia (a la CORBA),
• zabezpieczenia przed niepowołanym dostępem.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 10
2011
Ogólna charakterystyka języków zapytań
query languages
 Języki zapytań są przyjaznymi dla użytkowników interfejsami do
bazy danych, umożliwiającymi jej przeszukiwanie według dowolnie
wybranych kryteriów i dowolnie określanego wyniku
wyszukiwania.
 Języki zapytań tworzą relatywnie nową dziedzinę informatyki, która
(jak dotąd) jest związana z tematyką baz danych.
 Językiem zapytań dla relacyjnych baz danych jest SQL. SQL jest
uważany za źródło komercyjnego sukcesu całej technologii
relacyjnych baz danych.
 Pozycja SQL jako czołowego języka dla relacyjnych baz danych
została wzmocniona przez standardy ANSI (American National
Standard Institute) oraz ISO (International Standard Organization):
SQL-89 oraz SQL-92. Zakończyły się także prace nad standardem
SQL3, który uzyskał nowe oznaczenie SQL-99.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 11
2011
Teorie języków zapytań
 Wraz z językami zapytań pojawiły się różnorodne teorie, takie jak
algebra relacji, rachunek relacyjny i odmiany logiki matematycznej.
 Teorie języków zapytań są istotne z kilku względów, w
szczególności ustalają ich bazę koncepcyjną, semantyczną i
dydaktyczną, oraz zasadniczo wspomagają opracowanie metod
optymalizacyjnych.
 Pojawiło się także wiele metod empirycznych, w szczególności
dotyczących optymalizacji zapytań.
 Niestety, algebra relacji i rachunek relacyjny przykrywają kilka
procent konstrukcji SQL i nie są z nim do końca spójne
 Metody optymalizacyjne są zbytnio przywiązane do relacyjnego
modelu danych (którego czas minął) i do fizycznych własności
systemów, mają ograniczony zakres stosowalności, oraz mają luki i
niejasności koncepcyjne.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 12
2011
Chaos...
 Pojawienie się obiektowych i obiektowo-relacyjnych (object-relational)
baz danych stworzyło w tej dziedzinie nową jakość.
 Dotyczy to także technologii internetowych opartych o standard XML,
który jest ostatnio postrzegany jako nowy model bazy danych.
 Nowe modele danych, standardy, rozwiązania praktyczne, metody i teorie
spowodowały stan, który można określić jako totalny chaos:
• brak spójnych, jednorodnych podstaw teoretycznych,
• przypadkowość rozwiązań praktycznych.
 Dominują w tym względzie liczne rozszerzania operatorów obecnych w
SQL oraz rozszerzania i modyfikacje teorii takich jak algebra relacji,
rachunek relacyjny i innych.
 Świadectwem chaosu są wadliwe standardy SQL-99 i ODMG OQL.
 Świadectwem chaosu jest także stan języków zapytań dla XML, wśród
nich XQL, XPath, XLink, XPointer, XQuery i inne.
 Opakowanie składni w XML czyni je bardzo nieczytelnymi i jest bez
sensu. Niezrozumiałe jest dążenie do specjalizowania tych języków (np.
XPath, XLink, XPointer).
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 13
2011
Problem integracji rozproszonych zasobów
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 14
2011
Ogólny schemat integracji
 G. Wiederhold, 1992:
Aplikacja
użytkownika 1
Aplikacja
użytkownika 2
„Przyjazny” język
zewnętrzny
Mediator
Wydajny
wewnętrzny język
„komunikacyjny”
Mediator
Mediator
Osłona
Mediator
Mediator
Mediator
Osłona
Osłona
Osłona
Zasób
Zasób
Zasób
Zasób
Mediator
Osłona
Zasób
Mediator
Osłona
Zasób
Mediator
Mediator
Osłona
Osłona
Zasób
Zasób
Język zasobu
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 15
2011
Czy przyszłością języków zapytań jest SQL, OQL lub
XQuery?
 Propozycje są kontrowersyjne.
 SQL-99 jest krytykowany za eklektyzm, wszystkoizm i przypadkowość decyzji w
zakresie konstrukcji językowych, co owocuje monstrualną specyfikacją (ponad
1500 stron, plus dodatki, razem ponad 5000 stron).
 Jest wątpliwe, aby ktokolwiek zaimplementował ten język w całości.
 OQL jest językiem znacznie mniejszym, ze specyfikacją mieszczącą się na
kilkudziesięciu stronach, ale pozwala wyłącznie na wyszukiwanie danych.
Brakuje konstrukcji imperatywnych, perspektyw, procedur, itd.
 Co za tym idzie, programowanie w OQL wymaga zanurzenia zapytań w
uniwersalny język programowania: C++, Smalltalk i Java.
 Zanurzenie języka zapytań w uniwersalny język programowania ma złą sławę
określaną jako „niezgodność impedancji”.
 XQuery wzoruje się na OQL, ale wprowadza w sposób nieco chaotyczny dalsze
cechy, np. funkcje definiowane przez użytkowników.
 Wszystkie te propozycje cechuje niespójność (i w gruncie rzeczy, brak istotnej
koncepcji) w zakresie semantyki.
 Metody optymalizacyjne dla tych języków są w stanie embrionalnym.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 16
2011
Czy warto zabiegać o precyzyjną semantykę?
 Brak precyzyjnej semantyki jest powszechny dla nowo powstających
języków programowania.
 W przypadku języków zapytań sytuacja jest odmienna w porównaniu do
klasycznych języków programowania.
 Języki zapytań są dramatycznie nieefektywne (praktycznie
nieakceptowalne) w przypadku braku automatycznej optymalizacji.
 Optymalizacja oznacza zamianę zapytania q1, którego czas wykonania jest
dramatycznie długi (np. 500 lat), na semantycznie równoważne
zapytanie q2 posiadające akceptowalny czas wykonania (np. 5 sekund).
 Powoduje to konieczność ustalenia, co to znaczy „semantycznie
równoważne zapytanie”. Jest to niemożliwe bez precyzyjnej formalizacji
zarówno danych, na których operują zapytania, jak i semantyki
operatorów występujących w zapytaniach.
 Uzyskanie pełnej jasności i precyzji opisu semantyki obiektowych
języków zapytań jest celem tego wykładu.
 Wykład będzie opierać się o podejście stosowe do obiektowych języków
zapytań.
Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 17
2011