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