Monitory transakcji

Komunikaty polimorficzne. W przeciwieństwie do oprogramowania middleware innego typu, ORB wywołując metodę kieruje ją do określonego obiektu, co powoduje, że ta sama funkcja przynosi różne wyniki, w zależności od obiektu docelowego.

Enkapsulacja aplikacji. Oddzielenie interfejsu od implementacji pozwala na zamknięcie istniejących aplikacji w otoczkę obiektową, co umożliwia współpracę z innymi obiektami.

Obsługa transakcji. Jednym z ważniejszych zadań monitora transakcji jest nadzór nad każdą transakcją, poczynając od miejsca jej powstania w stacji klienta, przez wszystkie uczestniczące w niej zasoby (serwery, bazy danych, sieć), aż do jej zakończenia przez zapisanie danych i powiadomienia klienta.

Obsługa komunikacji. Większość monitorów umożliwia różne sposoby komunikacji między stacją klienta a aplikacją - konwersacyjnie (komunikacja synchroniczna - klient czeka na odpowiedź), metodą asynchroniczną "zapamiętaj i wyślij" (klient zajmuje się obsługą użytkownika, nie czekając na odpowiedź z bazy), przez zaprenumerowanie przez klienta danych publikowanych przez serwer, a także ogłoszeniowo (serwer publikuje dane rozsyłane do wszystkich klientów).

Rozdział obciążenia. Monitory transakcji mogą decydować o priorytetach obsługi klientów (np. podczas pracy pierwszeństwo mają użytkownicy interaktywni, poza nimi obsługuje się także prace wsadowe), rozdzielać statycznie lub dynamicznie obciążenie na różne serwery bazy danych i serwery aplikacji pracujące w systemie.

Wysoka dostępność. Monitory transakcji opracowano z myślą o rozwiązywaniu problemów w przypadku awarii, umożliwiając tworzenie systemu komputerowego do obsługi transakcji bez punktów potencjalnej awarii.

Ochrona aplikacji. Monitory transakcji zapewniają ochronę zasobów przed źle działającymi aplikacjami i aplikacji między sobą, tworząc zapory ogniowe.

Komunikacja obiektowa

Większość nowych aplikacji jest tworzona w technice obiektowej. Wynika to z licznych zalet tej techniki w zakresie lepszego odwzorowania biznesu na program komputerowy, wielokrotnego używania raz opracowanych obiektów, możliwości tworzenia aplikacji przez wizualne łączenie komponentów i in.

W środowisku informatycznym pojawiło się dziwne podejście, jeśli chodzi o serwery aplikacji. Firmy, które nigdy by się nie zdecydowały na opracowanie własnej bazy danych, porywają się na opracowanie serwera aplikacji. Wydaje się im, że jest to zadanie proste, dopóki nie okaże się w praktyce, jak skomplikowane wymagania trzeba spełnić. W efekcie czasem aż 70% zasobów przeznacza się na budowę infrastruktury aplikacji. Jest to zapewne jeden z powodów wysokiego wskaźnika nieudanych projektów informatycznych.

Obiekty nie działają jednak w próżni. Wymagają pośredniej warstwy oprogramowania - szyny programowej - zapewniającej komunikację, znajdowanie właściwego obiektu na podstawie jego identyfikatora, bezpieczeństwo i możliwość współpracy z istniejącymi aplikacjami.

Najlepszą szyną programową do komunikacji obiektowej w systemach unixowych i na mainframe'ach są tzw. brokery obiektowe ORB, zgodne ze specyfikacją Common Object Request Broker Architecture CORBA, opracowaną przez konsorcjum przemysłowe Object Management Group. W środowisku Windows Microsoft proponuje konkurencyjny standard komunikacji DCOM (Distributed Common Object Model), lecz nie zapewnia on takiej gamy usług, jak CORBA, ponadto na serwerze jest ograniczony tylko do Windows NT.


TOP 200