© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 1 styczeń 2005 Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz.

Prezentacja na temat: "© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 1 styczeń 2005 Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz."— Zapis prezentacji:

1 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 1 styczeń 2005 Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl Wykład 13: Osłony, mediatory, perspektywy, przetwarzanie rozproszonych zapytań, gridy

2 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 2 styczeń 2005 Osłona Jest to moduł oprogramowania umożliwiający przystosowanie interfejsu lokalnej bazy danych do pewnego standardu obowiązującego w systemie rozproszonym. Podstawowe zadanie: fizyczne połączenie różnych baz danych. Osłona nie zajmuje się bardziej wyrafinowanym odwzorowaniem; chodzi o translację danych, parametrów i wywołań funkcji płynących z zewnątrz lokalnego systemu (o specyficznych formatach i reprezentacji) na analogiczne dane, parametry i funkcje wyrażone w API konkretnego lokalnego systemu bazy danych. Dla niektórych przypadków, np. dla niektórych stron HTML lub plików XML, napisanie osłony jest bardzo trudnym zadaniem ze względu na nieregularności formatu (dane pół-strukturalne, semi-structured) oraz różnice ontologiczne. Osłona jest niezbędna do tego, aby budować bardziej wyrafinowane środki odwzorowania schematów i aplikacji, takie jak mediatory i perspektywy wrapper

3 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 3 styczeń 2005 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 f). Osłony przystosowują lokalne SZBD do interfejsu programistycznego obowiązującego w federacji. Osłony w federacyjnych BD Federacyjny SZBD Lokalny SZBD 2 Osłona 2 API 2 Lokalny SZBD n Osłona n API nAPI 1 Lokalny SZBD 1 Osłona 1 API f...

4 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 4 styczeń 2005 Problem pojawia się wtedy, gdy API f dla federacyjnej bazy danych nie jest oparty o model relacyjny, lecz o model obiektowy a la CORBA lub ODMG. Potencjalne problemy i rozwiązania: Osłony dla lokalnych relacyjnych SZBD 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. Ogólne 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 koncepcyjne. Problemy z wydajnością.

5 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 5 styczeń 2005 Mediatory mediator Jest to warstwa pośrednia pomiędzy lokalną bazą danych a globalnymi aplikacjami. Jest konieczny wtedy, gdy nie ma odwzorowania 1:1 pomiędzy ontologiami. Np. w jednej bazie podany jest zarobek brutto z ubezpieczeniem, w innej zarobek brutto bez ubezpieczenia. Jak to sprowadzić do wspólnego mianownika? Zadania mediatora: Rozstrzyganie rozbieżności pomiędzy schematem lokalnym a schematem federacyjnym. Wspomaganie dla wyłowienia cech formalnych z danych niesformatowanych. Selekcja właściwej informacji. Wspomaganie dla informacji sumarycznych, wyliczalnych oraz o większym stopniu abstrakcji. Wspomaganie dla wykrywania niezidentyfikowanych związków w danych (eksploracja danych). Zasady konstrukcji mediatorów nie są jasne. W większości przypadków mediator musi być zaprojektowany ad hoc, pisany techniką niskiego poziomu i przypisany do konkretnej aplikacji (nie uniwersalny).

6 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 6 styczeń 2005 Perspektywa (view) jest to odwzorowanie schematu lokalnego w inny (zmodyfikowany) schemat. Temu odwzorowaniu towarzyszy odwzorowanie danych rzeczywistych lokalnej bazy danych na dane wirtualne lub dane zmaterializowane (wyliczone). Przykładem są perspektywy w SQL. Podstawowe problemy: W przypadku istotnych różnic pomiędzy schematami lokalnymi baz danych, odwzorowanie ich w zadany schemat może być złożone lub niemożliwe. Środki definiowania perspektyw np. w SQL są za mało uniwersalne. Aktualizacja perspektyw (view updating): problem dotychczas nie był rozwiązany w stopniu zadowalającym (obecnie jest wreszcie właściwa koncepcja, ale do zastosowań biznesowych jest bardzo daleko). Aplikacje (np. w C++) są często przywiązane do fizycznej postaci danych. Odwzorowanie ich w dane wirtualne powoduje, że większość aplikacji przestaje działać. Ograniczenie do zapytań (np. w SQL) silnie redukuje rodzaj aplikacji, które mogą działać na schemacie federacyjnym. Wydajność (performance) aplikacji. Perspektywy view, database view

7 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 7 styczeń 2005 Perspektywa jak schemat zewnętrzny Administrator BD Projektant BD Administrator BD Użytkownik 1Użytkownik 2Użytkownik 3 Schematy zewnętrzne 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. Schemat globalny Poziom fizyczny bazy danych Perspektywa 1Perspektywa 2Perspektywa 3 W tym sensie pojęcie perspektywy funkcjonuje w literaturze z zakresu modeli danych, analizy i projektowania. Architektura ANSI/SPARC:

8 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 8 styczeń 2005 Perspektywa jako odwzorowanie W wąskim znaczeniu: Perspektywą określa się nazwane odwzorowanie danych zapamiętanych w bazie danych na dane wirtualne. Matematycznie, perspektywa jest funkcją określoną na danych. Ten punkt widzenia nie jest jednak dostatecznie precyzyjny, gdyż nie uwzględnia mechanizmów nazywania, wiązania i zakresu. Nieco bardziej precyzyjny punkt widzenia: Perspektywa jest procedurą funkcyjną, która (najczęściej, ale niekoniecznie) zwraca wynik będący daną typu masowego (zbiór, wielozbiór, 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. Ich ciało można sprowadzić do pojedynczego zdania:return Najbardziej precyzyjny punkt widzenia: perspektywa jest bytem programistycznym zawierającym definicję odwzorowania danych rzeczywistych na dane wirtualne oraz definicje odwzorowań wszelkich operacji na danych wirtualnych na operacje na danych rzeczywistych.

9 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 9 styczeń 2005 Po co są perspektywy? Istnieje wiele ważnych zastosowań perspektyw, które czynią z nich bardzo gorący i aktualny temat. 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ń Ograniczenie dostępu do obiektów, ochrona prywatności. Ograniczenie dostępu w systemach rozproszonych federacyjnych 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 różnych źródeł.

10 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 10 styczeń 2005 Perspektywy wirtualne Perspektywa istnieje wyłącznie w postaci definicji (np. zapytania, procedury funkc.). 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 jest bardzo często nieakceptowalny.

11 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 11 styczeń 2005 Perspektywy zmaterializowane 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.

12 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 12 styczeń 2005 Z punkty widzenia użytkownika dowolne operacje na perspektywach nie powinny niczym różnić się od podobnych operacji na zapamiętanych danych. Np. jeżeli w federacyjnej bazie danych administrator udostępnia tylko część danych poprzez perspektywę, wówczas programista końcowy nie powinien być zmuszany do modyfikacji programów działających na zapamiętanych danych z tego powodu, że mają one teraz działać na perspektywach. Warunek przezroczystości perspektyw jest trudny, gdyż: Dla pewnych odwzorowań danych zapamiętanych w wirtualne przyjęte środki definicji perspektyw (np. SQL) mogą okazać się niewystarczające (schematic discrepancies). Problem aktualizacji perspektyw. Pewne dane mogą być manipulowane wyłącznie przez przypisane im interfejsy, a nie przez języki zapytań. Problemy z wydajnością mogą unicestwić rozwiązania trzech poprzednich problemów. Zasada przezroczystości perspektyw view transparency

13 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 13 styczeń 2005 Przetwarzanie perspektyw w zapytaniach Obowiązują dwie strategie: Materializacja. Perspektywa jest całkowicie liczona w momencie, kiedy sterowanie programu/zapytania osiągnie punkt, w którym wynik tej perspektywy staje się niezbędny dla dalszego przetwarzania. Każde odwołanie się do perspektywy powoduje jej ponowne wyliczenie (dla uniknięcia niespójności związanych z ewentualną aktualizacją BD). Ta strategia może być optymalizowana poprzez zmaterializowane perspektywy. Modyfikacja zapytań (query modyfication). Tekst zapytania, w którym występuje odwołanie do perspektywy, jest scalany z tekstem definicji perspektywy. Następnie takie rozwinięte zapytanie jest wspólnie optymalizowane na normalnych zasadach. W tej strategii definicja perspektywy jest traktowana jako makro. Ponieważ wcześniejszy SQL nie dopuszczał klauzuli SELECT wewnątrz klauzuli FROM, kwestia banalnego tekstowego zastępowania przybrała cudaczne formy, owocując w super-naukowe algorytmy :-) (Stonebraker et al). W SQL-92 tę wadę usunięto. W różnych sytuacjach pierwsza lub druga strategia może być bardziej optymalna, ale najczęściej strategia modyfikacji zapytań jest bardziej skuteczna. Z tego powodu jest ona standardem we wszystkich relacyjnych SZBD.

14 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 14 styczeń 2005 Przetwarzanie zapytań w rozproszonych BD Przetwarzanie zapytań powinno minimalizować zarówno obciążenie linii transmisyjnych jak i pracochłonność przetwarzania po stronie klienta (globalnej aplikacji) jak i po stronie serwerów. Przetwarzanie wyłącznie po stronie klienta (gruby klient): ogromne obciążenie linii transmisyjnych. Przetwarzanie wyłącznie po stronie serwerów (chudy klient): może powstać wąskie gardło wskutek tego, że jednocześnie wielu klientów będzie żądać usługi od jednego serwera. Generalna zasada: "wyślij zapytanie do danych, a nie dane do zapytanie" nie dla wszystkich przypadków jest słuszna i rodzi problemy koncepcyjne. Przetwarzanie zapytań odbywa się poprzez: dekompozycję zapytania na operacje wysyłane do różnych węzłów, porządkowanie tych operacji, zbieranie ich rezultatów oraz ich przetwarzanie przez klienta w celu skonstruowania ostatecznego wyniku zapytania.

15 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 15 styczeń 2005 Strategie optymalizacji zapytań w rozprosz. BD Przetwarzanie wyłącznie po stronie klienta. Pobiera on wszystkie dane potrzebne do realizacji zapytania do swojego obszaru Duży czas i koszt transmisji danych, małe problemy koncepcyjne. "Statyczna" dekompozycja zapytania na podzapytania, wysłanie ich do lokalnych miejsc, przesłanie rezultatów podzapytań do klienta, który łączy tych rezultaty w globalny rezultat. Skuteczna dla fragmentacji poziomej danych i zapytań ograniczonych do selekcji/projekcji, nieskuteczna dla zapytań złożonych. "Dynamiczna" dekompozycja: generacja podzapytania do miejsca 1 i przesłanie wyniku 1 do centralnego miejsca; generacja podzapytania do miejsca 2 i przesłanie wyniku 2 do centralnego miejsca, itd. Brak równoległości działania serwerów, trudności koncepcyjne. Hybrydowa dekompozycja - połączenie dekompozycji statycznej i dynamicznej. Hybrydowa dekompozycja z przesłaniem danych do serwera. Klient nie tylko dokonuje wysłania podzapytania do serwera, ale również przesyła do niego część danych, które otrzymał od innych serwerów.

16 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 16 styczeń 2005 Indeksowanie rozproszonych zasobów Szczególnie istotne w przypadku technologii P2P, ale nie tylko. Indeks centralny, adresujący całe zasoby rozproszonej sieci. Przykładem wykorzystania indeksów centralnych jest Napster oraz liczne motorki wyszukiwawcze takie jak Google lub AltaVista, Indeksy lokalne replikowane, trzymane przez klientów celem szybkiego zlokalizowania miejsc z interesującymi danymi. W tym przypadku duża część optymalizacji zapytania może być wykonana przez klienta zanim on wyśle zlecenia do odległych serwerów. Problem z indeksami centralnymi - zależność całości rozproszonej bazy danych od jednego miejsca. Problemy z indeksami lokalnymi replikowanymi: kłopotliwa aktualizacja indeksów możliwość powstawania niespójności wskutek opóźnień lub braku możliwości aktualizacji indeksów straty przestrzeni dyskowej

17 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 17 styczeń 2005 Statyczny schemat przetwarzania zapytań (1) 1. Klient realizuje zapytanie Z odwołujące się do danych na serwerach S1, S2,..., Sk 2. Klient dokonuje odwzorowania zapytania Z na zapytania Z1, Z2,..., Zk adresowane do serwerów S1, S2,..., Sk. Odwzorowanie wymaga znajomości lokalnych schematów danych. 3. Zapytania Z1,Z2,...,Zk są konstruowane z Z w taki sposób, aby wyniki tych zapytań W1, W2,...,Wk uzyskane z poszczególnych serwerów dały możliwość utworzenia globalnego wyniku W. 4. Zapytania Z1,Z2,...,Zk są kierowane do serwerów S1, S2,..., Sk, gdzie są wykonywane. 5. Serwery zwracają do klienta wyniki W1, W2,...,Wk zapytań Z1,Z2,...,Zk 6. Klient dokonuje scalenia wyników W1, W2,...,Wk w globalny wynik w.

18 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 18 styczeń 2005 Statyczny schemat przetwarzania zapytań (2) Dekompozycja zapytania Z Serwer S1 Serwer S2 Serwer Sk Scalenie wyników... Klient Wynik W zapytania Z Z1 Z2 Zk W1 W2 Wk Statyczny schemat ma przede wszystkim zastosowanie w przypadku poziomej fragmentacji danych, np. rozbicia obiektów Pracownik na wiele podzbiorów o takiej samej budowie przechowywanych na poszczególnych serwerach. W tym przypadku dekompozycja zapytania oznacza po prostu jego skopiowanie: Z = Z1 = Z2 =... = Zk Scalenie wyników polega na sumie mnogościowej wyników cząstkowych.

19 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 19 styczeń 2005 Dynamiczny schemat przetwarzania zapytań 1. Klient realizuje zapytanie Z odwołujące się do danych na serwerach S1, S2,..., Sk 2. Klient dokonuje odwzorowania zapytania Z na podzapytanie Z1 adresowane do serwera S1 (na podstawie schematu S1). Z1jest konstruowane z Z w taki sposób, aby jego wynik W1 uzyskany z S1 wystarczył do realizacji zapytania Z. 3. Z1jest kierowane do serwera S1, gdzie jest wykonywane. Serwer S1 zwraca do klienta wynik W1 podzapytania Z1. 4. Na podstawie znajomości W1 klient konstruuje z Z kolejne podzapytanie Z2 kierowane do serwera S2. Może do tego serwera skierować pewien fragment W1, nazwijmy go F1;.... proces jest powtarzany dla wszystkich serwerów, aż do uzyskania rezultatu. Z Z1 Serwer S1 Serwer S2 Serwer S3 Scalenie wyników Klient Z1 Z2, F1 W1 W2 W3 (Z, W1) Z2, F1 (Z, W1, W2) Z3, F2 Z3, F2

20 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 20 styczeń 2005 Technologie gridowe Grid computing jest nową wersją starego marzenia o masowej równoległości przetwarzania. Marzenie to miało wiele materializacji, większość nieudanych. Chyba największą klapę można przypisać japończykom i ich projektowi 5-tej generacji komputerów (1982-1992) – 3 miliardy dolarów utopione w programowanie w logice i inne akademickie utopie. Termin grid nawiązuje do ustawienia komputerów w siatkę (klaster). Nowy termin wzbudza nowe nadzieje i nowe środki przeznaczone na realizację starego marzenia. Wiele firm i zespołów badawczych skorzysta z tych środków. Jest to jeden z najlepszych sposobów pozyskiwania pieniędzy. Temat jest nieustannie fascynujący.

21 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 21 styczeń 2005 Równoległe przetwarzanie Nowy poziom technologiczny w dużym stopniu już tę równoległość zapewnia: Rozproszone lub federacyjne bazy danych (np. Oracle10G). Oprogramowanie komponentowe: CORBA, DCOM,.NET, EJB, RMI, J2EE+WebServices. Nowe inicjatywy, takie jak OGSA/OGSI lub Enterprise Service Bus (ESB). Sieci P2P (peer-to-peer), czyli korzystanie z zasobów udostępnianych przez poszczególnych uczestników sieci dla całej społeczności sieci. Web Services, tj. utylizacja usług dostarczanych przez odlegle serwery na gruncie standardu XML. Technologie agentowe, czyli mobilni geograficznie niewolnicy wykonujące pracę na rzecz swojego mistrza. W technologiach gridowych najbardziej istotne będą podejścia nawiązujące do koncepcji federacyjnych baz danych. Jakkolwiek geneza technologii gridowych jest oparta o zrównoleglenie obliczeń.

22 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 22 styczeń 2005 Krótka ocena Największe znaczenie mają rozproszone/federacyjne bazy danych, oprogramowanie komponentowe i P2P. Mój lekki sceptycyzm dotyczy Web Services (mimo licznych inicjatyw potencjalnych zastosowań). Ubogość koncepcji spowoduje, że będzie ona rosnąć na zasadzie piramidy postawionej na czubku. Mogą być użyte/przykryte przez bardziej konceptualne protokoły. Niejasny (naiwny?) stosunek do heterogeniczności. Nowe inicjatywy w tym zakresie, takie jak OGSA/OGSI lub Enterprise Service Bus (ESB) zdają się zmierzać w kierunku federacyjnych heterogenicznych baz danych na zasadzie rozwoju bottom-up. Mój spory sceptycyzm dotyczy agentów. Poza antropomorfizmami i pobożnymi życzeniami tam zbyt wiele nie ma. Brak kluczowych aplikacji (killer applications) pokazujących techniczny lub biznesowy sens pomysłu. Nadzieje w technologii workflow – ale czy uzasadnione?

23 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 23 styczeń 2005 Najważniejsze problemy Przezroczystość (transparency): traktowanie rozproszonych zasobów i usług tak, jak gdyby były one wewnątrz przestrzeni adresowej jednego komputera. Bezpieczeństwo (security): przeciwdziałanie losowym awariom oraz możliwościom ataku z zewnętrz. Interoperacyjność (interoperability): umożliwienie współpracy heterogenicznych platform, aplikacji, logik biznesowych i organizacji danych. Efektywność (performance, efficiency): uzyskanie czasów przetwarzania akceptowalnych dla szerokiego kręgu użytkowników rozproszonych aplikacji. Jakość usług (Quality of Service, QoS): uzyskanie odpowiednich wskaźników dostępności, niezawodności, ergonomii, itp. aspektów.

24 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 24 styczeń 2005 Architektura gridu... Klient globalny 1 Klient globalny 2 Klient globalny 3... Globalny wirtualny skład obiektów i usług Aktualizowalne perspektywy Protokół komunikacyjny Organizator gridu Informacja kontrybucyjna Schemat globalny (model kanoniczny) Schemat lokalny A Skład lokalnych obiektów i usług Serwer lokalny A Perspektywa lokalna A Schemat lokalny B Skład lokalnych obiektów i usług Serwer lokalny B Perspektywa lokalna B

25 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 25 styczeń 2005 Objaśnienie architektury (1) Linie ciągłe grube: związki między oprogramowaniem w run-time (zapytania, zlecenia, odpowiedzi). Linie i strzałki przerywane: związki definicyjne (podczas tworzenia oprogramowania). Klient globalny: program aplikacyjny wykorzystujący globalny wirtualny skład. Globalny wirtualny skład obiektów i usług: skład, do którego adresowane są zapytania i zlecenia ze strony klienta globalnego; w rzeczywistości nie istnieje. Schemat globalny: definicje obiektów i usług wirtualnych wykorzystywane (głównie) przez programistów podczas tworzenia klientów globalnych.

26 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 26 styczeń 2005 Objaśnienie architektury (2) Aktualizowalne perspektywy: oprogramowanie, którego celem jest wytworzenie globalnego wirtualnego składu. Wykorzystanie aktualizowalnych perspektyw: jako integratora wielu rozproszonych danych i serwisów jako osłon i mediatorów dla poszczególnych lokalnych serwerów. Protokół komunikacyjny: zestaw funkcji działających na odległych serwerach używanych do definicji perspektyw. Organizator gridu: osoba, zespół osób lub program definiujący perspektywy na podstawie schematów lokalnych, sch.globalnego i i informacji kontrybucyjnej. Schemat lokalny: informacja katalogowa o obiektach i usługach udostępnianych przez serwer lokalny (IDL, WSDL, ODL,...) Serwer lokalny: jednostka sprzętowa/programowa identyfikowana przez system rozproszony.

27 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 27 styczeń 2005 Informacja kontrybucyjna Określa w jaki sposób poszczególne serwery kontrybuują do globalnego wirtualnego składu obiektów. Określa redundancje w danych trzymanych na poszczególnych serwerach. Określa replikacje. Określa sposoby aktualizacji danych. Określa zależności pomiędzy poszczególnymi serwerami. Jest podstawą definicji odpowiednich perspektyw.

28 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 28 styczeń 2005 Przykład: fragmentacja pozioma Prac NIP Nazwisko Zar Stan Schemat globalny: Schematy lokalne: Informacja kontrybucyjna: Jednoznacznym identyfikatorem pracowników jest NIP. Nie występują powtórzenia NIPu w lokalnych bazach danych. Globalna baza danych jest wirtualną sumą lokalnych baz danych. Kielce Prac NIP Nazwisko Zar Stan Radom Prac NIP Nazwisko Zar Stan Kalisz Prac NIP Nazwisko Zar Stan

29 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 29 styczeń 2005 Integrująca perspektywa Ziarno obiektów wirtualnych ma postać dwóch binderów: struct{ m(adres serwera), p(OID obiektu na tym serwerze)} Nazwy Kalisz, Radom i Kielce są niewidoczne dla klientów; posługują się oni tylko nazwą MoiPrac i nazwami atrybutów, np. (MoiPrac where Nazwisko = Kolski).NIP create view MoiPracDef { virtual objects MoiPrac { return ((Kalisz as m) join (m.Prac as p)) (((Radom as m) join (m.Prac as p)) (((Kielce as m) join (m.Prac as p)) } on_retrieve do { connect (m); return p.(deref(NIP) as NIP, deref(Nazwisko) as Nazwisko, deref(Zar) as Zar, deref(Stan) as Stan) }; on_delete do { connect (m); remoteDelete (p) };... Ewentualnie dalsze części definicji perspektywy... }

30 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 30 styczeń 2005 Prac NIP Nazwisko Zar Stan Schemat globalny: Schematy lokalne: Informacja kontrybucyjna:.... jak poprzednio.... Radom i Kielce zawierają te same dane. Użytkownik powinien używać tej repliki, do której ma szybszy dostęp. Aktualizacja danych w Radomiu spowoduje tę samą aktualizację danych w Kielcach. Użytkownik nie może aktualizować danych w Kielcach. Kielce Prac NIP Nazwisko Zar Stan Radom Prac NIP Nazwisko Zar Stan Kalisz Prac NIP Nazwisko Zar Stan Przykład: fragmentacja pozioma z replikacją

31 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 31 styczeń 2005 Integrująca perspektywa create view MoiPracDef { virtual objects MoiPrac { int czasDoRadomia := 1000000; int czasDoKielc := 1000000; if alive(Radom) then czasDoRadomia := checkAccessTime(Radom); if alive(Kielce) then czasDoKielc := checkAccessTime(Kielce); if min(bag(czasDoRadomia, czasDoKielc)) > 100 then { exception(CzasRealizacjiJestNieakceptowalny); return ;} return ((Kalisz as m) join (m.Prac as p)) if czasDoRadomia < czasDoKielc then ((Radom as m) join (m.Prac as p)) else ((Kielce as m) join (m.Prac as p)) } on_retrieve do {...jak poprzednio... }; on_delete do { if serverName(m) = Kielce then { connect(Radom); remoteDelete (Prac where NIP = (p.NIP))} else { connect (m); remoteDelete (p) } } } alive, checkAccessTime, serverName, connect, remoteDelete,... – funkcje protokołu

32 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 32 styczeń 2005 Problemy do rozwiązania Zaimplementowanie aktualizowalnych perspektyw. Ustalenie i zaimplementowanie zestawu funkcji protokołu komunikacyjnego, które są niezbędne dla definicji perspektyw. Opracowanie precyzyjnego języka informacji kontrybucyjnej: Pełna formalizacja tego języka, wraz z formalizacją globalnego i lokalnych schematów, umożliwiłaby automatyczną generację perspektyw. Przypisania informacji kontrybucyjnej do pojedynczych serwerów i automatyczne uzupełnianie perspektyw na jej podstawie stworzyłoby coś w rodzaju szyny CORBA lub sieci P2P. Opracowanie systemu rejestracji danych i usług (trading service, UDDI,...) Przetwarzanie rozproszonych transakcji. Optymalizacje zmierzające do uzyskania odpowiedniego QoS, w szczególności optymalizacja rozproszonych zapytań.

33 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 33 styczeń 2005 W przedstawionej koncepcji całość przetwarzania zapytań jest po stronie klienta. Trzeba to przetwarzanie przesunąć na stronę serwera, np. poprzez przesłanie tam odpowiednich części stosów i (pod-) zapytań. Obecna koncepcja nie zakłada równoległości przetwarzania. Przesunięcie przetwarzania na stronę serwera i analiza postaci zapytania stwarzają szansę na równoległość (jest to dość łatwe dla fragmentacji poziomej, trudniejsze w ogólnym przypadku). Dekompozycja zapytań przy fragmentacji pionowej. Wykorzystanie scenariuszy dynamicznych, w których wynik przetwarzania na jednym serwerze jest wykorzystany do optymalizacji przetwarzania na innym serwerze. Obiekty i usługi proxy ulokowane wewnątrz perspektywy integrującej. Przezroczyste indeksy zasobów globalnych wykorzystywane automatycznie przez klientów i/lub perspektywy...... wiele innych optymalizacji... Optymalizacje

34 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 34 styczeń 2005 Podsumowanie (1) Globalizacja przestrzeni informacyjnej powoduje nacisk na tworzenie rozproszonych i federacyjnych baz danych, które umożliwiłyby tworzenie aplikacji globalnych, działających na zestawie dziesiątków, tysięcy lub milionów lokalnych BD. Połączenie tych lokalnych baz danych siecią komputerową stwarza niezbędną infrastrukturę techniczną, ale nie rozwiązuje ogromnej ilości problemów koncepcyjnych, których część została omówiona na tym wykładzie. Pewna część problemów jest rozwiązana dla rozproszonych relacyjnych baz danych. Rozproszone obiektowe bazy danych znajdują się na początku drogi. Niektóre problemy, takie jak: przetwarzanie globalnych transakcji, aktualizowalne perspektywy, rozstrzyganie niezgodności schematów, akceptowalna wydajność globalnych aplikacji, itd., prawdopodobnie nie mają ogólnego rozwiązania. Pozostają nadzieje na rozwiązania cząstkowe.

35 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 13, Folia 35 styczeń 2005 Podsumowanie (2) Problemy rozproszenia są skutkiem spadku pozostawionego nam przez naszych poprzedników. Znaczna część problemów może rozwiązać się sama poprzez rezygnację ze spadku, tj. poprzez wymarcie kłopotliwych SZBD i powstanie nowych SZBD, lepiej przystosowanych do tworzenia rozproszonych federacji. Konieczna jest standardyzacja: w zakresie modeli danych w zakresie ontologii biznesowej i metamodeli w zakresie wymiany danych w zakresie API realizującego dostęp do do danych, w szczególności języków zapytań Konieczne są dalsze prace badawcze i wdrożeniowe w zakresie przetwarzania i optymalizacji rozproszonych obiektowych zapytań, protokołów dostępu, obiektowych perspektyw, ontologii, metamodeli, formatów wymiany danych, rozproszonych transakcji, itd.