• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Writing Data Client

 
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
About Writing the data client My specs say:-


To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.


Can some one explain this to me. Does this mean I cannot implement my interface using two separate classes one for local and one for remote.
Thanks.
 
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is how I did mine... I have a LocalData object and a RemoteData object. My LocalData extends Data and basically uses Data as is. My RemoteData is extending UnicastRemoteObject (I choose RMI) so I had to keep a private reference to a Data in my remote and then have methods to call all of the public methods that are in the Data class from the RemoteData object.
Also, both LocalData and RemoteData implement a common DataAccess interface, so that the client does not have to worry about having a local or remote connection.
Hope that helps,
[ August 10, 2002: Message edited by: Nate Johnson ]
 
Samual Harvey
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for an early reply. Can you clarify further. I have this doubt on (using two interfaces vs one interface), if I should create two similar interfaces both extending Remote. One to be implemented by the client side of local and remote classes and the second one to be implemented by the Server side class.
Example Solution 1:-
Interface 1 as follows:-
Interface DatabaseInterface extends Remote
class DatabaseLocal implements DatabaseInterface
class DatabaseRemote extends UnicastRemoteObject implements DatabaseInterface throws RemoteException. Thus the client uses DatabaseInterface.
Interface 2 as follows:-
Interface ServerInterface extends Remote
class ServerInterfaceImpl extends UnicastRemoteObject implements ServerInterface. Thus the server uses ServerInterfaceImpl
In this case both the Interfaces uses all the methods of Data Class.
Example Solution 2:-
Do not use second interface, instead the both client and Server uses DatabasInterface.
Any comments are appreciable.
Thanks.
 
Nate Johnson
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is how mine works...
DataAccess in the base interface that includes all public methods of the Data class.
LocalData implemets DataAccess and extends Data to fullfill DataAccess requirements.
RemoteDataAccess implements Remote and DataAccess... nothing else addes to RemoteDataAccess interface. Then RemoteData implements RemoteDataAccess and extends UnicastRemoteObejct. It keeps a reference to a Data and had all the public methods that Data has, each of which go through the reference to Data... except that I have a LockManager class that the RemoteData knows about and uses to do the lock and unlock methods.
I choose two interfaces because I did not want to have any objects that were not remote objects implementing the Remote interface. If it is not a Remote object, don't implement Remote.
So it is a bit like your number 1 solution, with an extra interface for remote objects...
[ August 10, 2002: Message edited by: Nate Johnson ]
 
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Originally posted by Samual Harvey
Interface 1 as follows:-
Interface DatabaseInterface extends Remote
class DatabaseLocal implements DatabaseInterface
class DatabaseRemote extends UnicastRemoteObject implements DatabaseInterface throws RemoteException. Thus the client uses DatabaseInterface.


That's similar to what I did, except that I used a Builder Pattern to create composites for local and remote. By using a single interface, you simplify client interactions with the database.


Originally posted by Samual Harvey
Interface 2 as follows:-
Interface ServerInterface extends Remote
class ServerInterfaceImpl extends UnicastRemoteObject implements ServerInterface. Thus the server uses ServerInterfaceImpl


Could you elaborate on this? What exactly do you have in mind here?

Michael Morris
[ August 10, 2002: Message edited by: Michael Morris ]
 
Samual Harvey
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Interface 2 as follows:-
Interface ServerInterface extends Remote
class ServerInterfaceImpl extends UnicastRemoteObject implements ServerInterface. Thus the server uses ServerInterfaceImpl


I was thinking if I need an additional interface to be used just by the server OR the server can also share the same DatabaseInterface used by the client.
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Samual,
Well, I'm not sure that you need a third (or even a second) interface for the server. You could, I suppose do something like RemoteDataInterface extends LocalDataInterface extends ServerDataInterface (extends Remote?). But then what really is the difference in the three? I think I see where you're trying to go with this: target three different types of database interaction. The server connection only needs to implement lock (and possibly unlock) and close; the local, everything but lock and unlock; and the remote everything but close. If that's what you want to do, you can still do it with a single interface. If you do go with multiple interfaces, I would at least encourage you to have a parent interface that is always used by the client. Once the client is started in either local or remote mode, all database interaction should be identical.
Hope this helps,
Michael Morris
 
Ranch Hand
Posts: 295
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi reader,
Does this mean apart from Data class which is already present in db package, should also have its all same public methods in server pack ?. If yes then it would be double implementation of Data class methods. Then in that case can we extend Data class more than once.
Thank you,
 
Nate Johnson
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I personally would not make the server with the same methods as the Data class.
I would have the server be a factory that would spit back remote data object for the client. When the client starts up, it asks for a connection and if it is in remote mode, the server would return a new remote data object (which contains a reference to the database, the Data class, being used for all connections on the server).
Just my two cents...
 
Gurpreet Saini
Ranch Hand
Posts: 295
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi johnson,

To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.
--------------------------------------------------------------------------------


Then don't you think you are going against the above said quote.
Thank you,
 
Nate Johnson
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gurpreet Saini:
Hi johnson,

Then don't you think you are going against the above said quote.
Thank you,



No. My RemoteData object, which is sent back from the remote data factory (the server), has all of the methods that Data has. It stores a reference to Data (which is shared by all remote clients), and calls the corresponding methods on Data when the same method is called on the RemoteData class.
This RemoteData implements DataAccess (interface) as does my LocalData object... so, the client does not care which mode it is in, it just makes calls to a DataAccess object.
 
Samual Harvey
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I choose to use only one interface i.e. DatabaseInterface. I have the following three packages:-
suncertify.client
suncertify.db
suncertify.server
In which package should I keep the interface. And in which package should I keep the DataInterfaceLocal and DataInterfaceRemote classes. Also, I am creating a factory class which returns a DatabaseInterface (local or remote) reference. So where should I keep the factory class.
 
Nate Johnson
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is the way that I did it...
If it had to do with the database, I put it in the db package... if it had to do with the server, I put it in the server package, etc.
As long as you can justify where you put things, it probably does not really matter.
FYI: I am submitting my assignment as soon as Sun tells me that I have access to upload, so maybe some others that have already gotten a passing grade can comment on this packaging structure too.
 
Samual Harvey
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks!!! All the Best for your assignment.

Originally posted by Nate Johnson:
I would have the server be a factory that would spit back remote data object for the client. When the client starts up, it asks for a connection and if it is in remote mode, the server would return a new remote data object (which contains a reference to the database, the Data class, being used for all connections on the server).


w.r.t above, did you made a factory class inside server package? Also does your class that starts the Server process, has a reference to your remote class ( i.e the class that implements your interface and extends UnicastRemoteObject). Did you made this remote class a part of server package.
Thanks.
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Samual,
You should absolutely use a connection factory in the server. If you don't, you'll have to keep up with client threads yourself. Why not let RMI worry about that? Just issue each client his own remote connection object and forget about him.
Hope this helps,
Michael Morris
 
Nate Johnson
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Samual Harvey:
Thanks!!! All the Best for your assignment.

w.r.t above, did you made a factory class inside server package? Also does your class that starts the Server process, has a reference to your remote class ( i.e the class that implements your interface and extends UnicastRemoteObject). Did you made this remote class a part of server package.
Thanks.


My server is quite simple... it is a main class that parses command line options (db file, port number), creates a Data object for all remote objects to use, binds my RMI factory to the registry and that is it.
All that the factory does is creates new RemoteData objects, each referncing the Data that the server created, for each client that wants a remote connection. Then, since each client has a unique RemoteData object, locking via an id is simple because you can just use the RemoteData object as the id.
 
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
<quote> All that the factory does is creates new RemoteData objects, each referncing the Data that the server created, for each client that wants a remote connection. </quote>
Nate, how do you create a new instance of RemoteData object for each getConnection method when your RemoteData is extending UnicastRemoteObject... from what i know is UnicastRemoteObject does not allow replication of Object...
 
Kruger Scheitz
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
<html>
<body>
<bold> All that the factory does is creates new RemoteData objects, each referncing the Data that the server created, for each client that wants a remote connection. </bold>
</body>
</html>
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Because the Remote object is not bound to the registry.
Also this board doesn't use HTML in posts, and for quoting it uses the brackets []
or you can click on the buttons below to put them in for you.
Mark
 
reply
    Bookmark Topic Watch Topic
  • New Topic