Integracja danych i aplikacji przy użyciu wirtualnych repozytoriów

Transkrypt

1 Polsko-Japońska Wyższa Szkoła Technik Komputerowych Integracja danych i aplikacji przy użyciu wirtualnych repozytoriów Michał Lentner Polsko-Japońska Wyższa Szkoła Technik Komputerowych Praca doktorska napisana pod kierunkiem prof. dr hab. inż. Kazimierza Subiety Warszawa, styczeń 2008

2

3 Streszczenie Podstawowym celem rozprawy doktorskiej jest zbadanie nowych paradygmatów ułatwiających proces implementacji systemów informatycznych. Przedstawiona w niej została propozycja narzędzia programistycznego umożliwiającemu pracę programiście bazodanowemu na znacznie wyższym poziomie, niż umożliwiają to popularne współczesne rozwiązania. W tym celu stworzony został nowy, obiektowy język programowania, bezszwowo zintegrowany z konstrukcjami języka zapytań (zapytania jako wyrażenia), razem z jego rozproszonym, bazodanowo zorientowanym środowiskiem wykonawczym. Oprogramowanie to zapewnia funkcjonalność wielu istniejących narzędzi (takich jak np. języki programowania aplikacji baz danych, języki zapytań do baz danych, systemy zarządzania bazami danych, różnego rodzaju middleware) w jednym, spójnym, uniwersalnym, łatwym do wykorzystania i efektywnym w użyciu środowisku programistycznym. Praca została podzielona na siedem rozdziałów. W pierwszym rozdziale przedstawiamy problem integracji danych i aplikacji jako jednego z głównych czynników wpływającego na wydajność inżynierów wytwarzających oprogramowanie biznesowe. Problem ten definiujemy z punktu widzenia dwóch aspektów: integracji języka programowania z bazą danych, oraz integracji istniejących aplikacji w systemach rozproszonych. Rozdział drugi poświęcony jest kilku najbardziej znanym obecnie podejściom do integracji danych i aplikacji. Omawiamy tutaj zagadnienia związane z metodami łączenia aplikacji z relacyjnymi i obiektowymi bazami danych, jak również najważniejsze rodzaje middleware. 3

4 W rozdziale trzecim przedstawiamy skrótowo podejście stosowe do języków zapytań - teoretyczną bazę na podstawie której zaprojektujemy prototypowy język programowania/zapytań zintegrowany z obiektową bazą danych, funkcjonującą również jako middleware. W rozdziale czwartych przedstawimy architekturę zaproponowanego przez nas narzędzia oraz zaprezentujemy przykładowe scenariusze jego zastosowania w dziedzinie integracji danych i aplikacji. Kolejny rozdział, czyli rozdział piąty, jest nieformalnym opisem języka SBQL, rozszerzonego przez nas na potrzeby niniejszej pracy do kompletnego języka programowania. W związku z tym, iż język SBQL posiada szereg mechanizmów deklaratywnych, niezbędne jest zaprojektowanie wydajnych algorytmów optymalizacyjnych dla zapytań. Podstawowe algorytmy optymalizacyjne dla SBQL w środowisku scentralizowanym zostały już sformułowane, jednak optymalizacja zapytań rozproszonych wymaga dodatkowych technik. Temu zagadnieniu poświęcono zatem rozdział szósty. Rozdział siódmy stanowi szczegółowa dyskusja na temat integracji danych za pomocą aktualizowalnych perspektyw. Prezentujemy kod źródłowy prostego systemu trójwarstwowego (klient-serwer integracyjny-serwery kontrybucyjne) oraz objaśniamy mechanizm wymiany danych w takim środowisku. Ostatni rozdział, czyli rozdział ósmy, dokumentuje szereg niskopoziomowych decyzji, jakie zostały podjęte w celu zaimplementowania prototypu zaproponowanego przez nas narzędzia. Obok tekstu niniejszej pracy, prototyp ten jest jednocześnie podstawowym rezultatem badań podjętych przez autora rozprawy. 4

5 Summary The main objective of this Ph.D. thesis is to develop new software construction paradigms that make the implementation of information systems easier. We have proposed an application development environment allowing a database programmer to work on a much higher level of abstraction than it is possible when current solutions are used. To this end, we have created a new object-oriented programming language, seamlessly integrated with query language constructs (queries as expressions) and with its distributed, database-oriented runtime environment. Our software provides functionality of many existing tools (such as: database programming languages, database query languages, database management systems, several kinds of middleware) in a single, consistent, universal, easy to use and effective to apply programming environment. The thesis is divided into seven chapters. In the first chapter, a brief introduction to the problem of data and application integration is discussed. The need for integration is presented as one of the most important factors influencing the work of today s business application developers. The problem is defined from the point of view of two aspects: the integration of a programming language and a database management system, as well as the integration of existing applications being parts of distributed systems. 5

6 The second chapter is focused on highlighting some of the most popular approaches of data and application integration. We have discussed several issues associated with existing methods of connecting applications with relational and object-oriented databases, as well as the most important types of middleware. In the third chapter the Stack-Based Approach to query languages is briefly described. It is presented as a theoretical base allowing us to construct a prototype programming/query language integrated with an object-oriented database having middleware features. In the fourth chapter the architecture of our prototype solution is introduced. Several typical scenarios of its application in the area of data and application integration is also presented. The fifth chapter contains an informal description of the SBQL language, extended by us to a fullyfledged database programming language. Since SBQL contains declarative constructs, it was necessary to design efficient query optimization algorithms. The most important optimizations for SBQL queries executed in a centralized environment have already been designed in other works. However, distributed query processing requires completely new solutions. This issue has been discussed in the sixth chapter. The seventh chapter contains a detailed discussion on data integration with the use of updateable views. The source code of a simple, three-tier (client, integration server, contributory server) system is presented. We have also explain the functionality of several low-level mechanisms responsible for data exchange between particular nodes of the system. The last chapter documents several low-level decisions which have been made in order to implement a prototype of the tool discussed in this thesis. Apart from the text of the disseration, the prototype is the main product of the research conducted by the Author. 6

7 Spis treści Rozdział 1: Wprowadzenie... 9 Rozdział 2: Stan sztuki w dziedzinie integracji danych i aplikacji Rozdział 3: Podejście stosowe do języków zapytań Rozdział 4: Koncepcja architektury narzędzia RAD nowej generacji Rozdział 5: Język SBQL w systemie Odra Rozdział 6: Optymalizacja zapytań rozproszonych Rozdział 7: Integracja danych rozproszonych Rozdział 8: Prototyp Podsumowanie pracy Dodatek A: Przykładowy program SBQL Dodatek B: Kod źródłowy zintegrowanego systemu połączeń kolejowych Dodatek C: Ewaluacja przykładowego zapytania SBQL Dodatek D: Przetwarzanie danych XML za pomocą SBQL Dodatek E: Ważniejsze operacje maszyny wirtualnej SBQL Lista ważniejszych akronimów użytych w pracy Literatura

8

9 Rozdział 1: Wprowadzenie Eksplozja informacji W ostatnich latach obserwowana jest gwałtowna eksplozja ilości informacji, z jaką mają do czynienia systemy informatyczne współczesnych organizacji. Zbadano, iż w ciągu trzech poprzednich lat wygenerowano więcej informacji, niż zapisano w ciągu całej historii ludzkości [1]. Niestety, za tą eksplozją informacji oraz rozwojem potrzeb nie nadąża rozwój narzędzi informatycznych. Nie dziwi więc, iż systemy wielu organizacji często załamują się pod wpływem wielkiej ilości i różnorodności danych, jakie muszą być przetwarzane przez poszczególne (często odizolowane od siebie) składniki tych systemów. Okazuje się, że wraz z rozwojem potrzeb integracyjnych problem przetwarzania danych masowych w rozproszonych i heterogenicznych środowiskach zdobywa coraz większe znaczenie, a narzędzia wspomagające czynności z tym związane stają się coraz potrzebniejsze [2]. Nieprzerwanie rosnąca złożoność tych narzędzi wiąże się jednak z tym, iż programiści coraz rzadziej zdolni są opanować wszystkie czynności, jakie wynikają z produkcji oprogramowania w takich środowiskach. Ilość technologii, interfejsów programistycznych, języków, bibliotek, protokołów, serwerów, etc., które współczesny programista musi znać i używać jest wprost gigantyczna. Ten ciągle rosnący zakres technologii jest jedną z przyczyn ogromnej zlożoności współczesnego oprogramowania, a co za tym idzie - kosztów jego wytwarzania oraz pielęgnacji. Ponieważ w przyszłości problem ten będzie narastał, nieodzowne są prace nad nowymi, prostymi w obsłudze, uniwersalnymi i homogenicznymi narzędziami 9

10 programistycznymi wspomagającymi tworzenie aplikacji baz danych w środowiskach rozproszonych. Obiektowość Walka ze złożonością oprogramowania wymaga przede wszystkim sięgnięcia do źródeł tej złożoności, czyli sposobu postrzegania problemów przez człowieka oraz implementacji tych problemów za pomocą maszyny. Okazuje się, iż im mniejsze są różnice, tym prostsze jest tworzenie systemów informatycznych oraz tym mniejszy jest koszt ich wytworzenia i pielęgnacji. Praktyka pokazała, iż jednym z najbardziej zaawansowanych obecnie paradygmatów umożliwiających niwelowanie tych różnic jest obiektowość. Na przestrzeni lat okazało się, iż pojęcia takie jak obiekt, klasa, asocjacja, metoda, specjalizacja, generalizacja, polimorfizm itp., bliższe są ludzkiemu sposobowi postrzegania świata, a realizowana przy ich pomocy struktura danych/oprogramowania staje się bardziej intuicyjna. Dziś normą jest obiektowa analiza i projektowanie oprogramowania za pomocą obiektowych notacji graficznych, oraz implementacja oprogramowania za pomocą obiektowych języków programowania [6]. Rozwój obiektowości nie jest jednak zakończony. Pomimo wiodącej roli tego podejścia w analizie oraz projektowaniu systemów oraz w językach programowania, idee obiektowości nie zyskały dotychczas szerokiego uznania na polu baz danych. Standard ODMG [12], czyli próba ustandaryzowania obiektowego modelu danych, języka zapytań i interfejsu programistycznego do obiektowych baz danych okazał się klęską. Zaprezentowane w nim idee okazały się w dużym stopniu nieimplementowalne dla twórców systemów zarządzania bazami danych, oraz nieakceptowalne dla programistów aplikacji. Również powstające niezależnie od tego standardu systemy zarządzania obiektowymi bazami danych nie zyskały dotychczas szerszego uznania, dobrze sprawdzając się jedynie w niszowych zastosowaniach. Mnogość tymczasowych rozwiązań zapewniejących mechanizmy odwzorowania relacyjno-obiektowego (realizowanych często ad-hoc przez środowiska przemysłowe) pokazuje jednak, jak ważne dla współczesnych programistów jest operowanie na bazach danych chociażby bez konieczności tłumaczenia struktur relacyjnych na struktury obiektowe i odwrotnie. Zalety obiektowych baz danych w stosunku do baz relacyjnych akcentowane w ubiegłej dekadzie nie straciły zatem nic ze swej aktualności [34, 36, 32]. Są to przede wszystkim: Znacznie bogatszy model danych. 10

11 Brak niezgodności impedancji pomiędzy modelem danych obiektowego języka programowania i bazy danych. Ortogonalna trwałość. Potencjalnie wyższa wydajność (zwłaszcza w zakresie przetwarzania asocjacji). Praktyczna realizacja tych postulatów stała się niestety trudniejsza niż początkowo przypuszczano. Niektórzy specjaliści uważają wręcz, że idea obiektowych baz danych okazała się niemożliwą do spełnienia utopią. Do najczęściej wymienianych wad obiektowych baz danych należą: Zbyt mocne powiązanie aplikacji z operacjami wykonywanymi na bazie danych. Przypadkowość rozwiązań, brak ogólnie przyjętego standardu, takiego jak SQL [87]. Brak lub utrudnione korzystanie z języka zapytań. Wszystkie te wady powodują, iż potrzebne są dalsze badania w tej dziedzinie. Niezbędne staje się opracowanie zupełnie nowych architektur obiektowych baz danych, dramatycznie innych od obecnie stosowanych. W przeciwnym razie bazy danych tego typu na zawsze skazane będą na zastosowania niszowe, jako rozszerzenia tradycyjnych języków programowania. Środowiska programowania aplikacji baz danych Bazy danych są krytycznym elementem każdej współczesnej aplikacji biznesowej. Programiści korzystają z baz danych w celu zapewnienia trwałości danym masowym oraz uzyskania do nich szybkiego i bezpiecznego dostępu. Ponieważ dane lokalne aplikacji oraz dane przechowywane w bazie danych należą do dwóch różnych światów, częścią praktycznie każdej współczesnej aplikacji jest warstwa odpowiedzialna za wymianę danych pomiędzy tymi światami. Implementacja takiej warstwy osiąga często nawet kilkadziesiąt procent objętości całego systemu, jest niejednokrotnie źródłem błędów i frustracji programistów. Nie dziwią więc ciągłe próby podejmowane przez światy naukowy i akademicki, zmierzające do integracji języków programowania z bazami danych. W idealnej sytuacji (postulowanej przez tzw. ortogonalną trwałość) dostęp do obiektów aplikacyjnych i obiektów bazy danych realizowany powinien być z użyciem dokładnie tych samych konstrukcji językowych. W praktyce taka bezszwowa integracja języka programowania z bazą danych nie została dotychczas osiągnięta w satysfakcjonujący sposób. Idea ta realizowana jest obecnie zazwyczaj poprzez rozszerzenie tradycyjnego języka programowania (np. Java) w taki sposób, by niektóre obiekty (np. będące instancjami specjalnej klasy) nie miały charakteru ulotnego 11

12 (znikały po wyłączeniu komputera), ale trwały (zapisywane były automatycznie na dysku komputera). Idea ta została pierwotnie zapoczątkowana przez tzw. języki z trwałością (np. Persistent Modula 3 [24], PJama [23], etc.), a następnie rozwijana w ramach obiektowych baz danych. Dzięki tym rozwiązaniom udało się przede wszystkim ujednolicić modele danych. Ten sam obiektowy model danych znajduje się zatem zarówno po stronie bazy danych, jak i języka programowania. Programista nie jest dzięki temu zmuszony do utrzymywania dwóch równoważnych struktur danych (np. tabel i obiektów), ale w przezroczysty sposób operuje na trwałych obiektach. Technika zapoczątkowana przez języki z trwałością stała się również inspiracją dla technologii wywodzących się ze środowisk przemysłowych i reprezentowanych przez techniki odwzorowania relacyjno-obiektowego. Rozwiązania takie jak Hibernate próbują połączyć zalety ortogonalnej trwałości, oraz dobrze znanych systemów zarządzania relacyjnymi bazami danych. Realizowane jest to poprzez wprowadzenie dodatkowej warstwy metadanych (tworzonych przez programistę), odwzorowującej strukturę obiektową aplikacji na strukturę relacyjnej bazy danych. Języki z trwałością oraz bazujące na nich rozwiązania nie spotkały się z większym uznaniem z powodu wad, w szczególnością jednej która naszym zdaniem całkowicie je dyskwalifikuje. Wadą tą jest brak języka zapytań lub też język zapytań w szczątkowej formie. Powstaje z związku z tym pewien dysonans - operacje aktualizacyjne pozbawione są niezgodności impedancji, natomiast operacje wyszukiwawcze realizowane są w tradycyjny sposób (poprzez zagnieżdżanie zapytań jako literałów, proceduralne przetwarzanie za pomocą iteratorów [29], etc.). Brak możliwości wyjścia z tej sytuacji skłania niektórych autorów do stwierdzenia, że języki zapytań w obiektowych bazach danych nie mogą być poprawnie zdefiniowane, albo wręcz że nie są potrzebne. Zamiast tego proponuje się wyrażanie operacji wyszukiwawczych w bazie danych za pomocą języka takiego jak Java czy C#. Okazuje się tymczasem, że rozwiązania takie jak native queries są nie tylko nieporównywalnie uboższe nawet w stosunku do standardowego SQL, ale również praktycznie uniemożliwiają realizację technik optymalizacyjnych, bez których konstrukcje deklaratywne tracą sens. Naszym zdaniem eliminacja języków zapytań z obiektowych baz danych jest skazaniem ich na porażkę. To właśnie dzięki językowi SQL mógł mieć miejsce tak przytłaczający sukces relacyjnych baz danych. Język zapytań jest niezwykle istotnym składnikiem każdego liczącego się obecnie systemu zarządządzania bazą danych. Podstawowym zadaniem języka zapytań jest podwyższenie wydajności programistów poprzez dostarczenie do ich dyspozycji pojęciowych, makroskopowych 12

13 operacji, pozwalających zapisać złożone operacje związane z przetwarzaniem danych w zwartej, czytelnej i zrozumiałej formie. Powszechną stała się opinia, że jedno zdanie napisane w języku zapytań może zastąpić kilka stron programu napisanego w języku programowania ogólnego przeznaczenia. Ma to krytyczne znaczenie dla tempa wytwarzania oprogramowania, jego kosztu, pielęgnacyjności i modyfikowalności. Następnym powodem jest dążenie do podwyższenia niezawodności produktów programistycznych, czemu sprzyja zwartość zapisu programu, konceptualizacja myślenia programisty i tzw. niezależność danych, przejawiająca się m.in. w abstrahowaniu od ich fizycznej organizacji. Jeszcze jednym powodem jest otwarcie nowych możliwości dla automatycznej optymalizacji programów. Operacje makroskopowe dają w tym względzie znacznie większe możliwości niż języki niskiego poziomu. Ten fakt jest potwierdzony przez szereg badań dowodzących, że dla złożonych zapytań automatyczny optymalizator daje lepsze wyniki niż ręczna optymalizacja [4, 39]. Wydaje się że różnice między językami zapytań i tradycyjnymi językami programowania są na tyle duże, iż ich integracja jest po prostu niewykonalna. Naszym zdaniem nie jest możliwe stworzenie wersji języka takiego jak Java czy C#, która w czysty semantycznie sposób pozwalałaby połączyć ze sobą konstrukcje języka proceduralnego i języka zapytań. Przyczyną tego stanu rzeczy jest to, iż języki zapytań bazują na zupełnie innych założeniach semantycznych i optymalizacyjnych: konstrukcje imperatywne vs. konstrukcje deklaratywne, optymalizacja podczas kompilacji vs. optymalizacja podczas czasu wykonania, algorytmy i struktury danych vs. tabele (w przypadku systemów relacyjnych) i indeksy, wątki vs. transakcje, null jako wskaźnik vs. null jako brak danych, różnice w składni, systemach typów, sposobie enkapsulacji danych, itp. Różnice te znane są powszechnie pod nazwą niezgodność impedancji. Jedynym sposobem na rozcięcie tego węzła gordyjskiego jest wprowadzenie nowej klasy języków programowania, w których wyrażenia byłyby tożsame z zapytaniami, a rezultatami wyrażeń mogły być kolekcje. Wyrażenia takie mogłyby posiadać właściwości tradycyjnych języków programowania (literały, nazwy, operatory), ale mogłyby również umożliwiać deklaratywne przetwarzanie dużych kolekcji danych. Operatory takiego języka powinny dawać się swobodnie łączyć z innymi konstrukcjami języka, wliczając w to konstrukcje imperatywne, instrukcje sterujące oraz abstrakcje programistyczne. Język taki powinien służyć zarówno do programowania strony serwera bazy danych, ale również strony klienckiej. Programy takiego języka powinny być uruchamiane w środowisku posiadającym cechy współczesnych systemów zarządzania bazami 13

14 danych (trwałość, indeksy, optymalizacja zapytań, bezpieczeństwo, transakcje, itd.), ale również maszyn wirtualnych (wirtualny zbiór instrukcji, pamięć, I/O). Poprzez przeniesie poziomu abstrakcji na znacznie wyższy poziom niż w obecnych językach programowania, języki takie pozwoliłyby na znaczące skrócenie czasu programowania oraz zwiększenie jakości wytwarzanego przy ich użyciu oprogramowania. Integracja rozproszonych danych i aplikacji We współczesnych systemach informatycznych zauważyć można tendencję zwiększonego zapotrzebowania na zapewnienie możliwości komunikacji pomiędzy programami komputerowymi, czy wręcz całymi systemami informatycznymi tych samych (Enterprise Application Integration, EAI), bądź całkowicie odrębnych (Business To Business, B2B) organizacji. Użytkownicy domagają się natychmiastowego dostępu do wszystkich informacji jakie posiada dana organizacja, niezależnie od systemu, w jakim informacja ta jest przechowywana. Zadaniem projektantów jest zatem sprawienie, by poszczególne systemy mogły ze sobą współpracować, czyli połączenie tzw. wysp automatyzacji (odizolowanych od siebie systemów realizujące ściśle określone zadania) w jeden wirtualny system informatyczny. Jak dotąd istnieje szereg kontrowersji co do tego, jak taki wirtualny system miałby wyglądać od strony technicznej. Przykładowo, niektórzy specjaliści postulują rozszerzenie tradycyjnego języka programowania o zestaw narzędzi (zwykle bibliotek i/lub generatorów kodu źródłowego) umożliwiających do pewnego stopnia przezroczyste dla programisty wykorzystywanie rozproszonych zasobów. Inni postulują oparcie integracji na tzw. usługach, komunikujących się ze sobą za pomocą standardowych protokołów i języków opisu danych. Jeszcze inni są zwolennikami integracji na poziomie procesów biznesowych, albo poprzez portale biznesowe. Istnieje także grupa zwolenników integracji aplikacji na poziomie danych - poprzez replikację danych (np. w hurtowni danych), albo federację baz danych. Cechą wspólną wszystkich tych rozwiązań jest dążenie do tego, by każda informacja była dostępna natychmiast, niezależniej od tego gdzie i w jakiej postaci jest ona w rzeczywistości przechowywana. Mechanizmy integracyjne muszą zatem działać w czasie rzeczywistym, oraz być na tyle sprawne, aby były w stanie współpracować z różnorodnymi bazami danych, serwerami aplikacji, systemami zarządzania treścią, hurtowniami danych, systemami przepływu prac, językami programowania, protokołami wymiany danych itp. 14

15 Middleware Podstawowym mechanizmem warunkującym sprawną komunikację w środowisku rozproszonym jest tzw. wartstwa pośrednia (middleware) [10]. Jest to oprogramowanie znajdujące się pomiędzy systemem operacyjnym oraz aplikacją po każdej stronie systemu rozproszonego. Istnieje wiele rodzajów middleware: rozproszone obiekty, serwery aplikacji, monitory transakcyjne, serwery integracyjne, brokery komunikatów i inne. Najważniejszym zadaniem middleware jest uczynienie procesu wytwarzania oprogramowania prostszym, poprzez dostarczenie abstrakcji programistycznych wspólnych dla każdej strony systemu rozproszonego, ukrycie heterogeniczności oraz dystrybucji systemów komputerowych, jak również niskopoziomowych szczegółów dotyczących komunikacji. Warto przy tym zauważyć, że aspekt przezroczystości w komunikacji rozproszonej nie jest jedynie domeną middleware. Tematyka ta jest również przedmiotem badań w dziedzinie rozproszonych/ federacyjnych baz danych [47, 48, 51]. Na przestrzeni lat specjaliści z tej dziedziny wypracowali znacznie bardziej zaawansowane aspekty przezroczystości niż te, które charakteryzują współczesne middleware. Do najważniejszych form przezroczystości zapewnianych przez federacyjne (zwane również wirtualnymi) bazy danych należą: przezroczystość dostępu, położenia, współbieżności, heterogeniczności, skalowania, fragmentacji, replikacji, optymalizacji, awarii, migracji, i inne. [89] Tradycyjne rodzaje middleware nie wspierają większości z tych własności, ponieważ nie są one nastawione na przetwarzanie kolekcji, ani danych trwałych za pomocą konstrukcji deklaratywnych. Middleware posiada zwykle charakter proceduralny, czyli znacznie niższy poziom abstrakcji niż języki zapytań. Konieczności przetwarzania kolekcji w systemie rozproszonym nie można jednak uniknąć. Problemy z tym związane widać szczególnie na przykładzie technologii rozproszonych obiektów. Przykładowo, w technologiach takich jak CORBA [25] podjęto próbę ukrycia różnic w dostępie do danych zdalnych i lokalnych. Ta iluzja okazała się zgubna dla wielu projektów programistycznych ze względów wydajnościowych. Źródłem problemów była pokusa operowania na danych zdalnych za pomocą takich samych algorytmów, jakie byłyby użyte gdyby dane te znajdowały się w pamięci operacyjnej lokalnego komputera. Niestety, okazuje się że ze względu na naturę pracy w sieciach komputerowych (czas dostępu, awaryjność) algorytmy te nie mogą być takie same. Twórcy standardu CORBA podjęli próbę wprowadzenia dodatkowych usług (Query Service, Persistence Service) mających usprawnić obsługę danych masowych za pomocą języka zapytań. 15

16 Próba ta nie zakończyła się satysfakcjonującymi rezultatami, głównie ze względu na problem niezgodności impedancji pomiędzy językami zapytań i tradycyjnymi językami programowania. Podobna sytuacja dotyczy popularnej technologii EJB (Enterprise Java Beans) [52] - tzw. ziarna encyjne (Entity Beans) oraz działający na nich język zapytań EJB QL nie rozwiązują naszym zdaniem problemu przetwarzania rozproszonych danych masowych. Pomijając nawet fakt małych możliwości tych języków zapytań, są one wręcz bezużyteczne w sytuacji gdy potrzebna jest aplikacja kombinująca dane z różnych źródeł danych. Ze względu na niskopoziomową (poprzez API) pracę z middleware sytuacje takie wymagają gigantycznych nakładów programistycznych związanych z optymalizacją kodu. Optymalizacja taka rzadko jest możliwa do zrealizowania w idealny sposób poprzez człowieka, ponieważ niejednokrotnie realizacja tej samej operacji dostępu do danych może mieć wiele (np. tysiące) możliwych sposobów implementacji (tzw. planów wykonania). Automatyczna optymalizacja rozproszonych zapytań za pomocą technik znanych z rozproszonych baz danych mogłaby rozwiązać ten problem, niestety współczesne rodzaje middleware nie posiadają takiej możliwości. Panujące obecnie trendy polegają raczej na ucieczce od tego złożonego problemu. Przykładowo, najnowsze rozwiązania, oparte na idei tzw. architektury zorientowanej na usługi (Service Oriented Architecture, SOA) całkowicie ignorują problem przetwarzania danych masowych. Ich zwolennicy przekonują, iż SOA operuje na poziomie usług, czyli na znacznie wyższym, niż zwykłe dane (wysokopoziomowa integracja usług vs. niskopoziomowa integracja danych). Automatycznie zakłada się zatem, że zdalna procedura (usługa) zaprojektowana została w taki sposób, by obsłużyć wszystkie możliwe sytuacje biznesowe związane ze zdalnym dostępem do zasobów. Naszym zdaniem jest to złudne założenie, które prowadzi do odkrywania na nowo dobrze znanych mechanizmów (np. transakcje dla WebServices) przetwarzania danych w środowisku rozproszonym. Obiektowa baza danych jako middleware We współczesnych systemach informatycznych bazy danych wykorzystywane są w projektach integracyjnych najczęściej wówczas, gdy problem da się rozwiązać za pomocą replikacji, federacji lub poprzez budowę hurtowni danych. Jeśli projekt integracyjny wymaga wykorzystania takich pojęć jak logika aplikacji, wówczas wykorzystywane są inne strategie integracyjne, np. integracja poprzez usługi. Zauważmy jednak że te ograniczenia baz danych wynikają z prostoty relacyjnego modelu danych i nie dotyczą baz obiektowych. Obiektowe bazy danych potencjalnie posiadają zarówno zalety relacyjnych baz danych, jak i języków programowania, dlatego każda znana strategia integracyjna może być wyrażona w kontekście takiego systemu. 16

17 Obiektowe bazy danych w projektach integracyjnych posiadają szereg znaczących zalet. Znacznie wyższy poziom abstrakcji, na którym pracuje potencjalny inżynier integracyjny korzystający z obiektowej bazy danych pozwala często wyrazić w jednej linii kod, który przy użyciu np. środków opartych na standardzie CORBA przyjąłby postać dużego programu. Ma to znaczenie nie tylko dla produktywności programistów, łatwości i stabilności tworzonego przez nich oprogramowania, ale również umożliwia automatyczną optymalizację operacji na rozproszonych danych. Taka automatyczna optymalizacja nie jest możliwa jeśli dany komponent systemu (np. usługa) zostanie zaprogramowany w ramach niskopoziomowego języka programowania. Jeśli integrowane mają być dane pochodzące ze źródeł heterogenicznych i integracja ma zachodzić w czasie rzeczywistym, wówczas konieczne jest zbudowanie federacyjnej bazy danych. Obiektowe bazy danych znane są tymczasem ze znacznie bogatszego modelu danych, pozwalającego na łatwiejsze wyspecyfikowanie kanonicznego modelu danych obowiązującego w federacji. Pozwala to zintegrować istniejące, rozproszone i heterogeniczne zbiory danych do postaci jednego, wirtualnego repozytorium wszystkich danych jakimi dysponuje organizacja. Nie zależy to od tego, czy integrowane zasoby to relacyjne, albo obiektowe bazy danych, repozytoria XML, czy dane multimedialne. Tak różnorodne modele danych stanowią problem dla relacyjnego modelu danych, ale nie dla wielu istniejących modeli obiektowych. Zauważmy, że nawet jeśli jako kanoniczny model danych wybrany zostanie stosunkowo uniwersalny model danych XML, taka decyzja nie gwarantuje sukcesu w integracji danych. Najpoważniejszymi problemami są tutaj m.in.: sposób opisu globalnych danych danych, język zapytań i jego optymalizacja, oraz aktualizacji danych z poziomu globalnego użytkownika. Ze względu na brak globalnego identyfikatora obiektu (obecnego np. w CORBA, ale nie istniejącego obecnie w innych niż obiektowe modelach danych), nie jest możliwe stworzenie generalnej metody modyfikowania zintegrowanych danych. Z tego powodu, choć większość obecnych federacyjnych baz danych bez problemu potrafi udostępniać dane do odczytu, operacje modyfikujące stan poszczególnych baz danych nie są możliwe w ogóle, albo tylko w niektórych przypadkach. Ponieważ interfejs do danych globalnych zwykle w federacyjnych bazach danych definiowany jest jako perspektywa, problem ten można rozszerzyć do dużo szerszego i znanego od wielu lat problemu aktualizacji perspektyw. Perspektywy znane z systemów relacyjnych (traktowane jako zapamiętane zapytynia) umożliwiają tymczasem aktualizację danych wirtualnych tylko w najprostszych przypadkach. Przykładowo, nie można aktualizować danych uzyskanych poprzez złączenie (z kilkoma drobnymi wyjątkami), albo wygenerowanych za pomocą operatorów agregujących. Przezroczystość wszystkich operacji 17

18 realizowanych na perspektywach jest tymczasem szczególnie wymagana w federacyjnej bazie danych, gdzie perspektywy mogą integrować dane z tysięcy źródeł danych. Okazuje się, że rozwiązanie problemu aktualizacji perspektyw musi wiązać się z wprowadzeniem dużo bardziej wyspecjalizowanej struktury pełniącej rolę perspektywy. Takie struktury zaprojektowane zostały dla obiektowych baz danych, i tylko w ich kontekście ich moc może być w pełni wykorzystana. Wiąże się to m.in. z koniecznością rozszerzenia identyfikatora obiektu do postaci umożliwiającej opisywanie wirtualnych danych. Wraz z definiowanymi przez twórców perspektyw generycznymi procedurami przeciążającymi podstawowe operacje na wirtualnych obiektach, identyfikatorami posiadającymi informację na temat perspektywy, oraz zapytania za pomocą którego obiekty wirtualne są generowane, perspektywy takie umożliwiają modyfikację dowolnych danych wirtualnych. Strategie integracyjne Specjaliści z dziedziny EAI zgodni są w jednej kwestii - żadna istniejąca obecnie metoda integracji, czy też technologia nie jest złotym środkiem na każdy problem integracyjny [3, 11, 102]. Przykładowo, dla pewnej organizacji, niezbędna może być integracja danych zawartych w jej bazach danych. Organizacja ta wymaga nieograniczonego dostępu do wszystkich swoich danych i nie jest w stanie przewidzieć wszystkich ścieżek dostępu teraz lub w przyszłości. Ponieważ zgodnie np. z architekturą SOA dostęp do nowego zbioru danych wiąże się z budową nowej usługi, oznacza to w takiej sytuacji każdorazową modyfikację systemu docelowego, co z różnych powodów (np. koszt) może być nieakceptowalne. Federacyjna baza danych jest więc tutaj najlepszym rozwiązaniem. Podobny problem może jednak nie dotyczyć takiej organizacji, która może skoncentrować się na integracji logiki aplikacji, a nie przetwarzaniu rozproszonych danych. Poszczególne operacje możliwe do realizacji na zintegrowanych systemach należących do tej organizacji są dobrze znane, a ich interfejsy mają charakter statyczny. Dla takiej organizacji tak niskopoziomowa integracja, jaką jest integracja danych, może okazać się zbyt skomplikowana. Możliwe dla niej jest zatem wydzielenie dobrze zdefiniowanej funkcjonalności każdego z integrowanych systemów i globalne ich opublikowanie jako usługi. Stworzony w ten sposób zbiór usług może stać się następnie podstawą do integracji procesów biznesowych zachodzących w ramach takiej organizacji. Taka wysokopoziomowa (i pożądana z punktu widzenia biznesu) integracja nie może być z kolei wykorzystana w przypadku pierwszej z wymienionych organizacji. 18

19 Zauważmy, iż obecnie obie opisane wyżej organizacje do osiągnięcia swoich celów musiałyby używać różnego zestawu narzędzi. Pierwsza z nich prawdopodobnie wykorzystałaby jakąś relacyjną bazę danych umożliwiającą budowę federacyjnych baz danych (np. DB2 z wbudowanym modułem Garlic), a druga - rozproszonych obiektów, middleware zorientowanego na komunikaty, albo WebServices. Naszym zdaniem wszystkie te rozwiązania możliwe są do wyrażenia za pomocą obiektowej bazy danych zintegrowanej z językiem zapytań rozszerzonym do kompletnego języka programowania. Narzędzie takie wykorzystane jako middleware może wnieść zupełnie nową jakość do tematyki integracji aplikacji. Możliwość wykorzystania tego samego narzędzia do zrealizowania różnych strategii integracyjnych powinna zwiększyć produktywność programistów, ograniczyć koszty wytwarzania oprogramowania, skrócić czas nauki oraz zredukować liczbę struktur, koncepcji i mechanizmów niezbędnych do opanowania przez programistów. W tej pracy skoncentrujemy na zaprojektowaniu architektury takiego narzędzia. Cel pracy doktorskiej Podstawowym celem rozprawy doktorskiej jest zbadanie nowych paradygmatów ułatwiających proces implementacji systemów informatycznych. Zaprojektowana zostanie nowa metodologia tworzenia aplikacji baz danych, wraz z prototypowym narzędziem, umożliwiającym pracę programiście bazodanowemu na znacznie wyższym poziomie, niż umożliwiają to współczesne rozwiązania. W tym celu stworzony zostanie nowy, obiektowy język programowania, bezszwowo zintegrowany z konstrukcjami języka zapytań (zapytania jako wyrażenia), razem z jego rozproszonym, bazodanowo zorientowanym, obiektowym środowiskiem wykonawczym. Technologia ta zapewniać będzie funkcjonalność wielu istniejących narzędzi (takich jak np. języki programowania aplikacji baz danych, języki zapytań do baz danych, systemy zarządzania bazami danych, różnego rodzaju middleware) w jednym, spójnym, uniwersalnym, łatwym do wykorzystania i efektywnym w użyciu środowisku programistycznym. Będzie to jednocześnie propozycja nowej architektury obiektowych baz danych, konkurencyjna wobec istniejących architektur obiektowych i relacyjnych SZBD. Najważniejszym zadaniem takiego środowiska programistycznego będzie integracja rozproszonych zasobów rozumianych jako dane, dlatego zagadnienie to stanowić będzie najpoważniejszy fragment rozprawy. Integracja danych zrealizowana zostanie za pomocą koncepcji znanej pod nazwą wirtualnego repozytorium. Zgodnie z tą koncepcją, wszystkie składniki systemu informatycznego 19

20 widziane będą jako jedna, wirtualna, rozproszona baza danych i usług, dostępna za pomocą języka zapytań. Zapewnienie odpowiedniego stopnia przezroczystości (przezroczystość danych/usług, współbieżności, heterogeniczności, skalowania, fragmentacji, replikacji, migracji, optymalizacji, itp.) niezbędnego w wirtualnym repozytorium osiągalne będzie w satysfakcjonującym stopniu jedynie wówczas, gdy programista aplikacyjny zwolniony zostanie z ich ręcznego zaprogramowania za pomocą języka ogólnego przeznaczenia (jak to ma miejsce w typowych rozwiązaniach). Zamiast tego, za ich realizację odpowiedzialny powinien być system zarządzania bazą danych sterowany za pomocą bardzo wysokopoziomowych konstrukcji deklaratywnych. Aby korzystać z wirtualnego repozytorium, programista nie będzie zatem zmuszony do posługiwania się złożonym API udostępnianym przez obecne middleware. Zamiast tego, pozwolimy mu pracować na znacznie wyższym poziomie abstrakcji, ukrywając złożoność procesów komunikacyjnych, mechanizmów bezpieczeństwa, transakcyjności i optymalizacji. Najważniejszą zaletą naszego wirtualnego repozytorium będzie możliwość aktualizacji danych z poziomu globalnego użytkownika. Właściwość tę osiągniemy poprzez wykorzystanie w pełni aktualizowalnych perspektyw, wykorzystywanych jako osłony/mediatory i nie mających precedensu w istniejących rozwiązaniach z dziedziny integracji danych i aplikacji. Zaproponowane przez nas narzędzie posiadało będzie potencjał zostania samodzielnym środowiskiem programistycznym, dostarczającym możliwości budowy aplikacji baz danych oraz samych baz danych. Integracja danych i aplikacji zbudowanych za pomocą wyłącznie tego środowiska będzie najbardziej pożądaną sytuacją, najmniej pracochłonną programistycznie. Rzeczywiste, rozproszone systemy informatyczne składają się jednak z wielu różnych elementów zbudowanych przy użyciu setek technologii pojawiających się i znikających na przestrzeni lat. Ze względu na koszty, jakie ponoszą organizacje przy wdrażaniu poszczególnych składników takich systemów, ich przepisanie w nowym języku programowania, a często nawet drobna modyfikacja, jest zwykle nierealne. Oznacza to, iż wirtualne repozytorium musi posiadać możliwość integracji zasobów spadkowych o heterogenicznym charakterze. Cel ten zostanie zrealizowany zgodnie z regułami przyjętymi dla federacyjnych baz danych. Zaprojektowany zatem zostanie kanoniczny model danych zdolny reprezentować popularne modele danych wykorzystywanych we współczesnych bazach danych i językach programowania. Ten kanoniczny model danych obowiązywać będzie w całym wirtualnym repozytorium, a każdy integrowany zasób (np. relacyjna baza danych) będzie mógł być wyrażany w jego kategoriach za pomocą zestawu osłon (adapterów) lub filtrów (importerów). Dodatkowe różnice w schematach poszczególnych żródeł danych oraz 20

21 reprezentacji danych (np. różne waluty) rozwiązywane będą za pomocą aktualizowalnych perspektyw pełniących rolę mediatorów. W szczególności, osobna taka perspektywa będzie mogła zostać zdefiniowana dla każdego systemu kontrybuującego do repozytorium (tzw. perspektywa kontrybucyjna) oraz globalna perspektywa prezentująca zawartość całego systemu jako wirtualną całość (tzw. perspektywa integracyjna). Globalny użytkownik korzystał będzie z repozytorium za pomocą jednego języka zapytań (rozszerzonego do języka programowania), niezależnie od tego gdzie fizycznie znajdować się będą integrowane dane/usługi, oraz jakie technologie zostały użyte do ich wygenerowania. Ponieważ tak utworzona rozproszona baza danych widziana jest przez zewnętrznego użytkownika jako pojedyncza, wirtualna baza danych, istnieje także możliwość zbudowania dla niej tradycyjnych interfejsów dostępowych, np. JDBC, czy WebServices. W ten sposób, technologia ta zgodna będzie z przyjętymi w przemyśle standardami, ale jednocześnie niezależna od nich. W niniejszej pracy nie będziemy jednak zajmowali się konstrukcją takich interfejsów dostępowych, ani (w szczególności) wrapperów. Konstrukcja takich modułów (np. osłony do relacyjnej bazy danych) jest zadaniem nietrywialnym i stanowi treść osobnych prac doktorskich. Język programowania/zapytań zaproponowany w rozprawie bazuje na podejściu stosowym (Stack- Based Approach, SBA) do języków zapytań. SBA jest semantyczną ramą ułatwiającą budowę mocnego języka zapytań dla praktycznie dowolnego znanego modelu danych, niezależnie od tego czy jest to model półstrukturalny (np. XML), ustrukturalizowany (np. relacyjna baza danych), czy nieustrukturalizowany (np. dane multimedialne). Przykładowo, obsługa danych XML zapewniona jest poprzez możliwość zaimportowania zawartości dowolnego dokumentu do bazy danych i wyrażenia jego treści w terminach obiektów tej bazy danych. Na takich danych można następnie pracować w taki sposób, jak gdyby były to natywne dane zdefiniowane za pomocą języka definicji danych wbudowanego w SZBD. Budowa kompletnego języka programowania bezszwowo zintegrowanego z konstrukcjami języka zapytań możliwa jest dzięki temu, iż w podejściu stosowym zapytania traktowane są tak, jak wyrażenia w tradycyjnych językach programowania. Semantyka zapytań jest zatem oparta na mechanizmach dobrze znanych z typowych języków - stosie środowisk, stosie arytmetycznym oraz paradygmacie nazwa-zakres-wiązanie. Pozwala to na precyzyjne określenie semantyki operacyjnej języków zapytań z uwzględnieniem cech obiektowości (np. klasy, dynamiczne role obiektów), konstrukcji imperatywnych i abstrakcji programistycznych (np. procedur, perspektyw, modułów). 21

22 Wykorzystanie SBA umożliwi nam znaczną redukcję liczby języków, z jakimi ma do czynienia typowy programista baz danych. W idealnej sytuacji może to być jeden język przeznaczony do programowania aplikacji, definiowania schematu bazy danych, wykonywania zapytań, transformowania danych, itd. Najważniejsze aspekty technologii zaprezentowanej w rozprawie zaimplementowane zostały w postaci prototypu. Jest on podstawowym komponentem systemów e-govbus oraz VIDE, realizowanych przez PJWSTK wspólnie z partnerami, oraz finansowanych w ramach grantów przyznanych przez Unię Europejską. Teza rozprawy doktorskiej Koncepcja wirtualnego repozytorium oparta na jednorodnym obiektowym środowisku programistycznym bazującym na języku zapytań zintegrowanym z językiem programowania jest alternatywą dla wielu obecnie popularnych, eklektycznych technologii. Koncepcja ta potwierdzona została poprzez stworzone oprogramowanie. Jest ono zatem dowodem tezy naukowej dektoratu mówiącej o tym, iż jest możliwe stworzenie metodologii oraz odpowiednich dla niej narzędzi programistych (opartych o zintegrowany język zapytań/programowania), które pozwalą na szybką i tanią budowę wirtualnego repozytorium opartego o kanoniczny model obiektowy. Zadaniem takiego repozytorium jest integracja danych i aplikacji znajdujących się pod kontrolą tych samych lub niezależnych od siebie organizacji, a także umożliwienie szybkiego programowania wydajnych aplikacji baz danych na bardzo wysokim poziomie abstrakcji. Podsumowanie W rozdziale krótko przedstawiliśmy problemy wiążące się z integracją danych i aplikacji w systemach rozproszonych. Przedstawiliśmy w nim nasze stanowisko mówiące o tym, iż obiektowa baza danych z wbudowanym językiem zapytań zintegrowanym z językiem programowania stanowi potencjalne narzędzie do budowy zintegrowanych baz danych oraz ich aplikacji. Dzięki pełnej mocy obliczeniowej porównywalnej z istniejącymi językami programowania, obiektowa baza danych tego typu jest w stanie przykryć funkcjonalnością dowolny istniejący współcześnie rodzaje middleware, a także niektóre języki programowania czwartej generacji. Poprzez zastosowanie w pełni aktualizowalnych perspektyw, system tego typu może również służyć do budowy federacyjnych baz danych. Tak zbudowana baza danych pozbawiona jest dwóch poważnych problemów związanych z takimi bazami danych jeśli realizowane są przy użyciu relacyjnych baz danych: 22

23 1. uproszczonego modelu danych implikowanego przez relacyjny model danych, 2. braku możliwości aktualizacji sfederowanych zasobów danych od strony globalnego klienta. Przedstawiliśmy również cel niniejszej pracy doktorskiej, której zamierzeniem jest zaprojektowanie architektury obiektowej bazy danych nowego typu, jak również zaimplementowanie jej prototypu. 23

24

25 Rozdział 2: Stan sztuki w dziedzinie integracji danych i aplikacji Wprowadzenie W bieżącym rozdziale krótko omówimy najważniejsze teorie, techniki, technologie i inne rozwiązania związane z integracją danych i aplikacji. Ponieważ w niniejszej pracy będziemy dowodzili, iż obiektowa baza danych jest doskonałym narzędziem dla EAI/EII, zanim przejdziemy do dokładniejszego opisu naszej koncepcji, postaramy się pokazać dlaczego naszym zdaniem istniejące techniki programowania aplikacji baz danych powinny zostać w dużej części przedefiniowane. W naszym opisie skoncentrujemy się na trzech aspektach integracyjnych: integracji języków programowania z bazami danych za pomocą języków zapytań, metodach zapewniania komunikacji pomiędzy heterogenicznymi aplikacjami, oraz deklaratywnych sposobach integracji różnorodnych baz danych. Integracja baz danych z językami programowania Metody integracji języków programowania z bazami danych studiowane są od wielu lat. W związku z tym, iż ogólnie przyjętym mechanizmem operowania na bazach danych jest język zapytań, integracja baz danych z językami programowania wiąże się zazwyczaj z integracją języka imperatywnego ogólnego przeznaczenia z językiem deklaratywnym operującym na bazie danych. 25

26 Najbardziej popularna klasyfikacja metod integracji języków programowania z bazami danych oparta jest na dwóch metodach. Pierwsze z tych podejść, tzn. zanurzanie jako literałów kodu języka zapytań w kodzie języka programowania, obarczone są poważną wadą znaną pod nazwą niezgodność impedancji. Alternatywne podejścia (np. Pascal/R [43], Napier88 [44], DBPL [41], LOQIS [31], Fibonacci [28], Oracle PL/SQL) w dużym stopniu pozbawione są tej wady, ponieważ dążą one do stworzenia jednolitego środowiska programistycznego, a konstrukcje imperatywne zintegrowane są z konstrukcjami deklaratywnymi. Poniżej przedstawimy krótki, krytyczny opis najbardziej znanych podejść w dziedzinie integracji języków zapytań z językami programowania. Interfejs poziomu wywołań Najbardziej znanym sposobem dostępu do baz danych jest tzw. interfejs poziomu wywołań (Call Level Interface, CLI). Technika ta polega na zagniedżaniu kodu języka zapytań odpowiedzialnego za operacje realizowane na bazie danych jako literały łańcuchów znaków w kodzie źródłowym programów napisanych w językach proceduralnych, a następnie użyciu pewnej bazodanowej warstwy pośredniej (database middleware) dostępnej jako API. Poniższy kod w języku Java ilustruje sposób korzystania z interfejsu poziomu wywołań. Fragment ten odpowiedzialny jest za wysłanie zapytania SELECT * FROM MyTable do bazy danych, a następnie wyświetlenie na ekranie wszystkich wierszy i kolumn tabeli wynikowej. Statement stmt = conn.createstatement(); try { ResultSet rs = stmt.executequery("select * FROM MyTable"); try { while (rs.next()) { int numcolumns = rs.getmetadata().getcolumncount(); for (int i = 1 ; i <= numcolumns ; i++) System.out.println("COLUMN " + i + " = " + rs.getobject(i)); finally { rs.close(); finally { stmt.close(); Na przestrzeni lat podejście takie zostało mocno skrytykowane jako uniemożliwiające statyczną kontrolę typów zapytań (literały Javy nie są dostępne dla kompilatora SQL), wymagające konwersji 26

27 typów języka programowania na typy bazy danych, stanowiące zagrożenie dla bezpieczeństwa systemu (tzw. sql injection), uniemożliwiające operacje wspomagania programowania realizowane przez środowiska programistyczne (refaktoryzacja, podpowiadanie nazw) i inne. Niedogodności te próbowano ominąć wprowadzając dodatkowy etap kompilacji za pomocą tzw. prekompilatora (np. SQLJ), analizującego specjalne bloki kodu źródłowego z zawartością będącą kodem rozpoznawanym przez prekompilator. Prekompilator zdolny jest analizować wnętrze takich specjalnych klauzul, kontrolować poprawność odwołań zarówno do Javy, jak i do bazy danych, a także automatycznie zamieniać wnętrze tych klauzul na odpowiednie wywołania CLI (w przypadku SQLJ na kod Javy używający JDBC). Niestety okazało się że podejście to jest niewystarczające. Języki z trwałością Języki z trwałością należą do dosyć istotnego nurtu bliskiego bazom danych. Aczkolwiek eksperymentalne projekty (np. Fibonacci [28], PS-Algol [57], DBPL [41], Napier88 [44], Machiavelli [46], PJama [23], i in.) stworzone w ubiegłej dekadzie nie zdobyły popularności poza laboratoriami w których powstały, odegrały one silny wpływ na architekturę obiektowych baz danych. Języki te były zwykle rozszerzonymi tradycyjnymi językami programowania (np. PJama jest rozszerzeniem Javy, a DBPL Moduli2) wprowadzającymi pojęcie trwałych zmiennych/ obiektów. Trwała zmienna to taka, która ma wszystkie własności zmiennej języka programowania, ale zachowuje swoją wartość pomiędzy kolejnymi uruchomieniami programu. Uważano że dzięki takiemu podejściu dowolne bazy danych można traktować jako zestawy trwałych zmiennych. Prawdopodobnie najpoważniejszym wkładem tych języków w dziedzinę obiektowych baz danych stało się pojęcie ortogonalnej trwałości. Koncepcja ortogonalnej trwałości mówi, iż programista nigdy nie powinien być zmuszany do tworzenia kodu odpowiedzialnego za przenoszenie danych pomiędzy trwałym i ulotnym składem danych. Zakładająca pełną unifikację definicji i środków manipulacji trwałymi i ulotnymi danymi, koncepcja ta stanowiła ogromny postęp w zakresie abstrakcji i estetycznego domknięcia pojęć. Przykładowo, projekt PJama zakładał, iż programista nie musi w ogóle korzystać z żadnego API zapewniającego trwałość, gdyż jest ona zapewniana na poziomie systemowym i dotyczy wszystkich zmiennych globalnych. System zapewnia zatem iluzję ciągłej pracy oprogramowania, nawet pomimo zamierzonych lub niezamierzonych wyłączeń. Cel ten próbowano osiągnąć poprzez rozszerzenie funkcjonalności wirtualnej maszyny języka Java w taki sposób, aby w trakcie wystąpienia tzw. punktu kontrolnego bieżący stan aplikacji 27

28 (danych i procesów) był utrwalany. Utrwalone zostają jedyne te dane, które od czasu ostatniego punktu kontrolnego zostały zmodyfikowane. Gdy nastąpi punkt kontrolny, system jest zamrażany, a wirtualna maszyna analizuje całe drzewo obiektów sterty w poszukiwaniu takich obiektów. Po zatrzymaniu aplikacji i jej ponownym uruchomieniu tak zmodyfikowana maszyna potrafi kontynuować przetwarzanie od momentu w którym jego stan został utrwalony w trakcie ostatniego punktu kontrolnego. W innych językach z trwałością stosowano mniej lub bardziej podobne metody utrwalania danych. W większości projektów koncentrowano się na zbudowaniu nowego języka (często z bardzo wymyślną semantyką i systemem typów), albo rozszerzeniu istniejącego o aspekt trwałości, całkowicie ignorując wiążące się z tym implikacje wynikające z konieczności przetwarzania danych masowych. Żaden ze stworzonych w ten sposób języków nie pozwalał na wykorzystywanie typowo bazodanowych konstrukcji, np. indeksów, perspektyw, czy wyzwalaczy. Większość języków z trwałością nie obsługuje również innych krytycznych dla baz danych mechanizmów, np. transakcji, dzienników, dynamicznej optymalizacji, współbieżnego dostępu wielu równoległych sesji, kont użytkowników, uprawnień, itd. Tylko w niewielkiej grupie języków wprowadzone zostały konstrukcje deklaratywne, niezbędne do wygodnego operowania na danych masowych. Niestety, zazwyczaj konstrukcje te były nieortogonalne z resztą języka. Przykładowo, w systemie DBPL można korzystać z języka zapytań, ale tylko w stosunku do specjalnego rodzaju zmiennych zadeklarowanych jako (zagnieżdżone) relacje (próba połączenia języka programowania z modelem relacyjnym). Wyjątkiem był tu jedynie system Loqis [30, 31], w którym przyjęto jednak zupełnie inne założenia. Zamiast rozszerzać język proceduralny o konstrukcje charakterystyczne dla baz danych, rozszerzono bazę danych oraz jej język zapytań o konstrukcje charakterystyczne dla proceduralnych języków programowania. Dosyć podobne podejście (aczkolwiek w nieporównywalnie mniejszym stopniu) dotyczy języka PL/SQL firmy Oracle. Odwzorowanie relacyjno-obiektowe Odwzorowanie relacyjno-obiektowe jest innym rodzajem integracji aplikacji z bazą danych. Celem tej techniki jest stworzenie wirtualnej obiektowej bazy danych na bazie relacyjnej bazy danych oraz obiektowego języka programowania. Zdaniem zwolenników tej metody umożliwia to wykorzystanie istniejących relacyjnych baz danych i obiektowych języków programowania w sposób obiektowy, czyli bez pracochłonnego tłumaczenia struktur relacyjnych na struktury 28