Aplikacje klient/serwer przechodzą z poziomu departamentalnego na poziom przedsiębiorstwa.

Mimo szybkiego rozwoju intranetu i wprowadzanie jego technologii do obsługi działalności gospodarczej, główny kierunek rozwoju aplikacji biznesowych to rozproszone środowisko przetwarzania klient/serwer. W miarę dojrzewania narzędzi i aplikacji wybór "krytycznych" aplikacji dla przedsiębiorstwa jest większy i coraz więcej firm jest w stanie rozwijać je na poziomie całego przedsiębiorstwa, a nie tylko na poziomie poszczególnych wydziałów czy departamentów.

Sposobów tworzenia złożonych aplikacji klient/serwer jest tyle, ile organizacji, które je implementują. Firmy stosują partycjonowanie aplikacji, wielowarstwową architekturę software'ową lub zaawansowane pakiety komunikacji między aplikacjami (middleware) do tworzenia systemów do obsługi swej działalności. Jeżeli chcemy mieć przewagę nad konkurencją dzięki szybkiej możliwości zmiany reguł działania, trzeba stosować centralne serwery reguł działania (business rule servers), pozwalające prowadzić spójną politykę gospodarczą na poziomie przedsiębiorstwa.

Narzędzia taktyczne w czołówce

Sukces taktycznych narzędzi do tworzenia aplikacji klient/serwer, takich jak PowerBuilder (Powersoft) czy SQLWindows (Gupta, obecnie Centura) wynika z faktu, że doskonale sprawdzają się przy opracowaniu aplikacji na poziomie wydziału lub departamentu. Ponieważ jednocześnie firmy dążą do uproszczenia i spłaszczenia struktury zarządzania, nastąpiła synergia narzędzi i kierunków rozwoju biznesu.

Podstawowym narzędziem do informatycznej obsługi klienta, wprowadzania danych, ich poszukiwania w bazie lub wspomagania zarządzania są aplikacje działające na stacjach klienta z Windows, opracowane za pomocą wspomnianych narzędzi taktycznych. Pozwoliły one na szybkie opracowanie aplikacji i obniżenie kosztów obsługi klienta.

Kiedy aplikacje klient/serwer stały się zjawiskiem powszechnym, pojawiły się nowe technologie, pozwalające na budowę aplikacji krytycznych dla całego przedsiębiorstwa. Przykładami takich technologii są rozwinięte systemy zarządzania bazami danych, postęp techniczny w zakresie sprzętu i oprogramowania dla przetwarzania rozproszonego oraz narzędzia do zarządzania systemami i aplikacjami na poziomie przedsiębiorstwa. Programiści nabrali także doświadczenia i są w stanie podjąć się wykonania zadania.

Pierwsze relacje z udanych wdrożeń aplikacji klient/serwer zachęciły wielu szefów przedsiębiorstw do zdefiniowania strategii przechodzenia na tę nową metodę tworzenia aplikacji. W przypadku firm, posiadających nadal mainframe'a, planowano także znaczną obniżkę kosztów eksploatacji po przejściu na systemy unixowe.

Niestety, nadal wiele narzędzi do tworzenia aplikacji klient/serwer nie nadaje się do opracowania aplikacji o znaczeniu krytycznym dla działania całego przedsiębiorstwa.

W stronę lepszych narzędzi

Większość obecnych narzędzi klient/serwer umożliwia opracowanie aplikacji, w której całe przetwarzanie danych uzyskanych z bazy odbywa się na stacji klienta (tzw. syndrom grubego klienta). Ograniczenia tych narzędzi ujawniają się w chwili, gdy zamierzamy użyć ich do opracowania większych, bardziej złożonych systemów.

Głównym problemem systemów dla przedsiębiorstwa jest bezpieczeństwo danych oraz możliwość utrzymania aplikacji przez kilka lub kilkanaście lat. Z punktu widzenia bezpieczeństwa i łatwości utrzymywania aplikacji nie jest wskazane ładowanie reguł działalności (logiki działania) biznesu na biurko każdego użytkownika. Pierwsi użytkownicy aplikacji utworzonych taką metodą utrzymują, że uaktualnianie aplikacji na każdym biurku zajmuje zbyt dużo czasu a jej utrzymanie jest trudne.

Dla współczesnych przedsiębiorstw charakterystyczna jest złożona logika działania biznesu, ale większość narzędzi źle sobie radzi z jej implementacją. Wiele narzędzi niższej klasy ułatwia opracowanie jedynie interfejsu użytkowego, dostęp do baz danych i nawigowanie w niej. Jeżeli narzędzie pozwala na zapisanie logiki działania o średnim stopniu komplikacji, to interpretowany kod nie nadaje się do obsługi wielu klientów, gdyż wydajność aplikacji jest mała.

Ten model przetwarzania wymaga także, aby system zarządzania bazami danych rezydował na serwerze Unixa, Windows NT lub NetWare. Nie da się więc do niego włączyć danych zgromadzonych w innych systemach (np. bazach plikowych lub hierarchicznych).

Większość narzędzi klient/serwer tworzy aplikacje, w których logika jej działania znajduje się w całości na stacji klienta, zaś na serwerze bazy SQL odbywa się jedynie poszukiwanie danych. Powoduje to konieczność przesyłania ogromnych bloków danych między serwerem a klientami, znaczne obciążenie sieci i spowolnienie całej aplikacji.

Dedykowany serwer

Najprostsza metoda zwiększenia wydajności aplikacji klient/serwer polega na przeniesieniu części logiki działania biznesu na dedykowany serwer reguł biznesowych, często utożsamiany z serwerem aplikacji. Ma to jeszcze dodatkowe zalety - jedno miejsce do utrzymywania biznesowej części aplikacji, łatwość modyfikowania kodu tylko na serwerze, bez potrzeby rozprzestrzeniania go na wszystkie stacje klienta oraz możliwość stosowania wydajnego systemu komputerowego typu SMP lub MPP jako serwera reguł działania.

Scentralizowanie przetwarzania w jednym miejscu powoduje zmniejszenie ruchu w sieci: dane przesyłane są teraz w sieci od serwera bazy danych jedynie do serwera aplikacji, nie do wszystkich klientów w sieci.

To rozwiązanie nie jest zalecane w przypadku aplikacji nie wymagających dostępu do zbiorów reguł działania obejmujących całe przedsiębiorstwo, niezależnie od ich lokalizacji. Podobnie, jeśli pewne reguły są wykorzystywane nonstop, np. sprawdzanie poprawności danych wprowadzanych z klawiatury, to korzystniej będzie umieścić je na stacji klienta niż przesyłać dane wejściowe do sprawdzenia w serwerze aplikacji. Jeżeli jednak można wydzielić zestaw reguł obowiązujących w całej firmie oraz określić potrzeby w zakresie rozszerzonego przetwarzania danych, realizowane w wielu stacjach klienta - najkorzystniejszą ich lokalizacją jest serwer aplikacji.

Trygery i zapamiętane procedury

Producenci systemów zarządzania bazami danych oferują sposób przeniesienia części logiki aplikacji na serwer baz danych. Zapewniają go tzw. trygery i zapamiętane procedury. Pozwalają one ponadto na ścisłe powiązanie reguł działania z danymi zapisywanymi lub zapamiętanymi w bazie.

Tryger jest to kawałek kodu, specyficzny dla danego systemu zarządzania bazami danych, automatycznie utrzymujący spójność bazy danych przez sprawdzanie zależności między różnymi encjami w bazie i wykonywanie określonych działań w chwili wprowadzania nowych danych, modyfikowania lub usuwania dawnych. Trygery wykonują swe działania jedynie w wyniku wystąpienia dowolnej akcji w bazie i nie nadają się do wykonywania bardziej złożonych operacji typu przetwarzania.

Zapamiętane procedury są to części kodu rezydujące w serwerze bazy danych i wykonywane na żądanie kodu aplikacji. Zapamiętana procedura może być dowolnie skomplikowana, gdyż wszyscy wielcy producenci baz danych umożliwiają tworzenie ich za pomocą języków 3GL z wbudowanymi elementami kodu SQL lub za pomocą firmowych proceduralnych rozszerzeń języka programowania serwera bazy danych SQL (np. PL-SQL Oracle'a, Transact-SQL Sybase i Microsoftu). Na ogół zapamiętane procedury są przechowywane w bazie w formie skompilowanej dla przyśpieszenia ich wykonywania.

Wzmocniona promocja zapamiętanych procedur i trygerów przez producentów baz danych doprowadziła do tego, że są one akceptowane jako metoda realizacji wielu złożonych operacji z dziedziny reguł biznesu. Argumentuje się przy tym, że jedna centralna lokalizacja danych i reguł działania ułatwia ich administrowanie i utrzymywanie.

Lecz w dobrze pojętym interesie własnym i firmy programiści powinni unikać umieszczania wszystkich reguł działania w bazach danych. Żaden z producentów baz danych nie oferuje solidnych narzędzi do uruchamiania i konserwacji trygerów i zapamiętanych procedur; nawet jeśli są dostępne - nie mogą się równać ze specjalistycznymi środowiskami do tworzenia aplikacji. Tymczasem reguły działania stanowią podstawę działania firmy i powinno się je móc uruchamiać i konserwować równie łatwo, jak inne aplikacje. Ponadto proceduralne rozszerzenia SQL mają na celu przede wszystkim zwiększenie efektywności wykonywania kodu SQL przez serwer bazy danych, nie zaś tworzenie kodu ogólnego przeznaczenia, nie dają więc maksymalnej wydajności. Serwer bazy danych nie jest także najlepszym miejscem do stałego wykonywania reguł działania, gdyż obniża to jego wydajność transakcyjną lub wykonywanie zapytań.

Umieszczanie reguł działania w serwerze bazy danych ma jeszcze jedną wadę -zarówno trygery, jak zapamiętane procedury nie są przenośne między różnymi serwerami baz danych. Konieczność przeniesienia aplikacji na inny serwer oznacza napisanie ich od początku.

Trójwarstwowa architektura aplikacji

W miarę jak aplikacje przechodziły z poziomu departamentu na poziom całego przedsiębiorstwa, okazywało się że prosty podział aplikacji na część kliencką i serwerową (aplikacja dwuwarstwowa) nie daje dobrych wyników w zakresie wydajności aplikacji. Aplikacje trójwarstwowe (serwery: bazy danych i aplikacji, część kliencka) są znacznie lepsze od aplikacji dwuwarstwowych. Oddzielenie części interfejsu graficznego od logiki aplikacji ułatwia zmianę i utrzymywanie kodu i daje aplikacje wyższej jakości.

Jednak w architekturze trójwarstwowej pojawia się komplikacja związana z komunikacją między poszczególnymi warstwami. Do porozumienia się między nimi konieczne jest użycie dowolnego standardowego pakietu komunikacyjnego realizującego np. zdalne wywołanie procedur (Remote Procedure Call - RPC), obsługę kolejek (Message Queueing - MQ) lub komunikację obiektową (Object Request Broker - ORB).

Nowe narzędzia

Większość narzędzi pierwszej generacji do tworzenia aplikacji klient/serwer nie pozwala na swobodny podział aplikacji na część kliencką i serwerową (nawet jeśli to ma być jedynie serwer bazy danych). Nowsze narzędzia umożliwiają taki podział, ale najczęściej dopuszczają możliwość użycia kodu jedynie na konkretnym serwerze bazy danych.

Pojawiły się już nowe narzędzia, pozwalające na tworzenie trzech oddzielnych warstw aplikacji - interfejsu użytkowego, części kodu serwera aplikacji i bazy danych.

Konkurencyjne rozwiązania

Konkurencyjne rozwiązania realizacji logiki biznesu oparte są na wykorzystaniu tzw. serwera reguł biznesowych, wykorzystującego zestaw reguł, zaleceń i wymagań specyficznych dla każdego przedsiębiorstwa. Najprostsza reguła biznesowa mówi, że zysk równa się dochodowi pomniejszonemu o koszty. Ale reguły działania są na ogół znacznie bardziej skomplikowane i dotyczą np. ustalonych zasad przyznawania opcji czy rabatów, sposobów prowadzenia rozliczeń zależnie od typu i charakteru działalności klienta lub dostawcy itp. Najczęściej zbiór reguł biznesowych jest duży, skomplikowany, często zmieniany i bardzo trudny do uchwycenia i zapisania.

Jak je wprowadzić do aplikacji? Można je zakodować przy użyciu języka 3GL, ale ma to wiele wad, w szczególności nie daje elastycznej możliwości modyfikowania ich w miarę potrzeb i zmian w działalności firmy.

Dużo bardziej zaawansowane reguły można zrealizować za pomocą tzw. motoru wnioskowania (inference engine), współdziałającego z aplikacją z oddzielnego serwera reguł. Tradycyjnie motory wnioskowania stosują dwie metody wyciągania wniosków - wnioskowanie w przód i wnioskowanie wstecz. Wnioskowanie w przód polega na łączeniu kolejnych reguł i danych w celu ustalenia nowych faktów. Wnioskowanie wstecz ma na celu znalezienie reguł niezbędnych do uzyskania odpowiedzi na pytanie.

Łącząc te metody, motor wnioskowania jest w stanie na bieżąco rozwiązywać skomplikowane problemy, wymagające rozważenia wielu rozwiązań alternatywnych.

Propozycja Platinum Technology

Firma Platinum Technology oferuje zaawansowany system wnioskowania Platinum AionDS przeznaczony do realizacji systemów biznesowych, opartych na zestawie reguł działania. Pakiet AionDS jest systemem obiektowym, w którym reguły działania (procesy biznesowe) i dane są wyrażane jako klasy obiektów.

Reguły do pakietu wprowadza się za pomocą prostego, nieproceduralnego języka Knowledge Definition Language (KDL) w sposób wymagający jedynie minimalnego udziału programisty. W czasie pracy systemu motor wnioskowania wykonuje reguły biznesowe zależnie od danych, zawartych w bazie reguł. Moduł Callable Aion Building System (CABS) służy do szybkiej edycji reguł.

AionDS może być umieszczony na dowolnej platformie unixowej, służącej jako serwer reguł działania, i współpracuje z aplikacją za pośrednictwem pakietu komunikacyjnego RPC, zgodnego ze specyfikacją DCE (Distributed Computing Environment) opracowaną prze Open Software Foundation.

AionDS współpracuje bezpośrednio z bazami DB2, Oracle, Sybase, Informix i Microsoft SQL Server oraz z innymi bazami za pośrednictwem sterowników ODBC.

Aktualna wersja AionDS jest zintegrowana z tzw. serwerem reguł RuleServer, działającym na platformach SMP pod kontrolą systemów Windows NT, Solaris, HP UX, AIX i OS2. Reguły działania są skompilowane w kodzie RuleServera i w połączeniu z wydajną architekturą serwerów SMP zapewniają wysoką skalowalność i łatwą realizację trójwarstwowej architektury klient/serwer dla całego przedsiębiorstwa.