Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 1 2011 Języki i środowiska programowania systemów rozproszonych Wykładowca:

Prezentacja na temat: "Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 1 2011 Języki i środowiska programowania systemów rozproszonych Wykładowca:"— Zapis prezentacji:

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

2 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 2 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 (Peer- To-Peer) oraz technologie gridowe (grid computing).

3 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 3 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.

4 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 4 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.

5 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 5 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.

6 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 6 2011 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. Krytyczne zagadnienia projektowe dla systemów rozproszonych

7 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 7 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.

8 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 8 2011 Co to jest rozproszona baza danych? 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. distributed database

9 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 9 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.

10 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 10 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.

11 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 11 2011 Ogólna charakterystyka języków zapytań 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. query languages

12 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 12 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.

13 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 13 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).

14 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 14 2011 Problem integracji rozproszonych zasobów

15 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 15 2011 Ogólny schemat integracji G. Wiederhold, 1992: Zasób Osłona Mediator Zasób Osłona Mediator Zasób Osłona Mediator Zasób Osłona Mediator Zasób Osłona Mediator Zasób Osłona Mediator Aplikacja użytkownika 1 Aplikacja użytkownika 2 Zasób Osłona Mediator Zasób Osłona Przyjazny język zewnętrzny Wydajny wewnętrzny język komunikacyjny Język zasobu

16 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 16 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.

17 Języki i środowiska programowania systemów rozproszonych, Wykład 01, Slajd 17 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 q 1, którego czas wykonania jest dramatycznie długi (np. 500 lat), na semantycznie równoważne zapytanie q 2 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ń.