FBNS: Elegant design for client-side business classes

[Azbel Eden]

Hello, Java Ranchers!
I've finally made a decent design after reading so many valuable topics and discussions in this forum, and books. I think I finally have something I could share with you so you could comment or criticize. I'll appreciate any feedback :-)

DB
- DataInterface: Extends Remote. Interface defines all public Data methods but throws DatabaseException and RemoteException.
- Data: Implements DataInterface. Implements criteriaFind(), but not lock() and unlock().

CLIENT
- FBNServices: Interface used by the GUI, provides business services. Methods: book(), searchFlights(), etc.
- FBNServicesImpl: Implements FBNServices and its methods. Uses DataClient instance in all business methods.
- FBNServicesLocal: Extends FBNServicesImpl. Overrides constructor to get DataClient (local DataInterface).
- FBNServicesRemote: Extends FBNServicesImpl. Overrides constructor to get DataClient (via remote DataInterface) and overrides book() by calling DataClient instance methods lock()-> super.book()->unlock().
- DataClient: Class in client side that has same methods of DataInterface but throw DataClientException (Deal with RemoteException and DataException and throw DataClientException). Uses DataInterface instance (locally or remotelly instantiaded via a DataFactory).
- DataFactory: Creates DataInterface by methods getLocal() or getRemote().

REMOTE
- RemoteDataImpl: Extends UnicastRemoteObject implements DataInterface. Implements lock() and unlock(). Uses LockManager.
- LockManager: Holds HashSet of locked records. Methods: lock() and unlock().
- RegisterDataServer: Creates registry and binds RemoteDataImpl.

GUI
- ConnectionDialog: Uses FBNServices by instantiating FBNServicesLocal or FBNServicesRemote, depending on the user choice. Send instance to MainWindow.
- MainWindow: Uses FBNServices instance created in the ConnectionDialog. Inner classes BookFlight and SearchFlight (ActionListeners who play the controller in the MVC design pattern) use FBNServices instance to execute business services.

I'm deciding on using a Client ID and looking a mechanism to get an unique identified of every connection.

Thank you for spending your time reading this topic :-)
Best regards.
[ October 14, 2005: Message edited by: Azbel Eden ]

[Azbel Eden]

I would like to be more specific, exposing my main concern about my design. I have a class FBNServicesImpl in the client side which has methods such as bookFlight() and searchFlight(). I would like the bookFlight() method to behave differently depending on the connection mode. The difference is that in the remote mode the lock(), [booking logic], unlock() is used. OTOH, in the local mode only [booking logic].

What would be the more "elegant" or, just let say, the correct way to do that? How did you guys do that? I was thinking in making a subclass of FBNServicesImpl class called FBNServicesRemote and override the bookFlight() method by adding the lock(), super.bookFlight(), unlock() sequence. Another way would be just adding a condition in the FBNServicesImpl.bookFlight() method: if (it is remote mode) lock(); [booking logic]; if (it is remote mode) unlock(). Then no need to subclass.

Any thoughts? Thanks in advance.
Regards.

[Seb Mathe]

I don't have the same assignment than you, but :

Data: Implements DataInterface. Implements criteriaFind(), but not lock() and unlock().

Isn't it said in your assignement that your Data class must implements the provided interface (which, in my assignment, declares the lock & unlock methods).

I'm deciding on using a Client ID and looking a mechanism to get an unique identified of every connection.

It's an interesting question... Does your lock method return something like a cookie ?

[Seb Mathe]

What would be the more "elegant" or, just ......

I think an other solution would be to have 2 implementation of your Service interface : a local one and a remote one...

And if there a lot of redundant code between the 2 classes, you can have an abstract implementation too.

[Azbel Eden]

Hello, Seb. Thanks for replying.

Originally posted by Seb Mathe:
Isn't it said in your assignement that your Data class must implements the provided interface (which, in my assignment, declares the lock & unlock methods).

In my assignment Data class doesn't need to implement this new interface I created. In my assignment, Data class complete code was provided with lock() and unlock() methods empty. I modified it, implementing the DataInterface, correcting the deprecated code and adding the criteriaFind() method with code. When I implemented DataInterface ONLY in the remote class I coded unlock() and unlock() methods by using the LockManager instance.

Originally posted by Seb Mathe:
It's an interesting question... Does your lock method return something like a cookie ?

I've read that new assignments the use of cookies is required. In my assignment, it is not. The only requirement is "If an attempt is made to unlock a record that has not been locked by this connection, then no action is be taken". Since I call lock(),[book logic],unlock() in the client side I think it won't be necessary to track the connection, but I'm still analyzing this.

Regards,
Azbel.

[Azbel Eden]

Originally posted by Seb Mathe:

I think an other solution would be to have 2 implementation of your Service interface : a local one and a remote one...

And if there a lot of redundant code between the 2 classes, you can have an abstract implementation too.

Mmm... Interesting solution, Seb! I think it is a good idea. Plus, what about making the FBNServices class abstract, include all service implemented methods (one called book() which has only the booking logic) and include an abstract empty method called bookFlight(). In the FBNServicesRemote class that extends FBNServices, bookFlight() should be implemented and includes lock(), book(), unlock(). In the FBNServicesLocal subclass of FBNServices, the bookFlight() implementation includes only book() call.

Regards,
Azbel.

[Seb Mathe]

Concerning the Data class, take care that Sun seems to do automated tests on it -> if you leave the lock/unlock method empty, it may result an automatic failure. (Imagine they have a test wich call your Data lock method, then try to deleted the record lock previously... )

Please confirm that you have at least something like "Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:..."

If so, you'll have to deal with the client Id... (read "Data client" Id)

[Seb Mathe]

Plus, what about making the FBNServices class abstract, include all service implemented...

That's what I was thinking about... Plus : maintain the existence of an interface. (Your service consumer just needs to know the interface, no ?)

[Azbel Eden]

Originally posted by Seb Mathe:
Concerning the Data class, take care that Sun seems to do automated tests on it -> if you leave the lock/unlock method empty, it may result an automatic failure. (Imagine they have a test wich call your Data lock method, then try to deleted the record lock previously... )

Please confirm that you have at least something like "Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:..."

If so, you'll have to deal with the client Id... (read "Data client" Id)

No Seb, "Data.java" functional code is provided and I must implement lock(), unlock() and criteriaFind() methods. The requirement says "Part of your assignment will be to enhance the Data class. You may do this by modification or subclassing, but you should document the approach and reason for your choice."

My original aproach is to both modify it and subclass it. Data by itself would only be used in local mode so lock() and unlock() would not be required. The DataInterface remote implementation does implement both methods since they are required.

I think that just modify it and implement all the methods is correct, too, since lock() and lock() methods would only be used in remote mode. It just depends on the choice you make and provide the reason for it.

[Azbel Eden]

Originally posted by Seb Mathe:


That's what I was thinking about... Plus : maintain the existence of an interface. (Your service consumer just needs to know the interface, no ?)

Well, is the interface really required? I mean, I only coded something like this:

// Action listener code fragment in the local button
FBNServices fbnServices = new FBNServicesLocal();
...
 
// Action listener code fragment in the remoet button
FBNServices fbnServices = new FBNServicesRemote();

[Seb Mathe]

"Required", not... But with an interface your design will be open to future other implementations

And sorry for the Data class, FBN seems to be different than the others
[ October 14, 2005: Message edited by: Seb Mathe ]

[Andrew Monkhouse]

Hi Azbel,

The only requirement is "If an attempt is made to unlock a record that has not been locked by this connection, then no action is be taken". Since I call lock(),[book logic],unlock() in the client side I think it won't be necessary to track the connection, but I'm still analyzing this.

The thing to remember here is that it is not your code that you need to worry about. Unlike the newer assignments, FBNS specifies that you have to code with the expectation of future enhancements. It is possible that some future enhancement by some other programmer might result in code that tries to unlock a record it has not locked - and your server must guard against this.

Also my reading of the instructions is that your locking code must be in either the Data class or a subclass of the Data class. Since RemoteDataImpl does not extend Data, this might not meet the requirements - you might want to re-read your instructions and decide for yourself whether this is a problem or not.

Regards, Andrew