Local/Remote implemetation Advice PLEASE !

[Ricardo Polero]

Hi,
I applied a adapter adapter in server, but I have no idea the way that I can make transparent the access to remote / local since in client size I used the remote server interface to call server methods ? and in the same situation in local mode I'll use a Data instance.
Please someone can give an idea that how can i make the access transparent in client to local or remote ?
I don't want to change almost anything because is working fine in remote mode !
Some advice ?
PLEASE

[Paul Anilprem]

You should not directly use the Data class instance in local mode.
This is what I suggest:
1. Have an abstract class, say, DBAdapter that has all the methods (but abstract) of Data class.
2. For Remote case, extend this class, say RMIDBAdapter, and of course, you'll need to have to define a Remote interface etc. basically the whole 9 yards needed for RMI.
3. For local mode, have LocalDBAdapter. This class will internally use Data class instance and will delegate all the calls to it.
Using this architecture, your client side component will make a call DBAdapterFactory.getDBAdapeter(...params that decide whether you need a local or remote adapter...) which will return DBAdapter reference which will point to Local or RMI impl. But the client need not worry about it.
HTH,
Paul.
------------------
SCJP2, SCWCD Resources, Free Question A Day, Mock Exam Results and More!
www.jdiscuss.com
Get Certified, Guaranteed!
JQPlus - For SCJP2
JWebPlus - For SCWCD
JDevPlus - For SCJD

[Peter den Haan]

Originally posted by Paul Anil:
1. Have an abstract class, say, DBAdapter that has all the methods (but abstract) of Data class.

I assume you meant "interface".

2. For Remote case, extend this class, say RMIDBAdapter, and of course, you'll need to have to define a Remote interface etc. basically the whole 9 yards needed for RMI.
3. For local mode, have LocalDBAdapter. This class will internally use Data class instance and will delegate all the calls to it.

Using an interface, you can dispense with adapters altogether - both Data and the stub for your remote database would implement your interface.
- Peter

[Ricardo Polero]

Thanks SO much guys !!!

[Paul Anilprem]

>I assume you meant "interface".
No, I meant Abstract class. The reason of choosing Abstract class instead of interface is as follows:
1. Instead of letting the client code use loose methods read, lock, read, modify, unlock directly, you can provide a method bookTicket(...) that can be directly used by the client. This method will internally call the read/modfy/etc. method.
This is a business functionality that you can reuse using an abstract class by implementing "non-abstract" method in the Abstract base class.
You can similary provide other business functionality like findByAirline() etc. in the Abstract base class.
This way you do not have to code it again and again in different implementations of the interface.
2. If you use an interface, then what will be the throws clause for it's methods? If you keep RemoteException, your client components will have to catch RemoteException thereby making them aware that RMI is being used. If you want to do the remoting using SOAP or CORBA, you'll have to change the signatures again. Better would be to keep DatabaseException in the throws clause. Your Data class can be used locally and other remote implementations can catch their RemoteException (SOAPException, CORBAException or whatever), extract the message and throw a DatabaseException. The same mechanism will be used in the Abstract class approach.
HTH,
Paul.
------------------
SCJP2, SCWCD Resources, Free Question A Day, Mock Exam Results and More!
www.jdiscuss.com
Get Certified, Guaranteed!
JQPlus - For SCJP2
JWebPlus - For SCWCD
JDevPlus - For SCJD

[Devu Shah]

paul,
can u pl. eloberate on how to use DatabaseException class that is provided by assignment ?
that is to say "is is more advisable to use DatabaseException class and throwing error or to do normal try catch ? in case of using DatabaseException class do we have to modify to add many more code ??? '
your coments and guideline would be appricaited .
thanks
devu

[Peter den Haan]

Originally posted by Paul Anil:
1. Instead of letting the client code use loose methods read, lock, read, modify, unlock directly, you can provide a method bookTicket(...) that can be directly used by the client.

So on one hand you would be creating an adapter with all the public methods of the Data class - presumably to satisfy Sun's requirements - which is supposed to be a completely generic class for re-use in other projects. On the other hand you would be putting FBN-specific business methods in the same class. This gives it very blurred responsibilities which is not a good idea by any standard.
A class such as this should either be generic without business methods, or FBN-specific and expose nothing but business methods.

2. If you use an interface, then what will be the throws clause for it's methods? If you keep RemoteException, your client components will have to catch RemoteException thereby making them aware that RMI is being used.

Exactly, these methods would throw RemoteException, making the client aware that a remote database may be used - which is exactly the case. The communication protocol may be RMI, RMI/IIOP, or raw sockets or SOAP unless you're squeamish about subclassing RemoteException. I'd like to point out that (a) a RemoteException can be wrapped around an underlying exception (much better than merely extracting the message and turning it into a DatabaseException) and (b) RemoteException is not only used in java.rmi, e.g. javax.transaction.TransactionRequiredException.
But this point is rather less clear-cut than the first one. You could well argue that there should be a DatabaseException subclass that would implement a proper exception wrapping, and adapters that throw this exception (not DatabaseException itself) for remote communication errors. Although throwing RemoteException certainly doesn't prevent you from using a SOAP implementation later on, if you anticipate using SOAP in the near future using wrappers might be the cleaner approach. But it appears to be way outside the scope of the assignment.
- Peter

[This message has been edited by Peter den Haan (edited September 25, 2001).]