• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

FBN and Business Interface - Allowed?

 
Todd Harney
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all:
My design is very similar to the one just discussed where I have a RemoteDataConnection class that is a remote object, but not bound to the RMI registry...so each client asks the connection factory in the registry for a remote connection and is issued a reference to a new RemoteDataConnection(data,lockManager) which lives on the server. (data and lockManager are instance variables that come from the connection factory). So, I am having two issues that I would like some insight into:
1) It has been mentioned that we don't need to change the method signatures for lock/unlock to include a "client id" (specifically if we use the connection per client model) Isn't true however that since there is only one locking instance for each data instance that there will need to be some adapter code to map the record number to the connection object? (like in a HashMap?)
2) It has also been mentioned that a business interface is a bad idea as it is not re-usable. In my design, the GUI speaks only to a business interface that defines methods like bookFlight, searchFlights, etc which in turn invoke the appropriate methods on a DataAccess interface (either local or remote). Is this against the requirements set forth by Sun? Should I remove this interface and go with a DataClient that implements DataAccess, but adds methods like bookFlight, searchFlight, etc?
Any comments/suggestions would be appreciated!
Thanks,
Todd Harney
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
this against the requirements set forth by Sun? Should I remove this interface and go with a DataClient that implements DataAccess, but adds methods like bookFlight, searchFlight, etc?

No, I had a DataAccessFacade class which is the same thing. Only the facade isn't reusable, but to make another for other cases is easy, and actually easier than passing the interface with all the data class methods
Even though you have one instance of LockManager, that class it to hold all the locks of all the clients. The Connection object that each client has can have it's own HashSet to track the locks that the client has, and only pass an unlock through to the Data class is that record is in their own HashSet.
Mark
 
Todd Harney
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark,
Did your facade class then implement the Data access interface? Or did it contain an instance variable of type DataAccess?
Thanks for the help!
Todd Harney
PS - Regarding the lock manager class, you're saying that the lock manager itself has a mapping of record numbers to connection objects? And then each connection object has its own mapping as well? I guess I was not clear on that point. My remote data connection has a reference to the data class and the lock manager class. I thought I was just going to add a lock, let's say, for record 1 in the mapping with the connection object as the value...effectively mapping each locked record number to a presumably unique remote data connection object reference. Is that not correct..or is it misguided?
 
Todd Harney
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I see now...
Each remote connection has its own set of locks for itself...this way we can guard against some other client trying to unlock a record that wasn't his, right?
Let me know if I am way off base here.
Thanks,
Todd Harney
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic