[ Pobierz całość w formacie PDF ]
.Tak więc przed zakończeniem dyskusji na tematkomunikacji aplet-serwlet przedstawiony zostanie przykład bardziej skomplikowany serwer pogawędek(chat), zaimplementowany jako serwlet, który obsługuje klientów łączących się przez HTTP, porty nie-HTTP iRMI. Ten serwer pogawędek zostanie utworzony przy pomocy wszystkich trzech technik komunikacji, aby mógłkorzystać z zalet najlepszego, najbardziej wydajnego rozwiązania dla każdego klienta.Na przykład, kiedy klientobsługuje RMI, serwlet może być traktowany jako obiekt zdalny, a (gdzie to możliwe) może traktować apletrównież jako zdalny obiekt.Kiedy klient nie obsługuje HTTP, ale obsługuje bezpośrednie połączenia przez port,serwer pogawędek może skorzystać z trwałości portów i łączyć się z klientem przy pomocy protokołu portu niebędącego HTTP.I, oczywiście, jeżeli inne techniki zawiodą, serwer pogawędek wykorzystać HTTP.Nie jest topolecane, ponieważ HTTP jako protokół bezstanowy wymaga od klienta aktywności w celu dokonaniauaktualnień.Lecz dla wielu klientów HTTP jest jedynym możliwym rozwiązaniem.Serwer pogawędek jest implementowany jako pojedyncza klasa z pojedynczym egzemplarzowaniem, ponieważposiada on dużą ilość związanych ze sobą danych i sporą ilość kodu, który musiałby być powtarzany.Podzielenie go na trzy klasy, jedną dla każdego protokołu, wymagałoby nadmiernej komunikacji między nimi itrzykrotnego powtarzania podstawowego kodu serwera pogawędek.Implementacja serwera pogawędek jakoserwletu dostarcza prostej metody udostępnienia jednego obiektu przy pomocy wszystkich trzech technikkomunikacji.Jako że jest on serwletem HTTP, posiada wbudowaną obsługę HTTP.A dzięki temu, że jestrozszerzeniem klasy RemoteDaemonHttpServlet, może również łatwo uzyskać możliwość obsługi portównie-HTTP i komunikacji RMI.Proszę zauważyć, że chociaż kod zostanie przedstawiony w całości, nie zostanie wyjaśniona każda pojedynczalinia.Spowodowałoby to powiększenie niniejszego rozdziału poza rozsądny rozmiar, jeżeli się to już nie stało.Tak więc zostaną wyjaśnione kwestie ściśle związane z komunikacją aplet-serwlet, a analiza kodu i zrozumieniewszystkich szczegółów będą pozostawione Czytelnikowi.ProjektRysunek 10.3 przedstawia aplet pogawędek w działaniu.Proszę zauważyć, że wykorzystuje on duży elementTextArea w celu wyświetlenia toczącej się konwersacji.Mały element TextArea poniżej służyużytkownikowi do wpisywania i wysyłania jednolinijkowych wiadomości.Kiedy dowolny użytkownik wpiszewiadomość zostaje ona wysłana do serwera i rozprowadzona na różne sposoby do innych klientów.Rysunek 10.3.Aplet pogawędek w działaniuKlienci HTTP wysyłają swoje wiadomości na serwer przy pomoc metody HTTP POST.Aplet pobiera nowąwiadomość z elementu TextInput, kiedy użytkownik naciska Enter, koduje wiadomość w URL-u i wysyła jądo serwletu jako parametr wiadomości.Jest to działanie bardzo proste.Nieco bardziej skomplikowany jestsposób zarządzania pobieraniem wiadomości od innych użytkowników przez klienta pogawędek HTTP.Wykorzystuje on metodę HTTP GET do odebrania każdej wiadomości, występuje jednak pewien problem: niewie on, kiedy pojawia się nowa wiadomość do odebrania.Jest to problem związany z paradygmatemjednokierunkowej komunikacji żądanie/odpowiedz.Klient musi albo od czasu do czasu wysłać jakąś wiadomość w celu uaktualnienia, lub symulować komunikację dwukierunkową przy pomocy serii blokujących żądań GET.Oznacza to, że klient pogawędek inicjuje żądanie GET, które działa blokująco, dopóki serwer nie zdecyduje, żenadszedł czas na zwrócenie jakiejś informacji.W niniejszym przykładzie zaimplementowana zostanie tasymulowana komunikacja dwukierunkowa.Klienci uzyskujący dostęp przez port, w celu zachowania spójności, wysyłają swoje wiadomości w identycznysposób jak klienci HTTP, przy pomocy metody HTTP POST.Mogą oni wysyłać swoje wiadomości przypomocy połączeń przez zwykły port, lecz daje to jedynie minimalny zysk w wydajności, który, przynajmniej wtym przypadku, nie przeważa zwiększonej złożoności.Klienci korzystający ze zwykłych portów wykorzystują jejednak do odbierania wiadomości od innych użytkowników.W tym przypadku symulowana łącznośćdwukierunkowa zostaje zastąpiona przez komunikację prawdziwą.Kiedy dowolna nowa wiadomość jestodbierana przez serwlet, jest wysyłana bezpośrednio z serwletu do klientów korzystających z portów przypomocy opartych na zwykłym tekście połączeń przez port.Klienci pogawędek RMI wykonują swoje żądania POST i GET przy pomocy wywołań metod.Aby wysłać nowąwiadomość, aplet po prostu wywołuje metodę zdalnego serwletu nadajWiadomosc(String).Aby odebraćnowe wiadomości, może zastosować jedną z dwóch opcji.Może wywołać blokującą serwlet metodępobierzNastepnaWiadomosc() lub, przy pomocy wywołań wstecznych, może poprosić serwer owywołanie swojej własnej metody ustawNastepnaWiadomosc(String) za każdym razem, kiedy nadanazostaje nowa wiadomość.W niniejszym przykładzie zastosowana zostanie technika wywołań wstecznych.Pierwszym z wszystkich powyższych apletów jest aplet-dyspozytor.Pozwala on użytkownikowi na wybórtechniki komunikacji aplet-serwlet (HTTP, port lub RMI), któryą chce on wykorzystać i, w oparciu o jegowybór, generuje stronę zawierającą właściwy aplet.Prawdą jest, że pojedynczy aplet mógłby obsługiwaćwszystkie te trzy techniki i automatycznie wybierać między nimi w oparciu o środowisko uruchomieniowe, leczdziałanie takie w tym miejscu jedynie niepotrzebnie skomplikowałoby przykład.Serwlet-dyspozytor podajerównież apletowi nazwę jego użytkownika, zostanie to jednak opisane pózniej.SerwletPełne wydruki interfejsu SerwerPogaw i klasy SerwletPogaw, która go wykorzystuje są przedstawione wprzykładach 10.15 i 10.16.Przykład 10.15.Interfejs SerwerPogaw, wykorzystywany przez SerwletPogawimport java.rmi.Remote;import java.rmi.RemoteException;public interface SerwerPogaw extends Remote {public String pobierzNastepnaWiadomosc() throws RemoteException;public void nadajWiadomosc(String message) throws RemoteException;public void dodajKlient(KlientPogaw klient) throws RemoteException;public void usunKlient(KlientPogaw klient) throws RemoteException;}Przykład 10.16.W pełni funkcjonalny serwer-serwlet pogawędekimport java.io.*;import java.net.*;import java.rmi.*;import java.util.*;import javax.servlet.*;import javax.servlet.http.*;import com.oreilly.servlet [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl odbijak.htw.pl
.Tak więc przed zakończeniem dyskusji na tematkomunikacji aplet-serwlet przedstawiony zostanie przykład bardziej skomplikowany serwer pogawędek(chat), zaimplementowany jako serwlet, który obsługuje klientów łączących się przez HTTP, porty nie-HTTP iRMI. Ten serwer pogawędek zostanie utworzony przy pomocy wszystkich trzech technik komunikacji, aby mógłkorzystać z zalet najlepszego, najbardziej wydajnego rozwiązania dla każdego klienta.Na przykład, kiedy klientobsługuje RMI, serwlet może być traktowany jako obiekt zdalny, a (gdzie to możliwe) może traktować apletrównież jako zdalny obiekt.Kiedy klient nie obsługuje HTTP, ale obsługuje bezpośrednie połączenia przez port,serwer pogawędek może skorzystać z trwałości portów i łączyć się z klientem przy pomocy protokołu portu niebędącego HTTP.I, oczywiście, jeżeli inne techniki zawiodą, serwer pogawędek wykorzystać HTTP.Nie jest topolecane, ponieważ HTTP jako protokół bezstanowy wymaga od klienta aktywności w celu dokonaniauaktualnień.Lecz dla wielu klientów HTTP jest jedynym możliwym rozwiązaniem.Serwer pogawędek jest implementowany jako pojedyncza klasa z pojedynczym egzemplarzowaniem, ponieważposiada on dużą ilość związanych ze sobą danych i sporą ilość kodu, który musiałby być powtarzany.Podzielenie go na trzy klasy, jedną dla każdego protokołu, wymagałoby nadmiernej komunikacji między nimi itrzykrotnego powtarzania podstawowego kodu serwera pogawędek.Implementacja serwera pogawędek jakoserwletu dostarcza prostej metody udostępnienia jednego obiektu przy pomocy wszystkich trzech technikkomunikacji.Jako że jest on serwletem HTTP, posiada wbudowaną obsługę HTTP.A dzięki temu, że jestrozszerzeniem klasy RemoteDaemonHttpServlet, może również łatwo uzyskać możliwość obsługi portównie-HTTP i komunikacji RMI.Proszę zauważyć, że chociaż kod zostanie przedstawiony w całości, nie zostanie wyjaśniona każda pojedynczalinia.Spowodowałoby to powiększenie niniejszego rozdziału poza rozsądny rozmiar, jeżeli się to już nie stało.Tak więc zostaną wyjaśnione kwestie ściśle związane z komunikacją aplet-serwlet, a analiza kodu i zrozumieniewszystkich szczegółów będą pozostawione Czytelnikowi.ProjektRysunek 10.3 przedstawia aplet pogawędek w działaniu.Proszę zauważyć, że wykorzystuje on duży elementTextArea w celu wyświetlenia toczącej się konwersacji.Mały element TextArea poniżej służyużytkownikowi do wpisywania i wysyłania jednolinijkowych wiadomości.Kiedy dowolny użytkownik wpiszewiadomość zostaje ona wysłana do serwera i rozprowadzona na różne sposoby do innych klientów.Rysunek 10.3.Aplet pogawędek w działaniuKlienci HTTP wysyłają swoje wiadomości na serwer przy pomoc metody HTTP POST.Aplet pobiera nowąwiadomość z elementu TextInput, kiedy użytkownik naciska Enter, koduje wiadomość w URL-u i wysyła jądo serwletu jako parametr wiadomości.Jest to działanie bardzo proste.Nieco bardziej skomplikowany jestsposób zarządzania pobieraniem wiadomości od innych użytkowników przez klienta pogawędek HTTP.Wykorzystuje on metodę HTTP GET do odebrania każdej wiadomości, występuje jednak pewien problem: niewie on, kiedy pojawia się nowa wiadomość do odebrania.Jest to problem związany z paradygmatemjednokierunkowej komunikacji żądanie/odpowiedz.Klient musi albo od czasu do czasu wysłać jakąś wiadomość w celu uaktualnienia, lub symulować komunikację dwukierunkową przy pomocy serii blokujących żądań GET.Oznacza to, że klient pogawędek inicjuje żądanie GET, które działa blokująco, dopóki serwer nie zdecyduje, żenadszedł czas na zwrócenie jakiejś informacji.W niniejszym przykładzie zaimplementowana zostanie tasymulowana komunikacja dwukierunkowa.Klienci uzyskujący dostęp przez port, w celu zachowania spójności, wysyłają swoje wiadomości w identycznysposób jak klienci HTTP, przy pomocy metody HTTP POST.Mogą oni wysyłać swoje wiadomości przypomocy połączeń przez zwykły port, lecz daje to jedynie minimalny zysk w wydajności, który, przynajmniej wtym przypadku, nie przeważa zwiększonej złożoności.Klienci korzystający ze zwykłych portów wykorzystują jejednak do odbierania wiadomości od innych użytkowników.W tym przypadku symulowana łącznośćdwukierunkowa zostaje zastąpiona przez komunikację prawdziwą.Kiedy dowolna nowa wiadomość jestodbierana przez serwlet, jest wysyłana bezpośrednio z serwletu do klientów korzystających z portów przypomocy opartych na zwykłym tekście połączeń przez port.Klienci pogawędek RMI wykonują swoje żądania POST i GET przy pomocy wywołań metod.Aby wysłać nowąwiadomość, aplet po prostu wywołuje metodę zdalnego serwletu nadajWiadomosc(String).Aby odebraćnowe wiadomości, może zastosować jedną z dwóch opcji.Może wywołać blokującą serwlet metodępobierzNastepnaWiadomosc() lub, przy pomocy wywołań wstecznych, może poprosić serwer owywołanie swojej własnej metody ustawNastepnaWiadomosc(String) za każdym razem, kiedy nadanazostaje nowa wiadomość.W niniejszym przykładzie zastosowana zostanie technika wywołań wstecznych.Pierwszym z wszystkich powyższych apletów jest aplet-dyspozytor.Pozwala on użytkownikowi na wybórtechniki komunikacji aplet-serwlet (HTTP, port lub RMI), któryą chce on wykorzystać i, w oparciu o jegowybór, generuje stronę zawierającą właściwy aplet.Prawdą jest, że pojedynczy aplet mógłby obsługiwaćwszystkie te trzy techniki i automatycznie wybierać między nimi w oparciu o środowisko uruchomieniowe, leczdziałanie takie w tym miejscu jedynie niepotrzebnie skomplikowałoby przykład.Serwlet-dyspozytor podajerównież apletowi nazwę jego użytkownika, zostanie to jednak opisane pózniej.SerwletPełne wydruki interfejsu SerwerPogaw i klasy SerwletPogaw, która go wykorzystuje są przedstawione wprzykładach 10.15 i 10.16.Przykład 10.15.Interfejs SerwerPogaw, wykorzystywany przez SerwletPogawimport java.rmi.Remote;import java.rmi.RemoteException;public interface SerwerPogaw extends Remote {public String pobierzNastepnaWiadomosc() throws RemoteException;public void nadajWiadomosc(String message) throws RemoteException;public void dodajKlient(KlientPogaw klient) throws RemoteException;public void usunKlient(KlientPogaw klient) throws RemoteException;}Przykład 10.16.W pełni funkcjonalny serwer-serwlet pogawędekimport java.io.*;import java.net.*;import java.rmi.*;import java.util.*;import javax.servlet.*;import javax.servlet.http.*;import com.oreilly.servlet [ Pobierz całość w formacie PDF ]