This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Howdy -- this isn't really a beginning question, but I'll give you the high-level answer since it's one of my favorite topics A Remote class is associated with Java RMI (Java's Remote Method Invocation) and is used so that you can make an object on one machine talk to (call methods on) an object running on a *different* machine. Normally in Java, to make one object talk to another you: 1) Instantiate the class Dog d = new Dog(); 2) Call a method on the reference variable that refers to the new object d.bark(); But what if the Dog object is actually on a remote machine somewhere? In other words, what if you want the Dog to bark *on the server*? Then you need to have a Dog class that is Remote. So, that's the purpose and idea of a Remote class... so that you can have OBJECTS that are remote, and call methods on them from objects running on other machines. In Java terms, a Remote class means: 1) A class that implements a Remote interface (that's an intermediate-level question so we won't go into it here, but a Remote interface is one that extends java.rmi.Remote, and every method declares a RemoteException). 2) A class that provides the capability of an instance of itself to be found and used by objects on other machines. In other words, the client needs a way to go and get a reference to something that allows the client to call the method on the remote object, and the Remote class itself provides some of this. RMI is actually *not* hard to do and it's very very cool. I have a campfire story that talks about this... it will be up on javaranch in a week or two, but you can find a version of it on O'Reilly's site at: How to talk about Jini, J2EE, and Web Services at a Cocktail Party You do NOT need to read the whole article; the first half of the article describes what it means to be Remote. Don't worry if you don't understand it all either, because it assumes you have a pretty good understanding of Java, but it will give you an idea of what it's about, and the section of the article on RMI will show you what the Remote code looks like (surprisingly easy). But in a nutshell, a Remote class means that you must build *two* things: a Remote interface and a class that implements that interface. It is truly one of the most amazing features in all of Java, though, but I'd put it in the intermediate level, not beginner. cheers, Kathy
A Remote class is the name generally used to refer to a proxy class in distributed programs. That is, the remote class provides access to the methods of the class it is mimicking, but it has no logic in it other than the logic to relay the message to the server where the actual logic resides. Remote classes are instantiated on the client machine, so they are "Remote" to the server (or you can think of it that they provide "remote access" to a class running on a server somewhere)
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Joined: Jan 04, 2001
Thanks Kathy & Joel!
Cowgirl and Author
Joined: Oct 10, 2002
Ah... Joel makes a good point, and just so we don't give conflicting info... Joel is saying that the Remote class is the "pretending to be the real thing" class that goes on the client, whereas I said that the Remote class is the one on the server... in reality, they are BOTH classes that implement the Remote interface. That's the part I don't want to get into, but yes, for every Remote object, instantiated from a Remote class, there is *another* object that is the Remote object's stand-in. The one that lives on the client, but whose sole job in life is to get the message (the method call) from the client back to the object on the server. And this is where the terminology gets a little fuzzy. cheers, Kathy
Those (plus EJB and maybe sockets and some other protocols) are all remote object technologies with a little "r". Remote with a big "R" is a particular RMI interface. The concepts are usually similar, but the implementations are very different. They'd all have pros & cons in interoperability (say with .NET machines), scalability (a thousand users? fifty thousand?), availability (clustering, failover), speed, ease of use, cost of supporting software, etc.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
When I move this to the Intermediate forum, and I include a link to the moved thread in that forum, which thread is the remote one? This thread? The one in the Intermediate forum? [ February 25, 2004: Message edited by: Dirk Schreckmann ]