I'm currently attempting to complete the programming assignment for URLyBird 1.1.2 and I am grappling with what is probably the most basic design question:
When the application is operating in true client-server mode (i.e. client-side GUI in one JVM makes RMI calls on a remote object in a separate JVM - aka the Server) - is it OK to implement a design where "lock" and "unlock" methods ARE NOT invoked by the client-side GUI.
In other words, I'm favoring a design where the remote interface does not resemble the suncertify.db.DB interface with RemoteException added to the method signatures. Rather, this remote interface would look like a business object (methods would have names like "bookReservation", "queryAllReservations", "queryReservationByHotelName", etc.).
I believe this design is also called "Thin-Client". Although this design requires changes in two abstraction layers (business object and client) when another business operation (such as deleting a reservation) is added later, I think I can justify the design because it insulates the client-side GUI from the data access implementation.
Has anybody passed URLyBird 1.1.2 using server-side locking/thin-client design without losing a lot of points in the locking section?
By the way, in URLyBird 1.1.2 the lock and unlock signatures look like:
I tried to get an answer from this thread before posting this question:
I don't see why not. I may not have pass it yet, but I think reading some of the other post of those who did (including the recent one from Kasper with 400/400), it sounds like that's what he did.
From a design point of view, you really don't want to expose ANY of the low level DB interface to the client. In my implementation, those are completely hidden from the client. It only knows how to search and book/unbook records. That's 2 methods, and they are also abstracted and does not deal with any of the String stuff. Those are all handled on the data access side.
By hiding the lock/unlock calls, you save yourself the problem of client locking a record but fail to unlock it for whatever reason, intentional or unintentional. As well, it allows you to keep the lock for the minimal amount of time.