1. Wstęp Wprowadzenie Cel i zakres pracy Wymagania... 6

Transkrypt

1 1. Wstęp Wprowadzenie Cel i zakres pracy Wymagania Użyte protokoły internetowe Model OSI (Open System Interconnection) Transmission Control Protocol User Datagram Protocol Real-time Transport Protocol Opis wykorzystanych technologii Język programowania Java Hibernate framework Spring framework Java media framework Apache Maven Wybór narzędzi Netbeans IDE Power Designer System zarządzania relacyjnymi bazami danych Opis aplikacji Aplikacja serwerowa Aplikacja kliencka Projekt systemu Szyfrowanie DES (Data Encryption Standard) Szyfrowanie RSA Architektura systemu Wymagania funkcjonalne Diagram przypadków użycia Strona 1

2 8.6. Model fizyczny Tabela Department Tabela Employee Tabela ULevel Tabela Users Tabela Messages Tabela Conference Tabela Confdetails Tabela Rooms Tabela Task Tabela Reset_Password Activate_Account Wykonanie aplikacji serwerowej Uruchomienie serwera Przyjmowanie połączeń od klientów Bezpieczeństwo komunikacji między klientem a serwerem Dostęp do zasobów przez użytkownika niezalogowanego Dostęp do zasobów przez użytkownika zalogowanego Sprawdzanie połączenia pomiędzy klientem a serwerem Panel administratora Wysyłanie wiadomości Klasy mapujące Wykonanie aplikacji klienckiej Uruchomienie aplikacji klienckiej Część użytkownika niezalogowanego Rejestracja nowego użytkownika Aktywacja konta Zmiana hasła na nowe Część użytkownika zalogowanego Logowanie do systemu Zmiana statusu konta Interakcja z innymi użytkownikami Strona 2

3 Wiadomości nieodebrane Zadania definiowane przez użytkownika Archiwum wiadomości Zgłaszanie problemów administratorowi Prototyp audio konferencji Możliwość zmiany ustawień Podsumowanie Bibliografia Strona 3

4 1. Wstęp. W dzisiejszych czasach gdy cały świat pędzi do przodu każda sekunda naszego życia staje się niezwykle cenna. Sytuacja ta jest obecna w każdej dziedzinie naszego życia : naukowej, medycznej, przemysłowej itd. Zjawisko to jest najlepiej widoczne w firmach gdzie nieustannie szuka się rozwiązań, które przyczyniłyby się do szybszej komunikacji międzyludzkiej, czego odzwierciedleniem jest efektywniejsze wykorzystanie czasu pracy. Z uwagi na fakt, iż świat jest obecnie w stadium olbrzymiej informatyzacji, tak więc większość dostępnych rozwiązań związanych jest z tą dziedziną. Mając na uwadze powyższe wybierając temat mojej pracy inżynierskiej postanowiłem stworzyć komunikator internetowy dla podmiotów gospodarczych, który znacząco usprawni oraz przyspieszy komunikację pomiędzy pracownikami danej firmy. Ponadto moje oprogramowanie cechuje prostota obsługi i na pewno z jego użytkowaniem poradzi sobie każdy nawet najmniej zaawansowany odbiorca. Na rynku istnieje wiele komunikatorów takich jak : Gadu-Gadu, Skype, AQQ itd. jednakże większość z nich to komunikatory publiczne, czyli korzystające z serwerów zewnętrznych oraz skupiające dużą pulę osób z całego świata. Wadą powyższego rozwiązania jest brak kontroli nad bazą danych oraz niski stopień bezpieczeństwa przesyłanych informacji firmowych. Nie są to rozwiązania skierowane typowo dla przedsiębiorstw. Dlatego też stworzony przeze mnie program jest skierowany dla firm a dzięki temu, iż korzysta z serwera wewnątrz firmy gwarantuje pełną kontrolę nad informacjami przesyłanymi poprzez moją aplikację. Strona 4

5 2. Wprowadzenie Cel i zakres pracy. Na cel mojej pracy składają się trzy zadania. Pierwszym z nich jest zaprojektowanie oraz stworzenie aplikacji klienckiej, której głównym zadaniem będzie umożliwienie bezpiecznej wymiany danych pomiędzy pracownikami danej firmy. Ponadto aplikacja ta umożliwia zapis ważnych wydarzeń które zostaną automatycznie przypomniane użytkownikowi. Drugim zadaniem jest stworzenie wydajnej aplikacji serwerowej, która będzie pośrednikiem pomiędzy aplikacjami klienckimi. To znaczy, iż wszystkie informacje jakie zostaną wysłane przez użytkownika końcowego muszą przejść przez aplikacje serwerową. W mojej architekturze pełni on role drogowskazu. Trzecim celem jest ciągłe rozwijanie moich umiejętności związanych z programowaniem. Praca inżynierska została podzielona na 9 rozdziałów. Pierwszy rozdział to wstęp. W drugim zawarty jest krótki opis aplikacji wchodzących w skład mojej pracy dyplomowej oraz wymagania dotyczące ich funkcjonowania. W rozdziale trzecim opisałem protokoły internetowe które zostały użyte w moim oprogramowaniu. Część czwarta zawiera opis technologii użytych przy tworzeniu komunikatora internetowego natomiast w rozdziale piątym zawarte są informacje dotyczące narzędzi, które zostały użyte podczas tworzenia pracy. Część szósta dotyczy systemu w którym została stworzona baza danych natomiast rozdział siódmy zawiera szczegółowy opis aplikacji wchodzących w skład pracy inżynierskiej. Przedostatnia część poświęcona została na podsumowanie i wnioski wynikające z moich spostrzeżeń podczas pisania pracy dyplomowej. Ostatni rozdział zawiera spis materiałów dydaktycznych, które okazały się pomocne w czasie realizacji projektu. Strona 5

6 2.2. Wymagania. Do poprawnego funkcjonowania aplikacja serwerowa potrzebuje: Wirtualna maszyna Javy (Java Virtual Machine). Serwer bazy danych. Dostęp do internetu. Konto mailowe administratora. Obsługiwane systemy operacyjne: oprogramowanie jest wieloplatformowe. Aplikacja kliencka aby funkcjonować prawidłowo wymaga: Wirtualna maszyna Javy (Java Virtual Machine). Dostęp do internetu bądź dany komputer musi być w tej samej sieci komputerowej co aplikacja serwerowa. Zainstalowany Java Media Framework. Wolny port potrzebny do prawidłowego funkcjonowania audio konferencji. Obsługiwane systemy operacyjne: Windows oraz Linux z wbudowanym KDE (K Desktop Environment). Strona 6

7 3. Użyte protokoły internetowe. W rozdziale tym zawarłem podstawowe informacje dotyczące protokołów, które zostały wykorzystane w mojej pracy inżynierskiej Model OSI (Open System Interconnection). Z uwagi na fakt, iż protokoły, które zostaną niżej omówione wykorzystują model OSI, postanowiłem opisać podstawowe informacje na temat tego standardu. Poniżej został zamieszczony ogólny schemat niniejszego modelu: Jak możemy zauważyć w skład modelu OSI wchodzi siedem warstw, które ściśle ze sobą współpracują. Niniejszy model opisuje drogę danych z jednej aplikacji do innej aplikacji znajdującej się na innym komputerze. Pakiety, które mają zostać wysłane biorą udział w procesie nazywanym Enkapsulacją. Polega to na otaczaniu danych informacjami dotyczącymi protokołu. Dzięki czemu wraz z przemieszczaniem się danych przez kolejne warstwy modelu OSI, dodawane są ą informacje takie jak: Strona 7

8 nagłówki, stopki itp. Na rysunku Enkapsulacja została zaznaczona strzałką numer jeden. Jak widać dane są enkapsulowane zaczynając od warstwy aplikacji kończąc na warstwie fizycznej. W czasie gdy pakiety dotrą do hosta docelowego następuje proces nazywany deenkapsulacją. Jego celem jest skonwertowanie otrzymanych danych do postaci początkowej. Na rysunku de-enkapsulacja została oznaczona strzałką numer dwa. Dane są de-enkapsulowane zaczynając od warstwy fizycznej kończąc na warstwie aplikacji Transmission Control Protocol. Jest to protokół komunikacyjny między dwoma komputerami zorientowany połączeniowo. Oznacza to, iż przed wysłaniem jakichkolwiek danych z jednego urządzenia do drugiego musi nastąpić tak zwane rozpoczęcie sesji pomiędzy hostami. Połączenie to jest realizowane poprzez warstwę transportową. Protokół TCP działa w architekturze klient-serwer oznacza to, iż komputer, który jest serwerem czeka na połączenie na wybranym porcie. Inicjalizacja połączenia jest zadaniem klienta. Poniżej przedstawiłem schemat nawiązywania połączenia miedzy hostami: Powyższy rysunek przedstawia trzy zadania realizowane podczas ustanawiania sesji protokołu TCP. W pierwszym etapie host inicjalizujący połączenie wysyła segment danych z flagą SYN (synchronize). Jest to żądanie rozpoczęcia sesji miedzy komputerami. Następnie serwer odsyła segment TCP z ustawionymi flagami SYN Strona 8

9 oraz ACK (acknowledge). Flaga ACK ma za zadanie poinformować klienta, iż serwer przyjął żądanie ustanowienia sesji. Trzeci etap to wysłanie pierwszej porcji danych z ustawioną już tylko flaga ACK. Następna ważną cechą protokołu TCP jest retransmisja danych, które z różnych przyczyn nie dotarły do hosta docelowego. Komputer, który wysyła dane zobowiązany jest oczekiwać na potwierdzenie od hosta docelowego dotyczącego odebranych danych. Jeśli otrzyma takie potwierdzenie może przestać monitorować wysyłane przez niego dane. W przeciwnym wypadku zobligowany jest do retransmisji zagubionych pakietów. Niezawodność komunikacji uzyskiwana jest dzięki wprowadzeniu dodatkowego narzutu sieciowego związanego z generowaniem potwierdzeń oraz retransmisją danych. Zakończenie połączenia następuje poprzez wysłanie segmentu danych z ustawiona flagą FIN (finished). Sytuacja taka wymaga potwierdzenia poprzez ustawienie flagi ACK przez drugą stronę. Możliwe jest także awaryjne zakończenie połączenia poprzez wysłanie segmentu z ustawioną flaga RST (reset). Pakiet taki nie wymaga potwierdzenia. Poniżej zamieszczony został nagłówek ramki TCP wraz z opisem najważniejszych pól: Jak możemy zauważyć w skład nagłówka protokołu TCP wchodzą pola takie jak: Strona 9

10 Numer portu źródłowego - numer portu nadawcy. Numer portu docelowego - numer portu odbiorcy. Numer sekwencyjny - numer ostatniego bajtu w segmencie. Numer potwierdzenia - numer następnego bajtu oczekiwanego przez odbiorcę. Długość nagłówka - określa w bajtach rozmiar nagłówka. Flagi - informacja lub polecenie do dotycząca bieżącego pakietu. Rozmiar okna - ilość danych informująca ile danych może przyjąć odbiorca. Suma kontrolna TCP - kontrola błędów nagłówka i danych. Wskaźnik ważności - jeśli flaga URG została włączona, pole to informuje nas o ważności pakietu. Opcje - informacje opcjonalne. Dane - dane warstwy aplikacji. Protokół TCP znajduje zastosowanie wszędzie tam gdzie sprawą priorytetową jest dostarczenie wszystkich pakietów w kolejności, w której zostały wysłane oraz gdzie nie można sobie pozwolić nawet na najmniejszą stratę danych User Datagram Protocol. Jest to jeden z podstawowych protokołów służących do komunikacji w sieci zorientowany bezpołączeniowo co jest przeciwieństwem protokołu TCP. Oznacza to brak narzutu związanego z ustanawianiem połączenia miedzy hostami oraz brak monitorowania sesji. Idąc dalej protokół UDP nie oferuje mechanizmów retransmisji danych oraz porządkowania kiedy dotrą do hosta docelowego. Innymi słowy warstwa transportowa nie jest odpowiedzialna za każde z wyżej wymienionych zadań jak to miało miejsce w TCP. Nie oznacza to jednak, iż protokół UDP jest zawodny. Jeśli mechanizmy retransmisji lub porządkowania danych są wymagane muszą zostać zaimplementowane np. w aplikacji. Strona 10

11 Mówi się, że e protokół UDP jest protokołem transakcyjnym. Mówiąc inaczej jeśli aplikacja ma jakieś ś dane do wysłania po prostu to robi. Dane do wysłania dzielone są na datagramy. Jest to podstawowa jednostka danych w protokole UDP. W momencie kiedy trzeba podzielić jakiś ś segment danych na kilka data gramów istnieje ryzyko, iż dojdą one do celu w kolejności innej niż zostały wysłane. Tak samo jak w protokole TCP, aplikacje serwerowe mają ą przypisane porty, na których oczekują ą na datagramy. Korzyścią wynikającą z zastosowania protokołu UDP jest na pewno szybkość transmisji danych oraz brak wykonywania dodatkowych zadań ń jak to ma miejsce w TCP. Protokół UDP znajduje zastosowanie wszędzie tam gdzie możemy sobie pozwolić na małą utratę danych oraz wymagana jest bardzo szybka wymiana danych pomiędzy hostami. Są to: Wideokonferencje. Audiokonferencje (VoiP). Gry sieciowe. Poniżej zamieszczony został nagłówek ramki UDP wraz z opisem najważniejszych pól: Jak możemy zauważyć w skład nagłówka ramki UDP wchodzą ą pola takie jak: Port nadawcy - numer portu nadawcy. W przypadku braku użycia przyjmowana jest wartość 0. Port odbiorcy - numer portu odbiorcy. Strona 11

12 Długość - rozmiar całego datagramu określony w bajtach. Suma kontrolna - pole użyte do sprawdzenia poprawności nagłówka oraz danych. Jest gwarancją, że dane nie zostały uszkodzone podczas przesyłania pomiędzy hostami. Dane - dane warstwy aplikacji. Dzięki małemu narzutowi informacji kontrolnych jest on pożądany w powyższych aplikacjach Real-time Transport Protocol. Jest protokołem transmisji w czasie rzeczywistym. Przeważnie używa on protokołu UDP jako protokołu warstwy transportowej. Jest szeroko wykorzystywany w aplikacjach, które oferują opcje takie jak: Wideokonferencje. Audio konferencje. RTP sam w sobie nie gwarantuje jakości usług dlatego bardzo często jest używany z protokołami takimi jak: RTP Control Protocol, RTSP, SIP. Protokół RTP używa sesji dla każdego strumienia danych. Przykładowo w aplikacjach gdzie mamy do czynienia z wideokonferencjami strumienie danych audio i video będą przesyłane w osobnych sesjach. Każda sesja rozpoznawana jest po adresie IP oraz dwóch portach. Jeden port używany jest przez protokół RTP zaś drugi port przez protokół RTCP. RTP wspiera następujące rodzaje transmisji: Unicast jeden nadawca - jeden odbiorca. Multicast jeden nadawca - dowolna liczba odbiorców. Strona 12

13 4. Opis wykorzystanych technologii. Niniejszy rozdział poświęcony został do omówienia technologii, które zostały użyte podczas tworzenia mojej pracy dyplomowej. Możemy znaleźć tutaj także przykłady kodu źródłowego wraz z wytłumaczeniem Język programowania Java. Java to jeden z najpopularniejszych i najbardziej stosowanych języków programowania. Został stworzony przez firmę Sun Microsystems. Obecnie jest własnością firmy Oracle. Java jest obiektowym językiem programowania. Składnia tego języka przypomina składnie C++ i C. Ponadto Java to cała platforma programistyczna zawierająca mnóstwo gotowych do użycia bibliotek. Główne cechy Javy to: Prostota - została zaprojektowany tak aby umożliwić jak najszybsze przyswojenie składni przez programistę. Idąc dalej jeśli kiedykolwiek miało się do czynienia z C++ lub C wówczas możemy nauczyć się programować w Javie w bardzo krótkim okresie czasu. Dodatkowo istnieje całe multum framework ow mających na celu ułatwienie pracy programiście. Obiektowość - w Javie prawie wszystko jest obiektem. Ze względów wydajnościowych jedynym wyjątkiem są typy proste (int, double itd.). Każdy obiekt to tak jakby samoistna część programu cechująca się określonym zachowaniem oraz możliwość przyjmowania różnych stanów. W przeciwieństwie do C++, Java umożliwia dziedziczenie tylko po jednej klasie. Wprowadzono natomiast interfejsy (interface). Klasa może implementować nieograniczoną liczbę interfejsów. Solidność - dzięki tej zalecie programista piszący aplikacje w Javie nie musi się martwić o to, że popełni najczęstsze błędy programistyczne. Zostało to zrealizowane dzięki silnej typizacji tego języka oraz poprzez sprawdzanie kodu w trakcie wykonywania programu. Jeśli zdarzy się Strona 13

14 sytuacja, w której wystąpi błąd w czasie trwania programu wówczas zostanie wyłapany wyjątek, który programista może obsłużyć według własnego uznania. Kolejną zaletą jest tak zwany mechanizm zwalniania nieużywanej pamięci (Garbage Collector). Odciąża on programistę od ręcznego usuwania wcześniej przydzielonej pamięci. Wielowątkowość sam język udostępnia programiście profesjonalne mechanizmy dotyczące wielowątkowości. Jedynym zmartwieniem programisty zostaje odpowiednie zaprogramowanie zachowania programu. Wieloplatformowość sprawą priorytetową podczas projektowania Javy była przenośność kodu. Oznacza to, iż tworząc aplikacje nie musimy przejmować się czy uda nam się uruchomić ja na różnych systemach. Neutralność architektury została osiągnięta dzięki maszynie wirtualnej Javy (Java Virtual Machine). Maszyna wirtualna to interpreter kodu bajtowego, który cały kod źródłowy tłumaczy bezpośrednio do kodu bajtowego. Oznacza to, iż aby uruchomić aplikacje pod różnymi systemami operacyjnymi musimy zainstalować odpowiednią maszynę wirtualną. Wydajność - część programistów zarzuca Javie, iż jest powolna. Jednakże w dzisiejszych czasach maszyna wirtualna używa zaawansowany kompilator JIT (Just in time compilation). Dzięki wyżej wymienionej technice wydajność Javy nie odbiega od wydajności innych języków programowania. Rozproszenie - dzięki obsłudze protokołu TCP/IP, Java znajduje zastosowanie w rozproszonym środowisku internetowym. Dostęp do zasobu poprzez adres URL praktycznie nie różni się od dostępu do pliku. Dodatkowo możliwe jest zdalne wywoływanie metod znajdujących się na odległych komputerach (Remote Method Invocation). Dla lepszego zobrazowania składni języka Java, poniżej zamieszczam przykład prostej klasy: package user; import java.util.arraylist; Strona 14

15 import java.util.list; import miscellaneous.linepoint; public class UserPoints { private String name; private List<LinePoint> userpoints = new ArrayList<LinePoint>(); public UserPoints(String name, List<LinePoint> userpoints) { this.name = name; this.userpoints = userpoints; public String getname() { return name; public void setname(string name) { this.name = name; public List<LinePoint> getuserpoints() { return userpoints; public void setuserpoints(list<linepoint> userpoints) { this.userpoints = userpoints; Przeanalizujmy teraz wyżej pokazany przykład. Linia, w której widnieje package user; to nic innego jak pakiet. Innymi słowy pakiet to przestrzeń nazw. Dzięki temu może istnieć więcej klas o tej samej nazwie pod warunkiem, że będą znajdować się w innych pakietach. Następne trzy linijki służą do zaimportowania bibliotek, z których korzystamy. Idąc dalej mamy deklaracje klasy. Klasa ta zawiera dwa prywatne pola klasowe. Oznacza to, iż dostęp do tych pól możemy uzyskać jedynie przez tak zwane Strona 15

16 gettery i settery. Przykładowo za pomocą metody setname możemy ustawić wartość pola name. Jeśli chcemy pobrać wartość pola name musimy skorzystać z metody getname. Podczas tworzenia obiektu wywoływany jest konstruktor, który ustawia pola klasowe zgodne z przekazanymi argumentami Hibernate framework. Hibernate jest bogatą biblioteką służącą do realizacji warstwy dostępu do danych. Jego głównym zadaniem jest mapowanie obiektowo-relacyjne. Oznacza to iż tabele w relacyjnej bazie danych są odpowiednio mapowane na obiekty. Mapowanie relacyjnoobiektowe praktycznie całkowicie eliminuje problem żmudnego pisania kodu związanego z językiem zapytań jakim jest SQL. Następna bardzo ważną zaletą technologii Hibernate jest zwiększenie wydajności operacji, które są wykonywane na bazie danych poprzez buforowanie oraz minimalna liczbę zapytań, które są do niej kierowane. Idąc dalej dostęp do bazy danych w Hibernate odbywa się za pomocą specjalnych sterowników oraz dialektów SQL. Dzięki temu programista pisząc aplikacje nie musi się martwić o drobne różnice w składni w różnych systemów służących do zarządzania relacyjnymi bazami danych. Hibernate czyni nas kod uniwersalnym. Sytuacja ta przypomina trochę wieloplatformowość aplikacji napisanych w Javie. Kolejną cechą jest na pewno wsparcie dla zapytań przy pomocy kryteriów. Realizowane jest to za pośrednictwem specjalnych metod udostępnianych przez bibliotekę Hibernate. Prawdziwą potęgę kryteriów można zauważyć przy bardzo skomplikowanych zapytaniach do bazy danych. Bardzo ważną cechą jest fakt, iż Hibernate posiada swój własny wbudowany język zapytań HQL (Hibernate Query Language). Wszystkie zapytania wykonywane w HQL są kompatybilne z wszystkimi bazami danych, które obsługiwane są przez Hibernate. Strona 16

17 Wszystkie odwzorowania relacyjno-obiektowe trzymane są w specjalnych klasach zawierających adnotacje udostępniane przez bibliotekę wyżej wymienionej technologii. Innym wariantem są specjalne pliki xml. Dzięki temu oddzielamy logikę biznesową aplikacji od tych informacji. Warto również zauważyć, iż obecnie na rynku istnieje wiele narzędzi wspomagających pracę z Hibernate. Umożliwiają one automatyczne stworzenie obiektów z istniejących tabel w bazie danych bądź jeśli zajdzie potrzeba możemy stworzyć tabele na podstawie obiektów. Poniżej zamieszczony został schemat mapowania relacyjno-obiektowego na przykładzie tabeli Activate_Account :. Jednym z najważniejszych plików jest plik konfiguracyjny Hibernate, który zawiera w sobie informacje dotyczące bazy danych takie jak: dialekt SQL, sterownik do łączenia, adres URL, pod którym dostępna jest baza danych dla aplikacji, nazwa użytkownika oraz hasło. Ponadto zawiera on także ścieżki do plików xml, które są odwzorowaniami poszczególnych tabel. Zawartość plików xml to nic innego jak poszczególne pola wraz z ich właściwościami odnoszące się do pól w naszej tabeli. Ostatnim plikiem, który jest potrzebny do mapowania relacyjno-obiektowego jest Hibernate Reveng (Hibernate reverse engineering). Używany jest po to by zapewnić odpowiednią konwersję z typów języka SQL do typów używanych przez Hibernate. Efektem końcowym mapowania relacyjno-obiektowego jest powstanie zwykłej klasy Javy, która zawiera takie same pola jak tabela w bazie danych. Hibernate użyty np. z Spring framework potrafi znacząco przyspieszyć oraz zredukować liczbę zadań związanych z bazą danych w naszej aplikacji. W przypadku użycia odpowiednich narzędzi programistycznych takich jak np. Netbeans IDE, powyższe pliki generowane są automatycznie co pozwala zaoszczędzić Strona 17

18 programiście mnóstwo czasu. Poniżej znajduje się przykładowa klasa wygenerowana na podstawie mapowania relacyjno-obiektowego: package mapping; import javax.persistence.column; import javax.persistence.entity; import javax.persistence.id; ) public class ActivateAccount implements java.io.serializable { private int idactivation; private String code; private Integer iduser; public ActivateAccount() { public ActivateAccount(int idactivation) { this.idactivation = idactivation; public ActivateAccount(String code, Integer iduser) { this.code = code; this.iduser = iduser; Strona 18

19 unique=true, nullable=false) public int getidactivation() { return this.idactivation; public void setidactivation(int idactivation) { this.idactivation = length=5) public String getcode() { return this.code; public void setcode(string code) { this.code = public Integer getiduser() { return this.iduser; public void setiduser(integer iduser) { this.iduser = iduser; Jak widać jest to zwykła klasa Javy zawierająca identyczne pola jak te w tabeli w bazie danych. Ponadto posiada ona adnotacje wiążące pola klasowe z polami w tabeli. Strona 19

20 4.3. Spring framework. Spring framework jest szkieletem do tworzenia aplikacji w języku Java. Głównym celem podczas projektowania i tworzenia Spring a było sprawienie by pisanie aplikacji na platformę Java EE było prostsze. Staje się to bardzo widoczne jeśli weźmiemy pod uwage pierwszą wersje Spring a, w której głównym narzędziem do budowy aplikacji były komponenty EJB 2.1 (Enterprise JavaBean). Ich główną wadą było to, że zmuszały programistę do uzależnienia się od konkretnej specyfikacji, kontenera oraz serwera aplikacji. Inną wadą jest to, iż EJB wymaga dużego nakładu zasobów oraz złożonej architektury. Dlatego podczas tworzenia twórcy postanowili uprościć framework czego skutkiem jest zwiększona wydajność, bezpieczeństwo oraz skrócenie czasu podczas tworzenia aplikacji. Głównym aspektem Spring a jest tak zwane odwrócenie sterowania (Inversion of Control). Jest to bazowane na specyfikacji JavaBeans zarządzanie konfiguracją. Z IoC często kojarzone jest tak zwane wstrzykiwanie zależności (Dependency Injection). Dependency Injection usuwa wszelkie zależności pomiędzy komponentami. Oferuje za to architekturę plug-in, w której w dowolnym czasie możemy wstrzyknąć do aplikacji potrzebny nam obiekt. Trzeba podkreślić, iż wstrzykujemy obiekty, które żyją w kontenerze co oznacza, iż obiekty te zapamiętują swój stan. W dotyczącym Hibernate a wspomniałem, iż jeśli połączymy go z Spring iem wówczas znacząco przyspieszymy tworzenie aplikacji. Dlatego też zdecydowałem się połączyć te dwie technologie. W mojej aplikacji Spring odpowiedzialny jest za dwa zadania. Pierwszym z nich jest dostęp do danych za pomocą DAO (Data Access Object). Drugim jest przechowanie najczęściej używanych obiektów. Wszystkie obiekty DAO wraz z innymi beanami muszą zostać zadeklarowane w pliku konfiguracyjnym Spring a. Następnie aby powołać do życia wszystkie obiekty musimy załadować kontekst. Poniższy linia kodu pokazuje jak możemy to uczynić: ctx = new ClassPathXmlApplicationContext("beans.xml"); Zmienna ctx widoczna w powyższym przykładzie jest interfejsem typu ApplicationContext. Przekazany argument przy tworzeniu tej zmiennej to ścieżka do pliku konfiguracyjnego Spring a, który zostanie pokazany w dalszych rozdziałach. Strona 20

21 Jeśli mamy już zainicjalizowany kontekst wówczas możemy za jego pośrednictwem w danej chwili wczytać jakiegoś bean a, co zostało pokazane poniżej: RoomDao roomsdao = ctx.getbean("roomsdao", RoomDao.class); Jak widać wczytywanie obiektów z kontekstu jest niezwykle proste a w dodatku bardzo wygodne Java media framework. JMF jest biblioteką Javy należącą do J2SE (Java Standard Edition). Udostępnia ona kilkadziesiąt klas i interfejsów służących do dodawania i obsługiwania multimediów w aplikacjach tworzonych w języku Java. Za pomocą JMF możemy odtwarzać pliki audio lub video umieszczane w aplikacjach desktopowych bądź webowych (za pośrednictwem Apletów). Dodatkowo mamy możliwość przychwytywania audio lub video w czasie rzeczywistym. Możemy te dane zachować do pliku bądź wysłać do innych hostów przy użyciu protokołu RTP. JMF daje nam możliwość wyboru kodeków oraz wykonywania różnych operacji na wyżej wymienionych danych. Poniżej zamieszczam fragment kodu wykorzystujący Java Media Framework. soundplayer = Manager.createRealizedPlayer (new URL("file:///" + userdir + filename)); soundplayer.start(); Powyższe dwie linie kodu umożliwiają odtworzenie pliku multimedialnego w aplikacji. Manager jest jedną z najważniejszych klas w całym JMF. W powyższym przykładzie inicjalizuje ona zmienną soundplayer na podstawie przekazanego adresu URL. Idąc dalej następuje wywołanie metody start(), która ma za zadanie odtworzyć plik multimedialny. Odtwarzanie wszelkich plików multimedialnych odbywa się za pomocą metod zawartych w interfejsie Player. Strona 21

22 4.5. Apache Maven. Przeznaczeniem Maven a jest automatyzacja budowy oprogramowania na platformę Java. Wszystkie funkcjonalności realizowane są za pośrednictwem specjalnych wtyczek, które przy pierwszym użyciu pobierane są z specjalnie wyznaczonych do tego repozytoriów. Każdy projekt stworzony za pośrednictwem Maven a posiada tak zwany Project Object Model (POM). POM jest plikiem xml, który nie tylko precyzuje podstawowe szczegóły budowania projektu ale może np. przechowywać informacje dotyczące pracowników pracujących nad rozwojem oprogramowania. Wszelkie operacje związane z konfiguracja projektu wywołujemy w pliku POM. Maven zawiera główny cykl życia projektu, w które skład wchodzą następujące punkty: Validate - jest to faza projektu, w której następuje sprawdzenie poprawności projektu oraz informacji potrzebnych do dalszych etapów. Compile - w tym punkcie następuje skompilowanie plików z kodem źródłowym. Test - faza ta odpowiedzialna jest za przeprowadzenie testów jednostkowych o ile takie zostały zlecone. Package - jest to faza budowania projektu. Oznacza to umieszczenie wszystkich plików, które zostały skompilowane w np. pliku JAR. Integration-test - w punkcie tym następuje wykonanie testów integracyjnych. Verify - sprawdzenie poprawności np. pliku JAR. Install - faza, w której następuje umieszczenie np. pliku JAR w lokalnym repozytorium. Oznacza to, iż może być używana przez inne projekty na zasadzie zależności dodawanych do pliku POM. Deploy - ostatnia faza projektu, w której umieszcza się np. plik JAR w zdalnym repozytorium. Dodatkową funkcjonalnością Apache Mavena jest generowanie raportów w skład których wchodzą: kody źródłowe, dokumenty Javadoc (dokumentacja klas) itd. Strona 22

23 5. Wybór narzędzi. Niniejszy rozdział poświecony został omówieniu narzędzi programistycznych, których użyłem podczas tworzenia mojej pracy inżynierskiej Netbeans IDE. Netbeans IDE jest środowiskiem programistycznym do tworzenia aplikacji na różne platformy. Głównym celem Netbeans a jest przyspieszenie budowy aplikacji. Niewątpliwie jego zaletą jest stabilność oraz dopracowanie pod każdym kątem. Dzięki możliwości doinstalowania wtyczek możemy w każdej chwili rozszerzyć dostępne funkcje. Netbeans a cechuje na pewno bardzo przyjazny interfejs graficzny użytkownika. Umożliwia on tworzenie aplikacji desktopowych, webowych lub mobilnych. Przy tworzeniu projektów możemy wykorzystać specjalnie przygotowane wizualne edytory służące np. do projektowania graficznego interfejsu użytkownika, który zostanie automatycznie powiązany z odpowiednimi procedurami. Podstawowa wersja Netbeans a oferuje wbudowane serwery bazo-danowe takie jak: Java Derby lub MySQL. Oczywiście nic nie stoi na przeszkodzie aby używać innych baz danych jednakże do tego wymagana jest prosta konfiguracja. Ponadto Netbeans oferuje także wbudowane serwery aplikacji takie jak: Glassfish lub Tomcat. Oczywiście istnieje także wsparcie dla innych serwerów. Kolejną bardzo ważną cechą jest na pewno wsparcie dla pracy grupowej poprzez integracje projektów z systemami kontroli wersji takimi jak: Subversion, Concurrent Versions System lub GIT. Dodatkowo w Internecie istnieje całe multum różnych poradników do Netbeans a co z pewnością ucieszy nowych użytkowników tego środowiska programistycznego. Poniżej zamieściłem obrazek Netbeans a, który został wykonany podczas pisania mojej pracy inżynierskiej. Strona 23

24 Jak możemy zauważyć interfejs graficzny Netbeans a jest prosty i intuicyjny co jest bardzo ważne w przypadku doświadczonych jak i początkujących deweloperów Power Designer. Power Designer jest narzędziem stworzonym przez firmę Sybase, które zastosowanie znajduje w modelowaniu i projektowaniu systemów. Dzięki użyciu zaawansowanych technologii czas wytworzenia aplikacji jest znacząco przyspieszony. Dodatkowo zawiera wbudowane funkcje obsługujące większość systemów do zarządzania relacyjnymi bazami danych. W skład narzędzi służących do modelowania wchodzą następujące techniki: modelowanie z użyciem języka UML oraz modelowanie procesów dotyczących biznesu. Strona 24

25 Głównymi cechami Power Designer a są: Szczegółowe zarządzanie wymaganiami. Automatyczne generowanie dokumentacji projektu. Przeprowadzenie analizy wpływu na poziomie całego przedsiębiorstwa. Obsługa większości popularnych platform programowania i serwerów aplikacji. Dzięki niesamowitej elastyczności wprowadzania zmian w projekcie Power Designer jest jednym z najlepszych narzędzi w odniesieniu do wymagań klientów. Dostęp do modeli danych poprzez interfejs WWW. Wsparcie dla pracy grupowej zrealizowane poprzez wprowadzenie repozytorium. Funkcja importu danych z innych narzędzi. Dodatkowo Power Designer a cechuje prosty i intuicyjny graficzny interfejs użytkownika. Poniżej zamieszczam rysunek ukazujący graficzny interfejs użytkownika: W rozdziale 8 pokazany zostanie diagram przypadków użycia. Strona 25

26 6. System zarządzania relacyjnymi bazami danych. Rozdział ten zawiera omówienie systemów zarządzania relacyjnymi bazami danych, które docelowo mogą współpracować z moją aplikacją. Dzięki zastosowaniu Hibernate framework moje oprogramowanie może wykorzystywać bazy danych takie jak: MySQL - jest własnością firmy Oracle. Oprócz tego, iż jest szybkim oraz solidnym systemem do zarządzania relacyjnymi bazami danych, jest serwerem wielowątkowym i wielodostępnym. Wykorzystuje język zapytań SQL. Jest dostępny w dwóch licencjach: GPL(Open Source) oraz komercyjnej. Głównymi zaletami MySQL są: łatwość konfiguracji, przenośność, wysoka wydajność oraz dostępność kodu źródłowego. Apache Derby - jest projektem rozwijanym przez Apache Software Foundation. Została w całości napisana w języku programowania Java oraz jej przeznaczeniem są aplikacje napisane także w Javie. Dostępna pod licencją Apache License 2.0. Używa SQL jako języka zapytań. Umożliwia wbudowanie bazy danych całkowicie w aplikacje lub po prostu oferuje łączenie z bazą danych za pomocą połączenia klient-serwer. Dodatkowo jest bardzo prosta w obsłudze oraz instalacji. Oracle Database została stworzona przez firmę Oracle. Niewątpliwie jest to jeden z najlepszych systemów do zarządzania relacyjnymi bazami danych. Stanowi idealny wybór dla aplikacji, które w dużym stopniu wykorzystują bazy danych. Wykorzystuje język zapytań SQL. Dodatkowo posiada wbudowany język do tworzenia procedur składowanych PL/SQL. Począwszy od wersji 8i do tworzenia wyżej wymienionych procedur można używać języka Java. Oczywiście istnieje dużo więcej systemów do zarządzania relacyjnymi bazami, które można by bez problemów użyć w moim oprogramowaniu jednakże postanowiłem, iż wymienić tylko kilka z nich. W mojej pracy użyłem Apache Derby z powodów czysto programistycznych. Dzięki temu, iż Netbeans IDE posiada wbudowane opcje dotyczące zarządzania bazami Strona 26

27 danych stworzonymi w Apache Derby zaoszczędziłem mnóstwo czasu podczas rozwoju aplikacji. 7. Opis aplikacji. Rozdział ten zawiera ogólny opis aplikacji wraz z ich przeznaczeniem. Dodatkowo zostały zamieszczone tutaj obrazki ukazujące graficzny interfejs użytkownika Aplikacja serwerowa. Przeznaczeniem aplikacji serwerowej jest zarządzać żądaniami i ruchem generowanym przez klientów. Aplikacja została napisana pod konsole dzięki czemu jest w pełni wieloplatformowa. Została przeznaczona tylko i wyłącznie do użytku administratora. Proces uruchomienia aplikacji serwerowej jest niezwykle prosty wymaga jedynie otworzenia konsoli, przejścia do katalogu w którym znajduje się plik JJServer.jar i wykonanie następującej komendy java -jar JJServer.jar. Dodatkowo zanim wykonamy wyżej wymienioną komendę musimy uruchomić serwer bazodanowy aby nasza aplikacja miała dostęp do bazy danych. Dodatkowo komputer, na którym znajduje się aplikacja musi mieć dostęp do internetu. Jeśli wszystko pójdzie dobrze powinniśmy otrzymać kilka komunikatów informujących nas o statusie serwera, które zostały pokazane na poniższym obrazku: Jak widać wszystkie czynności zostały przeprowadzone prawidłowo. Serwer od tej pory nasłuchuje na wybranym porcie w tym przypadku W tym momencie dostępne są trzy opcje takie jak: 0 - wyłączenie serwera. 1 - zmiana pliku konfiguracyjnego. Strona 27

28 2 - zalogowanie do panelu administratora. W momencie gdy nastąpi autoryzacja administratora pojawią się dodatkowe operacje. W przypadku błędnych danych potrzebnych do logowania wyświetlony zostanie odpowiedni komunikat. Operacje dostępne po zalogowaniu ukazuje poniższy obrazek: Po udanej autoryzacji do systemu administrator ma możliwość wykonać dodatkowe opcje takie jak: 3 - dodać nowy dział. 4 - usunąć dział. 5 - wyświetlić dane osobowe pracowników. 6 - wyświetlić informacje dotyczące działów w firmie. 7 - usunąć pracownika. W rozdziale dotyczącym wykonania aplikacji serwerowej powyższe opcje zostaną opisane dokładniej. W przypadku gdyby coś poszło nie tak podczas uruchamiania serwera wyświetlony zostanie odpowiedni komunikat. Strona 28

29 7.2. Aplikacja kliencka. Główną zaleta aplikacji klienckiej jest na pewno znaczne usprawnienie komunikacji pomiędzy pracownikami danej firmy. Zrealizowane to zostało za pośrednictwem funkcjonalności takich jak: Rozmowy tekstowe z innymi użytkownikami. Możliwość stworzenia konferencji tekstowej. Audio-konferencje pomiędzy pracownikami w specjalnie przygotowanych do tego pokojach (jest to prototyp). Dodatkowo komunikator udostępnia funkcjonalność, która pozwala użytkownikowi zapisać jakieś ważne zdarzenie w bazie danych. Następnie gdy nadejdzie dany dzień, pod którym zapisano zdarzenie zostanie ono automatycznie przypomniane. Ponadto niniejsza aplikacja umożliwia rysowanie w czasie rzeczywistym pomiędzy pracownikami, dzięki czemu użytkownicy mogą wyrazić swoje zdanie na określony temat gdy zwykłe wiadomości tekstowe zawiodą. Co więcej komunikator posiada wbudowane archiwum wiadomości, które umożliwia przeglądanie informacji wymienianych między danymi pracownikami w przeszłości. Z uwagi na fakt, iż dane te są cennymi i pewnie niektóre z nich tajnymi informacjami firmy dostęp do nich ma tylko użytkownik, który pomyślnie zaloguje się do systemu, dzięki czemu dane te są bezpieczne. Dodatkowo zachowanie aplikacji klienckiej można dopasować do swoich własnych potrzeb poprzez włączenie lub wyłączenie różnych opcji. W rozdziale, który został poświęcony na wykonanie aplikacji klienckiej zamieszczony zostanie szczegółowy opis dotyczący wykonania różnych funkcjonalności wraz z przykładowymi obrazkami i kodem. Na następnej stronie zamieszczony został obrazek ukazujący ogólny wygląd aplikacji klienckiej. Jak będziemy mogli zauważyć główne okno aplikacji klienckiej zostało zaprojektowane w taki sposób aby było intuicyjne dla każdego użytkownika nawet tego najmniej zaawansowanego. Dlatego też jeśli kiedykolwiek mieliśmy styczność z jakimś komunikatorem internetowym wówczas użytkowanie mojego komunikatora nie powinno stanowić dla nas problemu. Strona 29

30 Jak widzimy interfejs graficzny użytkownika jest bardzo przyjazny i przejrzysty. Całość została podzielona na 5 głównych części takich jak: Menu - dzięki temu mamy dostęp do archiwum wiadomości, opcji komunikatora jak i specjalnego panelu, przez który możemy zgłaszać błędy w działaniu aplikacji administratorowi. Kontakty - w tej części mamy możliwość zmiany statusu naszego konta na online lub offline. Status ten widoczny będzie widoczny dla innych użytkowników. Następnie możemy zwinąć lub rozwinąć listę użytkowników posortowaną według działów, do których należą. Jak widzimy użytkownicy, którzy są dostępni maja zielone tło panelu zaś niezalogowani maja szare tło panelu. Wiadomości nieodebrane - w tej sekcji wyświetlane są wiadomości nieodebrane, które zostały przysłane w czasie gdy dany użytkownik był niezalogowany. Wiadomości te możemy wyświetlić bądź usunąć. Zadania użytkownika - jest to część aplikacji poświęcona na wyświetlanie, dodawanie i sortowanie zadań zdefiniowanych przez użytkownika. Strona 30

31 Pokoje do audio konferencji - jest to sekcja poświecona na pokoje w których możemy rozmawiać z innymi pracownikami. Aktualnie jest to prototyp nad którym będę pracował. 8. Projekt systemu. Niniejszy rozdział zawiera projekt systemu na podstawie, którego powstała moja praca. Zawiera on między innymi omówienie architektury systemu, wymagania funkcjonalne, model fizyczny bazy danych oraz tabele wchodzące w skład tego modelu wraz z przykładowymi danymi. W rozdziale tym pojawią się także zagadnienia dotyczące informacji przesyłanych pomiędzy klientem i serwerem, dlatego też pierwsze dwa podrozdziały poświęcone są na opis standardów, które zostały użyte w mojej pracy do zapewnienia bezpieczeństwa Szyfrowanie DES (Data Encryption Standard). Jest to jeden z najpopularniejszych algorytmów szyfrowania danych. DES został zaprojektowany w latach siedemdziesiątych w firmie IBM. Jest symetrycznym szyfrem blokowym, którego zasada działania opiera się na 56-bitowym tajnym kluczu służącym do szyfrowania i deszyfrowania danych. Dane, które maja być zaszyfrowane dzielone są na 64-bitowe bloki, na których następnie wykonuje się kilka do kilkanaście operacji, podczas których dane ulegają wielokrotnym przeobrażeniom. Ponieważ DES jest symetrycznym algorytmem szyfrowania wówczas do szyfrowania i deszyfrowania danych stosowany jest jeden klucz, który musi być znany aplikacji szyfrującej jak i deszyfrującej. Deszyfrowanie wiadomości polega na wykonaniu operacji w odwrotnej kolejności niż przy szyfrowaniu. Tajny klucz DES wybierany jest losowo spośród 72 kwadrylionów możliwości. Strona 31

32 8.2. Szyfrowanie RSA. Jest również jednym z najpopularniejszych asymetrycznych algorytmów służących do szyfrowania danych. Stworzony został w roku 1977 przez Rona Rivesta, Adi Shamira oraz Leonarda Adlemana. Stąd też wywodzi się nazwa - od pierwszych liter ich nazwisk. Obecnie znajduje zastosowanie w szyfrowaniu danych oraz podpisach cyfrowych. Bezpieczeństwo szyfrowania tym algorytmem polega na rozkładzie na czynniki pierwsze dużych liczb złożonych. W przeciwieństwie do DES a używa dwóch kluczy: prywatny i publiczny. Klucz publiczny służy do szyfrowania danych. Natomiast zadaniem klucza prywatnego jest deszyfrowanie danych. Klucze są generowane w taki sposób aby odtworzenie klucza prywatnego na podstawie publicznego było bardzo trudne. Ponadto klucz prywatny znany jest tylko aplikacji, która chce deszyfrować dane natomiast klucz publiczny znany jest każdemu kto chce szyfrować dane. Ponieważ szyfrowanie asymetryczne jest dużo powolniejsze od szyfrowania symetrycznego, mało jest przypadków gdzie szyfrowanie danych odbywa się na zasadzie szyfrowania za pomocą algorytmów takich jak np. RSA. Zamiast tego krypto-systemy asymetryczne stosuje się przeważnie do zaszyfrowania klucza jakiegoś szyfru symetrycznego np. DES Architektura systemu. Zaprojektowanie systemu klient-serwer było jedną z najważniejszych rzeczy do wykonania, uwzględniając to, iż aplikacja ma cechować się wydajnością, skalowalnością i bezpieczeństwem. Dzięki zastosowaniu mechanizmów programowania wielowątkowego aplikacja serwerowa umożliwia obsługę wielu klientów w tym samym czasie. Maksymalna liczba klientów jest zależna od parametrów komputera, na którym w danej chwili działa. Ponadto architektura została zaprojektowana w taki sposób aby w przyszłości było możliwe dalsze Strona 32

33 rozbudowywanie jej poprzez dodawanie nowych modułów, które w żaden sposób nie zakłócą działań funkcjonalności już istniejących. Poniżej zamieszczony jest ogólny schemat architektury mojej aplikacji: Jak widać na obrazku powyżej głównym elementem, który niejako staje się mózgiem mojej aplikacji jest serwer. Komunikacja między klientem a serwerem odbywa się przy pomocy protokołu TCP/IP. W architekturze tej serwer jest pasywna aplikacją oznacza to, iż oczekuje na żądania klientów. Jeśli takie żądania zostaną odebrane wówczas następuje ich przetwarzanie. Przykładowo każda wiadomość tekstowa wysłana przez klienta zostaje przetworzona przez serwer, który odsyła ją do hosta docelowego. Dzięki zastosowaniu takiej architektury wszystkie wrażliwe dane są przetrzymywane na serwerze, które takim sposobem można zabezpieczyć w lepszy sposób. To serwer decyduje kto może uzyskać dostęp do takich danych. Tylko i wyłącznie za jego pośrednictwem możliwy jest zapis, edytowanie, wyciąganie i Strona 33

34 usuwanie danych w bazie danych. Rozwiązanie to uniemożliwia aplikacjom klienckim bezpośredni dostęp do bazy danych, co znacznie utrudnia możliwość przejęcia wrażliwych danych przez osoby trzecie. Komunikacja pomiędzy klientem i serwer została zabezpieczona przez użycie szyfrowań DES i RSA, dzięki czemu dane firmowe przesyłane pomiędzy pracownikami w firmie stają się bezpieczne. Jest to ogólny opis architektury mojego systemu, który zostanie opisywany szczegółowo w następnym rozdziale Wymagania funkcjonalne. W podrozdziale tym opisałem wymagania funkcjonalne jakie oferuje moje oprogramowanie. System umożliwia: Przed zalogowaniem pracownika: Rejestracja nowego użytkownika. Aktywacja konta użytkownika. Zmiana hasła na nowe. Po zalogowaniu pracownika: Możliwość zmiany statusu użytkownika na online (zalogowany) bądź offline (niezalogowany). Wyświetlenie listy kontaktów pracowników firmy posortowanych według działów wraz z ich statusem. Możliwość wysyłania wiadomości do innego pracownika. Konferencje tekstowe, w których udział brać mogą więcej niż dwie osoby. Skrzynka odbiorcza wiadomości nieodebranych. Archiwizowanie wiadomości. Rysowanie w czasie rzeczywistym na specjalnie wyznaczonym do tego panelu podczas rozmowy tekstowej. Możliwość dodawania zadań na określony dzień, które zostaną przypomniane przez oprogramowanie kiedy nadejdzie odpowiednia data. Sortowanie wyświetlonych zadań na podstawie przedziału czasowego. Strona 34

35 Usuwanie zadań. Dostosowanie aplikacji do indywidualnych wymagań. Kontakt z osobą odpowiedzialną za aplikacje poprzez wysłanie wiadomości na adres administratora. Audio konferencje w specjalnie wyznaczonych do tego pokojach (jest to prototyp). Zakładanie nowych pokoi do audio konferencji. Usuwanie istniejących pokoi audio konferencyjnych. Osoba, która założy pokój staje się jego administratorem, który może otworzyć lub zamknąć pokój. Dodatkowo ma prawo wyrzucić użytkowników kiedy uzna, że są nieproszeni. Po zalogowaniu administratora: Wyświetlenie listy działów firmy. Możliwość usunięcia działu. Dodanie nowego działu. Wyświetlenie danych osobowych pracowników. Możliwość usunięcia pracownika. Strona 35

36 8.5. Diagram przypadków użycia. Poniżej zamieszczony został diagram przypadków użycia mojego systemu wykonany w Power Designerze: Strona 36

37 Jak możemy zauważyć na diagramie przypadków użycia, użytkowników w moim systemie podzielono na dwie grupy: administratora i pracownika. Administrator po zalogowaniu do systemu może: Wyświetlić listę z informacjami dotyczącymi działów w firmie. Dodać nowy dział. Usunąć już istniejący dział. Wyświetlić dane osobowe pracowników. Usunąć pracownika. Pracownik przed zalogowaniem do systemu może: Stworzyć nowe konto. Jeden pracownik może posiadać tylko i wyłącznie jedno konto. Aktywować konto za pośrednictwem specjalnego kodu uzyskanego podczas rejestracji konta. Zmienić hasło na nowe poprzez specjalny kod uzyskany od systemu. Po zalogowaniu do systemu użytkownik może: Zmienić status swojego konta na online lub offline. Status ten widoczny jest dla innych użytkowników systemu. Wyświetlić listę kontaktów posortowaną według listy działów. Zarządzać wiadomościami nieodebranymi poprzez ich wyświetlenie bądź usunięcie. Komunikować się z innymi pracownikami za pośrednictwem rozmów tekstowych i audio-konferencji. Możliwość zmiany ustawień komunikatora według własnych potrzeb. Zadawanie pytań bądź zgłaszanie problemów administratorowi za pośrednictwem specjalnego panelu. Przeglądanie wiadomości archiwalnych posortowanych według pracowników i daty. Zarządzanie zadaniami wyznaczonymi przez pracownika. Użytkownik ma możliwość zakładania, usuwania i sortowania zadań. Zarządzanie pokojami do audio-konferencji. Użytkownik może zakładać, usuwać, zamykać pokoje, które stworzył. Ponadto ma możliwość dołączenia do innych pokoi. Strona 37

38 8.6. Model fizyczny. Poniżej został zamieszczony model fizyczny bazy danych obrazujący powiązania pomiędzy tabelami: Jak widać w skład mojego modelu fizycznego wchodzi jedenaście tabel. W kolejnych podrozdziałach zostaną omówione wyżej pokazane tabele wraz z omówieniem i przykładowymi danymi. Strona 38

39 8.7. Tabela Department. firmy. W tabeli Department przechowywane są informacje dotyczące działów danej Poniższy rysunek ukazuje przykładowe dane zawarte w niniejszej tabeli: Jak widać na rysunku powyżej tabela Department składa się z dwóch pól. Pole o nazwie NAME przechowuje nazwę działu natomiast pole ID_DEPT jest unikalnym kluczem głównym wymaganym przy łączeniu z inną tabelą Tabela Employee. W tabeli Employee przechowywane są informacje dotyczące danych osobowych pracowników firmy. Poniżej zamieszczony jest obrazek z przykładowymi danymi tej tabeli: Jak można zauważyć na rysunku powyżej w skład tabeli Employee wchodzą pola takie jak: ID_EMP - unikalny klucz główny wiersza. NAME - komórka danych gdzie przechowywane jest imię pracownika. SURNAME - w tej kolumnie przechowywane jest nazwisko pracownika. PESEL w tym polu przechowywany jest pesel pracownika. Strona 39

40 PHONE - kolumna ta przechowuje informacje o numerze telefonu do pracownika. OCCUPATION - niniejsza komórka danych odpowiada za przechowywanie informacji o stanowisku pracownika. ID_DEPT - jest to powiązanie z tabelą Department. Pole to przechowuje informacje na temat działu pracownika Tabela ULevel. W tabeli ULevel przechowywane są informacje na temat praw użytkowników. Poniżej zamieściłem rysunek z przykładowymi danymi: W skład tej tabeli wchodzą dwa pola. Pierwszym z nich jest ID_LEVEL, które przechowuje unikalny klucz główny. Natomiast pole NAME przetrzymuje nazwę prawa Tabela Users. Niewątpliwie jest to najważniejsza tabela w mojej bazie danych. Zawiera informacje dotyczące kont użytkowników mojej aplikacji. Jest powiązana z kilkoma innymi tabelami. Poniżej rysunek z przykładowymi danymi: Strona 40

41 Jak możemy zaobserwować w skład tej tabeli wchodzą między innymi pola takie jak: ACCOUNT_NUMBER - przechowuje login użytkownika potrzebny podczas logowania do systemu. PASSWORD pole to przechowuje hasła użytkowników. Wszystkie hasła ze względów bezpieczeństwa zostały zaszyfrowane. Niezbędne podczas autoryzacji do systemu. - kolumna ta przechowuje adres użytkownika potrzebny do rejestracji konta oraz do uzyskania nowego hasła do systemu. Reszta pól stanowi powiązania z innymi tabelami jak i klucz główny Tabela Messages. Niniejsza tabela przechowuje informacje dotyczące wiadomości tekstowych przesyłanych pomiędzy dwoma użytkownikami systemu. Poniżej został zamieszczony rysunek z przykładowymi danymi: Najważniejszymi polami w tej tabeli są: TRESC - zawiera treść wiadomości tekstowej. SENT - pole, które informuje czy dana wiadomość została wysłana do użytkownika. Jeśli tak to wartość ustawiana jest na 1 w przeciwnym wypadku na 0. FROMW - pole powiązane z tabelą Users. Dotyczy użytkownika, który wysłał daną wiadomość. TOW - powiązanie z tabelą Users. Dotyczy użytkownika, do którego została wysłana wiadomość. DATETIME - przechowuje datę wysłania wiadomości. Strona 41

42 8.12. Tabela Conference. Tabela ta zawiera dane dotyczące wiadomości tekstowych wysyłanych podczas konferencji między użytkownikami systemu. Zamieszczony niżej rysunek pokazuje przykładowe dane: Jak możemy zauważyć tabela ta zawiera pole TRESC, w którym przechowywane są wysłane wiadomości. Pole FROMW jest powiązaniem z tabela Users. Zawiera informacje dotyczące nadawcy. Następne pole DATETIME przechowuje datę wysłania wiadomości Tabela Confdetails. W tabeli tej przechowywane są informacje dotyczące odbiorców konferencji między użytkownikami systemu. Jest ona bezpośrednio powiązana z tabelą Conference. Poniższy rysunek pokazuje przykładowe dane przechowywane w tabeli Confdetails: Jak możemy zaobserwować w skład wyżej pokazanej tabeli wchodzą cztery pola. Pole TOW jest powiązaniem z tabelą Users. Dotyczy informacji o odbiorcy. Pole SENT przechowuje informacje czy dana wiadomość została wysłana czy też nie. Natomiast pole ID_CONF jest powiązaniem z tabelą Conference. Strona 42

43 8.14. Tabela Rooms. W skład niniejszej tabeli wchodzą dane dotyczące pokoi audio-konferencyjnych. Poniżej zamieszczony został rysunek z przykładowymi danymi: Jak możemy zauważyć pole LOCKED informuje nas o tym czy dany pokój jest zamknięty. Następne pole NAME przechowuje nazwę pokoju. Ostatnim ważnym polem jest ID_OWNER, które jest powiązaniem z tabelą Users Tabela Task. Niniejsza tabela przechowuje dane na temat zadań definiowanych przez użytkowników. Poniżej przykład z danymi: Jak możemy zaobserwować w skład tabeli wchodzą między innymi pola takie jak: TITLE - przechowuje tytuł zdefiniowanego zadania. MESSAGE - w tej kolumnie zawarta jest wiadomość dotyczące danego zadania. REMIND_DATA - data kiedy zadanie zostanie przypomniane użytkownikowi. ID_USER - powiązanie z tabelą Users. Dane użytkownika, który założył zadanie. Strona 43

44 8.16. Tabela Reset_Password. W tej tabeli przechowywane są dane na temat użytkowników, którzy zdecydowali się na zresetowanie swojego hasła. Poniżej przykładowe dane tej tabeli: Jak widać w skład tej tabeli wchodzą trzy pola. Pole CODE przechowuje kod potrzebny przy zmianie hasła. Pole ID_USER zawiera identyfikator użytkownika, który zgłosił potrzebę zmiany hasła Activate_Account. Niniejsza tabela zawiera dane dotyczące kont użytkowników, którzy zarejestrowali się jednakże nie aktywowali jeszcze swoich kont. Poniżej przykładowe dane znajdujące się w tej tabeli. W skład tej tabeli wchodzą trzy pola. Pole CODE przechowuje kod, który wymagany jest przy aktywacji konta. Pole ID_USER zawiera identyfikator użytkownika, który nie aktywował jeszcze konta. Strona 44

45 9. Wykonanie aplikacji serwerowej. Rozdział ten został w całości poświęcony do omówienia sposobu w jaki została stworzona i jak działa aplikacja serwerowa. Przy pisaniu tej aplikacji kierowałem się tym aby mogła zostać uruchomiona w każdym środowisku, dlatego też, zdecydowałem się ją napisać jako aplikację konsolową. Ponieważ aplikacja ta jest rozległa zdecydowałem się przedstawić najważniejsze aspekty wchodzące w jej skład. Na płycie CD zawierającej kod źródłowy aplikacji zamieściłem instrukcję, która pozwoli w szybki sposób przygotować aplikację do działania Uruchomienie serwera. Strona 45 Podczas uruchomienia aplikacji serwerowej sprawdzany jest plik konfiguracyjny zawierający adres administratora jak i hasło do niego. Zawartość tego pliku została zaszyfrowana algorytmem DES. W razie jakichkolwiek problemów z zawartością pliku, administrator zobowiązany jest ponownie wprowadzić dane. Następnie następuje kluczowy moment, w którym serwer zaczyna nasłuchiwać na połączenia przychodzące od aplikacji klienckich. Aplikacje klienckie łączą się na określony adres IP i numer portu. Zanim serwer zacznie nasłuchiwanie musi wybrać i otworzyć wolny port. Zostało to zrealizowane w następujący sposób: int port = 30000; boolean isavailable = false; // zmienna pomocnicza - status portu while (!isavailable) { // dopóki port nie jest wolny try { ServerSocket ss = new ServerSocket(port); //otworzenie portu ss.close(); // zamknięcie portu ss = null; // usuniecie referencji isavailable = true; // port jest wolny catch (IOException ex) { //błąd - port jest zajęty isavailable = false; port++; // zwiększenie portu o 1 i cały proces od nowa try { serversocket = new ServerSocket(port); // otworzenie portu catch (IOException ex) {

46 say("port " + port + " is already in use"); System.exit(0); Jak możemy zauważyć, aplikacja zaczyna sprawdzanie dostępnych portów od numeru Proces sprawdzania portu polega na otwarciu portu i jeśli jest wolny wszystko zostaje ustawione zgodnie z powyższym kodem. Jeśli port jest zajęty wyłapywany jest wyjątek, zwiększany numer portu i cały proces jest wykonywany od nowa. Podczas uruchomienia serwera następuje także załadowanie kontekstu Spring a. W momencie tym zainicjalizowane zostają zmienne dostępu do bazy danych i wiele innych, które pełnią funkcje pomocnicze Przyjmowanie połączeń od klientów. Kolejnym ważnym zadaniem aplikacji jest na pewno przyjmowanie połączeń od klientów. Po uruchomieniu serwera tworzona jest instancja klasy ConnectionListener, która odpowiedzialna jest za przyjmowanie połączeń od nowych klientów. Oczekiwanie na połączenia zostało zrealizowane w osobnym wątku. Poniżej przedstawiam fragment realizacji, o której mowa wyżej: while(!isend){ try { // Nowy klient socket = serversocket.accept(); //utworzenie nowego wątku dla klienta new Thread(new TemporaryConnector(socket, ctx)).start(); //zapis do pliku pw.println("incoming connection from " + socket.getremotesocketaddress()); catch (IOException ex) { Oczekiwanie na połączenia od klientów trwa tak długo dopóki nie zostanie zamknięta aplikacja serwerowa. W momencie gdy nawiązane zostaje połączenie między klientem a serwerem wówczas zostaje stworzony osobny wątek, który od tej pory jest specjalnie wyznaczonym miejscem w pamięci serwera, przez który od teraz odbywa się między Strona 46

47 nimi komunikacja. Następnie informacje dotyczące połączenia zostają zapisane w pliku aby na bieżąco kontrolować skąd nawiązywane są połączenia oraz ich ogólna liczba. Serwer tworzy codziennie nowy plik z informacjami dotyczącymi połączeń oraz osobny plik z logami z bazy danych Bezpieczeństwo komunikacji między klientem a serwerem. Podczas gdy nawiązane zostanie połączenie, między hostami następuje bardzo ważny proces wymiany między nimi tajnego klucza, którym zostaną zaszyfrowane później przesyłane dane. Zostało to zrealizowane w następujący sposób: try { //Hello packet z kluczem RSA HelloPacket hellopacket = new HelloPacket(); hellopacket.setpublickey(crypto.getpublickey()); //wyslanie pakietu out.writeobject(hellopacket); //oczekiwanie na klucz DES od klienta EncryptedDesKey encrypteddeskey = (EncryptedDesKey) in.readobject(); //deszyfrowanie klucza DES od klienta crypto.decryptdeskey(encrypteddeskey.getencrypteddeskey()); new Thread(new DepartmentListThread(out, ctx, crypto)).start(); while(!isconnected.isvalue()){ //oczekiwanie na zaszyfrowaną wiadomość SealedObject sealedobject = (SealedObject) in.readobject(); if(isconnected.isvalue()){ isconnected.setcanstart(true); return; new Thread(new TemporaryObjectChecker(socket, out, in, ctx, sealedobject, crypto, isconnected)).start(); catch (IOException ex) { //wyłapany wyjątek gdy połączenie z klientem zostało zerwane. isconnected.setvalue(true); catch (ClassNotFoundException ex) { Powyższy fragment kodu zawiera kluczowe rozwiązania w kwestii bezpieczeństwa. Za każdym razem gdy nawiązywane jest nowe połączenie serwer generuje nową parę kluczy algorytmu szyfrowania jakim jest RSA. Następnie wysyła hellopacket do klienta z publicznym kluczem. Wszystkie czynności odbywające się po stronie klienta Strona 47

48 zostaną pokazane w rozdziale poświęconym opisowi aplikacji klienckiej. W momencie gdy serwer otrzyma zaszyfrowany klucz DES kluczem RSA, następuje proces deszyfrowania. Od tej chwili zarówno serwer jak i klient znają ten sam klucz DES, którym szyfrują obiekty przesyłane pomiędzy nimi. Następnie serwer oczekuje na żądania klienta. Gdy takie żądanie zostanie odebrane wówczas następuje stworzenie nowego wątku, który ma za zadanie go przetworzyć. Poniżej zamieszczony kod odpowiada za wygenerowanie pary kluczy algorytmu RSA: try { //pobranie instacji RSA KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA"); generator.initialize(1024); //wyegenrowanie kluczy KeyPair pairofkeys = generator.generatekeypair(); publickey = pairofkeys.getpublic(); privatekey = pairofkeys.getprivate(); catch (NoSuchAlgorithmException ex) { Jak możemy zauważyć, aby wygenerować parę kluczy algorytmu do szyfrowania RSA musimy pobrać generator tej instancji. Następnie zainicjalizować jego długość. W tym przypadku jest to 1024-bitowy klucz. Ostatnią czynnością jest wygenerowanie kluczy na podstawie wyżej pobranej instancji generatora. Ze względów bezpieczeństwa architektura mojego systemu została zaprojektowana tak aby żądania użytkowników niezalogowanych były okrojone. Oznacza to, iż żądanie takiego użytkownika ma tylko dostęp do specjalnie wytyczonych funkcji mających przetworzyć dane żądanie. W miejscu gdzie tworzona jest instancja klasy TemporaryObjectChecker następuje dostęp do wyżej wymienionych funkcji. W następnym podrozdziale omówię wyżej wymienioną klasę Dostęp do zasobów przez użytkownika niezalogowanego. Jak wspomniałem wyżej ze względów bezpieczeństwa podzieliłem dostęp do zasobów aplikacji na dwie grupy: użytkownika zalogowanego i niezalogowanego. Strona 48

49 Strona 49 Użytkownik, który jeszcze nie dokonał autoryzacji do systemu może jedynie wykonać operacje takie jak: Rejestracja nowego konta. Aktywacja konta. Zmiana hasła. Logowanie do systemu. Co więcej wątki w pamięci serwera odpowiedzialne za przetwarzanie żądań użytkowników nie mają w ogóle pojęcia o istnieniu wątków użytkowników zalogowanych i odwrotnie. Ponieważ klasa TemporaryObjectChecker jest dosyć rozległa, dlatego też zdecydowałem się zamieścić krótki fragment z opisem: private Socket socket; private ObjectOutputStream out; private ObjectInputStream in; private ApplicationContext ctx; private Cryptography crypto; private SealedObject sealedobject; private MyBoolean isconnected; Powyżej zamieszczone zostały pola klasy TemporaryObjectChecker. Pole out jest strumieniem wyjściowym, przez który wątek wysyła do klienta dane. Pole in jest strumieniem wejściowym, przez który dane od klienta zostają odbierane. Następnym ważnym polem jest ctx. Dzięki tej zmiennej możemy uzyskać dostęp do zmiennych, które są przechowywane w kontekście Spring a. Następnym ważnym polem jest crypto udostępniające metody do szyfrowania i deszyfrowania danych. Zmienna sealedobject jest po prostu zaszyfrowanym obiektem, który zostaje deszyfrowany w wyżej wymienionej klasie. Poniżej zamieszczony został krótki fragment ukazujący jak przetwarzane są poszczególne żądania (w tym przypadku RegisterRequest): //deszyfrowanie obiektu Object object = crypto.decryptobject(sealedobject); //sprawdzenie jakiego typu jest obiekt if (object instanceof RegisterRequest) { //rzutowanie RegisterRequest register = (RegisterRequest) object; //pobranie zmiennej z kontekstu Spring'a. UserDao userdao = ctx.getbean("userdao", UserDao.class); //wiadomość zwrotna RegisterResponse registerresponse = new RegisterResponse(userDao.createUser(register, ctx)); try { //wyslanie wiadomosci

50 out.writeobject(crypto.encryptobject(registerresponse)); catch (IOException ex) { Jak możemy zauważyć pierwszą operacją jest deszyfrowanie otrzymanego obiektu. Odbywa się to za pośrednictwem metody decryptobject. Następnie wykonywane jest sprawdzenie jakiej instancji jest przesłany obiekt w celu zastosowania odpowiednich metod do jego przetworzenia. Obiekty przesyłane pomiędzy aplikacją klientem a serwerem muszą być tych samych typów. W obydwóch aplikacjach istnieje pakiet nazwany communicationdata zawierający klasy, których obiekty są przesyłane pomiędzy aplikacjami dzięki czemu niemożliwa jest sytuacja, w której zostaną przesłane obiekty nieznane aplikacjom. Dodatkowo rozwiązanie to uniemożliwia osobom trzecim dostępu do zasobów serwera i wykonywania na nich operacji nieprzewidzianych podczas projektowania systemu mających na celu sparaliżowanie aplikacji lub uszkodzenie danych Dostęp do zasobów przez użytkownika zalogowanego. Moment, w którym następuje pomyślna autoryzacja klienta do systemu jest bardzo ważny w działaniu aplikacji. Użytkownik taki trafia na listę użytkowników zalogowanych do systemu. Lista taka przetrzymywana jest w pamięci serwera. Dzięki temu serwer wie kto jest zalogowany do systemu i jeśli odbiera żądania, które przykładowo muszą zostać rozesłane do innych klientów, wówczas nie musi wykonywać zbędnych operacji sprawdzających czy dane klient jest zalogowany czy nie. Dodatkowo możliwe jest odtworzenie tej listy praktycznie w każdym miejscu mojej aplikacji dzięki mechanizmowi Dependency Injection (wstrzykiwanie zależności). Jedyne czego potrzeba aby odtworzyć taka listę to kontekst Spring a. W czasie gdy użytkownik trafia na wyżej wymieniona listę dochodzi do dwóch bardzo ważnych rzeczy takich jak: Utrata dostępu do zasobów użytkownika niezalogowanego. Stworzenie nowego wątku do komunikacji oraz skasowanie starego. Dostęp do zasobów użytkownika zalogowanego. Strona 50

51 Utworzenie dodatkowe połączenia między klientem a serwerem, które ma za zadanie sprawdzać czy połączenie nie zostało zerwane w sposób nagły np. odłączenie kabla do internetu. Z chwilą stworzenia nowego wątku do komunikacji następuje wiele operacji wykonywanych na bazie danych. Poniżej zostanie pokazany fragment klasy UsersOnline, która od tej chwili jest główną klasą po stronie serwera służącą do komunikacji. Pola wyżej wspomnianej klasy zawierają pola takie same jak klasa TemporaryObjectChecker, której fragment został omówiony w powyższym podrozdziale. Dodatkowo znajdują się tutaj pola takie jak: Lista użytkowników zalogowanych. Zmienne pomocnicze. Ponieważ klasa UsersOnline wykonuje wiele różnych i zarazem rozbudowanych operacji zdecydowałem się ukazać przykładowy kod podczas wyciągania z bazy danych zadań zdefiniowanych przez konkretnego użytkownika: //wywołanie metody pobierającej zadania List<Task> tasks = ctx.getbean("taskdao", TaskDao.class).getAllTasksOfUser(user.getIdUser()); //stworzenie nowej listy List<TaskInfo> listoftasks = new ArrayList<TaskInfo>(); for(task task: tasks){ //wypelnienie listy danymi listoftasks.add(new TaskInfo(task.getTitle(), task.getreminddata(), task.getmessage())); Aby pobrać zadania zdefiniowane przez konkretnego użytkownika należy wstrzyknąć obiekt dostępu do bazy danych z kontekstu Spring a. W tym przypadku obiektem tym jest taskdao, który zawiera metody dostępu do tabeli Task. Następnie na rzecz tego obiektu wywoływana jest metoda getalltasksofuser, która jako parametr przyjmuje numer identyfikacyjny użytkownika. Następnie gdy mamy już listę zadań pobrana z bazy danych tworzymy nowa listę, która uzupełniamy konkretnymi danymi z listy z zadaniami. Dzięki takiemu rozwiązaniu aplikacja kliencka, która odbierze listę tasks nie ma pojęcia o tym jak wyglądają klasy mapujące stworzone przez Hibernate a. Co więcej nie ma pojęcia jak wygląda struktura bazy danych. Poniżej zamieściłem kod metody getalltasksofuser : Strona 51

52 public List<Task> getalltasksofuser(int iduser) { //tworzone jest kryterium DetachedCriteria criteria = initcriteria(task.class); //ustawienie parametrów kryterium criteria.add(restrictions.eq("iduser", iduser)); //wykonanie zapytania List<Task> listoftasks = gethibernatetemplate().findbycriteria(criteria); return listoftasks; Jak możemy zauważyć powyższa metoda zwraca listę zadań. Jako parametr przyjmuje identyfikator użytkownika. Pierwszą czynnością jest stworzenie kryterium zapytania, które od teraz wie ze będziemy się odnosić do pól jakie posiada klasa Task. Następnie ustawiamy parametry tego kryterium. W tym przypadku linia Restrictions.eq("idUser", iduser) tworzy zapytanie, w którym pole iduser ma być równe parametrowi przekazanemu do funkcji. Następnie następuje wykonanie zapytania na podstawie kryterium po czym zwracany jest wynik. Odbieranie danych od użytkownika zalogowanego zostało zrealizowane w taki sam sposób jak od użytkownika, który nie jest zalogowany. Różnicą jest tutaj jedynie dostęp do innych zasobów Sprawdzanie połączenia pomiędzy klientem a serwerem. Ze względów wydajnościowych zdecydowałem się na utworzenie dodatkowego połączenia pomiędzy klientem a serwerem. Można sobie zadać pytanie dlaczego wprowadzać dodatkowe połączenie pomiędzy tymi samymi aplikacjami. Otóż postanowiłem, że połączenie, w którym wymieniane są dane pomiędzy pracownikami nie powinno być zakłócane przez pakiety, które co parę sekund sprawdzają czy dane połączenie istnieje. W tym celu stworzyłem dodatkowe połączenie, w którym tylko i wyłącznie co dwie sekundy wysyłam małą jednostkę danych, która za zadanie ma sprawdzić czy dane połączenie jest aktywne. Jednakże jak się okazało protokół TCP nie działa w taki sposób co skutkowało tym, że utrata połączenia była odkrywana po około 20 sekundach. Jak na komunikator 20 sekund to za dużo dlatego też zdecydowałem się zaimplementować mechanizm, który pozwoli na wykrycie utraty Strona 52

53 połączenia w około 4 sekundy. Poniżej przedstawiam fragmenty kodu odpowiedzialne za niniejsza funkcjonalność: //dopóki jest połączenie while(!isend.isvalue()){ //wysłanie wartości 0 dos.write(0); //uspanie wątku Thread.sleep(2000); Zarówno aplikacja kliencka jak i serwerowa wysyłają do siebie co dwie sekundy wartość 0. Cały mechanizm polega na tym, że co dwie sekundy obydwie aplikacje starają się odczytać wysłane do nich dane. Zostało to zrealizowane w następujący sposób: while(!isend.isvalue()){ //odczytanie wartości int connectionstatus = dis.read(); //jeśli jest to początek połączenia if(start == 0){ //zwiększenie licznika danych connectioncount.setcounter(connectioncount.getcounter() + 1); //uruchomienie nowego wątku new Thread(new ConnectionBeat(ctx, true, connectioncount, socket, out, in)).start(); start++; connectioncount.setcounter(connectioncount.getcounter() + 1); Strona 53 Jak możemy zauważyć pierwsze następuje odczytanie wartości. Następnie jeśli jest to pierwszy pakiet danych następuje zwiększenie wartości licznika, który liczy rzeczywistą liczbę otrzymanych pakietów. Kluczowym momentem jest utworzenie nowego wątku, który co dwie sekundy sprawdza czy licznik uległ zwiększeniu. Mechanizm ten został ukazany poniżej: //ustawienie zmiennej pomocniczej long tmp = count.getcounter(); //licznik błędów int terminateconnection = 0; while(connected){ try { Thread.sleep(2000); //dane nie dotarły if(tmp == count.getcounter()){ terminateconnection++; //dane dotarły else{

54 tmp = count.getcounter(); terminateconnection = 0; //dane nie dotarły 2 razy pod rząd if(terminateconnection == 2){ connected = false; connchecker.close(); out.close(); in.close(); catch (IOException ex) { catch (InterruptedException ex) { Przy stworzeniu instancji klasy ConnectionBeat zmienna pomocnicza zostaje ustawiona na wartość licznika rzeczywistej liczby danych. Od teraz co dwie sekundy wątek sprawdza czy licznik uległ zwiększeniu. Jeśli dane nie dotrą dwa razy pod rząd wówczas oznacza to, iż połączenie zostało zerwane przez którąś ze stron. W momencie tym zamykane zostają strumienie służące do komunikacji z klientem. Następnie usuwany jest wątek nieaktywnego klienta z pamięci serwera jak również dany użytkownik usuwany jest z listy użytkowników zalogowanych. Następnie serwer informuje innych użytkowników o tym, iż dany klient się wylogował. Identyczny mechanizm sprawdzania czy połączenie jest aktywne został zaimplementowany w aplikacji klienckiej Panel administratora. Po pomyślnym uruchomieniu serwera administrator ma możliwość zalogować się do aplikacji serwerowej. Logowanie odbywa się poprzez podanie unikatowego loginu oraz hasła administratora. W przypadku podania fałszywych danych wyświetlony zostanie komunikator, który został pokazany poniżej: Strona 54

55 Jak możemy zauważyć ktoś próbował zalogować się do systemu przez podanie błędnych danych jednakże próba ta zakończyła się fiaskiem. W przypadku pomyślnej autoryzacji do systemu administrator może wykonać szereg funkcji. Pierwszą z nich jest dodanie nowego działu do firmy. Proces ten odbywa się na zasadzie podania nazwy działu. Następnie system sprawdza czy dział o takiej nazwie już nie istnieje. Rezultat zostanie wyświetlony na konsoli. Po operacji tej aplikacja musi zostać zrestartowana. Ponadto administrator może usunąć istniejący dział tylko i wyłącznie jeśli nie istnieją pracownicy należący do niego. Proces ten odbywa się poprzez podanie nazwy działu, który ma zostać usunięty. Wynik operacji zostanie wyświetlony na konsoli. Aplikacja zostaje automatycznie zrestartowana po tej operacji. Dodatkowo administrator może wyświetlić informacje dotyczące działów. Następna opcją jest wyświetlenie danych osobowych pracowników. Wszystkie informacje zostaną wyświetlone na konsoli. Ponadto administrator może usunąć pracownika. Pociąga to za sobą szereg innych operacji wykonywanych na bazie danych. Usuwane zostają wszelkie dane, która w jakiś sposób były związane z tym pracownikiem. Proces odbywa się poprzez podanie numeru identyfikacyjnego pracownika. Następnie następuje sprawdzenie czy pracownik o podanym numerze istnieje. Wynik operacji zostaje wypisany na konsoli. Aplikacja zostaje automatycznie zrestartowana po tej operacji. Dostęp do innych funkcjonalności nie jest potrzebny ponieważ aplikacja została napisana w taki sposób, iż reszta zadań wykonywana jest automatycznie. Strona 55

56 9.8. Wysyłanie wiadomości . Aplikacja serwerowa podczas przetwarzania żądań klientów czasami musi wysłać wiadomość , która zawiera niezbędne dane. Poniżej została omówiona . Zawiera ona pola takie jak: //od kogo private String from; //do kogo private String to; //tytuł private String title; //wiadomość private String body; //hasło private String password; Pola takie jak from i password dotyczą adresu administratora. Zaszyfrowane zostały w pliku konfiguracyjnym serwera. Pole to jest adresem odbiorcy. Natomias reszta pól to tytuł i wiadomość, które generowane są automatycznie w zależności od operacji. Poniżej znajduje się kod metody odpowiedzialnej za wysyłanie wiadomości public boolean send (){ boolean succesfull = true; //ustawienie właściwości poczty Properties properties = new Properties(); properties.put("mail.smtp.host", "smtp.gmail.com"); properties.put("mail.smtp.user", from); properties.put("mail.smtp.port", "465"); properties.put("mail.smtp.socketfactory.class", "javax.net.ssl.sslsocketfactory"); properties.put("mail.smtp.auth", "true"); //autentyfikacja Authenticator auth = new SMTPAuthenticator(); Session session = Session.getInstance(properties, auth); //Stworzenie wiadomości Message message = new MimeMessage(session); try { message.setfrom(); message.setsubject(title); message.setsentdate(new Date()); message.setrecipient(message.recipienttype.to, new InternetAddress(to)); Strona 56

57 message.setcontent(body, "text/html"); //wysłanie wiadomości Transport.send(message, message.getallrecipients()); catch (MessagingException ex) { succesfull = false; return succesfull; Jak możemy zauważyć metoda send zwraca wartość boolean. Wartość true jeśli wiadomość została wysyłana w przeciwnym razie false. Ze względu, iż moja aplikacja używa serwera SMTP gmail a, dlatego też adres administratora musi być adresem gmail. Ważnym momentem w całym procesie jest na pewno autentyfikacja użytkownika. W przypadku błędnych danych podanych przez administratora cały proces nie powiedzie się. Następnie tworzona jest wiadomość na podstawie sesji uzyskanej dzięki autentyfikacji. Kolejna operacją jest ustawienie odbiorcy, nadawcy, tytułu i tekstu wiadomości. Następnie ustawia się format wiadomości na text/html po czym następuje wysłanie wiadomości. Na płycie CD zawierającej kod źródłowy aplikacji zamieściłem login i hasło do skrzynki pocztowej w celu przetestowania aplikacji Klasy mapujące. Dzięki zastosowaniu Hibernate a wszystkie klasy mapujące zostały wygenerowane przez wyżej wymieniony framework. Oznacza to, iż pola klas mapujących są identyczne jak pola w tabelach w bazie danych. Klasy mapujące przetrzymywane są na serwerze dzięki czemu tylko aplikacja serwerowa zna strukturę bazy danych. Strona 57

58 10. Wykonanie aplikacji klienckiej. Rozdział ten zawiera szczegółowy opis wykonania funkcjonalności zawartych w aplikacji klienckiej mojego komunikatora. Aplikacja kliencka przeznaczona jest dla zwykłych pracowników firmy i też tylko oni mogą się zalogować do systemu Uruchomienie aplikacji klienckiej. Podczas uruchamiania aplikacji klienckiej zachodzi parę bardzo ważnych procesów. Pierwszym z nich jest sprawdzenie pliku konfiguracyjnego znajdującego się w katalogu roboczym niniejszej aplikacji, który zawiera informacje takie jak: Adres IP serwera. Numer portu serwera, na którym nasłuchuje aplikacja serwerowa na połączenia od klientów. W przypadku braku takiego pliku lub niekompletnych informacji parametrów serwera wówczas tworzony jest nowy plik z domyślnymi ustawieniami, które nie pozwolą na połączenie do serwera. Aby uzupełnić plik parametrami połączenia należy uruchomić aplikację ConnectionSetter znajdującą się w katalogu roboczym aplikacji klienckiej i wypełnić pola danymi. Poniżej zamieściłem fragment kodu, w którym następuje połączenie: //próba połączenia socket = new Socket(ip, port); //stworzenie strumienia out = new ObjectOutputStream(socket.getOutputStream()); out.flush(); //stworzenie strumienia in = new ObjectInputStream(socket.getInputStream()); Jak możemy zauważyć nawiązanie połączenia z serwerem następuje poprzez podanie adresu IP i numeru portu na którym nasłuchuje aplikacja serwerowa. Parametry te zostają zczytane z pliku konfiguracyjnego. Następnie jeśli połączenie zostanie nawiązane tworzone są strumienie wyjściowe i wejściowe danych. Jeśli wszystko się Strona 58

59 powiedzie powinniśmy zobaczyć główny panel do logowania z komunikatem pokazany na poniższym rysunku: odpowiednim Jak możemy zauważyć aplikacja kliencka połączyła się z aplikacją serwerową co zostało pokazane w dolnej części panelu za pośrednictwem napisu Connected. Jeśli nawiązywanie połączenia zakończyło by się błędem wówczas otrzymalibyśmy komunikat Not connected co sugerowałoby, że albo nasze dane znajdujące się w pliku konfiguracyjnym są błędne lub serwer po prostu z jakiś przyczyn nie działa Część użytkownika niezalogowanego. Podrozdział ten zawiera szczegółowy opis funkcjonalności dostępnych dla użytkownika, który jeszcze nie wykonał autoryzacji do systemu. Strona 59

60 Rejestracja nowego użytkownika. Zanim użytkownik będzie mógł w pełni skorzystać z usług jakie oferuje mój komunikator musi stworzyć nowe konto. Jeden pracownik może posiadać dokładnie jedno konto. Poniżej zamieszczony jest obrazek, który pokazuje panel do rejestracji: Jak możemy zauważyć podczas rejestracji nowego konta użytkownik musi wypełnić 7 pól dotyczących jego danych osobowych takich jak: imię, nazwisko, pesel, hasło, telefon, stanowisko, adres i potem wybrać z listy dział, do którego należy. Jak możemy zauważyć pola podczas rejestracji są sprawdzane pod kątem formatu danych. Walidacja pól odbywa się na zasadzie zdarzenia focuslost przypisanego do komponentu jakim jest TextField. Sprawdzenie formatu danych odbywa się w Strona 60

61 momencie utraty przez dany komponent skupienia czyli momentu, w którym możemy wykonywać na nim jakieś operacje. Jeśli format danych jest poprawny wówczas kolor TextField jest zielony w przeciwnym razie czerwony. Jeśli najedziemy na ikonę błędu wówczas wyświetlona zostanie informacja dotycząca błędu. Wybór działu, do którego należy pracownik odbywa się poprzez komponent jakim jest JComboBox. Jest on wypełniany od razu przy starcie aplikacji w momencie otrzymania od serwera listy działów. Walidacja pól została wykonana na podstawie wyrażeń regularnych co zostało zrealizowane w następujący sposób: //sprawdzenie długości if ( textfield.gettext().length() > 5) { //szablon wyrażenia regularnego Pattern pattern = Pattern.compile("[a-zA-Z0-9]+@[a-zA-Z0-9]+\\.[a-zA-Z]{2,"); //pobranie instancji Matcher match = pattern.matcher( textfield.gettext()); //sprawdzenie tekstu if (!match.matches()) { textfield.setbackground(new Color(255, 51, 51)); errorlabel.seticon(new ImageIcon( map.getclassloader().getresource(path + "error.png"))); errorlabel.settooltiptext("the following format" + "isn't valid"); registerinputs[3].setinputok(false); return; //dobry format textfield.setbackground(new Color(153, 255, 153)); errorlabel.seticon(new ImageIcon( map.getclassloader().getresource(path + "ok.png"))); errorlabel.settooltiptext(null); registerinputs[3].setinputok(true); else { //za mało znaków textfield.setbackground(new Color(255, 51, 51)); errorlabel.seticon(new ImageIcon( map.getclassloader().getresource(path + "error.png"))); errorlabel.settooltiptext("not enough characters in" + "the input"); registerinputs[3].setinputok(false); return; Jak możemy zauważyć podczas walidacji pola w tym przypadku jest to pole , najpierw sprawdzana jest długość znaków. Jeśli jest większa od 5, wówczas następuje użycie wyrażeń regularnych. Następnie pobierany jest tekst z komponenty Strona 61

62 TextField, który zostaje sprawdzony według wyrażenia regularnego. Jeśli się powiedzie wówczas ustawiane są różne własności komponentów. W momencie kliknięcia na przycisk Register następuje ponowne sprawdzenie komponentów, w których z jakiś przyczyn wystąpił błąd. W przypadku poprawnych danych następuje utworzenie instancji klasy RegisterRequest, która następnie wysyłana jest do serwera gdzie następuje sprawdzenie danych pod kątem bazy danych. Oznacza to, że sprawdzane są dane osobowe pracowników w firmie czy przypadkiem nie istnieje już taki numer Pesel, który jest unikatowy lub adres , na który wysłany zostanie kod aktywujący konto. Jeśli nie istnieje taki pracownik wówczas tworzone są rekordy w bazie danych i serwer powiadamia użytkowników zalogowanych, iż dany użytkownik dołączył do grona osób korzystających z komunikatora. Dodatkowo serwer odsyła do klienta obiekt klasy RegisterResponse z informacją czy dana operacja została wykonana pomyślnie lub nie. Jeśli wszystko zostało wykonane pomyślnie wówczas powinien ukazać się nam komunikat pokazany poniżej: Jak możemy zauważyć serwer odesłał do klienta wiadomość, która informuje go, że kod aktywujący konto został wysłany na dany adres . Jeśli z jakiś przyczyn rejestracja nie powiedzie się otrzymamy odpowiedni komunikat Aktywacja konta. W poprzednim podrozdziale omówiona została rejestracja nowego konta użytkownika, która zakończyła się wysłaniem specjalnie wygenerowanego kodu, który musi zostać użyty podczas aktywacji konta. Dlatego też podanie poprawnego adresu podczas rejestracji jest niezbędne. Strona 62

63 Panel służący do aktywacji konta składa się z dwóch pół takich jak: kod aktywacyjny oraz adres , na który ów kod został wysłany. Pola te są również walidowane jak to miało miejsce w przypadku rejestracji nowego konta. Poniżej został pokazany graficzny interfejs tego panelu: W momencie gdy użytkownik zdecyduje się aktywować konto, wówczas sprawdzane są pola, w których z jakiś przyczyn walidacja się nie powiodła. Następnie wysyłany jest obiekt klasy ActivationRequest do serwera gdzie następuje sprawdzenie czy podany kod aktywacyjny jest poprawny dla podanego adresu . Następnie serwer odsyła obiekt klasy ActivationResponse, w którym informuje klienta czy dana operacja się powiodła lub nie. Jeśli aktywacja konta się powiodła serwer wysyła z wiadomością o aktywacji na podany adres podczas rejestracji. Użytkownik, który nie aktywował konta nie ma możliwości zalogować się do systemu. Jednakże jego konto jest widoczne dla innych użytkowników Zmiana hasła na nowe. W przypadku gdy użytkownik zapomni hasła do swojego konta ma możliwość zmiany hasła na nowe. Na proces ten składają się dwie operacje. Pierwszą z nich jest uzyskanie specjalnego kodu za pośrednictwem, którego nastąpi zresetowanie i zmiana hasła. Panel służący do uzyskania specjalnego kodu składa się dwóch pól takich jak: numer konta i adres , na który zostało zarejestrowane. Walidacja pól odbywa się Strona 63

64 na tej samej zasadzie, jak podczas procesu rejestracji. Poniżej przedstawiony został graficzny wygląd wyżej wymienionego panelu: W momencie gdy użytkownik zdecyduje się uzyskać kod potrzebny do zresetowania hasła, sprawdzone zostają ponownie pola, które z jakiś powodów zawierają błędny format danych. Jeśli wszystko pójdzie dobrze wysyłany jest obiekt klasy GetCodeRequest, który jest przetwarzany po stronie serwera. Jeśli podane dane są prawidłowe i takie konto istnieje wówczas tworzona jest instancja klasy GetCodeResponse, która zawiera komunikat czy operacja się powiodła lub nie. Ponadto. Następnie gdy już uzyskamy kod do zmiany hasła pozostaje wybrać z komponentu JComboBox operację Reset password. W skład panelu służącego do zmiany hasła wchodzą takie jak: kod do zresetowania hasła, adres , na który zostało zarejestrowane konto oraz nowe hasło do konta. Walidacja wyżej wymienionych pól została wykonana na tej samej zasadzie co walidacja pól podczas rejestracji. W momencie kliknięcia przycisku Reset następuje ponowna walidacja pól, które zawierają błędny format danych. Jeśli wszystkie pola są wypełnione poprawnymi Strona 64

65 danymi wówczas wysyłana jest instancja klasy ResetPasswordRequest do serwera, gdzie następnie jest przetwarzana i sprawdzana pod kątem bazy danych. Gdy serwer skończy wykonywać operacje wysyła do klienta instancję klasy ResetPasswordResponse, która zawiera informację na temat powodzenia operacji zmiany hasła Część użytkownika zalogowanego. Podrozdział ten zawiera szczegółowy opis głównych funkcjonalności komunikator, które dostępne są po pomyślnym zalogowaniu do systemu Logowanie do systemu. Proces logowania do systemu przez użytkownika składa się z kilku etapów. Pierwszym z nich jest sprawdzenie poprawności dwóch pól takich jak: login i hasło do konta. Walidacja ta zrealizowana jest na tej samej zasadzie co walidacja podczas rejestracji. Gdy dane format danych jest poprawny, następuje wysłanie instancji klasy Login do serwera gdzie sprawdzane jest baza danych pod kątem przekazanego loginu i hasła. Po przetworzeniu żądania serwer odsyła instancję klasy LoginResponse, która zawiera informacje czy autoryzacja do systemu zakończyła się sukcesem lub niepowodzeniem. W przypadku gdy logowanie zakończyło się niepowodzeniem zobaczymy niżej pokazany komunikat: Strona 65

66 W przeciwnym przypadku powinniśmy zobaczyć logo aplikacji z paskiem ładowania. W tym momencie serwer przesyła do klienta całą masę informacji między innymi takich jak: Lista pracowników posortowana według działów. Wiadomości nieodebrane. Wiadomości archiwalne. Lista zadań zdefiniowanych przez użytkownika. Lista pokoi do audio konferencji. Na podstawie wyżej wymienionych informacji następuje stworzenie głównego okna aplikacji. Ponadto w tym momencie następuje także utworzenie dodatkowego połączenia między klientem a serwerem mającego za zadanie sprawdzanie połączenia pomiędzy aplikacjami. Mechanizm ten został omówiony w rozdziale dotyczącym wykonania aplikacji serwerowej Zmiana statusu konta. Komunikator ten pozwala na zmianę statusu konta na: Zalogowany (online). Niezalogowany (offline). Przeznaczeniem tej funkcjonalności jest poinformowanie innych użytkowników czy jesteśmy w danej chwili dostępni. W chwili gdy następuje zmiana statusu na offline tworzona jest instancja klasy ClientStatus, która następnie wysyłana jest do serwera, który informuje resztę użytkowników zalogowanych o tym, że dany klient się wylogował. Ponadto użytkownik traci dostęp do funkcjonalności dostępnych dla użytkowników zalogowanych. Drugim wariantem jest zmiana statusu konta na online. Proces ten jest trochę bardziej złożony. Pierwszą operacją jest wysłanie do serwera instancji klasy ClientStatus. Strona 66

67 Aplikacja serwerowa sprawdza czy przypadkiem już jakiś użytkownik nie korzysta z tego konta. W przypadku gdy z konta nikt nie korzysta wówczas serwer informuje pozostałych klientów, że nowy użytkownik się zalogował. Następnie odsyła do klienta odpowiedź. W przypadku pomyślnego przeprowadzenia operacji zmiany statusu serwer na nowo przesyła do klienta informacje. Ponieważ w rozdziale dotyczącym opisu aplikacji zamieściłem obrazek ukazujący główne okno aplikacji po zalogowaniy, dlatego też postanowiłem zamieścić tutaj zdjęcie pokazujące graficzny interfejs użytkownika gdy zmieni status konta na offline: Jak możemy zauważyć w momencie zmiany statusu z online na offline następuje utrata dostępu do funkcjonalności komunikator. W przypadku gdybyśmy chcieli przykładowo stworzyć nowe zadanie wówczas otrzymamy komunikat pokazany poniżej: Strona 67

68 Interakcja z innymi użytkownikami. Głównym celem powstania mojego komunikatora była szybka i niezawodna interakcja z innymi pracownikami firmy. Zostało to osiągnięte między innymi poprzez wiadomości tekstowe, które pracownicy danej firmy mogą wymieniać między sobą w czasie rzeczywistym. Ze względu na fakt, iż w czasie działania komunikatora jest przesyłanych bardzo dużo danych pomiędzy klientem a serwerem musiałem zaimplementować mechanizm synchronizacji danych wysłanych i odebranych pomiędzy tymi dwoma aplikacjami. W komunikatorze istnieje lista pracowników, która pokazuje status konta innych użytkowników. Poniżej znajduje się obrazek ukazujący taką listę: Strona 68

69 Jak możemy zauważyć kontakty posortowane są według działów. Jeśli kolor kontaktu jest zielony wówczas dany użytkownik jest zalogowany. Aby rozpocząć rozmowę z wybranym użytkownikiem wystarczy dwa razy kliknąć lewym przyciskiem myszy w wybrany kontakt. W pamięci aplikacji klienckiej trzymana jest lista zawierająca referencje do otwartych okien służących do rozmów tekstowych. W momencie kliknięcia dwa razy w kontakt następuje sprawdzenie czy przypadkiem nie jest już prowadzona rozmowa z takim użytkownikiem. Zostało to zrealizowane w następujący sposób: //lista okien ListOfTalkWindows talkwindows = ctx.getbean("talkwindows", ListOfTalkWindows.class); //zmienna pomocnicza int j = -1; for (int i = 0; i < talkwindows.getlistoftalkwindows().size(); i++) { //warunek if (talkwindows.getlistoftalkwindows().get(i). getnumber().equals(number)) { j = i; break; //brak okna j = -1; Jak możemy zauważyć pierwsze następuje pobranie listy okien z kontekstu Spring a. Następnie sprawdzane są okna pod kątem unikalnego numeru konta. Jeśli takie okno istnieje wówczas zmienna pomocnicza ustawiana jest na numer okna w liście. Jeśli zmienna pomocnicza po wyjściu z pętli będzie równa -1 oznacza to, że w liście nie istnieje takie okno. Jeśli okno istnieje wówczas wykonywane są dwie instrukcje: //ustawiana właściwość okna talkwindows.getlistoftalkwindows().get(j).setextendedstate( JFrame.NORMAL); //wyświetlenie okna talkwindows.getlistoftalkwindows().get(j).setvisible(true); Pierwszą czynnością jest zmiana stanu okna na normalny. Oznacza to, iż wcześniej okno mogło być w stanie zminimalizowanym w pasku zadań. Następnie okno zostaje wyświetlone na ekran. Strona 69

70 Przypadek gdy szukane okno nie istnieje zostanie wyjaśniony w dalszym rozdziale opisującym wiadomości nieodebrane. Jeśli chcemy stworzyć konferencję tekstową pomiędzy większą liczbą użytkowników wówczas musimy przytrzymać klawisz Ctrl + zaznaczać lewym przyciskiem myszy użytkowników którzy mają brać udział w konferencji. Proces wyszukiwania okna odbywa się na trochę innej zasadzie niż w przypadku rozmowy tekstowej, w której biorą udział dwie osoby. Każde okno jest identyfikowane według pojedynczego numeru lub listy składającej się z imienia i nazwiska użytkowników. Sprawdzeniu ulegają tutaj dane użytkowników. W momencie gdy wykonane zostaną wszystkie instrukcje powinniśmy zobaczyć przykładowe okno: Jak możemy zobaczyć okno służące do rozmów tekstowych składa się z dwóch głównych paneli. Pierwszy z nich służy do rozmów tekstowych. Przeznaczeniem drugiego natomiast jest rysowanie w czasie rzeczywistym. Strona 70

71 Strona 71 W momencie gdy użytkownik zdecyduje się wysłać wiadomość następują procesy takie jak: Sprawdzenie formatu danych. Utworzenie instancji klasy TextMessage po czym zostaje ona wysłana do serwera lub trafia do kolejki wiadomości oczekujących na wysłanie. Utworzenie nowego wątku do sprawdzenia wiadomości pod kątem ikon oraz znaczników pogrubiających. Następnie dane te zostaną wyświetlone na komponencie jakim jest JTextPane. Zapisanie wiadomości do archiwum. Użytkownik ma możliwość dekoracji tekstu za pośrednictwem pogrubienia lub wstawianiem ikonek co zostało pokazane na powyższym obrazku. Pogrubienie zostało zrealizowane na podstawie wstawiania znaczników <b>komunikator</b> do tekstu. Wstawianie ikon zostało zrealizowane poprzez wstawienie specjalnych ciągów znaków takich jak np. :D, :P. Wyżej wspomniana kolejka wiadomości oczekujących na wysłanie została zaimplementowana w sposób pokazany poniżej: //jeśli kolejka jest pusta if(que.getmessages().isempty() &&!que.isbusy()){ //wysyłanie wiadomości que.setbusy(true); outobject.getout().writeobject( outobject.getcrypto().encryptobject(message)); else{ //dodanie wiadomości do kolejki que.getmessages().add(message); //utworzenie nowego wątku if(messthread.getawaitingmessages() == null){ Thread thread = new Thread(new Runnable() { public void run() { TextMessage m; while ((m = que.getmessages().get(0))!= null) { while(que.isbusy()){ continue; try { que.setbusy(true); outobject.getout().writeobject( outobject.getcrypto().encryptobject(m)); if(que.getmessages().size() <= 1){ que.getmessages().clear();

72 break; else{ que.getmessages().remove(m); que.getmessages().remove(m); catch (Exception ex) { messthread.setawaitingmessages(null); ); thread.start(); messthread.setawaitingmessages(thread); Aplikacja kliencka w momencie wysłania jakiś danych do serwera zmuszona jest poczekać z następnym pakietem aż serwer odeśle wiadomość, że otrzymał dane. Tak też zaimplementowany został mechanizm kolejkowania wiadomości. Jeśli kolejka jest pusta wówczas wysyłana zostaje wiadomość. O wiele ciekawiej wygląda sprawa gdy kolejka zawiera wiadomości oczekujące na wysłanie. Wówczas wiadomość zostaje dodana do kolejki. Następnym krokiem jest sprawdzenie czy istnieje wątek mający za zadanie wysłać oczekujące w kolejce wiadomości. Wątek taki będzie działał tak długo dopóki kolejka nie będzie pusta. Dodatkowo użytkownik może włączyć opcję wysyłania wiadomości poprzez przycisk enter. Jest to domyślne ustawienie. W momencie w którym otrzymamy wiadomość od jakiegoś użytkownika powiadomieni zostaniemy poprzez wyświetlenie specjalnego komunikatu w lewym dolnym rogu ekranu. Dodatkowo jeśli włączymy opcję dźwięku przy nowych wiadomościach powiadomienie nastąpi poprzez charakterystyczny dźwięk. Jeśli w jakimś przypadku rozmowy tekstowe okażą się nie wystarczające wówczas możemy użyć rysowania w czasie rzeczywistym. Oprócz zwykłego rysowania dodane zostały dodatkowe opcje rysowania figur oraz zmiany koloru. Rysowanie zostało zrealizowane na podstawie przesyłania punktów identyfikujących daną linię. Dany punkt zawiera informacje takie jak: początek/koniec lini, współrzędne i kolor punktu. Strona 72

73 Aby możliwe było odtworzenie narysowanych linii lub figur po zminimalizowaniu i zmaksymalizowaniu okna musiałem zapisywać wszystkie punkty i figury w listach. Zostało to zrealizowane na zasadzie, że każdy użytkownik ma swoją listę punktów i figur dzięki czemu nie pomieszają się punkty podczas odtwarzania figur i linii. Rysowanie zostało zrealizowane dzięki zdarzeniom takim jak: mousepressed - w momencie naciśnięcia przycisku myszki następuje zapis punktów do listy. mousedragged - w momencie przeciągania myszki po komponencie gdy wciśnięty jest przycisk myszy następuje zapis punktów do listy i wysłanie danych do serwera. Wysłanie danych możliwe jest tylko wtedy gdy mechanizm synchronizacji na to pozwala. mousereleased w momencie puszczenia przycisku myszki następuje wysłanie punktów do serwera jeśli mechanizm synchronizacji na to pozwala. Rysowanie figur zostało zrealizowane dzięki przesyłaniu punktów identyfikujących górny róg figury Wiadomości nieodebrane. Strona 73 W momencie gdy użytkownik jest niezalogowany istnieje możliwość wysyłania do niego wiadomości. Podczas najbliższego logowania zostaną do niego wysłane wszystkie wiadomości, których nie odebrał. W pamięci aplikacji klienckiej trzymana jest lista wiadomości nieodebranych posortowanych według nadawców. W powyższym pod rozdziale wspomniałem, że podczas opisywania wiadomości nieodebranych pokaże kod, który za zadanie ma pokazać co się dzieje jeśli szukane przez nas okno do rozmów jeszcze nie istnieje: //pobranie listy paneli ListOfMessagePanels messagepanel = ctx.getbean("messagepanels", ListOfMessagePanels.class); TalkWindow talkwind = null; int i = 0; int k = 0;

74 //szukanie panela for (MessagePanel panel : messagepanel.getlistofmessagepanels()) { if (panel.getnumber().equals(number)) { i = 1; break; i = 0; k++; Pierwsze pobierana jest lista paneli posortowanych według nadawców. Następnie szukany jest panel identyfikujący się unikatowym numerem konta nadawcy. W przypadku znalezienia danego panelu następuje: //pobranie wiadomości od danego użytkownika List<IncomingMessage> messages = messagepanel.getlistofmessagepanels().get(k).getmessages(); //utworzenie okna talkwind = new TalkWindow(recipients, ctx, number); //wypełnienie okna wiadomościami for (IncomingMessage message : messages) { while(talkwind.isbusy()){ continue; talkwind.setbusy(true); //nowy wątek new Thread(new ParseText(message.getMessage(), ctx, talkwind, createdata( clientname + " " + surname, message.getdata()))).start(); Pierwsze następuje pobranie wiadomości od danego nadawcy, który następnie wypełniany jest komponent JTextPane nowego okna. Ważną częścią tego kodu jest na pewno utworzenie nowego wątku, który ma za zadanie przeszukać wiadomość pod względem znaczników pogrubiających i ikon, które zostaną odpowiednio wstawione i wyświetlone. Strona 74

75 Zadania definiowane przez użytkownika. Kolejną funkcjonalnością jaką oferuje mój komunikator jest definiowanie zadań z określoną datą. W momencie gdy nadejdzie dzień, w którym mają zostać przypomniane zostaną wyświetlone na specjalnie do tego przygotowanym panelu. Panel ten zachowuje się jak wirtualny pulpit dzięki czemu możemy bez problemu przesuwać zadania według naszego uznania. Listę zadań klient otrzymuje od serwera w momencie zalogowania do systemu. W momencie tym dochodzi do wygenerowania zadań i utworzenia listy w których są przetrzymywane. Dodatkowo każde zadanie ma swoje własne współrzędne na panelu dzięki czemu można je łatwo ułożyć. Użytkownik ma możliwość: Dodawać nowe zadania, poprzez wypełnienie specjalnie przygotowanego do tego formularza zawierającego pola takie jak: tytuł, data i wiadomość zadania. Wyświetlić zadania wraz z szczegółami. Sortować zadania według przedziału czasowego. Podczas sortowania zadań sprawdzany jest przedział czasowy. Oznacza to, iż data początku nie może być większa niż data końca itp. Jeśli przedział czasowy będzie błędny wówczas użytkownik zostanie ujrzy odpowiedni komunikat. Wyświetlić wszystkie zadania. Usunąć istniejące zadanie. Poniżej przedstawiony został rysunek z przykładowymi zadaniami: Jak widzimy na panelu widoczne są dwa zadania oznaczone dwoma kolorami. Zadanie oznaczone kolorem zielonym wskazuje, że dana sprawa powinna zostać wykonana w danym dniu. Natomiast zadanie, które nie zostało wykonane w danym dniu z różnych Strona 75

76 przyczyn bądź zadania, które mają być wykonane w dniach następnych oznaczone zostały kolorem niebieskim. Aby uzyskać dostęp do informacji szczegółowych danego zadania należy kliknąć dwa razy lewym przyciskiem myszy na zadaniu. Wówczas ukaże się okno z informacjami takimi jak: tytuł, data przypomnienia, wiadomość zadania. Poniższy rysunek przedstawia przykładowe okno: Dodatkową opcją dostępna z tego miejsca jest usunięcie danego zadania z bazy danych i panelu Archiwum wiadomości. Użytkownik w każdym momencie ma możliwość przejrzeć wiadomości tekstowe umieszczone w archiwum. Ze względów bezpieczeństwa, archiwum wiadomości znajduje się po stronie serwera dzięki czemu poufne informacje pracowników danej firmy nie są publiczne. W momencie autoryzacji do systemu przez klienta, serwer przesyła wiadomości archiwalne. Następnie podczas tworzenia głównego okna aplikacji tworzone jest także Strona 76

77 archiwum na podstawie odebranych informacji. W czasie działaniu programu każda wysłana lub przysłana wiadomość trafia do archiwum. Poniżej zamieszczony został przykładowy obrazek ukazujący archiwum wiadomości: Jak możemy zauważyć archiwum zostało podzielone na trzy główne panele. Pierwszy z nich został podzielony na mniejsze panele dotyczące pracowników, z którymi w przeszłości rozmawialiśmy. Każdy z takich mniejszych paneli zawiera listę wiadomości posortowaną według dni wraz z informacjami dotyczącymi nadawcy. Jeśli klikniemy na jeden z takich mniejszych paneli wówczas wygenerowane zostaną panele z określonymi datami. W momencie kliknięcia na panel z datą następuje zapełnienie komponentu JTextPane wiadomościami tekstowymi. Strona 77

78 Zgłaszanie problemów administratorowi. W każdym momencie, użytkownik, który jest zalogowany do systemu może skorzystać z specjalnie przygotowanego panelu służącego do kontaktu z administratorem. Dzięki tej funkcjonalności, użytkownik może zgłosić błąd w działaniu aplikacji lub po prostu zadać pytanie odnośnie sposobu działania komunikatora. Poniżej zamieszczony został obrazek ukazujący wyżej wymieniony panel: Jak możemy zauważyć aby zadać pytanie lub zgłosić problem administratorowi musimy wypełnić dwa pola. Pola te są walidowane na tej samej zasadzie co podczas procesu rejestracji. W momencie kliknięcia przycisku Send następuje wysłanie do serwera żądania. Dopiero po stronie serwera odbywa się wysłanie a. Administrator w chwili wejścia na swoją skrzynkę pocztową dostaje a z informacjami dotyczącymi pytania i nadawcy dzięki czemu w każdej chwili może odesłać odpowiedź. Strona 78