Hi Ranchers,
Background
----------
I am working on my
SCJD. Until now I've created a Data-Access-Layer and a GUI. Between both I've implemented a very small business layer (methods book, release, search). My GUI doesn't communicate directly with the Data-Access-Layer, it goes over the business layer. The application works quite fine, but until now it is all single-user. I've not create the server part.
I'm quite familiar with topics like Swing or the RandomAccessFile, but RMI and Sockets are new for me. Because I don't know any of these twos techniques, and most of you use RMI, I decided to make my first steps in RMI.
Server
------
I successfully created a very small
test case with a Server (extends UnicastRemoteObject implements ServerInterface), a ServerInterface (extends Remote), a ServerMain and a ClientMain-Class.
My idea to "migrate" my actual application on RMI is to change the connection between my GUI and my Business-Layer, where I have an interface ServiceInterface. For that I want to create a ServerInterface that extends my ServiceInterface. By the way can this be a wise approach ?
The problem on this is that the ServerInterface has to add the RemoteException to all of my methods and if I do that than I break my contract with the ServiceInterface. So, I can't do this.
In Ken Krebs
thread (thread) I read about one solution, but I don't prefer it:
Networking
========
Choosing RMI seemed to be a total no-brainer as it is so simple compared to using sockets. My entire networking code compiles to only 5,408 bytes of code. It consists of 2 classes, RemoteServices and RemoteServicesImpl. RemoteServices is an interface that extends Services and Remote. It has no body. This is possible because all the Services methods throw IOException and can therefore also throw a RemoteException. It's a nice trick that keeps things simple. RemoteServicesImpl extends UnicastRemoteObject and implements RemoteServices. It has 2 parts, the implementation of RemoteServices (i.e. the 2 Services methods) and static getServices methods that allow the clients to get a Services instance that is either an RMI server for the Network Server application functionality or its stub for the Network Client application functionality. The Services method implementations simply delegate all work to the ServicesImpl singleton. Since all of the locking occurs in a single method call in the Network Server's JVM, there is no need to worry about the RMI connection dieing in the middle of a locking operation.
I 've another idea. I'm not able to extend the ServerInterface from the ServiceInterface. But I'm able to do the contrary. What do you think about extending the ServiceInterface from the ServerInterface. That doesn't violate any rules. The only which I found not really fine is that my ServerInterface extends Remote, and if I extend the ServiceInterface from ServerInterface than I've an "IS-a" relationship between ServiceInterface and Remote. I don't believe that a ServiceInterface is a Remote-Object.
What do you think about it ? Is it ok ? Have you other ideas ?
Best regards
Christian Nicoll