The code below is my current approach to provide an RMI interface to the client.
My thoughts on this approach.
DBAccess is Sun’s provided interface.
ClientDBAcess extends above to introduce two additional methods –
readRecordObj() – identical to Sun’s readRecord() except a Record object is returned instead
of an Array of Strings. I don’t particularly like the method name ! readRecords() – Return all records in the database. Useful to initialise the JTable on startup.
1) The client will communicate with either the local or remote database via a ClientDBAcess instance.
In the local mode, I will return an instance of Data, which implements ClientDBAcess.
In the remote mode, I will return an instance of DatabaseRemote, which implements ClientDBAcess.
This way, the client will not have to worry whether the connection is remote or local.
Any issues that I have overlooked/should consider with this approach ?
2) Is it OK to simply add the RemoteExceptions to the methods DatabaseRemoteImpl class, like I have shown.
3) My client will not be using the readRecord() which returns an array of Strings or findByCriteria() which
returns a array of londs, however, if the client did use either, would there be any issue with serialization ?
4) Do I need to consider any serialization issue with respect List<Record> readRecords() ?
Joined: Feb 29, 2008
1. See 2.
2. It's not possible, your remote class won't compile.
4. Only that Record is Serializable.