Prace z informatyki

Prace dyplomowe z informatyki

Serwer Jakarta-Tomcat 5.0

5/5 - (1 vote)

Serwer Jakarta-Tomcat [8] jest darmowym serwerem WWW z ogólnodostępnym kodem źródłowym. Umożliwia on tworzenie dynamicznych stron w oparciu o standardy Java (serwlety i strony JSP). Pomimo bardzo prężnego rozwoju serwera wciąż brakuje w nim w pełni funkcjonalnego i działającego klastra. Twórcy Tomcata dostrzegli już jak duży wpływ na decyzję o wyborze kontenera aplikacji ma jego skalowalność i odporność na awarie. W wersji 5.0 wprowadzili standard klastra w kodach źródłowych serwera oraz podłączyli bardzo prosty moduł replikujący stan sesji między węzłami klastra. Przykładowa implementacja modułu nie rozwiązuje jednak wielu problemów, które mogą spowodować wadliwe działanie klastra. Stąd zrodziła się idea stworzenia nowego klastra dla serwera Jakarta-Tomcat.

W kolejnych punktach zostanie opisany serwer Jakarta-Tomcat oraz przedstawiona implementacja pierwszego modułu klastra napisana przez Filipa Hanika (por. p. 3.4).

  • Rozwój serwera Jakarta-Tomcat

Pierwszym pomysłodawcą i twórcą Tomcata był James Duncan Davidson (projektant i programista z firmy Sun). Pod koniec lat dziewięćdziesiątych rozpoczął on prace nad wzorcową implementacją kontenera dla serwletów i stron JSP. Po napisaniu sporej części systemu przekazał kody źródłowe organizacji Apache Software Foundation, aby dalszy rozwój serwera odbywał się pod jej patronatem. Organizacja ochrzciła projekt nazwą Jakarta-Tomcat i w 1999 roku opublikowała wersję 3.0, jako wtyczkę do serwera WWW – Apache. Kolejna wersja (4.0) była już w pełni niezależnym serwerem. Pojawiła się obsługa takich standardów jak JDBC, SSL czy Realms.

Serwer Jakarta-Tomcat stał się bardzo popularnym kontenerem serwletów oraz stron JSP, głównie za sprawą ogólnodostępnego kodu źródłowego oraz jego dobrej wydajności. Prosta implementacja ograniczonego podzbioru standardów J2EE [3] umożliwiła stworzenie bardzo szybkiego i „lekkiego” serwera, który mógł być bardzo dobrą alternatywą dla serwerów ze stronami pisanymi w języku PHP. W wielu projektach nie ma potrzeby wykorzystywania skomplikowanych mechanizmów EJB czy JMS, a do pełnej realizacji zadań wystarczą serwlety z możliwością dostępu do bazy danych. Do tego typu projektów idealnie nadawał się serwer Jakarta-Tomcat. Wiele projektów i firm korzysta z Tomcata jako jednego z komponentów, jak choćby Jonas [7] czy Hyperion Analyzer [5].

  • Główne założenia koncepcyjne

Serwer Jakarta-Tomcat jest przede wszystkim kontenerem serwletów (wersja 2.4) i stron JSP (wersja 2.0). Intencją twórców projektu nie było stworzenie pełnej implementacji standardu J2EE [3], ale szybkiego i stabilnego kontenera serwującego strony dynamiczne napisane w języku Java. Ponieważ cały serwer został napisany w języku Java, więc może działać w zasadzie na dowolnej platformie, posiadającej implementację maszyny wirtualnej.

W kolejnych wersjach doszło sporo różnego rodzaju dodatków, ułatwiających pracę programistom i administratorom systemu.

Autoryzacja

Doszło wsparcie dla obiektów autoryzacji (czyli tzw. recilmś). Administrator może stworzyć własne implementacje mechanizmu uwierzytelniania lub skorzystać z trzech gotowych komponentów (w szczególności dostępny jest mechanizm korzystający z bazy danych). Ponadto obsługę żądań można tunelować w protokole HTTPS.

Drzewa JNDI, JDBC, JavaMail

Tomcat udostępnia proste mechanizmy rejestrowania obiektów w drzewie nazw (JNDI). Programista może pobierać w kodzie obiekty, wyszukując je po nazwie. Najczęściej stosuje się ten mechanizm przy korzystaniu z połączeń do bazy danych (obiekty typu javax. sql. DataSourc )    – administrator może modyfikować

parametry połączenia bez potrzeby zaglądania czy modyfikowania kodu aplikacji.

Analogicznie można korzystać z obiektów umożliwiających wysyłanie listów pocztą elektroniczną [4],

Menedżer bezpieczeństwa

Tomcat w wersji 5.0 posiada wsparcie dla menedżera bezpieczeństwa (ang. security manager). Administrator może definiować poziom izolacji przy wykonywaniu kodu napisanego przez programistów. W ten sposób można obronić się przed wykonaniem niebezpiecznego z punktu widzenia serwera kodu w aplikacjach,

np.

System.exit(0);

co powodowałoby koniec pracy całego systemu.

  • Opis implementacji

Jakarta-Tomcat jest w całości napisany w języku Java.

Źródła systemu są podzielone na trzy grupy:

  1. jakarta-tomcat-catalina – część, w której znajduje się faktyczna implementacja kontenera serwletów,
  2. jakarta-tomcat-connectors – implementacja podstawowych typów połączeń stosowanych w systemie (między klientem a serwerem),
  3. jakarta-tomcat-jasper – implementacja kompilatora do stron JSP.

Z punktu widzenia klastrów najciekawsza jest pierwsza część, ponieważ tu znajduje się implementacja jądra systemu, a także moduł do tworzenia klastra.

Tomcat został zaimplementowany w postaci hierarchicznego drzewa obiektów, w którym każdy węzeł może zostać przedefiniowany przez odpowiednie wpisy w plikach konfiguracyjnych. Takie podejście ułatwia modyfikację systemu, co miało duży wpływ na spopularyzowanie serwera.

  • Hierarchia obiektów

Serwer Jakarta-Tomcat zazwyczaj składa się z następującej hierarchii komponentów:

– Korzeniem drzewa jest maszyna (obiekt implementujący interfejs org. apache. catalina. Engin ). Reprezentuje ona niezależny serwer.

  • Maszyna posiada węzły (obiekty implementujące interfejs apache. catalina.Host), które reprezentująwirtualne węzły.
  • Węzeł posiada konteksty (obiekty implementujące interfejs apache. catalina. Contexi), które reprezentują aplikacje internetowe (ang. w eh applications). Aplikacją może być plik z rozszerzeniem .war lub podkatalog w katalogu webapps.
  • Kontekst składa się z serwletów zadeklarowanych przez programistę w pliku opisującym aplikację (plik web.xml) oraz menedżera sesji.
  • Menedżer sesji (obiekt implementujący interfejs apache. catalina. Manage ) zarządza sesjami użytkowników.

Taka hierarchia nie jest obligatoryjna – dla przykładu w sytuacji, gdy instalujemy Tomcat jako wtyczkę w serwerze Apache, drzewo degraduje się do ostatniego poziomu, czyli samych obiektów aplikacji. Wszystkie pozostałe stają się zbędne, gdyż obsługą żądania na wyższym poziomie zajmuje się macierzysty serwer.

Konfiguracja hierarchii obiektów znajduje się w pliku server.xml. Każdy poziom jest definiowany przez odpowiedni znacznik w języku XML. W szczególności, standardowa dystrybucja Tomcata dostarcza trzy różne rodzaje menedżerów sesji, które w zależności od zapotrzebowania można ustawiać w pliku konfiguracyjnym. Ze względu na rolę jaką odgrywa menedżer sesji w klastrze (przechowuje stan sesji), w p. 3.3.1.1 zostaną zaprezentowane dostępne implementacje tego obiektu.

  • Implementacje menedżera sesji

W standardowej dystrybucji serwera Tomcat dostępne są trzy rodzaje menedżera sesji:

  1. standardowy (ang. StandardManager),
  2. plikowy (ang. PersistentManager),
  3. bazodanowy (ang. JDBCManager).

Pierwszy z nich udostępnia podstawową funkcjonalność menedżera sesji – czyli po prostu przechowuje dane w pamięci operacyjnej jednej maszyny.

Drugi pozwala na periodyczne zapisywanie stanu sesji do pliku i odzyskanie tych danych po restarcie maszyny. Jest również przydatny w sytuacji, gdy nie wszystkie sesje mieszczą się w pamięci operacyjnej maszyny. Wtedy menedżer zapewnia nam dodatkowy mechanizm wymiany.

Trzecie rozwiązanie działa analogicznie do drugiego z tą różnicą, że zapis odbywa się w bazie danych, w odpowiednio zdefiniowanym schemacie.

  • Klaster w serwerze Tomcat

W wersji 5.0 została dodana obsługa klastra. Administrator może zdefiniować klasę implementującą klaster (interfejs org. apache. catalina. ciuster) w znaczniku Cluster, w pliku konfiguracyjnym serwera. Klaster jest definiowany na poziomie węzła, dzięki czemu można łatwo rozdzielić aplikacje, które mają działać w trybie rozproszonym od tych działających na pojedynczym serwerze. Klaster jest odpowiedzialny za obsługę wszystkich aplikacji (kontekstów) zainstalowanych w obrębie węzła. Implementacja musi zapewnić mechanizmy replikacji i synchronizacji w obrębie grupy połączonych maszyn oraz może udostępniać metody instalowania i odinstalowywania aplikacji w całym klastrze (metody installContext (string contextPath, URL war), start(String contextPath) oraz stop(String contextPath) ).

Dodatkowo rozszerzono specyfikację pliku opisującego aplikację (web.xml [3]) o znacznik :distributable/>, określający czy aplikacja ma być obsługiwana przez klaster. Jeżeli znacznik zostanie wstawiony, to system podłączy do kontekstu menedżer sesji utworzony przez implementację klastra. W przeciwnym przypadku do kontekstu zostanie podłączony standardowy menedżer.

Każdy obiekt tworzony w drzewie hierarchii Tomcata będzie miał skopiowane wartości parametrów z pliku konfiguracyjnego, poprzez wywołanie metod setxxx (string value) (gdzie XXXjest nazwą parametru oraz jednocześnie nazwą atrybutu w pliku XML). Dodatkowo w specjalny sposób traktowane są obiekty implementujące interfejs klasy org.apache . catalina . Lifecycle.

  • Obiekty klasy Lifecycle

Jeżeli tworzone na poziomie serwera obiekty implementują interfejs org.apache. catalina. Lifecycl , to w momencie startu systemu wywoływana jest dla nich metoda starto. Obiekty tego interfejsu zostaną powiadomione o zamknięciu systemu poprzez wywołanie dla nich metody stop(). Dla przykładu obiekt implementujący interfejs ciuster w module klastrowania jednocześnie implementuje interfejs Lifecycl , aby w metodach start i stój wykonać czynności przygotowujące do pracy oraz czynności kończące pracę klastra.

Każde żądanie obsługiwane przez serwer Tomcat przechodzi przez odpowiedni strumień wywołań procedur. Jest to najbardziej newralgiczne miejsce systemu, ze względu na częstość wywoływania jego kodu.

  • Strumień przetwarzania żądań

Strumień przetwarzania żądań w serwerze Tomcat składa się z następujących wywołań:

  1. Strumień jest inicjowany przez konektor, dostarczający żądanie klienta.
  2. Lokalizowany jest odpowiedni węzeł, a w nim kontekst, do którego odwołuje się żądanie.
  3. Wykonywany jest ciąg wyzwalaczy (tzw. valve), które obudowują wywołanie serwletu (szerzej o wyzwalaczach będzie mowa w p. 3.3.3).
  4. Uruchamiany jest serwlet
  5. Wyzwalacze kończą działanie.
  6. Konektor przekazuje odpowiedź do klienta.
  • Wyzwalacze

Serwer Tomcat umożliwia podpięcie wyzwalaczy obudowujących wykonanie żądania przez serwlet. Zasada działania jest podobna do serwletów filtrujących [3], z tym że wyzwalacze definiuje się na poziomie węzła. Wyzwalacz musi być obiektem klasy implementującej interfejs org. apache . catalina .Valve.

W metodzie invoke (Reąuest, Response, Context) programista może zdefiniować akcje, które będą wykonywane podczas obsługi każdego żądania. Programista decyduje czy żądanie ma być przetwarzane dalej, czy ma zostać przerwane, wywołując lub nie metody invokeNext (Reąuest, Response).

Przykładowo implementacja kontenera autoryzującego opiera się na wyzwalaczach. Przed wywołaniem odpowiedniej strony obsługi żądania sprawdzane jest czy klient posiada wystarczające uprawnienia.

Wyzwalacze umożliwiają tworzenie dzienników serwera lub stosowanie globalnych dla całego serwera filtrów przychodzących żądań.

W szczególności mechanizm ten jest również wykorzystywany przy implementacji klastra (patrz p. 3.4).

3.4 Implementacja klastra w serwerze Tomcat 5.0

W wersji 5.0 klaster dla serwera Tomcat został ustandaryzowany. Dołączono odpowiedni mechanizm podłączania i konfiguracji odrębnych implementacji mechanizmu rozpraszania obliczeń. Osobą odpowiedzialną za rozwój standardu, jak również dołączenie pierwszego w pełni działającego modułu klastra w oficjalnej dystrybucji serwera, jest Filip Hanik – członek zespołu programistów Tomcata.

Wybór Filipa Hanika jako osoby odpowiedzialnej za klaster nie był przypadkowy. Już wcześniej zaimplementował on działającą wtyczkę do Tomcata wersji 4.0 umożliwiającą stworzenie klastra.

  • Klaster dla wersji 4.0

Hanik zaimplementował w pełni funkcjonalny moduł dla Tomcata w wersji 4.0, który po podpięciu do serwera umożliwiał stworzenie klastra. Jego pomysł polegał na podmianie klasy menedżera sesji, w której dodał mechanizm replikowania zmian zachodzących w sesjach użytkowników. Jako warstwy transportującej użył biblioteki JavaGroups [6] dostarczającej mechanizmów ułatwiających programowanie w środowisku rozproszonym. Konfiguracja JavaGroups dopuszcza komunikację w trybie rozgłoszeni owym (ang. multicast), minimalizującą liczbę przesyłanych pakietów (niestety implementacja nie posiada mechanizmów zapewniających niezawodność transmisji, jaka jest w protokole TPC/IP).

Rozwiązanie Filipa Hanika było tylko zewnętrzną nadbudówką do serwera, który sam w sobie nie posiadał jeszcze wtedy żadnego wbudowanego wsparcia dla klastrów. Wymuszało to tworzenie odrębnych klastrów dla każdej aplikacji, co oczywiście powodowało zbędny narzut.

W wersji 5.0 moduł Filipa Hanika został przepisany i dołączony do oficjalnej dystrybucji.

  • Architektura klastra w wersji 5.0

Klaster jest całkowicie zdecentralizowany, każdy kolejny węzeł dołącza się rozsyłając odpowiedni komunikat w trybie rozgłoszeni owym, w lokalnej sieci. Sesje replikowane są do wszystkich węzłów – w szczególności zakłada się, że węzły posiadają identyczny stan każdej sesji. Klaster nie zakłada istnienia zintegrowanego mechanizmu równoważącego obciążenie – każde kolejne żądanie może trafić do dowolnego serwera w klastrze i będzie obsłużone tak, jakby cała interakcja odbywała się na jednej fizycznej maszynie. Takie podejście pozwala na zastosowanie dynamicznego równoważenia obciążenia, z czym wiąże się minimalizacja wariancji czasu obsługi żądania.

Klaster jest zaimplementowany jako moduł (plik z rozszerzeniem .jar), który można opcjonalnie dołączyć do serwera Tomcat.

  • Implementacja klastra w wersji 5.0

Kody źródłowe modułu można podzielić na trzy części:

  1. warstwa transportuj ąca (por. p. 3.4.3.1),
  2. warstwa związana z serwerem Tomcat: menedżer sesji, obiekt sesji (por. p. 3.4.32),
  3. klasy pomocnicze (por. p. 3.4.3.3).
  • Warstwa transportująca

Hanik zrezygnował z korzystania z biblioteki JavaGroups – jak sam twierdzi z powodu braku gwarancji poprawności przesyłanych informacji [11], Zaimplementował warstwę opartą na protokole TCP/IP, służącą do wymiany danych między węzłami klastra. Każdy węzeł trzyma otwarte połączenia do wszystkich pozostałych węzłów. Lista pozostałych węzłów uaktualniana jest na podstawie periodycznie wysyłanych komunikatów o istnieniu węzła (w trybie rozgłoszeniowym). Jeżeli któryś węzeł przestanie wysyłać komunikat, to pozostałe komputery uznają, że nastąpiła w nim awaria i wyrzucą go z listy członków klastra. Niestety pojawia się tu problem rozspójnienia klastra – może zdarzyć się, że część węzłów uzna, że dany komputer przestał działać (np. z powodu nadmiernego obciążenia sieci, bądź procesora), a część pozostawi go na liście aktywnych węzłów. Wtedy podczas replikacji uaktualniona wersja sesji nie dotrze do wszystkich komputerów. Przy założeniu, że cały klaster posiada spójną wersję sesji, może okazać się to dużym zagrożeniem utraty danych. Wystarczy, że kolejne żądanie zostanie przekierowane do węzła nie posiadającego najnowszej wersji sesji.

Każdy węzeł przy starcie otwiera jeden port, na którym będzie oczekiwał na połączenia od pozostałych węzłów. Połączenie nawiązywane jest tylko raz, a przy wysyłaniu danych korzysta się z wcześniej otwartego połączenia. Niestety między każdymi dwoma węzłami otwierane są dwa osobne połączenia, co negatywnie wpływa na wydajność sieci.

Każdy węzeł otwiera jeden port w trybie rozgłoszeniowym, w celu periodycznego wysyłania komunikatu o swoim istnieniu. W komunikacie znajduje się informacja o węźle oraz o porcie, na którym nasłuchuje. Jeżeli odbiorca komunikatu nie posiada otwartego połączenia do ogłaszającego się węzła, to inicjowane jest nowe połączenie.

Wadą wysyłania komunikatów w trybie rozgłoszeniowym jest uniemożliwienie pracy dwóch serwerów Tomcat na jednej fizycznej maszynie, tak aby oba należały do tego samego klastra. Tylko jeden z serwerów będzie w stanie otworzyć konkretny port rozgłoszeniowy.

Wszelkie informacje wymieniane między węzłami klastra przesyłane są za pomocą wiadomości. Komunikacja jest całkowicie bezstanowa – to znaczy po wysłaniu komunikatu nadawca nie oczekuje na odpowiedź, minimalizując ryzyko potencjalnych zakleszczeń (ang. deadlock). Format rozsyłanych wiadomości jest następujący:

  • 7 bajtów – preambuła,
  • 1 bajt – długość wiadomości,
  • dane wiadomości,
  • 7 bajtów-zakończenie wiadomości.

Na dane składa się zserializowana postać klasy 3essionMessage. Klasa zawiera typ wiadomości, identyfikator sesji, dane sesji, identyfikator kontekstu oraz adres węzła wysyłającego wiadomość.

Występują następujące typy wiadomości:

  1. evt_session_created – została utworzona nowa sesja lub istniejąca sesja została zmieniona;
  2. evt_session_expired_wonotify – wygasła sesja, ale nie należy powiadamiać o tym słuchaczy (ang. listner)\
  3. evt_session_expired_wnotify – wygasła sesja i należy powiadomić słuchaczy;
  4. evt_session_accessed – użytkownik odwołał się do sesji, ale jej nie zmieniał;
  5. evt_get_all_s e s s i on s – nowy węzeł pobiera wszystkie do tej pory stworzone sesje;
  6. EVT_ALL_SESsioN_DATi – przesyłane są dane sesji.

W aktualnej wersji rozwiązania zdarzenia evt_session_expired_wonotify oraz evt_session_expired_wnotify są obsługiwane jednakowo, z powiadamianiem słuchaczy.

Zapisywanie i odtwarzanie danych sesji

Dane sesji są serializowane za pomocą wywołania standardowej metody

writeObjectData(ObjectOutputStream stream) z klasy StandardSession, a deserializowane za pomocą metody readObjectData (Objectlnputstream stream). Przy odtwarzaniu danych sesji z tablicy bajtów, tworzony jest strumień wejściowy Replicationstrea , który czyta obiekty korzystając z mechanizmu ładowania klas dostarczanego przez kontekst aplikacji, do której należy sesja. W ten sposób przesyła się obiekty klas stworzonych w ramach danej aplikacji.

  • Warstwa związana z serwerem Tomcat

Moduł Hanika podłączany jest za pomocą klasy simpleTcpCluste , którą definiuje się w znaczniku <ciuster: , w pliku konfiguracyjnym serwera. Klasa implementuje standardowy interfejs org. apache. catalina. ciuste:, dostarczając niezbędnych metod do pracy systemu. W aktualnej wersji implementacja nie wspiera metod instalacji oraz deinstalacji aplikacji w całym klastrze.

Klasa SimpleTcpCluster implementuje interfejs org.apache.catalina. Lifecycle, wykorzystując metody starto oraz stop() do inicjowania swoich struktur danych.

Przy starcie systemu w metodzie start () obiekt tworzy warstwę transportującą, przekazując do niej parametry pobrane z pliku konfiguracyjnego server.xml (dokładniej o parametrach klastra będzie mowa w p. 3.4.4).

W metodzie createManager(string name;, odpowiadającej za tworzenie menedżera sesji, przekazywany jest obiekt instancji klasy SimpleTcpReplicationManagei, będącej nadklasą klasy StandardManager. Klasa przeimplementowuje metodę createSession ( , w której tworzy i przekazuje obiekt typu ReplicatedSession zamiast standardSession. Obiekty replikowanych sesji przechwytują wywołania metod

  • setAttribute(String name, Object value),
  • removeAttribute(String name),
  • expire(boolean notify)

z poziomu aplikacji w celu ustawienia bitu informującego o przeprowadzonych zmianach w sesji. Po zakończeniu przetwarzania żądania system podejmuje decyzję o replikacji na podstawie wartości tego bitu.

Inicjowanie procesu replikacji zachodzi w odpowiednim wyzwalaczu (obiekt klasy ReplicationValve), podpiętym pod wywołania żądań. Po wykonaniu żądania przez aplikację obsługującą dany kontekst, wyzwalacz wywołuje metodę

reąuestcompieted(string sessionid) w obiekcie zarządcy sesji. Metoda przekazuje wiadomość, zawierającą zserializowane dane sesji, która zostaje rozesłana do wszystkich węzłów w klastrze.

Rozsyłanie wiadomości do węzłów może być wykonywane w dwóch trybach: synchronicznym oraz asynchronicznym. Przy pierwszym trybie wątek obsługujący żądanie jest równocześnie odpowiedzialny za rozesłanie pakietów w obrębie klastra. Powoduje to oczywiście wydłużenie czasu obsługi żądania, co może negatywnie wpływać na wydajność systemu.

W trybie asynchronicznym tworzone jest zadanie replikacji sesji, które zostanie wykonane przez jeden ze specjalnych wątków – zazwyczaj już po zakończeniu obsługi żądania. Przy takim podejściu klient nie musi niepotrzebnie czekać na zakończenie zadania replikacji sesji; proces ten wykonywany jest w tle, w czasie przesyłania odpowiedzi do klienta. Niestety implementacja tego mechanizmu ma dużą wadę – nie jest w żaden sposób sprawdzane czy węzeł zdążył rozesłać nową wersję sesji przy kolejnym odwołaniu. Czyli może zdarzyć się następująca sytuacja:

  1. Klient wysyła żądanie do klastra i zostaje przekierowany do maszyny A.
  2. Podczas obsługi żądania sesja zostaje zmodyfikowana (na maszynie A).
  3. Klient otrzymuje odpowiedź i natychmiastowo wysyła kolejne żądanie.
  4. Serwer równoważący obciążenie przekierowuje żądanie do maszyny B.
  5. Kod obsługujący żądanie odwołuje się do sesji, której maszyna A nie zdążyła jeszcze wysłać do maszyny B.

Taka sytuacja może z łatwością zajść przy nadmiernym obciążeniu danego węzła. Z powodu braku mocy obliczeniowej (lub przeciążenia sieci) wysyłanie wiadomości ze zmienionym stanem sesji zaczyna się opóźniać, co może doprowadzić do rozspójnienia klastra i w konsekwencji utraty danych. W praktycznych zastosowaniach tryb asynchroniczny jest rozwiązaniem niedopuszczalnym, właśnie z powodu ryzyka utraty danych.

Kolejnym poważnym problemem implementacji jest brak synchronizacji dostępu do sesji w obrębie klastra. Klaster nie posiada żadnego mechanizmu kontrolującego równoczesny dostęp do tej samej sesji. Jeżeli klient wyśle równolegle dwa żądania, modyfikujące te same zasoby, to doprowadzi to do utraty danych. Co gorsze, może okazać się, że część węzłów będzie posiadała sesję zmienioną przez jedno żądanie, a część przez drugie – jeżeli wiadomości z replikami będą docierały w różnej kolejności.

Taka sytuacja może mieć miejsce w przypadku stron HTML posiadających ramki. Po odświeżeniu strony przeglądarka wysyła równolegle wiele żądań do tych samych zasobów, automatycznie generując równoległe odwołania do tej samej sesji.

  • Klasy pomocnicze

Buforowanie

Został zaimplementowany prosty mechanizm buforowania przesyłanych w sieci informacji. W przypadku pracy w trybie asynchronicznym po przetworzeniu żądania kolejkowane jest zadanie replikacji sesji. Jeżeli zadanie dotyczące tej samej sesji znajdowało się już w kolejce, to zostanie ono nadpisane przez nowszą wersję. W ten sposób eliminuje się niepotrzebny ruch w sieci. Niemniej jednak taka sytuacja ma miejsce tylko przy dużym obciążeniu sieci, kiedy węzeł nie jest w stanie wystarczająco szybko wysłać wiadomości do pozostałych węzłów. Niestety zysk z wykorzystania tego mechanizmu jest iluzoryczny, ponieważ jest mało prawdopodobne, że kolejne żądanie trafi do tego samego węzła. Skoro zakłada się, że mogą występować tak duże opóźnienia w rozsyłaniu replik zmienionej sesji, to klaster bardzo szybko stanie się niespójny i zacznie tracić dane.

Pula wątków

W celu minimalizowania narzutu związanego z tworzeniem wątków została zaimplementowana pula wątków, obsługująca przychodzące wiadomości. Jeżeli wątek nasłuchujący na otwartych połączeniach z pozostałymi węzłami odbierze dane, to budzi jeden z wątków z puli i przydziela mu gniazdo (ang. socket), z którego należy wczytać dane. Wątek wczytuje kolejne wiadomości przetwarzając je synchronicznie. Po zakończeniu zwraca gniazdo i przechodzi w stan oczekiwania.

  • Konfiguracja klastra w wersji 5.0

Klaster włącza się poprzez odkomentowanie sekcji klastra w pliku server.xml:

<Cluster

className=”org.apache.catalina.cluster.tcp.SimpleTcpCluster”

name=”FilipsCluster”

debug=”10″

serviceclass=”org.apache.catalina.cluster.mcast.McastService”

mcastAddr=”228.0.0.4″

mcastPort=”45564″

mcastFrequency=”500″

mcastDropTime=”3000″

tcpThreadCount=”2″

tcpListenAddress=”auto”

tcpListenPort=”4001″

tcpSelectorTimeout=”100″

printToScreen=”false”

expireSessionsOnShutdown=”false”

useDirtyFlag=”true”

replicationMode=”synchronous”

/>

oraz sekcji wyzwalacza wykorzystywanego przez klaster:

<Valve

className=”org.apache.catalina.cluster.tcp.ReplicationValve”

filter=”.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;”

/>

Znaczenie odpowiednich atrybutów w sekcji klastra:

  1. name – nazwa klastra (wartość w zasadzie nie wykorzystywana),
  2. debug – poziom szczegółowości generowanych przez implementację zapisów systemowych,
  3. serviceclass – klasa służąca do dostarczania informacji o dostępnych węzłach w klastrze (musi implementować interfejs

org.apache.catalina.cluster.MembershipService),

  1. mcastAddr – adres rozgłoszeniowy, na którym węzły będą powiadamiały się nawzajem o swoim istnieniu,
  2. mcastPort – port używany przy rozgłaszaniu,
  3. mcastFreąuency – częstotliwość rozsyłania informacji o istnieniu węzła (w milisekundach),
  4. mcastDropTime – czas po jakim węzeł zostaje uznany za niesprawny od momentu otrzymania ostatniego pakietu o jego istnieniu,
  5. tcpThreadCount – liczba wątków obsługujących przychodzące wiadomości w klastrze,
  6. tcpListenAddress – adres, na którym węzeł spodziewa się połączeń od pozostałych węzłów (jeżeli ustawiona jest wartość „auto”, to zostanie użyty domyślny adres komputera). Wykorzystuje się go, jeżeli komputer posiada więcej niż jedną kartę sieciową,
  7. tcpListenPort – port, na którym nasłuchuje węzeł,
  8. tcpSelectorTimeout – czas w milisekundach po jakim wątek nasłuchujący na otwartych połączeniach ma sprawdzić czy serwer nie jest zamykany,
  9. printToScreen – czy strumień diagnostyczny ma być przekierowany do standardowego wyj ścia,
  10. expireSessionsOnShutdown – czy podczas zamykania serwera sesje mają zostać zdezaktualizowane,
  11. useDirtyFlag – czy sesja ma być replikowana tylko po wywołaniu metod

setAttribute(..), removeAttribute(..), expire(), invalidate(), setPrincipal(..), setMaxInactiveInterval(..),

  1. replicationMode — przyjmuje wartość synchronous lub asynchronous i

oznacza tryb w jakim sesje będą replikowane.

Wyzwalacz przyjmuje atrybuty:

  1. filter – zawiera wyrażenia regularne oddzielone znakiem średnika, definiujące adresy, podczas przetwarzania których na pewno sesja nie będzie zmieniana. Przy obsłudze tych żądań mechanizm replikacji nie będzie wywoływany, nawet gdy flaga iseDirty będzie ustawiona na fałsz.
  • Zalety rozwiązania

Zaletą przedstawionego rozwiązania jest jego całkowite zdecentralizowanie. Klaster nie posiada wyróżnionego węzła, co zwiększa stabilność i odporność na

awarie konkretnej maszyny. Dołączanie kolejnego węzła wiąże się jedynie z włączeniem go do sieci.

Kolejną cechą wyróżniającą klaster w serwerze Tomcat jest całkowita niezależność od algorytmu równoważenia obciążenia. Rozwiązanie nie wymaga specjalnego oprogramowania interpretującego identyfikatory sesji czy zapamiętującego przypisania węzeł-sesja. Administrator może wykorzystać dowolny mechanizm przekierowywania (programowy czy sprzętowy).

Pełna replikacja (tzn. każdy węzeł replikuje swoje sesje do wszystkich pozostałych węzłów) zapewnia dużą odporność klastra na awarie. Wystarczy, że chociaż jeden z serwerów pozostanie sprawny, aby nie utracić żadnych informacji. Poza tym umożliwia zastosowanie wyrafinowanych algorytmów równoważenia obciążenia, które nie będą ograniczane stałymi przypisaniami sesji do węzłów. W szczególności po dodaniu kolejnego węzła do klastra bardzo szybko możemy przerzucić na niego obciążenie z pozostałych komputerów, a nie tylko przekierowywać nowo przybyłych użytkowników.

Niestety rozwiązanie oprócz zalet ma również wady. Niektóre z nich są na tyle poważne, że uniemożliwiają wykorzystanie serwera w komercyjnych zastosowaniach. Rozwiązanie nie gwarantuje poprawnego działania systemu.

  • Wady rozwiązania

Główną wadą rozwiązania jest brak synchronizacji przy dostępie do sesji oraz brak kontroli nad spójnością klastra. Założenie o pełnej replikacji pociąga za sobą konieczność zapewnienia mechanizmu synchronizacji przy wprowadzaniu zmian czy chociażby odczycie sesji. Jeżeli każdy komputer może uchodzić za serwer macierzysty dowolnej sesji (czyli może obsługiwać wszelkie żądania, jakie docierają do klastra), to należy uniemożliwić wprowadzanie równoczesnych zmian na różnych maszynach. Niestety rozwiązanie Filipa Hanika ignoruje zagrożenie równoległych zmian, tak samo jak ignoruje możliwość opóźnień w replikacji sesji. Jeżeli komputer z powodu nadmiernego obciążenia opóźni rozesłanie nowej wersji sesji, to przy kolejnym żądaniu klienta, przekierowanym do innego węzła, aplikacja będzie korzystała z nieaktualnej wersji danych, nadpisując tym samym poprzednie zmiany. Co gorsze w takiej sytuacji nie ma pewności, która wersja sesji trafi do pozostałych węzłów, ponieważ będzie to zależało tylko od kolejności w jakiej odbiorą one repliki z dwóch różnych źródeł.

Nie mniej ważne jest niebezpieczeństwo rozspójnienia klastra. Zakłada się, że wszystkie węzły w klastrze posiadają identyczną wersję dowolnej sesji, ale co się stanie jeżeli węzeł chwilowo uzna inny komputer za niesprawny i nie prześle mu repliki zmienionej sesji? Taka sytuacja może zaistnieć przy dużym obciążeniu sieci lub maszyny – wystarczy, że na czas nie dotrze do któregoś węzła pakiet rozgłoszeniowy informujący o istnieniu innego węzła. Ten odrzuci go, sądząc, że węzeł przestał działać i nie będzie wysyłał do niego wiadomości. Za chwile pakiet o istnieniu znowu dotrze i węzeł ponownie zostanie włączony do listy aktywnych członków, ale sesja nie zostanie już zaktualizowana.

Korzystanie z trybu rozgłoszeniowego w sieci uniemożliwia zainstalowanie dwóch węzłów klastra na jednej fizycznej maszynie – tylko jeden serwer otworzy port rozgłoszeniowy i będzie mógł z niego korzystać. To może okazać się sporą niedogodnością w niektórych topologiach klastrów. Czasami administrator może chcieć zainstalować więcej niż jeden serwer na fizycznej maszynie zapewniając większą odporność klastra na awarie oprogramowania. Niestety przedstawione rozwiązanie wyklucza taki model.

Architektura rozwiązania powoduje generowanie dużego ruchu w sieci – każdy węzeł rozsyła repliki sesji do wszystkich pozostałych. Przy dużym obciążeniu sieć może okazać się wąskim gardłem całego klastra. Powoduje to spore ograniczenia na liczbę węzłów jednocześnie działających w klastrze. Liczba przesyłanych komunikatów jest kwadratowo zależna od liczby podłączonych węzłów.

Reasumując można stwierdzić, że Hanik przygotował bardzo stabilne podstawy do implementacji modułu klastra dla serwera Jakarta-Tomcat. Wyłonił się standard jaki muszą spełniać moduły, aby mogły poprawnie działać przy każdej kolejnej dystrybucji Tomcata oraz został naszkicowany schemat podłączenia modułu do serwera. Wzorcowa implementacja dostarcza wiele wskazówek, które mogą ułatwić pracę twórcom kolejnych rozwiązań. Niestety nie spełnia ona wymagań stawianych przez komercyjne zastosowania i może służyć jedynie jako przykład.

Celem tej pracy jest stworzenie modułu, bazującego na koncepcji Hanika, wykorzystującego zalety rozwiązania, ale przede wszystkim eliminującego jego wady i zagrożenia. Główną zaletą, która została zidentyfikowana w bazowym rozwiązaniu, jest możliwość dynamicznego sterowania obciążeniem poszczególnych jednostek klastra. Główną wadą jest brak synchronizacji podczas odwoływania się do sesji oraz brak kontroli nad spójnością klastra. Drugim bardzo ważnym celem jest optymalizacja rozwiązania, aby jego wydajność nie stała się powodem rezygnacji ze stosowania klastra w serwerze Jakarta-Tomcat. W rozdziale 4 przedstawię nową, autorską implementację klastra, a w rozdziale 5 opiszę wyniki testów wydajnościowych zaproponowanego rozwiązania.

Model OSI

5/5 - (1 vote)

Organizacja ISO opracowała Model Referencyjny Połączonych Systemów Otwartych (model OSI) w celu ułatwienia realizacji otwartych połączeń systemów komputerowych. Połączenia otwarte to takie, które mogą być obsługiwane w środowiskach wielosystemowych. Omawiany model jest globalnym standardem określania warstw funkcjonalnych wymaganych do obsługi tego typu połączeń. Model referencyjny OSI dzieli procesy zachodzące podczas sesji komunikacyjnej na siedem warstw funkcjonalnych, które zorganizowane są według naturalnej sekwencji zdarzeń zachodzących podczas sesji komunikacyjnej. Warstwy od 1 do 3 umożliwiają dostęp do sieci, a warstwy od 4 do 7 obsługują logistycznie komunikację końcową.

Nazwa warstwy modelu OSI Numer warstwy
Aplikacji 7
Prezentacji 6
Sesji 5
Transportu 4
Sieci 3
Łącza danych 2
Fizyczna 1

Warstwa fizyczna. Warstwa najniższa. Jest ona odpowiedzialna za przesyłanie strumieni bitów. Odbiera ramki danych z warstwy 2, czyli warstwy łącza danych, i przesyła szeregowo, bit po bicie, całą ich strukturę oraz zawartość. Jest ona również odpowiedzialna za odbiór kolejnych bitów przychodzących strumieni danych. Strumienie te są następnie przesyłane do warstwy łącza danych w celu ich ponownego ukształtowania.

Warstwa łącza danych. Druga warstwa modelu OSI nazywana jest warstwą łącza danych. Jak każda z warstw, pełni ona dwie zasadnicze funkcje: odbierania i nadawania. Jest ona odpowiedzialna za końcową zgodność przesyłania danych. W zakresie zadań związanych z przesyłaniem, warstwa łącza danych jest odpowiedzialna za upakowanie instrukcji, danych itp. W tzw. ramki. Ramka jest strukturą rodzimą – czyli właściwą dla – warstwy łącza danych, która zawiera ilość informacji wystarczającą do pomyślnego przesyłania danych przez sieć lokalną do ich miejsca docelowego. Pomyślna transmisja danych zachodzi wtedy, gdy dane osiągają miejsce docelowe w postaci niezmienionej w stosunku do postaci, w której zostały wysłane. Ramka musi, więc zawierać mechanizm umożliwiający weryfikowanie integralności jej zawartości podczas transmisji. W wielu sytuacjach wysyłane ramki mogą nie osiągnąć miejsca docelowego lub ulec uszkodzeniu podczas transmisji. Warstwa łącza danych jest odpowiedzialna za rozpoznawanie i naprawę każdego takiego błędu. Warstwa łącza danych jest również odpowiedzialna za ponowne składanie otrzymanych z warstwy fizycznej strumieni binarnych i umieszczanie ich w ramkach. Ze względu na fakt przesyłania zarówno struktury, jak i zawartości ramki, warstwa łącza danych nie tworzy ramek od nowa. Buforuje ona przychodzące bity dopóki nie uzbiera w ten sposób całej ramki.

Warstwa sieci jest odpowiedzialna za określenie trasy transmisji między komputerem-nadawcą, a komputerem-odbiorcą. Warstwa ta nie ma żadnych wbudowanych mechanizmów korekcji błędów i w związku z tym musi polegać na wiarygodnej transmisji końcowej warstwy łącza danych. Warstwa sieci używana jest do komunikowania się z komputerami znajdującymi się poza lokalnym segmentem sieci LAN. Umożliwia im to własna architektura trasowania, niezależna od adresowania fizycznego warstwy 2. Korzystanie z warstwy sieci nie jest obowiązkowe. Wymagane jest jedynie wtedy, gdy komputery komunikujące się znajdują się w różnych segmentach sieci przedzielonych routerem.

Warstwa transportu, pełni funkcję podobną do funkcji warstwy łącza w tym sensie, że jest odpowiedzialna za końcową integralność transmisji. Jednak w odróżnieniu od warstwy łącza danych – warstwa transportu umożliwia tę usługę również poza lokalnymi segmentami sieci LAN. Potrafi, bowiem wykrywać pakiety, które zostały przez routery odrzucone i automatycznie generować żądanie ich ponownej transmisji. Warstwa transportu identyfikuje oryginalną sekwencję pakietów i ustawia je w oryginalnej kolejności przed wysłaniem ich zawartości do warstwy sesji.

Warstwa sesji, jest piątą warstwą modelu OSI. Jest ona rzadko używana; wiele protokołów funkcje tej warstwy dołącza do swoich warstw transportowych. Zadaniem warstwy sesji modelu OSI jest zarządzanie przebiegiem komunikacji podczas połączenia miedzy dwoma komputerami. Przepływ tej komunikacji nazywany jest sesją. Warstwa ta określa, czy komunikacja może zachodzić w jednym, czy obu kierunkach. Gwarantuje również zakończenie wykonywania bieżącego żądania przed przyjęciem kolejnego.

Warstwa prezentacji, jest odpowiedzialna za zarządzanie sposobem kodowania wszelkich danych. Nie każdy komputer korzysta z tych samych schematów kodowania danych, więc warstwa prezentacji odpowiedzialna jest za translację między niezgodnymi schematami kodowania danych. Warstwa ta może być również wykorzystywana do niwelowania różnic między formatami zmiennopozycyjnymi, jak również do szyfrowania i rozszyfrowywania wiadomości.

Warstwa aplikacji, jest najwyższą warstwą modelu OSI. Pełni ona rolę interfejsu pomiędzy aplikacjami użytkownika a usługami sieci. Warstwę tę można uważać za inicjującą sesje komunikacyjne.

Wstęp pracy magisterskiej

5/5 - (1 vote)

W dzisiejszych czasach usługi informatyczne zdominowały zarówno świat biznesu, jak i prywatne życie zwykłych ludzi. Internet spopularyzował systemy komputerowe do tego stopnia, że zaczynają one wypierać tradycyjne metody przetwarzania informacji ze wszystkich dziedzin życia. W świecie WWW można skorzystać ze słownika, obejrzeć mapy, szybko i komfortowo wyszukać dowolne interesujące nas dane.

Jak łatwo się domyśleć wraz z popularnością systemów informatycznych wzrosła liczba ich potencjalnych użytkowników, co bezpośrednio wiąże się z potrzebą zwiększenia mocy obliczeniowej. Firmy prześcigają się w ofertach dużych, wieloprocesorowych maszyn, które umożliwiłyby obsługę tysięcy czy nawet milionów użytkowników na sekundę. Niestety koszt takiej maszyny bardzo często przekracza budżet małych czy średnich firm, które mają dobre pomysły, ale brakuje im odpowiednich funduszy, aby je zrealizować. W takiej sytuacji idealnym rozwiązaniem może okazać się połączenie wielu zwykłych, niedrogich komputerów, które wspólnie umożliwią obsługę dużej liczby klientów. Aby taka architektura mogła rozwiązać problem zwiększonego zapotrzebowania na moc obliczeniową w sposób niewidoczny dla końcowego użytkownika, niezbędne jest odpowiednie oprogramowanie.

W swojej pracy przedstawię pomysł stworzenia modułu wspierającego rozproszone przetwarzanie danych (klaster) dla bardzo popularnego serwera WWW – Jakarta-Tomcat. W pierwszej części zostanie przedstawiona koncepcja klastra (por. rozdz. 2) oraz opisany sposób działania Tomcata (por. rozdz. 3). W drugiej części pracy przedstawię zrealizowany przeze mnie moduł klastra (por. rozdz. 4) wraz z testami jego wydajności (por. rozdz. 5). Możliwe rozszerzenia opisuję w rozdz. 6.

W pracy prezentuję pozytywne strony wykorzystania modelu replikowania „każdy do każdego”. Wykazuję, że dobrze zaimplementowany moduł może okazać się bezpieczniejszy i wydajniejszy od modelu „serwer macierzysty, serwer kopii”. Oczywiście implementacja jest znacznie bardziej skomplikowana (pojawia się problem synchronizowania dostępu do sesji) – niemniej jednak zysk jaki można osiągnąć stosując ten model w przypadku protokołu HTTPS rekompensuje trudy implementacji modułu.

 

Otwarte Oprogramowanie

5/5 - (1 vote)

Geneza

Początki idei Otwartego Oprogramowania oficjalnie datuje się na rok 1984, kiedy to Richard Stallman, sfrustrowany niemożnością naprawy urzą­dzenia komputerowego w swoim biurze, założył Fundację Wolnego Oprogra­mowania [1]. Producent odmówił mu udostępnienia kodów źródłowych, które pozwoliłyby rozwiązać problem.

Komercyjne firmy produkujące oprogramowanie zazwyczaj sprzedają tyl­ko wersje binarne swoich programów. Zatrzymują natomiast kod źródłowy, który pozwala na zrozumienie zasad działania oprogramowania i wprowadze­nie ewentualnych zmian, jeśli zaszła by taka potrzeba. Otwarty kod źródłowy staje się także gwarancją dobrej jakości. Jeżeli programy są dostarczane tylko w postaci zamkniętej[1], nierzetelny producent może umieścić w nich elemen­ty, które będą działać na szkodę użytkowników. Nie musi też utrzymywać wysokiej jakości, gdyż nikt nie widzi jego pracy.

Jednak rozprowadzanie wersji binarnych wraz kodami źródłowymi mia­ło miejsce już na długo przed powstaniem FSF[2]. Instytucje dystrybuowały w ten sposób oprogramowanie, aby zapewnić sobie wsparcie swoich klientów oraz by wymienić się doświadczeniami z innymi programistami. Tak powsta­wały pierwsze systemy operacyjne firm IBM i AT&T Bell Labs – DOS i Unix.

W latach osiemdziesiątych producenci widząc, że można czerpać zyski z opłat licencyjnych, coraz częściej zaczęli zamykać swoje programy [7]. Po­wstanie organizacji chroniącej otwarte oprogramowanie było niezbędne, by zapobiec przywłaszczaniu pracy programistów chcących pracować zgodnie z tą ideą. Stworzenie FSF nie przypadkowo zbiegło się też z innym przeło­mowym wydarzeniem – ogłoszeniem przez AT&T zamiaru pobierania opłat licencyjnych od systemu Unix, co wywołało duże niezadowolenie w kręgach inżynierskich.

W ponad trzydziesto letniej tradycji rozwoju oprogramowania, utajnia­nie kodów źródłowych jest względnie młodym zjawiskiem. Natomiast dzisiaj idea Otwartego Oprogramowania staje się przedmiotem coraz szerszego za­interesowania i wspierana jest nawet na poziomie państw [21]. W związku z tym można stwierdzić, iż pod wieloma względami świat oprogramowania zatacza pełne koło.

Czym jest wolne oprogramowanie

Zjawisko Otwartego Oprogramowania to fenomen, który jest na całym świecie badany przez wielu specjalistów z różnych dziedzin. Zaskoczyło naj­większych w środowisku biznesu i na stałe zmieniło przemysł związany z in­formatyką [7]. Dla wielu jest nadal nie zrozumiałą zagadką. W świecie agre­sywnego kapitalizmu nie powinno mieć swojego miejsca, a jednak zaistniało i nabiera coraz większego impetu. Jest samo spełniającą się przepowiednią, która powoduje, że sprzedaż alternatywnych rozwiązań staje się coraz trud­niejsza.

Mianem Otwartego Oprogramowania określa się oprogramowanie dostęp­ne wraz z kodami źródłowymi, które może być swobodnie studiowane, roz­powszechniane i modyfikowane przez użytkownika [2]. Samo określenie jest używane jako synonim dla Wolnego Oprogramowania oraz Oprogramowa­nia Open Source. Zarówno w przypadku WO jak i OSS efekty końcowe są identyczne, natomiast różnica leży w ideach jakimi kierują się programiści.

Wolne Oprogramowanie jest terminem używanym przez Richarda Stall- mana i osoby związane z fundacją FSF. Słowo wolne rozumiane jest tu nie jako powolne lub wolne od opłat, ale w kategorii wolności słowa. Słynne jest tu powiedzenie, że to nie kwestia ceny, ale wolności [1]. Puryści w rodzaju Stallmana wierzą, że tworzenie oprogramowania tak, aby nowe technologie były dostępne dla wszystkich, jest równie ważne jak wolność słowa. Jednak motywy takiego poglądu nie leżą w sferze moralnej, jak by to się mogło wy­dawać, ale w przekonaniu, że społeczeństwo, którego podstawą jest wolność wypowiedzi i wolny rynek po prostu funkcjonuje lepiej niż alternatywne. Trudno się tu nie zgodzić z tym twierdzeniem, jednak trudno też nie zauwa­żyć, że mechanizmy na jakich funkcjonuje współczesny świat są tylko w nie­wielkim stopniu nakierowane na dobro człowieka i społeczeństwa, w którym on żyje. Dlatego też, szczególnie w środowiskach biznesowych, takie poglądy mogą nie być zbyt popularne.

Ruch Open Source nie podziela w pełni nieco utopijnej wizji świata pre­zentowanej przez Richarda Stallmana i uważa, że może ona tu tylko zaszko­dzić. Motywami jakimi kierują się zwolennicy OSS jest przekonanie, że je­dynie taki sposób tworzenia oprogramowania, poprzez udostępnianie kodów źródłowych i nawiązanie współpracy ze środowiskiem zewnętrznym, pozwala uzyskać jego najwyższą jakość i wiarygodność oraz daje możliwość dotrzy­mania kroku producentom sprzętu [3].

Jednak dzisiaj w dobie nowej ekonomii i nowych sposobów zarządzania [4] obie ideologie mają szanse się spotkać. Menadżerowie coraz częściej dochodzą do wniosku, że zwrot w kierunku człowieka, wykorzystywanie jego potencjału i działanie dla jego dobra jest jedyną drogą do osiągnięcia prosperity. Moż­na stwierdzić, że środowisko biznesu zaczyna nabierać wymiar humanizmu. W takim świecie idee Otwartego Oprogramowania będą zyskiwać na wartości.

W ramach ochrony prawnej FSF zdecydowało się na przyjęcie systemu li­cencyjnego. Mimo że właśnie tym narzędziem posługują się producenci opro­gramowania zamkniętego, okazało się ono najlepszym rozwiązaniem. Naj­ważniejszą licencją dla otwartego oprogramowania[5] jest GNU[6] General Pu­blic License. Ochrona, jaką zapewnia ta licencja, nie dotyczy dzieła ja­ko takiego, ale wolności jego rozpowszechniania. Zabezpiecza wolę twórców oprogramowania, którzy chcą aby mogło ono być swobodnie używane przez innych, jednak nie zgadzają się na wykorzystywanie swojej pracy w zamknię­tych produktach. Programy wykorzystujące w całości lub w części kod na licencji GNU GPL muszą być opublikowane na tej samej licencji, czyli nie mogą zostać zamknięte

FSF zachęca programistów do zrzekania się praw autorskich oprogramo­wania na licencji GNU GPL na rzecz fundacji. Jest to podyktowane tym, że FSF dysponuje odpowiednimi środkami prawnymi pozwalającymi na skutecz­ne działanie w sytuacjach stwierdzenia naruszenia postanowień licencyjnych. Programiści nie powinni zajmować się aspektami prawnymi, a jedynie pisaniem dobrego kodu. Zrzeczenie się praw autorskich w żaden sposób nie zmienia informacji na temat tego, kto jest autorem dzieła i nie odbiera ko­rzyści płynących z tego tytułu.[7]

Oprócz licencji GNU GPL istnieją także inne licencje, którymi posługu­je się Otwarte Oprogramowanie. Stanowią one modyfikacje podstawowej licencji lub są po prostu zgodne z jej duchem. Część twórców otwartego opro­gramowania nie zgadza się ze wszystkimi konsekwencjami liberalnej licencji GNU GPL i decyduje się na przyjęcie rozwiązań nieco różniących się w spor­nych miejscach.

Ostatecznym kryterium otwartości oprogramowania jest więc licencja, która powinna być zgodna z duchem GNU GPL. Sama dostępność kodów źródłowych o niczym nie musi świadczyć. Zdarzają się firmy, które dla po­prawy swojego wizerunku przekazują swoim klientom kody źródłowe.[8] Jed­nak są to tylko zabiegi marketingowe i nie ma to nic wspólnego z Otwartym Oprogramowaniem, gdyż takie programy nie są tworzone zgodnie z ideami WO/OSS oraz wraz z przekazaniem źródeł nie jest przekazywane prawo do ich swobodnego używania.

[1]Bez kodu źródłowego.

[2]Skrót od pierwszych liter Free Software Foundation.

[3]Od angielskiego: Free Software. Dalej oznaczanego skrótem WO.

[4]Rozpowszechnianego wraz z kodami źródłowymi. Dalej oznaczanego skrótem OSS.

[5]OSS posługuje się systemem licencyjnym wypracowanym przez FSF lub w dużym stopniu z nim zgodnym.

[6]Skrót pochodzi od słów GNU’s Not Unix, które jasno miały określać, że projekt nie ma nic wspólnego z systemem Unix. Jest to także przekorna gra słów związana z wydarzeniami towarzyszącymi powstaniu FSF (roz. 2.1).

[7]Zyskanie sławy i dobrego imienia jest częstym motywem programistów piszących otwarte oprogramowanie.

[8]Przykładem może być firma Microsoft, która klientom korporacyjnym dostarcza kody źródłowe systemu Windows.

Implementacja Joomla!

5/5 - (1 vote)

Nadleśnictwo Węgierska Górka składa się z dwóch obrębów: Lipowa i Węgierska Górka i wchodzi w skład Regionalnej Dyrekcji Lasów Państwowych w Katowicach. Powierzchnia zasięgu terytorialnego nadleśnictwa wynosi 28 968 ha. Do głównych zadań nadleśnictwa należy prowadzenie spraw związanych z planowaniem, organizacją, koordynacją i nadzorem prac w zakresie: nasiennictwa, szkółkarstwa, hodowli lasu, łowiectwa oraz innych działów zagospodarowania lasu, użytkowania lasu oraz sprzedaży drewna.

Nadleśnictwo prowadzi sprawy związane ze stanem posiadania i ewidencją gruntów, udostępnianiem lasu oraz edukacją leśną społeczeństwa jak również kieruje nadzór nad lasami nie stanowiącymi własności Skarbu Państwa. Realizuje działania w zakresie prowadzenia Leśnego Kompleksu Promocyjnego oraz tworzenia i redagowania informacji na strony Biuletynu Informacji Publicznej.

W ostatnich dziesięcioleciach zaobserwowano stałe powolne pogarszanie się kondycji lasów. Wpływ na to miało rozpadanie się podstawowego gatunku lasotwórczego w tym regionie – świerka. Przyczyniły się do tego:

  • przewaga jednego gatunku, sztucznie wprowadzonego,
  • zakłócenia hydrologiczne spowodowane anomaliami pogodowymi, spadek retencji obszarów leśnych,
  • choroby systemów korzeniowych spowodowane przez opieńkę,
  • plaga kornika,
  • zaniedbania w higienie lasu właścicieli prywatnych,
  • śniegołomy i wiatrołomy.

Dziś jednym z kluczowych zadań jest opóźnienie procesu wymarcia beskidzkiej świerczyny poprzez usuwanie zarażonych drzew i stopniową przebudowę drzewostanu. Informowanie społeczeństwa o przyczynach dotyczących wzmożonej wycinki świerka odgrywa istotną rolę. Dzięki temu zapobiega się błędnemu postrzeganiu Lasów Państwowych jako podmiotu prowadzącego rabunkową gospodarkę leśną. Również ważne jest nakłonienie do współpracy prywatnych właścicieli lasów, w których rękach znajduje się ok. 1/5 beskidzkich lasów.

Dlatego potrzebna jest kampania informacyjna skierowana do prywatnych właścicieli.

Zarządzanie stroną

Po uruchomieniu serwisu poprzez wpisanie adresu internetowego w przeglądarce pojawia się główna strona, na której znajduje się dodatkowe menu pozwalające zalogować się do panelu administracyjnego.

Rysunek 18. Panel administracyjny Joomla!

Joomla! Administrator jest graficznym interfejsem użytkownika (GUI) (rys.18) służącym do zarządzania witryną. W panelu administracyjnym znajdują się wszystkie konieczne narzędzia do dodawania zawartości, a także do zarządzania konfiguracją oraz wszystkimi składnikami Joomla!

Tabela 3. Opis głównych elementów panelu administracyjnego

Dodaj artykuł Umożliwia dodanie nowego artykułu przypisanego do danej sekcji i kategorii
Artykuły Pozwala przeglądać wszystkie artykuły lub tylko w wybranych sekcjach/kategoriach oraz nimi zarządzać
Materiały statyczne Wyświetla materiały statyczne i pozwala nimi zarządzać
Strona startowa Komponent zarządzający stroną naszego serwisu, która wyświetla się jako pierwsza
Sekcje artykułów Zawiera sekcje do których przyporządkowane są kategorie, z możliwością dodawania, usuwania, edytowania
Kategorie artykułów Zawiera kategorie, w których znajdują się artykuły, publikowania, edytowania lub tworzenia nowych kategorii
Biblioteka mediów Zarządzenie mediami- wczytywanie nowych obrazków, plików dźwiękowych czy wideo
Kosz Miejsce, w którym znajdują się usunięte przez nas elementy menu oraz opublikowane artykuły. Aż do momentu definitywnego usunięcia można je z tego miejsca odzyskać
Menedżer menu Menedżer umożliwia tworzenie wielu menu i wyświetlających je modułów oraz zmianę nazw menu. Z poziomu menedżera menu dostępny jest edytor właściwości menu, umożliwiający zdefiniowanie nazwy – typu menu i tytułu wyświetlającego je modułu, a po utworzeniu menu tylko zmianę nazwy menu
Języki Zmiana języka naszej witryny
Użytkownicy W tym miejscu można zarządzać kontami użytkowników: tworzyć, blokować, usuwać, zmieniać uprawnienia, wylogowywać z serwisu
Konfiguracja Znajduję się tu szczegółowa konfiguracja naszego serwisu, jego lokalizacji, globalnych ustawień co do wyglądu treści oraz konfiguracji bazy danych, konta administratora, statystki strony

Dostosowanie Joomla! dla potrzeb klienta

Głównym zadaniem było stworzenie serwisu internetowego i dopasowanie go dla potrzeb nadleśnictwa Węgierska Górka (rys.19). W założeniu serwis powinien spełniać kilka podstawowych wymogów:

  • powinien być jak najprostszy w obsłudze dla użytkowników mających słabe doświadczenie z komputerem,
  • edycj a serwisu ma być dostępna z różnych miej sc,
  • koszt budowy i utrzymania serwisu powinien być j ak najniższy,
  • nie trzeba stosować specjalistycznego oprogramowania komputerowego,
  • powinien spełniać rolę informacyjną,
  • promować nadleśnictwo,
  • ma wspomagać pracę leśników.

Przy pierwszym uruchomieniu naszej strony stworzonej w Joomla! mamy serwis z domyślną szatą graficzną, w którym możemy publikować tekst i umieszczać obrazki. Jednak system ma budowę modułową, dzięki czemu dodawanie nowych możliwości nie stanowi problemu. Poniżej znajduje się lista wykorzystanych w projekcie komponentów, które zostały dobrane podczas moich konsultacji z pracownikami nadleśnictwa.

Blog – artykuły z sekcji

Zadaniem stron WWW jest promowanie oraz dostarczanie informacji. Od około roku leśnicy prowadzą kampanię na rzecz ratowania beskidzkich świerków.

Jednym z problemów jest dotarcie i przekonanie właścicieli lasów prywatnych, by usuwali zaatakowane świerki. Leśnicy rozdają ulotki informacyjne, organizują spotkania robocze, proszą o pomoc księży, którzy nawołują z ambon do ratowania lasów. I choć ten problem jest już w bardzo dużym zakresie opisany na wielu internetowych stronach Lasów Państwowych czy stronach poświęconych ekologii, to każda kolejna witryna poruszająca tą tematykę zwiększa szansę dotarcia do zainteresowanych osób.

Treść możemy publikować w postaci blogów lub tabel. Formy blogu używa się w przypadku małej ilości artykułów, są one wyświetlane w całości jeden po drugim. Tabela to lista odnośników do poszczególnych artykułów, jest przydatna przy dużej ilości artykułów. Publikowanie artykułów jest nad wyraz proste, do dyspozycji możemy wybrać jeden z kilku edytorów, które swoim wyglądem przypominają windowsowego WordPada. Wystarczy stworzyć kategorię i przypisywać do niej kolejne artykuły.

Osobisty kalendarz

Do stworzenia kalendarza wykorzystany został komponent ExtCalendar. Osobisty kalendarz jest dostępny tylko dla właściciela strony i grupy osób z odpowiednimi uprawnieniami. Zakładka w menu pojawia się tylko po jego zalogowaniu. Dzieje się tak dzięki przypisaniu tej pozycji menu dostępu specjalny. Dostęp specjalny (ang. special) to uzyskiwany po zalogowaniu się do witryny dostęp dla zarejestrowanych użytkowników, którym administrator witryny nadał specjalne przywileje (przypisał ich do grupy z uprawnieniami specjalnymi). Dzięki takiemu rozwiązaniu kalendarz może służyć do wymiany informacji między pracownikami nadleśnictwa a leśniczym, np. w łatwy sposób można zmienić datę narady lub sprawdzić, kiedy leśniczy ma urlop (rys.21).

Po kliknięciu na wybraną datę mamy szczegółowy podgląd przypisany do wydarzenia (rys.22).

Rysunek 22. Szczegółowy opis wydarzenia „Obchód Terenu”

Dodaj wydarzenie Miesiąc Wykaz Tydzień Dzień Kategorie Znajdź
■■ Wydarzenie: 'Obchód Terenu’
1 Ogólne Data: Poniedziałek, Sierpień 04, Z008 At 08:00
1 To jest domyślna kategoria Czas trwania: 1 dzień
Obchód terenu Podlas, Drągowy. Kontrola pułapek kornika w oddziale 9 i 17, bez uwag.

Obsługa tego komponentu została maksymalnie uproszczona, ponadto jest on w polskiej wersji językowej.

Oferty handlowe

Przy użyciu komponentu JPortfolio, który jest dedykowany do prezentacji produktów zebranych w kategorie, w prosty sposób można stworzyć ofertę handlową danego nadleśnictwa. Jest to ogromne ułatwienie dla ludzi chcących zapoznać się z cenami drewna i innych produktów za pomocą Internetu.

Wadą komponentu jest brak polskiej wersji językowej.

Drewno

Sprzedaż drewna.

Leśnictwo oferuje szeroki asortyment surowca drzewnego takich gatunków jak: świerk, sosna, modrzew, buk, brzoza i in. Sprzedaż drewna prowadzi się bezpośrednio z lasu (loco las) lub ze Składnicy Spedycyjnej Drewna w Węgierskiej Górce, z której istnieje możliwość wysłania ładunku transportem kolejowym i kołowym. Odnośnie zakupu drewna większych ilości należy kontaktować się z:

  • Zastąpcą Nadleśniczego mgr inż. Wojciechem Motyka ( tel. 660 021 358, w.motyka(®katowice.lasy.pl ),
  • Specjalista, ds. marketingu inż. Marcinem Szewczyk ( tel. 033/867 22 12/14, kom. 660 155 458 m.szewczyktąkatowice.lasy.gov.pl ).

Drewno średniowymiarowe opałowe oraz małowymiarowe można bezpośrednio kupować u leśniczych, do których telefony kontaktowe podane są w tabeli „Struktura organizacyjna”.

Ceny detaliczne surowca drzewnego iglastego i liściastego zamieszczone są w dostępnych zestawieniach.

Po wprowadzeniu produktów przyporządkowanych do odpowiednich kategorii możemy załączyć jeden obrazek i umieścić opis korzystając z wbudowanego edytora (rys.24-25). Edycja poszczególnych produktów jest prosta i szybka, dzięki czemu łatwo możemy zaktualizować np. cennik.

Świerk:

Cennik surowca drzewnego iglastego – sprzedaż detaliczna obowiązujący na okres od 17 stycznia 2008r.

L.p. Symbol Klasa wymiarowa Cena netto[1] loco las po zrywce w zł/lm3
1 WńO 2 320
2 3 370
3 1 255
4 WBO 2 280
5 3 300
6 i 250
7 wco 2 270
8 3 290
9 i 150
10 WD 2 180
11 3 191
12 SIO – 150
13 S2a – 125
14 S2b – 170
15 S3a – 150
16 S3b 1 130
17 2 130
18 S4 – 65
19 M2 – 40

 

„*Do ceny drewna S4 i M2 dolicza się 7% podatku VAT, do ceny stroiszu iglastego 3 % VAT, a do ceny pozostałych sortymentów 22% podatku VAT”

Przy sprzedaży ze składnicy do ceny drewna dolicza się ryczałt składnicowy.

Rysunek 25. Szczegółowa oferta drewna gatunku świerk

Komponent umożliwia edycję CSS, dzięki czemu można dopasować wygląd generowanych stron do szablonu witryny.

Rysunek 26. Główny panel komponentu Forme

Menedżer formularzy Formularze

przychodzące

 Dodaj przykładowe dane Forme u1.0.2
Formularz zwrotny
DONATĘ ] Wersja: Forme v1.0.2
Informacja
Wydawca: |©2007
Darowizna Licencja: gnu.org/copyleft/gpl.html GNUA3PL
Wykonaj kopie formularzy Przywróć z kopii

 

Wadą komponentu Forme jest brak możliwości zmiany wyglądu formularza, np. odstępów między poszczególnymi polami (rys.27). Należy również pamiętać, że przesyłane w ten sposób dane nie są w żaden sposób szyfrowane, a więc istnieje możliwość przejęcia ich przez niepożądane osoby.

Rysunek 27. Wygląd gotowego formularza

► BRUDNICA MNISZKA

Numer protokołu * 5
Sporządzony dnia * 30.05.2008
Oddział, pododdział VM
Typ siedliskowy lasu Św yj
Wiek rzeczywisty 20 jJ
Stopień defoliacji *
Bonitacja/zwarcie 30%             –
Liczba samic zaobserwowanych na drzewie * 11|wyślij

 

Biorąc pod uwagę, że w nadleśnictwie korzysta się z około 60-ciu różnych formularzy i blankietów, zastosowanie powyższego komponentu może znacznie ułatwić pracę biurową. Ze względu na to, iż nie każdy ma dostęp do Internetu, rozwiązanie to może jedynie uzupełniać obecnie używane papierowe dokumenty.

Struktura organizacyjna – książka adresowa

Przy użyciu komponentu Kontakty można w łatwy sposób stworzyć strukturę organizacyjną danej firmy, umieścić w nich odpowiednie dane kontaktowe, co ułatwi osobom zainteresowanym jak i samym pracownikom komunikację.

Po utworzeniu interesujących nas kategorii (rys.28) umieszczamy w nich dane poszczególnych osób tworząc w ten sposób uporządkowaną strukturę organizacyjną nadleśnictwa.

Komponent narzuca nam z góry ustawienia strony pozwalając na tylko nieznaczną modyfikację, mimo to jest funkcjonalny a książka adresowa stworzona przy jego pomocy przejrzysta (rys.29).

Biuletyn Informacji Publicznej

Biuletyn Informacji Publicznej to już niemal standard większości portali internetowych związanych głównie z instytucjami samorządowymi lub publicznymi. Dzięki komponentowi DOCMan możemy w łatwy sposób umieszczać pliki, grupować je w odpowiednie kategorie oraz opisywać, co ułatwi rozeznanie w dokumentach osobom zainteresowanym. Osoba zarządzająca dokumentami ma możliwość podglądu statystyk ściągania poszczególnych plików lub nadawania uprawnień do ściągania plików (rys.31).

Klasyfikacja funkcjonalna zadań Lasów Państwowych O Klasyfikacja funkcjonalna zadań Lasów Państwowych

DOCMan pozwala wczytywać pliki z lokalnego dysku lub „podłączać” pliki znajdujące się na innym serwerze, dzięki czemu możemy zmniejszyć zajmowaną przestrzeń dyskową naszego serwera. Komponent został przetłumaczony na język polski.

Forum dyskusyjne

Forum dyskusyjne jest przeniesioną do struktury stron WWW formą grup dyskusyjnych, która służy do wymiany informacji i poglądów przy użyciu przeglądarki internetowej.

Na stworzonym forum użytkownicy mogą wymieniać poglądy odnośnie ochrony środowiska, zarządzaniem lasu czy prawem leśnym.

Joomlaboard jest komponentem mocno rozbudowanym i z powodzeniem może konkurować z phpBB czy QuickForum – systemami dedykowanymi tylko do tworzenia forów internetowych.

Joomlaboard-Forum

Zadaniem forum jest zachęcić zainteresowane strony do swobodnej wymiany poglądów na różne tematy (rys.34).

Sonda

Ten komponent daje użytkownikom możliwość wypowiedzenia się na dany temat. Dzięki temu możemy zdobyć ważne informacje na interesujący nas temat. Komponent nie ogranicza nas do prowadzenia jednej sondy, umożliwia zarządzanie nawet kilkoma sondami naraz.

W ustawieniach możemy zdefiniować czas pomiędzy głosowaniem dla jednego użytkownika, strony, na których ma pojawiać się sonda oraz listę możliwych, maksymalnie dwunastu odpowiedzi.

Wyniki są gromadzone w bazie danych. Po oddaniu głosu, na ich podstawie w serwisie internetowym są automatycznie publikowane rezultaty (rys.36).

Księga gości

Księga gości pozwala internautom przeglądającym serwis na pozostawienie informacji oraz ocenę strony.

Komponent księgi gości ArtgBook 1.0 b4 został zastosowany w połączeniu z cenzorem nieprzyzwoitych słów BadWord Filter, co skutecznie blokuje wyświetlanie nieprzyzwoitych słów na naszej stronie. O skuteczności tego komponentu możemy przekonać się przy wpisie anonima, gdzie dwa wulgarne słowa zostały zastąpione predefiniowanymi symbolami.

Dodawanie wpisów do księgi gości jest proste, a sposób autoryzacji kodem z obrazka zapobiega automatycznemu tworzeniu wpisów przez roboty sieciowe

[1] Formularze

Kolejna zakładka, do której dostęp mają tylko określeni użytkownicy. Komponent Forme umożliwia tworzenie oraz bezpośrednie wysyłanie formularzy do nadleśnictwa, w których zawarte są informacje z przeprowadzonych prac w lesie (rys.26). Dzięki temu formularze mogą docierać znacznie szybciej, niż tradycyjną drogą, co eliminuje konieczność fizycznego ich przewożenia.