This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: How to add RemoteException capability to DB interface? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S: How to add RemoteException capability to DB interface?" Watch "B&S: How to add RemoteException capability to DB interface?" New topic
Author

B&S: How to add RemoteException capability to DB interface?

Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Dear all,

please view the design below.



This is the design I have so far to provide a mechanism to handle local and remote calls in the network layer

RemoteDB is a copy of the DB interface provided by Sun and extends Java's Remote interface (not shown here) and add throws RemoteException to each method.

RemoteData should act as an Adapter between network and local mode. It has a reference to Data and wraps each peer Data method in a throws RemoteException to implement the RemoteDB interface.

What disturbs me is the fact that I had to change RemoteDB and RemoteData whenever Data becomes changed.

So, what do you think of applying the Adapter Design Pattern to my network layer ?


SCJP, SCJD, SCWCD, SCBCD
Frank Hardy
Greenhorn

Joined: Aug 17, 2004
Posts: 13
Hi Darya,

I have a different assignment (URLyBird), but the situation for me is the same.
My approach to that problem is nearly the same (glad to see that others have the same ideas ) but I used to add another adapter (DB2RemoteDB) which adapts from DB to RemoteDB because I think the requirement is that the client-app has to use always the DB-interface (as given in the requirement spec). And as I can see, your current solution implies that the client-app has to use the RemoteDB-interface when it wants to talk to a remote server.
On the client side you need to have some kind of factory that creates a connection to a remote database or a local database.
Behind the scenes - in the case of a remote connection - the factory has to get a RemoteDB instance via RMI (maybe from a factory or directly from the Registry) and wrap it with the DB2RemoteDB adapter, which than will be returned.
So the client-app talks always to a DB-interface instance.

Using the adapter-pattern implies that when the DB-interface changes, the RemoteDB-interface has to be corrected to match the new DB-interface and the two adapters have to be corrected too. This involves 4 classes and because the adapters only delegate their calls it is not much overhead.

Do you(all) agree?

Greetz,

Franky.


SCJP 1.4
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Frank,

I don't understand your DB2RemoteDB. Is it an interface? How does it fit into the Adapter Pattern in terms of Target interface, Adapter class and Adaptee class?

Regards,
Darya
[ April 03, 2005: Message edited by: Darya Akbari ]
Frank Hardy
Greenhorn

Joined: Aug 17, 2004
Posts: 13
Hi Darya,

ok, maybe I'm wrong.
You made a copy of DB and called it RemoteDB. RemoteDB has no relation to DB and hence it is not a DB.
The implementation of RemoteDB is RemoteData. Hence a RemoteData is a RemoteDB but no DB. But in my opinion the client-app should use always the DB interface.
For example: if you put an instance of RemoteData into the RMI-registry and you get it at the client-site, it is still a RemoteDB and no DB instance.

That's my opinion (and planned solution):
I think you need a second adapter class (used on the client-site) which I called here DB2RemoteDB. It adapts an instance of RemoteDB (your remote object RemoteData is such an instance). This adapter is an implementation of DB (like Data) and forwards (delegates) every call to the adapted (RemoteDB) instance.

During runntime - at the client-site - you wrap your remote RemoteData instance that you retrieved from the registry with an instance of the DB2RemoteDB adapter. And the client-app uses this adapter instance to make the calls to the database system. So, the client uses a DB instance and doesn't have to talk to a different interface in remote mode.

I hope my explanation was a little bit more clearly.

Greetz,

Franky.
Olena Golub
Ranch Hand

Joined: Jan 17, 2005
Posts: 113
Hi Darya,

you can find the answer for you question in this great topic "RMI implementation"

It can be used like RMI implementation tutorial!
Olena
[ April 03, 2005: Message edited by: Olena Golub ]

SCJP 1.4<br />SCJD 1.4 (in progress)
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi,

I wouldn't have a problem to let the client handle RemoteDB AND DB objects. However maybe Sun would have a problem with it . Frank, maybe your approach is more what Sun expects.

I really like to know how other see it? Are we ought to let the client act only through the DB interface :roll: ?

Olena, thanks for the link

Regards,
Darya
Frank Hardy
Greenhorn

Joined: Aug 17, 2004
Posts: 13
Hi Darya,

I'm sorry. It wasn't my intent to affront you, but you wanted an explanation and I gave it to you.
My first approach was similiar to the post which has been linked by Olena. But I made a new decision and as I said before: maybe I'm wrong, maybe I'm not, maybe our requirements are different ... we'll see

Are we ought to let the client act only through the DB interface?


For sure NOT - I know that, and the others definitely too :roll: - but the topic of this post was about the database, its interface and its remtote-ability, not about further abstraction by creating a business interface which then is used by the client-app. Ok, I have to admit that my previous post could be misunderstood. My fault.

And, btw, I'm sure you can handle the problem. I'd never thought anything else.

Best regards,

Franky.
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Frank,

no problem at all . I'm like you trying to find a way out of this jungle .

Regards,
Darya
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Dear all,

How about this extension to my previous model? Please view below:



In my extension I make use of the Factory Pattern. My goal is to keep the client layer (gui) free of handling different connection types (local and remote). The only handle will be a Connection object.

In terms of the Factory Pattern, the abstract Creator class Connector provide the abstract method createConnection. This method must be implemented by the concrete Creator classes LocalConnector and RemoteConnector.

Further in terms of the Factory Pattern, the Product interface Connection provides the interface for the concrete Product classes LocalConnection and RemoteConnection. LocalConnection refers to Data, RemoteConnection refers to RemoteData.

So the client layer will only see Connector and Connection objects.

What do you think of this approach ?

Regards,
Darya
 
Consider Paul's rocket mass heater.
 
subject: B&S: How to add RemoteException capability to DB interface?