FBN Architecture Query

[dean tomlinson]

Dear friends,
I have a design in mind for the FlyByNight system. But would appreciate any feedback / opinions.
Create DataAccess interface, which defines all the public methods of Data. The interface also extends Remote; so all methods are changed to throw Exception.
Modify Data to implement DataAccess. Also the implementation of criteriaFind, lock, unlock etc will be in here. The reason for this is due to the requirement existing, that the remote client must implement all the public methods of Data. Because this has created the need for a DataAccess interface. I think that the DataAccess interface should now not become the master entity regarding data access, and Data should be changed to show that it is only 1 implementation of DataAccess.
Create RemoteData class that implements DataAccess. Not sure whether to extend Data or to just hold an instance of Data as a member, and delegate to this � I have read that as a rule, composition is better than inheritance
DataAccessFactory, depending on the connection mode, will return an implementation of DataAccess. Data if in local mode or RemoteData is in networked mode.
At the client end I am going to use a facade object that totally hides all Data / Network type code, and just presents business type methods, such as getFlights, makeReseration
Thanks a lot for any advice

[Mark Spritzler]

If in local mode the factory returns the Data object, then the facades call to lock will lock the record in local mode, which isn't needed, since in local mode there is ever only one user.
But I wonder if that is a problem at all? I mean it won't hurt the database to actually lock the record in local mode, but on the other hand it is extra work that it doesn't have to do.
Other than that you design is very solid.
I always wonder if Data needs to implement the DataAccess interface, like you intend to do, or not. I did not have it implement the interface. For some reason I thought the Data class and the DataAccess interfaces where different. In that I was separating them. DataAccess interface extends Remote and throws Exception, well the throwing Exception won't have any affect, since all the exceptions thrown in the Data class would be more specific classes. But the Remote part is where I wonder. I mean the purpose of the Data class by itself is to provide Data services to the db.db file only. It does not have any responsibility to know or set up a mode(local or remote), which extending Remote does.
Now here's the catch, in my DataAccess interface I also extended Remote, so my implementation of LocalDataAccess would also be a Remote object, when it doesn't need to be, which is almost like above with Data implementing the DataAccess interface. Some people get around that by creating another interface for RemoteDataAccessInterface, and a LocalDataAccessInterface, and this allows only RemoteDataAccessInterface to extend Remote where LocalDataAccessInterface does not.
I hope I have cleared things up, more than just confuse myself.
Mark
So to answer your question again, I think you have a great design so far.

[dean tomlinson]

thanks a lot for your comments Mark. I just need some free time now so I can get on with the development.

[Peter den Haan]

Mark, do realise you broke the contract for the Remote interface.
"Deanos", please review our naming policy and change your display name. Thanks.
- Peter

[Mark Spritzler]

Mark, do realise you broke the contract for the Remote interface.

Where. In the DataAccess interface extending Remote?
Thanks Peter, and welcome back to the SCJD Forum.
Mark

[Peter den Haan]

Mark, thanks for the welcome And forget what I said above -- neither your interface nor its implementations break the Remote contract or anything else.
For some reason, I thought that RMI would always try to pass instanceof Remote objects by reference. This is not true. It will pass all objects by value (serialization) unless they have been exported by calling UnicastRemoteObject.exportObject(). Doh.
- Peter