Czy middleware oznacza zanik systemów baz danych?

Systemy zarządzania relacyjnymi bazami danych zdominowały rynek baz danych. I nie wynika to bynajmniej z ich zdecydowanej przewagi w szybkości, komforcie obsługi czy większej funkcjonalności w stosunku do innych systemów. Powszechna jest opinia, że produkcyjny, wysoko wydajny system przetwarzania transakcji znacznie łatwiej można zrealizować za pomocą baz plikowych (np. ISAM) niż relacyjnych.

Systemy zarządzania relacyjnymi bazami danych zdominowały rynek baz danych. I nie wynika to bynajmniej z ich zdecydowanej przewagi w szybkości, komforcie obsługi czy większej funkcjonalności w stosunku do innych systemów. Powszechna jest opinia, że produkcyjny, wysoko wydajny system przetwarzania transakcji znacznie łatwiej można zrealizować za pomocą baz plikowych (np. ISAM) niż relacyjnych.

Jednakże zasadnicza zaleta systemów zarządzania relacyjnymi bazami danych kryje się w oddzieleniu aplikacji do obsługi danych od samych danych. Dane są zarządzane nie przez aplikację, a przez niezależny od niej system bazy danych. Umożliwiło to zresztą powstanie przetwarzania rozproszonego, środowiska klient/serwer i uniezależnienie aplikacji od systemu zarządzania bazą. W gruncie rzeczy, użytkownika końcowego wcale nie interesuje za pomocą jakiej bazy są zarządzane dane, z których korzysta aplikacja.

Czy jest nadzieja, że tak samo nie będzie to ważne dla programisty przygotowującego aplikację? Wygląda na to, że tak. Czy wyobrażasz sobie Czytelniku, że zmuszony byłbyś zajmować się szczegółami dotyczącymi protokołu Ethernet tylko dlatego, że przygotowujesz prostą aplikację działającą w tej sieci? A co będzie, jeśli aplikacja ma być zainstalowana u klienta z siecią Token Ring? Przecież jej zmiana jest nie do pomyślenia.

Uniezależnić się od bazy

Organizacje dążą do tego, aby ich aplikacje były niezależne od środowiska sprzętowego i systemowego. Dotyczy to także niezależności od systemu zarządzania bazą danych, co daje większą niezależność od dostawców.

Co właściwie znaczy niezależność od systemu zarządzania bazami danych? Możliwość korzystania z tej samej składni dostępu do danych w programach użytkowych, niezależnie od tego jaki system zarządzania bazami jest używany. Ponadto składnia nie powinna zależeć od typu używanego systemu zarządzania czy jest baza relacyjna, hierarchiczna, plikowa czy sieciowa.

Middleware coraz bardziej wyrafinowany

Definicja tej pośredniej warstwy oprogramowania (middleware), pośredniczącej między aplikacją a systemami zarządzania bazami danych, zmienia się wraz z jej rozwojem. Początkowo wystarczało, że middleware dobrze ukrywał przed programistą szczegóły dotyczące używanych protokołów sieciowych. Obecnie to już nie wystarcza, zwłaszcza wobec chęci osiągnięcia wymienionego wyżej celu niezależności od systemu zarządzania bazami danych.

"Middleware jest to technologia programistyczna, pozwalająca na odwzorowanie aplikacji do używanych przez nią zasobów". Może ta definicja nie jest zbyt przejrzysta, ale cel jest jasny: uchronienie użytkownika i programisty od konieczności zajmowania się szczegółami związanymi z zasobami, z których się korzysta. Przy czym przez zasoby należy rozumieć nie tylko dane i sieć, ale także takie usługi jak: synchronizacja czasowa wszystkich komputerów w sieci, dynamiczne powiązanie nazwy konkretnego zasobu z jego fizyczną lokalizacją, niezależnie od tego, gdzie się znajduje itp.

Wielka jest różnorodność produktów typu middleware. Większość tych produktów dobrze odwzorowuje potrzeby aplikacji do systemu zarządzania bazami danych; niektóre z nich dostarczają możliwości korzystania z baz plikowych czy hierarchicznych na dużych komputerach; inne ograniczają się tylko do baz relacyjnych. Monitory transakcji (Tuxedo z firmy Novell, Encina z Transarc, HP lub IBM, CICS z IBM) pozwalają na dokładną kontrolę nad wykonywaniem transakcji w środowisku rozproszonym.

Jednakże najbardziej pożądaną właściwością middleware jest dostarczanie pojedynczego zestawu interfejsu programowego API, niezależnego od używanego systemu baz danych. Spowodowało to de facto powstanie w tej dziedzinie standardów: ODBC opracowanego przez Microsoft i IDAPI opracowanego przez Borland. Sądząc z obecnej sytuacji finansowej firm, jedynie standard ODBC ma szansę powszechnie się przyjąć.

Zanik systemów baz danych

Z chwilą, gdy aplikacja stanie się niezależna od systemów zarządzania bazami danych, ich waga jako podstawowego czynnika określającego strategię opracowania aplikacji dla potrzeb przedsiębiorstwa, znacznie spadnie. Szefowie działów informatyki przedsiębiorstwa coraz częściej zaczną traktować system zarządzania bazami danych tak samo, jak sprzęt czy system operacyjny: jako element wyposażenia. Ważna więc stanie się jego cena i wydajność, nie specyficzne cechy funkcjonalne.

Większość producentów systemów zarządzania bazami danych stara się zapobiec tej tendencji, umieszczając w swych produktach "specjalne cechy", mając nadzieję związać użytkowników na stałe ze swymi produktami. Naprawdę warto starannie przemyśleć, jak i w jakim zakresie należy używać takich cech, jak zapamiętane procedury i trygery. Na szczęście nowy standard SQL3 rozsztrzyga w znacznej części i te zagadnienia, warto więc przyjrzeć się zgodności systemu ze standardami.

Middleware, zwłaszcza taki, który korzysta z ODBC, zastępuje w oczach programisty system zarządzania bazami danych i na dodatek zapewnia połączenia z bazą w sieci. Daje także szanse używania systemu zarządzania bazami danych najlepiej przystosowanego do zadania, niekoniecznie relacyjnego. Otwiera to także pole badań w zakresie nowych technologii (modne ostatnio technologie obiektowe i tzw. postrelacyjne), nie zamykając drogi istniejącym systemom.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200