aspose file tools*
The moose likes Distributed Java and the fly likes Passing an object back and forth between Client and Server!!! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "Passing an object back and forth between Client and Server!!!" Watch "Passing an object back and forth between Client and Server!!!" New topic
Author

Passing an object back and forth between Client and Server!!!

Brian Smith
Ranch Hand

Joined: Oct 26, 2002
Posts: 232
hi folks,
i am trying to pass an object through a socket connection. i have created a server socket that reads an employee object created by a client. So the client creates an object in a different machine and sends it to another server machine which it reads and prints. this is just for my experience. Now what i am seeing here is the copy of an employee class both in Server machine and Client machine. Is there any way that prevents having an employee class in both places?
here are the codes:

The fact that the employee class is in both machine is that both Server and Client need an instance of this. is there any way that avoid this redundancy? i am worried that employee class being in both places might create a situation where i might change employee in one place and forget to change in another place.
Also, server is reading an object from Cleint, how can i have client read an object from server. i am thinking to create a server that gets an record from database and sends back to a client. the client makes some changes and sends it back to the server and the server updates it in the database.
thanks for your help.
[ August 05, 2003: Message edited by: Namaste Sathi ]
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

RMI is a higher-level abstraction for what you're trying to do. Part of RMI includes the notion of a "class server" from which clients can download class files automatically, eliminating exactly the problem you're describing. See, for example Sun's RMI tutorial.


[Jess in Action][AskingGoodQuestions]
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
This isn't a beginner's question so I am promoting you to intermediate.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
hi Sathi

The fact that the employee class is in both machine is that both Server and Client need an instance of this. is there any way that avoid this redundancy? i am worried that employee class being in both places might create a situation where i might change employee in one place and forget to change in another place.

This exactly is a problem solved by following means,
1. using SerialVersionUID for the class (as far as u'r not changing the interface). more u can find over here
2. create an interface Employee and write implementation separately say EmployeeImpl,
- then just make Employee interface copy to client and server. So, u can hook any Employee implemenation anytime as client/server only knows Employee interfaces w/o referring to specific implemenations. So, u'd write EmployeeImpl object to the stream but at the recieving end u'll get it as,
(Employee)ois.readObject() u know...
- this is a similar concept RMI would use but the only difference (and that is a big one) is RMI uses "automatic class transfer" etc as Ernest suggested above.
i guess this two pointers shd help u understand ur situation more clearly.
regards
maulin
Brian Smith
Ranch Hand

Joined: Oct 26, 2002
Posts: 232
hi maulin,

2. create an interface Employee and write implementation separately say EmployeeImpl,
- then just make Employee interface copy to client and server. So, u can hook any Employee implemenation anytime as client/server only knows Employee interfaces w/o referring to specific implemenations. So, u'd write EmployeeImpl object to the stream but at the recieving end u'll get it as,
(Employee)ois.readObject() u know...maulin

the problem is that you still need the EmployeeImpl class as you sugessted (Employee)ois.readObject() does not let you to access the actual method implementation in EmployeeImpl class. I may be not understanding the way you've tried to show here. I would appreciate if you could show me how we can get around my proble with your way of implementing interface.
thanks.
[ August 05, 2003: Message edited by: Namaste Sathi ]
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
hi sathi
no. u will not need EmployeeImpl.class file on the other end but u'll need Employee.class file which is an interface.
here is how it would work,
1. U prepared EmployeeImpl object that implements Employee interface
2. now, when u wrote that object on the output stream via ObjectOutputStream then all the object bytes are written to the stream
3. when u read the object from ObjectInputStream then u'll get (Object) type so to say which u'll have to cast to "appropriate type"
4. that "appropriate type" can be the interface (Employee) u defined as its a parent of the implementation class (EmployeeImpl), right?
5. now, when u invoke a method on that object u will know that the particular method is there in the object u've because the class "implements" the interface
u get me?
well, try this way,
- create Employee interface and EmployeeImpl differently and make sure that client has only Employee.class file for the interface only (not EmployeeImpl.class file) WHILE server has both the class files
- create EmployeeImpl object and write it to the client from server
- read the object and cast it to Employee and call any methods in the interface. it would work
anybody else can try explain my point here? i feel poor in explaining this concept here...
regards
maulin
Brian Smith
Ranch Hand

Joined: Oct 26, 2002
Posts: 232
hi maulin,
the idea almost worked. in fact, it works in the same machine. but it does not between two machine. there no problem is the server side but when i do like this Employee emp2 = (Employee)oi.readObject(); in the client side, it throws an exception saying "connection reset". i don't know what does that mean. could you please explain me this?
thanks.
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
hi sathi
that exception seems not related w/ the concept i explained. may b some i/o and socket expert help us here...
regards
maulin
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
hi sathi
plz post ur new code here so that i can look into it..
regards
maulin
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

Hi Guys,
While what Maulin Vasavada writes would allow you to compile the client without benefit of the EmployeeImpl class, I'm afraid that Namaste Sathi was correct when he guessed that the client won't be able to call any of the methods of the received object -- and indeed, won't be able to receive the object at all. You can not deserialize an object unless you've got the .class file; the .class file for a superclass or interface is not enough. Without the .class file, the client JVM won't know how to lay out the data that forms the reconstituted object -- and, of course, it won't have the bytecodes with which to call the methods of that object.
If you want to do this without needing to manually install the class files on the client, then you need some way to do it automatically; and RMI provides such a mechanism. Not only does it provide the mechanism for sending the .class files it also -- and this is a subtle point -- provides the mechanism by which the client learns that it needs a particular .class file. You need the .class file before you try to deserialize an object, not after.
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
hi Ernest
yes. u r right. we need .class file on the client side
but if we refer to the link at JDC Techtip,
JDC Techtip April 25, 2000
and excerpt from that link as,

With normal serializable classes the stream format includes field names and types. So it is possible to reconstruct the state of an object even without the object's class file. Unfortunately, the Java serialization mechanism doesn't include any code to do the reconstruction, so you will have write your own code to do that.

ideally serialization shdnt have required .class file...
my bad sathi. sorry for making things harder on ur end.
regards
maulin
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
also,

You need the .class file before you try to deserialize an object, not after.

is important to note from Ernest explanation...
so does it mean that to call methods subsequently we don't need the .class file??
regards
maulin
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

What I meant was you need to get the class file before you deserialize the class; getting it after isn't good enough.
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
oh ok!
i realized that after the post as anyways methods won't b getting serialized i believe..
regards
maulin
Brian Smith
Ranch Hand

Joined: Oct 26, 2002
Posts: 232
thanks Earnest-Hill and Maulin for providing insight into my problem with your discussion. i appreciate it.
thanks.
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
OK, if you guys are done now , I will move this to the RMI forum (Distributed Computing).


"JavaRanch, where the deer and the Certified play" - David O'Meara
 
Don't get me started about those stupid light bulbs.
 
subject: Passing an object back and forth between Client and Server!!!