in my opinion i think there are two solutions to the limitation in the interface provided:
1- Create anew intermediate interface that will contains news methods and used in the local/remote mode (ex. Data-->MyInterface-->SUNInterface), OR
2- Use adapter design pattern to Adapt an instance of SUNInterface to a new interface (MyInterface) and use this instance in local/remote mode.
In solution one you must provide implementation for all public methods in the Data class and another methods specific to you context.
but in solution two you provide only specific methods that will use the public method of the data class, and in this solution the GUI client are limited to specific methods that provide desire functionality.
SCJP, SCJD, SCWCD in progress.
Roel and Roberto, you gurus... , in my implementation i currently have to choose between those two options described by mohamed. At the moment, my solution looks like mohameds second one: i have a remote adapter which adapts my remote interface and implements SUN's interface. You both wrote you would prefer the first one, can you explain why? Are there any disadvantages within the second approach i can't see at the moment?
Could you give a small sample of the structure your interfaces and Data class are connected together (like I did in my post above)? That will make it easier to understand and respond (without communication errors).
In local mode i instantiate Data directly, in remote mode my factory returns an instance of DatabaseRemoteImpl (DatabaseRemoteImpl itself creates an instance of Data), my DatabaseRemoteAdapter adapts the DatabaseRemoteImpl instance and handles RemoteExceptions...
My factory is the class i bind to rmi registry.
I guess it all depends on what you need to make your solution work. I needed for example a method to initialize my record cache (read records and build a map containing this records). As far as I know you need your own interface to do something like that, and you can't solve it with using the Adapter pattern (because there isn't a suitable method in the original sun interface to call).
And I guess you are making a thick client (expose read, lock and other methods in your DatabaseRemote interface)? I used a thin client so I had a BusinessService method containing just 2 methods for my assignment (find and book). So that's a completely other approach as you, but yours is just as good (even more appropriate according to the instructions and Andrew Monkhouse his opinion about exposing lock/unlock methods to the client, you can read the big discussion here).
yes you are right i'm making a thick client, i have all methods (lock, unlock, read,...) in my interfaces DBMain and DatabaseRemote. They have the equivalent methods and only differ in throwing RemoteExceptions or not. I think that Mohamed is right, there are (only) those two common ways to overcome SUN's interface limitations. I was wondering why you decided for solution #1. But, as you said, it strongly depends on what client you want to have and how your locking strategy looks like and yours is completely different to mine. I will continue this way and let you know if it was ok (or not)...
BTW, all i want to hear from you is that i am not on the woodway and to keep my mind free from all that certification stuff....
No, just kidding...
I too opted for a thick client... but if it was today, I'd prepare a thin client. I think it eases the implementation, the API that is provided to the client side gets simpler and the services become more useful. When I studied the Exposed Domain Model pattern, I thought that it was too complicated to control transactions and the ORM framework in the web tier... in my opinion, there's some equivalence with us creating a thick client. The lock() method is equivalent to the start of a transaction (and that is why I think it must not be called from the update() or delete() methods), and I don't know... I think it is easier to have a thin client. It's simpler... in my opinion.
Roel, you said you extended SUN's interface and your Data class implements your own interface. But why? As you said here you put another tier between client an db access, your business layer with only two methods, book and find. so what's the role of your new own interface? You followed the 3-tier-approach described in your posted link, i'm going to have a 2-tier-app (thin and thick). Can you please explain whats the role of your interface, do you have an example?
I already indicated in my previous post why I needed my own interface, but apparently I didn't explain it very well, so I give it another shot
I opted for a singleton Data class with a record cache (a map containing the database records). In my opinion that's the easiest and simplest approach possible (for example you don't have to cope with IOExceptions in read, update,... methods). So before you can call the read-method on your Data instance you have to first initialize (and populate) the record cache. So in Sun's interface there isn't any method suitable to do this, so I created my own interface:
And of course I needed also a method to write the records from the cache back to the file (invoked when the server is stopped or the standalone application exits).
I also redefined some methods from Sun's interface. More info about this approach you can read in this thread.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Can my Data class implement an interface which extends the DataAccess interface?