Transakcje w środowisku rozproszonym

Aplikacje bazodanowe osiągnęły już granice możliwości dwuwarstwowej architektury klient/serwer; dalszy rozwój jest możliwy już tylko w wersji trójwarstwowej.

Aplikacje bazodanowe osiągnęły już granice możliwości dwuwarstwowej architektury klient/serwer; dalszy rozwój jest możliwy już tylko w wersji trójwarstwowej.

Obecnie już tylko nieliczne aplikacje przygotowywane są jako produkty monolityczne. Aby zminimalizować wpływ zmian, wprowadzanych w czasie "życia" aplikacji, programiści coraz częściej posługują się modelem przetwarzania obiektowego, zapewniającego większe możliwości modyfikowania aplikacji, korzystania z komponentów komercyjnych i tworzenia aplikacji rozproszonych.

Również eksplozja Internetu ma ogromny wpływ na przechodzenie w stronę modelu przetwarzania obiektowego w środowisku rozproszonym. Pierwsze, proste aplikacje internetowe szybko zmieniają swój charakter, zapewniając coraz szerszą gamę usług, a handel elektroniczny wymaga koordynowania transakcji na skalę nie znaną w tradycyjnych aplikacjach komercyjnych.

Stąd zapotrzebowanie na produkty zapewniające obiektowe usługi transakcyjne, służące do:

  • koordynowania wielu komponentów w ramach jednej transakcji

  • umożliwienia dostępu wielu komponentom do jednego lub wielu źródeł danych

  • zapewnienia integralności danych w wielu bazach danych

  • zapewnienia bezpieczeństwa w Internecie i korporacyjnym intranecie.

Monitory transakcji, serwery aplikacji, brokery obiektowe

Profesjonalni informatycy od lat budowali wysoko wydajne aplikacje transakcyjne. Największe aplikacje tego typu działają głównie na mainframe'ach. Na świecie nadal ponad 80% danych jest zarządzanych przez mainframe'y. Już w latach 70. opracowano programy o nazwie monitor transakcyjny (IBM CICS, AT&T Tuxedo, NCR TopEnd), stanowiące podstawę tego typu aplikacji, a służące do zapewnienia bezpieczeństwa danych, równomiernego rozkładania obciążenia na wiele procesorów lub komputerów w sieci, obsługi dużej liczby klientów.

Zmiana podejścia do tworzenia aplikacji, związana z rozpowszechnieniem się graficznego interfejsu użytkowego, spowodowała powstanie modelu przetwarzania typu klient/serwer, w którym nie było już miejsca na monitor transakcji. Jednak możliwości takiego modelu przetwarzania były ograniczone - w efekcie powstał trójwarstwowy model przetwarzania klient/serwer, zawierający pośrednią warstwę z serwerem aplikacji, zapewniający lepsze możliwości aplikacjom klient/serwer.

Wiele firm podejmowało trud opracowania własnych rozwiązań serwera aplikacji. Jak ironicznie spointował jeden z analityków IDC: "...nie przychodzi im na myśl opracowanie własnej bazy danych, natomiast podejmują się opracowania serwera aplikacji, mimo że jest to równie trudne zadanie". Jest to bowiem praca przekraczająca możliwości intelektualne i finansowe większości zespołów informatycznych. Na szczęście, skoordynowane działania przemysłowego konsorcjum Object Management Group (OMG) doprowadziły do opracowania specyfikacji Common Object Request Broker Architecture (CORBA), pozwalającej na tworzenie współpracujących ze sobą brokerów obiektowych ORB, zapewniających usługi serwera aplikacji.

CORBA stała się standardem de facto architektury przetwarzania rozproszonego. W efekcie na rynku pojawiło się kilkunastu producentów brokerów obiektowych, m.in. Digital, IBM, Iona Technologies, Visigenic. Również najwięksi producenci baz danych (Oracle, Sybase) opracowali własne rozwiązania serwera aplikacji bądź brokera obiektowego. Konkurencja i łączenie firm lub zakup produktu od oryginalnego twórcy wpłynęły na zmniejszenie liczby producentów brokerów obiektowych. Obecnie na rynku brokerów obiektowych ORB liczą się praktycznie jedynie Iona, Inprise (dawny Borland, który zakupił firmę Visigenic) i IBM. Inni korzystają z licencjonowanych technologii ORB do tworzenia specjalizowanych wersji serwerów aplikacji w niejednorodnym, obiektowym środowisku przetwarzania.

Wszystkie brokery obiektowe korzystają ze standardowego protokołu Internet Inter-ORB Protocol (IIOP), działającego na warstwie transportowej TCP/IP do komunikacji między obiektami.

Transakcje w środowisku rozproszonym

Do koordynowania transakcji w środowisku rozproszonym z wieloma bazami danych nie wystarcza używanie tylko serwera aplikacji bądź brokera obiektowego. Niezbędna jest współpraca z pakietem zapewniającym usługi transakcyjne. Z tego powodu OMG opracowało rozszerzenia do specyfikacji CORBA, mające na celu stworzenie usług transakcyjnych, nadbudowanych na typowym brokerze obiektowym lub stanowiącym jego integralną część.

Opracowana przez OMG specyfikacja CORBA Transaction Service ma służyć zapewnieniu integralności transakcji w aplikacjach rozproszonych. Wielu programistów neguje konieczność stosowania pakietu usług transakcyjnych w środowisku z jedną bazą danych. Jednak powszechna tendencja do przechodzenia na rozwiązania korzystające z techniki obiektowej wymusi również i w tym przypadku konieczność koordynacji działań wielu obiektów. Łatwiej jest bowiem prezentować konto każdego użytkownika jako obiekt. Podobnie obiektem może być skomplikowana operacja transferu zasobów między kontami. Zamiast zajmować się koordynacją operacji z poziomu obiektu transferu, łatwiej jest skorzystać z usług transakcyjnych wbudowanych w broker obiektowy. Ponadto zastosowanie modelu rozproszonego w systemie monolitycznym ułatwi przejście w przyszłości na rozproszony model aplikacji.

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

TOP 200