Klient/serwer: druga generacja

W znanym powiedzeniu o stanie współczesnej informatyki stwierdza się, że charakterystyczną jej cechą jest ciągła zmienność. To samo dotyczy nowych technik opracowania i uruchamiania aplikacji rozproszonych, zwanych umownie aplikacjami klient/serwer.

W znanym powiedzeniu o stanie współczesnej informatyki stwierdza się, że charakterystyczną jej cechą jest ciągła zmienność. To samo dotyczy nowych technik opracowania i uruchamiania aplikacji rozproszonych, zwanych umownie aplikacjami klient/serwer.

Idea decentralizacji obliczeń rozwija się od momentu pojawienia się komputera PC w 1981 r., a więc już od 15 lat. Wielu użytkowników w firmach dąży do uniezależnienia się od potrzeb obliczeniowych od dużego komputera, zainstalowanego gdzieś tam w szklanej klatce i obsługiwanego przez dział informatyki firmy. Pierwsze produkty i aplikacje, określane mianem klient/serwer, pojawiły się już dawno w wyniku tej właśnie decentralizacji obliczeń i nosiły wszelkie znamiona bałaganu, jaki wiązał się od początku z rewolucją PC. Narzędzia i aplikacje klient/serwer wykazywały poważne ograniczenia w zakresie skalowalności oraz elastyczności. Dopiero w ostatnim czasie zaczynają pojawiać się nowe narzędzia do tworzenia aplikacji klient/serwer (a z nimi aplikacje), które można określić mianem systemów klient/serwer drugiej generacji.

Dlaczego klient/serwer?

Wiele dużych firm jest obsługiwanych przez systemy informatyczne sprzed 20 i więcej lat, działające na dużych komputerach. Aplikacje nie tylko są stare - one także nie dają się już zmieniać. Zmiana jednej tabeli w bazie w celu dostosowania do nowych wymagań w działalności, może pociągnąć za sobą konieczność zmieniania kodu w tysiącach programów, których działanie zależy od konkretnych właściwości tej właśnie tabeli.

Konieczność odejścia od tych aplikacji i tego sposobu przetwarzania danych spowodowała, że wraz z pojawieniem się komputerów PC pojawiły się pierwsze systemy klient/serwer.

Pierwsza generacja systemów klient/serwer

Pierwsze systemy klient/serwer wykorzystywały możliwości jakie dają komputery PC w celu stworzenia na nich graficznego interfejsu użytkownika do relacyjnych baz danych przechowywanych nadal na dużych komputerach (aplikacje zorientowane na serwer danych), bądź przeniesienia na PC całej logiki działania aplikacji (PC centryczne).

Nie są to rozwiązania zadowalające. Przy podejściu zorientowanym na PC nie można uzyskać właściwej skalowalności, gdyż moc obliczeniowa PC jest niewielka i nie nadaje się on do obsługi bardzo złożonych aplikacji. Podejście zorientowane na wykorzystanie dużego komputera pozwala na tworzenie potężnych aplikacji działających na nim, ale nie daje ono elastyczności właściwej dla PC.

Narzędzia pierwszej generacji

Narzędzia klient/serwer pierwszej generacji, takie jak PowerBuilder, Visual Basic czy Gupta SQL Windows, są nastawione na budowanie aplikacji graficznych, zastępujących dawne aplikacje znakowe. Bardzo ładny interfejs użytkowy w gotowej aplikacji to ich główna, a czasem jedyna zaleta.

Łatwość tworzenia graficznego interfejsu użytkowego zwodzi użytkownika końcowego co do faktycznych możliwości tych narzędzi. W miarę rozwoju potrzeb okazuje się, że narzędzia te nie mogą spełnić oczekiwań bardziej wymagających użytkowników. Na ogół nie nadają się także do tworzenia aplikacji skalowalnych wraz ze wzrostem zapotrzebowania na moc obliczeniową, ilość przetwarzanych danych, potrzebę dostępu do wielu baz danych itp.

Bardzo ładny graficznie prototyp aplikacji może prowadzić do wyników niepożądanych w dalszej perspektywie rozwoju informatyki w firmie. Użytkownik zobaczywszy prototyp aplikacji na ogół przecenia jej możliwości, których nie jest w stanie dostarczyć w sensownym czasie zespół informatyków. Jeżeli presja użytkowników jest za duża, informatycy muszą się jej poddać, co prowadzi do zaniechania innych projektów (ostatecznie informatyk też musi kiedyś spać). Często jednak produkt końcowy nie spełnia (nie uzasadnionych) oczekiwań użytkowników, a wynika to głównie z ograniczeń dostępnych im narzędzi.

Poważnym problemem narzędzi 1. generacji jest ich ograniczona skalowalność. Używany powszechnie system Windows 3.1 nie jest ani wielozadaniowy (zrealizowano w nim bowiem prymitywną wielozadaniowość kooperacyjną), ani nie nadaje się dla wielu użytkowników. Obecne aplikacje są jednozadaniowe i jednowątkowe. Nie można ich więc łatwo podzielić na część uruchamianą na serwerze i na część uruchamianą na stacji klienta. Złożona aplikacja musi nadal w całości działać na stacji klienta w Windows. Jeżeli zaś potrzebne jest napisanie wysoko wydajnej części kodu, musi robić się to w języku 3GL, na ogół C - wydajność programisty znacznie spada.

W systemach 1. generacji nie ma się dostępu do specjalistycznych narzędzi do opieki nad kodem, pracy grupowej, kontroli wersji z możliwościami powrotu do dawniejszych wersji kodu itp. Wszystko to prowadzi kuo tworzeniu aplikacji, które za rok czy dwa staną się równie trudno modyfikowalne, jak używane obecnie aplikacje sprzed 20 lat.

Obecne aplikacje klient/serwer charakteryzują się na ogół bardzo dużymi rozmiarami (tzw. syndrom grubego klienta), gdyż faktycznie działają wyłącznie na stacji klienta.

Uwarunkowania

Dostępność i łatwość użycia PC powoduje, że zwykli użytkownicy stają się programistami - korzystają z wizualnych narzędzi, nie oglądają się na informatyków firmy, piszą aplikacje spełniające ich obecne potrzeby. Korzystają z zasobów danych z dużego komputera czy z mini, ale tworzą raczej protezy prawdziwego rozwiązania problemów dostępu do danych. Wielość niespójnych aplikacji powoduje, że coraz trudniej zarządzać zasobami danych firmy, określać uprawnienia, wprowadzać nowe wersje programów związanych ze zmieniającym się profilem działalności itp.

Coraz większe wymagania użytkowników mogą spełnić tylko wielkie, złożone systemy informacyjne, dobrze przystosowane do wymagań firmy, ale jednocześnie łatwe do utrzymania, modyfikacji i uaktualniania. Ich opracowanie wymaga zespołowego wysiłku wszystkich informatyków firmy w ścisłej współpracy z użytkownikami, efektywnego wykorzystania pracy (nie można wynajdywać koła od nowa przy każdym nowym projekcie) przez zapamiętanie danych o elementach aplikacji i obiektach w bazie danych - repozytorium wspólnym dla wszystkich aplikacji. Narzędzia 1. generacji nie dają takich możliwości.

W aplikacjach rozproszonych szczególnego znaczenia nabiera spójność modelu danych dla całej firmy. Te same dane nie mogą być interpretowane różnie przez różne działy firmy. Zapobiec temu może jedynie wspólna, dostępna dla wszystkich, definicja zasadniczych terminów i wymagań oraz reguł działania, najlepiej zrealizowanych w postaci procedur zapamiętanych w bazie, wspólnych dla wszystkich aplikacji. Jeżeli ponadto w firmie dostępne będą wspólne elementy składowe aplikacji, opracowane przez profesjonalnych informatyków zgodnie z wymaganiami jej działania, to nie odbierzemy użytkownikom najważniejszej możliwości, jaką daje im PC - samodzielnego opracowania aplikacji, bez obawy utraty kontroli nad danymi.

Właściwości narzędzi 2. generacji

Podany poniżej wykaz właściwości wygląda trochę na listę pobożnych życzeń, gdyż nie ma na rynku narzędzi, spełniających w całości te wymagania. Jednakże jego cel jest jasny - wskazanie kierunku poszukiwań. Im więcej cech mają nowe narzędzia, tym większa szansa, że będą nam służyć kilka lat do realizacji aplikacji, bez konieczności zmiany kwalifikacji i związanego z tym zmniejszenia wydajności.

Najważniejsze cechy narzędzi 2. generacji są następujące:

- skalowalność

- partycjonowanie aplikacji

- obsługa replik baz danych

- przetwarzanie transakcyjne

- bezpieczeństwo

- testowanie i utrzymanie aplikacji

- praca wieloplatformowa

- obiektowość.

Skalowalność - to termin chętnie nadużywany, mimo że tylko nieliczni producenci narzędzi mają produkty dające aplikacje rzeczywiście skalowalne. Celem zaś jest narzędzie nadające się do opracowania aplikacji zarówno dla 10, jak i dla 1000 użytkowników. Aplikacja skalowalna musi obsługiwać coraz większą liczbę zdarzeń (działań użytkowników) bez zmniejszenia wydajności i niezawodności. Narzędzie skalowalne zaś powinno równie dobrze nadawać się do pracy zespołowej zarowno 3, jak i 30 programistów, zapewniając pełną kontrolę nad aplikacjami.

Partycjonowanie aplikacji - to wymaganie coraz ważniejsze. Bardziej złożone przetwarzanie danych wymaga coraz większej mocy obliczeniowej, której nie może dostarczyć PC. Przeniesienie części kodu aplikacji na serwer danych, a jeszcze lepiej na specjalny serwer aplikacji, ułatwia konserwację części kodu wspólnej dla wielu aplikacji, zapewniając wysoką wydajność.

Obsługa replik baz danych. Z punktu widzenia wydajności aplikacji, zwłaszcza związanych z intensywnym przetwarzaniem transakcji - im dane znajdują się bliżej użytkownika, tym większa wydajność. Możliwość elastycznego korzystania z lokalnych kopii danych i niewidoczne dla użytkownika rozstrzyganie ewentualnych konfliktów spójności danych jest cechą szczególnie ważną w każdym projekcie. Problemy te rozwiązują wielcy producenci systemów zarządzania bazami danych proponując różne formy replikacji, natomiast mało dostrzegają producenci narzędzi.

Przetwarzanie transakcyjne. Zawsze stanowiło domenę dużych komputerów. Nawet obecnie niektórzy analitycy systemowi uważają, że relacyjne bazy danych nie nadają się do obsługi dużego wolumenu transakcji on-line. Tymczasem jednak zanikają typowe systemy transakcyjne z mainframem, zaś środowisko przetwarzania rozproszonego z relacyjnymi bazami danych musi przejąć ich obsługę. Współpraca narzędzi do opracowania aplikacji z monitorami transakcji (Tuxedo Novella, Encina firmy Transarc, CICS IBM-a i in.) stanowi warunek uzyskiwania wydajnej obsługi transakcji przez systemy unixowe.

Bezpieczeństwo. Jeżeli pewnego dnia wszystkie systemy mainframe'owe o dużej centralizacji i dużym poziomie bezpieczeństwa danych mają być zastąpione przez systemy rozproszone, to muszą one zapewniać taki sam poziom ochrony dostępu do danych, jak i ochrony samych danych (archiwizowanie, odzyskiwanie po awarii, wysoka dostępność danych). Większość obecnie realizowanych aplikacji klient/serwer pomija milczeniem problemy ochrony danych przed niepowołanym dostępem, ograniczając się do możliwości jakie oferuje system operacyjny (logowanie). Jednocześnie przesyła się w sieci "otwartym tekstem" hasła dostępu, co stanowi zachętę dla włamywaczy.

Skorzystanie z zaleceń, opracowań i narzędzi konsorcjum Distributed Computing Environment (DCE) daje możliwość połączenia przetwarzania rozproszonego z handlowymi serwerami bezpieczeństwa (Kerberos). Żaden zestaw narzędzi do opracowania aplikacji nie korzysta na razie z usług bezpieczeństwa DCE. Podobnie żaden pakiet narzędziowy nie zajmuje się zagadnieniami ochrony danych przed awariami, co jest szczególnie trudne do rozwiązania w środowisku przetwarzania rozproszonego.

Testowanie i utrzymanie aplikacji. Większość systemów mainframe'owych zawiera narzędzia do testowania i utrzymywania aplikacji. W środowisku przetwarzania rozproszonego nie istnieją takie procedury ani standardy. Jeżeli więc nawet istnieją rozwiązania tych problemów w pakietach narzędziowych CASE, są one cząstkowe i nie nadają się do współpracy z narzędziami innych producentów.

Praca wieloplatformowa. Wymaganie sine qua non w środowisku rozproszonym. Użytkownik nie chce z góry decydować jaki sprzęt i system operacyjny ma zakupić. Zresztą szybkość zmian technologii jest tak duża, że każda decyzja szybko staje się nieaktualna.

Obiekty. Jedna z najważniejszych zmian, jaką obserwujemy od kilku lat w zakresie opracowania aplikacji, to przechodzenie na narzędzia obiektowe. Obiecują one elastyczność, wielokrotne używanie raz opracowanych części kodu (obiektów), tworzenie aplikacji modularnych i dostarczenie zwykłemu użytkownikowi możliwości tworzenia aplikacji przez składanie obiektów. Zwykle narzędzia obiektowe oferują także możliwość korzystania z repozytorium danych o danych, obiektach i aplikacjach.

Panaceum

Oczywiście nie istnieje. Gdyby pewnego dnia firma wyrzuciła wszystkie dane, aplikacje i narzędzia oraz rozpoczęła działalność informatyczną na nowo, to i tak nie uchroni się przed powstawaniem aplikacji, które za kilka lat staną się przestarzałe, trudne do utrzymania i niedostosowane do profilu jej działalności. Jednakże im lepsze narzędzia wybierzemy obecnie, tym większa szansa, że ten moment nastąpi później.

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

TOP 200