I dare you to read through all the code !
And I also date you to do not point me to other Threads... ooops ... sorry , topics .
After browsing through this forum I've found that arguably the most common solution for uniquely identifying a client ( RMI ) is by returning a new instance of a class ( let's say the business level class) for each client . This way when a client makes a call on any of our remote objects , those remote objects will be using a different instance of the business level class and we can uniquely identify/distinguish him because he will be passing an instance of "this" ( and "this" being a different class each time ) to one of the locking methods in the persistence layer.
I'm asking all of you guys if you see something that's bad practice or simply something that can be done much better please say so! My approach was this:
This is the remote object factory implementation. It exposes to the client the getMgmtServiceImplementation() method. All calls to this method will return a new instance of RoomMgmtServiceImpl class. The client will reuse this stub object ( remote object reference) for his whole lifetime. The RoomMgmtServiceImpl class is also a UnicastRemoteObject and consists of the business level methods.
Below is a small excerpt from this class:
Supposing the dbImplementation is obtained from a singleton ( thus unique on the whole application ) and it is able to handle the locking when it receives proper arguments to the lock(...,...) method , do you guys see this a good design? Perhaps i missinterpreted the previous topics and produced something that might not be good. And here are a couple of reasons :
1. the DBMain interface is not fully implemented , as the void lock(int recNo) and the void unlock(int recNo) remain EMPTY. They have been replaced with with the void lock(int recNo,RoomMgmtService srvc) and void unlock(int recNo,RoomMgmtService srvc) .
2. Is it a proper object oriented approach to pass the business layer class as an argument for a locking method in the persistence layer ?And more than that using the "this" pointer?
3. ??? No point no 3 ? :-)
Maybe I exagerated a bit on the details. Long story short here is the question :
If I were to use a factory that generates different instances of let's say the remote domain object on each client call, and use that domain object as a unique identifier for the client, would it be considered ok by Sun ?
Because if I were to use that object as an identifier i would have the following disadvantages :
- I will have to extend Sun's interface and add new lock methods ( which take the domain object as an argument), thus leaving the old lock methods unused.
- This would be in a sense bad OO practice, because a client should be identified by an id not a class that is instantiated when a client calls our server code.
Victor Bucutea wrote:1. the DBMain interface is not fully implemented , as the void lock(int recNo) and the void unlock(int recNo) remain EMPTY. They have been replaced with with the void lock(int recNo,RoomMgmtService srvc) and void unlock(int recNo,RoomMgmtService srvc) .
It's better to use the Sun Interface as was given to you! All methods of the Sun Interface must be implemented and not empty! That is my opinion.
I did my facade to call my business object (repository pattern) which, call the sun methods, as they are (I not extended sun interface), and my repository interface process all the results coming from sun interface like necessary. So, if you use your own interface, you will be free to put only the methods that you need and your own names and parameters as you would like, without extends sun interface. Use the repository pattern!
Yes, since you explain all thing that you did in you choice file, anything is valid for sun, since also, that you conform with your specification correctly. So, do what you think correct and you will feel better at the end!
... would it be considered ok by Sun...