Studia Podyplomowe IT w Biznesie Systemy Rozproszone Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Studia Podyplomowe IT w Biznesie Systemy Rozproszone Wykład 2 Pojęcia systemów rozproszonych Wykładowca: dr hab. inż. Kazimierz Subieta profesor PJWSTK subieta@ipipan.waw.pl, http://www.ipipan.waw.pl/~subieta Niniejszy materiał jest dostępny pod: http://www.si.pjwstk.edu.pl

Podejścia do projektowania systemów rozproszonych: top-down i bottom-up Odgórne zaprojektowanie bazy danych i funkcji systemu. Następnie uwzględnienie konieczności rozproszenia danych i funkcji celem optymalizacji ruchu w sieci, niezawodności, bezpieczeństwa, i innych kryteriów top-down bottom-up Integrowanie już istniejących lub zaprojektowanych lokalnych baz danych i usług lokalnych systemów w jeden globalny rozproszony system. Podejście to jest koniecznością ze względu na współczesne tendencje integracyjne, których katalizatorem stał się m.in. Internet.

Podejście top-down Analiza systemowa rozpoznanie wymagań, precyzowanie kontekstu przyszłej bazy danych Projektowanie schematu pojęciowego, przypadków użycia,... Projektowanie struktury logicznej Kryteria rozproszenia są związane z faktem fizycznego rozproszenia źródeł i odbiorców danych oraz autonomii lokalnych baz danych. Ustalają one decyzje, które fragmenty projektu pojęciowego będą przechowywane w poszczególnych miejscach, a także jak należy zdekomponować schemat logiczny na poszczególne miejsca

Fazy postępowania w podejściu top-down Określenie danych i funkcjonalności niezbędnych w poszczególnych węzłach systemu rozproszonego. Określenie danych podlegających replikacjom (lokalnych kopii) oraz strategii replikacji. Zróżnicowanie logicznego schematu danych w zależności od typu SZBD w poszczególnych miejscach. Określenie lokalnych schematów pojęciowych dla poszczególnych miejsc. Określenie danych autonomicznych dla poszczególnych miejsc, nie uczestniczących w rozproszonej bazie danych, co prowadzi do określenia schematu pojęciowego i logicznego dla danych widzianych z zewnątrz. Podział danych i funkcjonalności: wg różnych kryteriów związanych z fizycznym ulokowaniem danych lub też z fizycznym ulokowaniem programów aplikacyjnych działających na danych.

Podejście bottom-up - zagadnienia Współdziałanie (interoperacyjność) - możliwość współpracy niezależnie zaprojektowanych systemów. Przenaszalność - możliwość przeniesienia oprogramowania zrealizowanego dla danej platformy sprzętowo-programowej na inną platformę. Heterogeniczność (niejednorodność) - sytuacja w których dane i usługi ulokowane w różnych miejscach mają duże różnice w zakresie dostępu, struktury, organizacji, semantyki, ontologii biznesowej, itd. Systemy spadkowe (legacy) - konieczność przystosowania starych, ale użytecznych systemów do nowych wymagań, w szczególności, do włączenia ich w rozproszony system. Autonomia - nie łamanie dotychczasowych lokalnych zasad korzystania z systemu scentralizowanego po jego włączeniu do systemu rozproszonego. Niezależność danych - możliwość rozpatrywania danych jako samodzielnej warstwy niezależnej od oprogramowania, które na tych danych działa. Przezroczystość - odizolowanie użytkownika i programisty od szczegółów rozmieszczenia i implementacji danych.

Współdziałanie (interoperacyjność) interoperability Umożliwieniem współpracy niezależnie zbudowanych (heterogenicznych) systemów. Aspekty: Budowa otwartych systemów operacyjnych, umożliwiających współdziałanie w ramach wielu platform sprzętowych. Wykorzystanie starszego oprogramowania przez nowsze systemy, czyli tzw. zastosowania spadkowe (legacy applications). Budowa wspólnego schematu danych oraz wspólnego języka manipulacji danymi dla heterogenicznego zbioru baz danych. Np. standardowy mobilny kod. Pomosty (gateways), osłony (wrappers) i mediatory (mediators) do obcych baz danych. Automatyczna translacja zapytań/programów z języka A na język B. Opracowanie różnorodnych standardów: SQL, CORBA/IIOP, XML, ODMG, ODBC, JDBC, ...

Przenaszalność portability Własność języka programowania i jego kompilatorów/interpreterów umożliwiająca przenoszenie programów na różne platformy. Typy przenaszalności: Na poziomie składni, koncepcji języka i edukacji (np. SQL-92). Na poziomie kodu źródłowego (np. C++ (?), JDBC). Na poziomie interpretowanego kodu pośredniego (np. Java). Na poziomie kodu binarnego (? - trudno podać przykład). Przenaszalność wymaga precyzyjnej specyfikacji składni i semantyki języka, oraz wyeliminowania z niego własności specyficznych dla poszczególnych platform. Wiele standardów nie spełnia kryterium przenaszalności z powodu niedospecyfikowania i/lub nie spełniania standardu przez wytwórców systemów. Przenaszalność jest celem standardów SQL, CORBA oraz ODMG, niekoniecznie celem już osiągniętym. Przenaszalność realizuje kod pośredni języka Java, ale dotyczy to ograniczonych funkcjonalności.

Problem: heterogeniczność (niejednorodność) heterogeneity Heterogeniczność jest nieodłączną cechą sieci komputerowych i rozproszonych aplikacji.Jest to cecha Internetu, Intranetu, WWW, systemów przepływu prac, rozproszonych baz danych. Np. system Intranetowy może składać się z różnorodnego sprzętu: - komputerów klasy mainframe - stacji roboczych UNIX - komputerów PC pracujących pod MS Windows - komputerów Apple Macintosh - central telefonicznych - robotów, zautomatyzowanych linii produkcyjnych ...włączać różnorodne protokoły komunikacyjne: Ethernet, FDDI, ATM, TCP/IP, Novell Netware, protokoły oparte na RPC,... ...bazować na różnych systemach zarządzania bazą danych/dokumentów: Oracle, Informix, SQL Server, DB2, Lotus Notes, Excell, ObjectStore,.... ...oraz wymieniać pomiędzy sobą niejednorodne dane, podlegające różnym modelom danych, schematom, semantyce, mechanizmom dostępu,...

Przyczyny heterogeniczności Niezależność działania: wytwórcy systemów nie uzgadniają między sobą ich cech. Standardy, o ile się pojawiają, są spóźnione, niekompletne i nie przestrzegane w 100%. Konkurencja: wytwórcy systemów starają się wyposażyć systemy w atrakcyjne cechy, których nie posiadają konkurujące systemy Różnorodność pomysłów: Nie zdarza się, aby było jedno rozwiązanie dla złożonego problemu. Różne zespoły znajdują różne rozwiązania, bazujące często na odmiennych celach i założeniach. Efektywność finansowa i kompromisy: Wytwórcy oferują produkty o różnej cenie, funkcjonalności i jakości, zgodnie z wyczuciem potencjalnych potrzeb klientów, dostosowaniem się do ich portfela i maksymalizacją swoich zysków. Systemy spadkowe (legacy): Systemy, które dawno zostały wdrożone i działają efektywnie, nie mogą być z tego działania wyłączone. Nie jest możliwe (lub jest bardzo kosztowne) zastąpienie ich nowymi systemami. Nowe systemy, o podobnym przeznaczeniu, posiadają inne założenia, cechy i funkcjonalności

Niezgodności schematów schematic discrepancies Przy integracji niezależnie zaprojektowanych baz danych w jeden schemat należy się liczyć z tym, że organizacja, struktura i semantyka danych będzie niezgodna. Nie istnieje ani “jeden” ani “najlepszy” sposób odwzorowania dziedziny przedmiotowej w struktury danych zapamiętane w bazie danych. Różni projektanci projektują całkowicie odmienne struktury dla tego samego problemu. Dlaczego? Obiekty tej samej dziedziny problemowej mogą być widziane przez różnych projektantów całkowicie odmiennie. Systemy zarządzania BD mają ograniczenia struktur danych, które wymuszają sposób myślenia projektantów nad koncepcją struktur danych. Różne środki manipulacji strukturami dostarczane przez SZBD wymuszają często różną koncepcję. Projektanci podejmują różnorodne decyzje co do koncepcji struktur danych w związku z zamierzonymi własnościami użytkowymi, np. szybkością dostępu.

Rodzaje niezgodności Reprezentacja danych. Np. w jednej BD nazwisko jest pisane dużymi literami na 15 znakach, w innej z dużej litery (dalej małe) na 30 znakach; w jednej bazie danych data jest stringiem, w innej są to 3 liczby short; itp. Zawartość struktur danych. Np. w jednej BD projektanci wprowadzili atrybut NazwiskoPanieńskie, w innej z tego zrezygnowano. Różna strukturalizacja informacji. Np. w jednej BD utworzono odrębną tabelę PrzynależnośćDoZwiązkuZawodowego, zaś w innej ta przynależność jest atrybutem tabeli Pracownik; w jednej BD atrybut Adres jest polem tekstowym, w innej zaś strukturą z polami Miejscowość, Ulica, NrDomu, itd. Podział danych i metadane. Np. w jednej BD atrybut Zawód tabeli Pracownicy jest stringiem, zaś w innej utworzono odrębne tabele Piekarze, Stolarze, itd. Zawartość semantyczna danych. Np. w jednej BD rejestrowany jest zarobek miesięczny brutto+premia, w innej zaś tygodniowy bez premii. Istnieje wiele innych niezgodności danych. Do nich dochodzą niezgodności w metodach dostępu do danych.

Autonomia autonomy Autonomia lokalnego miejsca w systemie rozproszonym oznacza, że: Lokalne dane podlegają lokalnym priorytetom, regułom własności, autoryzacji dostępu, bezpieczeństwa, itd. Lokalna baza danych może odrzucić zlecenia przychodzące z systemu rozproszonego, o ile naruszają one lokalne ograniczenia lub zbytnio obciążają czas procesora lub inne lokalne zasoby. Lokalna baza danych może udostępniać aplikacjom działającym w systemie rozproszonym tylko określoną część swoich danych i usług. Programiści tych aplikacji nie mają jakichkolwiek środków dostępu do pozostałych danych i usług. Włączenie lokalnego miejsca do systemu rozproszonego nie może powodować konieczności zmiany programów aplikacyjnych działających w tym miejscu. System rozproszony może przetwarzać lokalne zasoby tylko poprzez interfejs programowania aplikacji (API) specyficzny dla lokalnego systemu. Inne metody (np. bezpośredni dostęp do plików) są niedozwolone. System rozproszony nie może żądać od lokalnego miejsca zmiany/rozszerzenia jej usług (np. udostępnienia lokalnego dziennika transakcji). Możliwa jest pewna skala autonomii, w którym niektóre z tych reguł są osłabione.

Przezroczystość transparency Oddzielenie semantyki danych wysokiego poziomu od detali implementacyjnych niskiego poziomu. Jest to warunek konieczny redukcji złożoności oprogramowania działającego w systemie rozproszonym. Główne aspekty przezroczystości: Przezroczystość lokacji i dostępu: te same metody działania na wszystkich miejscach objętych systemem rozproszonym; programy aplikacyjnych są zwolnione z konieczności uwzględniania informacji o położeniu danych. Przezroczystość implementacji danych: zwolnienie programów aplikacyjnych z konieczności uwzględniania informacji o implementacji i organizacji danych. Przezroczystość protokołów komunikacyjnych: zwolnienie programów aplikacyjnych z konieczności uwzględniania specyfiki protokołów komunikacyjnych. Przezroczystość współbieżności: umożliwienie jednoczesnej pracy wielu programów aplikacyjnych bez utraty spójności i integralności danych. Przezroczystość skalowania: umożliwienie dodawania/usuwania baz danych do/z federacji bez wpływu na postać programów aplikacyjnych. Przezroczystość awarii: minimalizacja skutków awarii węzłów lub linii komunikacyjnych dla programów aplikacyjnych. Również: przezroczystość replikacji, aktywacji, fragmentacji, migracji, wydajności,...

Niezależność danych data independence Możliwość projektowania, utrzymywania, udostępniania, zmiany nośników, zmiany reprezentacji, itp. działań na danych niezależnie od programów, które na nich operują. Własność ta oznacza, że nie ma potrzeby zmiany kodu programów aplikacyjnych mimo zmian organizacji lub schematów danych. Niezależność danych jest osiągana poprzez interfejsy programistyczne umożliwiające dostęp do danych na odpowiednim poziomie abstrakcji, gdy niewidoczne są szczegóły organizacji i implementacji danych. Przykład: SQL. Fizyczna niezależność danych: ukrycie detali organizacji fizycznej i technik dostępu, dzięki czemu możliwa jest ich zmiana bez wpływu na kod aplikacji. Logiczna niezależność danych: umożliwienie niektórych zmian schematu logicznego bez wpływu na kod aplikacji, np. dodanie atrybutów do relacji, zmiana kolejności atrybutów, zmiana ich typów, utworzenie nowych relacji, itd. Ewolucja schematu (schema evolution): umożliwienie daleko idących zmian schematu danych i konwersja danych, przy jednoczesnym zastosowaniu metod umożliwiających automatyczne lub pół-automatyczne przystosowanie aplikacji do nowego schematu i nowych danych.

Osłony wrappers Osłona udostępnia dane i usługi lokalnego systemu i (dostępne w pewnym API i) dla aplikacji globalnych (wykorzystujących wspólny API g). Osłony przystosowują lokalne miejsca do interfejsu programistycznego obowiązującego w systemie rozproszonym. System rozproszony API g API g API g ... Osłona 1 Osłona 2 Osłona n API 1 API 2 API n System lokalny 1 System lokalny 2 System lokalny 3 Osłonom przypisuje się małe skomplikowanie; proste odwzorowanie interfejsów. Bardziej złożone osłony są określane jako mediatory (mediators). Definicja mediatora nie do końca jest jasna; mieści się on gdzieś pomiędzy prymitywną osłoną i bardzo wyrafinowaną perspektywą (view).

Osłony dla lokalnych relacyjnych SZBD Osłony takie są najczęściej zaimplementowane jako sterowniki (drivers) wg standardów opartych o SQL, takich ODBC lub JDBC. Problem pojawia się wtedy, gdy API g dla systemu rozproszonego nie jest oparty o model relacyjny, lecz o model obiektowy a la CORBA lub ODMG. Potencjalne problemy i rozwiązania: Konieczność silnego ograniczenia modelu obiektowego, np. brak złożonych obiektów, metod, związków, hermetyzacji, polimorfizmu, itd.; Odwzorowanie krotek tabel na złożone obiekty - wiele krotek składających się na jeden obiekt. Przetwarzanie np. w OQL+Java. Problemy koncepcyjne. Odwzorowanie obiektowego API, np. OQL +Java na relacyjne API, np. JDBC. Dla ogólnego modelu obiektowego rozwiązanie jest bardzo trudne. Zredukowanie API relacyjnej BD do prymitywnych operacji (get first, get next,...), dzięki czemu relacyjną bazę danych można będzie potraktować jako prymitywną obiektową bazę danych. Następnie, zdefiniowanie obiektowych, wirtualnych, aktualizowalnych perspektyw. Problemy z wydajnością.

Co to jest perspektywa? - pogląd 1 view, database view W literaturze funkcjonują dwa różne (zbliżone) znaczenia. W szerokim znaczeniu: Perspektywą nazywa się odwzorowanie globalnego schematu bazy danych (określającego zapamiętane zasoby danych) na schemat “zewnętrzny”, przystosowany do potrzeb i przyzwyczajeń konkretnego użytkownika. Użytkownik 1 Użytkownik 2 Użytkownik 3 Architektura ANSI/SPARC: Schematy “zewnętrzne” Perspektywa 1 Perspektywa 2 Perspektywa 3 Projektant BD Administrator BD Schemat globalny W tym sensie pojęcie perspektywy funkcjonuje w literaturze z zakresu modeli danych, analizy i projektowania. Poziom fizyczny bazy danych Administrator BD

Co to jest perspektywa? - pogląd 2 W węższym znaczeniu: Perspektywą określa się nazwane odwzorowanie danych zapamiętanych w bazie danych na dane “wirtualne”, t.j. pochodne lub wyliczalne. Matematycznie, perspektywa jest dowolną funkcją określoną na danych. Ten punkt widzenia nie jest jednak dostatecznie precyzyjny, gdyż nie uwzględnia mechanizmów nazywania (naming), wiązania (binding) i zakresu (scoping), które są kluczowe, szczególnie w przypadku obiektowości z hierarchią klas, tożsamością obiektów, hermetyzacją i innymi pojęciami. Bardziej precyzyjny punkt widzenia: Perspektywa jest procedurą funkcyjną, która (najczęściej, ale niekoniecznie) zwraca wynik będący daną typu masowego (zbiorem, wielozbiorem, sekwencją). Taki wynik powinien być wyposażony w dodatkowe nazwy (np. nazwy atrybutów wirtualnych obiektów zwracanych przez perspektywę). Perspektywy znane z SQL mieszczą się w tej definicji.

Perspektywy w relacyjnych bazach danych Perspektywę określa pewne zapytanie, np. SQL. Zdanie definiujące perspektywę określa nazwy atrybutów “wirtualnej tabeli”. Zapamiętana tabela: Pracownicy( Id_pracownika, Imię, Nazwisko, Stanowisko, Kierownik, Data_zatrudnienia, Zarobki, Premia, Id_działu ) Definicja perspektywy: CREATE VIEW Urzędnicy( Id_pracownika, Imię, Nazwisko, Zarobki ) AS SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = ‘urzędnik’; Użycie perspektywy: (Zarobki urzędnika o nazwisku Nowak: ) Perspektywy wolno użyć w zdaniach SQL (prawie) na takich samych zasadach jak zapamiętanej tabeli. SELECT Zarobki FROM Urzędnicy WHERE Nazwisko = ‘Nowak’

Po co są perspektywy? Uproszczenie modeli pojęciowych dla poszczególnych użytkowników. Uproszczenie zapytań poprzez “wyliczane” obiekty, atrybuty, związki. Dostosowanie się do punktu widzenia i terminologii dziedziny zastosowań BD. Ograniczenie dostępu do obiektów, ochrona prywatności. Ograniczenie dostępu w systemach rozproszonych sfederowanych baz danych. Logiczna niezależność obiektów i aplikacji działający na obiektach. Współdziałanie systemów heterogenicznych (wspólny schemat). Przystosowanie systemów spadkowych (legacy) do nowszych technologii i wymagań. Hurtownie danych: analiza informacji gromadzonych z heterogenicznych źródeł.

Rodzaje perspektyw Wirtualne perspektywy Perspektywa istnieje wyłącznie w postaci definicji (np. zapytania, procedury, funkcji). Wyliczenie (materializacja) następuje w momencie użycia perspektywy. Wynik jest “konsumowany” i następnie kasowany (tak jak wynik procedury funkcyjnej) . Zalety: nie ma dublowania danych, problemów aktualizacji wyliczonych danych, problemów z przetwarzaniem transakcji. Wada: czas ewaluacji perspektyw+czas ewaluacji zapytań używających perspektyw (bez optymalizacji bardzo często nieakceptowalny). Zmaterializowane perspektywy Perspektywa jest wyliczona “na zapas”, jej wynik jest przechowywany w bazie danych na normalnych zasadach. Aktualizacja danych stanowiących podstawę wyliczenia pociąga za sobą aktualizację zmaterializowanej perspektywy (lub jej skasowanie i ewentualnie, ponowne wyliczenie). Tego rodzaju perspektywy określa się także jako “zdjęcie migawkowe” (snapshot). Zalety: szybki dostęp, łatwa implementacja. Wady: dodatkowe zapotrzebowanie na pamięć, dodatkowy koszt aktualizacji zmaterializowanych perspektyw (często prowadzący do problemów koncepcyjnych i realizacyjnych), dodatkowe wąskie gardło dla transakcji.

Zasada przezroczystości perspektyw view transparency Z punkty widzenia użytkownika/programisty dowolne operacje na perspektywach nie powinny niczym różnić się od podobnych operacji na zapamiętanych danych. Jeżeli w systemie rozproszonym lokalny SZBD udostępnia dane poprzez perspektywę (a nie poprzez interfejs), wówczas użytkownik lub programista końcowy nie powinien być zmuszany do modyfikacji swoich programów. Zasada przezroczystości perspektyw jest trudna do spełnienia, gdyż: Środki definiowania perspektyw (np. SQL) są niewystarczające m.in. ze względu na silne niezgodności schematów. Potrzebna jest moc języków programowania. Problem aktualizacji perspektyw nie jest rozwiązany w zadowalającym stopniu. Aplikacje globalne mogą używać interfejsów programistycznych, a nie języków zapytań. Te interfejsy (np. Java, C++) “nie rozumieją” perspektyw. Powstają zasadnicze problemy z wydajnością przetwarzania. W/w perspektywy są bezstanowe. Często konieczne są perspektywy, które wymagają wprowadzenia pojęcia stanu (capacity augmenting views).

Przykład aktualizacji perspektyw view updating Dane rzeczywiste Perspektywa Pracownik Nazwisko Zarobek /MojeDziały Nazwa ŚredniZarobek Dział Nazwa zatrudnia Podwyższ średni zarobek w dziale „Produkcja Zabawek” o 500 zł: ? update MojeDziały set ŚredniZarobek = ŚredniZarobek + 500 where Nazwa = ‘Produkcja Zabawek’; Oczywiście, zlecenie jest błędne, gdyż: (1) nie ma danej o nazwie ŚredniZarobek. (2) nawet gdybyśmy chcieli je poprawnie wykonać na danych rzeczywistych, mamy do wyboru nieskończenie wiele sposobów. Istnieją pewne możliwości aktualizacji perspektyw, np. w systemie Oracle. Są one jednak daleko nie wystarczające dla celów integracji baz danych. Znacznie gorzej jest w systemach obiektowych: temat nie wyszedł z fazy badawczej.

Klasyfikacja złożoności perspektyw Proste perspektywy, np. definiowane poprzez operatory selekcji i projekcji w relacyjnych BD. Mała przydatność jako środek integrujący system rozproszony. Perspektywy bardziej złożone, np. wymagające złączeń i grupowania, ale wyrażalne w SQL i OQL. Problemy z aktualizacją perspektyw i wydajnością. Perspektywy umożliwiające zmianę reprezentacji danych. Perspektywy uwzględniające niezgodności schematów, np. zamieniające atrybut Zawód z wartościami “piekarz”, “stolarz” itd. na wirtualne tabele Piekarz, Stolarz, itd. Wymagają dostępu do metabazy i mechanizmu refleksji (reflection). Perspektywy uwzględniające niezgodności semantyczne pomiędzy danymi. Często nie ma możliwości odzyskania informacji, która pozwoliłaby usunąć te niezgodności. Konieczne jest wtedy zrezygnowanie z pełnej przezroczystości. Perspektywy z (trwałym) stanem, o pełnej mocy algorytmicznej. Wydajność? Pozostałe kryteria klasyfikacyjne: generyczność, moc, stopień uwzględnienia pojęć modelu obiektowego, perspektywy rekurencyjne, perspektywy z parametrami, możliwości aktualizacji perspektyw, możliwości optymalizacji, itd.

Refleksja lingwistyczna linguistic reflection Refleksja jest cechą interfejsu programistycznego i techniką programistyczną posiadającą dwa aspekty: Możliwość dynamicznego ustalenia podczas działania programu jego meta-danych. Np. można dynamicznie ustalić strukturę tablic lub interfejsów do obiektów zdefiniowanych w systemie. Możliwość dynamicznego użycia tych informacji w programie, np. skomponowania fragmentu programu (np. w postaci stringu) i następnie wykonanie go w tym samym programie Refleksja umożliwia tworzenie oprogramowania generycznego (niezależnego od konkretnej aplikacji) i oprogramowania systemowego. Pewne (ograniczone) możliwości refleksji posiada Java. Na refleksji są oparte dynamiczne wołania w standardzie CORBA. Wariant refleksji został wykorzystany w dynamicznym SQL. Refleksja może okazać się konieczna dla rozstrzygania poważnych niezgodności schematów lokalnych BD w systemie rozproszonym.