\nDen bog, du l\u00e6ser her, er fra 1998, og mange ting kan have \u00e6ndret sig siden da.
\nVi h\u00e5ber, at du stadig kan finde relevant information i den.
\nHvis du vil l\u00e6se aktuelle oplysninger om de avancerede dele af Java, anbefaler vi
\nbogen Core Java – Advanced Features<\/a>
S\u00e6dvanligvis h\u00e5ndteres fejlsituationer i Java ved hj\u00e6lp af exceptions. Hvis kommunikationen foreg\u00e5r gennem streams, er det ikke muligt at sende en exception, hvis der opst\u00e5r en fejl p\u00e5 serveren. Hvis serveren selv kaster en exception, vil klienten ikke f\u00e5 det at vide, og fejlen vil blive udskrevet p\u00e5 serverens konsol. Den eneste l\u00f8sning er at sende en tekstbesked, der angiver, at der er sket en exception, og derefter f\u00e5 klientprogrammet selv til at instantiere og kaste en exception. Dette undergraver imidlertid selve ideen med exceptions B fordelen skulle jo netop v\u00e6re, at man var fri for at kontrollere, at en bestemt operation var g\u00e5et godt.<\/p>\n
<\/p>\n
Et andet problem er opbygningen af serveren. Her vil der typisk v\u00e6re en funktion, der h\u00e5ndterer den indledende kommunikation med klienten. Denne funktion finder ud af, hvilken service klienten gerne vil have udf\u00f8rt, og herefter kalder den den tilsvarende funktion. Denne funktion beder om eventuelle parametre, og sender svar tilbage til klienten.<\/p>\n
<\/p>\n
Denne fremgangsm\u00e5de giver to problemer. Dels er det ikke designm\u00e6ssigt p\u00e6nt at have en funktion, der blot best\u00e5r af en r\u00e6kke if-s\u00e6tninger, der afg\u00f8r, hvilken funktion, der skal kaldes bagefter, men det er ogs\u00e5 irriterende at have netv\u00e6rkskommunikationen spredt udover hele programmet.<\/p>\n
<\/p>\n
Ogs\u00e5 for klienten ser det skidt ud. Igen bliver netv\u00e6rkskommunikationen spredt ud over hele programmet, og hver gang man skal have udf\u00f8rt en kommando hos serveren, skal man instantiere en Socket, streams og s\u00e5 videre.<\/p>\n
<\/p>\n
Det ville v\u00e6re nemmere, hvis man bare kunne instantiere et objekt p\u00e5 serveren, og herefter lade klienten kalde dem, som l\u00e5 de p\u00e5 den lokale maskine. Dette kan man ved at bruge RMI B n\u00e6sten. Der er lige et par kunstgreb, der skal g\u00f8res, men alt i alt er det v\u00e6sentligt lettere end den s\u00e6dvanlige kommunikation.<\/p>\n
<\/p>\n Som n\u00e6vnt kan man ved RMI lade serveren instantiere et objekt, og herefter lade klienten kalde dets metoder. Den klasse, objektet tilh\u00f8rer, skal imidlertid opfylde nogle bestemte krav. For eksempel skal alle de metoder, der skal kunne tilg\u00e5s fra klienten, l\u00e6gges ud i et interface, som klassen naturligvis skal implementere.<\/p>\n <\/p>\n Interfacet skal nedarve fra java.rmi.Remote. Dette sikrer, at man kan behandle alle RMI-objekter abstrakt ved blot at referere til dem som havende typen java.rmi.Remote. Derudover skal man v\u00e6re opm\u00e6rksom p\u00e5, at alle metoder skal have java.rmi.RemoteException i deres throws-sektion udover de andre exceptions, de kan kaste.<\/p>\n <\/p>\n Nedenst\u00e5ende eksempel viser et s\u00e5dant interface. Det angiver fire matematiske funktioner. I praksis vil man nok v\u00e6lge nogle lidt mere komplicerede funktioner, for den tid, der bruges p\u00e5 kommunikationen, er mangefold st\u00f8rre end den tid, selve udregningen tager.<\/p>\n <\/p>\n import java.rmi.*;<\/p>\n <\/p>\n public interface MathInterface extends Remote<\/p>\n {<\/p>\n public float add (float a, float b) throws RemoteException;<\/p>\n public float sub (float a, float b) throws RemoteException;<\/p>\n public float mul (float a, float b) throws RemoteException;<\/p>\n public float div (float a, float b) throws RemoteException,<\/p>\n ArithmeticException;<\/p>\n }<\/p>\n <\/p>\n N\u00e5r interfacet er lavet, kan man begynde at skrive selve implementateringen. Den klasse, der implementerer interfacet skal nedarve fra java.rmi.server.UnicastRemoteObject. Derudover skal den have en constructor B ogs\u00e5 selvom denne er tom. Constructoren skal B ligesom de \u00f8vrige funktioner B have java.rmi.RemoteException i throws-sektionen. Dette eksempel viser implementeringen af interfacet.<\/p>\n <\/p>\n import java.rmi.*;<\/p>\n import java.rmi.server.*;<\/p>\n <\/p>\n public class MathServer extends UnicastRemoteObject implements MathInterface<\/p>\n {<\/p>\n public MathServer () throws RemoteException<\/p>\n {<\/p>\n }<\/p>\n <\/p>\n public float add (float a, float b) throws RemoteException<\/p>\n {<\/p>\n return a + b;<\/p>\n }<\/p>\n <\/p>\n <\/p>\n public float sub (float a, float b) throws RemoteException<\/p>\n {<\/p>\n return a – b;<\/p>\n }<\/p>\n <\/p>\n public float mul (float a, float b) throws RemoteException<\/p>\n {<\/p>\n return a * b;<\/p>\n }<\/p>\n <\/p>\n public float div (float a, float b) throws RemoteException,<\/p>\n ArithmeticException<\/p>\n {<\/p>\n return a \/ b;<\/p>\n }<\/p>\n }<\/p>\n <\/p>\n Nu er selve den klasse, der skal g\u00f8res tilg\u00e6ngelig skrevet. Nu skal der blot skrives en klasse, der kalder de funktioner, der registrerer klassen som offentlig tilg\u00e6ngelig. Den kode kunne naturligvis have ligget i MathServer=s main-funktion, men her er det alts\u00e5 valgt at lave en selvst\u00e6ndig klasse til det. Nedenst\u00e5ende eksempel viser, hvordan et MathServer-objekt instantieres og registreres.<\/p>\n <\/p>\n import java.rmi.*;<\/p>\n import java.net.MalformedURLException;<\/p>\n <\/p>\n public class Server<\/p>\n {<\/p>\n public static final void main (String args[])<\/p>\n {<\/p>\n System.setSecurityManager (new RMISecurityManager());<\/p>\n <\/p>\n try<\/p>\n {<\/p>\n MathServer obj = new MathServer ();<\/p>\n }<\/p>\n catch (RemoteException re)<\/p>\n {<\/p>\n System.out.println (re.toString());<\/p>\n System.exit (1);<\/p>\n }<\/p>\n <\/p>\n try<\/p>\n {<\/p>\n Naming.bind (“\/\/void-main\/Math”, obj);<\/p>\n System.out.println (“Udf\u00f8rt”);<\/p>\n }<\/p>\n catch (MalformedURLException mue)<\/p>\n {<\/p>\n System.out.println (mue.toString());<\/p>\n <\/p>\n }<\/p>\n catch (UnknownHostException uhe)<\/p>\n {<\/p>\n System.out.println (uhe.toString());<\/p>\n }<\/p>\n catch (AlreadyBoundException abe)<\/p>\n {<\/p>\n System.out.println (abe.toString());<\/p>\n }<\/p>\n }<\/p>\n }<\/p>\n <\/p>\n Det f\u00f8rste, der sker i eksemplet er, at der bliver installeret en security manager. Det kan enten v\u00e6re RMISecurityManager, eller en man selv har defineret. Installerer man ikke en security manager, er det ikke tilladt at instantiere RMI-klasser.<\/p>\n Dern\u00e6st instantieres et objekt af klassen MathServer. Som n\u00e6vnt tidligere, kan det medf\u00f8re en RemoteException, og derfor bliver den fanget her. Opst\u00e5r denne exception afbrydes programmet, for s\u00e5 er der ikke megen id\u00e9 i at fors\u00f8ge at registrere objektet.<\/p>\n Hvis objektet bliver instantieret korrekt, er det n\u00e6ste skridt at g\u00f8re det tilg\u00e6ngeligt for klienterne. Det g\u00f8res ved at registrere det i Javas Naming-service ved hj\u00e6lp af metoden bind, der er en statisk metode i klassen Naming. Det f\u00f8rste parameter er en tekststreng, der angiver den URL, objektet skal kendes under. Klienterne skal kende denne URL for at kunne tilg\u00e5 objektet. Den f\u00f8rste del af URL=en er computerens navn B i dette tilf\u00e6lde void-main. Herefter skrives det navn, objektet skal v\u00e6re kendt under. Det beh\u00f8ver ikke at have nogen tilknytning til klassens eller objektets navn i programmet. Metodens andet parameter er en reference til det objekt, der skal bindes. Dette objekt skal v\u00e6re en sub-klasse af java.rmi.server.UnicastRemoteObject.<\/p>\n <\/p>\n Da det f\u00f8rste parameter som n\u00e6vnt er en URL, kan bind-metoden resultere i en java.net.MalformedURLException. Den kan ogs\u00e5 medf\u00f8re en java.rmi.UnknownHostException, hvis navnet p\u00e5 computeren ikke er gyldigt. Endeligt kan funktionskaldet medf\u00f8re en java.rmi.AlreadyBoundException, hvis der allerede er bundet et objekt med det navn, man angiver. Hvis man ved, at man har bundet objektet tidligere, men gerne vil opdatere det, kan man bruge Naming.rebind i stedet for Naming.bind.<\/p>\n Et objekt, der nedarver fra java.rmi.server.UnicastRemoteObject\u00a0beh\u00f8ver ikke at blive registreret i naming-servicen. Hvis en anden funktion returnerer objektet, kan klienter sagtens kalde funktioner p\u00e5 det, selvom det ikke er registreret. Problemet er bare at f\u00e5 fat i den f\u00f8rste instans af et objekt. Dette objekt kan ikke returneres ved et funktionskald, for man har ikke noget objekt at kalde funktionen p\u00e5. I stedet kan naming-servicen bruges som vist i dette eksempel. Bem\u00e6rk, at selvom man skal angive navnet p\u00e5 en computer i bind-metoden, er det kun muligt at bruge naming-servicen p\u00e5 den lokale maskine. Dette er gjort for at sikre, at man ikke kan tilslutte sig en anden computers naming-service, registrere et af sine egne objekter i stedet for det, der tidligere var registreret, og derefter f\u00e5 klienter til at tro, at de bruger det originale objekt.<\/p>\n <\/p>\n <\/p>\n N\u00e5r kildeteksterne er skrevet kan de kompileres med den vanlige Java-compiler. Derefter skal den klasse, der skal v\u00e6re offentligt tilg\u00e6ngelig, kompileres med en speciel RMI-compiler. Hvis man har Suns JDK hedder den rmic. Det vil alts\u00e5 sige, at man fra kommandoprompten skal skrive rmic MathServer for at f\u00e5 klassen MathServer gennem RMI-compileren. N\u00e5r rmic er f\u00e6rdig har den genereret to nye klasser: MathServer_Stub og MathServer_Skel. Stub-klassen skal l\u00e6gges sammen med klient-programmet B det er den, der h\u00e5ndterer netv\u00e6rkskommunikationen med Skeleton-klassen, der l\u00e6gges p\u00e5 serveren. Set fra programm\u00f8rens synspunkt er dette ikke s\u00e5 vigtigt B man f\u00e5r aldrig selv brug for at instantiere eller p\u00e5 anden m\u00e5de benytte stub- og skeleton-klasserne i sit program.<\/p>\n <\/p>\n Nu hvor programmet er kompileret og alle klassefiler genereret, er det klar til udf\u00f8rsel. Inden programmet startes skal man dog starte RMI-registreringsdatabasen. Det er program, der f\u00f8lger med Suns JDK. Programmet startes med kommandoen rmiregistry. Man skal huske, enten at starte rmiregistry fra det bibliotek, hvor klassefilerne ligger eller at inkludere klassefilerne i sin classpath.<\/p>\n <\/p>\n <\/p>\n N\u00e5r server-programmet er f\u00e6rdig, kan man begynde at skrive klienten. Klienten har to RMI-relaterede opgaver. Den skal for det f\u00f8rste finde det rette objekt, og for det andet skal den kalde metoder p\u00e5 objektet.<\/p>\n <\/p>\n Den f\u00f8rste opgave l\u00f8ses ved hj\u00e6lp af naming-servicen. Klienten kender servermaskinens navn og ogs\u00e5 det navn, objektet er blevet registreret som. Disse oplysninger sendes videre til naming-servicen ved hj\u00e6lp af lookup-metoden, der er en statisk funktion i Naming-klassen. Denne funktion returnerer en instans af RMI-objektet. Alle referencer til RMI-objekter, der bruges som parametre eller returv\u00e6rdier, skal v\u00e6re referencer til interfacet og ikke til selve objektet. Derfor skal klientens reference til MathServer v\u00e6re af typen MathInterface. Da Naming.lookup\u00a0er en generel funktion, skal returv\u00e6rdien castes.<\/p>\n <\/p>\n lookup-funktionen kan ende med en del exceptions. Den f\u00f8rste er java.net.MalformedURLException, der opst\u00e5r, hvis adressen p\u00e5 objektet er formuleret forkert. Dern\u00e6st kan java.rmi.NotBoundException opst\u00e5. Det sker, hvis det objekt, man fors\u00f8ger at f\u00e5 kontakt med, ikke er bundet p\u00e5 serveren. Endeligt kan java.rmi.RemoteException\u00a0blive opst\u00e5, hvis der opst\u00e5r en generel kommunikationsfejl.<\/p>\n <\/p>\n N\u00e5r f\u00f8rst naming-servicen har fundet objektet og returneret en reference til det, er det klart til brug. Man skal bare huske, at ethvert kald af en funktion i et RMI-objekt kan medf\u00f8re en java.rmi.RemoteException B derfor skal man enten erkl\u00e6re den i funktionernes throws-liste eller catch=e dem hver gang. Nedenst\u00e5ende klasse viser, hvordan MathServer kan bruges.<\/p>\n <\/p>\n import java.rmi.*;<\/p>\n <\/p>\n public class MathClient<\/p>\n {<\/p>\n public static final void main (String args[])<\/p>\n <\/p>\n {<\/p>\n MathInterface math = null;<\/p>\n <\/p>\n try<\/p>\n {<\/p>\n math = (MathInterface) Naming.lookup (“\/\/void-main\/Math”);<\/p>\n }<\/p>\n catch (java.net.MalformedURLException mue)<\/p>\n {<\/p>\n System.out.println (mue.toString());<\/p>\n System.exit (1);<\/p>\n }<\/p>\n catch (NotBoundException nbe)<\/p>\n {<\/p>\n System.out.println (nbe.toString());<\/p>\n System.exit (2);<\/p>\n }<\/p>\n catch (RemoteException re)<\/p>\n {<\/p>\n System.out.println (re.toString());<\/p>\n System.exit (3);<\/p>\n }<\/p>\n <\/p>\n <\/p>\n try<\/p>\n {<\/p>\n System.out.println (“1 + 2 er ” + math.add (1,2));<\/p>\n System.out.println (“3 – 4 er ” + math.sub (3,4));<\/p>\n System.out.println (“5 * 6 er ” + math.mul (5,6));<\/p>\n System.out.println (“7 \/ 8 er ” + math.div (7,8));<\/p>\n }<\/p>\n catch (RemoteException re)<\/p>\n {<\/p>\n System.out.println (re.toString());<\/p>\n System.exit (4);<\/p>\n }<\/p>\n }<\/p>\n }<\/p>\n <\/p>\n <\/p>\n N\u00e5r b\u00e5de serveren og klienten er skrevet og kompileret, er programmet parat til at blive delt ud p\u00e5 forskellige maskiner. P\u00e5 serveren skal implementeringen af server-klassen ligge sammen med interfacet, og den skeleton-klasse, der blev genereret af rmi-compileren. P\u00e5 klienten skal klient-programmet naturligvis ligge. Det skal interfacet ogs\u00e5 og den stub-klasse, rmi-compileren genererede. En samlet oversigt over placeringen af filer ses nedenst\u00e5ende tabel<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n RMI g\u00f8r det muligt at distribuere sin applikation over adskillige maskiner. Desv\u00e6rre er det uheldigt, at adressen p\u00e5 samtlige servere skal v\u00e6re kendt af klienten. Dette vil betyde \u00e6ndringer i samtlige klienter, hvis bare en af serverne skiftede adresse. For at l\u00f8se dette problem kan man bruge en nameserver.<\/p>\n Nameserverens opgave er at registrere hvilke servere, der stiller hvilke services til r\u00e5dighed. Det vil sige, at alle servere skal fort\u00e6lle nameserveren, at de udbyder en service. Dern\u00e6st kan en klient bede nameserveren om en reference til et givent objekt eller en given service, hvorefter nameserveren vil bede den rigtige server om en reference til objektet, der sendes videre til klienten. Der er tydeligvis nogle tidsm\u00e6ssige omkostninger ved at bruge en nameserver, men nogle gange kan det v\u00e6re den eneste udvej.<\/p>\n I dette afsnit vil et nameserver-eksempel blive gennemg\u00e5et. Der er tale om en relativt primitiv nameserver B der er mange sikkerhedsaspekter, der ikke er taget h\u00f8jde for. Dette er gjort fuldt bevidst, da disse aspekter ikke har meget med RMI at g\u00f8re og blot vil g\u00f8re kildeteksten mere kompliceret at l\u00e6se og forst\u00e5. Eksemplet afsluttes imidlertid med et afsnit, der kort beskriver, hvordan de n\u00f8dvendige udvidelser kan implementeres.<\/p>\n <\/p>\n <\/p>\n Nameserveren skal have f\u00f8lgende funktionalitet:<\/p>\n <\/p>\n Disse krav kan opfyldes af funktionerne i nedenst\u00e5ende interface:<\/p>\n <\/p>\n import java.rmi.*;<\/p>\n import java.net.MalformedURLException;<\/p>\n <\/p>\n public interface RMINameServer extends Remote<\/p>\n {<\/p>\n public void bind(String host, String name) throws RemoteException,<\/p>\n AlreadyBoundException;<\/p>\n <\/p>\n public void unbind (String host, String name) throws RemoteException;<\/p>\n <\/p>\n public void rebind (String host, String name) throws RemoteException;<\/p>\n <\/p>\n public Object lookup (String name) throws RemoteException,<\/p>\n MalformedURLException, NotBoundException;<\/p>\n }<\/p>\n <\/p>\n <\/p>\n bind-funktionen bruges, n\u00e5r en server skal registreres i nameserveren. Alle servere skal som bekendt registreres i nameserveren. Den f\u00f8rste parameter er navnet p\u00e5 server-computeren. Det kan enten v\u00e6re serverens IP-nummer eller computerens navn p\u00e5 netv\u00e6rket. name er det navn, objektet er bundet under p\u00e5 serveren \u2013 objektet vil p\u00e5 nameserveren blive bundet p\u00e5 det samme navn. Klienterne bruger dette navn til at tilg\u00e5 objektet.<\/p>\n <\/p>\n unbind-funktionen bruges, n\u00e5r en server oph\u00f8rer med at stille en bestemt service til r\u00e5dighed. Igen gives server-computerens navn med som parameter sammen med objektets navn.<\/p>\n rebind er en udvidelse af bind-funktionen. Den opdaterer den reference, der er til det angivne objekt. Hvis objektet ikke allerede er bundet i nameserveren, vil det blive bundet, som var der foretaget et kald af bind i stedet for rebind.<\/p>\n <\/p>\n lookup bruges af klienterne til at f\u00e5 en reference til et givent objekt. Det navn, der gives med, er det navn, som serverne har valgt at blive bundet p\u00e5.<\/p>\n <\/p>\n Som det ses, er funktionerne stor set magen til de, der findes i Naming-klassen.<\/p>\n Implementeringen af RMINameServer-interfacet findes i klassen ConcreteNameServer:<\/p>\n <\/p>\n import java.rmi.*;<\/p>\n import java.rmi.server.*;<\/p>\n import java.util.*;<\/p>\n import java.net.MalformedURLException;<\/p>\n <\/p>\n public class ConcreteNameServer extends UnicastRemoteObject implements RMINameServer<\/p>\n {<\/p>\n protected Vector bindings;<\/p>\n <\/p>\n public ConcreteNameServer () throws RemoteException<\/p>\n {<\/p>\n bindings = new Vector();<\/p>\n }<\/p>\n <\/p>\n public void bind (String host, String name) throws RemoteException,<\/p>\n AlreadyBoundException<\/p>\n {<\/p>\n Binding b = new Binding (host, name);<\/p>\n <\/p>\n if (bindings.contains (b))<\/p>\n throw new AlreadyBoundException (host + “\/” + name);<\/p>\n <\/p>\n bindings.addElement (b);<\/p>\n }<\/p>\n <\/p>\n public void unbind (String host, String name) throws RemoteException<\/p>\n {<\/p>\n Binding b = new Binding (host, name);<\/p>\n bindings.removeElement (b);<\/p>\n }<\/p>\n <\/p>\n public void rebind (String host, String name) throws RemoteException<\/p>\n {<\/p>\n try<\/p>\n {<\/p>\n unbind (host,name);<\/p>\n bind (host, name);<\/p>\n }<\/p>\n catch (AlreadyBoundException abe)<\/p>\n {<\/p>\n \/\/ Just catch it and ignore it<\/p>\n }<\/p>\n }<\/p>\n <\/p>\n public Object lookup (String name) throws RemoteException,<\/p>\n MalformedURLException, NotBoundException<\/p>\n {<\/p>\n for (int i = 0; i < bindings.size(); i++)<\/p>\n {<\/p>\n if (((Binding) bindings.elementAt (i)).name.equals (name))<\/p>\n {<\/p>\n return Naming.lookup (“rmi:\/\/” + ((Binding) bindings.elementAt (i)).host<\/p>\n + “\/” + ((Binding) bindings.elementAt (i)).name);<\/p>\n }<\/p>\n }<\/p>\n throw new NotBoundException (name);<\/p>\n }<\/p>\n }<\/p>\n <\/p>\n Nameserveren bruger klassen Binding til at registrere et server\/objekt-par. Listen over bindinger gemmes herefter i en vektor (java.util.Vector). Binding-klassen er specielt udviklet til nameserveren:<\/p>\n <\/p>\n public class Binding<\/p>\n {<\/p>\n public String host;<\/p>\n public String name;<\/p>\n <\/p>\n public Binding ()<\/p>\n <\/p>\n {<\/p>\n name = host = null;<\/p>\n }<\/p>\n <\/p>\n public Binding (String host, String name)<\/p>\n {<\/p>\n this.host = host;<\/p>\n this.name = name;<\/p>\n }<\/p>\n }<\/p>\n <\/p>\n Med de klasser, der indeholder nameserverens funktionalitet, mangler man bare den programkode, der opretter en instans af ConcreteNameServer-klassen og binder denne i registreringsservicen, s\u00e5 klienter og servere har adgang til den:<\/p>\n <\/p>\n import java.rmi.*;<\/p>\n import java.rmi.server.*;<\/p>\n import java.net.MalformedURLException;<\/p>\n <\/p>\n public class NameServerApp<\/p>\n {<\/p>\n public static void main(String args[]) throws MalformedURLException,<\/p>\n RemoteException<\/p>\n {<\/p>\n System.out.println (“Initializing”);<\/p>\n ConcreteNameServer nameServer = new ConcreteNameServer();<\/p>\n System.setSecurityManager (new RMISecurityManager ());<\/p>\n Naming.bind (“NameServer”, nameServer);<\/p>\n System.out.println (“Server ready”);<\/p>\n }<\/p>\n }<\/p>\n <\/p>\n <\/p>\n For at vise, hvordan henholdsvis klienten og serveren anvender en nameserver, beskrives her, hvilke \u00e6ndringer, der skal foretages i det Math-eksempel, der blev gennemg\u00e5et tidligere i kapitlet. Interfacet MathInterface og klassen MathServer skal ikke \u00e6ndres. Disse vedr\u00f8rer kun implementeringen af funktionaliteten p\u00e5 serveren, og den skal naturligvis v\u00e6re den samme, hvadenten der bruges en nameserver eller ej. Der skal til geng\u00e6ld foretages \u00e6ndringer i den klasse, der opretter MathServer-objektet og binder det \u2013 denne klasse skal nu ogs\u00e5 s\u00f8rge for at registrere klassen i nameserveren. Det betyder, at server-klassens main-funktion kommer til at se s\u00e5ledes ud:<\/p>\n <\/p>\n public static final void main (String args[])<\/p>\n {<\/p>\n System.setSecurityManager (new RMISecurityManager());<\/p>\n MathServer obj = null;<\/p>\n try<\/p>\n <\/p>\n {<\/p>\n obj = new MathServer ();<\/p>\n }<\/p>\n catch (RemoteException re)<\/p>\n {<\/p>\n System.out.println (re.toString());<\/p>\n System.exit (1);<\/p>\n }<\/p>\n <\/p>\n try<\/p>\n {<\/p>\n Naming.bind (“\/\/void-main\/Math”, obj);<\/p>\n System.out.println (“Objekt bundet lokalt”);<\/p>\n }<\/p>\n catch (MalformedURLException mue)<\/p>\n {<\/p>\n System.out.println (mue.toString());<\/p>\n }<\/p>\n catch (UnknownHostException uhe)<\/p>\n {<\/p>\n System.out.println (uhe.toString());<\/p>\n }<\/p>\n catch (AlreadyBoundException abe)<\/p>\n {<\/p>\n System.out.println (abe.toString());<\/p>\n }<\/p>\n catch (RemoteException rr)<\/p>\n {<\/p>\n System.out.println (rr.toString());<\/p>\n }<\/p>\n <\/p>\n RMINameServer nameserver = null;<\/p>\n <\/p>\n try<\/p>\n {<\/p>\n nameserver = (RMINameServer) Naming.lookup (“\/\/nameserver\/NameServer”);<\/p>\n }<\/p>\n catch (RemoteException rx)<\/p>\n {<\/p>\n System.out.println (rx.toString());<\/p>\n }<\/p>\n catch (MalformedURLException mux)<\/p>\n {<\/p>\n System.out.println (mux.toString());<\/p>\n }<\/p>\n catch (NotBoundException nbx)<\/p>\n {<\/p>\n System.out.println (nbx.toString());<\/p>\n }<\/p>\n <\/p>\n try<\/p>\n {<\/p>\n nameserver.bind (“void-main”,”Math”);<\/p>\n <\/p>\n }<\/p>\n catch (RemoteException rex)<\/p>\n {<\/p>\n System.out.println (rex.toString());<\/p>\n }<\/p>\n catch (AlreadyBoundException abex)<\/p>\n {<\/p>\n System.out.println (abex.toString());<\/p>\n }<\/p>\n }<\/p>\n <\/p>\n Ogs\u00e5 klient-programmet skal \u00e6ndres, men dog ikke i samme omfang som serveren. Blot skal klienten nu sp\u00f8rge nameserveren om at f\u00e5 en reference til MathServer-objektet i stedet for selve serveren. Det betyder, at main-funktionen i MathClient-klassen nu kommer til at se s\u00e5ledes ud:<\/p>\n <\/p>\n public static final void main (String args[])<\/p>\n {<\/p>\n MathInterface math = null;<\/p>\n <\/p>\n try<\/p>\n {<\/p>\n math = (MathInterface) Naming.lookup (“\/\/nameserver\/Math”);<\/p>\n }<\/p>\n catch (java.net.MalformedURLException mue)<\/p>\n {<\/p>\n System.out.println (mue.toString());<\/p>\n System.exit (1);<\/p>\n }<\/p>\n catch (NotBoundException nbe)<\/p>\n {<\/p>\n System.out.println (nbe.toString());<\/p>\n System.exit (2);<\/p>\n }<\/p>\n catch (RemoteException re)<\/p>\n {<\/p>\n System.out.println (re.toString());<\/p>\n System.exit (3);<\/p>\n }<\/p>\n <\/p>\n <\/p>\n try<\/p>\n {<\/p>\n System.out.println (“1 + 2 er ” + math.add (1,2));<\/p>\n System.out.println (“3 – 4 er ” + math.sub (3,4));<\/p>\n System.out.println (“5 * 6 er ” + math.mul (5,6));<\/p>\n System.out.println (“7 \/ 8 er ” + math.div (7,8));<\/p>\n }<\/p>\n catch (RemoteException re)<\/p>\n {<\/p>\n System.out.println (re.toString());<\/p>\n System.exit (4);<\/p>\n }<\/p>\n }<\/p>\n <\/p>\n <\/p>\n <\/p>\n Som n\u00e6vnt tidligere er det muligt at foretage mange forbedringer til den nameserver, der er blevet skitseret her.<\/p>\n <\/p>\n Sikkerheden i systemet er ikke-eksisterende. Det er muligt for en hvilken som helst server at unbind\u2019e en anden servers objekt og i stedet inds\u00e6tte sit eget objekt i det samme navn. Denne risiko kan man minimere ved at lade bind- og rebind-funktionerne returnere et unikt id. Dette id skal sendes med til unbind og rebind for at sikre, at det er den samme server, der bind\u2019er og unbind\u2019er objekter.<\/p>\n Et andet problem er, at serverne skal<\/em> kalde unbind-funktionen for at vise, at de ikke l\u00e6ngere stiller deres service til r\u00e5dighed. Desv\u00e6rre er det jo engang s\u00e5dan, at computere af og til g\u00e5r ned uden videre, og man kan derfor risikere, at nameserveren har referencer til computere, der er g\u00e5et ned. Denne problematik kan afhj\u00e6lpes ved hj\u00e6lp af time-outs. Ved at lade serveren kontrollere, om der stadig er kontakt til alle serverne med j\u00e6vne mellemrum, kan man formindske antallet af \u201dd\u00f8de\u201d servere drastisk. Det kan g\u00f8res ved at kr\u00e6ve, at alle objekter skal inkludere et interface, der indeholder funktionen ping(). Det eneste, denne funktion skal g\u00f8re, er at returnere true for at vise, at objektet stadig eksisterer, og at server-computeren stadigv\u00e6k k\u00f8rer. Hvis nameserveren ikke modtager svaret fra funktionen inden for et bestemt tidsrum, skal det p\u00e5g\u00e6ldende objekt fjernes fra listen over registrerede objekter. Hvor lang tid serverne skal have til at svare, afh\u00e6nger af netv\u00e6rkets hastighed og belastning. Hvor ofte nameserveren skal kontrollere om de \u00f8vrige servere er i live, er en afvejning mellem, hvor meget man \u00f8nsker at belaste netv\u00e6rket, nameserveren og de \u00f8vrige servere, og hvor mange \u201dd\u00f8de\u201d servere, man vil acceptere, der eksisterer p\u00e5 nameserveren.<\/p>\n <\/p>\n <\/p>\n RMI \u00e5bner mulighed for, at man selv kan definere sine sockets. Der kan v\u00e6re mange grunde til, at man selv \u00f8nsker at definere sine sockets. De to mest udbredte er<\/p>\n <\/p>\n En mulig og s\u00e6rdeles popul\u00e6r anvendelse af brugerdefinerede RMI-sockets er SSL. Ved at f\u00e5 RMI til at kommunikere ved hj\u00e6lp af SSL-protokollen kan man sikre sikker, krypteret kommunikation mellem klienten og serveren.<\/p>\n <\/p>\n Man definerer sin egen socket ved at anvende en java.rmi.server.RMISocketFactory. Ved at g\u00f8re det, f\u00e5r man mulighed for at anvende en anden protokol end den TCP\/IP, RMI normalt anvender. RMI anvender nemlig normalt den socket, der er defineret i java.net.Socket.<\/p>\n <\/p>\n Fra og med JDK version 1.2 er det muligt at definere forskellige former for sockets til forskellige forbindelser \u2013 det g\u00f8r man ved hj\u00e6lp af klassen java.rmi.server.SocketType. I dette afsnit vil det blive gennemg\u00e5et, hvordan man opretter en RMISocketFactory, der producerer en enkelt type<\/p>\n <\/p>\n socket, og hvordan man laver en RMISocketFactory, der producerer flere forskellige typer.<\/p>\n <\/p>\n Inden det gennemg\u00e5s, hvordan man bruger brugerdefinerede sockets sammen med RMI, er det imidlertid en god id\u00e9 at se p\u00e5, hvordan man opretter en brugerdefineret socket.<\/p>\n
\n<\/strong><\/p>\nServeren<\/h1>\n
Klienten<\/h1>\n
Fordeling af filer<\/h1>\n
\n\n
\n Fil<\/em><\/td>\n Placering<\/em><\/td>\n<\/tr>\n \n Implementering af server-klasse<\/td>\n Server<\/td>\n<\/tr>\n \n Skeleton-klasse<\/td>\n Server<\/td>\n<\/tr>\n \n Interface<\/td>\n Server og klient<\/td>\n<\/tr>\n \n Stub-klasse<\/td>\n Klient<\/td>\n<\/tr>\n \n Implementering af klient-klasse<\/td>\n Klient<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n En nameserver<\/h1>\n
Krav til nameserveren<\/h2>\n
\n
Funktioner i nameserveren<\/h2>\n
Et client\/server eksempel med nameserver<\/h2>\n
Forbedringer til nameserveren<\/h2>\n
Brugerdefinerede RMI-sockets<\/h1>\n
\n