Win a copy of JDBC Workbook this week in the JDBC and Relational Databases forum
or A Day in Code in the A Day in Code forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger

provide alle the public methods

Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a couple of questions, the first has briefly been touched in some other thread, but I think it was not really answered:
1) The assignment says that:
The remote client code that you write must provide all the public methods of the suncertify.db.Data class.
- Why is it that Sun would want us to implement all the public methods in out database client? I have wrapped the low level methods e.g. lock(...), modify(...) into methods like bookSeats(Object flight, int seats) so that the GUI-client would not worry about the tiny things. And I presume that's the way it should be done in a reallife system, or would you really expose methods like lock(...) to the users (in this case the GUI) of DBClient ?
2) To implement the RMI part of the assignment, I've just modified class Data so that it extends UnicastRemoteObject and added a method called registerWithRMI() that is called from the BootStrapServer. (If the client is started in local mode this method is ofcourse never called). After looking around in here a bit, I get the feeling that it is a bad design, and that I instead should extend Data -> RemoteData. But im really not sure what the benefits are - and actually I don't find it more attractive designwise?!
Posts: 17346
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well I didn't extend the Data class at all. But I do have an interface called DataAccess that has all the public methods of the DataClass, and I have two classes that implement the DataAccess interface. One for remote and one for local.
This is how the public methods are exposed to the client. It is still ok to have a class that acts as a Facade to these classes, as a means to make the GUI call a few methods like bookFlight.
I would not extend UnicastObject in the Data class, or add that method, you need to come up with another "Wrapper type class to load into the registry, preferably a ConnectionFactory, that passes connections back to the client, that have references to the Data class. etc...

Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are no problems making such a change to Data. You can make just about any change to Data provided that you can provide a good justification to do so. And arguing that, if there is another class implementing the same methods as Data, then they should both implement the same interface through which the client will access them, is an excellent justification for such a minor change.
It might well be that Sun has a test harness they run against your Data implementation, and that they basically don't want to rewrite their harness for every submission. Implementing an interface will not affect their ability to run the harness. Mind you, this is some speculation on my part - I do not know. What I do know is that you can introduce that interface and pass with a perfect score.
- Peter
Grow a forest with seedballs and this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
    Bookmark Topic Watch Topic
  • New Topic