Dear all, According to the instruction, for the data client :
This implementation should include a class that implements the same public methods as the suncertify.db.Data class
I wonder whether i am asking to implement a generic database server and all business logic is implemented in client side. Personally, I prefer to implement the business logic in server side and export remote interfaces for the client's operation. However, I am not sure whether I am allowed to do so. Please help. Thank you.
Therefore, the server just extends the suncertify.db.Data with remote access capability and the exported method's signatures should be the same as the suncertify.db.Data class's public method. Am I right ? I am really confusing that why i cannot implement the business logic ( the flight booking logic ) in server side. Sorry if i am asking stupid question.
What you will do is then wrap the interface into a Facade, in the Facade you can methods like BookFlight() the business logic. This class in my submission was part of the server package. This way the Facade accept a class that implement the interface, meaing both Local and Remote implementations of the interface. Since the Facade doesn't care which mode you are in. Mark
Originally posted by Wilson Liu: I am really confusing that why i cannot implement the business logic ( the flight booking logic ) in server side.
Ha! Any excuse to whip out my generic 3-tier architecture template[tm] will do. GUI <==> business logic <==> database There are three layers, with two interfaces to separate them. The most natural way to implement your application is to make the RMI interface correspond to one of the two interfaces above. So there are two possible choices. The requirement that you must have a client-side class that implements the public methods from Data means that Sun forces you into one specific choice. They force you to make the business <==> database interface your RMI interface. Because if you'd make it the GUI <==> business interface, i.e. implement your business logic on the server, then having a Data-like object in the client would be useless and in fact simply bad object design. This choice they force you into is also implied in the requirement that your code needs to be as reusable as possible. After all, Data is fully generic and reusable. A well-written database server will also be fully generic and reusable. However, if you'd implement the business logic on the server, your server tier would suddenly be application specific and non-reusable (unless you reinvent EJBs). So from a reusability point of view, the first choice makes much more sense. - Peter
posted 17 years ago
Therefore, I need to implement a generic database server. Thanks Peter and Mark. The resaon for making the server application specific is that it can prevent wrongly-written client from messing the data. my 2 cents.
My favorite is a chocolate cupcake with white frosting and tiny ad sprinkles.