Artykuł - Instytut Automatyki i Informatyki Stosowanej
Transkrypt
Artykuł - Instytut Automatyki i Informatyki Stosowanej
ZASTOSOWANIE XML W HETEROGENICZNEJ ROZPROSZONEJ BAZIE DANYCH WSPIERAJĄCEJ WIELKI EKSPERYMENT FIZYKI JĄDROWEJ TOMASZ TRACZYK Streszczenie: Artykuł przedstawia przyczyny i okoliczności tworzenia rozproszonej bazy danych wspierającej konstrukcję detektorów dla wielkiego eksperymentu fizyki jądrowej ALICE. Zaprezentowano napotkane problemy i wybrane rozwiązania, ze szczególnym uwzględnieniem zastosowania XML. 1. Wprowadzenie W Europejskim Centrum Fizyki Jądrowej CERN w Genewie jest obecnie budowany nowy akcelerator ciężkich jonów LHC (Large Hadron Collider [1]). Jednym z czterech głównych eksperymentów, które prowadzone będą na LHC jest ALICE (A Large Ion Collider Experiment [2]), mający na celu badanie właściwości materii w warunkach zderzeń jonów o wielkich energiach, w tym badanie przejścia fazowego do stanu plazmy kwarkowo-gluonowej [3]. LHC stanowi wielkie wyzwanie nie tylko z punktu widzenia fizyki, ale także inżynierii: sam tylko eksperyment ALICE jest jednym z największych obecnie realizowanych projektów badawczych, a skala całego przedsięwzięcia może być porównywana jedynie z programami badań kosmicznych. Dość wspomnieć, że LHC będzie największym urządzeniem zbudowanym w dziejach człowieka. Eksperyment ALICE wymaga zbudowania ogromnej – zarówno co do złożoności jak i fizycznych rozmiarów – aparatury badawczej mającej na celu śledzenie i analizę skutków zderzeń jonów. Główną część tej aparatury stanowi zespół detektorów cząstek. Każdy z detektorów jest sam w sobie bardzo złożonym urządzeniem; niektóre detektory składają się z dziesiątków tysięcy elementów detekcyjnych, z których każdy jest dość skomplikowanym urządzeniem elektronicznym! Prace nad eksperymentem ALICE prowadzi międzynarodowy zespół (collaboration), uczestniczy w nich kilkadziesiąt instytucji naukowych z całego świata. W ramach tej współpracy na Wydziale Fizyki Politechniki Warszawskiej działa pod kierownictwem dra Wiktora Peryta zespół zajmujący się projektem, wykonaniem i wdrożeniem baz danych wspierających budowę aparatury dla eksperymentu. Zespół składa się z pracowników, doktorantów i studentów kilku wydziałów Politechniki, a autor niniejszego opracowania pełni w nim rolę konsultanta w dziedzinie baz danych i opiekuna naukowego studentów. 1 2. Baza danych konstrukcji detektorów Podstawowym zadaniem na etapie przygotowania eksperymentu jest zaprojektowanie i wykonanie detektorów. Jest to zadanie trudne ze względu na: • unikalność sprzętu – detektory są projektowane specjalnie dla eksperymentu, a doświadczenia w dziedzinie projektowania i wykonania podobnej aparatury są bardzo ograniczone; zawsze zaś dotyczą znacznie mniejszej skali; • niemożność przetestowania sprzętu w warunkach rzeczywistej eksploatacji; • wielkie rozmiary sprzętu; • dużą jego złożoność (detektor składać się może z dziesiątek tysięcy komponentów); • konieczność osiągnięcia dużej precyzji działania sprzętu, by wyniki pomiarów były wiarygodne. Do tego dochodzą problemy natury organizacyjnej, wiążące się z faktem, iż sprzęt jest projektowany i produkowany w wielu laboratoriach rozproszonych po całym świecie; trzeba więc zapewnić koordynację pracy i przekazywanie jej wyników. Zadanie produkcyjne o takim rozmiarze jest właściwie niemożliwe do przeprowadzenia bez wsparcia informatycznego. Dlatego konstrukcję detektorów wspierać ma specjalna baza danych; to właśnie ona stanowi temat niniejszego opracowania. 2.1. Zadania bazy danych Rolą bazy danych konstrukcji detektorów (Detector Construction Database) jest wspomaganie procesu produkcji detektorów oraz gromadzenie danych pozyskiwanych na etapie produkcji, a niezbędnych w czasie eksploatacji, np. do kalibracji pomiarów lub do dokonywania napraw i wymiany zużytych elementów. Do najważniejszych zadań bazy danych należy zatem: • śledzenie obiegu komponentów w czasie produkcji, • śledzenie montażu komponentów składowych w komponentach złożonych oraz podziału komponentów na mniejsze elementy (np. podziału „wafli” krzemowych na pojedyncze chipy); • gromadzenie danych opisujących produkowane komponenty; • gromadzenie danych pomiarowych uzyskiwanych w czasie produkcji, w szczególności wyników różnorodnych testów. 2.2. Rozproszenie Podstawowe problemy, warunkujące przyjęte rozwiązania techniczne, wynikają z faktu, iż produkcja detektorów odbywa się w wielu laboratoriach rozproszonych po całym świecie; dysponują one bardzo zróżnicowanymi możliwościami w dziedzinie informatyki. W szczególności niektóre z nich: 2 • • • nie mają dobrego dostępu do wydajnych łącz; nie zatrudniają profesjonalnych administratorów baz danych; nie dysponują profesjonalnymi systemami zarządzania bazami danych ani nie mają możliwości ich nabycia. Ze względu na pierwsze z tych ograniczeń nie jest możliwe przyjęcie koncepcji scentralizowanej bazy danych, choć centralizacja niewątpliwie pozwoliłaby uniknąć wielu istotnych problemów. Pozostałe ograniczenia skutkują niemożnością zastosowania komercyjnego systemu zarządzania bazami danych. Konieczne jest zastosowanie w laboratoriach systemu typu open source, który jest dostępny za darmo i łatwy do zainstalowania oraz administrowania. 2.3. Architektura rozproszonej bazy danych Konieczność zainstalowania baz danych w laboratoriach warunkuje przyjęcie architektury rozproszonej. Ponieważ jednak dane tworzone w rozproszonym procesie produkcji będą w przyszłości potrzebne w czasie eksploatacji, a ta oczywiście będzie miała miejsce w CERN, postanowiono oprócz zbioru baz w laboratoriach (nazwanych bazami satelickimi) zbudować także bazę centralną, umieszczoną w CERN. Ogólną architekturę systemu przedstawia rysunek 1. Centralna b.d. Satelickie b.d. Rysunek 1. Ogólna architektura rozproszonej bazy danych konstrukcji detektorów Architektura taka ma szereg ważnych zalet: • umożliwia sukcesywne gromadzenie danych w jednym miejscu i ich udostępnianie w miarę gromadzenia przez jeden centralnie zarządzany serwis WWW; • pozwala uniknąć konieczności zarządzania „siecią” wymiany danych między bazami satelickimi – wszelkie przekazy informacji odbywają się za pośrednictwem bazy centralnej; 3 ułatwia zadanie śledzenia obiegu komponentów – „spis inwentarza” przechowywany w bazie centralnej zawiera informacje o cyrkulacji każdego komponentu między laboratoriami; • w sposób naturalny zapewnia kanały dystrybucji metadanych – słowników konfigurujących generyczną strukturę danych; • zwiększa bezpieczeństwo – dane gromadzone w bazie centralnej stanowią swoistą kopię rezerwową danych z baz satelickich; jest to ważne wobec faktu, iż bazy satelickie nie będą zapewne administrowane w sposób profesjonalny; baza centralna będzie zaś odpowiednio administrowana i umieszczona na w pełni zabezpieczonych serwerach; • po zakończeniu produkcji umożliwia likwidację baz satelickich i dalsze wykorzystywanie jedynie bazy centralnej. Niestety, struktura ta ma także poważne wady; wynikają ona jednak z samego – niemożliwego z podanych wyżej przyczyn do uniknięcia – faktu rozproszenia bazy danych: • potrzebę zorganizowania wymiany danych między bazami; • konieczność zapewnienia zgodności danych między bazami satelickimi a bazą centralną; • potrzebę synchronizowania możliwości modyfikowania kopii tych samych danych w różnych bazach. • 2.4. Heterogeniczność Centralna baza danych gromadzić będzie wszystkie dane zbierane w bazach satelickich. Wolumen danych gromadzonych w tej bazie będzie zatem bardzo duży; należy spodziewać się, iż wystąpią tu problemy charakterystyczne dla bardzo wielkich baz danych (VLDB – Very Large Databases). Dlatego niezbędne są tu rozwiązania technologiczne zapewniające bezpieczne składowanie i efektywny dostęp do danych o wielkiej objętości. Systemy zarządzania bazami danych typu open source nie zapewniają odpowiednich środków, np. możliwości partycjonowania tabel. Co więcej, dane zgromadzone w centralnej bazie danych będą miały w przyszłości krytyczne znaczenie dla powodzenia eksperymentu, a ich utrata wiązałaby się z koniecznością powtórzenia części procesów produkcyjnych (np. niektóre złożone urządzenia trzeba by rozłożyć na części w celu przeprowadzenia pomiarów). Dlatego w przypadku centralnej bazy danych zastosowany być musi komercyjny system zarządzania bazami danych „z górnej półki”. Ze względu na zgodność z rozwiązaniami stosowanymi w innych systemach w CERN, zdecydowano użyć bazy danych Oracle 8i (z planowanym przejściem na wersję 9i). W przypadku baz satelickich, ze względu na koszty nabycia i eksploatacji, zastosowanie rozwiązań komercyjnych nie było możliwe. Użyta technologia musi jednak zapewniać dość zaawansowane mechanizmy, w tym przetwarzanie transakcyjne oraz wyzwalacze – konieczne do ustanowienia złożonych reguł integralności (business rules) w projektowanej generycznej strukturze bazy danych. Po analizie 4 dostępnych darmowych systemów zarządzania bazami danych wybrano system PostgreSQL. 2.5. Struktury generyczne Jedna z podstawowych trudności w konstrukcji omawianego systemu informacyjnego polega na dużym zróżnicowaniu struktur danych opisujących poszczególne komponenty i testy. Pierwsze, dość naiwne, próby stworzenia baz danych wspierających proces produkcji detektorów, podejmowano w samych laboratoriach. Powstało w ten sposób kilka zupełnie różnych i dość dziwacznych tworów. W kilku laboratoriach próbowano do zapisu danych stosować arkusze kalkulacyjne, co dość szybko okazało się pomysłem niefortunnym, gdy ilość danych stała się duża, a potrzebna struktura – bardziej złożona od pojedynczej tabelki. Były też próby stworzenia specjalizowanych struktur relacyjnych, także prowadzące do niepokojących rezultatów, np. dla jednego z detektorów utworzono kilkaset tabel, a niektóre z nich miały ponad tysiąc (!) kolumn. Takie specjalizowane dla poszczególnych detektorów rozwiązania, nawet gdyby wykonane były poprawnie, i tak miałyby poważne wady: • utrzymanie kilkunastu baz o zupełnie różnej strukturze wymagałoby bardzo wiele pracy i zdecydowanie przerastałoby możliwości niewielkiego zespołu; • do każdej z wyspecjalizowanych struktur danych trzeba byłoby stworzyć osobną aplikację, a następnie je niezależnie utrzymywać; to także wymaga bardzo potężnych sił, zdecydowanie przewyższających te będące do dyspozycji; • scalenie danych w jedną bazę centralną byłoby bardzo trudne. Koncepcję tworzenia niezależnych struktur dla każdej z baz satelickich należało zatem odrzucić. Zdecydowano się na stworzenie jednej, uniwersalnej generycznej struktury danych, stosowanej we wszystkich bazach satelickich i dla wszystkich typów detektorów oraz komponentów. W strukturze tej, przedstawionej na rysunku 2, znaczną część stanowią słowniki metadanych (oznaczone na diagramie kolorem szarym), które definiują typy detektorów i komponentów oraz opisujące je dane i struktury wyników testów. Stosując ujednoliconą strukturę generyczną uzyskano ważne korzyści: • radykalnie ułatwiono zarządzanie rozwojem systemu; • umożliwiono stworzenie jednej uniwersalnej aplikacji, sterowanej metadanymi; • znacznie ułatwiono gromadzenie danych w bazie centralnej, struktura bazy centralnej może bowiem być bardzo podobna do struktury baz satelickich. 5 Ze stosowaniem struktur generycznych wiążą się oczywiście także pewne problemy: • struktury te zwykle prowadzą do trudniejszych zapytań, a przez to do gorszej wydajności systemu; w tym przypadku jednak przed podjęciem ostatecznej decyzji o zastosowaniu struktur generycznych przeprowadzono intensywne testy na realistycznie dużych danych próbnych; • założenie jednakowej struktury wszystkich baz satelickich prowadzi do konieczności równoczesnego wprowadzania poprawek do nich wszystkich; jednak jest to i tak zadanie łatwiejsze niż zapanowanie nad poprawkami wprowadzanymi niezależnie do kilkunastu różnych struktur. group of DEFINITION OF PARAMETER of type DETECTOR # DETECTOR CODE * NAME o DESCRIPTION consists of # * o o o * PARAMETER CODE NAME SEQUENTIAL NO UNITS OF MEASURE DESCRIPTION IS ACTIVE MANUFACTURER in group PARAMETER defines defined by of type includes # * * o # VALID FROM o VALID TO o VALUE COMPONENT TYPE DERIVATION * DERIVATION TYPE o DESCRIPTION o QUANTITY source of COMPONENT TYPE # * * o source of derivative TYPE CODE NAME IS ACTIVE DESCRIPTION # * * o . DATA TYPE CODE NAME ELEMENTARY TYPE DESCRIPTION of type belongs to processed by consists of DATA TYPE . . of type of type # * * o o o o o o * PROCESS CODE NAME TYPE SEQUENTIAL NO UNITS OF MEASURE X LABEL Y LABEL Z LABEL DESCRIPTION IS ACTIVE consists of defines defined by # o o o o o o * PROCESS DATE DESCRIPTION X SIZE Y SIZE Z SIZE VALUE TABLE PROCESSED BY IS SKELETON described by ALLOWABLE VALUE # * o o o SEQUENTIAL NO VALUE HIGH VALUE MEANING NUMERICAL VALUE DEFINITION OF PROCESS PARAMETER # * o o o * * PARAMETER CODE NAME SEQUENTIAL NO UNITS OF MEASURE DESCRIPTION IS RESULT IS ACTIVE # o * o o o defined by PROCESS PARAMETER o VALUE o DESCRIPTION derivative in derivative VALID FROM VALID TO DERIVATION TYPE LOCATION POSITION NO DESCRIPTION of componen has describes BLOB # * o o o o o BLOB ID BLOB VALUE BLOB DATE FILE NAME FILE PATH FILE OWNER DESCRIPTION of defines source of COMPONENT DERIVATION of test has parameters . of type has source of for PROCESS DEFINITION OF PROCESS COMPONENT ID USER CODE SERIAL NUMBER DESCRIPTION IS SKELETON IS VIRTUAL LAST MODIFIED tested by delivered by constrained by belongs to # o o o * * * derivative belongs to consists of in group coded by COMPONENT described by includes # GROUP CODE * NAME o DESCRIPTION creates cod manufactured b belongs to COMPONENT GROUP # DATABASE CODE * NAME creates delivers of described by belongs to DATA BASE MANUFACTURER CODE site NAME IS LAB located in DESCRIPTION defines COMPONENT STATE # o * o o o o VALID FROM VALID TO EXISTENCE QUALITY ACCEPTED IMPORT DATETIME EXPORT DATETIME of type BLOB TYPE # MIME TYPE o NAME Rysunek 2. Diagram ER generycznej struktury danych baz satelickich (fragment) Ze względów wydajnościowych zdecydowano, by do przechowywania wyników pomiarów zastosować struktury relacyjno-obiektowe: atrybut VALUE TABLE w encji PROCESS jest zagnieżdżoną tablicą. 2.6. Aplikacje i API Zarówno dla baz satelickich jak dla bazy centralnej stworzyć trzeba aplikacje umożliwiające wprowadzanie, a przede wszystkim wygodne wyszukiwanie, przeglądanie i zestawianie danych. Wszystkie aplikacje w systemie są udostępniane wyłącznie przez WWW. Do stworzenia obecnie funkcjonujących wersji użyto języka PHP, w dalszym rozwoju 6 systemu planowane jest jednak przejście na inne technologie, przede wszystkim JSP. Część aplikacji przeznaczona jedynie dla bazy centralnej (np. edycja słowników metadanych) stworzona została za pomocą Oracle Web Toolkit w języku PL/SQL. Oprócz aplikacji interaktywnych niezbędne jest także stworzenie odpowiedniego interfejsu programistycznego (API) do bazy centralnej, który umożliwi korzystanie z danych bezpośrednio w programach obliczeniowych. API musi być przystosowane do współpracy ze specjalizowanym, opracowanym w CERN systemem obliczeniowo-prezentacyjnym AliRoot [6], a także do użycia w strukturze obliczeń rozproszonych opartych o infrastrukturę DataGrid [7]. 3. Śledzenie obiegu komponentów i danych Jednym z najważniejszych zadań konstrukcyjnej bazy danych jest śledzenie obiegu komponentów. Baza powinna przechowywać informacje o tym w którym laboratorium znajduje się każdy komponent, a także historię jego obiegu. Zadanie komplikuje fakt, że w trakcie produkcji komponenty mogą być montowane do komponentów złożonych i przez to tracić samodzielność; mogą także być dzielone na mniejsze części. 1. Tworzenie 2. Wyrejestrowanie 3. Zarejestrowanie Satelicka b.d. Centralna b.d. 4. Destrukcja Rysunek 3. Uproszczony schemat śledzenia obiegu komponentów Przepływ informacji o położeniu komponentu ilustruje rysunek 3. Informacje o obiegu komponentów przechowywane będą w repozytorium w bazie centralnej. Ponieważ jednak awaria łącza do bazy centralnej nie może powodować wstrzymania produkcji, zarejestrowanie nowego komponentu odbywa się w bazie satelickiej; następnie, gdy komponent opuszcza dane laboratorium, zostaje wyrejestrowany, a gdy przybędzie do następnego laboratorium, zostaje zarejestrowany. Gdy komponent przestaje istnieć na skutek fizycznego zniszczenia lub zamontowania w innym komponencie, fakt ten jest rejestrowany w bazie satelickiej laboratorium, w którym nastąpiło zniszczenie komponentu, a następnie informacja o tym jest przekazywana do bazy centralnej. 7 4. Obieg informacji w rozproszonej bazie danych Niewątpliwie najtrudniejszym zadaniem, które stanęło przed twórcami omawianego systemu informacyjnego, jest zorganizowanie obiegu informacji między bazami danych. Poczyniono tu następujące ważne założenia, nieco upraszczające problem: • nie jest możliwa wymiana danych bezpośrednio między bazami satelickimi, konieczne jest pośrednictwo bazy centralnej; • słowniki metadanych są konfigurowane centralnie i dystrybuowane do wszystkich baz satelickich; w bazach tych nie można metadanych zmieniać; • wymiana danych dotyczących komponentów odbywać się będzie zawsze „całymi komponentami”, tj. nie jest możliwe przesłanie cząstkowych danych dotyczących komponentu. 4.1. Check-in i check-out Ważnym problemem, który trzeba rozwiązać w tego typu strukturze rozproszonej, jest synchronizacja wprowadzania modyfikacji do danych. Gdyby bowiem zdarzyło się, że te same dane są modyfikowane w dwóch bazach równocześnie, to podczas transferu do bazy centralnej nastąpiłby konflikt. Aby zapobiec tego typu sytuacji wprowadzono mechanizmy check-in i check-out, podobne do znanych z systemów zarządzania wersjami oprogramowania. • Gdy w bazie satelickiej wystąpi potrzeba modyfikowania danych, zgłasza ona do bazy centralnej żądanie operacji check-out i dopiero po pomyślnym jej wykonaniu może modyfikować dane. Oczywiście operacja ta musi być poprzedzona transferem lub odświeżeniem samych danych, które mają być modyfikowane. • Po zakończeniu modyfikowania danych są one transferowane do bazy centralnej. Jeśli baza satelicka nie jest zainteresowana dalszym utrzymywaniem „wyłączności” prawa modyfikacji danych, to wykonuje operację check-in, tym samym umożliwiając innym bazom wykonanie check-out i modyfikację danych. Operacje check-in i check-out, podobnie jak cała wymiana danych, dotyczą zawsze kompletnych danych komponentu. 4.2. Dodatkowe trudności Konstruując system obiegu informacji trzeba było wziąć pod uwagę ostre wymagania użytkowników, które dodatkowo komplikują problem. Potrzebna jest mianowicie możliwość pobrania danych z bazy satelickiej do bazy w komputerze przenośnym. Oznacza to, że obieg fizycznych komponentów i dotyczących ich danych może się różnić. Komponent pozostaje w laboratorium, gdy dane obrabiane są w komputerze przenośnym, poza bazą satelicką związaną z tym laboratorium. Problem rozwiązano w sposób następujący. • Baza na komputerze przenośnym jest traktowana równorzędnie z bazami satelickimi. Aby więc przenieść do niej dane, trzeba je najpierw skopiować do ba- 8 • zy centralnej, a następnie dopiero z niej pobrać dane do bazy na komputerze przenośnym. Aby nie dopuścić do całkowitego zerwania związku między danymi komponentu a samym komponentem założono, iż w normalnym trybie operację check-out może wykonać tylko baza danych związana z laboratorium posiadającym fizycznie komponent. Jeśli potrzebne jest pobranie danych na komputer przenośny, baza „posiadająca” komponent musi nie tylko wykonać operację check-in, ale także wyrazić jawnie zgodę na wykonanie check-out przez inną bazę. Niezbędna jest także możliwość pracy z danymi komponentów w sytuacji przejściowego braku łączności z bazą centralną. Oznacza to, że nawet jeśli nie istnieje możliwość pobrania znacznika check-out na dane komponentu, może być konieczne udostępnienie tych danych do edycji. W takiej sytuacji – nazwanej trybem wymuszonym – dane mogą być jednocześnie modyfikowane w więcej niż jednej bazie; przy zapisywaniu ich do bazy centralnej konieczne jest więc dokonanie rozstrzygnięcia ewentualnych konfliktów. Kolejna trudność nie wynika z wymagań użytkowników, ale z samego charakteru rozproszenia bazy. Otóż poszczególne serwery rozmieszczone będą niemal dookoła kuli ziemskiej (od Indii po USA), znajdować się zatem będą w różnych strefach czasowych. Dlatego zdecydowano, że dane zawierające datę i czas reprezentowane będą w formie uwzględniającej strefy czasowe. 5. Zastosowanie XML Heterogeniczność przyjętego rozwiązania powoduje, że nie jest możliwe skorzystanie z gotowych rozwiązań dla rozproszonych baz danych, np. z wbudowanych w niektóre systemy możliwości replikacji danych. Konieczne jest zatem stworzenie specjalizowanych rozwiązań do wymiany danych. XML stanowi bardzo dobry środek do elektronicznej wymiany danych, przede wszystkim ze względu na łatwość tworzenia specjalizowanych dialektów oraz szeroką dostępność narzędzi programistycznych (por. także [9]). W naszym projekcie postanowiono zastosować język XML do wymiany informacji między bazami w heterogenicznym rozproszonym systemie informacyjnym. XML okazał się też bardzo przydatny w tworzeniu pomocniczych systemów obiegu dokumentacji. 5.1. XML w wymianie danych Specjalnie zaprojektowane dokumenty („komunikaty”) w języku XML użyte będą do wymiany informacji między bazą centralną a bazami satelickimi: • do dystrybucji metadanych z bazy centralnej do baz satelickich; • do przekazywania informacji związanych z operacjami check-in i check-out oraz rejestrowania i wyrejestrowywania komponentu; • do transferu danych komponentów między bazami. 9 Konieczne okazało się zastosowanie dwóch trybów transferu: • on-line – potrzebny do przeprowadzania operacji check-in, check-out oraz rejestrowania i wyrejestrowywania komponentu; ponieważ operacje te wiążą się z zapisem danych kontrolnych w obu współdziałających bazach, niezbędne jest wprowadzenie mechanizmu zatwierdzania transakcji rozproszonych typu two phase commit; • off-line – używany do transferu danych. 5.2. XML – technologia Zdecydowano, by w projektowanych komunikatach XML używać przestrzeni nazw oraz schematów XML. Dzięki temu podstawowe sprawdzenie poprawności przekazywanych danych wykonywane jest przez standardowe narzędzia (parsery XML) i nie wymaga dodatkowej pracy. Do tworzenia oraz analizy przesyłanych dokumentów XML użyto pakietu Oracle XML Developers’ Toolkit (XDK), napisanego w języku Java i dobrze współdziałającego ze stosowanymi w projekcie bazami danych i serwerami HTTP. W szczególności używa się technologii XSU, służącej do generowania dokumentów XML na podstawie zapytań SQL do relacyjnej bazy danych (patrz [10]). Do formatowania i transformacji dokumentów XML stosuje się język XSLT. Analizę leksykalną przesyłanych dokumentów XML wykonuje się z użyciem parserów wchodzących w skład XDK. 6. Systemy pomocnicze Ponieważ powstający system jest dość złożony, konieczne stało się opracowanie pomocniczych systemów wspomagających prace projektowe i administracyjne. Jeden z tych systemów, wspomagający obieg dokumentacji, opiera się na technologiach związanych z XML. Powstająca rozproszona baza danych wymaga dokumentowania, a zadania zarządzania nią (np. dystrybucji kolejnych wersji) powinny być jakoś nadzorowane. Do tego celu tworzony jest system obiegu dokumentacji, o następujących zadaniach: • sformalizowany zapis i prezentacja w WWW wymagań użytkownika (user requirements) i wymagań co do oprogramowania (software requirements); • rejestracja zadań projektowych i administracyjnych; przypisanie ich do wymagań oraz przydzielenie konkretnym osobom do wykonania; • śledzenie wykonania zadań; • tworzenie listy często zadawanych pytań wraz z odpowiedziami itp. System ten, jak widać, nie obejmuje typowej dokumentacji technicznej samej bazy danych (ta dokumentacja jest tworzona za pomocą narzędzia CASE) ani dokumentacji użytkowej aplikacji. 10 Przyjęto następujące dodatkowe założenia: • informacje do systemu powinny być wprowadzane przez uprawnionych użytkowników za pomocą interfejsu bazującego na WWW; • informacje te następnie powinny być dystrybuowane w postaci stron WWW, w formie zdatnej do dalszego przetwarzania. Wyjściowe informacje powinny mieć dwojaki charakter: • roboczych stron WWW informujących o zadaniach i postępie w ich realizacji; • oficjalnych dokumentów zgodnych z wytycznymi ESA [11], o sformalizowanej i sztywnej strukturze, w których znaczna część zawartości jest stała albo bardzo rzadko zmieniana. Takie wymagania co do postaci wyjściowej skłaniają do przyjęcia następującego rozwiązania: • informacje stosunkowo często zmieniane (np. zadania, przydziały itp.) przechowywane będą w bazie danych, w specjalnie zaprojektowanej strukturze; • informacje stałe lub rzadko zmieniane będą reprezentowane z postaci plików XML. Uprawnieni użytkownicy będą mieli dostęp do zawartości bazy danych przez interfejs WWW (pierwsza wersja powstanie w technologii Oracle Web Toolkit w języku PL/SQL, wersja docelowa zapewne w technologii JSP). W przypadku stron roboczych całość informacji może być tworzona na podstawie zawartości bazy danych przy pomocy standardowych narzędzi. Tworzone dynamicznie dokumenty XML będą zaopatrzone w arkusze stylistyczne w XSL, będzie także dostępne opcjonalne przekształcanie ich do formatu HTML po stronie serwera. W przypadku oficjalnych dokumentów części wolnozmienne składowane w postaci plików XML będą łączone z częściami dynamicznie generowanymi na podstawie zawartości bazy danych. Proces ten będzie sterowany odpowiednim skryptem w języku XSLT. To stworzenia opisywanych tu stron WWW zastosowana zapewne zostanie technologia XSQL Server Pages (patrz [10]). 7. Podsumowanie Tworzenie bazy danych konstrukcji detektorów dla eksperymentu ALICE jest zadaniem ekscytującym, gdyż pozwala na udział w jednym z ambitniejszych współczesnych zamierzeń badawczych. Jednocześnie jednak, ze względu na nietypowe uwarunkowania, jest to zadanie dość trudne. Uwarunkowania te wymuszają budowę systemu rozproszonego i heterogenicznego i zorganizowanie w nim złożonej wymiany informacji. Dzięki zastosowaniu do 11 owej wymiany języka XML można było wykorzystać gotowe narzędzia programistyczne, dobrze współpracujące z użytymi bazami danych. Omawiana praca jest obecnie zaawansowana, ale jeszcze dość daleka od ukończenia. Projekt baz satelickich jest ukończony i obecnie trwają pierwsze wdrożenia w laboratoriach. Projekt bazy centralnej jest na ukończeniu. Trwają intensywne prace nad systemem wymiany danych i systemem obiegu dokumentacji. Mimo iż praca nie jest jeszcze ukończona, zgromadzone dotychczas doświadczenia pozwalają stwierdzić, że język XML bardzo dobrze nadaje się do wymiany danych w heterogenicznym systemie rozproszonym. Zastosowanie schematów, języka XSLT oraz gotowych standardowych narzędzi programistycznych pozwala znacznie zredukować nakłady pracy niezbędnej do wykonania zadania. Literatura 1. http://www.cern.ch/lhc 2. http://www.cern.ch/alice 3. Peryt W.: Informacja/oferta współpracy. Materiał wewnętrzny, Wydział Fizyki Politechniki Warszawskiej, 2000. 4. Eksperyment ALICE. Miesięcznik Politechniki Warszawskiej, nr 11, 2000. 5. http://det-dbalice.if.pw.edu.pl 6. http://alisoft.cern.ch/offline/aliroot-pro/manual.html 7. http://eu-datagrid.web.cern.ch/eu-datagrid 8. Traczyk T.: XML i XSL. Materiały XII Górskiej Szkoły PTI, Szczyrk 2000. 9. Traczyk T.: XML – uniwersalny język wymiany informacji w e-świecie. Proceedings of the 3rd conference IBIS'01 (Implementation of Business Information Systems) Global Information Society. Malmoe–Kopenhaga, wrzesień 2001. 10. Traczyk T.: Czy już warto używać XML? Tutorial, Materiały I Seminarium PLOUG, Warszawa 2001. 11. Software Engineering Standards. ESA Board for Software Standardisation and Control, 1994. dr inż. Tomasz Traczyk Politechnika Warszawska Instytut Automatyki i Informatyki Stosowanej ul. Nowowiejska 15/19, 00-665 Warszawa e-mail: [email protected] URL: http://www.ia.pw.edu.pl/~ttraczyk 12