Get your CodeRanch badge!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes No sockets? Design considerations Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "No sockets? Design considerations" Watch "No sockets? Design considerations" New topic
Author

No sockets? Design considerations

Mag Hoehme
Ranch Hand

Joined: Apr 07, 2002
Posts: 194
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!


Mag
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
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


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
Mag Hoehme
Ranch Hand

Joined: Apr 07, 2002
Posts: 194
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?
 
jQuery in Action, 2nd edition
 
subject: No sockets? Design considerations
 
Similar Threads
The Data Client / Connection Proxy
ConnectionFactory question
Design feedback
Design and questions
NX: (Contractors) Interfaces and design question