Nowoczesne Przetwórstwo Aluminiowe ze Skawiny to prawdopodobnie jedyna firma na świecie, która, nie zmieniając aplikacji, wykorzystuje już trzecią z kolei bazę danych.

Nowoczesne Przetwórstwo Aluminiowe sp. z o.o. (NPA) powstało we wrześniu 2001 r. w wyniku wydzielenia majątku z Zakładów Metalurgicznych "Skawina". Nowa firma, podobnie jak nadal istniejące ZM "Skawina", wykorzystuje system wspomagający zarządzanie ASIMS+ krakowskiej Supry. Nie byłoby w tym nic nadzwyczajnego, gdyby nie fakt, że w ciągu kilku lat ta sama aplikacja współpracuje już z trzecim serwerem bazy danych, działającym na trzeciej z kolei platformie systemowej.

Z Informixa do DB2

ZM "Skawina" zakupiły system ASIMS+ w 1996 r. Aplikacja stworzona za pomocą narzędzi Informix 4GL współpracowała wtedy z serwerem baz danych Informix OnLine 5. Ponieważ liczba transakcji i danych przyrastała w szybkim tempie, w 1997 r. czteroprocesorowy serwer Compaqa z systemem SCO Unix i bazą danych Informix przestał wystarczać. Ponadto zaczęły się kłopoty z jakością wsparcia ze strony Informixa, który w tym czasie rozwijał już nowe produkty. "Zakład potrzebował stabilniejszej i bardziej skalowalnej platformy serwerowej. Zmiana oznaczałaby jednak konieczność wymiany aplikacji, na co nie mogliśmy sobie pozwolić" - wspomina Janusz Gigoń, były kierownik działu informatyki, obecnie szef firmy Infor Usługi Informatyczne, świadczącej usługi utrzymania systemów zarówno na rzecz NPA, jak i Zakładów Metalurgicznych "Skawina".

Po konsultacjach z dostawcą aplikacji okazało się, że wymiany aplikacji da się uniknąć - od 1995 r. Supra pracowała bowiem nad technologią, umożliwiającą współpracę aplikacji stworzonych w środowisku Informix 4GL z bazami innymi niż Informix. Pierwsze przymiarki pokazały, że proces jest wykonalny. Istniało jednak wiele wątpliwości. "Technologia migracyjna Supry wydawała się bardzo interesująca, nie byliśmy jednak pewni, czy sprawdzi się w środowisku produkcyjnym. Mimo obaw, postanowiliśmy ją przetestować" - mówi Janusz Gigoń. Po kilkutygodniowym testowaniu i usuwaniu błędów, system produkcyjny udało się bez szwanku przenieść na platformę IBM DB2 5.2. Sukces był tym większy, że była to pierwsza wersja bazy DB2 działająca na platformie AIX. Obecnie ZM "Skawina" wykorzystują bazę DB2 w wersji 7.2.

Z DB2 do Oracle 9i

Kilka lat później, podczas wydzielania NPA z ZM "Skawina", powstało pytanie o wybór systemu dla nowej firmy. NPA nie chciało uczyć się obsługi nowej aplikacji i zdecydowano o wdrożeniu ASIMS+. W tym czasie dostawca poinformował, że prowadzi zaawansowane prace nad przeniesieniem swojej aplikacji na platformę Oracle. "Propozycja była atrakcyjna ze względu na możliwości baz Oracle. Wstępne szacunki cenowe wypadały jednak na korzyść DB2. Ostatecznie jednak Suprze udało się wynegocjować z Oracle Polska preferencyjne warunki" - mówi Janusz Gigoń.

W okresie przejściowym, do czasu ukończenia przez Suprę prac nad technologią migracyjną, NPA korzystało z systemu informatycznego ZM "Skawina". Pod koniec kwietnia br. rozpoczęły się testy. "Testowanie polegało głównie na sprawdzaniu zgodności wyników różnych operacji, prowadzonych równolegle na dwóch bazach danych. Ponieważ technologia jest już dojrzała, trwało to znacznie krócej niż poprzednio - ok. dwóch tygodni. Właściwa migracja danych produkcyjnych z DB2 7.2 do Oracle 9i zajęła nam 4,5 godziny" - twierdzi Janusz Gigoń.

Jak to możliwe?

Opracowana przez Suprę technologia migracji aplikacji nie zakłada modyfikacji kodu źródłowego Informix 4GL czy tłumaczenia go na język niższego poziomu. Firma stworzyła własny język - Supra 4GL, dla którego Informix 4GL stanowi pewien podzbiór. Po wzbogaceniu w funkcje charakterystyczne dla baz IBM DB2 czy Oracle, kod aplikacji jest kompilowany za pomocą opracowanego przez Suprę kompilatora. Dopiero tak spreparowana aplikacja może porozumiewać się z wprowadzoną przez Suprę warstwą pośrednią MDC Server, działającą pomiędzy aplikacją a bazą danych.

MDC Server przyjmuje od aplikacji polecenia SQL i odwołania do API ESQL/C (w tym przypadku charakterystyczne dla bazy Informix), a następnie przetwarza je na postać wymaganą przez wykorzystywane bazy danych, np. DB2 czy Oracle. Po wykonaniu operacji, wyniki są przekształcane z powrotem do postaci zrozumiałej dla aplikacji Informix 4 GL. Od strony czysto technicznej MDC Server to zestaw bibliotek typu runtime, uzupełniających standardowe biblioteki dostarczane przez producenta bazy danych. Komunikacja między aplikacją a MDC Server odbywa się poprzez współdzielone obszary pamięci.

MDC Server składa się z subserwerów, odpowiadających za komunikację z poszczególnymi bazami danych (Informix, DB2, Oracle), subserwery natomiast składają się z tzw. agentów: kompilatora, aplikacyjnych i zarządzających. Agent kompilatora to komponent, którego rolą jest informowanie kompilatora o strukturze bazy i typach danych podczas kompilacji. Dla zapewnienia wydajności kompilacji utrzymuje on stałe połączenie z bazą. Agent aplikacyjny jest odpowiedzialny za właściwą wymianę danych miedzy aplikacją a bazą. Oddzielny komponent tego typu jest przydzielany każdej aplikacji korzystającej z bazy danych (z wyjątkiem kompilatora). W ramach pojedynczego subserwera może występować wiele agentów aplikacyjnych. Agent zarządzający nadzoruje pracę dwóch pierwszych typów: powołuje ich instancje i przydziela im aplikacje.

Inne bazy i środowiska

Czy i ewentualnie kiedy technologia MDC bę- dzie obsługiwać także inne bazy danych, np. Microsoft SQL Server? Czy możliwa jest migracja w odwrotną stronę, tj. np. z bazy Oracle do DB2? Czy możliwe jest przenoszenie między bazami aplikacji tworzonych przy użyciu innych języków 4GL, np. Progress 4GL czy Oracle PL/SQL? To tylko niektóre z pytań, które wynikają z zapoznania się z historią aplikacji stosowanej w ZM "Skawina". Zdaniem producenta, odpowiedź na wszystkie te pytania brzmi: jeżeli nie dziś, to na pewno jutro.

Twórcy technologii MDC od początku uwzględnili możliwość współpracy z wieloma bazami danych, stąd zresztą nazwa: MDC - Multi Database Connectivity. "Dotychczasowe prace rozwojowe dotyczyły wyłącznie baz danych działających na systemach unixowych, co było relatywnie proste. Umożliwienie migracji do bazy SQL Server to znacznie większe wyzwanie, mamy tu bowiem do czynienia z podwójną migracją: między bazami danych oraz między znacznie różniącymi się systemami operacyjnymi. Niesie to zupełnie nowe problemy i dlatego wciąż poważnie się nad tym zastanawiamy" - mówi autor koncepcji MDC Krzysztof Kuśnierz, inżynier w Supra sp. z o.o.