Wydział Matematyki i Informatyki Uniwersytetu Łódzkiego www.math.uni.lodz.pl/ radmat radmat@math.uni.lodz.pl
Serwer aplikacji Serwer aplikacji to: Serwer wchodzący w skład sieci komputerowej, przeznaczony do zdalnego uruchamiania i użytkowania aplikacji. Zestaw oprogramowania (platforma) wspierająca programistę / developera przy tworzeniu aplikacji. Umożliwia oddzielenie logiki biznesowej od usług dostarczanych przez producenta platformy (bezpieczeństwo, zarządzanie transakcjami, skalowalność, czy też dostęp do baz danych). Do serwerów aplikacji należą m.in.: JBoss, BEA WebLogic, IBM WebSphere oraz platforma.net Microsoftu. Program działający na zdalnej maszynie obsługujący żądania kierowane do aplikacji, do której dostęp zapewnia. Użytkownik łączy się za pośrednictwem przeglądarki internetowej, kieruje żądanie do wybranej aplikacji, a całość operacji odbywa się po stronie usługodawcy serwera.
Architektura WWW Rysunek: Architektura
Realizacja aplikacji WWW wymaga zastosowania rozszerzonej architektury WWW, w skład której wchodzą trzy programowe warstwy funkcjonalne: warstwa klienta warstwa aplikacji warstwa danych
Architektura serwerów aplikacji Kluczowym składnikiem rozszerzonej architektury WWW, umożliwiającym wykonywanie aplikacji WWW, jest serwer aplikacji. Serwer aplikacji jest oprogramowaniem o charakterze systemowym, które odpowiada m.in. za obsługę komunikacji z warstwą klienta i warstwą danych. Dzięki temu programista tworzący aplikacje WWW nie musi samodzielnie implementować kodu obsługi protokołu HTTP (z klientem HTTP) ani kodu obsługi komunikacji SQL (z serwerem bazy danych).
1 Warstwa kliencka aplikacje klienckie aplety 2 Warstwa webowa Java Servlet Java Server Pages Java Server Faces 3 Warstwa serwerowa Enterprise Java Beans 4 Wymiana danych pomiędzy warstwami
Architektura czterowarstwowa Architektura czterowarstwowa (4-tier architecture) zakłada, że komponenty aplikacji WWW dzielą się na dwie grupy: komponenty logiki prezentacji i komponenty logiki biznesowej.
Architektura Model-View-Controller Architektura Model-View-Controller zakłada, że komponenty aplikacji WWW dzielą się na trzy grupy: komponenty sterujące (controller), komponenty prezentacji (view) i komponenty modelu (model).
Rodzaje serwerów aplikacji Apache Tomcat GlassFish Bea Weblogic ZOPE (Z Object Publishing Environment) Windows 2003 Server.Net
Usługi serwerów aplikacji pule zasobów (na przykład pule bazy danych i pule obiektów) rozproszone zarządzanie transakcjami asynchroniczna komunikacja programowa, zazwyczaj poprzez kolejkowanie wiadomości dokładnie zsynchronizowany model aktywacji obiektu automatyczne interfejsy usług sieci Web XML umożliwiające dostęp do obiektów biznesowych usługi wykrywania awarii i stanu aplikacji zintegrowane zabezpieczenia
Klienci serwerów aplikacji 1 Klient HTML: statyczny brak lub minimalna logika porozumiewa się za pośrednictwem HTTP 2 Klient Java aplet java+html własna logika porozumiewa się za pośrednictwem IIOP lub JRMI
Zalety serwerów aplikacji niski koszt utrzymania klienta obsługa standardów otwartych szerokie możliwości generowania i publikowania informacji
Wymagania stawiane serwerom aplikacji integralność transakcji skalowalność, wydajność stabilność otwartość (w sensie obsługi standardów) bezpieczeństwo ochrona inwestycji
Cechy serwerów aplikacji umożliwia tworzenie i obsługę aplikacji napisanych m.in. w C, C++, Javie obsługuje wydajnie transakcyjne relacyjne bazy danych, jest niezależny od producenta bazy oferuje dużą skalowalność (obsługa klastrów) zapewnia zintegrowane, zcentralizowane zarządzanie obsługuje standardy: HTTP, HTML, CGI, NSAPI (Netscape), ISAPI (Microsoft), Java zawiera środowisko do tworzenia, testowania, wdrażania i zarządzania aplikacjami
Pliki konfiguracyjne w katalogu conf server.xml tomcat-users.xml web.xml
Pliki konfiguracyjne w katalogu logs catalina.2016-02-20.log localhost access log.2016-02-20
Java Enterprise Edition Java Enterprise Edition (w skrócie J EE) jest standardem tworzenia zorientowanych na usługi aplikacji biznesowych (Service Oriented Architecture), utworzonym na bazie języka Java i technologii Java 2 Standard Edition. W praktyce jest to pewien zbiór (pakiet) różnorodnych technologii i frameworków, który umożliwia tworzenie aplikacji.
Aplikacje webowe korzystają z grupy tych samych elementów, z których korzystają aplikacje biznesowe. Jednak formalnie aplikacje webowe powinny korzystać jedynie z: JavaServer Faces JavaServer Pages JavaServer Pages Standard Tag Library Java Servlet Jednym z najważniejszych elementów, które odróżniają aplikacje J EE od innych, jest konieczność ich uruchamiania na specjalnych serwerach aplikacji. Do aplikacji biznesowych często wykorzystywany jest serwer GlassFish, który oczywiście obsługuje także technologię EJB.
Układ katalogów projektu w Netbeansie Struktura stworzonego za pomocą Netbeansa projektu jest następująca: 1 Web Pages META-INF WEB-INF 2 Source Packages 3 Libraries
Serwlety Serwlet w Javie jest klasą, która rozszerza możliwości serwera aplikacji. Praktycznie jedynym wymaganiem jest, aby serwlet działał w trybie żądanie - odpowiedź. Serwlet wykonuje się w środowisku serwera WWW (aplikacji) i nie może funkcjonować autonomicznie. Serwer WWW musi zapewniać obsługę serwletów Java.
Hierarchia dziedziczenia Interfejs Servlet Abstrakcyjna klasa GenericServlet Klasa HttpServlet
Metody do* doget() dopost() dohead() dotrace() doput() dodelete() dooptions() doconnect()
Interfejs HttpServletRequest Najbardziej istotne metody interfejsu HttpServletRequest: Object getparameter(string nazwa) Enumeration<String> getparameternames() String getremoteuser() Cookie[] getcookies() String getheader(string nazwa)
int getintheader(string nazwa) long getdataheader(string nazwa) String getcontextpath() String getservletpath() String getpathinfo()
Interfejs HttpServletResponse Najbardziej istotne operacje, które będziemy wykonywać przesyłając odpowiedź klientowi (dzięki interfejsowi HttpServletRequest): przesyłanie odpowiedzi w postaci danych tekstowych lub binarnych tworzenie i przesyłanie ciasteczek dodawanie do odpowiedzi dowolnych nagłówków przekierowywanie żadań lub przesyłanie kodów błędu
Życie serwletu W chwili uruchomienia aplikacji serwer aplikacji podejmuje następujące działania: załadowanie klasy serwletu utworzenie instancji serwletu wywołanie metody init() wywołanie metody service()
Struktura serwletu protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { processrequest(request, response); }
protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { processrequest(request, response); } public String getservletinfo() { return "Short description"; }
Zalety i wady serwletu 1 Zalety: dostępne funkcje do obsługi typowych czynności mechanizm stosunkowo ustandaryzowany mechanizm uniwersalny i łatwo rozszerzalny stosunkowo bezpieczne 2 Wady: w bardziej złożonych środowiskach wydajność może pozostawiać wiele do życzenia (wymagania na RAM, garbage collection) występują istotne różnice pomiędzy różnymi środowiskami bazującymi na serwletach (np. por. - Tomcat, Oracle App. Server, IBM Websphere)
Żądanie - odpowiedź W przypadku żądania mamy do czynienia z odczytem nagłówków i ciasteczek, które przesyłane są przez klienta. Natomiast w przypadku odpowiedzi występuje proces odwrotny. Mamy do dyspozycji dwie metody: void addheader(string nazwa, String wartość) void setheader(string nazwa, String wartość)
Do obowiązków odpowiedzi HTTP należy także przekazywanie kodów odpowiedzi, jeśli chcemy zaznaczyć, że odpowiedź nie zostanie zakończona w zwykły sposób. Kod odpowiedzi przekazujemy wykorzystując metodę void setstatus(int kod). W przypadku błędów (np. brak zasobu - kod błędu 404) należy wykorzystywać metody void senderror(int kod) lub void senderror(int kod, String komunikat)
Korzystając z metod senderror() i sendredirect() należy pamiętać o kwestiach związanych z fizycznym przesyłaniem danych do klienta. Zauważmy, że przesyłanie komunikatów o błędach lub przekierowań stanowi ingerencję w sam proces przesyłania odpowiedzi. Proces odpowiedzi jest natychmiast przerywany, a klient otrzymuje komunikat z wybranym kodem odpowiedzi. Jeśli jednak zdążymy wysłać już do klienta jakieś dane, nastąpi błąd. Po wysłaniu danych nie można bowiem ingerować w treść nagłówków, czyli nie można także ustawić kodu odpowiedzi.
Nagłówki Accept. Ten nagłówek określa typy MIME, jakie przeglądarka lub inny program jest w stanie obsługiwać Accept-Encoding. Ten nagłówek podaje typy kodowania, które klient jest w stanie obsługiwać. Connection. Ten nagłówek zawiera informację czy klient jest w stanie obsługiwać trwałe połączenia HTTP. Cookie. Nagłówek ten jest stosowany do przekazania na serwer WWW cookies, które wcześniej serwer ten przesłał do przeglądarki.
Host. Przeglądarki muszą generować ten nagłówek, ponieważ zawiera on określenie komputera (host) oraz numer portu podany w adresie URL. Referer. Ten nagłówek zawiera adres URL strony z jakiej zostało przesłane żądanie. User-Agent. Ten nagłówek określa jaka przeglądarka lub program nadesłał żądanie.
Choć użycie metody getheader jest ogólnym sposobem odczytywania wartości nagłówków żądania, to jednak wartości niektórych nagłówków są pobierane tak często, że interfejs HttpServletRequest udostępnia specjalne metody pozwalające na dostęp do tych wartości. getcookies - metoda ta przetwarza zawartość nagłówka Cookie i zwraca ją w postaci tablicy obiektów Cookie. getauthtype oraz getremoteuser - metody te dzielą nagłówek Authorization na elementy składowe. getcontentlength - metoda ta zwraca wartość nagłówka Content-Length w formie liczby całkowitej (typu int). getcontenttype - metoda ta zwraca obiekt String zawierający wartość nagłówka Content-Type.
getdateheader oraz getintheader - metody te odczytują wartość nagłówka o podanej nazwie i zwracają ją odpowiednio jako wartość typu Date oraz typu int. getheadernames - metoda ta zwraca obiekt Enumeration. Zamiast pobierać wartość konkretnego nagłówka, można stworzyć listę nazw wszystkich nagłówków umieszczonych w danym żądaniu. getheaders - w większości przypadków nazwa konkretnego nagłówka pojawia się w danym żądaniu tylko raz. Jednak od czasu do czasu, ten sam nagłówek może się pojawić w żądaniu kilka razy, a za każdym razem jego wartość może być różna.
getmethod - zwraca metodę żądania (zazwyczaj jest to wartość GET lub POST, jednak mogą się także pojawić wartości HEAD, PUT bądź DELETE). getrequesturi - metoda ta zwraca fragment adresu URL znajdujący się za nazwą komputera i numerem portu oraz przed danymi pochodzącymi z formularza. getprotocol - metoda ta zwraca część wiersza żądania, określającą używany protokół.
Ciasteczka Ciasteczka (cookies) są to niewielkie pliki przechowywane na komputerach użytkowników aplikacji webowych, dzięki czemu mamy mozliwość zapamiętania ich preferencji, loginów, haseł, itp. Utworzenie ciasteczka wymaga podania jego nazwy i wartości, jaką ma posiadać: Cookie c=new Cookie( mojeciasteczko, wartość ). Wysłanie ciasteczka realizowane jest za pomocą metody response.addcookie(c). Stworzone ciasteczka są dostępne za pomocą Cookie[] c=request.getcookies().
Dostępne są następujące metody ciasteczek: setname() getname() setvalue() getvalue() setmaxage() getmaxage() setpath() getpath()
Korzyści związane ze stosowania ciasteczek: identyfikacja użytkowników podczas trwania sesji w witrynach komercyjnych unikanie konieczności podawania nazwy użytkownika i hasła dostosowywanie witryny dobór reklam
Kilka ciekawostek: Ciasteczka w żaden sposób nie są ani interpretowane, ani wykonywane, w związku z czym nie można ich użyć do przekazania wirusa lub zaatakowania komputera. Przeglądarki internetowe akceptują zazwyczaj 20 ciasteczek pochodzących z jednej witryny i nie więcej, niż 300 łącznie. Pojedyncze ciasteczko nie może mieć więcej, niż 4kB wielkości. Ciasteczka nie mogą przechowywać ważnych informacji - danych personalnych, numerów kart kredytowych, itp. Działanie strony nie może zależeć od tego, czy przeglądarka użytkownika obsługuje ciasteczka.
Sesje Obsługa sesji jest nieodłącznym elementem większości aplikacji webowych. Służy zapisywaniu informacji o poszczególnych klientach odwiedzających daną stronę. Informacje te zapisywane są na serwerze i identyfikowane przez odpowiednie ciasteczko wysyłane do klienta. W celu uzyskania obiektu sesji z serwletu należy posłużyć się odpowiednią metodą obiektu klasy request: HttpSession getsession() lub HttpSession getsession(boolean czytworzyc).
Wybrane metody klasy HttpSession: getattributenames() setattribute(string nazwa, Object wartość) getattribute(string nazwa) getid() getcreationtime() getlastaccessedtime() setmaxinactivetime() getmaxinactivetime() invalidate() isnew() removeattribute()
Warunki zakończenia sesji: ręczne zakończenie sesji przez programistę upłynięcie czasu życia sesji zamknięcie okna przeglądarki przez użytkownika
Metody obsługi sesji: w elemencie HIDDEN (dla metody GET ma ograniczoną wielkość, istnieje także ryzyko manipulacji przez klienta) w cookie (ograniczona wielkość, limitowana przez ciasteczko; również istnieje ryzyko manipulacji przez klienta) w obiekcie serwera (dla bezpiecznych aplikacji zaleca się stosowanie protokołu HTTPS)
Kontekst serwletów Kontekst serwletów to obiekt, który służy do komunikacji serwletów z kontenerem. Dzięki niemu można: dynamicznie dodawać serwlety do aplikacji uzyskiwać dostęp do zasobów znajdujących się w obrębie aplikacji zapisywać logi do dziennika znajdującego się na serwerze korzystać z parametrów aplikacji webowej (kontekstu)
Atrybuty Najważniejszym środkiem komunikacji pomiędzy poszczególnymi elementami aplikacji (serwletem, kontenerem, sesją, użytkownikiem i obiektem żądania) są atrybuty. Zestawienie parametrów i atrybutów: Parametry Atrybuty Zakres Zapis Odczyt Zapis Odczyt Żądanie NIE TAK TAK TAK Serwlet NIE TAK BRAK BRAK Sesja BRAK BRAK TAK TAK Kontekst TAK TAK TAK TAK
Atrybuty, a mnogość żądań Jedna aplikacja webowa może być obsługiwana przez nawet tysiące użytkowników jednocześnie. Każde żądanie HTTP request obsługiwane jest przez kontener w osobnym wątku. Niezwykle istotną kwestią jest zapewnienie integralności operacji wykonywanych przez każdego z użytkowników. Oczywiście nie może się zdarzyć, że operacje wykonywane przez jednego użytkownika mają wpływ na operacje wykonywane przez innego. Problem ten praktycznie nie występuje w przypadku parametrów.
Atrybuty sesji Jedna sesja jest powiązana z jednym użytkownikiem. Może się jednak zdarzyć, że użytkownik uruchomi ten sam serwlet w dwóch zakładkach w przeglądarce internetowej i będzie próbował przy pomocy tego serwletu zapisać jakieś informacje. W tym przypadku nastąpiłby jednoczesny dostęp do sesji. Aby rozwiązać ten problem należy skorzystać ze standardowego mechanizmu Javy, jakim jest synchronizacja.
HttpSession sesja=request.getsession(): synchronized(sesja) { if(sesja.isnew()) sesja.setattribute("licznik",1); else { int licznik=integer.parseinteger( sesja.getattribute("licznik").tostring()); sesja.setattribute("licznik",licznik+1); } }
Atrybuty kontekstu serwletów Największe niebezpieczeństwo niesie ze sobą korzystanie z atrybutów należących do kontekstu serwletów. Każdy taki atrybut może być odczytany i zmodyfikowany niemal w dowolnym miejscu aplikacji. Z tego względu każda próba korzystania z atrybutów (szczególnie zapisu) powinna być zsynchronizowana.
ServletContext s=this.getservletcontext(): synchronized(s); { Object licznik=sc.getattribute("licznik"); if(licznik==null) sc.setattribute("licznik",1); else { licznik=sc.getattribute("licznik"); sc.setattribute("licznik",integer.parseint (licznik.tostring())+1); } }
Filtry Filtry umożliwiają wykonywanie operacji w momencie nadejścia żądań do serwletów i wygenerowania przez nie odpowiedzi. Nie ingerują jednak w działanie samego serwletu. Można w związku z tym np. zapisać w dzienniku datę każdego żądania, czy też jakie są jego parametry. Dzięki filtrom można skompresować treść odpowiedzi, zanim zostanie ostatecznie przesłana do klienta, a także np. odrzucać żądania, które nie spełniają określonych warunków. Największą zaletą filtrów jest możliwość podłączenia ich do dowolnej grupy serwletów. Filtry są łączone z serwletami za pomocą znacznika url-pattern, który działa analogicznie, jak w przypadku serwletów.
Filtr jest klasą implementującą interfejs javax.servlet.filter. Interfejs ten składa się z następujących metod: void init(filterconfig c) void dofilter(servletrequest request, ServletResponse response, FilterChain chain) void destroy()