Note om RMI af Peter Kjærsgaard

Transkript

1 Note om RMI af Peter Kjærsgaard 1. Filosofi Filosofien i RMI er, at et objekt på en server skal kunne kaldes fra en klient, som om server-objektet lå på klienten. RMI er dermed på et højere niveau end Sockets, idet server og klienter i RMI deler objekter med hinanden, hvor man i Sockets deler datastrømme. RMI betyder Remote Method Invocation, dvs. kald af remote - dvs. (ikke-lokale)server-metoder. Miljø: RMI findes kun til Java. RMI er altså objektorienteret, og syntaksen for RMI-kald svarer til syntaksen for almindelige Java-kald. Interface Server Implementering Server-siden <<interface>> Subject -siden +request( ) Implements Proxy 1 1 RealSubject +request( ) +request( ) Proxy-mønstret (Eksempel) Princippet i RMI er, at klienten får stillet et interface (kontrakt) til rådighed, som er implementeret på server-objektet (se øverst på tegningen). For at klienten kan bruge dette interface, må der på klienten nødvendigvis være et objekt (af en klasse), som også implementerer interfacet, og som kan sende kaldet videre til server-objektet. Dette princip er netop ideen bag Proxy-mønstret (se nedre del af tegningen), som RMI benytter sig af. I Proxy-mønstret har vi to klasser, som implementerer samme interface (fx. Subject); dvs. de to klasser implementerer begge interfacets metoder (i ovenstående figur er det for enkelhedens skyld kun metoden request). Den ene klasse er den rigtige (RealSubject), dvs. den har den rigtige implementering. Den anden klasse er Proxy en, dvs. et surrogat eller en repræsentant for den rigtige klasse. Proxy-klassen implementerer også interfacet, men dens implementering består i, at kaldet til proxy-objektet sendes videre til det rigtige objekt. Dette kan proxy-objektet gøre, fordi det har en associering (reference) til det rigtige objekt. Altså, når request kaldes på proxy-objekt, dirigeres request-kaldet videre til det rigtige objekt. Otto Knudsen/Note om RMI Side 1 af 7

2 Hvorledes RMI benytter Proxy-mønstret kan illustreres med flg. eksempel: <<interface>> KontoServerI +indsaet(beloeb:float):float +haev(beloeb:float):float +getsaldo():float Server +main(args) implements implements KontoServer -kontonr -saldo uses Proxy remote reference Interfacet (KontoserverI) implementeres både af klienten (Proxy-klassen) og af den rigtige klasse på serveren (KontoServer). Proxy-klassens reference er lidt tillempet i forhold til Proxy-mønstret, idet referencen nu ikke er en associering, men derimod en såkaldt remote reference, som indeholder ip-adresse, portnr og objekt-id på serverobjektet. Vha. denne remote reference kan proxy-objektet så dirigere metode-kaldene videre til server-objektet. 2. Implementerings-koden på serveren Her vises først interfacet: import java.rmi.*; // Interface (kontrakt) for remote konto-objekt public interface KontoServerI extends Remote { public void setkontonr(string kontonr) throws RemoteException; public String getkontonr() throws RemoteException; public double indsaet(double beloeb) throws RemoteException; public double haev(double beloeb) throws RemoteException; public double getsaldo() throws RemoteException; Interfacet arver fra Remote, som er et marker interface, dvs. typen af KontoServerI er remote, dvs. de objekter, som er af klasser, der implementerer KontoServerI vil være remote objekter, dvs. RMI-objekter. Bemærk i øvrigt også, at alle interfacets metoder kaster en RemoteException, som kan fanges på klienten, så denne kan vise hvilke fejl, der evt har været i kommunikationen. Implementeringskoden ser fx således ud: import java.rmi.*; import java.rmi.server.unicastremoteobject; // UnicastRemoteObject // Implementering af (interface til) remote konto-objekt public class KontoServer extends UnicastRemoteObject implements KontoServerI { // Attributter private String kontonr; private double saldo; Otto Knudsen/Note om RMI Side 2 af 7

3 // Konstruktør public KontoServer() throws RemoteException { super(); saldo = 0.0; // Implementér metoderne fra interfacet public void setkontonr(string kontonr) throws RemoteException { this.kontonr = kontonr; public String getkontonr() throws RemoteException {return kontonr; public double indsaet(double beloeb) throws RemoteException { saldo += beloeb; return saldo; public double haev(double beloeb) throws RemoteException { saldo -= beloeb; return saldo; public double getsaldo() throws RemoteException {return saldo; // Her skal være main()-metode, se afsnit 5 Grunden til at implementeringsklassen arver fra UnicastRemoteObject forklares i afsnit Forløbet af et RMI-kald Proxy-mønstret for RMI er en logisk model, som abstraherer fra selve den fysiske kommunikation mellem klient og server over netværket. Fysisk set foregår denne kommunikation vha. Sockets. Sockets kommunikerer vha.. datastrømme. Serversiden er derfor nødt til at have et objekt, som kan modtage og fortolke datastrømmen fra Proxyen (objekt-id, metodenavn, parametre) og omsætte det til det rigtige metodekald på serverobjektet. Dette ekstra objekt på serversiden kaldes Skeleton (skelet), mens proxy-objektet på klienten kaldes en Stub. :KontoServer 1: saldo := indsaet(beloeb) 3: saldo := indsaet(beloeb) :Stub 2: "write"(objectid, "indsaet", beloeb) 4: "write"(saldo) :Skeleton På nedenstående figur er vist hvorledes et kald af RMI-metoden indsaet (jf. forrige figur) forløber. Forløbet (rækkefølgen) af kaldet er følgende: 1. en kalder stub-objektet (1) 2. Derefter opretter stubben (vha. ip-adresse og portnr fra dens remote reference) først en socket-forbindelse til skeleton en (ikke vist på figuren). Dernæst opbygger stubben en datastrøm bestående af objektid (på serverobjekt), metodenavn ( indsaet ) og parametre til metoden (i dette tilfælde beloeb). Denne proces kaldes marshallering, dvs. informationerne stilles op på en række. Endelig sender stubben (vha. en eller anden datastrøms-metode, fx write ) datastrømmen til skeleton en (2). Otto Knudsen/Note om RMI Side 3 af 7

4 3. Skeleton en modtager datastrømmen fra stubben og opbygger derudfra et metodekald på serverobjektet. Skeleton en kan finde server-objektet udfra objekt-id og metoden udfra metode-strengen. Tilsvarende indsættes parametrene fra datastrømmen som parametre i metodekaldet. Hele denne process kaldes demarshalling (det modsatte af marshalling). 4. Server-objektet returnerer saldo til skeleton 5. Skeleton opbygger en datastrøm, som skal sendes til stubben vha. socket-forbindelsen (marshalling). Datastrømmen består her kun af returværdien saldo. 6. Stubben modtager datastrømmen fra skeleton. Fra datastrømmen læses saldo, som returneres til klienten (1) (de-marshalling). Koden til stub og skeleton autogenereres af RMI udfra interface og implementeringsklasse (se evt min note om RMI og Kawa) 4. RMI er trådet, men ikke synkroniseret Hvad sker der, hvis to klienter kalder ind på samme server-objekt samtidigt? For at kunne svare på det, må vi først forstå, at runtime-delen af RMI er en del af JVM (Java Virtuel Machine), som afvikler alle Java-programmer. Dvs. både stub og skeleton kalder ned i RMI-runtime, når de skal kommunikere med hinanden. Kommunikationen (gennem socket-datastrømmene) mellem stub og skeleton foregår altså i virkeligheden mellem RMI-runtime på klient og server. RMI-runtime har altså både en klient-del og en server-del, se nedenstående illustration. Server Serverobjekt Stub Skeleton RMI-runtime () RMI-runtime (Server) Når stubben kalder ned i RMI-runtime på klienten etableres socket-forbindelsen til RMI-runtime på serveren. RMIruntime på serveren starter derefter en tråd, som vha. af denne socket modtager datastrømmen fra klienten og sender den videre til skeleton. Denne tråd på serveren sørger også for at sende returdata tilbage til klienten gennem socketforbindelsen. Tråden lever altså indtil returdata er sendt tilbage til klienten, hvorefter socket-forbindelsen lukkes ned. Når man benytter RMI skal man altså sørge for at gøre server-objektet thread-safe, dvs. lave synchronize på de metoder, der tilgår fælles ressourcer/attributter. 5. Opstart af RMI Ovennævnte beskrivelse af forløbet af et RMI-kald forudsætter, at RMI er initialiseret (startet op) på både server og klient. Opstart på Server For at RMI kan fungere, skal der først laves opstart af server-objekt på serveren. I praksis er der tre ting der skal gøres: 1. Skab remote name-server objekt 2. Skab (allokér) server-objekt 3. Bind server-objekt til name-server. Otto Knudsen/Note om RMI Side 4 af 7

5 Ad 1. Nameserver-objektet er et remote RMI-objekt, hvis klasse er færdig-implementeret af Java. Formålet med nameserver-objektet (fremover kaldt nameserveren) er at klienten vha. et symbolsk navn (alias) for server-objektet kan få en remote reference til det (remote-referencen består jo bl.a. af et objekt-id, som ikke siger brugeren (klienten) noget). Dette kan gøres vha. et opslag på nameserveren. Koden ser således ud: LocateRegistry.createRegistry(1099); På klassen LocateRegistry kaldes metoden createregistry som skaber nameserveren. Nameserveren er et remote RMIobjekt, men adskiller sig fra andre ved, at det angives med et portnr. Portnr 1099 er det normalt anvendte. For at kunne skabe nameserver-objektet skal java.rmi.registry.* importeres. Ad 2. Server-objektet skabes på normal vis med new-operatoren: KontoServer kontoserver = new KontoServer(); // Skab konto-objekt Da klassen KontoServer arver fra klassen UnicastRemoteObject kaldes dennes konstruktør, som sørger for at eksportere kontoserver-objektet til RMI-runtime. Når dette sker registreres objektet i RMI-runtimes liste over remote objekter, og objektet tildeles et objekt-id og et portnr (objekt-id og portnr bruges dog ikke af klinten, som i stedet bruger nameserveren til at skaffe en remote reference til objektet). I øvrigt er nameserveren også registreret i RMI-runtime; det skete, da nameserveren blev skabt. Ad 3. Server-objektet (kontoserver) skal nu bindes (tilmeldes) til nameserveren. Nameserveren har nemlig en liste over hvorledes hvert tilmeldt remote objekt kan mappes fra et symbolsk navn til objektets remote reference (Ikke at forveksle med RMI-runtime s liste over remote objekter). Når server-objektet bindes til nameserveren skal det symbolske navn og server-objektet derfor angives: Naming.rebind("Konto", kontoserver); Klassen Naming administrerer nameserverens liste over remote objekter. Koden for opstart af server-objektet kan fx ligges i server-klassens main-metode, således at når server-klassen køres opstartes server-objektet. Når main-metoden afsluttes kører RMI-runtime stadig (i en selvstændig tråd), og derfor eksisterer server-objektet og nameserveren også stadig, sålænge RMI-runtime har en reference til dem. Koden for server-opstart er vist her på næste figur: import java.rmi.registry.*; // LocateRegistry // Main-metode public static void main(string argv[]) { String regnavn="konto"; // Objektets reg.navn (id i regdb) try { // Start registreringdatabase-program (nameserver) på port 1099 LocateRegistry.createRegistry(1099); KontoServer kontoserver = new KontoServer(); // Skab konto-objekt // Registrer konto-objekt under navnet regnavn Naming.rebind(regNavn, kontoserver); System.out.println(regNavn + "-objekt er registreret!"); catch(exception e) { System.err.println("Fejl ved registrering: " + e); e.printstacktrace(); Otto Knudsen/Note om RMI Side 5 af 7

6 Hvad der er sket efter opstarten kan illustreres således: Server (efter opstart) F4892 kontoserver RMI-runtime Port 1099, ID F3456 Port 1266, ID F4892 KontoServer RMI-registry (Nameserver) F3456 "Konto", Port 1266, ID F4892 Altså: Der er blevet skabt to remote objekter: Nameserveren og kontoserver. De er begge blevet eksporteret til RMIruntime, som dermed har styr på deres portnumre og objektid (objektid kunne fx. tænkes at være objektets adresse). Derudover er kontoserver blevet bundet til nameserveren med det symbolske navn Konto, således at nameserveren nu har forbundet Konto med den remote reference til kontoserver. Bemærk at portnr på kontoserver (1266) og adresser på kontoserver (F4892) og nameserver (F3456) er vilkårligt valgt; de bestemmes nemlig af RMI-runtime, og vi (klienten) har ikke brug for at kende dem. Opstart på På klienten ser opstartskoden således ud: import java.rmi.*; // Klasse, som benytter remote konto-objekt public class Konto { public static void main (String argv[]) { KontoServerI konto = null; // reference til remote konto-objekt try { // Hent reference til remote konto-objekt konto = (KontoServerI)Naming.lookup("//pc353.tietgen.dk:1099/Konto"); catch (Exception e) { System.err.println("Fejl! Kan ikke få reference til konto-objekt: " + e); e.printstacktrace(); System.exit(1); // Her kan konto-reference bruges Som det ses, skaffes en remote reference til kontoserver-objekt vha. et opslag på nameserveren. Det gøres ved at bruge metoden lookup på klassen Naming og som parameter angive en tekststreng med ip-adresse (pc353.tietgen.dk), portnr på nameserveren (1099) samt det symbolske navn for kontoserver-objektet (Konto). Herved returneres en remote reference til kontoserver (konto). Bemærk at den remote reference typeconverteres til interfacet (KontoServerI). Remote referencen er nemlig ikke til et objekt af KontoServer-klassen, men derimod til stub-objektet, hvis klasse vi ikke kender navnet på. Otto Knudsen/Note om RMI Side 6 af 7

7 6. Brug af remote objekt KontoServer-objektet er nu klar til at blive brugt af klienten. Metoderne på objektet kaldes ved at bruge den remote reference (konto): try { // Brug remote konto-objekt konto.setkontonr(" "); konto.indsaet(100); konto.haev(50); System.out.println(konto.getKontonr()); System.out.println(konto.getSaldo()); catch(exception e) { System.out.println("Fejl ved brug af konto-objekt: " + e); e.printstacktrace(); System.exit(1); Læg mærke til, at klienten kan fange de exceptions, som eventuelt er blevet kastet på serveren. 7. Serialisering af lokale objekter I RMI-teorien skelner man mellem remote objekter og lokale objekter. Remote objekter er de objekter, som implementerer et interface som udvider Remote-interfacet (desuden bliver objekterne selvfølgelig først remote, når de er blevet skabt og eksporteret til RMI-runtime). Alle andre objekter er i RMI-sammenhæng lokale. Som nævnt er remote objekter identificeret vha. remote referencer, dvs. hvis man i RMI-kald overfører remote objekter som parametre/returværdi er det den remote reference, man overfører. Dette vil typisk ske, når man i et RMI-kald får returneret en remote reference til et andet remote objekt. Hvis man i RMI-kald derimod overfører lokale objekter som parametre bliver disse objekter serialiseret og sendt fra klient og server (denne serialisering (marshalling) sker i stubben, og skeleton en de-serialiserer, dvs. genopbygger objektet). Tilsvarende hvis et RMI-kald returnerer et lokalt objekt bliver dette serialiseret og sendt fra server til klient (denne serialisering (marshalling) sker i skeleton en, og stubben de-serialiserer, dvs. genopbygger objektet). Denne serialisering er nødvendig, fordi det ikke giver mening at overføre referencen til et lokalt objekt, fx. fra klient til server, idet serveren jo ikke har adgang til klientens adresserum (eller omvendt). For at lokale objekter kan overføres i RMI-kald skal man sørge for at deres klasser implementerer interfacet Serializable, således at RMI ved hvorledes de skal serialiseres. Det svarer til, at objekter som skal gemmes i en fil, også skal være Serializable. Bemærk at serialisering ikke altid er en let proces. Hvis et objekt har referencer til andre objekter skal disse også serialiseres med, for at referencen kan opbygges på den anden side i de-serialiseringen. Så vi må være glade for at Java klarer det for os! Otto Knudsen/Note om RMI Side 7 af 7