Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Server Design

 
Matt Ghiold
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How's this work guys? Thoughts/comments/critism welcome.
The server is made of four key components: DataModelInterface, RemoteDataImpl, KeyGenerator, and FlyByNightServer. The DataModelInterface is the interface that defines all methods found within the Data class but also extends Remote to be used via RMI. This interface allows for seamless client use of the backend regardless of whether it is connected locally or remotely. The drawback to this is that all methods that call the back end data class need to catch RemoteException regardless of whether they are in local or network mode.
The RemoteData class implements the DataModelInterface, extends UnicastRemoteObject, implements the lock and unlock and a Singleton design pattern to form the remote server. The singleton pattern was chosen to guarantee that only one instance of the class exists within the JVM. This will help ensure data integrity. RemoteData through the use of RMI becomes the back end server. Because it implements the same interface as the local Data class, it allows for maximum flexibility and integration with the DataMgmtFacade.
The lock and unlock methods were implemented using a helper class called the KeyGenerator. The KeyGenerator also implements the Singleton design pattern and has only one responsibility - it grants unique strings for the locking and unlocking records. This uniquely identifies a client connection to a record lock and ensures that only one client can unlock and lock a given record at any point in time. The lock method has one additional feature built into it. When supplied with a -1 parameter, it prevents further modifications to the data file.
Thanks!
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why don't you just use the Unique Remote object that each client gets as the Unique ID. It seems redundant to have an IDGenerator class when what you need is already there.
Mark
 
Matt Ghiold
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you say the unique RemoteObject isn't that my RemoteData class? I think that's a lot of overhead to pass back and forth over the wire, where a string can do the same and not cause as much overhead...
Thoughts?
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually the RemoteData object is already on the serverside, it never comes over to the client side, the stub/Proxy, is on the client side.
Are you using the ConnectionFactory solution? If so the Connection object returned is a Remote Object that stays on the server, the client has the stub which acts as a proxy to pass the method colls to the object that resides on the server.
Since each client has their own serverside object, that can be used as the Unique ID.
Mark
 
Matt Ghiold
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I think I am one of the few that didn't do a connection factory. Each user is getting the same copy of RemoteData as I am only calling new 1x. I think this is less overhead.
Thanks!
-Matt
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not using the connection factory approach has the disadvantage that you usually end up either ignoring the requirements as specified in the javadoc for unlock(), or end up modifying the lock() and unlock() signatures.
I must say that I really disagree with your use of Singletons. I've written about it a few times -- searching this forum for "Singleton" is likely to show up a few rants -- but in a nutshell, the problem is that you (like many others) are misapplying the Singleton pattern because there is no fundamental reason why there could be only one instance of this class. To the contrary. I would submit that a database-driven application with just one table is the exception rather than the rule, and that the FBN system as a whole (only part of which is built by you) will surely use more than one table.
- Peter
 
Matt Ghiold
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter,
You are correct, I did need to modify my lock and unlock signatures in order for my solution to work, and I were to use a connection factory, I could get around that and use the original signatures.
Thank's for the comments, I guess I need to go decide whether to rewrite my back-end server. I definately why I should.
Thanks you Mark, and Peter for your insights!
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Matt Ghiold:
You are correct, I did need to modify my lock and unlock signatures in order for my solution to work, and I were to use a connection factory, I could get around that and use the original signatures.
Do realise that this is a disadvantage rather than a fatal problem. I've seen many use this approach and pass just fine. In fact, to my surprise, I've seen a few who completely ignored the client identification business and unlock() javadoc and still passed if not with stellar scores.
- Peter
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic