FBN - Design choices

[Meena Pitchiah]

Hi,
I am working on Fly By Night.
At the server side, I am using Adapter pattern to handle Local and network mode
1. I have a top level interface called DataInterface. Changed the Data class (which come with the Assignment) to implement the DataInterface. I have the RemoteInterface which extends Remote and DataInterface. My remote implementation implements RemoteInterface and is the Adapter class. In order to acheive this, I have to change all the public methods in Data to throw IOException. Otherwise, compilation of RemoteData fails. Is it OK to make changes like this to the Data class (for the exam). Is there any other way to overcome this problem?
2. My server is very simeple, creates rmi registry, only one instance of RemoteData and binds it to the registry. At any point of time there will be one instance of RemoteData. Initially I was thinking of using singleton pattern for Data class. I am not sure whether I still need to make Data a singleton.
3. In the ranch I have seen many postings on using ConnectionFactory and creating a new instance of RemoteData for each client. Which is different from my design (item 2). Why do we have to do it this way. Trying to find out, whether I am missing any thing if I do it as per item 2.
I very much appreciate your comments.

Thanks
Meena

[Andrew Monkhouse]

Hi Meena

I have to change all the public methods in Data to throw IOException. <snip> Is it OK to make changes like this to the Data class (for the exam).

The problem with this is that you do not know if any other applications exist which also use the Data class. Because of your change, these other programs will also need to be changed - this is considered bad programming practice. This is more a problem in real life than it is for the assignment, but it could apply for the assignment as well if, for example, the examiner had a prebuilt tool to delete records to make sure your application can handle deleted records.

Is there any other way to overcome this problem?

You could extend the Data class, which gives you far more freedom with changes like that. Or you could create a wrapper class for networking (I did this, and this was discussed in this thread).

At any point of time there will be one instance of RemoteData. Initially I was thinking of using singleton pattern for Data class. I am not sure whether I still need to make Data a singleton.

Since there is only ever one instance of the Data class, then you should not need to make it a singleton. Singleton's, and their overuse, was discussed in this thread

3. In the ranch I have seen many postings on using ConnectionFactory and creating a new instance of RemoteData for each client. Which is different from my design (item 2). Why do we have to do it this way. Trying to find out, whether I am missing any thing if I do it as per item 2.

You don't have to use a ConnectionFactory. It is just one of several solutions that many here on the Ranch like, and have used.
My instructions stated: If an attempt is made to unlock a record that has not been locked by this connection, then no action is be taken.
There are several ways to meet that criteria. Having a separate RemoteData for each connected client can assist in meeting it, and can also provide benefits in cleaning up locks if the client dies (which is not a requirement, but many here have considered it an unwritten requirement).
Have you met that criteria? And have you tested it? If so, then you should not need to worry about the ConnectionFactory solution.
Regards, Andrew

[S. Ganapathy]

Hi Meena,
I dont know the requirements of FBN assignemnt, but I am giving my comments in general scence.
When ever, we do read/ write from file IO, first we should think about Singleton, and this is not a hard and fast rule. But in logginf frame work, the class responsible for read/write is mostly singleton. And there is a writer demon(thread), which pushes logging requests in the queue.
In our case, we need not provide demon threads, and we should handle in Data class directly.
Are you sure to expose the interface (DataInterface) to client directly? This is the interface to use while read/write operations in file IO.
In my case, I implemented the interface in Data class, and created another interface, DBClient to the customized solution(to client requirements), and implemented in DBClientImpl. I am implementing DBClientRemote in RMI class, but using DBClientImpl inside RMI class, which, I am wrappering the RMI class, also called Adapter design pattern. All methods of DBClient throw a generic DBException, a super class of all custom written exceptions which are thrown in Data class.
I really dont know whether it is a good idea, or not.
What is your comments on my design Andreww, Max?
Regards,
Ganapathy.

[Meena Pitchiah]

Andrew,
Thank you for your comments.
I am planning to generate unique ID for each client and use it for locking and unlocking the records. I hope that will satisfy the requirement you mentioned. I have to test it.

I have one more question in the case of ConnectionFactory:
If each client gets an instance of RemoteData, which is a wrapper to Data, I think the adaptee (Data class) should be a singleton or pass the same instance of Data to the RemoteData constuctor. Can you please comment on this.
Thanks,
Meena

[Andrew Monkhouse]

Hi Ganapathy
As I understand your solution, DBClient provides methods suitable to the business requirements.
DBClientImpl implements DBClient.
What about DBClientRemote? Does it implement DBClient as well? Or extend DBClientImpl? Or does it just "have a" DBClientImpl.
Regardless, the overall idea is reasonably sound. The worst thing I can say about it is that you are not providing remote access to a generic database, you are providing remote access to a Contractor's database. If someone later wanted to use the same Data class to access a datafile containing Customer information, you Data class might work (I don't know), but the remote access would definately have to be built from scratch. Does this concern you?
Regards, Andrew

[Andrew Monkhouse]

Hi Meena

If each client gets an instance of RemoteData, which is a wrapper to Data, I think the adaptee (Data class) should be a singleton or pass the same instance of Data to the RemoteData constuctor. Can you please comment on this.

I think you should only have one instance of the Data class. Whether you choose to make it a singleton, or whether you choose to pass the same instance of Data to each instance of RemoteData is up to you. Ganapthy made some reasonable comments in favour of a singleton, and there are comments in the link I mentioned above where Vikas was also wondering about making his classes singletons or just have single instances of them. My argument against a singleton is that there is nothing tying the Data class to the FBNS assignment - you could use it with any database that follows the same formats. But if you make Data a singleton, you could not have two databases running simultaneously in the one VM. But if you make sure the RemoteData only ever get's the instance of Data that you want it to have, you could have two different databases being served. Does this make sense?
Regards, Andrew

[S. Ganapathy]

Hi Andrew,

What about DBClientRemote? Does it implement DBClient as well? Or extend DBClientImpl? Or does it just "have a" DBClientImpl.

DBClientRemote extends UnicastRemoteObject implements RemoteClient
RemoteClient extends DBClient, Remote
DBClientRemote is a wrapper to DBClientImpl.
Generic database is Data.java, which implements the interface provided by SUN (DBAccess).
I am using an adapter to Data. I am shielding the original database, with the DBClient interface.
In future, if the database is a RDBMS, only Data.java will differ, not the entire client provided the DBAccess remains same.
As long as the schema of the db file does not change, this implementation will surely work.
So the solution is specific to this database schema.
Please provide your comments.
Regards,
Ganapathy.

[Andrew Monkhouse]

Hi Ganapathy
OK, I understand your design, and my earlier comments stand: this sounds like a reasonable aproach.
My question (and it is mainly just for curiosity) is what sort of methods do you have in DBClient?
The way you wrote your reply to Meena, I suspect it has methods like "updateContractor" or other business methods, rather than the generic "update" method used in Data class.
Regards, Andrew

[S. Ganapathy]

Hi Andrew,
Your expectation is absolutely right. DBClient has updateContractor, and bookContractor like methods, which actually project business requirements, send and receive objects (Contractor data). Actually I am following "Design to interface" to little extent. I am using interfaces where ever applicable.
(This is what I reflected in giving reply to "Meena", but I think Meena has not noticed it.)
Further comments are welcome.
Regards,
Ganapathy.
[ June 15, 2003: Message edited by: S. Ganapathy ]

[Andrew Monkhouse]

Hi Ganapathy
I dont think Meena missed your suggestion, it just doesnt apply to the FBNS assignment. The FBNS assignment has the requirement:

To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class

To meet this requirement, it is easier to have the methods from the Data class directly visible to the client (via RMI / or direct connection). It would be possible to implement business methods which would be available via RMI as well, but why do the extra work?
I think you missunderstood my comment about multiple databases. This is not really a problem, since this concept is out of scope for the assignment. I will try to explain it another way though, just to give you something to think about (don't want you getting bored )
It is possible to write Data.java in a very generic manner. All the methods in it are generic for a databse (create, read, update, delete, ...). And the flat file itself contains it's own schema. So you could create a Data class that works with any flat file database that meets the published format.
So I could have the following flat files, and use the same Data class for all of them:

db.db - the contractors database

customer.db - a database of customers

jobs.db - a list of jobs assigned to contractors for customers

If you expose the methods of the Data class to the remote clients, then anytime anyone wants to have remote access to another database, you could just modify your server program to bind with a different name, and use a differently named database. You could even go a step further and use the name of the database as the name you register with the RMI Registry. If you allow the database name to be entered at the command line, then multiple databases can be served using the one serer application without any recoding.
Using your server design though, each new database would require additional coding to create business methods that can be exposed via RMI. Even a change to the current business requirements for the Contractors database might require a change to the server code.
Regards, Andrew

[S. Ganapathy]

Hi Andrew,
Thanks for your express response. I got what you mean multiple databases.
My solution is not very generic to different databases. This is only to specific database.
Also I really dont know the requirements of FBN assignment.
Hope you got my problem.
Regards,
Ganapathy.