W poprzedniej sekcji omówiono wykorzystanie produktu DB2 Connect z serwerami aplikacji. Serwer aplikacji umożliwia dużej liczbie użytkowników wykonywanie aplikacji przy użyciu minimalnych zasobów systemowych.
Serwer aplikacji można rozszerzyć w taki sposób, aby pozwalał na wywoływanie skoordynowanych transakcji z aplikacji wykonywanych przez serwer aplikacji. Taka koordynacja transakcji jest powszechnie znana jako monitor przetwarzania transakcyjnego (TP). Monitor TP działa w powiązaniu z serwerem aplikacji.
O transakcji można myśleć jak o procedurze zdarzenia, zazwyczaj żądaniu usługi uruchomionej w ramach normalnych, codziennych operacji wykonywanych w organizacji. Monitory TP zostały zaprojektowane do pracy, którą jest uporządkowane przetwarzanie transakcji.
W każdej organizacji są zasady i procedury opisujące sposób, w jaki organizacja ta powinna działać. Aplikacje użytkowników, w których zasady te zostały zaimplementowane, można nazywać logiką biznesową. Transakcje wykonywane przez takie aplikacje komercyjne bardzo często nazywamy przetwarzaniem transakcyjnym lub przetwarzaniem transakcyjnym w trybie z połączeniem (Online Transaction Processing - OLTP).
Kluczowe charakterystyki komercyjnego przetwarzania OLTP:
Na tym rysunku zarówno interfejsy API, jak i mechanizm połączeń między serwerem aplikacji i serwerami baz danych postprocesora zapewniane są przez produkt DB2 Connect Enterprise Edition.
Do najbardziej popularnych monitorów przetwarzania transakcyjnego, dostępnych obecnie na rynku należą:
Microsoft Transaction Server Remote S/390, AS/400 i serwery baz danych sieci LAN mogą być używane wewnątrz transakcji koordynowanych przez te monitory TP.
W przypadku produktu DB2 Connect wersja 6 i poprzednie aplikacje oparte na Tuxedo miały dostęp do serwerów baz danych hosta i systemu AS/400 ograniczony tylko do odczytu. Ograniczenie to nie istnieje w produkcie DB2 Connect wersja 7. Obecnie aplikacje oparte na Tuxedo mogą aktualizować serwery baz danych hosta i systemu AS/400 w ramach skoordynowanej transakcji Tuxedo. Mają zastosowanie specjalne ograniczenia i wymagania związane z konfiguracją. Więcej informacji można znaleźć w podręczniku Koncentrator połączeń DB2 Connect.
Do aktualizacji wielu zasobów w ramach jednej transakcji może być wymagana aplikacja wykonująca logikę biznesową. Na przykład aplikacja bankowa, w której zaimplementowane zostało przekazywanie pieniędzy z jednego konta na inne może wymagać debetowania jednej bazy danych (konta "skąd") i kredytowania drugiej bazy (konta "do").
Możliwe jest również, że dwie bazy danych pochodzą od innych dostawców. Na przykład jedna baza danych może być typu DB2 Universal Database for OS/390, a druga bazą danych Oracle. Zamiast monitorów, z których każdy implementuje interfejs transakcji prawnie zastrzeżony dla dostawcy bazy danych, zdefiniowany został jeden wspólny interfejs transakcji między monitorem TP i wszystkimi zasobami, do których sięga aplikacja. Interfejs ten jest znany pod nazwą interfejsu XA. Monitor TP korzystający z interfejsu XA nazywamy menedżerem transakcji zgodnym z XA. Zasób dający się aktualizować, w którym został zaimplementowany interfejs XA, nazywamy menedżerem zasobów zgodnym z XA.
Wszystkie monitory transakcji wymienione poniżej są zgodne z XA. Serwery baz danych zdalnego hosta, AS/400 i DB2 UDB w sieci lokalnej są RM zgodnymi z XA, gdy dostęp do nich następuje za pośrednictwem DB2 Connect. Dlatego też każdy monitor przetwarzania transakcyjnego, który ma menedżera transakcji zgodnego z XA, może w aplikacjach biznesowych wykonujących transakcje korzystać z serwerów baz danych hosta, systemu AS/400 i DB2 UDB w sieci lokalnej.
W tej sekcji zostały opisane kroki konfiguracyjne niezbędne, aby móc korzystać z serwerów baz S/390 i AS/400 przy użyciu monitora przetwarzania transakcyjnego. Założono, że użytkownik ma działający monitor przetwarzania transakcyjnego oraz zainstalowany produkt DB2 Connect, jak również skonfigurowane i przetestowane połączenie z serwerem baz danych hosta lub systemu AS/400. Szczegółowe informacje można znaleźć w podręczniku Krótkie wprowadzenie do produktu DB2 Connect.
Kroki niezbędne do skonfigurowania większości popularnych monitorów przetwarzania transakcyjnego można znaleźć w podręczniku Administration Guide. Konfigurowanie dla serwera baz danych DB2 UDB w sieci LAN nie różni się od konfigurowania serwera baz danych hosta lub AS/400. Następujące instrukcje zawierają zarys kroków ogólnej konfiguracji dla monitorów przetwarzania transakcyjnego, które nie zostały wymienione w podręczniku Administration Guide.
Aby skonfigurować produkt DB2 Connect, tak aby w monitorze przetwarzania transakcyjnego móc korzystać z serwerów baz danych S/390 i AS/400, należy wykonać następujące czynności:
SPM jest to komponent produktu DB2 Connect, który odwzorowuje protokół dwufazowego zatwierdzania XA na protokół dwufazowego zatwierdzania, używany przez serwery baz danych hosta i systemu AS/400. Domyślnie instancja DB2 ma predefiniowane wartości parametrów konfiguracyjnych SPM. Parametrem, który ma największe znaczenie jest parametr konfiguracyjny menedżera baz danych SPM_NAME. Domyślnie jest to kombinacja pierwszych siedmiu znaków nazwy hosta TCP/IP.
Jeśli do połączeń z DB2 for OS/390 używany jest protokół TCP/IP, to nie powinno się zmieniać żadnego z tych domyślnych ustawień. W takim przypadku konfiguracja SPM nie jest wymagana, ponieważ już działa. Jeśli dostęp do serwerów baz danych hosta lub AS/400 następuje za pośrednictwem protokołu SNA, to należy sprawdzić, czy wartość SPM_NAME reprezentuje poprawną jednostkę logiczną SNA w sieci komputerowej. Jeśli wartość domyślna SPM_NAME nie jest akceptowana, należy ją zmodyfikować za pomocą kreatora aktualizacji wielostanowiskowych.