Featured White Papers

• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Want to build HTML5 web applications? Check out Kendo UI JSP Server Wrappers!

  Learn More!

• Build modern HTML5 web apps using Java. Try Kendo UI Complete for JSP!

  Learn More!

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

An in-depth look at RMI callbacks (4/20/99)

The JavaWorld experts answer your most pressing Java questions -- every week

By Java Q&a Experts, JavaWorld.com, 04/20/99

I have a problem with RMI callbacks. Specifically, my server program successfully invokes a client method using callbacks. However, since the client method executes on the server side in this case, how am I supposed to manipulate my frontend AWT components from this method? Or is it not possible using RMI callbacks? I need my frontend AWT components, such as Lists, to be updated with values upon callback. Please explain.

We've received quite a few questions regarding RMI this month, from specific issues such as yours to things like, "What's the ding-dong deal with this RMI stuff?" So we thought we'd use your question as a jumping-off point to address RMI as a whole.

Here's the short answer to your question. It isn't correct to say that the client method executes on the server. When using RMI to do callbacks to an application client, the client code doesn't execute on the application server. Only the RMI proxy or stub class executes on the application's server machine. The proxy invocation then arranges for the implementation class for the callback to execute on the virtual machine of the application client. Therefore, since the RMI server logic and the frontend AWT components coexist on the same VM, there's no problem in having an RMI "callback" update information kept by AWT components.

Here's a much longer answer, with a sample program that illustrates what's going on:

It can be difficult when learning RMI to predict what's going on where. The trick is to remember that for any RMI interface there will be two classes that execute: the proxy or stub class runs in the VM of the caller, and the implementation class runs in the VM of the server.

The other thing to keep straight is that it can get confusing to label one VM the "client" and the other the "server" for a particular application. In RMI terminology, any VM that initiates an RMI invocation is the client, while any VM that receives and processes an RMI invocation is the server. I find it easier to think of Java VMs as peers, any of which may act as RMI clients or servers depending on the circumstances. Thus, in RMI there is really no such thing as a "callback" -- a callback is really just an RMI invocation in the other direction! In the context of what many people call client/server applications, it's helpful to designate the program that performs the user interface functions as the frontend or application client, and the program that provides services to that GUI as the backend or application server.

Using this new nomenclature, the question boils down to: Can RMI be used to allow a backend VM to send update information to a frontend VM and have the frontend VM use that information to update the information presented by the GUI? Put this way, the answer is: Yes!

Enough text. Let's look at this in code. Suppose we have a frontend whose mission in life is to display a list of stock symbols and stock prices The job of the backend would then be to notice when a stock's price changes and update the frontend with this information. Upon receiving such an update, the frontend would replace the old price for that stock with the new price in the AWT-based user interface.