• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX(URLyBird):single remote object or multi-remote object?

 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
peoples here often say :
"Each GUI client has one different remote data class object respectively".
I think this is reasonable.
But why not just use one single remote data class for each client and any disadvantage??
Is there any thread on the forum talk about this before??
Thanks.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you do a search on the Connection object you will find many discussions.
Basically it is a one to one relationship. For Each client there is one and only one Remote object to serve that client.
Mark
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Spritzler:
If you do a search on the Connection object you will find many discussions.
Basically it is a one to one relationship. For Each client there is one and only one Remote object to serve that client.
Mark

Ok,but there is only one Data object that realy access the db file,right?
So why not "for each remote object there is one Data object"??
Regards.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes there will be only one Data object.
So you have these proxy remote objects that are runing in a one to one relationship with the clients. These remote objects will pass calls on to the one and only one Data object.
Each remote object will have a reference to this one Data object.
So say you have a connection factory that is bound to RMI. In this one connection factory is the instance of the Data class. The client looks up this factory, calls the getConnection method. In this method is creates a new instance of the Remote object and passes it the reference to its Data object. Now you are set. The client has its own Connection object, that passes calls to the one Data object.
Mark
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Only one Data object is necessary, and Mark's description seems to match what I'm doing as well. However some other people here seem to be incorporating multiple Data instances into their designs - one per remote object implementation, or one per thread. Seems kind of wasteful and confusing to me, but it's possible.
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim and Mark,
Thanks a lot.
I make up my mind that I will follow your instructions.
But still one last question about "Remote object" for each client:
is it necessary that "Remote object" must implements "DataAccess" interface as well as "Data object" does??
I think the client is not necessary to call "lock" or "unlock" method,it is enough that client simply calls "read","write","create","delete" and "update" method of the "remote object" .
And,it is "remote object"'s responsibility to call "lock" or "unlock" method of the "Data object".
Am I right??
Regards.
[ June 04, 2003: Message edited by: biang lin ]
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Crap, stupid browser. I had a great response, and then I clicked on a link from my e-mail and it jumped to that page, and when I clicked back my reply text was gone.
The Remote object will implement the DataAccess interface. Basically its responsibility is to just pass its calls to the Data object. lock and unlock might have code it might not depending on your Locking mechanism. A call to the Remote objects create and such won't have calls to lock and unlock. What you will end up having is a Facade class that the client uses and calls a method like "book" and in that method it will have the business process of booking, and that will have calls to multiple methods of the Remote object.
Mark
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Spritzler:
Crap, stupid browser. I had a great response, and then I clicked on a link from my e-mail and it jumped to that page, and when I clicked back my reply text was gone.

Mark,
What a pity!! Maybe it is because of some javascript code.
Ok,let's talk about the "remote object".
If the remote object implements "DBAccess"("DataAccess" mentioned above should be "DBAccess") interface,it must be treated as a DBAccess somewhere,so where? The client can only treat it as a remote interface ,right? And the client can only calls the method that declared in the remote interface and can not see any method that declared in DBAccess interface.
Therefor,the client can only call "book" and "show" method which declared in the remote interface.(Say there is only two methods in the remote interface).
So I can not see any advantage that the remote object implements DBAccess interface,even I think it is not right.
Expecting your comments.
(Half an hour later)
I think about it afterwards,is this right:
//remote interface
public interface URLyBirdConnection extends Remote,DBAccess {
//all methods is DBAccess's methods
}
//remote object
public class URLyBirdConnectionImpl extends UnicastRemoteObject implements URLyBirdConnection {
//implements every method here......
}
Therefor, the client can access any method that declared in DBAccess interface.
That's what you are talking about,right?

[ June 04, 2003: Message edited by: biang lin ]
[ June 04, 2003: Message edited by: biang lin ]
[ June 04, 2003: Message edited by: biang lin ]
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey,I'm waiting for somebody's comment.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Now some might say DataAccess extending Remote, well what about in your local mode implementing that Interface and now it extends Remote. What Exceptions should it throw? In my submission I had the interface thorw Exception, so that my implementing classes can throw whatever they want. And in the case of the Local implementation, extending Remote does not hurt it.
Now there are other solutions that others have used, and all of them are good.
Now this interface does not have a book method, it has all the public methods of the Data class only. My Facade has methods like book, that call methods from this interface. So therefore my Facade does not care or know whether it is in local or remote mode, nor should it know.
So
Client Controller calls methods on the Facade class which has a reference to a DataAccess implementing class (remote or local) and calls the necessary methods to complete its task.
Does that make sense?
Hope that helps.
Mark
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,Mark
I will think about your comment carefully,thank you very much.
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Spritzler:


Mark

Hi,mark
"DataAccess" interface you mentioned above,is included in the instructions, right?
In my instructions it is "DBAccess" and we are talking about the same thing, rignt?
So,is it ok that I modify the code of "DataAccess"(or "DBAccess")?
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Biang
Mark is away this week.
In my copy of the UrlyBird instructions, the interface is called DB, and Data class must implement it.
Now I think Mark is suggesting a brand new interface called DataAccess which provides access to the methods of Data class.
So you can have a LocalDataAccess class which implements DataAccess. And you can have a RemoteDataAccess class which implements DataAccess.
This means that you do not have to modify the provided interface.
IMHO you do not want your GUI connecting directly to the Data class itself. There should always be a class in between the GUI and the Data class which handles connectivity things. In the case of the direct connection, the intermediate class will have nothing to do. But in the case of network connections, the intermediate classes may have to have specific code to handle the network connectivity stuff.
If you accept that there should be at least one class in between the client and the Data class, then the reason for the two almost identical interfaces becomes clearer: The DB interface is the inteface you code to in order to write the Data class. The DataAccess interface is the interface other programmers could code to in order to connect to your database.
Regards, Andrew
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
That's what I'm talking about!!
Thank you very much!!
 
Bob Reeves
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All:
My assignment is the URLyBird Hotel Booking application. My version of the assignment has no DB interface, it has a DDAccess interface.
I don't see any special reason for my remote object to implement DBAccess, it implements a simplified interface -- ie., a Facade. I think the DBAccess interface is rather clunky.
Also, I don't see any great advantage to having multiple remote objects, one per client. I suspect most implementations are using local variables on the remote object to pass their semantics to a contained Data object. So there is no thread-safety issue (assuming Data is thread safe). There is the issue that RMI doesn't guarantee that all calls generate users threads, but it seems to me the complexity of multiple remote objects isn't justified for an RMI failing. I vote that if you use RMI, you use it the way it was designed! Don't wrap fixups to it.
Anyone agree? I'm sure a lot disagree!
Thx
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bob
I dont see anything wrong with either of your comments / planned implementation.
The UrlyBird assignment is, in some respects, easier than the old FlyByNight assignment. In FBNS we had the requirement The remote client code that you write must provide all the public methods of the suncertify.db.Data class.. Without this requirement I probably would have provided a simpler facade.
Another issue we had was with the requirement that a client could not unlock a record that they had not locked. You have cookies in the interface you have to implement, which makes this easier. We had no such luxury. Having the multiple remote objects was one solution to how to meet this criteria. If I had been able to use cookies I doubt that I would have even looked at multiple remote objects.
But some food for thought: a possible advantage to multiple remote objects (although not required for this assignment) is that it could improve performance in a heavily used multi user environment.
Regards, Andrew
 
Maksim Golubkow
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bob,
Originally posted by Bob Reeves:
I don't see any special reason for my remote object to implement DBAccess, it implements a simplified interface -- ie., a Facade. I think the DBAccess interface is rather clunky.

I'm also doing URLyBird Room Booking assignment and I'm not sure that a Facade would meets the assigment requirements because of the following sentence in the "What you must do" section:
Network server functionality for the database system

and our database system or better the interface to the database system is defined by DBAccess interface.
Regards, Maksim
 
Bob Reeves
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Maksim:
I read that requirement as "Network server functionality *** FOR *** the database system. This is different than "Network server functionality *** IN *** the database system."
I think the trick is to document all assumptions in your design section. You can guess how I'm going to diocument this!
Tx
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic