Przygotowanie gruntu

To co nam będzie potrzebne to oczywiście Eclipse z wbudowaną lub doinstalowaną wtyczką WTP 3.1.1 (Web Tools Platform) oraz kontener serwletów Apache Tomcat 5.5 lub nowszy. Na chwile obecną dostępna jest dystrybucja Eclipse IDE for Java EE Developers, która ma wbudowaną wtyczkę WTP 3.1.1. Dystrybucja do ściągnięcia oczywiście ze strony www.eclipse.org/downloads.

Ok, zakładam, że masz już zainstalowanego Eclipsa i Tomcat’a. Ostatnią rzeczą przed właściwym tworzeniem Web Service’u będzie konfiguracja Tomcata pod Eclipsem. W tym celu przejdź do Windows -> Preferences -> Installed Runtimes i dodaj nowy serwer uruchomieniowy:  Apache Tomcat w wersji zgodnej z zainstalowaną.

Teraz możemy już tworzyć nasz przykładowy Web Service, którego zadaniem będzie tłumaczenie tekstu pisanego na alfabet Morsa i vice versa.

Tworzenie Web Service’u

Stwórzmy nowy projekt: File -> New -> Project -> Dynamic Web Project i nazwijmy go “MorseCodeService”.

Jeśli nie mamy żadnej głębszej potrzeby to możemy zostawić wszystkie pozostałe parametry z domyślnymi wartościami. U mnie wygląda to następująco:

Stwórzmy nową klasę java o nazwie MorseCode w pakiecie pl.smike.services, która będzie miała dwie metody txt2Morse i morse2Txt. Na postawie tej klasy stworzymy nasz Web Service.

MorseCode.java

Kliknij prawym przyciskiem myszy na plik MorseCode.java i wybierz New -> Other -> Web Service.

Upewnij się, że są zaznaczone obie metody klasy MorseCode.

Kliknij Next, w tym momencie kreator utworzy wszystkie potrzebne pliki i zależności do odpalenia Web Service’u. Na ekranie powinien pojawić sie przycisk Start Service, który należy wybrać.

Jeśli wszystko poszło prawidłowo i serwer odpalił się, dostępny będzie przycisk Next. Po jego użyciu nasz nowy serwis zostanie zdeployowany. Możemy zakończyć kreator -Finish.

W tym momencie nasz serwis powinien już być uruchomiony i prawidłowo działać. Dostępne, zdeployowane lokalnie serwisy w projekcie możemy sprawdzić pod adresem: http://localhost:8080/MorseCodeService/services

Tworzenie klienta Web Service’u

Naszego klienta stworzymy na podstawie pliku WSDL opisującego Web Service. Jest to o tyle dobre podejście, iż na ogół tworząc klienta Web Service’u posiadamy tylko plik WSDL.

Stwórzmy zatem nowy projekt: File -> New -> Project -> Dynamic Web Project i nazwijmy go “MorseCodeClient”. Wszystkie pozostałe parametry ustawmy takie jak w przypadku “MorseCodeService”.

Kliknij prawym przyciskiem myszy na nazwie projektu i wybierz New -> Other -> Web Service Client.

W polu Service Definition musimy podać plik wsdl. Kliknij Browse. W oknie, które nam sie pojawi moglibyśmy podać URL do tego pliku, ale możemy zrobić prościej i wybierzemy go z istniejącego projektu MorseCodeService. Kliknij zatem jeszcze raz na Browse i wybierz plik MorseCode.wsdl.

Ostatni krok przygotowujący klienta to umiejscowienie plików źródłowych. Zostawmy wartości domyśle i klikamy Finish. W tym momencie zostaną utworzone wszystkie potrzebne pliki i zależności do komunikacji z Web Service’em. Najważniejsza klasą, która nas będzie interesować jest MorseCodeProxy. To przy jej pomocy zdobędziemy referencje do klasy MorseCode lub wywołamy pośrednio metody z tej klasy.

Stwórzmy nową stronę index.jsp w katalogu WebContent (New -> Other -> JSP). Strona ta będzie interfejsem użytkownika naszego klienta.

index.jsp

Mając już interfejs użytkownika ostatnią rzeczą będzie stworzenie servletu, który będzie wywoływał Web Service. Wybierz New -> Other -> Servlet i nazwij go TranslateServlet i umieść w pakiecie pl.smike.servlets. Kreator zadba o odpowiednie wpisy w web.xml’u tak więc nie musisz sie o to martwić.

TranslateServlet.java

Jeśli wszystko poszło dobrze możemy odpalać i testować naszego klienta. Kliknij prawym przyciskiem myszy na nazwe projektu i wybierz: Run As -> Run on Server. Po zdeployowaniu naszej aplikacji na serwere wpisz w przeglądarce adres http://localhost:8080/MorseCodeClient/index.jsp . I to już wszystko.

Podsumowanie

Jak widać tworzenie Web Service’ów w Eclipsie jest rzeczą prostą i sprowadza się do wyklinania prawie wszystkiego. Tworząc w pełni funkcjonalny Web Service nie musimy się zagłebiać w szczegóły jego jego działania na serwerze, ani sposobu komunikacji z klientem.

• Po pierwsze integracja daje możliwość wykorzystania wszystkich dobrodziejstw jakie oferuje nam serwer Apache. A więc: obsługę CGI, PHP, Perla, obsługę modułów mod_rewrite, mod_headers, mod_expire.
• Po drugie mamy możliwość wydzielenia na Apache’u wirtualnych hostów, każdy z własną instancją Tomcata. Możemy również wybranym użytkownikom hostingu “podarować w prezencie” obsługę jsp i serwletów
• Po trzecie możemy wykorzystać mechanizm Load balancer, dzięki któremu obsługa żądań użytkowników będzie rozkładana na kilka instancji Tomcat’a. Zmniejszając tym samym obciążenie pojedynczego serwera.

Przygotowanie gruntu

Znając już powód, dla którego chcemy połączyć oba serwery przystąpmy do działania. Na wstępnie zaznaczam, że opisywana tu metoda połączenia powinna działać dla serwerów Tomcat 4.0 i nowszych oraz serwerów Apache 2.0 i nowszych. Ja osobiście używam Tomcat 5.5 oraz Apache 2.2. Zakładam, że posiadasz podstawową wiedzę na temat konfiguracji obu serwerów i masz już je zainstalowane na swoim dysku. Jeśli nie, odsyłam do oryginalnej dokumentacji tomcat.apache.org oraz httpd.apache.org.

To co nam będzie potrzebne do komunikacji obu serwerów to moduł Apache’a mod_jk do ściągnięcia w wersji skompilowanej «tutaj». Przy ściąganiu należy zwrócić uwagę na dwie rzeczy: jaki mamy system operacyjny oraz jaką mamy wersje Apache’a. Po ściągnięciu pliku zmieniamy jego nazwę na mod_jk.so i przenosimy do katalogu /modules/ (lub /libexec/ w przypadku Linux’a) znajdującego się w głównym katalogu Apache’a. Teraz pozostała nam już tylko czysta konfiguracja.

Stwórz nowy plik workers.properties i umieść go w katalogu /conf/ Apache’a. Plik ten będzie opisywał dostępne instancje Tomcatów oraz ich konfiguracje. W moim przypadku będzie to tylko jedna instancja.

workers.properties:

worker.list=worker1
 
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
worker.worker1.socket_timeout=2000

Objaśnienie:

• worker.list – określa listę dostępnych instancji Tomcata, dowolnie nazwanych.
• worker..type – określa typ konkretnego robotnika, w moim przypadku jest to robotnik, który będzie używał protokołu ajpv13 do komunikacji między serwerami.
• worker..host – określa nazwę hosta pod którym dostępny jest Tomcat.
• worker..port – port na którym nasłuchuje Tomcat. Domyślnie dla ajp13 jest to port 8009.
• worker..socker_timeout – czas oczekiwania na robotnika po upływnie, którego zgłoszony zostanie komunikat: server timeout.

Konfiguracja w pliku httpd.conf:

LoadModule jk_module modules/mod_jk.so
 
<IfModule jk_module>
  JkWorkersFile F:\Programy\Apache2.2\conf\workers.properties
  JkMount  /jsp-examples/* worker1
</IfModule>

Objaśnienie:

• JkWorkersFile – wskazuje plik opisujący robotników.
• JkMount – określa jaka ścieżka zostanie przekazana do jakiego robotnika. W moim przypadku wszystkie zapytania rozpoczynające sie od ścieżki http://localhost/jsp-examples/ będą obsługiwane przez worker1, czyli przez mojego Tomcata. Pozostałe zapytania będą obsługiwane przez Apache’a.

To już prawie wszystko. Sprawdźmy jeszcze czy connector ajp13 jest aktywny w Tomcat’ie i zakomentujmy connector odpowiedzialny za nasłuchiwanie Http. W tym celu w pliku server.xml, w katalogu /conf/ Tomcat’a, powinny znajdować się zapisy:

<Service name="Catalina">
 
  <!-- <Connector port="7080" maxHttpHeaderSize="8192" maxThreads="150" 
  minSpareThreads="25" maxSpareThreads="75" enableLookups="false" 
  redirectPort="8443" acceptCount="100" connectionTimeout="20000" 
  disableUploadTimeout="true" />
-->
 
  <Connector port="8009" enableLookups="false" redirectPort="8443" 
  protocol="AJP/1.3" />
 
 
</Service>

Show time

Teraz pozostało już nam tylko odpalić Apache’a, a następnie odpalić Tomcat’a. Spróbuj uruchomić adres http://localhost/ oraz http://localhost/jsp-examples. Jeśli wszystko działa, gratuluje udało się połączyć oba serwery!!!

Na koniec chciałbym zaznaczyć, że przedstawiona tu konfiguracja to minimum niezbędne aby oba serwery współpracowały. Możliwości konfiguracyjnych jest oczywiście znacznie więcej. Po szczegóły odsyłam do oryginalnej dokumentacji: The Apache Tomcat Connector oraz Workers How To.

Tak więc przedstawiam niezbędne minimum webdevelopera:

• Firebug – Jest to kompleksowe narzędzie umożliwiające łatwe przeglądanie kodu źródłowego strony, debugowanie kodu JavaScript, podgląd i edycje w locie styli CSS, podgląd obiektów DOM, podgląd nagłówków HTTP. Możliwości Firebuga jest naprawdę dużo. Jeśli ktoś jeszcze nie używa niech czym prędzej instaluje !!!
• Web Developer – Na plugin składa się kilkadziesiąt małych ale za to bardzo przydatnych narzędzi. Począwszy od wyłączenia całkowitego cache’u, poprzez czyszczenie sesji, operacje na formularzach typu aktywowanie zdisablowanych pól, tworzenie podsumowań pól formularzy, wyświetlanie informacji o rozmiarach obrazków, mierzenia rozmiaru strony za pomocą linijek, a skończywszy na podglądzie kodu wygenerowanego JavaScriptem. To tylko nieliczne z przydatnych drobiazgów, które ułatwiają życie.
• ColorZilla – Małe ale bardzo fajne narzędzie do pobierania informacji o kolorze z dowolnego elementu strony www. Pobrany kolor może być zapisany do schowka w rozmaitych formatach.
• iMacros – Automatyzuje procesy wypełniania formularzy, odwiedzania ciągle tych samych stron internetowych, wpisywania haseł, klikania ciągle tych samych przycisków. Doskonale nadaje się do testowania formularzy. Makra mogą być tworzone automatycznie (nagrywane) lub pisane ręcznie (co daje dość spore możliwości).
  
• Live HTTP Headers – Plugin rejestrujący wszelkie nagłówki HTTP wysyłane i odbierane z przeglądarki. Umożliwia również wysyłanie własnych, zmodyfikowanych nagłówków.
• EditCSS (opcjonalnie) – Plugin umożliwiający modyfikacje styli CSS w locie. Działa trochę bardziej niezawodnie aniżeli edytor dostępny w Firebug’u.

Dodatki ułatwiające życie:

• Mouse Gestures (opcjonalnie) – Jest to plugin umożliwiający sterowanie przeglądarką za pomocą gestów myszki. Osobiście używam tylko dwóch gestów (”poprzednia strona”, “następna strona”) ale chociażby tylko dla nich warto zainstalować.
• Adblock Plus (opcjonalnie) – Ogranicza spam i reklamy na stronach.

Podsumowując:
Jeśli ktoś zajmuje się poważnie tworzeniem stron/aplikacji internetowych zapewne zna większość przedstawionych tu pluginów. Dla tych którzy dopiero rozpoczynają przygodę z programowaniem sieci powyższe pluginy będą bardzo pomocne i zachęcam do ich instalacji.