But there is also the "inside view", the things under the hood. Real applications in enterprise environments are quite complex and often are interconnected with other applications: The software of the human resources department of a company and the software of the financial department of that company need to work together. Changes in the status of the employees need to automatically be reflected in their salary payments. The financial department's software will also need to interact with the software of banks to automatically issue salary payments. It becomes clear that this sort of connectivity and automation cannot be achieved with JSPs or plain servlets alone. Some "glue" technology is needed.
The glue technology is "remote procedure calls" (RPCs), the ability that a process on my computer can tell a process on a another computer to invoke a procedure (such as "pay salary to account xyz"). The code of that procedure will be unknown to my computer and the execution takes place entirely on the other system.
In this course, we will learn three approaches to RCP, Java's built-in RPC method, Web Services, the standard method in enterprise computing, and JSON RPC, an RPC technology used in situations where simplicity and speed beats broad enterprise tool framework supports.
Here you can find examples on how to perform Java Remote Method Invocation.
2.1. RemotePrintServer / RemotePrintClient
The interface RemotePrintInterface provides a method
String. The RMI Server RemotePrintServer implements this method in a straightforward fashion: it prints the
System.out. An instance of this server is created and registerd as RMI server object under the name
server in a registry listening for requests on port
9999. The RemotePrintClient wants to make use of this very valuable print service: It first obtains the registry and then, from this registry, the object names
server. This object must be an instance of RemotePrintInterface, so we can call its
2.2. RemotePrintServer / RemotePrintClientErroneous
As the name RemotePrintClientErroneous implies, this is a "wrong" version of the above example. The error is located in an incorrect typecast in the RemotePrintClientErroneous program: The program incorrectly assumes that the object returned from the registry can be cast to RemotePrintServer, which it cannot. It can only be cast to RemotePrintInterface, as done in RemotePrintClient.
But why is that? The reason is already mentioned in the text of the first example: The actual instance of RemotePrintServer resides in a different virtual machine (process) from the client's process. Its actual implementation code is unknown to the client. The object returned by the registry to the client is just a Proxy instance which "implements" all interfaces of the original object which inherit from Remote. RemotePrintInterface is such an interface. If a method of the proxy object is called, it will send a message with the method name and parameters to the actual object on the server side. The server object will invoke the method and send back the results. Then the proxy's method can return as well. This way, the communication and "remoteness" of the procedure invocation is invisible (transparent) to the user of the client object. And since the proxy object is not the real object, we cannot cast it to RemotePrintServer without receiving an exception.