Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

© K.Subieta.Systemy rozproszone 3, Folia 1 styczeń 2005 Systemy rozproszone (SYR) Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych,

Podobne prezentacje


Prezentacja na temat: "© K.Subieta.Systemy rozproszone 3, Folia 1 styczeń 2005 Systemy rozproszone (SYR) Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych,"— Zapis prezentacji:

1 © K.Subieta.Systemy rozproszone 3, Folia 1 styczeń 2005 Systemy rozproszone (SYR) Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Instytut Podstaw Informatyki PAN, Warszawa Wykład 3: Projektowanie i architektury rozproszonych baz danych

2 © K.Subieta.Systemy rozproszone 3, Folia 2 styczeń 2005 Podejścia do projektowania rozproszonych BD: top-down i bottom-up Od ogółu do szczegółów (top-down): Odgórne zaprojektowanie całej bazy danych, z uwzględnieniem optymalizacji przechowywanych danych, narzuconej przez fakt geograficznego rozproszenia producentów i konsumentów informacji przechowywanej w bazie danych. Od szczegółów do ogółu (bottom-up): Zintegrowanie już istniejących (spadkowych) lub zaprojektowanych lokalnych baz danych w jedną globalną rozproszoną bazę danych.

3 © K.Subieta.Systemy rozproszone 3, Folia 3 styczeń 2005 Projektowanie: podejście top-down Analiza systemowa: rozpoznanie wymagań, precyzowanie kontekstu przyszłej bazy danych. Projektowanie schematu pojęciowego 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 Analiza Model pojęciowy scentralizowany Model logiczny scentralizowany Kryteria rozproszenia Modele logiczne dla poszczególnych miejsc

4 © K.Subieta.Systemy rozproszone 3, Folia 4 styczeń 2005 Dalsze fazy postępowania w podejściu top-down 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 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ł schematu logicznego: Wg różnych reguł związanych na ogół z fizycznym ulokowaniem obiektów rzeczywistych (np. osób zatrudnionych, sprzętu, co pociąga za sobą odpowiedni podział schematu logicznego) lub też z fizycznym ulokowaniem programów aplikacyjnych działających na tych obiektach.

5 © K.Subieta.Systemy rozproszone 3, Folia 5 styczeń 2005 Podstawowe metody fragmentacji schematu Fragmentacja pionowa oznacza przyporządkowanie poszczególnych klas obiektów do poszczególnych miejsc, lub rozbicie obiektów danej klasy na dwa lub więcej podobiektów, przy czym takie podobiekty są przechowywane w różnych miejscach. Fragmentacja pionowa może oznaczać konieczność odpowiedniego podziału informacji zawartych w klasach obiektów oraz ustalenia środków podtrzymania jednoznacznej tożsamości obiektów. Fragmentacja pozioma oznacza rozbicie populacji obiektów danej klasy na dwa lub więcej miejsc geograficznych. Fragmentacja pozioma może być dokonywana na podstawie różnych kryteriów, które często wiązane są z geograficznym ulokowaniem obiektów rzeczywistych, lub też z geograficznym ulokowaniem przetwarzania tych obiektów.

6 © K.Subieta.Systemy rozproszone 3, Folia 6 styczeń 2005 Fragmentacja pionowa relacyjnej bazy danych DOSTAWCA_DANE DNR D1 D2 D3 D4 D5 NAZW Abacki Bober Czerny Dąbek Erbel STATUS DC DNR D1 D2 D3 D4 CNR C1 C2 C3 C4 C5 C6 C1 C2 C4 C5 ILOŚĆ Warszawa DOSTAWCA_MIASTO DNR D1 D2 D3 D4 D5 MIASTO Lublin Poznań Lublin Radom Gdańsk Kutno Sieć

7 © K.Subieta.Systemy rozproszone 3, Folia 7 styczeń 2005 Fragmentacja pozioma relacyjnej bazy danych DOSTAWCA DNR D2 D3 NAZW Bober Czerny STATUS MIASTO Poznań DC DNR D2 D3 CNR C1 C2 ILOŚĆ Poznań DOSTAWCA DNR D1 D4 NAZW Abacki Dąbek STATUS 20 MIASTO Lublin DC DNR D1 D4 CNR C6 C2 C4 ILOŚĆ Lublin DOSTAWCA DNR D5 NAZW Erbel STATUS 30 MIASTO Radom Sieć

8 © K.Subieta.Systemy rozproszone 3, Folia 8 styczeń 2005 Fragmentacja pionowa obiektów Pracownik Radom Klasa danych osobistych Nowak dane osobiste Kowalski dane osobiste... Kalisz Klasa danych o ocenach Nowak dane o ocenach Kowalski dane o ocenach... Kraków Klasa danych o zatrudnieniu Nowak dane o zatrud. Kowalski dane o zatrud.... Sieć

9 © K.Subieta.Systemy rozproszone 3, Folia 9 styczeń 2005 Fragmentacja pozioma obiektów Pracownik Radom Klasa Pracownik Pracownik Nowak Pracownik Kowalski... Kraków Pracownik Malasa Pracownik Zagórny.... Sieć Kalisz Pracownik Styka Pracownik Malina... Klasa Pracownik Obiekty Pracownik są przechowywane zgodnie z geograficznym położeniem pracodawcy.

10 © K.Subieta.Systemy rozproszone 3, Folia 10 styczeń 2005 Inne fragmentacje danych w rozproszonej BD Możliwe są inne, bardziej złożone fragmentacje danych, które łączą fragmentacje pionowe, fragmentacje poziome oraz redundantne dane (replikacje). Bardziej złożone fragmentacje rodzą trudności z: zarządzaniem metadanymi: gdzieś muszą być ulokowane informacje odnośnie tego w jaki sposób podzielone dane mają być scalone w kompletne obiekty lub kolekcje w ramach rozproszonej bazy danych. Jest to rola metadanych oraz mechanizmu właściwej dystrybucji metadanych pomiędzy uczestników rozproszonej bazy danych. przetwarzaniem zapytań: dekompozycja zapytania na pod-zapytania adresowane do poszczególnych miejsc staje się znacznie bardziej kłopotliwa. Przesyłanie fragmentów obiektów celem ich zmaterializowania po stronie klienta może być zbyt kosztowne. Bardziej złożone fragmentacje mogą być nie do uniknięcia w rozproszonej bazie danych integrującej istniejące bazy danych (podejście bottom-up). Ma to konsekwencje dla zarządzania metadanymi.

11 © K.Subieta.Systemy rozproszone 3, Folia 11 styczeń 2005 Projektowanie: podejście bottom-up Podejście ad hoc: Budowa uniwersalnych lub specyficznych dla danego zastosowania pomostów (gateways) umożliwiających dostęp z danego systemu bazy danych do innych baz danych. Pomost może (nie musi) zapewniać przezroczystość rozproszenia. Podejście oparte o globalny schemat: Wszystkie składniki rozproszonej BD są objęte jednym globalnym schematem, jednakowym dla każdego miejsca i zapewniającym przezroczystość rozproszenia. Istotną wadą podejścia opartego na globalnym schemacie jest brak możliwości sterowania zakresem autonomii każdego lokalnego systemu. Federacyjna baza danych: Każda lokalna baza danych zachowuje swoją autonomię, udostępniając tylko część danych dla innych miejsc w RBD. Podejście federacyjne zakłada, że każda lokalna baza danych jest widziana poprzez pewną perspektywę (view), ukrywającą niektóre dane dla rozproszonych aplikacji.

12 © K.Subieta.Systemy rozproszone 3, Folia 12 styczeń 2005 Baza danych 1 Miejsce 1 Schemat lokalny 1 Aplikacje lokalne Baza danych 2 Miejsce 2 Schemat lokalny 2 Aplikacje lokalne Federacyjna BD tworzona metodą bottom-up Schemat federacyjnej bazy danych Podejście federacyjne okazało się skuteczne ze względu na zapewnienie autonomii, bezpieczeństwa i efektywności. Rodzi jednak dużo problemów, m.in. z zapewnieniem jednolitej ontologii biznesowej, uniwersalnością aplikacji, wydajnością, itd. Perspektywa Mediator Osłona Perspektywa Mediator Osłona Aplikacje globalne.....

13 © K.Subieta.Systemy rozproszone 3, Folia 13 styczeń 2005 Architektura klient-serwer Całość pracy wykonywanej przez system komputerowy jest podzielona na dwie części: wykonywaną po stronie klienta (zwykle związaną z interakcją z użytkownikiem) wykonywaną po stronie serwera (komunikacja, dostęp do bazy danych, zarządzanie repozytoriami pamięci, zarządzanie globalną przestrzenią nazw) Określenie mechanizmu komunikacji pomiędzy klientem a serwerem. Określenie jednostki komunikacji klient - serwer Podział funkcji na te, które są wykonywane po stronie klienta i te, które są wykonywane po stronie serwera Podstawowe problemy:

14 © K.Subieta.Systemy rozproszone 3, Folia 14 styczeń 2005 Reguły architektury klient-serwer (1) Zachowanie autonomii serwera. Klienci powinni zachowywać reguły wykorzystania serwera, nie powinni powodować jego niedostępność (np. zamykać duże ilości danych), nie powinni łamać ograniczeń integralności. Zachowanie autonomii klienta. Klienci nie powinni zachowywać się różnie w zależności od tego, czy serwer jest lokalny czy odległy. Powinni być odizolowani od kwestii fizycznego ulokowania danych. Wspomaganie dla aplikacji niezależnych od serwera. Dostęp do własności (danych, usług) serwera. Klienci mogą żądać od serwera wykonanie przewidzianych dla niego funkcji. Wspomaganie dla bieżącego dostępu do danych. Dostęp ten powinien być bezpośredni, bez pośrednictwa plików przekazywanych do/od klienta. Minimalny wpływ architektury K/S na wymagania dla klienta. Oprogramowanie klienta w architekturze K/S nie powinno wykazywać znacznego zwiększenia zapotrzebowania na RAM lub objętość dysku.

15 © K.Subieta.Systemy rozproszone 3, Folia 15 styczeń 2005 Reguły architektury klient-serwer (2) Kompletność opcji niezbędnych do połączenia. Oprogramowanie klienta nie powinno zawierać kodu realizującego połączenie z serwerem.Powinien to zapewniać serwer komunikacyjny. Możliwość budowy lokalnych prototypów. Programista powinien mieć możliwość budowy i testowania aplikacji K/S wyłącznie na stacji klienta. Kompletność narzędzi użytkownika końcowego. Projektowanie ekranów, generacja zapytań, itd. powinny być częścią środowiska. Kompletność środowiska budowy aplikacji. Powinno przewidywać możliwość łączenia się w sieci, dostęp do usług globalnych w zakresie nazw, lokacji danych, itd. Otwarte środowisko języka-gospodarza. Powinno zapewniać możliwość użycia uniwersalnego języka programowania do budowy aplikacji. Szczególna troska o standardy. Im bardziej będą one przestrzegane, tym mniej będzie późniejszych kłopotów ze współdziałaniem.

16 © K.Subieta.Systemy rozproszone 3, Folia 16 styczeń 2005 Przykład architektury SZBD typu klient-serwer Aplikacja generująca transakcje Zarządzanie transakcjami Zarządzanie buforami Zarządzanie zasobami Klient 1 Aplikacja generująca transakcje Zarządzanie transakcjami Zarządzanie buforami Zarządzanie zasobami Klient n Zarządzanie siecią... Interfejs serwera Zarządzanie transakcjami Zarządzanie buforami Zarządzanie zasobami Serwer Zarządzanie logiem Zarządzanie zamkami

17 © K.Subieta.Systemy rozproszone 3, Folia 17 styczeń 2005 Architektura klient-(multi) serwer (1) s1 s2 s3 s4 k6 k5 k4 k3 k2 k1 k10 k9 k8 k7 k11 Połączenia bezpośrednie:

18 © K.Subieta.Systemy rozproszone 3, Folia 18 styczeń 2005 Architektura klient-(multi) serwer (2) s1 s2 s3 s4 k6 k5 k4 k3 k2 k1 k9 k8 k7 Połączenia poprzez sieć: nie ma bezpośrednich połączeń, zarówno serwery jak i klienci są przyłączani w jednakowy sposób do wspólnej sieci komputerowej. Sieć komputerowa

19 © K.Subieta.Systemy rozproszone 3, Folia 19 styczeń 2005 Architektura trzywarstwowa i wielowarstowa three-tier architecture Interfejs użytkownika Serwer bazy danych Serwer bazy danych multi-tier architecture Logika przetwarzania Architektura klient-serwer podzielona na trzy warstwy: interfejs użytkownika, logikę przetwarzania (reguły biznesu, logikę biznesu) serwer (serwery) bazy danych. Warstwy są zaprojektowane i istnieją niezależnie, co ma duże znaczenie dla pielęgnacyjności systemu ze względu na możliwość zmian w dowolnej warstwie bez konieczności zmian w pozostałych warstwach. Często warstwy są zrealizowane na odrębnych platformach: interfejs na MS Windows, logika przetwarzania na serwerze aplikacji i baza danych na serwerze bazy danych. Środkowa warstwa może składać się z wielu warstw, co jest określane jako architektura wielowarstwowa.

20 © K.Subieta.Systemy rozproszone 3, Folia 20 styczeń 2005 Logiczna architektura oprogramowania Architektura klient-serwer powinna odzwierciedlać logiczny podział oprogramowania na części. Nie jest to tak istotne w systemie scentralizowanym. Warstwa prezentacyjna (interfejs użytkownika) Warstwa prezentacyjna (interfejs użytkownika) Warstwa zarządzania bazą danych Architektura trójwarstwowa: Warstwa przetwarzania (logika biznesu) Warstwa przetwarzania (logika biznesu) Staranne rozdzielenie tych warstw jest bardzo istotne z punktu widzenia tworzenia i modyfikowalności oprogramowania. Dzięki temu rozdzieleniu, możliwa jest np. poprawa interfejsu użytkownika bez jakichkolwiek interwencji w pozostałe warstwy oprogramowania. Zasada oddzielania aspektów (separation of concerns principle, E.Dijkstra) cienki klient gruby klient

21 © K.Subieta.Systemy rozproszone 3, Folia 21 styczeń 2005 Cienki i gruby klient Terminy cienki klient (thin client) oraz gruby klient (fat client) odnoszą się do mocy i jakości przetwarzania po stronie klienta w architekturze klient-serwer. Model cienkiego klienta: klient posiada niezbyt wielką moc przetwarzania, ograniczoną do prezentacji danych na ekranie. Przykładem jest klient w postaci przeglądarki WWW. Model grubego klienta: klient posiada znacznie bogatsze możliwości przetwarzania, w szczególności może zajmować się nie tylko warstwą prezentacji, lecz także warstwą przetwarzania aplikacyjnego (logiki biznesu). Powyższy podział posiada oczywiście pewną gradację. Model cienkiego klienta jest najczęstszym rozwiązaniem w sytuacji, kiedy system scentralizowany jest zamieniany na architekturę klient-serwer. Wadą jest duże obciążenie serwera i linii komunikacyjnych. Model grubego klienta używa większej mocy komputera klienta do przetwarzania zarówno prezentacji jak i logiki biznesu. Serwer zajmuje się tylko obsługą transakcji bazy danych. Popularnym przykładem grubego klienta jest bankomat. Zarządzanie w modelu grubego klienta jest bardziej złożone.

22 © K.Subieta.Systemy rozproszone 3, Folia 22 styczeń 2005 Architektury dwuwarstwowe Uproszczone architektury trójwarstwowe z cienkim lub grubym klientem. Warstwa prezentacyjna (interfejs użytkownika) Warstwa prezentacyjna (interfejs użytkownika) Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych cienki klient Warstwa prezentacyjna (interfejs użytkownika) + Warstwa przetwarzania (logika biznesu) Warstwa prezentacyjna (interfejs użytkownika) + Warstwa przetwarzania (logika biznesu) gruby klient Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych W tym modelu przetwarzanie (logika biznesu) jest dzielone pomiędzy klienta i serwera. Zaprojektowanie jej jest trudniejsze.

23 © K.Subieta.Systemy rozproszone 3, Folia 23 styczeń 2005 Bankomat Serwer kont klientów banku Monitor tele-przetwarzania Baza danych kont klientów banku Oprogramowanie pośredniczące organizujące komunikację z odległymi klientami i szeregujące transakcje klientów celem przetwarzania ich przez bazę danych. Przykład architektury K/S - sieć bankomatów

24 © K.Subieta.Systemy rozproszone 3, Folia 24 styczeń 2005 klient Serwer Web: generacja dynamicznych stron HTML dla klienta + zlecenia do bazy danych Serwer Web: generacja dynamicznych stron HTML dla klienta + zlecenia do bazy danych Serwer bazy danych: wykonywanie zapytań w SQL Serwer bazy danych: wykonywanie zapytań w SQL zapytania SQL wyniki zapytań SQL interakcja poprzez HTTP Przykład architektury K/S - portal WWW

25 © K.Subieta.Systemy rozproszone 3, Folia 25 styczeń warstwowa architektura aplikacji Web Przeglądarka Sieć Internet Baza danych Serwer bazy danych Serwer Web Serwer aplikacji Serwer HTTP

26 © K.Subieta.Systemy rozproszone 3, Folia 26 styczeń warstwowa architektura aplikacji Web Przeglądarka Sieć Internet Baza danych Serwer bazy danych Serwer Web Serwer aplikacji Serwer HTTP Wiele warstw pośredniczących powoduje dodatkowe obciążenie.

27 © K.Subieta.Systemy rozproszone 3, Folia 27 styczeń 2005 Zastosowanie różnych architektur K/S Dwuwarstwowa architektura K/S z cienkim klientem Systemy spadkowe (legacy), gdzie oddzielenie przetwarzania i zarządzania danymi jest niepraktyczne. Aplikacje zorientowane na obliczenia, np. kompilatory, gdzie nie występuje lub jest bardzo mała interakcja z bazą danych. Aplikacje zorientowane na dane (przeglądanie i zadawanie pytań) gdzie nie występuje lub jest bardzo małe przetwarzanie. Dwuwarstwowa architektura K/S z grubym klientem Aplikacje w których przetwarzanie jest zapewnione przez wyspecjalizowane oprogramowanie klienta, np. MS Excel. Aplikacje ze złożonym przetwarzaniem (np. wizualizacją danych, przetwarzaniem multimediów). Aplikacje ze stabilną funkcjonalnością dla użytkownika, użyte w środowisku z dobrze określonym zarządzaniem. Trzywarstwowa lub wielowarstwowa archiktektura K/S Aplikacje o dużej skali z setkami lub tysiącami klientów. Aplikacje gdzie zarówno dane jak i aplikacje są ulotne (zmienne). Aplikacje integrujące dane z wielu rozproszonych źródeł.

28 © K.Subieta.Systemy rozproszone 3, Folia 28 styczeń 2005 Architektura rozproszonych obiektów (1) W architekturze klient-serwer istnieje wyraźna asymetria pomiędzy klientem i serwerem; w szczególności, nie występuje tam komunikacja bezpośrednio pomiędzy klientami. Model taki dla wielu zastosowań jest mało elastyczny i zapewnia zbyt małą skalowalność. Architektura rozproszonych obiektów znosi podział na klientów i serwery. Każde miejsce w rozproszonym systemie jest jednocześnie klientem i serwerem. Konieczne jest sprowadzenie wszystkich danych i usług do jednego standardu. Taki standard obejmuje: Model (pojęciowy i logiczny) danych i usług, który jest w stanie "przykryć" wszystkie możliwe dane i usługi, które mogą kiedykolwiek pojawić się w systemie rozproszonym; Specjalne oprogramowanie zwane pośrednikiem (broker), które akceptuje wspólny model danych i usług umożliwiając ich udostępnienie dla dowolnych miejsc w systemie rozproszonym. Specjalne oprogramowanie, zwane osłoną, adapterem lub mediatorem, które przystosowuje konkretne miejsce do modelu przyjętego przez pośrednika.

29 © K.Subieta.Systemy rozproszone 3, Folia 29 styczeń 2005 Pośrednik... Szyna oprogramowania (software bus) Miejsce 1Miejsce 2Miejsce 3 Osłona 1 Osłona 2Osłona 3 Aplikacja napisana w C++ Aplikacja na relacyjnej bazie danych Aplikacja na Lotus Notes Architektura rozproszonych obiektów (2)

30 © K.Subieta.Systemy rozproszone 3, Folia 30 styczeń 2005 Operacje na obiektach Struktura logiczna rozproszonych obiektów O6 O5 O3 O2 O1 O4 O7 O8 O9 K1 K2 K3 K4 Obiekty Szyna oprogramowania tworzy jedną przestrzeń obiektów. Obiekty te są dostępne dla dowolnego miejsca poprzez operacje (zgrupowane w klasach). Miejsca i sposoby implementacji obiektów są niewidoczne. Aplikacje korzystają z całej puli obiektów. Szyna oprogramowania (software bus) A1A2A3 Aplikacje

31 © K.Subieta.Systemy rozproszone 3, Folia 31 styczeń 2005 Architektura serwera stron strony Zarządzanie zamkami Zarządzanie składem Zarządzanie kieszenią stron Obiektowa baza danych Aplikacja Przeglądarka obiektów Interfejs zapytaniowy Optymalizacja zapytań Interfejs programistyczny Zarządzanie obiektami Zarządzanie plikami i indeksami Zarządzanie kieszenią stron Przedmiotem zarządzania są fizyczne strony dyskowe

32 © K.Subieta.Systemy rozproszone 3, Folia 32 styczeń 2005 Architektura serwera obiektów obiekty Zarządzanie obiektami Optymalizacja zapytań Zarządzanie zamkami Zarządzanie składem Zarządzanie stronami i kieszeniami Obiektowa baza danych Aplikacja Przeglądarka obiektów Interfejs zapytaniowy Interfejs programistyczny Zarządzanie obiektami Przedmiotem zarządzania są obiekty

33 © K.Subieta.Systemy rozproszone 3, Folia 33 styczeń 2005 Przyszłościowa architektura aplikacji internetowych Logiczna warstwa pośrednia Zasoby danych Warstwa klienta XML Przeglądarka WWW Przeglądarka WWW Serwer Web Serwer aplikacji Globalny wirtualny skład zasobów usług i danych Interakcja z aplikacjami poprzez protokoły oparte na XML Obiektowo- relacyjna baza danych Obiektowa baza danych Inne dokumenty na Webie: HTML, Word,... Dokumenty XML na Webie Relacyjna baza danych XML-owa baza danych Serwisy lokalne Zasoby usług i danych wrappery Web Services Aplikacja globalna Warstwa aplikacji globalnych

34 © K.Subieta.Systemy rozproszone 3, Folia 34 styczeń 2005 Standardy łączenia rozproszonych danych (1) Open DataBase Connectivity (ODBC): standard [zdalnego] dostępu do relacyjnych baz danych bazuje na Call Level Interface (CLI) opracowanym przez konsorcjum X/Open definiuje API oraz cechy SQL które muszą być zapewnione na różnych poziomach zgodności. Java DataBase Connectivity (JDBC): analogiczny do ODBC standard dla Java. OLE-DB: API podobne do ODBC, ale wspomagające źródła nie- bazodanowe, takie jak płaskie pliki. OLE-DB program może negocjować ze źródłem danych aby znaleźć własności, które ono podtrzymuje. API jest podzbiorem SQL ADO (Active Data Objects): łatwy interfejs do funkcji OLE-DB

35 © K.Subieta.Systemy rozproszone 3, Folia 35 styczeń 2005 Standardy łączenia rozproszonych danych (2) Kilka standardów bazujących na XML dla E-commerce Np. RosettaNet (łańcuchy dostaw), BizTalk Definiują katalogi, opisy usług, faktury, zamówienia, itd. osłony XML są używane do eksportu informacji z relacyjnej BD do XML Resource Description Framework (RDF): specyfikacja ontologii dla zasobów Web. Web Services i Simple Object Access Protocol (SOAP): bazujący na XML standard dla zdalnego wołania usług. SOAP jest mniej elastyczny i uniwersalny w stosunku do CORBA. Używa XML do zakodowania danych, HTTP jako protokołu transportowego Kilka dalszych standardów: WSDL (opis danych i usług), UDDI (rejestry usług), itd. Dalsze standardy są oparte na SOAP dla specyficznych aplikacji, np. OLAP i Data Mining (standardy Microsoft'u)

36 © K.Subieta.Systemy rozproszone 3, Folia 36 styczeń 2005 Standardy łączenia rozproszonych danych (3) Object Data Management Group (ODMG) standard obiektowych baz danych jest raczej używany hasłowo, nie jest znana całościowa implementacja. OMG CORBA (Common Object Request Broker Architecture) - najbardziej uniwersalny standard obejmujący ogromną liczbę aspektów. W szczególności, notacja UML jest jego składową. Pakiety ORB (Object Request Broker) są oprogramowaniem realizującym tę architekturą..NET/DCOM (Distributed Component Object Model) - standard Microsoftu zintegrowany z systemami operacyjnymi Microsoftu. Ograniczony w stosunku do standardu CORBA. RMI (Remote Method Invocation) - oprogramowanie firmy Sun, ograniczone w stosunku do standardu CORBA do oprogramowania pisanego w Java. Java Beans i Enterprise Java Beans wykorzystują RMI jako transport.


Pobierz ppt "© K.Subieta.Systemy rozproszone 3, Folia 1 styczeń 2005 Systemy rozproszone (SYR) Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych,"

Podobne prezentacje


Reklamy Google