Remote Objects

The Situation Is there a better (in terms of programmer time) way to do network communications? What is it we’re trying to accomplish? Transmit data (position updates, etc) Cause some action to happen on the remote machine (Cannon fires, tank explodes, etc.) For the second case, implementations in sockets often look very similar

Remote Commands Receive Message Determine Msg type Call method in local VM space Return Results

Major Computer Science Insight Computers are good at doing repetitive things. Why not write a framework to automate this process? Lets make it appear that we’re directly calling methods on objects on remote machines Saves having to write all that nasty code every time we want to do a command implementation

Remote Objects The idea is that we make available some server object with methods. Clients get a reference to the server object, then call methods on that object. doSomething() public double doSometingB(int anArg) Proxy Object (client) doSomething() public double doSometingB(int anArg) Server Object (client)

Remote Objects To the programmer on the client side, the server object appears to be just another object. In reality it might be on the same machine, or halfway around the world. Generally you have a stand-in or a “proxy” for the server object that resides on the client host. The proxy has all the same methods as the server object, but only forwards the messages to the server object

Remote Objects This is a popular idea that dates back a ways, and there are many implementations Remote Procedure Call, RPC. Oriented towards procedural programming Remote Method Invocation, RMI. A java-only technique for calling methods on other machines; essentially stripped-down CORBA Common Object Request Broker Architecture, CORBA

Remote Objects We’ll be looking at RMI and a little about CORBA CORBA is cross-platform and multiple-language, and reasonably popular RMI is reasonably easy to understand On the other hand, RMI is Java-only

Remote Objects So what needs to be done? Usually we have a proxy object on the client side. This proxy is responsible for communicating with the “real” server object placing all the parameters into the right format to be sent across the wire Getting the response back Masquerading as the server object

What Could Go Wrong? RMI has some potential issues, mostly relating to it being too good at what it set out to do Objects programmers are used to are fast, highly reliable, and local. They can be tightly coupled with other objects to accomplish some task RMI makes remote objects look like local objects; but they’re not, in a fundamental way

What Could Go Wrong? Though RMI makes it appear that objects are local the the programmer in syntax, the reality is that the method calls are being made across the network. And compared to making method calls inside a virtual memory space, this is slow and unreliable. You can get away with making method calls in a tight loop for local objects; not so for remote objects You can more tightly couple objects in a local VM Don’t have to worry nearly as much about failed method calls Easy to pass large amounts of data between objects

What Could Go Wrong? From a syntax standpoint it looks like a local object, and that tempts you to use it in inappropriate ways Remember that remote objects should be very loosely coupled, and keep in mind their limitations

What Could Go Wrong? If you’re traversing firewalls in your calls you will have an uphill fight against security policies Scalability: TCP sockets, no provision for broadcast or multicast, etc.

Proxies The proxies are stand-ins for the real object on the server. They get the request locally, serialize all parameter data, send it across the wire via sockets, and get a response back To the user, it looks like a local object. In reality all the computation in the object is being done on the server side

RMI RMI uses an rmic compiler to create proxy objects from existing classes Design the class you want to act as a server Run it through RMIC Define a security policy Start up rmiregistry, which acts as a way for servers to register themselves as available Run client

Example RMI implementation of a card deck