1 / 76

Lesson 3

Lesson 3. Advanced RMI JNI. Assorted real-world RMI issues. Review of rmi basics. rmi is a relatively very simple D.O. framework. Major limitations Only java to java Major advantages Clean, easy to deploy, robust Maps very cleanly to java language semantics

stian
Download Presentation

Lesson 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Lesson 3 Advanced RMI JNI

  2. Assorted real-world RMI issues

  3. Review of rmi basics • rmi is a relatively very simple D.O. framework. • Major limitations • Only java to java • Major advantages • Clean, easy to deploy, robust • Maps very cleanly to java language semantics • Competing frameworks/technologies • CORBA • Web Services

  4. rmi approach • Distributed objects have look-and-feel of local objects, but can be called across machines. • A distributed object is a regular object augmented with the following: • Extends UnicastRemoteObject • Have public distributed methods that throw RemoteException • Have parameters that implement Serializable • Have a constructor that throws RemoteException (it need not directly call super) • Have a separate interface file that lists the remote methods and extents java.rmi.Remote.

  5. Today’s naming convention for rmi

  6. Creating stubs • Layout of most simple rmi application before stub generation looks like • Server • StoreImpl.java (implementation) • Store.java (interface) • StoreServer.java (to bootstrap) • Other local classes • Client • StoreClient.java • Store.java • Must compile client and server before using rmic!

  7. Stub Class Generation • Recall that the _stub class contains the glue messaging code on both the client and the server. • There are three ways to create the stubs depending on which version of java you are using: • As of jdk5.0, stubs generated automatically. • As of jdk1.2, stubs are generated as • rmic –v1.2 StoreImpl • Before jdk1.2, stubs and skeletons are creates as • rmic –v1.1 StoreImpl • This creates StoreImpl_stub.class

  8. Creating stubs • Layout of most simple rmi application before stub generation looks like • Server • StoreImpl.class (implementation) • Store.class (interface) • StoreServer.class (to bootstrap) • Other local classes • StoreImpl_stub.class • Client • StoreClient.class • Store.class • StoreImpl_stub.class • Must compile client and server before using rmic! Make sure these are same!

  9. Deployment issues • A couple of more sophisticated issues arise in deployment • How to have client automatically download stubs and update class defintions • How to handle security issues • There are pretty simple approaches for each described in book. • For now, we will assume in our assignments that client has all updated class files and that security is not an issue. • I will give a quick pointer to security issues later in this lecture.

  10. More complex issues Callbacks

  11. Typical model of callback • class Client{ • Client(){ • Server x = new Server(); • x.doIt(…, this); • } • doIt(…){ • …. • } • } • class Foo{ • public void doIt(…, Client client){ • … • client.doIt(); • } • }

  12. Callback example – timer class • At specified time interval, server sends you e.g. current time, which you display locally. • Design • Server contains register method and receives remote reference to client • Client contains update method which recieves current time and displays • Consider how both all rmi and rmi + sockets version of this program would look

  13. Another callback example • TicTacToe game is another good example of a callback. • Client accesses server object to place next move. • Once new move is placed and accepted, server must contact other player with updated move. • In this sense, server become client and client server for this particular call • How to architect this with rmi?

  14. Tic-tac-toe with RMI • Pure rmi implementation • TicTacToeClient is adorned as D.O. also! • Contains method such as otherPlayerMove • TicTacToeClient calls server register method and passes copy of this • TicTacToeImpl stores this and uses for D.O. call to inform other player of current players move. • Note that notion of server and client is only meaningful for a particular method!

  15. Tic-tac-toe with RMI • RMI + sockets implementation • In this example, each client runs a socket server and gets a direct socket connection from the game server • TicTacToeClient is not a remote object • Game server still runs as remote object in regular way • Examples all posted on web site

  16. Handling many server objects Bootstrapping registry

  17. Binding many objects to registry • What if many people logon to play tic-tac-toe? How do we give each pair their own game? • What if we have many objects in general to post? • There are two ways to deal with this • give each their own name in registry (not good) • bootstrap off a single factory method (good)

  18. Bootstrapping • For tic-tac-toe example, we could have a method: TicTacToe getGame() throws RemoteException; • As long as both getGame and TicTacToeImpl are setup up as remote, only one remote object need get posted to the registry. • Can create a pool of tic-tac-toe games and assign as they come in. • Will be required for hw2, recommended for hw1. • This is a great simplification vs. binding multiple objects! • See examples under bootstrap directory

  19. Contacting rmi registry • In our simplified application, to get a remote reference we called: Naming.lookup(“tic-tac-toe”); • This assumes the default rmi port (1099) on localhost. • To change ports, run rmiregistery <port> • The more general rmi URL is Naming.lookup(“rmi://host:port/name”); e.g. to lookup on port 99 at host yourserver.com Naming.lookup(“rmi://yourserver.com:99/tic-tac-toe”);

  20. Listing objects in the registery • Note that the Naming class has a method list which returns a listing of all objects bound to the registry. • It is called from the client as: String[] bindings = Naming.list(“<rmi url goes here>”);

  21. Other changes in jdk5.0

  22. Naming service

  23. Security issues • Recall that client needs up-to-date stub functions. • No problem if these are available locally on client. • However, keeping a local installation can be cumbersome. Often stubs are downloaded via other servers (we’ll see how to do this). • In this case, a SecurityManager needs to be installed to ensure that the stubs are not hostile (unless applet is used, which has its own SecurityManager).

  24. A few notes about security/deployment

  25. RMISecurityManager • Easiest way to do this System.setSecurityManager(new RMISecurityManager()); • By default prohibits any socket connections • Obviously this is too strict. Need a policy file to allow client to make network connection to rmi port. It would look something like: grant{ permission java.net.SocketPermission “*:1024-65535”, “connect”} java Client –Djava.security.policy=client.policy

  26. Server-side security/firewalls • For this class we assume you have control over the server security configuration.

  27. RMI application deployment • Very simple if client/server both have up-to-date copies of all class files • However, this is unrealistic and impractical. • Better if client can dynamically load classes remotely. • RMI provides such a mechanism built on top of standard server protocols

  28. Deployment, cont. • For server, following classes must be available to its classloader: • Remote service interface definitions • Remote service implementations • Stubs • All other server classes • For client • Remote service interface definitions • Stubs • Server classes for objects used by the client (e.g. return values) • All other client classes

  29. RMIClassLoader • RMI support remote class loading by specfying the java.rmi.server.codebase property with an appropriate URL • This is done as: java WhateverImp -Djava.rmi.server.codebase=http://whatever ftp, file, etc. can also be used • See deployment directory in class examples • Proper remote deployment will be required on the next assignment.

  30. Remote Objects and object methods Clone, equals, etc.

  31. Using Remote Objects in Sets • Recall that equals() and hashcode must be overridden to use Sets. • For remote objects, this would require a network call to the server, which could fail. • Since equals does not throw RemoteException, it cannot be overridden and used remotely. • Thus, must use equals and hashCode methods in RemoteObject class. • These unfortunately only compare stubs, not contents. • Probably not a great idea to do this unless necessary

  32. clone() method • Can not call at all directly for stubs • If you want to clone, simply define a new remote method (e.g. remoteClone), have it call clone locally, and return copy as parameter.

  33. Non-remote objects • Note that all objects which are not remote are fully copied to client • This is very different from local method call, where objects are passed as references. • Thus, only remote objects can change state across client-server call • Also, performance issues can arise for very deep object graphs

  34. Remote Objects and Inheritance

  35. Using inheritance with rmi • Stubs are generated only from classes that implement a remote interface (and only for methods in that interface). • Subclasses of remote classes can be defined and used in place of superclass in remote method call. • However, only superclass remote methods will be available, not any other defined in subclass!

  36. Synchronized RMI calls

  37. Using synchronized methods in rmi • Recall that remote objects are passed by reference (stub). • Thus, when many users request the same object, they are manipulating a single copy. • If the object is immutable, there is no need to synchronize. • Otherwise, proper synchronization should be done in the regular way – using synchronized methods where appropriate, and synchronized blocks if necessary.

  38. RMI calling semantics

  39. Native Data Types • Native data types • pass by value – parameter copied before remote transmission • exactly like single jvm behavior • machine-independent format used

  40. Objects • Calling sequence for object parameters • pass by value also! • this differs from single-jvm behavior • All objects are completely serialized (deep copy) and sent to remote location. • This can be hugely inefficient. Be very careful when performance is at a premium!

  41. Remote Objects • Java defines a third type of parameter – a remote object. • Remote objects must be setup as rmi distributed objects in the regular way (extend UnicastRemoteObject and implement Remote interface) • Remote objects are pass-by-reference. proxies rather than serialized objects are returned.

  42. Distributed Garbage Collection

  43. Distributed garbage collection • Server keeps track of clients that have requested object. • When client disconnects, they are removed from the list. • Also a timeout mechanism controlled by java.rmi.dgc.leaveValue. • Remote object can implement java.rmi.server.Unfererenced to get notification when clients no longer hold live reference. • Bottom line: not much to worry about here.

  44. Object Activation

  45. Creating objects remotely • What we have learned about RMI requires the server to instantiate one or more objects and post them to the registry • What if objects do not exists. Is it possible for the client to remotely create an object on the server? • This can be useful occasionally and is now possible with java Activation framework. • We will not discuss Activation in this class.

  46. RMI inter-language calls indirectly using JNI

  47. JNI • Recall that CORBA allows inter-language remote object calls; RMI does not! • However, JNI allows one to call “native code” directly from java. • Thus, the two together give more CORBA-like capabilities. • rmi calls java remote method, which locally calls C code, which returns java parameter(s), and rmi sends back to client.

  48. What exactly does JNI do? • Provides the glue between java – C/C++ (but no other languages) • Provides the machinery for mapping datatypes. • Can be used to call C/C++ from Java (typical), or Java from C (invocation API) • Does NOT provide network transparency!

  49. Reasons for using JNI • Feature not available in java language. • Code already written in another language, don’t want to rewrite. • Java is slow. • Other language has no additional features per se, but has much better syntax for handling certain operations (Fortran for math).

  50. Problems with JNI • Only provides C/C++ bindings. Going to Fortran, COBOL, Ada, etc. requires extra step. • Not portable • Mapping is not trivial • No built-in security

More Related