• 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

altering DBAccess interface

 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi - I am doing Boggit and Scrapper - quick question..the instructions say that the Data class must implement the DBAccess interface. However, the DBAccess interface does not extend ..rmi. I can use an adapter pattern...but then the Data class is not implementing DBAccess.

Pse advise.

Thanks

L
 
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can do several things.
I decided to create a parallel interface to the DB interface which does throw RemoteExceptions, then have a parallel remote Data class implementing that.

To make it so that the client will still only see a DB you're then also going to have to create a proxy for that RemoteData which extends DB rather than RemoteDB.

So you'd get something like:
package suncertify.db:
- DB
- Data implements DB

package suncertify.db.net:
- RemoteDB
- RemoteData implements RemoteDB
- DataProxy implements DB

where the proxy is the thing your client application is calling methods on, with the proxy being responsible for forwarding those calls to the network enabled RemoteData instance you got back when opening the RMI connection.

Not ideal I admit. In an ideal world you'd have a single superinterface for both DB and RemoteDB but such is life.
 
Lucy Sommerman
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi - thanks for yr help. However, can I ask for some clarification.


CURRENT SITUATION:

interface DBAccess (extends java.rmi.Remote, but this needs to be changed, as not allowed to alter this interface)

class Data (implements DBAccess, extends java.rmi.server.UnicastRemoteObject)

//server
DBAcess dba = new DBAccess();
Data r = (Data)dba;
r.loadData();
//create and bind registry
LocateRegistry.createRegistry(port);
Registry registry = LocateRegistry.getRegistry(port);
registry.rebind("Data", r);

//client
Data d = (Data)Naming.lookup("Data");
System.out.println("Running as client");
Gui g = new Gui (d);
g.createAndShowGui(d);

The Gui constructor parameter is of type DBAccess.

FUTURE SITUATION:

I can remove all rmi from the DBAccess interface and Data class and create a new package suncertify.db.net to include the following:

RemoteDB - extends java.rmi.remote
RemoteData - implements RemoteDB, extends java.rmi.server.UnicastRemoteObject

But is that not (unnecessary) duplication of code?

I'm not quite sure about this proxy...

"the proxy is the thing your client application is calling methods on, with the proxy being responsible for forwarding those calls to the network enabled RemoteData instance you got back when opening the RMI connection."

I can have a DataProxy class that implements DB but not sure what should go in there...Or maybe I am confused about what should go in the RemoteData class..

Can you pse provide a little more info...

Thanks

L
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The proxy is needed to allow the client to not have to know about IOExceptions when doing calls on a DB (and to allow the client to not have to know whether it's calling on a DB or RemoteDB).

It takes any IOExceptions (and thus RemoteExceptions) generated by the RemoteData and transforms them into a RuntimeException (which aren't declared in the throws clause), so it can implement DB instead of RemoteDB while doing network calls through a contained RemoteData.

And yes, there is some duplication of code. Because of the requirement that the DB interface can't be modified that's unavoidable if you want to present a uniform view of the data to the client irrespective of how that data is retrieved.
Were you to be able to change the DB interface you could build a master interface which throws IOExceptions and inherit both DB and RemoteDB from that to respectively remove that IOException from the throws clause and change that IOException to a RemoteException.
That's the pretty solution, and one you would likely choose if you didn't get that DB interface supplied to you, but that option isn't open so you have to resort to a less pretty solution that gets the job done.
 
Lucy Sommerman
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK thanks. L
 
reply
    Bookmark Topic Watch Topic
  • New Topic