My instructions require my application to be able to run in local as well as in remote mode. In local mode, no sockets must be opened. This is how I tried to solve the problem: I have an interface DataAccess, which extends Remote. DataAccessImpl does not extend UnicastRemoteObject (the exporting is done explicitly by the ConnectionServer). DataAccess is the intermediary between the client and Data. Secondly I have a client-side ConnectionManager and a server-side ConnectionServer. The Client always asks the ConnectionManager for a database connection. In local mode, the ConnectionManager instantiates DataAccess and returns it to the client. In remote mode, the ConnectionManager fetches a DataAccess stub from the remote ConnectionServer and returns it to the Client.
Although everything works fine, I feel somewhat uncomfortable with this solution for the following reasons: 1. The instructions say that I have to create a data client that implements the same public interface as Data: DataAccess has the same public interface (plus business methods such as book()) - except for the fact that all methods have been added RemoteExceptions (the Data methods do not throw RemoteExceptions). 2. The instructions explicitely require a client-side Data client. In my opionion the DataAccess stub fulfills this requirement.
Yes that sounds right. The stub does fulfill that requirement. I had DataAccess extend Remote like yours. I had two implementation classes though. One called DataAccessRemote which extended UnicastRemoteObject, and one that was called DataAccessLocal which did not. That way I did not have to export the object explicitly in code. Which save a couple of lines of complexity for a junior programmer. Either way is fine too. Mark
... all methods have been added RemoteExceptions (the Data methods do not throw RemoteExceptions).
So did mine. Don't worry about it. I lost no points for doing it that way and am sure you won't either.
2. The instructions explicitely require a client-side Data client. In my opionion the DataAccess stub fulfills this requirement.
I'm not sure what you're getting at here, but your design sounds fine to me. You have isolated the client from the dirty little secrets of getting a connection into the database so all it has to do is book flights, search for particular flights and take coffee breaks Hope this helps, Michael Morris
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
posted 17 years ago
Thank you for your opinions - and for removing my doubts. And Mark:
Originally posted by Mark Spritzler: That way I did not have to export the object explicitly in code. Which save a couple of lines of complexity for a junior programmer.
When I have DataAccess for both, local and remote mode, I don't have code duplication. The little extra line for exporting is only in the server. How did you avoid code duplication?