pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 3
w
Koordynacja wymiany danych w środowisku P2P
da
.b
w
w
Streszczenie. W pracy analizujemy problemy zarządzania danymi związane
z nową klasą systemów informatycznych jaką są aplikacje internetowe
budowane w środowisku P2P w technologii usług sieciowych WebService.
Omawiamy architekturę uwzględniającą zarówno lokalną bazę danych
poszczególnego serwisu, jak i dane udostępniane przez serwisy z nim
współpracujące. Dyskutujmy możliwość opisanie zależności między bazami
danych różnych serwisów za pomocą formuł koordynacyjnych i
zastosowanie tych formuł do koordynowania wymiany danych. Omawiamy
możliwości wykorzystania technologii SOA do implementacji takich
systemów.
1 Wprowadzenie
pl
s.
Rozwój aplikacji internetowych, głównie usług sieciowych WebService, stwarza nowe
możliwości realizacji systemów baz danych. System bazy danych może stać się aktywnym
uczestnikiem współpracujących ze sobą systemów (serwisów). Istotnym problemem staje
się wówczas problem automatycznej wymiany danych między systemami. Wymiana taka
konieczna jest na przykład wtedy, gdy jeden z systemów uzupełnia swoje dane o
informacje pamiętane w innym systemie, gdy dane zbierane w jednym systemie muszą być
przekazywane według ustalonej strategii do innego systemu lub gdy powstaje problem
uzgadniania niespójnych danych [2].
Zarysowana powyżej wymiana danych jest obecnie realizowana głównie poprzez
techniki replikacji danych [5]. Replikacja danych możliwa jest jednak tylko wtedy, gdy
bazy danych znajdują się pod nadzorem zaawansowanych serwerów baz danych, takich jak
Oracle, MS SQL Server czy Sybase. Wielu współczesnych aplikacji korzystających z baz
danych nie jest jednak opartych na tak zaawansowanych serwerach. Często też nie ma
potrzeby ustalania tak ścisłych powiązań między aplikacjami, jak ma to miejsce w
przypadku systemów replikacji. W wielu przypadkach pożądane jest ustalanie luźnych
powiązań, które mogą podlegać dynamicznym zmianom i rekonfigurowaniu. Szanse na
realizację takiej koncepcji daje zastosowanie architektury przetwarzania P2P (peer-topeer), zamiast tradycyjnej architektury klient-serwer, oraz usług sieciowych WebService
Piotr Tarłowski, Tadeusz Pankowski: Politechnika Poznańska, Instytut Automatyki
i Inżynierii Informatycznej, pl. M. Skłodowskiej-Curie 5, 60-965 Poznań,
Tadeusz Pankowski, Uniwersytet im. Adama Mickiewicza, Wydział Matematyki
i Informatyki, ul. Umultowska 87, 61-614 Poznań
email: {piotr.tarlowski | tadeusz.pankowski}@put.poznan.pl
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
P. Tarłowski, T. Pankowski
w
[2], [7]. Wizję takich systemów przedstawiono w [2], a jej rozwinięciem są bazy danych
P2P (partnerskie bazy danych) [1], [15], [10], [11].
W tym rozdziale rozważamy problemy związane z tworzeniem klasy systemów luźno
powiązanych aplikacji, które wymieniają między sobą dane w środowisku P2P i zbudowane są z wykorzystaniem technologii usług sieciowych WebService. Koncentrujemy się przy
tym na problemie koordynacji wymiany danych. Zakładamy, że w środowisku
współpracujących ze sobą systemów powinna być możliwość definiowania, pamiętania i
zarządzania danymi opisującymi reguły koordynacyjne, określające sposób i zakres
wymienianych danych [2]. Reguły te mogą również stanowić swego rodzaju warunki
spójności danych w całym systemie.
Rozwój sieci P2P wpływa na różne dziedziny, takie jak: sieci komputerowe, systemy
rozproszone, systemy informacyjne czy bazy danych. P2P jest oparta na koncepcji
decentralizacji i swobodnej wymianie zasobów, a więc jest alternatywą dla architektury
klient-serwer. Dzięki unikaniu centralnych serwerów (będących często wąskim gardłem
sieci) i podział obciążenia, możliwe jest rozproszenie aplikacji w globalnej skali. P2P
stanowi model komunikacji w sieci komputerowej, który gwarantuje obydwu stronom
równorzędne prawa.
Użycie paradygmatu P2P jako praktycznego podejścia dla rozwijających się
skalowalnych aplikacji nie było wynikiem badań naukowych, ale rezultatem starań grona
zwykłych użytkowników Internetu. Popularność sieci P2P rozpoczęła się od systemów
współdzielenia plików (zwłaszcza muzycznych), takich jak początkowo Napster, a
następnie np. Kaaza. Właśnie ogromny sukces tych systemów miał wpływ na późniejsze
badania nad możliwościami wykorzystania P2P także w innych dziedzinach.
Skupienie się rozwoju sieci P2P na współdzieleniu i wymianie plików było przyczyną
zainteresowania się tą dziedziną projektantów baz danych.
W punkcie 2 przedstawiamy szerzej motywację prowadzonych prac. Problem i
proponowane rozwiązanie koordynacji wymiany danych omawiamy w punkcie 3.
Możliwość zastosowania technologii usług sieciowych do realizacji omawianych koncepcji
w środowisku P2P dyskutujemy w punkcie 4. Punkt 5 podsumowuje pracę.
da
.b
w
w
2 Wymiana danych w środowisku P2P
pl
s.
P2P składa się z otwartej sieci rozproszonych aplikacji sieciowych partnerów (ang. peer),
gdzie każda aplikacja może wymieniać dane i usługi ze zbiorem innych aplikacji,
tworzących zbiór jego znajomych (ang. acquaintances) [2]. Zakłada się, że aplikacje są w
pełni autonomiczne w wyborze swoich znajomych. Ponadto zakłada się, że nie ma kontroli
w formie globalnych rejestrów, usług, ani globalnego zarządzania zasobami.
Dane pamiętane w różnych bazach danych mogą mieć semantyczną współzależność.
Związki te mogą być wyrażane za pomocą formuł koordynacyjnych określających sposób
powiązań aplikacji z jego znajomymi. Przykładem takich powiązań jest aplikacja (serwis)
lekarza rodzinnego i serwis apteki. Serwisy te mogą koordynować informacje o pacjencie,
o otrzymanych przez niego receptach i wykupionych lekach. Wynikiem takiej koordynacji
jest wzajemne przekazanie sobie informacji, w najprostszym przypadku przekazanie
uaktualnień do relacji Recepta i Lekarstwo istniejących w obu bazach. Można rozważyć
także bardziej złożony przypadek realizacji zapytań (usług), wymagający dekompozycji
poleceń i odwoływania się do kolejnych znajomych.
Formuły koordynacyjne wymuszają spójność danych i propagację uaktualnień.
Dodatkowo aplikacje wymagają znajomości protokołu wymiany i ustalenia poziomu
38
w
koordynacji między nimi. Poziom koordynacji powinien być dynamiczny, co oznacza, że
zestaw formuł koordynacyjnych może się zmieniać w zależności od tego, czy powiązania
między parami są luźne, zacieśniają się, czy są w ogóle likwidowane (z powodu zmiany
zainteresowań i zadań poszczególnych aplikacji).
Przy tak dynamicznych zmianach nie można przyjąć istnienia globalnego schematu dla
wszystkich baz danych w sieci P2P, a nawet dla wszystkich znajomych baz danych. Co
więcej, zmiany te oznaczają, że partnerzy powinni mieć możliwość wzajemnej integracji
przy minimalnej interwencji człowieka.
Mamy więc do czynienia ze środowiskiem dynamicznym i rozszerzalnym. Partnerzy
mogą wchodzić i wychodzić z systemu. Partner wchodząc do systemu wnosi swoje dane,
swoje schematy oraz odwzorowania między schematami swoimi i swoich partnerów. W ten
sposób dynamicznie kształtuje się sieć semantycznie powiązanych ze sobą systemów
współpracujących w procesach integracji i wymiany danych [1], [10], [13], [15]. Wymiana
danych między partnerami wiąże się z problemami koordynacji tej wymiany oraz integracji
danych w procesie wymiany [3], [8], [9], [12].
w
w
3 Problemy koordynacji wymiany danych
da
.b
Federacje i multi-bazowe systemy są zazwyczaj traktowane jako rozszerzenia
konwencjonalnych baz danych [6], [14]. Formalizacje modelu relacyjnego nie stosują się
jednak do rozszerzeń, w których istnieją bazy danych niezgodne i operujące różnymi
poleceniami. Dla rozwiązania tego problemu w [2] wprowadza się pojęcie lokalnego
modelu relacyjnego (LMR) jako modelu danych przeznaczonego dla aplikacji P2P. LMR
zakłada, że zbiór wszystkich danych w sieci P2P składa się z lokalnych (relacyjnych) baz
danych. Każda z baz zawiera zbiór znajomych, który definiuje topologię sieci P2P. Między
każdą parą partnerów definiowane są odwzorowania pozwalające na transformację danych,
przy czym odwzorowania te powinny być odkrywane automatycznie na podstawie
dostępnych metadanych, takich jak schematy czy ontologie [10], [11], [15]. Bardziej
złożone zależności semantyczne między danymi w różnych bazach danych mogą być
definiowane za pomocą tzw. formuł koordynacyjnych [2].
Rozważając koordynację wymiany danych w środowisku P2P wróćmy do przykładu
bazy pacjentów. Przykład formuły koordynacyjnej określonej między bazą danych
NowakBD lekarza rodzinnego i bazą danych CefarmBD apteki:
pl
s.
∀Pesel, Nazwisko, Adres, IdRec, Lek, Data. (NowakBD:
Pacjent(Pesel,Nazwisko,Adres) ∧
Recepta(PESEL,IdRec,Lek,Data) →
CefarmBD: ∃DataSP, Wartość. Sprzedaż(Pesel,Nazwisko,IdRec,Lek,DataSp,Wartość)
Formuła ta specyfikuje sposób aktualizacji danych w aptece zgodnie z aktualizacją
danych w bazie lekarza rodzinnego.
Semantyczna współzależność pomiędzy lokalnymi bazami danych wyrażona jest w
języku deklaratywnym, niezależnym od języków używanych przez te bazy.
Formuły koordynacyjne mogą być użyte na dwa sposoby. Po pierwsze, mogą być użyte
do definiowania ograniczeń, które muszą zostać spełnione przez zbiór relacji. Na przykład,
formuła
∀ 1:x. (1: p(x) ∨ 2:q(x))
39
w
mówi, że każdy obiekt w bazie danych 1 albo jest w tablicy p albo odpowiadający mu
obiekt w bazie danych 2 jest w tablicy q. W ten sposób można deklarować, że pewne dane
są dostępne w zbiorze baz danych, bez deklaracji gdzie dokładnie. Po drugie, formuły
koordynacyjne mogą być użyte do tworzenia zapytań. W tym przypadku, formuła
koordynacyjne jest interpretowana jako reguła dedukcyjna, która wyprowadza nową
informację opartą na informacji istniejącej w innej bazie danych. Na przykład formuła
∀1: x. (1: ∃y.p(x, y) → 2:q(x))
pozwala nam stwierdzić, że wartość b należy do q, q(b), w bazie 2, jeśli istnieje taka
wartość a w bazie 1, że para (a,b) należy do p, p(a,b), w bazie 1.
Bazy danych w systemach P2P przypominają heterogeniczne rozproszone bazy (tzw.
systemy multi-bazowe). W takich systemach użytkownik wysyła zapytania, które system
dekomponuje na podzapytania. Każde źródło danych ma warstwę osłony (wrapper), która
odwzorowuje podzapytania w jego własny język zapytań. Projektant bazy danych jest
odpowiedzialny za utworzenie schematu i odwzorowania, które definiują jego relacje ze
źródłem danych.
Podobnie jak w większości systemów multi-bazowych, zakłada się, że wszystkie węzły
w sieci P2P posiadają identyczną architekturę, składającą się z warstwy LMR działającej na
lokalnym serwerze danych. Jak pokazuje rys. 1 [2], w skład architektury LMR wchodzą 4
moduły:
− interfejs użytkownika (UI),
− menadżer zapytań (QM),
− menadżer uaktualnień (UM),
− osłona.
UI umożliwia użytkownikom formułowanie zapytań, odbieranie odpowiedzi i
wiadomości z innych węzłów oraz kontrolowanie innych modułów warstwy P2P. QM i
UM są odpowiedzialne za zapytania i propagacje uaktualnień; zarządzają obszarami relacji,
znajomościami, formułami koordynacyjnymi i koordynowaniem reguł. Osłona pośredniczy
w tłumaczeniu pomiędzy QM i UM oraz LBD.
da
.b
w
w
pl
s.
Rys. 1. Architektura węzła LMR
40
w
Pary komunikują się poprzez QM i UM używając komunikatów XML. Komunikacja
międzymodułowa również odbywa się za pomocą XML (białe strzałki). Ciemna strzałka
reprezentuje połączenia pomiędzy osłoną i LBD.
Przekazywanie zapytań i uaktualnień jest realizowane poprzez kodowanie w zbiorze
reguł koordynacyjnych, które w większości przypadków są wyrażane jako reguły ECA
(Event Condition Action). Reguły koordynacyjne określają kiedy, jak i gdzie zapytanie lub
uaktualnienie musi być przekazane. Pojedyncza formuła może dać w rezultacie kilka reguł.
Chociaż większość architektur jest zmodernizowaną wersją konwencjonalnej multi-bazy,
warstwa P2P wymaga rozwiązania nowych problemów, które są okazją do przyszłych
badań.
− P2P wymaga protokołu dla ustanawiania znajomości w sposób dynamiczny. Taki
protokół może odnajdywać znajomych po nazwie i ustanawiać sesje, a następnie
każdy partner wysyła schematy wymiany.
− Kiedy znajomość zostaje nawiązana, potrzebne są formuły i reguły. Warstwa P2P
powinna oferować automatyczne wsparcie generowania formuł koordynacyjnych.
Powinna także automatycznie (np. za pomocą eksploracji danych) odkrywać
zależności między danymi; jeżeli na przykład wiersze dwóch relacji mają te same
klucze, wtedy wartości odpowiednich kolumn powinny być takie same.
− Dla zapewnienia większej efektywności koordynacji międzywęzłowej, partnerzy
powinni być zdolni do publikowania zawartości swoich danych poprzez podawanie
nazwy i opisu (słów kluczowych albo schematów). Warstwa P2P interpretowałaby tą
informację pomagając użytkownikom tworzyć znajomości i pewnego rodzaju grupy
zainteresowań z innymi partnerami mającymi podobne zawartości.
da
.b
w
w
4 Technologie usług sieciowych
pl
s.
Dla poprawnego wykorzystania P2P, potrzebujemy technologii, która pozwoliłaby w pełni
rozwinąć możliwości tej sieci. Jednym z takich rozwiązań jest architektura SOA (Service
Oriented Architecture), będąca wynikiem wieloletniego dążenia informatyki do
zasadniczego uproszczenia integracji aplikacji.
Pojęcie SOA, czyli architektury opartej na usługach pojawiło się już w latach 80, kiedy
próbowano standaryzować architekturę informatyczną w formie abstrakcyjnego opisu
komunikujących się usług (usługi są w założeniu „samodzielnymi”, możliwymi do
wykorzystania przez różne aplikacje/usługi odpowiednikami podstawowych funkcji
biznesowych). Efektem tych prób była architektura DCOM (Distributed Component Object
Model) zaproponowana przez Microsoft oraz CORBA (Common Object Request Broker
Architecture) opracowana przez organizację OMG (Object Management Group). Okazało
się jednak, że architektury te posiadały wady powodujące ich niezgodność z architekturą
SOA.
Następnie pojawiła się koncepcja usług sieciowych (Web Services). Jest to technologia,
wykorzystująca protokół SOAP (Simple Object Access Protocol) do zdalnego
wywoływania procedur i wymiany danych XML-owych. Web Services określają sposób
katalogowania i wyszukiwania usług za pomocą UDDI (Universal Description, Discovery,
and Integration) oraz definiują interfejs usługi za pomocą WSDL (Web Service Description
Language). Transport w Web Services jest najczęściej realizowany w oparciu o protokół
HTTP, ale mogą do tego celu służyć także asynchroniczne systemy kolejkowe stosowane w
systemach klasy enterprise (MQSeries, MSMQ), oraz protokół pocztowy SMTP. Na tej
podstawie można określić podstawową architekturę usług internetowych (rys. 2).
41
w
w
Rys. 2. Architektura SOA
da
.b
w
Wykorzystanie standardów w budowie SOA oznacza, że każda usługa jest w sposób
zrozumiały zdefiniowana zarówno dla dostawcy jak i klienta.
pl
s.
Rys. 3. Modelowanie protokołu koordynacyjnego – diagram przejść
Usługa sieciowa jest zwykle odpowiednikiem funkcji biznesowej w typowej aplikacji.
W rozumieniu usług WebService usługa ma formę wyodrębnionego, samodzielnego
komponentu programowego o jasno zdefiniowanej funkcjonalności biznesowej.
Przykładem usługi może być sprawdzenie zapasów surowca w magazynie, wysłanie
zamówienia do poddostawcy, wydrukowanie faktury itp. Usługa jest widziana na zewnątrz
jedynie poprzez swój interfejs, który opisuje, co usługa może zrobić i na jakich warunkach.
42
w
Wewnętrzna struktura usługi, jej platforma systemowa i aplikacyjna, język
programowania itp. są całkowicie niewidoczne dla świata zewnętrznego. Immanentną
cechą usług sieciowych jest możliwość zmiany interfejsu komunikacji bez dokonywania
zmian w kodzie realizującej ją aplikacji.
Projektując aplikację, musimy uwzględnić potrzebę istnienia protokołu
koordynacyjnego. Jest on niezbędny do interakcji pomiędzy usługami, wymieniającymi
dane i komunikaty (rys. 3).
Ponieważ usługi muszą być zrozumiałe zarówno dla usługodawcy, jak i dla klienta,
potrzebujemy pewnego rodzaju kontrolera pośredniczącego, wykonującego routing
komunikatów i weryfikującego zgodność protokołów dla (generowania) formuł
koordynacyjnych. Kontroler jest odpowiedzialny za przesyłanie komunikatów do
odpowiedniego „obiektu” (jeden obiekt dla każdego przypadku komunikacji), korelowanie
komunikatów, rozumienie protokołu koordynacyjnego i sprawdzanie, czy komunikaty są z
nim zgodne (rys. 4).
da
.b
w
w
Rys. 4. Kontroler pośredniczący
Moduły implementujące protokół koordynacyjny powinny zawierać logikę protokołu oraz
przetwarzać i generować komunikaty zgodnie z regułami protokołu (rys. 5).
pl
s.
Rys. 5. Protokół „poziomy”, definiujący wspólną infrastrukturę (np. transakcje)
43
5 Podsumowanie
w
W rozdziale opisano problemy związane z wymianą danych między współpracującymi ze
sobą systemami baz danych w środowisku P2P, które odróżniają je od innego rodzaju
rozproszonych baz danych. Po pierwsze, odwzorowanie między bazami danych mają
wyłącznie charakter lokalne – bez globalnego schematu; po drugie – zbiór partnerów
uczestniczących w systemie może podlegać dynamicznym zmianom. Realizacja tego typu
systemów wymaga rozwiązania takich problemów jak ustanawianie konfiguracji między
partnerami oraz określania odwzorowań i formuł koordynacyjnych opisujących
semantyczne zależności między danymi. Zagadnienia te należą do ważnego dziś nurtu
badań nad bazami P2P [1,2] oraz zagadnień semantycznej integracji danych [3,9,10].
Prowadzone przez nas badania nad implementacją tej klasy systemów pokazują, że
wykorzystanie technologii SOA i stosowanie usług sieciowych WebService stanowią dobrą
platformę do tworzenia warstwy realizującej funkcje koordynacji wymiany danych między
aplikacjami (systemami danych) w środowisku P2P.
w
w
Literatura
da
.b
1. Aberer K., Special Topic Section on Peer-To-Peer Data Management, SIGMOD Record, Vol.
32(3), 2003.
2. Bernstein, Ph., i in.: Data Management for Peer-to-Peer Computing: A Vision. 5th Int.
Workshop on the Web and Databases – WebDB 2002, s. 89-94.
3. Bussler Ch., Fensel D., Maedche A., A conceptual architecture for semantic web enabled web
services, SIGMOD Record, Vol. 31, Nr 4, 2002, ss. 24-29.
4. Calvanese, D., Giacomo, G. D., Lenzerini, M., Rosati, R, Logical Foundations of Peer-To-Peer
Data Integration. In Proc. of the 23rd ACM SIGMOD Symposium on Principles of Database
Systems (PODS 2004), ss. 241–251.
5. Connolly T., Begg C.: Systemy baz danych: Praktyczne metody projektowania, implementacji i
zarządzania, Wydawnictwo RM, Warszawa 2004
6. Garcia-Molina H., Ullman J.D., Widom J.: Database system implementation, Prentice-Hall,
2000
7. Kreger H., Fulfilling the Web services promise, Comm. of the ACM, Vol. 46, No 6, 2003, s.
29-34.
8. Pankowski T., A high-level language for specifying XML data transformations, In: ADBIS
2004: Advances in Databases and Information Systems, Lecture Notes in Computer Science,
vol. 3255, Springer-Verlag, pp. 159-172.
9. T. Pankowski, E. Hunt, Data Merging in Life Science Data Integration Systems, W: Intelligent
Information Processing and Web Mining, Seria: Advances in Soft Computing, Springer Verlag,
2005, pp. 279-288.
10. Pankowski T., Integration of XML Data in Peer-To-Peer E-commerce Applications, W :
Challenges of Expanding Internet: E-Commerce, E-Business, and E-Government, IFIP –
International Federation for Information processing, IFIP-I3E, Springer, New York, 2005, pp.
481-496.
11. Pankowski T., Odwzorowania schematów i reformułowanie zapytań w bazach danych P2P,
Technologie Przetwarzania danych, (T. Morzy, H. Rybiński, red.), Wydawnictwo Politechniki
Poznańskiej, Poznań, 2005, ss. 326-338.
12. Pankowski T., Reformułowanie zapytań w systemach integracji danych, Rozdział 9, w: Bazy
danych – modele, technologie, narzędzia, WKŁ, Warszawa, 2005, s. 75-83.
13. Pankowski T., Specifying Schema Mappings for Query Reformulation in Data Integration
Systems, W: Advances in Web Intelligence, Lecture Notes in Computer Science 3528, Springer
Verlag, 2005, pp. 361-366.
pl
s.
44
14. Sheth, A. P. and Larson, J. A., Federated database systems for managing distributed,
heterogeneous, and autonomous databases. ACM Computing Surveys, 22(3), 1990, ss. 183–
236.
15. Tatarinov, I. and Halevy, A. (2004). Efficient query reformulation in peer data management
systems, ACM SIGMOD Conference, 2004, pp. 539–550.
16. http://www.service-architecture.com
w
da
.b
w
w
pl
s.
45
w
da
.b
w
w
pl
s.

pobierz plik referatu

Transkrypt

Podobne dokumenty

Konfiguracja P2P aplikacji MMS na Androidzie - E

SYSTEMY ROZPROSZONE

ZPAV - walka z P2P

KPP PIŁA PIŁA - KORZYSTANIE Z SIECI P2P