Monitory transakcji

Monitor transakcyjny to koń roboczy 3-warstwowych aplikacji klient/serwer. W środowisku rozproszonych aplikacji obiektowych jego rola jest jeszcze większa.

Monitor transakcyjny to koń roboczy 3-warstwowych aplikacji klient/serwer. W środowisku rozproszonych aplikacji obiektowych jego rola jest jeszcze większa.

Monitory transakcyjne cieszą się popularnością wśród informatyków, którzy muszą pisać złożone aplikacje do obsługi dużych przedsiębiorstw. Jak podaje Standish Group, w 1996 r. 57% aplikacji krytycznych dla działalności przedsiębiorstwa korzystało z monitorów transakcji. Skąd to zainteresowanie programami, które pochodzą z odległych czasów mainframe'a? Sprawa jest prosta: na rynku nie ma lepszego produktu do uruchamiania i obsługi 3-warstwowych aplikacji klient/serwer.

Monitory transakcji od wielu lat sprawdziły się w praktyce, służąc do koordynacji działań krytycznych programów. Monitor transakcji umożliwia zarządzania procesami i programami. Wykonuje to dzieląc skomplikowany program na wiele części kodu zwanych usługami. Korzystając z transakcji, monitor doprowadza do tego, że te części kodu - nie mające z sobą nic wspólnego - działają jak zgrany zespół.

Popularne pojmowanie monitora jako narzędzia do wykonywania protokołu 2-fazowego zatwierdzania transakcji zbyt daleko odbiega od rzeczywistości. Monitory transakcji robią znacznie więcej.

Do czego służy monitor transakcji?

Monitor transakcji umożliwia tworzenia aplikacji do obsługi tysięcy klientów. Wyobraźmy sobie typowy system komputerowy z działającym na nim serwerem bazy danych. Każdy dostęp stacji klienta do serwera bazy danych polega na obsłudze połączenia do niego (sesji), wywołaniu procesu bazodanowego, przydzieleniu pamięci buforowej dla bazy i otwarciu bazy (co wiąże się z otwarciem kilkunastu lub kilkudziesięciu plików), a w końcu na obsłudze żądania klienta. Typowy proces połączeniowy wymaga 50 kB pamięci a otwarcie bazy - wymaga co najmniej 500 kB. Jeżeli jednocześnie działa 1000 klientów, zapotrzebowanie na zasoby systemowe jest tak duże (1000 połączeń, 1000 procesów bazy danych, ponad 500 MB pamięci, kilka tysięcy otwartych plików), że żaden system operacyjny nie może temu zadaniu zaradzić.

Monitor transakcji pośredniczy między serwerem bazy danych a klientami. Jednoczesne działanie użytkowników systemu nie oznacza, że istotnie żądają oni dostępu do bazy dokładnie w tym samym momencie. Do ich obsłużenia monitor transakcji otwiera pewną pulę połączeń z bazą oraz pewną liczbę procesów serwera bazy danych. Następnie współdzieli te otwarte połączenia i procesy między wszystkimi obsługiwanymi klientami. Jeżeli więc we wspomnianym systemie z 1000 użytkowników, monitor transakcji otworzy 50 połączeń, to będzie musiał dzielić je między 20 klientami, ale zmaleją 20-krotnie wymagania na zasoby systemowe. Potrzeba będzie ok. 30 MB RAM i kilkaset jednocześnie otwartych plików.

Właściwości monitora transakcji

Podstawowe zalety brokerów obiektowych ORB

Statyczne i dynamiczne wywołanie metod. Wywołanie metody obiektu można zdefiniować statycznie podczas kompilacji lub wykryć, jakie obiekt ma metody w czasie działania programu.

Możliwość użycia dowolnego języka programowania. CORBA oddziela interfejs obiektu od jego wdrożenia. Istnieją wiązania (binding) obiektów na serwerze dla większości języków programowania, można więc metodę wywoływać z obiektu opracowanego w innym języku.

System samoopisujący. CORBA zawiera repozytorium metadanych do opisania każdego interfejsu w systemie.

Działanie lokalne/zdalne. ORB może pracować lokalnie na notebooku lub współpracować z innymi ORB-ami w sieci za pośrednictwem standardowego protokołu Internet Inter-ORB Protocol (IIOP). Ani programista, ani użytkownik nie muszą wiedzieć, gdzie znajduje się używany przez nich obiekt.

Wbudowane usługi bezpieczeństwa i obsługi transakcji. Komunikaty przesyłane między ORB zawierają dostatecznie dużo informacji o kontekście i danych, aby bezpiecznie obsługiwać transakcje między sobą.