Języki i środowiska programowania systemów rozproszonych

1. Języki i środowiska programowania systemów rozproszonych Wykład 1 Wprowadzenie do systemów rozproszonych i rozproszonych baz danych Wykładowca: Tomasz Kowalski Wykłady przygotowane na podstawie materiałów prof. Kazimierza Subiety

2. 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 (Peer-To-Peer) oraz technologie gridowe (grid computing).

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

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

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

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

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

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

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

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

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

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

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

14. Problem integracji rozproszonych zasobów

15. Ogólny schemat integracji Aplikacja użytkownika 1 Aplikacja użytkownika 2 „Przyjazny” język zewnętrzny Mediator Wydajny wewnętrzny język „komunikacyjny” Mediator Mediator Mediator Mediator Osłona Osłona Osłona Mediator Mediator Mediator Mediator Mediator Zasób Zasób Zasób Osłona Osłona Osłona Osłona Osłona Język zasobu Zasób Zasób Zasób Zasób Zasób • G. Wiederhold, 1992:

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

17. 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ń.