NX: (Contractors) Interfaces and design question

[Jeff Wisard]

Hello all,
I am interested in how any of you have faced the following problem that deals with the networked vs non-networked interfaces of the problem:
For the GUI portion of the problem, I would like to separate the 'database' or 'model' portion of the application away from the presentation by supplying a factory that will return a common interface that GUI classes can use to access the database. The common interface should be useable in networked or non-networked mode. In this way, the presentation part of the GUI will not know or care whether or not the network is being used.
Therefore, there should be two implementations of the common interface...one for networked (in my case RMI) mode and one for non-networked mode. The instructions provide the DBAccess interface...and I would like to use that for the common interface described above. However, if I use RMI, then each method of the interface must throw a RemoteException. This would mean that I would need to add RemoteException to the DBAccess methods...which Sun says we cannot do.
So I was thinking that with the RMI implementation I would create a RemoteData interface that specifies all of the same methods of DBAccess but does not extend that interface. Then, on the client side, decorate this class with a class that does implement DBAccess and return this from the factory if the client is in networked mode.
However, this design may leave some disparity between the decorated interface and DBAccess. Has anyone else done anything similar?
Thanks!

[Ta Ri Ki Sun]

Has anyone else done anything similar?

I've been scratching my head once in a while for 2 days about something very very similar, my system is up and running for a while now, but I dont like a few things, one of them is that the remote class implementing said interface does nothing different to the local class except throw different exceptions, and that to me doesn't seem natural, I certainly wouldn't want to maintain 2 different classes everytime I want to change one method.
I've given it some rest cos I've got some other things to distract me for a while(bah work), but once I think of something I'll post, I hope you'll do the same , I'm sure we can benefit from a discussion around our solutions

[Barry Gaunt]

Checkout if you really, really need RemoteException. It is derived from a more much more common exception type. And that type can therefore be used in an interface suitable for both local and remote use. I believe the API was changed to enable of such generic interfaces.
If you hve the O'Reilly RMI book, there is lots of very useful info to be found.

[Ta Ri Ki Sun]

Originally posted by Barry Gaunt:
Checkout if you really, really need RemoteException. It is derived from a more much more common exception type. And that type can therefore be used in an interface suitable for both local and remote use. I believe the API was changed to enable of such generic interfaces.
If you hve the O'Reilly RMI book, there is lots of very useful info to be found.

I think the way I worded my previous post was misleading, anyway, I have managed to solve my problem, it had nothing to do with RemoteException, that was just a by product of poor design, what I've done to solve it is

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

so I now have DataFacade, well I had it to begin with but I duplicated the code in 2 different implementations, anyway this is what my connection factory will supply irrespective of connection type.
I then have DataFacadeImpl which provides the implementation details and hides the low level db work from clients, this is what will be returned for local connection, for remote connection I have RemoteDataFacade extending Remote and DataFacade, and RemoteDataAdapter extending UnicastRemoteObject and implementing RemoteDataFacade, the adapter takes the DataFacade interface as a parameter, this will of course be the implementation provided by DataFacadeImpl only it doesn't know or care, from there on the adapter merely delegates its tasks to the DataFacade object it was given.
please , criticise at will because to me that section of my code looks good enough to submit, of course I could be wrong.
whether its right so far or not many thanks to the person who initially posted the link to the adapter pattern on javaworld, that was useful combined with this site Design Patterns amongst others
[ April 24, 2003: Message edited by: Ta Ri Ki Sun ]

[shan chen]

Originally posted by Ta Ri Ki Sun
for remote connection I have RemoteDataFacade extending Remote and DataFacade, and RemoteDataAdapter extending UnicastRemoteObject and implementing RemoteDataFacade,

Is DataFacade the same as DBMain from SUN? Could you give an example of a method signature in DataFacade?
Assume there is a method find() in DataFacade. It should throws IOException in order to allow the same method in RemoteDataAdapter to throw RemoteException. Otherwise RemoteDataAdapter will not comply. But the origianl interface DBMain does not have IOException.

[S. Ganapathy]

Hi All,
Common guys. Better discuss about some design patterns related to the SCJD assignment. Hope it will be a better way to approach the completion of project, and at the same time highlight the issues.
DBMain/DBAccess is the given interface to the database (db.db) by the SUN. This is at the backend. But what about the interface we do provide for the client??? Have anybody ever thought about it? If your assignment says that you have to provide the functionality of displaying all available records(seats/hotel rooms/contractors), and book the record (seat/hotel/contractor). Surely, there is no delete functionality at the client side. Also locking functionality is not to be shown at that client side. That means, we should design a new interface for that purpose.
Then providing functionality for RMI/Standalone blah blah may be easy. It is not good idea of exposing the database access functionality as it is.
This is what I feel.
Please discuss about this.
Ganapathy
[ May 01, 2003: Message edited by: Ganapathy S ]

[Barry Gaunt]

Better discuss about some design patterns related to the SCJD assignment. Hope it will be a better way to approach the completion of project, and at the same time highlight the issues.
What particular design patterns do you have in mind?
Also locking functionality is not to be shown at that client side.
How do you know?

[S. Ganapathy]

Hi Barry,
Surely we should not show locking functionality to client. Moreover I believe that locking functionality is needed only when there is multi threaded server. This is the case of either RMI, or sockets. So what I believe is there is do-nothing methods in Data.java
Apart from that, Data.java has to be extended to provide the locking functionality. This class is used in RMI/sockets(Adapter Pattern??).
We should create new client interface to fulfill the client functionality.
There is some ambiguity in the interface provided (I believe). If we look at the interface carefully, updateRecord()/deleteRecord(), there is one argument long lockCookie. This lockCookie is returned when that record is locked. Same lockCookie is passed while unlocking the record too. Then what is the use of lockCookie in update/delete methods?
This is where we should put our attention. And accordingly we should design the system.
This is from my view.
Ganapathy

[Andrew Monkhouse]

Hi Ganapathy,

Surely we should not show locking functionality to client.

This is one of the areas where you have to make a design decision, and document your decision for the examiner
There are people who have passed who have not put any locking code into the client - they did the locking as you suggest, on the server side when doing an update on the record.
Most comercial databases allow (require) the client to lock records before modifying them, and that is the way that I have coded my client application - it does a "lock, verify record contents, update, unlock". This way my client gets to see if the update will work before doing the update, rather than getting an exception back from the server.
If your client application is going to verify record contents before doing an update then you need the lock and unlock methods. And if you are using RMI to achieve this, then the lock, unlock, and any data modification routines need some way to uniquely identify the client, hence the cookie.
Regards, Andrew

[S. Ganapathy]

Thankyou verymuch Andrew for your express response.
I expressed my way on lock/unlock functionality.

try {
    long lockCookie = lockRecord(recordNo);
    updateRecord(...)/deleteRecord(...);
    unlock(lockCookie);
} catch (SomeCustomException ex) {
    ...
}

The above functionality I wish to call in the RMI.
You will be the better judge for your implementation.
In new assignment, they changed the interface a bit. So is the confusion where to implement lock/unlock functionality.
I wish to know more on this front from you Andrew.
Ganapathy
[ May 02, 2003: Message edited by: Ganapathy S ]
[ May 02, 2003: Message edited by: Ganapathy S ]

[Ta Ri Ki Sun]

Originally posted by shan chen:

Is DataFacade the same as DBMain from SUN? Could you give an example of a method signature in DataFacade?
Assume there is a method find() in DataFacade. It should throws IOException in order to allow the same method in RemoteDataAdapter to throw RemoteException. Otherwise RemoteDataAdapter will not comply. But the origianl interface DBMain does not have IOException.

no Shan, DBMain is implemented by Data which does all the dog work, and DataFacade has methods like Map findRooms(String[] criteria) throws Exception; , void bookRoom(int recNo, String owner) throws Exception; , these methods use several Data methods to get the job done, this is primarily implemented by DataFacadeImpl, and this in turn allows RemoteDataAdapter to call the standard (local mode)DataFacade implementation as well as provide locking/unlocking in network mode.
RemoteDataAdapter can execute any method throwing any exception at all, it simply catches and chains them, so it catches an Exception, and this exception is a RecordNotFoundException or DatabaseException, whatever you prefer, it then throws a RemoteException , the cause of the exception can later be asked for and the correct message will be displayed to the user.
Nowhere in my instructions does it ask me to provide all DB methods to the client, and I dont believe its the clients business how a room gets booked, or how available rooms are found, what makes them available etc.

[Vitaly Zhuravlyov]

Originally posted by Ta Ri Ki Sun:


no Shan, DBMain is implemented by Data which does all the dog work, and DataFacade has methods like Map findRooms(String[] criteria) throws Exception; , void bookRoom(int recNo, String owner) throws Exception; , these methods use several Data methods to get the job done,

Hi Ta Ri Ki Sun,
Do you correctly use the word "Facade"? Facade for what? It seems to me that you do not use the Facade pattern. Correct me if I'm wrong.
Vitaly

[Ta Ri Ki Sun]

Originally posted by Vitaly Zhuravlyov:

Hi Ta Ri Ki Sun,
Do you correctly use the word "Facade"? Facade for what? It seems to me that you do not use the Facade pattern. Correct me if I'm wrong.
Vitaly

I'm glad you raised that, because until now I considered it a Facade to the DBMain interface, however if I my implementation through a checklist based on this link
Facade Design Pattern
it would meet some of the criteria but others not, specifically

* It does not prevent clients from accessing the underlying classes.

, so I guess it is a different pattern, and although it works very well I'll have to research it some more after work today and refactor those classes where needed, thanks for raising it

[Andrew Monkhouse]

Hi Ganapathy,
I think I may have misunderstood your intent. I think your last post is correct: the client side would have the code your psuedocode shows, however the implementation of those functions is on the server itself.
I thought you were suggesting to only have the updateRecord() on the client side, and have the server side implementation of that do the locking and unlocking.
Regards, Andrew

[S. Ganapathy]

Hi Andrew,
The code which I have written in my previous post is at the network server side, not at the client side. Why do we give the lock and unlock functionality to the client? I did not find any valid reason to give the lock/unlock functionality to client. Client calls only bookRoom(), bookContractor(), blah blah.
This is our own interface for which we do give for the client functionality requirement.
The interface given in the assignment must be implemented by the DB engine (Data.java in new assignemnt). But client interface should be different. This is what I feel, and understood.
There is some reason for this. We are not providing all the functionality at the client side, which ever is mentioned in the interface like deleting records, or creating new records. Just client needs only to access records which includes search functionality too, and update records.
So I feel it is better to design a new interface at the GUI client, and that is implemented in the RMI server. For network mode, and standalone mode, we do use Adapter pattern to get either standalone one or network server.
Hope you got my intention.
lock functionality is responsible for keeping the locked records in some datastructure until that record is unlocked, no matter who ever the client may be. This is just to maintain the transaction atomic. lock will check for if there is already that record is locked, if so will giveup CPU time.
Let us dig deep about this to scale the assignment in a better way. Past two days I am finding ways to do this.
I wish to know invaluable points from your side.
Regards,
Ganapathy
[ May 02, 2003: Message edited by: Ganapathy S ]

[Jeff Wisard]

Ok...so to get back to the original question. I have worked things out like this:
My Data class implements DBAccess as the instructions require. Data provides the implementation for locking using a static HashMap to store the lockCookie/recordNumber NVPs.
I have also defined two other interfaces: DataAccess and RemoteDataAccess. The DataAccess interface is what the client code will see and it hides the implementation of lockRecord and unlock. RemoteDataAccess does not extend DataAccess...however, it implements all of the same methods and adds the RemoteException to each method signature.
For networked mode, I have a class (DBAccessAdapter) that adapts the DBAccess interface to the RemoteDataAccess interface. I then have another adapter (RemoteDataAccessAdapter) that adapts the RemoteDataAccess interface to the DataAccess interface. This last class simply wraps each method of RemoteDataAccess and handles the RemoteExceptions.
So with this design, the client will only see a single interface for both networked and local modes (DataAccess).
I still don't like the fact that DataAccess and RemoteDataAccess have the same methods but are not otherwise related. I wish there was a clear way to implement a Remote interface while hiding the RemoteExceptions. I even tried having RecordNotFoundException and DuplicateKeyException extend RemoteException....but rmic will not accept that....saying that the public methods don't throw RemoteException.
If anyone has any comments about my design so far, I would appreciate it.
Thanks!
[ May 02, 2003: Message edited by: Jeff Wisard ]

[S. Ganapathy]

Hi Jeff,
Why so many adapters? One adapter is enough for the assignment. Just look at the Max book and walk through the code.
Ganapathy

[Marius Snyman]

What is this Max book. URL please.

[Alex Belisle Turcot]

Originally posted by Marius Snyman:
What is this Max book. URL please.

Hi Marius,

You should take a look at Andrew's book: http://www.amazon.com/SCJD-Exam-Second-Experts-Voice/dp/1590595165
No other book is needed in my own opinion.
Check also the SCJD FAQ

May I suggest you start a new tread for future questions and write complete sentence

Best regards,
Alex