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
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.