This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Clarification on Requirement Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Clarification on Requirement" Watch "Clarification on Requirement" New topic
Author

Clarification on Requirement

Rasika Chitnis
Ranch Hand

Joined: Jun 19, 2001
Posts: 131
Does anybody have clear idea about the following, specified in the instructions ?
"The remote client code that you write must provide all the public methods of the suncertify.db.Data class."
In my opinion, the word "client" should actually be "server". I am using RMI and have provided all public methods of Data in my remote server class. Then I have a DataServices class that acts as an intermediary between GUI and Data/DBServer. I just want to clarify that above sentence does not mean that I have to provide all public methods of Data class in my DataServices class.
will appreciate a feedback on this, please.
Trevor Dunn
Ranch Hand

Joined: Jun 13, 2001
Posts: 84
Yes, I think that is exactly what it means. All public methods in the Data class must be on the client side.
Trevor
Rasika Chitnis
Ranch Hand

Joined: Jun 19, 2001
Posts: 131
thanks, Trevor.
I am still confused. I have provided public methods on remote server, that can be called from data client but I have not replicated these methods on my data client. But you are saying that they should be on client ?
Trevor Dunn
Ranch Hand

Joined: Jun 13, 2001
Posts: 84
Yea they should be replicated on the data client also. Why? well I am not really sure, but Sun asks for it so I gave it to them.
I do not know if you will lose marks or even fail for not doing it, but i decided not to take that chance and provided the public methods on client.
Trevor
Terry McKee
Ranch Hand

Joined: Sep 29, 2000
Posts: 173
I have struggled with this issue too, but have come to the following conclusion: The client classes that deals directly with the server and/or directly with the Data object (in local mode) must have the same public methods as directed. However, the word 'client' is very confusing. I consider any class over the wire (accessing the server) as a 'client class'. If you think of it this way you can have more confidence that you are following the rules. Just because your classes that access the server and data object offer access to the same public methods does not mean that the GUI and other related client classes have to offer the same methods. If this is a little confusing take a look at this:
DataServer (implements RemoteDataBehaviorIF)
|
|
RemoteDataAdapter (implements FlightIF)
|
|
FlyByNightServicer
The DataServer has all of the public methods indicated by the directions. The RemoteDataAdapter uses the DataServer through a reference to the RemoteDataBehaviorIF. The trick here is that I added the FlyByNightServicer class. This class handles all of the network actions needed by the application. -- There aren't that many: bookFlight, getFlights() - all, getFlights() - criteria, close, etc. These methods are all described in the FlightIF interface which the RemoteDataBehaviorIF implements. This makes things a lot easier!!! Taking it a step further, I have a LocalDataAdapter which also implements the FlightIF interface. This helps to seperate how certain things are done depending on whether in local mode or remote mode.
For instance, do you want to lock a record in local mode...I guess you could, but I found it doesn't really make sense. So the bookFlight in local mode doesn't lock the associated row whereas the bookFlight in remote mode does.
This is just one way of looking at it...and I have been revising my design sense I started the project. Nevertheless, I have everything mapped out pretty well now. I haven't felt more confident about the design than I do now.
Let me know if you want me to explain more.
Rasika Chitnis
Ranch Hand

Joined: Jun 19, 2001
Posts: 131
Thanks Terry, for detailed reply.
I think it is a waste to replicate all public methods in Data class at client side. What value that adds other than of course getting satisfaction that one has followed SUN's instructions to the 'T'.
Here is my how I have laid out my classes :
-DBInterface (all public methods of SUN supplied Data class)
-DBRemoteInterface (extends DBInterface and Remote)
-Data implements DBInterface
-DBServer implements DBRemoteInterface
-DataClient holds a reference to an object of type DBInterface; it could be an instance of Data (in local mode) or a reference
handed by RMI to DBServer (in remote mode). This class has very few methods, like you said, bookFlight, searchFilghts and getAllValuesForColumn etc.
I do not see any reason to add all public methods of DBInterface again in DataClient. That would be just repetition of code, though they can be just one liners to call the methods on the reference to DBInterface.
For example, from my bookFlight method in DataClient, I would call modify method in itself first, which in turn will invoke modify method in either Data or DBServer. This would be repeated for all methods in Data ?
I think we should develop a framework for the client to make any public method in Data class available to it either locally or remotely. Duplicating all methods of Data class into DataClient again does not make sense to me.
I thought I am almost done with everything and at last minute I am struggling to make sense of the requirements.
Trevor Dunn
Ranch Hand

Joined: Jun 13, 2001
Posts: 84
I totally agree, there is no need to provide those methods on the client side, except for following Suns Spec.
I have a question. Are you relly willing to break the spec over this. While it may not be necassary, where is the harm in providing some sort of proxy class that implements the DBInterface and redirects all calls from your service layer to either the server or local database. This way you take no risk. However the decision is yours.
It would be nice to hear from someone who did not provide the methods to see if it has any consequences. You may just have to explain in your design doc why you did not do it.
Trevor
Terry McKee
Ranch Hand

Joined: Sep 29, 2000
Posts: 173
It's not so much about following the 'requirements' to make all of the methods available on the client. It makes sense for future requirements. Think about this...let's say you are really the programmer at Fly By Night Travel agency. You finally get done with this project. Well...you think you're done until your boss tells you that you need to create an administration screen to add, modify, and delete flight information. How are you going to do it?
Scenario 1:
You have the modify method , but not the add or delete methods available on the client. So first you have to change the interface used by the client. This requires more testing even before starting with the new administration screen. This also requires a recompile of the server because of the change to the interface. Finally, you get to work on the administration screen.
Scenario 2:
You already have all of the methods needed on the client. You make the necesary screen, hookup the methods, and test the application.
I don't know about you, but scenario 2 sounds much better to me!
Rasika Chitnis
Ranch Hand

Joined: Jun 19, 2001
Posts: 131
Terry,
As I said in my earlier mail, my DataClient class holds a reference (an instance variable) of type DBInterface and DBInterface already has all public methods of Data class including, of course, methods add, delete. If, in future, as you said, administration feature is to be added, my DataClient, simply needs to call add and delete methods on DBInteface, nothing else, which has to be done, anyway, even if add and delete methods are repeated again in DataClient. According to my design, no changes are required to any interface.
To Trevor's point, I agree that it may not be worthwhile to fight this issue, but rather blindly follow what SUN says. But the point still remains that, I believe, it is not only unnecessary, it is actually a bad design.
As Trevor said, it would be nice to hear from people who already got the certification, what they think about this issue !!
Terry McKee
Ranch Hand

Joined: Sep 29, 2000
Posts: 173
I stand corrected...but nevertheless it is important to follow the directions. Just emphasize in the design decisions your objections.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
By requiring that the remote client provide all the methods of the Data class, Sun steers your design in a certain direction. If you can't make sense of that requirement, then your design probably doesn't match what they want. Not that you won't pass. But it might affect your passmark.
Note that, contrary to what the instructions suggest, you don't necessarily have to write the class that fulfils this requirement! In particular, if you create a Remote object that has all the Data methods, the rmic-generated stub file is precisely the class they're looking for.
- Peter
Trevor Dunn
Ranch Hand

Joined: Jun 13, 2001
Posts: 84
Your exactly right Peter the stub does fulfill that requirement, I never even though of that. Cool!!!.
Trevor
Rasika Chitnis
Ranch Hand

Joined: Jun 19, 2001
Posts: 131
Thanks, Peter, like Trevor said, I too never thought of rmi generated Stub file as a client side class that fulfills this particular requirement.
I am so much relieved now. Thanks a lot, everybody who contributed on this subject and special thanks to Peter.
Terry McKee
Ranch Hand

Joined: Sep 29, 2000
Posts: 173

Though I think that it is true that the stub class does implement the same public methods as the Data class...it doesn't adhere strictly to the rules.



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.



The key phrase in the above directions is that ..."although it will need different constructors to allow it to support the network configuration." Why would a stub class need to account for a different network configurations? It is used always to connect to a remote source.
chr hessenbruch
Greenhorn

Joined: Dec 05, 2001
Posts: 2
Originally posted by Rasika Chitnis:
Thanks Terry, for detailed reply.
Here is my how I have laid out my classes :
-DBInterface (all public methods of SUN supplied Data class)
-DBRemoteInterface (extends DBInterface and Remote)
-Data implements DBInterface
-DBServer implements DBRemoteInterface
-DataClient holds a reference to an object of type DBInterface;

Does all you methods in DBInterface then throw RemoteException ??
As I see it, they would have to, because DBRemoteInterface methods has to throw RemoteException to be used with RMI (rmic).
There is no problem with this, only it looks a bit odd that the local interface throws RemoteExceptions.
Is this the case? Please enlighten me.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Terry McKee:
The key phrase in the above directions is that ..."although it will need different constructors to allow it to support the network configuration." Why would a stub class need to account for a different network configurations?
As I read it, Sun does not require different constructors to support different network configurations, but (a) constructor(s) different from Data to support networked mode. And the stub no doubt has a constructor that's different from the Data one.
In any case, from personal experience I know that this approach is perfectly acceptable and won't adversely affect your score.
- Peter
[This message has been edited by Peter den Haan (edited December 07, 2001).]
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by chr hessenbruch:
[...] it looks a bit odd that the local interface throws RemoteExceptions.
That would be a bit odd. But I suspect the "local interface" you're referring to is the root database interface that may be implemented by either a local or a remote database. The fact that its methods throw RemoteException is merely an expression of the fact that it may have Remote implementations. Note that an implementation (such as Data) or sub-interface does not have to have a "throws RemoteException" in its methods!
- Peter
[This message has been edited by Peter den Haan (edited December 07, 2001).]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Clarification on Requirement
 
Similar Threads
The remote client code that you write must provide all the public methods of the sunc
Remote Client Code
Remote client and Data client
Networking : RMI
Remote Client ?