OTC - Strona główna

  Download   |  Kontakt   |  Moje konto   |  Wyloguj się  

zalogowany: Gość / Guest




Winflector / Winflector Console
Serwer Mediator ISAM
Mediator - klient Delphi
Mediator - klient xBase/Clipper
Mediator - interfejs COM
Komponenty xHarbour dla Delphi
Interfejs COM dla xHarbour/DBF
Terminal GUI
Terminal Console
Terminal xBase
Jak kupić?
Download
Cennik
 


Rewolucja w świecie MySQL!
Darmowy, nielimitowany Mediator dla MySQL dla aplikacji xHarbour, Harbour oraz Delphi!
Szczegóły w Aktualnościach.
Strona główna  »  Produkty  »  Terminal xBase  »  Migracja aplikacji xBase

Migracja aplikacji xBase do architektury terminalowej

Poniżej opisano zasadę działania i możliwości oprogramowania Terminal oraz metodologię migracji aplikacji xBase (CA-Clipper/Harbour/xHarbour) do architektury terminalowej.

Tradycyjna architektura aplikacji xBase

Największą wadą systemów tworzonych w narzędziach xBase jest brak separacji funkcji zarządzania danymi od aplikacji. Funkcje zarządzania są podzielone pomiędzy wszystkie stacje robocze, na których wykonywana jest aplikacja. W konsekwencji uszkodzenie jednej ze stacji może spowodować istotne szkody w przechowywanych danych, a nawet uniemożliwić pracę pozostałym komputerom. Bardzo trudne jest zachowanie spójności danych i indeksów, a decentralizacja funkcji zarządzania danymi praktycznie uniemożliwia ich skuteczne zabezpieczenie przed niepowołanym dostępem. Przetwarzanie danych jest realizowane wyłącznie przez stacje robocze generujące ogromny ruch sieciowy, wykluczający racjonalne wykorzystanie aplikacji w sieciach rozległych.

Klient-serwer

Architektura klient-serwer przez wiele lat była uznawana za najlepsze rozwiązanie dla aplikacji baz danych. Zakłada ona podział zadań między stację roboczą a serwer. Umożliwia to znaczne zmniejszenie ruchu sieciowego, a scentralizowanie funkcji zarządzania bazą danych podwyższa poziom bezpieczeństwa całego systemu. Dzięki wprowadzeniu transakcyjności zachowanie spójności danych przestało być problemem. W trybie klient-serwer pracuje obecnie większość systemów transakcyjnych. Obok wielu zalet, architektura klient-serwer posiada również kilka wad. Należą do nich przede wszystkim duże wymagania na stację roboczą odpowiedzialną za przetwarzanie i prezentację wyników zapytań oraz wysokie koszty administrowania całym systemem. Ruch sieciowy, choć znacznie mniejszy niż w systemach z serwerem plików, pozostał jednak na tyle duży, aby mocno utrudnić wykorzystanie aplikacji w sieciach rozległych o niewielkich przepustowościach. Wielu z tych wad pozbawiona jest architektura terminalowa.

Terminal i serwer aplikacji

W architekturze terminalowej najważniejszym elementem jest serwer aplikacji, który może pełnić jednocześnie rolę serwera baz danych. Musi on być szczególnie wydajny w przeciwieństwie do terminali, których zadaniem jest wyłącznie obsługa klawiatury, wyświetlacza i realizacja funkcji komunikacyjnych. Koszt takich terminali jest minimalny. Odpowiedzialność za bezpieczeństwo sytemu spoczywa praktycznie wyłącznie na serwerze, dlatego zadania administratora systemu sprowadzają się głównie do obsługi serwera i utrzymania komunikacji sieciowej. Koszty administrowania tylko w minimalnym stopniu zależą od ilości dołączonych terminali. Ruch sieciowy generowany przez terminale jest tak mały, że umożliwia pracę wielu końcówek na łączach o niewielkiej przepustowości. Umożliwia to dołączanie całych oddziałów przedsiębiorstwa do centralnego serwera baz danych. Dotyczy to nie tylko nowo tworzonych systemów. Dzięki oprogramowaniu Terminal również aplikacje CA-Clipper mogą być uruchamiane w trybie terminalowym z serwerem aplikacji. Aplikacje te pracują bardzo efektywnie i są znacznie bezpieczniejsze od tradycyjnych zarówno w sieci LAN, jak i na łączach sieci rozległych.

OTC Terminal

Pakiet OTC Terminal przeznaczony jest do uruchamiania w trybie terminalowym zarówno tradycyjnych aplikacji CA-Clipper i/lub Harbour/xHarbour, jak i aplikacji wykorzystujących oprogramowanie Mediator do współpracy z serwerem relacyjnej bazy danych. Obie wersje pakietu Terminal wykorzystują serwer Windows NT/2000/XP/2003 jako serwer aplikacji. Konfiguracja sprzętowa serwera uzależniona jest od charakteru aplikacji i ilości użytkowników. Terminalami mogą być dowolne komputery PC (nawet i286) pracujące pod kontrolą MS DOS, Windows 95/98/ME/NT/2k/XP. Komunikacja terminala z aplikacją odbywa się za pośrednictwem protokołów IPX/SPX lub TCP/IP. Oprogramowanie składa się z trzech elementów:

  • Terminal Manager (terminal.exe) - agent pracujący na serwerze odpowiedzialny za uruchamianie odpowiedniej aplikacji na żądanie z terminala.

  • Terminal (te.exe) - program uruchamiany na stacji roboczej (terminalu) odpowiedzialny za obsługę klawiatury, ekranu, drukowanie, transmisję plików oraz komunikację z aplikacją wykonującą się na serwerze.

  • Biblioteki łączone z aplikacją CA-Clipper realizujące komunikację z terminalem i rozszerzenia architektury opisane w dalszej części artykułu.

Zasada działania oprogramowania przypomina znany z systemów UNIX protokół TELNET. Użytkownik zasiadający przy stacji roboczej uruchamia oprogramowanie terminala (te.exe) podając informacje niezbędne do zlokalizowania żądanej aplikacji na serwerze. Terminal wysyła te informacje do agenta (Terminal Manager) zainstalowanego na serwerze aplikacji, który uruchamia żądany program i odsyła do terminala informacje niezbędne do komunikacji z uruchomioną aplikacją. Po rozłączeniu z agentem, terminal nawiązuje połączenie z aplikacją, które jest wykorzystywane do przesyłania informacji o stanie klawiatury (od terminala do aplikacji) i o wyglądzie ekranu (od aplikacji do terminala). Dane przesyłane przez sieć są wstępnie kompresowane, co dodatkowo ogranicza ruch sieciowy. Aplikacja przeznaczona do pracy w trybie terminalowym musi zostać wstępnie dostosowana poprzez dołączenie bibliotek realizujących funkcje komunikacyjne i zawierających użyteczne rozszerzenia języka. W praktyce wystarczy to do uruchomienia aplikacji. Jeśli jednak użytkownik chce skorzystać z dostępnych rozszerzeń języka, powinien dokonać pewnych modyfikacji w kodzie źródłowym programu.

Co zyskujemy?

W porównaniu do tradycyjnej architektury aplikacji CA-Clipper z serwerem plików, architektura terminalowa ma wiele zalet:

  1. Wyższy poziom bezpieczeństwa danych wynikający z umieszczenia aplikacji i danych na tym samym serwerze, zastosowania rozszerzeń transakcyjnych gwarantujących zakończenie wykonywanej operacji oraz uniezależnienia się od awarii pojedynczych terminali.

  2. Zwiększona wydajność aplikacji osiągana dzięki lokalnemu wykonywaniu wszystkich operacji związanych z dostępem do plików.

  3. Efektywna praca w sieci rozległej umożliwiająca dołączanie pojedynczych stacji lub całych sieci LAN do centralnego serwera za pośrednictwem łączy o niewielkiej przepustowości.

  4. Niskie koszty instalacji i obsługi sprzętu komputerowego ograniczające się głównie do centralnego serwera - koszty terminali i sieci są bardzo niskie z uwagi na niewielkie wymagania sprzętowe i możliwość wykorzystania starego sprzętu.

  5. Prostota tworzenia aplikacji sieciowych integrujących dane całego, również wielooddziałowego przedsiębiorstwa - zbędne staje się stosowanie skomplikowanych i mało wydajnych mechanizmów replikacyjnych.

Aby maksymalnie zwiększyć bezpieczeństwo i wygodę korzystania z aplikacji, dołączane biblioteki zawierają wiele użytecznych funkcji realizujących rozszerzenia transakcyjne, wywoływanie z aplikacji procedur dołączonych do terminala (RPC), obsługę drukarek na terminalu, sterowanie priorytetami aplikacji.

Bezpieczeństwo danych

Aby wyjaśnić dlaczego praca terminalowa zwiększa bezpieczeństwo danych, należy zidentyfikować główne problemy występujące w tradycyjnej architekturze z serwerem plików. Zakładając, że korzystamy ze sprawnego serwera plików, najczęściej występują następujące uszkodzenia danych:
  1. Wpisanie bezsensownych informacji (losowego ciągu bajtów) do zbioru z danymi lub indeksu. Powodem może być uszkodzona stacja robocza, karta sieciowa, włączenie lub wyłączenie stacji w trakcie wysyłania wiadomości.

  2. Zaburzenie zgodności zbiorów DBF ze stowarzyszonymi indeksami. Powód: zerwanie łączności między aplikacją a serwerem plików po zmodyfikowaniu zbioru DBF a przed uaktualnieniem wszystkich indeksów. Przerwanie łączności wynika zwykle z uszkodzenia sieci, odłączenia stacji roboczej lub serwera od sieci, uszkodzenia lub wyłączenia stacji.

  3. Zaburzenie spójności logicznej danych. Zakładając że program napisany jest poprawnie, zaburzenie spójności logicznej może nastąpić w wyniku gwałtownego przerwania wykonywania programu, co uniemożliwia zakończenie logicznie powiązanych operacji (fragmentu kodu realizującego zależne od siebie zmiany w danych). Gwałtowne przerwanie wykonania programu jest zwykle następstwem zerwania łączności pomiędzy aplikacją a serwerem plików (przyczyny jak w punkcie 2).

Przy pracy terminalowej uszkodzenia typu 1. nie mogą wystąpić, gdyż aplikacja nie jest wykonywana na fizycznej stacji roboczej lecz w oknie DOS systemu Windows NT. Ewentualne problemy ze stacją roboczą spowodują rozłączenie terminala lub, w najgorszym przypadku, zniekształcenie obrazu wyświetlanego na terminalu.

Oprogramowanie Terminal zostało opracowane w taki sposób, że wykonanie aplikacji nie może zostać przerwane podczas uaktualniania indeksów, co eliminuje możliwość zaburzenia spójności indeksów i baz DBF, nawet w przypadku nagłego rozłączenia terminala. Ponieważ przy pracy w architekturze terminalowej dane (DBF, NTX) i aplikacja znajdują się na tym samym komputerze, przerwanie łączności między aplikacją i danymi jest praktycznie niemożliwe przy sprawnym serwerze. Pozostaje kwestia łączności pomiędzy aplikacją i terminalem. Domyślnie, aplikacja działająca w trybie terminalowym kończy działanie jeżeli wykryje, że połączenie z terminalem zostało przerwane. Może to spowodować zaburzenie spójności logicznej danych. Aby zapobiec takiej możliwości wprowadzono mechanizm transakcji terminalowej.

Transakcje terminalowe

Korzystając z funkcji TrmTsBegin() oraz TrmTsEnd() programista może oznaczyć w programie xBase fragmenty kodu które nie mogą być przerwane (Listing 1). Jeżeli łączność pomiędzy terminalem a aplikacją zostanie zerwana w momencie, gdy aplikacja jest w trybie transakcji terminalowej, fakt zerwania łączności zostanie zignorowany aż do momentu wywołania funkcji TrmTsEnd(), czyli do końca transakcji. Transakcja terminalowa gwarantuje pełne wykonanie oznaczonego fragmentu aplikacji. Prawidłowe wprowadzenie do aplikacji transakcji terminalowych eliminuje możliwość wystąpienia zaburzenia spójności logicznej danych. Pracując w architekturze terminalowej i korzystając z transakcji terminalowych można osiągnąć stabilność systemu i poziom bezpieczeństwa danych całkowicie niedostępny w tradycyjnych instalacjach z serwerem plików. Czynnikiem decydującym o stabilności i bezpieczeństwie danych staje się sprawność jednego elementu - serwera aplikacji. W tradycyjnych instalacjach bezpieczeństwo danych zależy od wielu elementów:
  • sprawności serwera plików

  • sprawności wszystkich stacji roboczych

  • sprawności sieci

  • dyscypliny pracowników


LISTING 1

&& Transakcje terminalowe

FUNCTION Ksieguj
PARAMETERS Konto1, Konto2, Kwota

TrmTsBegin() && rozpoczecie transakcji terminalowej

&& przeksiegowanie kwoty Kwota z konta1 na konto2 -
&& operacja wykonywana jest w transakcji i jest chroniona
&& przed przerwaniem nawet przy utracie polaczenia
&& aplikacji z terminalem

. . .

TrmTsEnd() && zakonczenie transakcji
RETURN


Mechanizm RPC (Remote Procedure Call)

Klasyczna praca terminalowa jednoznacznie określa podział zadań - aplikacja wykonuje się całkowicie na serwerze, terminal obsługuje ekran, klawiaturę i ewentualnie drukarki. Ponieważ oprogramowanie Terminal wykorzystuje w charakterze terminala komputer PC, możliwe stało się wprowadzenie mechanizmu zdalnego wywołania procedur (RPC) umożliwiającego wykonywanie fragmentów kodu nie w aplikacji a na terminalu. Programista może dołączyć własne funkcje do programu te.exe wykonywanego na terminalu i następnie wywoływać je z aplikacji przy pomocy funkcji TrmTrmRPC() przekazując ewentualne parametry wywołania. Po zakończeniu wykonania, procedura (funkcja) może zwrócić wynik do aplikacji (Listing 2a, 2b). Mechanizm RPC uzupełniają dwie funkcje (TrmPutFile(), TrmGetFile()) pozwalające przesyłać pliki w obu kierunkach między serwerem a terminalem. Zdalne wywołanie procedur jest bardzo ogólnym mechanizmem umożliwiającym efektywną realizację wszelkich nietypowych funkcji, które muszą być wykonywane na terminalu.

LISTING 2a

&& Odczytanie informacji z czujnika dolaczonego
&& do terminala za pomoca mechanizmu RPC

&& Funkcja dolaczana do programu te.exe wykonywanego na terminalu
&& odczytuje wartosc temperatury dla umownych wspolrzednych xc, yc

FUNCTION GetTemp
PARAMETERS xc, yc

tempVal = LowGetTemp(xc,yc) && odczytanie temperatury z czujnika

RETURN tempVal && odeslanie wartosci do aplikacji


LISTING 2b

&& Odczytanie informacji z czujnika dolaczonego
&& do terminala za pomoca mechanizmu RPC

&& Zdalne wykonanie funkcji GetTemp() na terminalu
&& z parametrami 10, 50

tempVal = TrmTrmRPC("GetTemp",10,50)

? "Odczytana przez terminal temperatura wynosi ", tempVal

. . .


Typowym zastosowaniem mechanizmu RPC jest obsługa nietypowych urządzeń peryferyjnych, np.:
  • obsługa czytnika kart magnetycznych,

  • obsługa czytnika kodów paskowych,

  • obsługa drukarek fiskalnych,

  • nietypowa obsługa drukarek (np. aplikacja generuje wydruk do pliku, kompresuje go, wysyła do terminala, terminal dekompresuje plik i drukuje go na drukarce),

  • implementacja własnych metod autoryzacji dostępu,

  • odczyt danych z czujników podłączonych do terminala.


Drukarki

Wydruki generowane przez aplikację najczęściej oczekiwane są na terminalu lub na drukarce sieciowej. Niezależnie od możliwości drukowania przez RPC, w oprogramowaniu Terminal dostępne są jeszcze dwie inne metody:
  1. Obsługa drukarek przez przechwycony port LPTx.
    Najprostszą metodą drukowania jest skorzystanie z domyślnie dostępnego mechanizmu przechwytywania portów drukarkowych LPT1, LPT2 oraz LPT3. Jeżeli program te.exe jest uruchamiany bez dodatkowych parametrów określających opcje przechwytywania, wówczas wszystkie trzy porty (LPT1-LPT3) widziane przez aplikację na serwerze Windows NT są automatycznie przechwytywane i dołączane do portów LPT1-LPT3 na stacji roboczej wykonującej program te.exe. Aplikacja CA-Clipper drukująca na porty LPT powinna bez zmian działać z oprogramowaniem Terminal. Aby wykorzystać tę metodę do programu te.exe należy przekazać dodatkowe parametry wpływające na przechwytywanie portów LPT:

    • /NOP - oznacza całkowitą rezygnację z przechwytywania portów LPT

    • /NOPn - oznacza rezygnację z przechwytywania portu LPTn na Windows NT. Opcja przydaje się wówczas gdy niektóre porty LPT na Windows NT są przekierowane na drukarkę (polecenie net use lptx) i chcemy skorzystać z tego przekierowania z aplikacji CA-Clipper/Terminal równocześnie zachowując przechwytywanie pozostałych portów.

    • /Pn=m - oznacza, że port LPTn na Windows NT ma być przechwycony i przekierunkowany na port LPTm na stacji roboczej. Opcja /P2=1 oznacza, że wszystkie wydruki wysyłane przez aplikację na port LPT2 będą drukowane na porcie LPT1 na stacji roboczej.

    • /Tn - określa czas w sekundach po którym procedura drukująca na stacji roboczej nie mogąc wydrukować żądanych informacji wyświetli komunikat: "Printer not ready. Continue printing (y/n)?". Domyślny czas wynosi 60 sekund. Opcja /T0 ustawia czas nieskończenie długi. Oznacza to, że wymieniony komunikat nie będzie się pojawiał, a próby drukowania będą ponawiane do skutku.



  2. Drukarki Windows NT
    Jedną z możliwości drukowania przez aplikację wykonującą się na serwerze Windows NT jest skorzystanie z drukarek zdefiniowanych w systemie. Mogą to być drukarki dołączone bezpośrednio do serwera NT lub dostępne przez sieć a fizycznie dołączone do innych komputerów z systemem Windows NT, Windows 95, Novell NetWare, stacji roboczych lub serwerów drukarek. Oprogramowanie TERMINAL udostępnia następujące funkcje umożliwiające korzystanie z drukarek systemu Windows NT:

    • TrmPrList() - pobranie informacji o drukarkach dostępnych w systemie

    • TrmPrFile() - wydrukowanie zawartości pliku na wskazanej drukarce

    • TrmPrOpen() - otwarcie sesji drukarkowej

    • TrmPrPut() - wysłanie do wydruku ciagu znaków w ramach otwartej sesji

    • TrmPrPutFl() - wysłanie do wydruku zawartości pliku w ramach otwartej sesji

    • TrmPrSubmt() - wysłanie do kolejki drukarki wydruku przygotowanego w wyniku wywołań TrmPrPut() i TrmPutFl()

    • TrmPrCancl() - usunięcie wydruku z kolejki drukarki

    • TrmPrClose() - zamknięcie sesji drukarkowej

Wszystkie wymienione funkcje oprócz TrmPrList() i TrmPrFile() mają charakter sesyjny - działają na drukarce otwartej w wyniku wywołania funkcji TrmPrOpen(). Typowa sekwencja wywołań dla trybu sesyjnego jest następująca:
  • TrmPrOpen() - otwarcie sesji - zwraca identyfikator drukarki

  • wielokrotne wywołanie funkcji TrmPrPut() i TrmPrPutFl() wysyłających dane do pliku stowarzyszonego z drukarką

  • TrmPrSubmt() - faktyczne rozpoczęcie drukowania przez wstawienie utworzonego pliku do kolejki drukarki

  • jeżeli zachodzi taka potrzeba można przerwać drukowanie wywołując funkcję TrmPrCancl()

  • zamknięcie sesji drukarkowej wywołaniem funkcji TrmPrClose()

Równocześnie może być otwartych wiele sesji drukarkowych dotyczących tej samej lub różnych drukarek.

Priorytety wykonania aplikacji

Domyślnie, każda aplikacja terminalowa wykonuje się na serwerze Windows NT z priorytetem normalnym. Korzystając z funkcji TrmGetPrty() oraz TrmSetPrty() aplikacja może manipulować swoim priorytetem wykonania (Listing 3). Na przykład, przy dużej liczbie sesji terminalowych wykonywanie skomplikowanych obliczeń i zestawień przez kilka aplikacji może wpłynąć na komfort pracy pozostałych, interaktywnych sesji. Obniżenie priorytetu aplikacji na czas wykonywania długich obliczeń sprawi, że będą one wykonywane jedynie wówczas gdy pozostałe sesje nie wykorzystują w pełni mocy procesora - interaktywne aplikacje będą działać bez opóźnień.

LISTING 3
&& Sterowanie priorytetem aplikacji

&& Symboliczne oznaczenia priorytetow
#define PRIORITY_LOW 0
#define PRIORITY_NORMAL 1
#define PRIORITY_HIGH 2
#define PRIORITY_RLTIME 3

FUNCTION ZestRok

oldPrty = TrmGetPrty() && zapamietanie biezacego priorytetu
TrmSetPrty(PRIORITY_LOW) && ustawienie niskiego priorytetu wykonania

&& wykonanie dlugotrwalych obliczen
&& przy niskim priorytecie

. . .

TrmSetPrty(oldPrty) && przywrocenie poczatkowego priorytetu
RETURN





 Polish English
| Mapa serwisu | Ochrona prywatności | Notka prawna | Uwagi | wersja do druku  wyślij e-mail