Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

No sockets? Design considerations

 
Mag Hoehme
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Any thoughs and comments on this are welcome!
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mag,

... 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
 
Mag Hoehme
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic