View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Sp02 Final Exam Review: Issues of Serialization

This problem gave me a little trouble please feel free to correct me.
1. .Net does not encapsulate objects. It simply outputs data structures with no behavior. This is because no bytecodes are outputed and the behavior lies in the byte codes.
When importing an object there is no way to insure that it has been modified or not. Any one with a text editor can change the structure.
Also all machines have to be able to support SOAP.

2.XML schemas define the valid form of an XML object. They differ from class definitions in that class definitions are controlled by the VM and XML schemas are written by the programmer?

3. XML instances are not really objects because they are simply data structures with no functionality. As was stated earlier the bytecodes are not exported with the data structure. And objects are supposed to have both structure and functionality.
Eric Soto

And if anything changes in the code...? Mark Guzdial

I'm assuming Mark is referring to functionality in the code such as method modifications, method additions, etc. If this happens, the class will change, but the serialization of that object will remain the same. You wouldn't be a to tell the difference between the two XML instances. There's the idea of Object –> XML but you can't completely represent an Object starting from the XML instance. Justin Daniel
You got the first part nearly right, Justin, but the issue isn't not being able to tell the difference between two XML instances. What if you add an instance variable to a class? Mark Guzdial

the serialized object wouldn't even work, you couldn't go back from xml –> object if the object has been changed, and the xml instance variables don't match up

Link to this Page