Poznańskie Centrum Superkomputerowo - Sieciowe

PROJEKT LDAP

 

Raport z wdrożenia systemu informacji

o usługach i zasobach POL-34 wykorzystującego bazę LDAP

 

Bartosz Belter

Jerzy Chochulski

Wiktor Procyk

 

Poznań 2003

 

Spis treści

 

1 Wstęp *

2 Założenia *

2.1 Założenia projektowe *

2.2 Język programowania i technologia *

3 Implementacja systemu *

3.1 Warstwa biznesowa *

3.2 Warstwa prezentacji *

4 Przykłady działania aplikacji *

5 Propozycje rozwoju *

6 Podsumowanie *

 

 

  1. Wstęp
  2. Niniejszy dokument stanowi raport wdrożeniowy systemu informacji o usługach i zasobach POL-34 wykorzystującego bazę LDAP. Projekt systemu został omówiony w raporcie "Projekt technik umożliwiających przechowywanie i gromadzenie w bazie LDAP informacji o zasobach POL-34/NASK : założenia ogólne i wymagania specyficzne w sieci POL-34".

    Celem tego raportu jest omówienie założeń dotyczących implementacji i wdrożenia systemu oraz wybranych technologii.

  3. Założenia
    1. Założenia projektowe
    2. Projekt systemu zakłada stosowanie bazy LDAP jako repozytorium informacji. Najważniejszym znanym ograniczeniem bazy LDAP jest preferencja do danych, które są rzadko modyfikowane.
      W przypadku systemu informacji o zasobach sieci POL34 ograniczenie to jest nieistotne. Istotną zaletą bazy LDAP jest natomiast hierarchiczność struktury danych pozwalająca w prosty sposób modelować rzeczywistość. Możliwość definiowania zależności pomiędzy obiektami umożliwia stosowanie bazy LDAP do wszystkich, także niestandardowych przypadków, gdzie hierarchiczność danych może być zakłócona.

      Drugie istotne założenie dotyczy sposobu komunikacji systemu z użytkownikiem. System adresowany jest przede wszystkim do administratorów urządzeń sieciowych. Aby w maksymalnym stopniu uprościć korzystanie z systemu zaproponowana została obsługa systemu poprzez interfejs WWW. Taki sposób, oprócz niewątpliwych zalet, ma także pewne ograniczenia. Każda zmiana schematu bazy LDAP wymaga wprowadzenia zmian w kodzie implementacji interfejsu zmniejszając elastyczność całości systemu na modyfikacje struktur danych.

      Jak przedstawiono powyżej projekt systemu precyzuje założenia dotyczące dwóch skrajnych elementów systemu - repozytorium danych oraz interfejs użytkownika, pozostawiając całkowitą swobodę w zakresie elementów pośrednich.

    3. Język programowania i technologia
    4. Wobec dość złożonej struktury danych do przechowywania informacji o zasobach sieci POL34 oraz licznych powiązań pomiędzy obiektami do implementacji systemu wybrano język Java. Język ten, jako język obiektowy, wyróżnia się prostotą w implementacji nawet bardzo rozbudowanych modeli. Inne zalety to bogate wsparcie dla tego języka oraz niezależność od platformy sprzętowej, tak samego kodu jak i skompilowanych binariów. Do oprogramowania obsługi serwera LDAP wykorzystany zostanie pakiet Netscape Directory SDK for Java.

      Jako warstwę pośrednią pomiędzy interfejsem użytkownika (www) a implementacją systemu w języku Java wybrany został serwer aplikacji Jakarta Tomcat. Serwer Tomcat może służyć jako niezależny serwer WWW lub współpracować z innymi serwerami, np. Apache. Zestawienie połączenia z serwerem WWW daje kilka istotnych korzyści. Tomcat zostaje zwolniony z obowiązku utrzymywania połączeń HTTP, zwłaszcza dla statycznej części serwowanych treści. Możliwe jest też skorzystanie z bezpiecznego protokołu SSL "wkomponowanego" w serwer Apache. Serwer WWW może ponadto w pełniejszy sposób obsługiwać własności protokołu HTTP, a także oferować dodatkowe możliwości, np. zarządzanie pasmem czy kompresję treści w locie.

  4. Implementacja systemu
    1. Warstwa biznesowa
    2. Struktura klas warstwy biznesowej odzwierciedla hierarchię i powiązania pomiędzy obiektami bazy LDAP. Poniżej zamieszczony został diagram klas uwzględniający powiązania ilościowe pomiędzy klasami.

      Rys. Struktura klas warstwy biznesowej

    3. Warstwa prezentacji
    4. Rys. Struktura klas warstwy prezentacji

      W warstwie prezentacji do wyboru operacji wykorzystano mechanizm wzorca projektowego "Factory Method". Na obiekcie OperationFactory wykonanie metody getInstance() powoduje utworzenie właściwej instancji klasy abstrakcyjnej AbstractOperation. Następnie na instancji wywoływana jest metoda execute(), która realizuje założone działania. Przykładami klas dziedziczących z klasy AbstractOperation są np. DeviceAddOperation, PatchcordsOperation, LocationEditOperation.

  5. Przykłady działania aplikacji
  6. Poniżej zamieszczone zostały zrzuty ekranu z działającej aplikacji. Wygląd poszczególnych stron może być łatwo zmieniony poprzez zastosowanie akuszy stylów css i szablonów stron.

    Rys. Okno danych dotyczących węzła w podanej lokalizacji

    Rys. Okno ze spisem kabli ewidencjonowanych w systemie

    Rys. Okno edycji danych dotyczących kabla

    Rys. Okno edycji danych dotyczących szafy krosowniczej.

     

  7. Propozycje rozwoju
  8. Dostępny na chwilę obecną system implementuje podstawową funkcjonalność; trwają prace nad jej poszerzeniem. Wśród funkcji priorytetowych można wymienić autoryzację. Obecnie autoryzacja przeprowadzana jest przez serwer Apache. Każdy użytkownik po dokonaniu autoryzacji może korzystać ze wszystkich funkcji systemu, tj. nie tylko przeglądać, lecz także dodawać. modyfikować i usuwać informacje. Planowane jest oddzielenie funkcji przeglądania od funkcji związanych z zarządzaniem informacją. Kolejną pożądaną funkcją, choć już nie tak priorytetową, byłaby możliwość załączania do poszczególnych obiektów informacji multimedialnej w postaci cyfrowych zdjęć (schemat bazy LDAP uwzględnia te potrzeby).

  9. Podsumowanie
  10. Cel projektu to wdrożenia systemu informacji o usługach i zasobach POL-34 wykorzystującego bazę LDAP. Cel ten został osiągnięty. W implementacji uwzględnione zostały założenia projektowe z raportu "Projekt technik umożliwiających przechowywanie i gromadzenie w bazie LDAP informacji o zasobach POL-34/NASK : założenia ogólne i wymagania specyficzne w sieci POL-34".

    Implementacja systemu z użyciem technologii serwera aplikacji Jakarta Tomcat i servletów Java, mimo rozbudowanego drzewa danych bazy LDAP oraz licznych powiązań pomiędzy obiektami, umożliwia stosunkowo dobrą czytelność kodu oraz ułatwia pielęgnację oprogramowania i poszerzanie jego funkcjonalności. Ważną zaletą jest przenośność kodu. Serwer aplikacji Tomcat jak i system informacji o usługach i zasobach POL-34, jako aplikacje Java-y nie wymagają rekompilacji w przypadku wdrożenia na kolejnych serwerach. Jedyne wymagania to obecność wirtualnej maszyny Java na komputerze objętym wdrożeniem.