About Facade design pattern

[Ying Ren]

Hi,
I used the factory class for returning the DataInterface which has two implementation class (local and remote). In my table model and the methods using data, I just import the DataInterface, so the client will not care local or remote. Why we need the facade pattern? I can not understand that.
Another question about RMI, I just writing the standard codes according the tutorial, do we need consider other stuffs?
for example, security, multithreading...
I am really new to those.
Thanks
Ying Ren

[Sai Prasad]

In the Facade class you can hide the details in booking the flights. The GUI (class extends JFrame), doesn't have to know the data structures used while communicating with the RMI server or the steps required to satisfy a business requirement.
I guess you are referring to the Sun RMI Tutorial. You need not worry about installing RMI Security Manager but you need to take care of multiple clients trying to book seats in the same flight to avoid data corruption. I think a scenario is mentioned in the Sun requirements document.

[Ying Ren]

Sai,
Thank you for your reply.
In my program, the GUI will not care about the data. All the data will be used in Controller. I am thinking put the book flight in my implementation classes. So, do i need the facade?
About RMI, how to avoid the data corruption? I suppose the lock and unlock can provide the function. Could you give me more information about that?
Thanks
YING REN

[Sai Prasad]

If you follow Controller pattern then you don't need a Facade.
RMI runtime environment is responsible to create threads for every request from the client. All you have to do is allow one only one thread to manipulate the database at any given time on a given record to avoid overbooking a flight.

[Ying Ren]

Now I can be sure I will not use the facade.
About the RMI, I understand what you mean, but how to start. I still feel lost somewhere.
ying Ren

[Sai Prasad]

This is one of the challenging areas in the certification. I suggest you think about the following make some design decisions. We will help you on the way!
1)You need to think about giving access to lock/unlock and also blocking threads which are trying to lock/unlock the same records. I suggest you use a LockManager to manage the access. What I mean by access is that only clients who locked the records are allowed to unlock the record. For example, LockManager will not allow to unlock a record 10 by client 2 which was locked by client 1.
2) Now to take care of the blocking, you can either do it in the LockManager or in the appropriate methods in Data. You make the decision. I had it in the Data class but I know people have implemented in the LockManager and scored good marks.
Once you make the architecural decision, then you concentrate on implementing the blocking first. Then you move on to restricting the access.

[Ying Ren]

Sai,
Thanks. Now I understand. I will follow your instruction.
Thanks again.
YING REN