[ Pobierz całość w formacie PDF ]
.Proszê przypomnieæ sobie, ¿e podczaszmiany SerwletGodziny na obiekt zdalny, usuniêta zosta³a obs³uga komunikacjiprzez port.Zostanie ona ponownie umieszczona poni¿ej.W pe³ni funkcjonalny serwletPotrzebny jest pojedynczy serwlet dostêpny przez komunikacjê HTTP, nie-HTTP iRMI.Serwlet tego typu mo¿e byæ rozszerzeniem nowej superklasy,com.oreilly.servlet.RemoteDaemonHttpServlet, wykorzystuj¹cym mo¿liwoœci opisanedotychczas dla RemoteHttpServlet i DaemonHttpServlet.Poni¿ej przedstawiony jest kod deklaruj¹cy ten w pe³ni funkcjonalny serwlet:import java.io.*;import java.net.*;import java.util.*;import javax.servlet.*;import javax.servlet.http.*;import com.oreilly.servlet.RemoteDaemonHttpServlet;public class SerwletGodziny extends RemoteDaemonHttpServletimplements SerwerGodziny {public Data getDate() {return new Data();}// Pozosta³a czêœæ bez zmianPowy¿szy kod jest niemal identyczny jak przyk³ad 10.8.Jest to po prostu tamtenprzyk³ad napisany ponownie, aby zadeklarowaæ, ¿e rozszerza onRemoteDaemonHttpServlet i implementuje SerwerGodziny.Kod superklasy RemoteDaemonHttpServlet równie¿ jest niemal identyczny jakRemoteHttpServlet.Wystêpuj¹ jedynie dwie zmiany — rozszerza onDaemonHttpServlet zamiast HttpServlet, a jego metoda destroy() jako pierwszawywo³uje super.destroy():package com.oreilly.servlet;import java.io.*;import java.net.*;import java.rmi.*;import java.rmi.server.*;import java.rmi.registry.*;import java.util.*;import javax.servlet.*;import javax.servlet.http.*;public abstract class RemoteDaemonHttpServlet extends DaemonHttpServletimplements Remote {public void destroy() {super.destroy();unbind();}// Pozosta³a czêœæ bez zmianW tym momencie ApletGodziny mo¿e po³¹czyæ siê z poprawionym zdalnymserwerem-demonem i utworzyæ pe³ny wynik przedstawiony wczeœniej na rysunku10.1.Serwer pogawêdekPrzyk³ad serwera godziny z poprzedniego podrozdzia³u przedstawia³ wady i zaletystosowania wszystkich trzech technik komunikacji aplet-serwer.Nie korzysta³jednak z zalet utrzymywania po³¹czenia w przypadku po³¹czenia przez port.Nieprzedstawia³ równie¿ prostoty komunikacji RMI i elegancji wywo³añ wstecznychRMI (w których serwlet mo¿e wywo³ywaæ metody apletu).Nie przedstawia³powa¿nego powodu, dla którego jeden serwlet powinien obs³ugiwaæ wszystkietechniki komunikacji — nie istnia³ powód dla którego nale¿a³o utrzymywaæskomplikowany kod w jednym miejscu.Tak wiêc przed zakoñczeniem dyskusji natemat komunikacji aplet-serwlet przedstawiony zostanie przyk³ad bardziejskomplikowany — serwer pogawêdek (chat), zaimplementowany jako serwlet, któryobs³uguje klientów ³¹cz¹cych siê przez HTTP, porty nie-HTTP i RMI.Ten serwer pogawêdek zostanie utworzony przy pomocy wszystkich trzech technikkomunikacji, aby móg³ korzystaæ z zalet najlepszego, najbardziej wydajnegorozwi¹zania dla ka¿dego klienta.Na przyk³ad, kiedy klient obs³uguje RMI,serwlet mo¿e byæ traktowany jako obiekt zdalny, a (gdzie to mo¿liwe) mo¿etraktowaæ aplet równie¿ jako zdalny obiekt.Kiedy klient nie obs³uguje HTTP,ale obs³uguje bezpoœrednie po³¹czenia przez port, serwer pogawêdek mo¿eskorzystaæ z trwa³oœci portów i ³¹czyæ siê z klientem przy pomocy protoko³uportu nie bêd¹cego HTTP.I, oczywiœcie, je¿eli inne techniki zawiod¹, serwerpogawêdek wykorzystaæ HTTP.Nie jest to polecane, poniewa¿ HTTP jako protokó³bezstanowy wymaga od klienta aktywnoœci w celu dokonania uaktualnieñ.Lecz dlawielu klientów HTTP jest jedynym mo¿liwym rozwi¹zaniem.Serwer pogawêdek jest implementowany jako pojedyncza klasa z pojedynczymegzemplarzowaniem, poniewa¿ posiada on du¿¹ iloœæ zwi¹zanych ze sob¹ danych ispor¹ 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.Implementacjaserwera pogawêdek jako serwletu dostarcza prostej metody udostêpnienia jednegoobiektu przy pomocy wszystkich trzech technik komunikacji
[ Pobierz całość w formacie PDF ]