Zastosowanie otwartej platformy transportowej Peer-to-Peer do po³¹czenia i integracji obiektowych baz danych w architekturze DataGrid**

Transkrypt

1 AUTOMATYKA 2006 Tom 10 Zeszyt 3 Kamil Kuliberda*, Jacek Wiœlicki*, Tomasz Kowalski*, Piotr B³aszczyk*, Grzegorz Balcerzak*, Rados³aw Adamus* Zastosowanie otwartej platformy transportowej Peer-to-Peer do po³¹czenia i integracji obiektowych baz danych w architekturze DataGrid** 1. Wprowadzenie Technologie rozproszone osi¹gaj¹ coraz wiêksze znaczenie w procesie przetwarzania informacji biznesowej. Najczêœciej stawianymi wymaganiami dla systemów wspieraj¹cych procesy i operacje biznesowe s¹ dostêpnoœæ do informacji, aktualnoœæ informacji oraz prostota dostêpu do informacji. Takie wymagania wyp³ywaj¹ nie tylko od korporacji komercyjnych, lecz coraz czêœciej pojawiaj¹ siê tak e w segmencie organizacji rz¹dowych. Wychodz¹c naprzeciw jednym i drugim, skupiamy nasze badania nad realizacj¹ prototypowej platformy wspomagaj¹cej dzia³anie systemów bazodanowych o charakterze biznesowym. Nasze podejœcie do problemu opiera siê o prototyp obiektowej bazy danych, opartej o teoriê podejœcia stosowego do jêzyków zapytañ (Stack Based Approach) [12] oraz obiektowe aktualizowalne perspektywy (Updateable Object Views) [3]. Badania prezentowane w niniejszej publikacji s¹ praktycznym zastosowaniem za³o eñ teoretycznych precyzuj¹cych aspekty budowy sieci gridowych oraz prototypu DataGrid [7, 9, 10, 11]. Koncepcja integracji Ÿróde³ rozproszonych zosta³a szeroko opisana w [4, 5, 7, 8, 9, 10, 11]. Zastosowanie prototypu architektury opisanej w [7, 9, 10, 11] opiera siê o prototyp otwartej platformy transportowej realizuj¹cej swobodn¹ komunikacjê sieciow¹ (Ethernet oraz Internet) za pomoc¹ architektury sieciowej ka dy z ka dym P2P (Peer-to-Peer) [6, 8]. Zaimplementowany prototyp platformy transportowej pozwala na realizacjê komunikacji niezale nie od regu³ dzia³ania sieci Ethernet i Internet (NAT, Firewall), tworzy wirtualn¹ sieæ, w której wspó³uczestnicy s¹ niezale nie indeksowani, i których sieæ organizuje w spo- ³ecznoœæ otrzymuj¹c¹ mo liwoœæ komunikacji zgodnie z odpowiednimi za³o eniami pro- * Katedra Informatyki Stosowanej, Politechnika ódzka ** Praca wspó³finansowana ze œrodków Europejskiego Funduszu Spo³ecznego oraz Bud etu Pañstwa w ramach programu Mechanizm WIDDOK (numer umowy Z/2.10/II/2.6/04/05/U/2/06) 603

2 604 Kamil Kuliberda, Jacek Wiœlicki, Tomasz Kowalski, Piotr B³aszczyk, Grzegorz Balcerzak, Rados³aw Adamus jektantów sieci grid [1, 2]. Platforma transportowa wykorzystuje rozwi¹zanie Open Source JXTA [13]. W dalszej czêœci artyku³u omówione s¹ nastêpuj¹ce tematy: w rozdziale drugim opisano szczegó³y integracji baz danych za pomoc¹ platformy transportowej, przetwarzanie komunikatów sieciowych, zadania serwera centralnego wraz z indeksem zasobów, rozdzia³ trzeci to podsumowanie wykonania prototypu. 2. Koncepcja integracji baz danych za pomoc¹ platformy transportowej Prototypowe rozwi¹zanie integracji ³¹czy ze sob¹ dwa niezale ne systemy przetwarzania danych; 1) bazê danych Odra (Object Database for Rapid Application development) prototypow¹ bazê danych zbudowan¹ na bazie koncepcji SBA [12], 2) otwart¹ platformê transportow¹. Po³¹czenie aplikacji zasta³o zrealizowane zgodnie z za³o eniami architektury Data- Grid [7, 9, 10, 11]. W wyniku implementacji powsta³y w lokalnym œrodowisku komputera dwie aplikacje, z których jedna jest odpowiedzialna za przezroczyst¹ komunikacjê sieciow¹ z innymi aplikacjami wspó³pracuj¹cymi w ramach sieci wirtualnej platformy transportowej. W wyniku tego tworzona jest niezale na warstwa komunikacyjna, któr¹ zarz¹dzaj¹ aplikacje bazodanowe, bêd¹ce zarówno interfejsami u ytkowników sieci oraz zasobami danych dla gridu. Tak utworzona sieæ charakteryzuje siê scentralizowan¹ architektur¹ P2P, jest przezroczysta dla wspó³uczestników gridu, pozwala na implementacjê dodatkowych technologii jak np. infrastruktury zaufania (trust infrastructure). W sieci mog¹ dzia³aæ dwa rodzaje wspó³uczestników: 1) serwer centralny odpowiedzialny za utworzenie i utrzymanie sieci, 2) wspó³u ytkownicy sieci przetwarzaj¹cy dane [7]. Uproszczony schemat sieci prezentuje rysunek 1. Na rysunku widaæ, e implementacja platformy transportowej opiera siê o œrodowisko Java oraz technologiê JXTA, a systemy baz danych napisane s¹ w œrodowisku C#. Otwarta platforma transportowa zosta³a tak zaprojektowana, aby mo liwe by³o jej wykorzystanie do tworzenia wszelkiego rodzaju sieci równoleg³ych. Opracowane zosta³y dwa protoko³y komunikacyjne: 1) do komunikacji wewn¹trz wirtualnej sieci, 2) do komunikacji z zewnêtrznymi aplikacjami u ytkownika (w tym wypadku z bazami danych Odra). W dalszej czêœci artyku³u wyjaœnione zostanie dzia³anie komunikacji pomiêdzy aplikacjami bazy danych oraz platformy transportowej w œrodowisku lokalnym komputera. Mechanizm dzia³ania platformy jest obszernym problemem, któremu zosta³ poœwiêcony oddzielny artyku³.

3 Zastosowanie otwartej platformy transportowej Peer-to-Peer do po³¹czenia i integracji Rys. 1. Pogl¹dowy schemat komunikacji elementów architektury DataGrid 2.1. Komunikacja na poziomie baz danych w prototypie DataGrid Komunikacja pomiêdzy obiektow¹ baz¹ danych a aplikacj¹ sieci wirtualnej odbywa siê z wykorzystaniem gniazd sieciowych (sockets) jêzyka C# plaftromy.net od strony obiektowej bazy danych i gniazd sieciowych jêzyka Java od strony aplikacji sieci P2P. Zrealizowana wirtualna sieæ P2P jest w pe³ni przezroczysta dla po³¹czonych za jej pomoc¹ rozproszonych obiektowych baz danych Odra. U ytkownik pracuj¹cy z interfejsem obiektowej bazy nie ingeruje w aplikacjê P2P, nie musi nawet wiedzieæ o jej istnieniu. Jedyn¹ informacj¹, jak¹ musi posiadaæ, jest nazwa innej bazy danych, z któr¹ chce wspó³pracowaæ (zgodnie z semantyk¹ SBA). Podczas budowy zapytania okreœla on tylko bazê i zasób, o którym chce uzyskaæ informacje. Przyk³adowe zapytanie wygl¹da nastêpuj¹co: Odra1.Pracownik. Taka konstrukcja u³atwia przetwarzanie danych informacje na temat architektury i struktury sieci s¹ zbyteczne podczas realizacji zleceñ na danych. Rozwi¹zanie to znacznie u³atwia i przyspiesza pracê z rozproszon¹ obiektow¹ baz¹ danych. Zlecenie realizacji zapytania przedstawia rysunek 2. Odra1 Platforma transportowa Odra2 Rys. 2. Ewaluacja zapytañ pomiêdzy OODBMS poprzez platformê transportow¹ Transport zapytania wys³anego przez obiektow¹ bazê danych mo na podzieliæ na piêæ faz: 1. obiektowa baza danych Odra wysy³a zapytanie do sieci; 2. zapytanie trafia do aplikacji platformy transportowej zwi¹zanej z nadaj¹c¹ baz¹ danych, modu³ ten odczytuje informacje o nadawcy i odbiorcy; 3. aplikacja platformy transportowej przesy³a ca³¹ zawartoœæ zapytania do odpowiedniego odbiorcy w sieci wirtualnej P2P, z którym zwi¹zana jest okreœlona w zapytaniu docelowa baza danych Odra;

4 606 Kamil Kuliberda, Jacek Wiœlicki, Tomasz Kowalski, Piotr B³aszczyk, Grzegorz Balcerzak, Rados³aw Adamus 4. aplikacja platformy transportowej odbiorcy po otrzymaniu danych od aplikacji nadawcy rozpoznaje docelow¹ bazê danych, do której jest adresowanie zapytanie i przekazuje je do niej; 5. Odra docelowa odbiera zaadresowane do niej zapytanie. Ca³y proces przedstawia rysunek Odra1 <Datagram> </Datagram> Message <Datagram> </Datagram> Odra2 Rys. 3. Piêæ faz procesu transportu zapytania w DataGrid Aby powy szy proces móg³ byæ zrealizowany, zaimplementowano wspomniany wczeœniej protokó³ pozwalaj¹cy na transport dowolnych danych pomiêdzy bazami danych a aplikacj¹ sieci wirtualnej zachowuj¹c jednoczeœnie informacje na temat ich lokalizacji i przeznaczenia. Pojedyncza wiadomoœæ przekazywana miêdzy aplikacjami w sieci grid ma postaæ dokumentu XML. Ca³a wiadomoœæ jest zamkniêta w elemencie o nazwie Datagram np.: <Datagram> <!--Informacje na temat nadawcy--> <Sender Address= Server@Server /> <!--Informacje na temat odbiorcy--> <Recipient Address= Odra1@Peer1" /> <!--Dane do przes³ania--> <Data Type= AreYouAlive Part="1/1" /> </Datagram> Element Datagram zawiera miedzy innymi dwa podelementy Sender i Recipient. To w nich zawarte s¹ informacje na temat nadawcy i odbiorcy. Potencjalny odbiorca mo e odczytaæ od kogo pochodzi wiadomoœæ i czy by³a adresowana do niego. Adresy nadawcy i odbiorcy zapisane s¹ w atrybutach Address. Przyk³adowy adres ma nastêpuj¹c¹ postaæ: Odra1@Peer1. Sk³ada siê z dwóch czêœci: pierwsza identyfikuje bazê Odra, druga to identyfikator wspó³uczestnika sieci JXTA, do którego pod³¹czona jest baza. W kolejnym elemencie Data umieszczone s¹ dane do przes³ania. W atrybutach tego elementu zapisane s¹ dwie informacje. 1) Pierwsza dotyczy typu przesy³anych danych informacje ró ni¹ siê dla serwera i klienta. Powodem tych rozbie noœci s¹ ró ne zadania, jakie pe³ni¹ obie aplikacje. Klient mo e wysy³aæ nastêpuj¹ce typy wiadomoœci:

5 Zastosowanie otwartej platformy transportowej Peer-to-Peer do po³¹czenia i integracji Query zapytanie do innej bazy z sieci grid, Response odpowiedÿ na zapytanie z innej bazy z sieci grid, GetMetaschema proœba o przes³anie metaschematu przez serwer, IAmAlive potwierdzenie zwrotne dla serwera, e baza dzia³a, DeleteLocalSchema od³¹cza schemat lokalny od schematu globalnego, Message wiadomoœæ tekstowa. Odpowiednio serwer wysy³a nastêpuj¹ce typy: SetLocalSchema do³¹cza schemat lokalny do schematu globalnego, SetMetaschema ustawia schemat globalny baz Odra, SchemaDeleted informacja potwierdzaj¹ca od³¹czenie schematu lokalnego od schematu globalnego, AreYouAlive zapytanie serwera o dostêpnoœæ klienta, Message wiadomoœæ tekstowa. 2) Drugi atrybut o nazwie Part ma znaczenie, gdy przesy³ana ramka danych ma wielkoœæ wiêksz¹ od wielkoœci bufora wysy³kowego protoko³u TCP/IP. Wtedy wysy³ane dane s¹ dzielone na poziomie protoko³u i umieszczane w odrêbnych datagramach. Dodatkowo w atrybucie Part umieszczona zostaje informacja która czêœæ danych zawarta jest w ramce oraz ile jest wszystkich czêœci danych. Dla przyk³adu: Part= 5/10" oznacza, e w ramce przesy³ana jest pi¹ta czêœæ danych, a liczba wszystkich czêœci wynosi 10. Atrybut ten znacz¹co u³atwia sk³adanie danych w ca³oœæ z pojedynczych ramek. Do zapisywania dokumentu w formacie XML u yto klasy XmlTextWriter z biblioteki.net. Klasa ta wspomaga szybkie, bezbuforowe, zapisywanie przez dodawanie s³ów do strumienia. Zapisany dokument jest zgodny z wymaganiami W3C Extensible Markup Language (XML) 1.0. Za nas³uchiwanie i odbieranie ramek z sieci odpowiedzialny jest osobny w¹tek. Po odebraniu ramki sprawdzany jest jej format, je eli ramka posiada nieprawid³ow¹ budowê jest ignorowana. W¹tek obs³ugujê sytuacjê zape³niania bufora odbioru przez wiêksz¹ iloœæ datagramów. Protokó³ wyodrêbnia pojedyncze ramki identyfikuj¹c je po elementach pocz¹tkowych i koñcowych (znacznik Datagram). Po odebraniu ramki, aplikacja analizuje j¹ przy u yciu interfejsu SAX (Simple API for XML) zaimplementowanego w bibliotekach.net Aspekty integracji aplikacji bazy danych oraz aplikacji platformy transportowej w ramach rozproszonego systemu baz danych Transport komunikatów miêdzy bazami danych zrealizowany jest w trzech etapach (rys. 4): 1. przesy³anie informacji do platformy JXTA, 2. przesy³anie w ramach wspó³uczestników wirtualnej sieci JXTA, 3. przekazanie danych do celu przeznaczenia.

6 608 Kamil Kuliberda, Jacek Wiœlicki, Tomasz Kowalski, Piotr B³aszczyk, Grzegorz Balcerzak, Rados³aw Adamus Ka da operacja wymaga opakowania informacji w odpowiednie ramki i przekazania dalej. Kolejne kroki przep³ywu informacji prezentuje B³¹d! Nie mo na odnaleÿæ Ÿród³a odsy³acza. W miejscach oznaczonych pionowymi przerywanymi liniami dochodzi do przetwarzania danych. Rys. 4. Etapy integracji baz danych W projekcie za³o ono, e komunikacja miêdzy aplikacj¹ sieci wirtualnej (platformy transportowej), zewnêtrzn¹ aplikacj¹ u ytkownika (baza danych Odra) co jest równoznaczne z realizacj¹ komunikacji pomiêdzy ró nymi jêzykami programowania odbywaæ siê bêdzie za pomoc¹ mechanizmu gniazd. Po stronie JXTA utworzono serwer jednow¹tkowy oczekuj¹cy na po³¹czenia ze strony bazy danych Odra zarówno dla aplikacji klienckich, jak i dla serwera centralnego. Po nawi¹zaniu po³¹czenia tworzony jest kana³ umo liwiaj¹cy dwukierunkow¹ komunikacjê. Ta czêœæ aplikacji ma typow¹ architekturê klient-serwer. Za- ³o enie, e serwer jest jednow¹tkowy okreœla mo liwoœæ po³¹czenia dok³adnie z jednym klientem. Takie rozwi¹zanie pozwala traktowaæ parê baza sieæ P2P jako jedn¹ aplikacjê chocia zaimplementowan¹ w ró nych jêzykach programowania, umo liwia dodatkowo przekazanie odpowiedzialnoœci obs³ugi dostêpnoœci klientów w sieci grid na poziom sieci wirtualnej JXTA. Od³¹czenie klienta po stronie bazy danych jest równoznaczne z od³¹czeniem wspó³uczestnika sieci JXTA (w sieci P2P). Przetwarzanie ramek danych przychodz¹cych od baz danych do aplikacji platformy transportowej Aplikacja sieci wirtualnej po³¹czona z aplikacj¹ bazy danych mo e otrzymywaæ tylko jeden rodzaj wiadomoœci od bazy danych. S¹ to datagramy zapisane w formacie XML, które pomiêdzy znacznikami <Datagram> oraz </Datagram> zawieraj¹ dowoln¹ informacjê. Wnêtrze datagramu jest przesy³ane tylko pomiêdzy bazami danych znajduj¹cymi siê w sieci grid. Buduj¹c wiadomoœæ dedykowan¹ innej bazie danych, sk³ada siê j¹ z elementów opisanych w podrozdziale 2.1. Tylko wtedy informacja przenoszona przez tak z³o ony datagram mo e byæ prawid³owo odczytana i zinterpretowana przez inn¹ bazê danych. Z punktu widzenia platformy transportowej datagram posiada jedynie informacje o wspó³u ytkowniku Ÿród³owym oraz docelowym, inne informacje dotycz¹ce platformy transportowej nie s¹ przenoszone. Przyk³ad datagramu jest zamieszczony w podrozdziale 2.1. Po odebraniu wiadomoœci od bazy danych aplikacja sieci wirtualnej analizuje otrzyman¹ wiadomoœæ i pobiera z niej dane nadawcy i odbiorcy. Na podstawie przyk³adowej wiadomoœci z podrozdzia³u 2.1 mo emy okreœliæ:

7 Zastosowanie otwartej platformy transportowej Peer-to-Peer do po³¹czenia i integracji nadawc¹ wiadomoœci jest baza Server pod³¹czona do aplikacji sieci wirtualne o identyfikatorze Server <Sender Address= Server@Server />, adresatem jest baza danych Odra1 pod³¹czona do aplikacji sieci wirtualnej o identyfikatorze Peer1 <Recipient Address= Odra1@Peer1 />. Aplikacja platformy transportowej po okreœleniu, kto jest adresatem wiadomoœci wysy³a element Datagram do miejsca przeznaczenia. Je eli zdarzy³aby siê sytuacja, w której baza docelowa bêdzie niedostêpna, wówczas dostarczenie wiadomoœci nie bêdzie mo liwe i baza wysy³aj¹ca wiadomoœæ (Server) otrzyma od aplikacji sieci wirtualnej informacje o niedostêpnoœci bazy zdalnej. Przetwarzanie ramek danych przesy³anych pomiêdzy aplikacjami platformy transportowej Aplikacja sieci wirtualnej mo e odbieraæ i wysy³aæ komunikaty do innych aplikacji sieci wirtualnej, dla takiego scenariusza zaimplementowano dwa rodzaje wiadomoœci: 1) Datagram przyk³ad przedstawiony w podrozdziale 2.1; 1) Command wiadomoœæ steruj¹ca sieci¹ P2P, mo e byæ przesy³ana przez aplikacjê serwera centralnego sieci P2P, b¹dÿ aplikacjê wspó³uczestnika sieci; np. dodanie do sieci wirtualnej nowego wspó³u ytkownika sieci, realizowane przez nastêpuj¹c¹ wiadomoœæ wys³an¹ od aplikacji wspó³u ytkownika sieci wirtualnej do aplikacji serwera centralnego sieci wirtualnej: <?xml version="1.0"?> <Command> <! Infromacja na temat Nadawcy > <Sender Address= PeerName /> <Add Name= PeerName /> </Command> Aplikacja sieci wirtualnej wspó³u ytkownika sieci po odebraniu wiadomoœci XML typu przedstawionego powy ej, dokonuje jej analizy. Je eli odebrana wiadomoœæ jest typu Datagram wówczas aplikacja przesy³a j¹ do wy szej warstwy aplikacji bazodanowej. Je- eli wiadomoœæ jest typu Command rozpoznaje j¹ jako jeden z wewnêtrznych komunikatów steruj¹cych, b¹dÿ monitoruj¹cych sieæ wirtualn¹. Komunikat zostajê przetworzony zgodnie z jego przeznaczeniem Integracja schematów baz danych wspó³uczestników sieci grid Kluczowym aspektem realizacji gridu dla baz danych jest odpowiednie zarz¹dzanie lokalnymi schematami danych. Ka da prototypowa baza danych dzia³aj¹ca w DataGrid posiada swój schemat lokalny danych zapisany w strukturze podobnej do stosu. Aby zintegrowaæ ten schemat z globalnym schematem gridu, nale y zrealizowaæ odpowiednie mapowanie zasobów lokalnych: Struktura bazy danych musi zostaæ przetransformowana do postaci ³atwej do przesy³ania przez jakikolwiek protokó³ komunikacyjny w tym przypadku zastosowano XML

8 610 Kamil Kuliberda, Jacek Wiœlicki, Tomasz Kowalski, Piotr B³aszczyk, Grzegorz Balcerzak, Rados³aw Adamus Schema, który jest standardem opisu struktury dokumentu XML. Umo liwia on dok³adne opisanie drzewiastej struktury dokumentu, czyli typów danych znajduj¹cych siê w elementach i atrybutach. Poniewa struktura bazy to równie drzewo, wykorzystanie tego standardu spe³nia stawiane wymagania. Dodatkowo, w przysz³oœci mo e przydaæ siê do walidacji poprawnoœci danych wprowadzanych lub odczytywanych z bazy danych do dokumentu XML. Taka koniecznoœæ mo e wyst¹piæ np. przy przenoszeniu danych z jednej bazy do drugiej. Odrzucenie danych lokalnych na podstawie schematu lokalnego, które nie mog¹ zostaæ udostêpnione w sieci. S¹ to dane prywatne, chronione przed dostêpem z zewn¹trz. Mechanizm jest analogiczny do udostêpniania zasobów w sieci komputerowej. Nale y postawiæ widoczn¹ granicê miêdzy danymi udostêpnionymi w sieci grid a pozosta³ymi zasobami. Takiego podzia³u mo na dokonaæ przy odpowiedniej wiedzy o danych publicznych. W tym przypadku realizuje siê udostêpnianie na podstawie schematu globalnego gridu. Schemat globalny przesy³any jest do wspó³uczestnika sieci na ¹danie wys³ane do serwera centralnego. Mapowanie informacji jest podobne do wycinania kszta³tu z kartki papieru po przy³o eniu wzorca. Po wyciêciu zostaje jedynie czêœæ pasuj¹ca do wzorca. Odrzuca siê wszystkie dane niepasuj¹ce do wzorca, proces ten jest przedstawiony na rysunku 5. Rys. 5. Proces mapowania schematu lokalnego do gridu na podstawie schematu globalnego Implementacja mechanizmu z rysunku 5 realizuje analizê schematu lokalnego i metaschematu (schematu globalnego) za pomoc¹ interfejsu DOM XML oraz porównywaniu poszczególnych elementów. Standard DOM reprezentuje dokument XML jako drzewo sk³adaj¹ce siê z okreœlonej hierarchii wêz³ów (obiektów Node lub po nich dziedzicz¹cych). W odró nieniu od SAX, pozwala na tworzenie w pamiêci nowych dokumentów. W mechanizmie wykorzystano zapis do pamiêci elementów dokumentu XML, nastêpnie dokumenty s¹ porównywane wzglêdem zawartoœci elementów je eli dany wêze³ znajduje siê w schemacie lokalnym, a nie wystêpuje w schemacie globalnym zostaje usuniêty. W re-

9 Zastosowanie otwartej platformy transportowej Peer-to-Peer do po³¹czenia i integracji zultacie powstaje publiczny schemat, który jest przesy³any do serwera centralnego. Nastêpnie po stronie klienta tworzony jest osobny schemat w bazie danych Odra. Schemat ten odpowiedzialny jest za sprawdzanie poprawnoœci sk³adniowych zapytañ pochodz¹cych z sieci grid. Zapobiega to sytuacji, w której zapytanie od innego klienta w sieci mog³oby dotyczyæ nieudostêpnionych danych Odpowiedzialnoœæ centralnego serwera gridu w zarz¹dzaniu rozproszonymi bazami danych W architekturze DataGrid serwer centralny pe³ni rolê integratora danych w odró nieniu od architektury klient-serwer, w której pe³ni rolê poœrednika komunikacyjnego. Najwa niejszym jego zadaniem jest przechowywanie metaschematu gridu, czyli opisu struktury, jak¹ maj¹ tworzyæ po³¹czone bazy danych. Metaschemat przechowywany jest w takiej samej bazie danych, jak te, które pracuj¹ w aplikacjach klienckich gridu. Struktura schematu lokalnego jest tworzona przez administratora i tylko przez niego mo e byæ zmieniona z poziomu serwera. Metaschemat jest zapisany w postaci XML Schema i jest ca³kowicie zgodny ze standardem. W przypadku zapisu zawartoœci bazy danych do postaci dokumentu XML z powodzeniem mo na zastosowaæ walidator poprawnoœci sk³adniowej. Dokument metaschematu mo na utworzyæ za pomoc¹ edytorów wspieraj¹cych XML (np. Altova) lub utworzyæ wzorcow¹ bazê i zapisaæ jej strukturê do XML Schema. Proces mapowania danych jest bardzo prosty: 1. baza danych wspó³uczestnika sieci wysy³a ¹danie do serwera centralnego o przes³anie zwrotne schematu globalnego gridu (komunikat GetMetaschema); 2. serwer centralny po otrzymaniu takiego schematu przygotowuje dane do wysy³ki i odsy³a je w odpowiednim komunikacie (SetMetaschema); 3. wspó³u ytkownik sieci, po otrzymaniu danych, dokonuje mapowania schematu lokalnego zgodnie z algorytmem z podrozdzia³u 2.3; 4. wspó³u ytkownik odsy³a do serwera centralnego komunikat zawieraj¹cy jego zintegrowany ju gridem schemat; 5. serwer centralny indeksuje zawartoœæ lokaln¹ do dalszego przetwarzania przez innych wspó³u ytkowników gridu. Serwer centralny zawsze otrzymuje od nadawców struktury po mapowaniu, st¹d pewnoœæ, e ich zawartoœæ pokrywa siê ze schematem globalnym lub jest jego czêœci¹. Znajduj¹ca siê na serwerze centralnym baza danych Odra nie stanowi zasobu gridu jako zbiór danych. Jest ona wykorzystywana do przechowywania struktury gridu oraz schematów lokalnych baz danych. Indeks lokalnych schematów na serwerze centralnym posiada zawsze aktualn¹ informacjê o rozproszeniu obiektów w gridzie. Indeks jest dokumentem XML i posiada nastêpuj¹c¹ postaæ (gdzie Odra1/2/3 to lokalizacje zasobów oznaczonych jako elementy drzewa):

10 612 Kamil Kuliberda, Jacek Wiœlicki, Tomasz Kowalski, Piotr B³aszczyk, Grzegorz Balcerzak, Rados³aw Adamus <Odra> <Department> <Item>Odra1</Item> <Item>Odra2</Item> <Item>Odra3</Item> </Department> <Person> <Item>Odra1</Item> <Item>Odra2</Item> </Person> <House> <Item>Odra2</Item> <Item>Odra3</Item> </House> </Odra> Indeks w takiej postaci jest rozsy³any do wszystkich aktywnych klientów gridu. Na jego podstawie oraz w oparciu o schemat globalny wspó³uczestnicy sieci s¹ w stanie odtworzyæ kompletn¹ strukturê sieci oraz lokalizacjê zasobów w wêz³ach, jest wiêc jednym z najwa niejszych elementów sieci DataGrid. Sam indeks jest niewielki i zawiera wiele informacji o gridzie. Zosta³o to osi¹gniête poprzez wyeliminowanie zbêdnych, powtarzaj¹cych siê informacji i odpowiedni¹ strukturê zawartoœci indeksu. 3. Podsumowanie Opisane prace implementacyjne pozwoli³y na podsumowanie badañ dotycz¹cych realizacji sieci grid zorientowanej na przetwarzanie danych (data-intensive). Koncepcja budowy platformy transportowej opartej o architekturê sieci ka dy z ka dym (Peer-to- Peer) zosta³a potwierdzona budow¹ uproszczonego modelu DataGrid opisanego w niniejszym artykule. Prototyp modelu realizuje rozproszon¹ komunikacjê dla obiektowych baz danych, jednak aby osi¹gn¹æ zamierzony cel podejœcia DataGrid, nale y zapewniæ pe³n¹ przezroczystoœæ [7]. Jest to trudne do osi¹gniêcia bez zastosowania odpowiedniego mechanizmu. Dalsze implementacje bêd¹ integrowaæ do istniej¹cego rozwi¹zania obiektowe aktualizowalne perspektywy (updateable object views) [3]. Propozycje takiego rozwi¹zania s¹ przedstawione w [7]. Literatura [1] Moore R., Merzky A.: Persistent Archive Concepts. Global Grid Forum GFD-I.026. December 2003 [2] Foster I., Kesselman C., Nick J., Tuecke S.: The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. Global Grid Forum, June 22, 2002 [3] Kozankiewicz H.: Updateable Object Views. PhD Thesis, 2005, Finished PhD-s

11 Zastosowanie otwartej platformy transportowej Peer-to-Peer do po³¹czenia i integracji [4] Kozankiewicz H., Stencel K., Subieta K.: Implementation of Federated Databases through Updateable Views. Proc. EGC 2005 European Grid Conference, Springer LNCS, 2005 [5] Kozankiewicz H., Stencel K., Subieta K.: Integration of Heterogeneous Resources through Updatable Views. Workshop on Emerging Technologies for Next generation GRID (ETNGRID-2004), 13th IEEE International Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises (WETICE-2004), University of Modena and Reggio Emilia, Italy, June 14 16, 2004, Proceedings published by IEEE [6] Kuliberda K.: Podstawowe mechanizmy architektury Grid Computing. Pó³rocznik AGH, Automatyka, t. 8, z. 3, 2004, [7] Kuliberda K., Kaczmarski K., Adamus R., B³aszczyk P., Balcerzak G., Subieta K.: Virtual Repository Supporting Integration of Pluginable Resources. 17th DEXA 2006 and 2nd International Workshop on Data Management in Global Data Repositories (GRep) 2006, Proceedings in IEEE Computer Society, to appear, 2006 [8] Kuliberda K., Sekulska-Nalewajko J., Kuzañski M.: Technologia Grid Computing nowa architektura sieci komputerowych. XII Sieci i systemy informatyczne: teoria, projekty, wdro enia, aplikacje, Politechnika ódzka, t. 2, 2004, [9] Kuliberda K., Wiœlicki J.: Architektura gridu bazodanowego data grid. Pó³rocznik AGH, Automatyka, t. 9, z. 3, 2005, [10] Kuliberda K., Wiœlicki J.: Przezroczysta platforma transportowa dla rozproszonego, równoleg³ego przetwarzania zasobów bazodanowych. Sieci i systemy informatyczne: teoria, projekty, wdro- enia, aplikacje, Politechnika ódzka, t. 2, 2005, [11] Kuliberda K., Wiœlicki J., Adamus R.: The Main Issues of The Database Grid Realization Based on Data Grid Concept. I KKNTPD, Poznañ, 2005, [12] Subieta K.: Teoria i konstrukcja obiektowych jêzyków zapytañ. Wydawnictwo PJWSTK, Warszawa 2004, ISBN (522 strony) [13] Project JXTA Community:

12 614 Kamil Kuliberda, Jacek Wiœlicki, Tomasz Kowalski, Piotr B³aszczyk, Grzegorz Balcerzak, Rados³aw Adamus