[ Pobierz całość w formacie PDF ]
.close(); }catch (IOException ignored) { }}}}private String pobierzDataPortObiekt() {InputStream in = null;try {// Ustanowienie po³¹czenia przez port z serwletemSocket port = new Socket(getCodeBase().getHost(), getSocketPort());// Wyœwietlenie linii "obiekt", wskazuj¹cej chêæ pobrania Data jako obiektu// zserializowanegoPrintStream wyj = new PrintStream(port.getOutputStream());wyj.println("obiekt");wyj.flush();// Stworzenie ObjectInputStream odczytuj¹cego odpowiedŸin = port.getInputStream();ObjectInputStream wynik =new ObjectInputStream(new BufferedInputStream(in));// Odczytanie obiektu i zapamiêtania go jako DataObject obi = wynik.readObject();Date data = (Date)obi;// Zwrócenie ³añcuchowej reprezentacji otrzymanej Datareturn data.toString();}catch (Exception w) {// Je¿eli wyst¹pi³ problem, wyœwietlenie w System.out// (zazwyczaj konsoli Javy) i zwrócenie nullw.printStackTrace();return null;}finally {// Zawsze zamkniêcie po³¹czenia// Poni¿szy kod jest wykonywany niezale¿nie od wykonania poprzednich dzia³añif (in != null) {try { in.close(); }catch (IOException ignored) { }}}}W obu powy¿szych metodach, aplet rozpoczyna dzia³anie przez utworzenie obiektuSocket wykorzystywanego do komunikacji z serwerem.Aby go utworzyæ, musi znaænazwê komputera i numer portu, na którym nas³uchuje serwlet.Okreœleniekomputera jest proste — musi to byæ ten sam komputer, z którego zosta³ onpobrany, dostêpny przy pomocy wywo³ania getCodeBase().getHost().Okreœlenieportu jest trudniejsze, jako ¿e zale¿y wy³¹cznie od serwletu, z którym ³¹czysiê aplet.Aplet ten wykorzystuje metodê getSocketPort() w celu okreœleniatego.Przedstawiona powy¿ej implementacja getSocketPort() zwraca wartoœæparametru apletu socketPort lub (je¿eli parametr ten nie jest podany) wartoœæzmiennej DEFAULT_PORT.Po ustanowieniu po³¹czenia przez port, aplet wykorzystuje nienazwany protokó³ wcelu porozumienia siê z serwerem.Protokó³ ten wymaga, aby aplet wys³a³ jedn¹liniê w celu wskazania, czy aktualny czas wysy³any w odpowiedzi mia³ formêtekstu, czy obiektu.Je¿eli linia ta zawiera s³owo obiekt, aplet otrzymujeobiekt.Je¿eli zawiera cokolwiek innego, otrzymuje zwyk³y tekst.Po wys³aniutej linii, aplet mo¿e odczytaæ odpowiedŸ we w³aœciwy sposób.Aplet i serwlet mog¹ kontynuowaæ porozumiewanie siê przy pomocy tego portu.Jest to jedna z g³Ã³wnych zalet niestosowania komunikacji HTTP.Jednak w tymprzypadku, aplet otrzyma³ po¿¹dane informacje i mo¿e po prostu zamkn¹æpo³¹czenie.Zamkniêcie to jest wykonywane w bloku finally.Umieszczeniezamkniêcia w tym miejscu zapewnia koniec po³¹czenia niezale¿nie od tego, czytry spowoduje dowolny wyj¹tek, czy nie.Po dodaniu dwóch powy¿szych metod aplet jest niemal kompletny.Po uruchomieniugo w tym momencie, wynikiem bêdzie wyœwietlenie dat we wszystkich polach poza„Obiekt RMI”.Komunikacja RMIWe wczeœniejszej czêœci tego rozdzia³u powiedziano, ¿e jednym z powodów niewykorzystywania komunikacji RMI jest jej skomplikowanie.Chocia¿ jest toprawda, jest równie¿ prawd¹, ¿e przy pomocy innej superklasy serwletu, kodwymagany, aby serwlet by³ dostêpny przez komunikacjê RMI, mo¿e byæ a¿ œmiesznieprosty.Po pierwsze, dok³adnie opisany zostanie proces nadawania serwletowiw³aœciwoœci obiektu zdalnego.Nastêpnie, po udowodnieniu prostoty tegodzia³ania wyjaœniona zostanie ca³a praca maj¹ca miejsce w tle.SerwletWszystkie obiekty zdalne RMI musz¹ wykorzystywaæ specyficzny interfejs,Interfejs ten wykonuje dwa dzia³ania — deklaruje, które metody obiektu zdalnegomaj¹ zostaæ udostêpnione zdalnym klientom, oraz rozszerza interfejs Remote wcelu wskazania, ¿e jest to interfejs obiektu zdalnego
[ Pobierz całość w formacie PDF ]