RMI Factory

[Kevin Broderick]

Hello everyone.

I'm trying to decide if I should need an RMI Factory. From reading Andrews book, he points out that thread identification can become a problem on using RMI so he suggested on creating an RMI Factory or client if you wish to call it that.

Ok so my solution so far, I've created a thin client where the business rules reside on the server. In the Bodgitt and Scarper assignment the data class can return a cookie value thus identifying the client, but because I'm using a thin client I'm not passing this over the network.

I now have created a connector class where one of its constructors is called depending if the application is to be a stand alone, server or network. Code implemented as a network is as follows:

public Controller(String IPAddress, int PortNumber)throw ControllerException{
    try{
        ContractorFactory ServiceFactory = new ContractorFactoryService(IPAddress, PortNumber);
        connectorService = ServiceFactory.getContractor();
}catch(RemoteException e){
        throws new ControllerException(e.getMessage());
    }
}

And the contractorFactory or client class and interface is as follows:

public interface ContractorFactory extends Remote {
	
    public RemoteContractorDAO getContractor() throws RemoteException;  
}
public class ContractorFactoryDAO implements ContractorFactory{

Registry registry;
	
    public ContractorFactoryDAO(String IPAddress, int portNumber)throws RemoteException{
    	registry = LocateRegistry.getRegistry(IPAddress,portNumber);
    }
    
    public RemoteContractorDAO getContractor() throws RemoteException{
    	return (ContractorService)registry.lookup("B&S_Server");
    }
}

Would a solution like this be correct? I'd be interested to know if ye fellow ranchers implemented the client such as above. Maybe a simpler client class is all thats needed when the application wants to go via network and my way of going about it is overkill. I noticed while searching through the Java ranch that most of ye chose a thick client. Could the reason be because by doing so you avoid the problem of thread identification through RMI thus not having this as a problem for your locking.

Again, I much appreciate your advice and thank you

Kind regards

Kevin

[Roel De Nijs]

Hi Kevin,

You have a lockCookie for client identification and you decide to ignore it. As far as i know you are the 1st one ignoring the lockCookie. Why ignoring this cookie and creating another solution for it, if the solution is right there?

My interface didn't have such a lockCookie and I decided to implement a thin client. I didn't use the RMI Factory as described in Andrew's book. More info about my approach can be found here or in other threads on this forum (using search function).

Kind regards,
Roel

[Olu Shiyan]

Just some clarification guys: I have just read the RMI chapter of Andrew's book and feel like I dont need to use an RMI factory as was done in the book. This is because my lock method returns a cookie which is used by the update, delete and unlock methods. Hence, client identification with regards to logical record locking is not a problem. I believe this is the only reason why an RMI factory was used by Andrew and that I dont need an RMI factory since my Data.lock method makes provision for client identification via lock cookie?

Thanks

P.s:

By the way, to the knowledge sharing here and here , these two threads have been very helpful in sorting out my thoughts as to how to implement the network layer.

[Roberto Perillo]

Kevin Broderick wrote:Would a solution like this be correct?

Well champion, I'd say that, if it works, then yes. But what you have to consider is: do you think this solution is complicated? There are other proposals of design (such as the ones indicated by my good buddy Olu) that can ease your job. If your lock() method returns a value, then using it will ease your job. I implemented a thick client, but today I would implement a thin client. This way, the transactions will be controlled on the server and all you'll do on the client side is call a method, say, bookRoom(), and this method will call the lock()/update()/unlock() methods. To me, it is more complicated to do this on the client side because you are controlling the transanctions on the client side (although in your case it will be easier because your lock() method does return a value). I think that if we implement a thin client, then it is easier to build other clients, and the lock()/update()/unlock() will always be respected because they are controlled on the server side.

[Olu Shiyan]

Cheers Roberto.