The Dream of True Interoperability

That XML can be exchanged between heterogeneous platforms and understood anywhere is a fact. Web services are a relatively new type of software that exploits this aspect of XML. The rub lies in the fact that in the real world, data must be used once it has been transferred. XML data must be converted to usable objects. But which tool can take care of this mapping process? An easy answer would be the parser, but the parser is a generic tool that processes XML data and returns an XML-specific object, not an application-specific object. For example, while parsing employee data, the parser can create an XML DOM object that contains a tree of nodes set to employee data. There is no way for the parser to return an application-specific object such as an Employee class with properties and methods.

Just as SOAP provides a universal technique for defining a method call, another protocol should provide the ability to describe a class. I’d like to have a simple class definition protocol that would let servers and clients exchange documents that contain structure and data of a given class instance. A specialized type of parser would be needed with the extra ability to deserialize the class description into a valid instance of a type. Sound confusing? Think of the .NET Framework XML serializer (or the SOAP formatter). The XML serializer provides the ability to save and restore instances of classes. The saved data contains information about the structure of the class and its instance data. I believe that the .NET Framework already contains a prototype of the parser of the future.

It will be interesting to see how many of the features predicted or called for in this book will find their place in the next version of the .NET Framework (code-named Whidbey).