PL193583B1 - Sposób i urządzenie do przetwarzania danych typu klient/serwer - Google Patents

Abstract

1. Sposób przetwarzania danych typu klient/serwer, w którym wykonuje sie transak- cje, podczas których odbiera sie od klienta rozkaz transakcji zawierajacy kontekst transak- cji majacy specyficzna wartosc, za pomoca której wskazuje sie, ze transakcja zostala roz- poczeta przez klienta, lecz obiekty transakcyj- ne, reprezentujace transakcje, nie zostaly jesz- cze utworzone oraz rozpoznaje sie specyficzna wartosc w kontekscie transakcji i tworzy sie lokalnie obiekty transakcyjne w odpowiedzi na te specyficzna wartosc, znamienny tym, ze rejestruje sie lokalne zasoby wywolywane przez transakcje, za pomoca tworzonych lokalnie obiektów transakcyjnych. PL PL PL

Description

Opis wynalazku

Przedmiotem wynalazku jest sposób i urządzenie do przetwarzania danych typu klient/serwer, zwane również obliczaniem rozproszonym, w których urządzenie przetwarzające - klient wymaga zastosowania innego urządzenia przetwarzającego - serwera do wykonywania części pracy klienta, przy czym klient i serwer są umieszczone na przykład w tym samym urządzeniu przetwarzającym.

Znane przetwarzanie danych typu klient/serwer służy do przekazywania pewnej części pracy jednej maszyny drugiej maszynie, która jest na przykład lepiej dostosowana do wykonania tej pracy. Serwer jest na przykład komputerem dużej mocy, działającym z programem bazy danych, zarządzającym przechowywaniem ogromnej ilości danych, natomiast klient jest po prostu stołowym komputerem osobistym PC, który żąda informacji z bazy danych do użycia w jednym z programów lokalnych.

Znane jest udoskonalone przetwarzanie danych typu klient/serwer, stosujące znaną technikę programowania komputerowego, zwaną programowaniem obiektowym OOP, która umożliwia lokalizację klienta i serwera na różnych niejednorodnych platformach. Platforma jest kombinacją specyficznego sprzętu komputerowego/oprogramowania/systemu operacyjnego/protokołu telekomunikacyjnego, stosowaną przy pracy maszyny. Programowanie OOP umożliwia działanie programu aplikacyjnego klienta i programu aplikacyjnego serwera na własnych platformach, bez obawy o to, jak żądanie pracy aplikacji klienta będą wysyłane i odbierane przez aplikację serwera. Podobnie aplikacja serwera nie musi obawiać się, jak system OOP będzie odbierał, tłumaczył i przesyłał wyniki przetwarzania aplikacji serwera z powrotem do żądanej aplikacji klienta.

Znane techniki programowania OOP w niejednorodnych systemach przetwarzania danych typu klient/serwer są objaśnione na przykład w opisie patentowym USA nr 5440774 i opisie zgłoszenia patentowego europejskiego nr EP 0677943 A2, w których przedstawiono podstawową architekturę tych systemów.

Pos. 1 przedstawia komputer 10 klienta, który jest na przykład komputerem osobistym z zainstalowanym systemem operacyjnym IBM OS/2 i ma program aplikacyjny 40 działający w jego systemie operacyjnym. Program aplikacyjny 40 żąda okresowo wykonania pracy na komputerze 20 serwera i/lub zwrócenia danych z komputera 20 serwera do następnego wykorzystania przez program aplikacyjny 40. Komputer 20 serwera jest na przykład głównym komputerem dużej mocy, działającym w systemie operacyjnym MVS IBM. Dla celów wynalazku nie ma znaczenia, czy żądania usług komunikacyjnych do wykonania przez serwer są wywoływane przez pierwszy program aplikacyjny 40, czy też program aplikacyjny 40 działa niezależnie od oddziaływania wzajemnego z użytkownikiem i wysyła żądania automatycznie podczas przebiegu program.

Gdy komputer 10 klienta chce postawić żądanie na usługę komputera 20 serwera, pierwszy program aplikacyjny 40 informuje pierwszy układ logiczny 50 o żądanej usłudze. Wykonuje to na przykład przez przesłanie do pierwszego układu logicznego nazwy procedury zdalnej wraz z listą parametrów wejściowych i wyjściowych. Pierwszy układ logiczny 50 obsługuje wtedy zadanie utworzenia potrzebnej komunikacji z drugim komputerem 20 serwera w odniesieniu do określenia dostępnych usług komunikacyjnych, przechowywanych w urządzeniu pamięciowym 60. Wszystkie możliwe usługi są określone jako spójna struktura klasy 70 obiektów, przy czym te klasy są wyprowadzane z pojedynczej klasy obiektów. Określanie usług w ten sposób jest wydajne i możliwe do wielokrotnego zastosowania.

Dla utworzenia potrzebnej komunikacji z komputerem 20 serwera pierwszy układ logiczny 50 określa, której klasy obiektów należy użyć w strukturze i następnie tworzy egzemplarz tego obiektu w serwerze, przy czym zostaje wysłany komunikat do tego obiektu, aby spowodować wywołanie przez obiekt jednej z jego metod. Zapewnia to utworzenie połączenia z komputerem 20 serwera za pośrednictwem układu połączeniowego 80 i następne wysłanie żądania do drugiego układu logicznego 90.

Drugi układ logiczny 90 przekazuje następnie żądanie do drugiego programu aplikacyjnego usługowego 100, poniżej zwanego aplikacją usługową, działającego na komputerze 20 serwera, tak że aplikacja usługowa 100 wykonuje zadanie postawione w tym żądaniu, na przykład uruchomienie procedury odzyskiwania danych. Po wykonaniu tego zadania aplikacja usługowa wysyła wyniki z powrotem do pierwszego komputera 10 klienta. Aplikacja usługowa 100 oddziałuje wzajemnie z drugim układem logicznym 90 podczas wykonywania żądanych zadań i przy wysyłaniu wyników z powrotem do pierwszego komputera 10 klienta. Drugi układ logiczny 90 tworzy egzemplarze obiektów i wywołuje metody tych obiektów i gdy są one żądane przez aplikację usługową 100, egzemplarze obiektu są tworzone ze spójnej struktury klas obiektów w urządzeniu pamięciowym 110.

PL 193 583 B1

Przy stosowaniu tej techniki program aplikacyjny 40 klienta nie jest wystawiany na działanie architektury komunikacyjnej. Poza tym aplikacja usługowa 100 jest wywoływana przez mechanizm typowy dla środowiska i nie wie, że jest wywoływana zdalnie.

Grupa zarządzania obiektami OMG jest międzynarodowym zrzeszeniem organizacji biorących udział w różnych realizacjach przetwarzania danych typu klient/serwer na niejednorodnych platformach z obiektami rozproszonymi, jak pokazano na pos. 1. Grupa OMG opublikowała normy komunikacji komputerów klientów, jak komputer 10 klienta, przez programowanie OOP z maszynami serwera, jak komputer 20 serwera. Jako składnik tych norm określono obiektowego pośrednika zapytań ORB, zwanego CORBA, który stanowi most obiektowy między maszynami klienta i serwera. Pośrednik ORB odsprzęga aplikacje klienta i serwera od szczegółów implementacyjnych obiektowych, wykonując przynajmniej część pracy pierwszego i drugiego układu logicznego 50 i 90, jak również układu połączeniowego 80.

Grupa OMG zaproponowała, jako część struktury oprogramowania CORBA, standardy dotyczące transakcji, znane jako OTS czyli obsługa transakcji obiektowych, przedstawiona na przykład w publikacji CORBA Object Transaction Service Specification 1.0, dokument OMG 94.9.4. Realizowane komputerowo systemy przetwarzania transakcji są stosowane przy krytycznych zadaniach handlowych w niektórych gałęziach przemysłu. Transakcja oznacza pojedynczą jednostkę pracy, która musi być wykonana całkowicie albo usunięta całkowicie, bez działania. Na przykład, w przypadku bankomatu, z którego klient chce podjąć pieniądze, działania w celu wydania pieniędzy, powodujące zmniejszenie stanu pieniędzy do dyspozycji w automacie i zmniejszenie stanu bankowego klienta, muszą wystąpić wszystkie albo żadne z nich. Brak jednego z działań podrzędnych doprowadziłby do niezgodności między zapisami i stanami faktycznymi.

Przetwarzanie rozproszone transakcji obejmuje transakcję, która oddziałuje na zasoby w więcej niż jednej lokalizacji fizycznej lub logicznej. W powyższym przykładzie transakcja oddziałuje na zasoby zarządzane w lokalnym bankomacie, jak również na stany bankowe zarządzane przez główny komputer banku. Takie transakcje dotyczą jednego konkretnego komputera klienta, na przykład komputera 10 klienta, który komunikuje się z jednym konkretnym komputerem serwera, na przykład komputerem 20 serwera, przy szeregu żądań klienta, które są przetwarzane przez serwer. Obsługa transakcji obiektowych OTS grupy OMG jest odpowiedzialna za koordynację tych transakcji rozproszonych.

Zwykle aplikacja działająca przy przetwarzaniu klienta rozpoczyna transakcję, która może obejmować wywoływanie wielu różnych serwerów, z których każdy będzie inicjował proces serwera w celu dokonania zmian lokalnej bazy danych zgodnie z rozkazami zwartymi w transakcji. Transakcja kończy się przyjęciem transakcji do wykonania, czyli dokonaniem przez wszystkie serwery zmian w ich bazach danych, albo rezygnacją z transakcji, a zatem wycofaniem lub zignorowaniem wykonania przez wszystkie serwery zmian ich lokalnych baz danych. Dla zapewnienia komunikacji z serwerami podczas transakcji, na przykład instruowania ich co do przyjęcia lub odrzucenia części transakcji, jeden z wykonywanych procesów musi utrzymywać dane stanu transakcji. Dotyczy to zwykle procesu ustalenia szeregu obiektów transakcyjnych, z których jednym jest obiekt koordynacyjny, który koordynuje transakcję względem różnych serwerów.

Pos. 2 przedstawia znaną realizację obsługi transakcji obiektowych OTS, opracowanej przez International Business Machines Corporation w produkcie Component Broker Series. Proces 21 klienta, który chce rozpocząć transakcję, na przykład podjęcie pieniędzy z rachunku bankowego, musi zlokalizować proces, który jest zdolny do utworzenia i przechowywania obiektów transakcyjnych, które utrzymują stan transakcji. Nową tendencją jest tworzenie komputerów klientów, które mają tylko minimum możliwości funkcjonalnych, więc proces 21 klienta zwykle nie jest w stanie utrzymywać obiektów transakcyjnych lokalnie i musi użyć do tego celu procesu serwera.

Według tego znanego sposobu, obsługa transakcji obiektowych OTS lub inna usługa, jak na przykład usługa CORBA Lifecycle, wyszukuje proces serwera dla utworzenia na nim obiektów transakcyjnych 221, które obejmują obiekty: koordynatora, sterowanie i terminatora. Zostaje wybrany zawsze ten sam proces serwera, na pos. 2 proces 22 serwera A. Po zlokalizowaniu procesu 22 serwera A, proces 21 klienta nadaje komunikat, co oznaczono liczbą 1 w kółku, do procesu 22 serwera A z poleceniem utworzenia przez proces 22 serwera A obiektów transakcyjnych 221. Następnie proces 2,2 serwera A tworzy obiekty transakcyjne 221 i wysyła odpowiedź, co oznaczono liczbą 2 w kółku, zawierającą kontekst transakcji do procesu 21 klienta. Proces 21 klienta nadaje wtedy polecenie obciążenia rachunku bankowego, co oznaczono liczbą 3 w kółku, do procesu 23 serwera B, czyli procesu zawierającego obiekt 231 rachunku bankowego, z którego proces 21 klienta żąda wypłaty. Ten

PL 193 583 B1 ostatni rozkaz przenosi jednocześnie kontekst transakcji, dostarczany do procesu 21 klienta przez proces 22 serwera A. Dzięki temu obiekt 231 rachunku bankowego w procesie 23 serwera B rejestruje się, co oznaczono liczbą 4w kółku, wraz obiektami transakcyjnymi 221w procesie 22 serwera A, tak że obiekt 231 rachunku bankowego wykonuje rozkaz, co oznaczono liczbą 5 w kółku, dla przystąpienia do transakcji lub wycofania się z transakcji, który został wydany przez obiekty transakcyjne 221na końcu transakcji. Jednak to wykonanie jest nieskuteczne, ponieważ jest wykorzystywany zawsze ten sam proces serwera, gdy klient lokalizuje proces zdalny do tworzenia i utrzymywania obiektów transakcji, a ten proces serwera szybko ulega przeciążeniu i jest niezdolny do skutecznego wykonywania własnych zadań, na przykład aktualizacji treści zasobów lokalnych. Poza tym między różnymi procesami przy transakcji występuje wiele skrośnych przepływów procesowych. Nawet, jeżeli obiekty transakcyjne są tworzone i utrzymywane na przypadkowym serwerze, zawsze występuje problem wielu skrośnych wywołań procesowych.

Znany jest z opisu wynalazku w dokumencie WO 97 40457 A transakcyjny system przetwarzania danych typu klient/serwer, w którym serwer przyporządkowuje każdej sesji klienta unikalny znacznik.

Sposób według wynalazku charakteryzuje się tym, że rejestruje się lokalne zasoby wywoływane przez transakcję, za pomocą tworzonych lokalnie obiektów transakcyjnych.

Urządzenie według wynalazku charakteryzuje się tym, że zawiera element rejestracji lokalnych zasobów wywoływanych przez transakcję, za pomocą tworzonych lokalnie obiektów transakcyjnych.

Zaletą wynalazku jest to, że liczba skrośnych przepływów procesowych zmniejsza się znacznie w porównaniu ze znanymi rozwiązaniami. Proces klienta nie wymaga zastosowania rozkazów tworzenia transakcji w sposób dedykowany, natomiast tworzenie transakcji, dotyczące klienta, jest łączone z bezpośrednim rozkazem transakcji klienta, na przykład poleceniem obciążenia rachunku bankowego. Wynalazek zapewnia klientowi uniknięcie konieczności lokalizacji procesu serwera zdalnego i generacji metody tworzenia w tym zlokalizowanym procesie.

Przedmiot wynalazku jest pokazany w przykładzie wykonania na rysunku, na którym pos. 1 przedstawia w postaci schematu blokowego strukturę niejednorodną klient/serwer stosującą technikę obiektową w kontekście wykonania wynalazku, pos. 2 -w postaci schematu blokowego znane wykonanie obsługi transakcji obiektowych OTS, fig. 3 w postaci schematu blokowego wykonanie obsługi transakcji obiektowych OTS według wynalazku i fig. 4 -sieć działań po wydaniu przez klienta rozkazu rozpoczęcia wykonania obsługi transakcji obiektowych OTS z fig. 3.

Obsługa transakcji obiektowych OTS obiektowego pośrednika zapytań, zwanego CORBA, zapewnia obiekt interfejsowy zwany aktualnym, który określa metodę rozpoczynania, stosowaną przez programy aplikacyjne klientów z kodem źródłowym, dla sygnalizacji rozpoczęcia transakcji niższym warstwom oprogramowania. Gdy aplikacja klienta jest tworzona lub wykonywana w konkretnej strukturze klienta i zawiera metodę rozpoczynania, oprogramowanie niższych warstw przebiega odpowiednio dla tworzenia transakcji przez ustalanie obiektów stanu transakcji w serwerze, który jest bezpośrednio wprowadzany do transakcji, na przykład w serwerze, który ma zasoby wprowadzane do transakcji.

Figura 3 przedstawia, że aplikacja działająca w procesie 31 klienta rozpoczyna transakcję, jak zwykle od wywołania metody rozpoczynania w aktualnym obiekcie interfejsowym. Proces klienta rejestruje następnie fakt, że wydał rozkaz, na przykład przez lokalne utworzenie minimalnego zestawu obiektów. Powyższe działanie jest przeprowadzane w kroku 41 sieci działań zfig. 4. Założono, że realizowana transakcja jest transakcją podejmowania pieniędzy z rachunku bankowego, zwykłą operacją transakcyjną, która jest realizowana codziennie na całym świecie, przy użyciu bankomatu przez klienta.

W rozwiązaniach znanych, w tym etapie był lokalizowany zdalny proces 22 serwera A, w którym były tworzone obiekty transakcyjne 221 pokazane na pos. 2. Według wynalazku tworzenie obiektów transakcyjnych jest opóźniane do pewnego momentu, co objaśniono poniżej.

Aplikacja działająca w procesie 31 klienta wydaje następnie dla obiektu 331 polecenie obciążenia rachunku bankowego w procesie 33 serwera B, jako pierwszą część transakcji podejmowania pieniędzy. Wtym przypadku polecenie obciążenia jest pierwszym, po wydaniu rozkazu rozpoczynania, zdalnym przepływem w transakcji procesu klienta. Przy wykonywaniu tego rozkazu proces klienta musi włączać do rozkazu pewien kontekst transakcyjny, który dostarcza obiektowi 331 rachunku bankowego informację, że rozkaz jest częścią transakcji i który identyfikuje konkretną transakcję.

W rozwiązaniach znanych proces 21 klienta odbiera kontekst transakcyjny z obiektów transakcyjnych 221 ustalanych w zdalnym procesie 22 serwera A. Natomiast według wynalazku obiekty transakcyjne nie zostały jeszcze utworzone, a zatem nie mogły dostarczyć kontekstu transakcyjnego

PL 193 583 B1 do procesu klienta. Zatem, gdy proces 31 klienta wysyła polecenie obciążenia do obiektu 331 rachunku bankowego w zdalnym procesie 33, do rozkazu jest włączany kontekst specyficznej transakcji, oznaczony liczbą 1w kółku na fig. 3, na przykład kontekst transakcyjny zerowy. Kontekst transakcyjny zerowy oznacza, że wszystkie pola kontekstu transakcyjnego są ustawione na wartość zerową. Ten specyficzny kontekst transakcyjny oznacza, że transakcja została rozpoczęta, lecz obiekty transakcyjne nie zostały jeszcze utworzone. Tę ostatnią operację przedstawiono na fig. 4 jako krok 42.

Gdy proces 33 serwera B rozpoznaje ten specyficzny kontekst transakcyjny, na przykład kontekst transakcyjny zerowy, jest informowany, że transakcja została rozpoczęta, lecz obiekty transakcyjne nie zostały jeszcze utworzone. Proces 33 serwera B tworzy wtedy te obiekty transakcyjne 332 lokalnie w kroku 43. Gdy są już utworzone obiekty transakcyjne 332, transakcja ma ważny kontekst transakcyjny, który zostaje przypisany transakcji. Proces serwera B wysyła następnie odpowiedź, oznaczoną liczbą 2 w kółku, do procesu 31 klienta dla poinformowania procesu 31 klienta o ważności kontekstu transakcyjnego w kroku 44 na fig. 4. Teraz proces klienta ma pełną wiedzę o tworzonej transakcji.

W tym etapie obiekt 331 rachunku bankowego komunikuje się w kroku 45 z obiektami transakcyjnymi 332 w zwykły sposób, z tym wyjątkiem, że wszystkie takie komunikacje odbywają się w tym samym procesie, a zatem do takiej komunikacji nie są potrzebne skrośne przepływy procesowe. W tym przykładzie komunikacja obejmuje rejestrację obiektu 331 rachunku bankowego przez obiekty transakcyjne 332 i po zakończeniu transakcji obiekty transakcyjne 332 wysyłają do obiektu 331 rachunku bankowego rozkaz wykonania lub wycofania się z transakcji.

W innym przykładzie wykonania wynalazku proces 33 serwera B tworzy obiekty transakcyjne w późniejszym czasie, na przykład podczas rejestracji zasobów, zamiast natychmiast po wprowadzeniu kontekstu transakcyjnego zerowego procesu 33 serwera B.

W tym przykładzie wykonania wykorzystano kontekst transakcyjny zerowy, ze wszystkimi polami ustawionymi na zero, lecz możliwe jest zastosowanie innych specyficznych wartości kontekstu transakcyjnego, na przykład ustalenie konkretnych wartości w polach danych prywatnych kontekstu transakcyjnego.

Claims (2)

1. Sposób przetwarzania danych typu klient/serwer, w którym wykonuje się transakcje, podczas których odbiera się od klienta rozkaz transakcji zawierający kontekst transakcji mający specyficzną wartość, za pomocą której wskazuje się, że transakcja została rozpoczęta przez klienta, lecz obiekty transakcyjne, reprezentujące transakcję, nie zostały jeszcze utworzone oraz rozpoznaje się specyficzną wartość w kontekście transakcji i tworzy się lokalnie obiekty transakcyjne w odpowiedzi na tę specyficzną wartość, znamienny tym, że rejestruje się lokalne zasoby wywoływane przez transakcję, za pomocą tworzonych lokalnie obiektów transakcyjnych.

2. Urządzenie do przetwarzania danych typu klient/serwer do wykonywania transakcji, zawierające układ odbioru od klienta rozkazu transakcji zawierającego kontekst transakcji mający specyficzną wartość do wskazywania rozpoczęcia transakcji przez klienta, oraz układ rozpoznawania specyficznej wartości i tworzenia lokalnie obiektów transakcyjnych, znamienny tym, że zawiera element rejestracji lokalnych zasobów (331) wywoływanych przez transakcję, za pomocą tworzonych lokalnie obiektów transakcyjnych (332).