interface DataAccessInterface extends Remote //for DataAccessLocal and DataAccessRemote. have all the public method of Data class and have criteriaFind(String criteria),book(String flightNumber,int num),String[][] getData()
There's a fundamental design problem with that. This mixes low-level, concrete, generic database API ("criteriaFind", "read", "write", etc) with high-level, abstract, application-specific business API ("book"). Never the twain should meet.
On an architectural level, take a look at my boilerplate 3-tier architecture diagram[tm]:
User Interface <==> Business Logic <==> Database
You find this approach in almost any well-conceived modern application. There are three tiers, and two interfaces between them. You are mixing up the two interfaces, which means you are mixing up the Business Logic tier with the Database tier.
In the FBN project, either interface is in principle a good candidate for the RMI interface between the client and the server. However, Sun's requirement that
you should have a client-side object that implements all the public Data method effectively forces you to make the RMI interface correspond to the Business Logic <==> Database interface. Anything else would make a muddle of your architecture.
With the above considerations in mind, it should be clear that the book() method implements business logic, and that it therefore cannot live on the server.
DataAccessRemote extends UnicastRemoteObject implements DataAccessInterface //Remote Object too,as clientID,I am confused with it. Can I do it like this?
Yes, fine.
DataAccessLocal implements DataAccessInterface //Local data
What do you need this for? Surely Data implements DataAccessInterface? Junk this class. It serves no purpose.
and can i copy DataAccessRemote_stub to client.jar?
Either that, or put it in a shared.jar and use the Class-Path manifest attribute in client.jar and server.jar to link in shared.jar.
HTH
- Peter