OX Mapping - Pt 3 - .NET 3.0 and Indigo 2?
In my previous post I went through a basic outline of how I've performed OX mapping to C# classes. In reality getting this mapping correct will always be impossible. The reason is simply that they are too different. On one side a programmatic class or ADT has always represented memory with a type safe abstraction. On the side in the messaging world, a message and its schema describe what is valid for a series of bytes over a stream. One implies complete random access, using names to uniquely identify memory locations. The other aims to describe what to expect during the course of a conversation with a connected process.
The two goals make the two modeling approaches very different. In a message schema you can have optional elements, anonymous types and repeated elements with the same name. You can also have elements that are undefined, that can contain any element. There are a number of approaches used to solve this design gulf:
- Use messages only, don't do OX mapping. Some people suggest that we shouldn't even try to map messages to classes and that web services should not be treated as API calls because they are not. Realistically, developers gravitate towards achieving their goals using the simplest method. It's very unlikely that you will find your average Visual Basic developer dealing with asynchronous communications and parsing XML. In all but the most trivial processes this data will need to be mapped to classes or structures eventually, unless web service developers are willing to give up type safety.
Something that the message advocates also ignore is performance. Performing a one time mapping to actual classes (as in XML Deserialization) has the potential to be a lot faster than creating an XML DOM and reading that DOM structure for all your processing.
- The next option is to restrict XML schemas to configurations that are compatible with simple OX mapping. Like the DataSet schemas in .NET, using special schema formats you can achieve good OX mapping and equate classes to XML types across platforms. The problem is, who will define these standards? Who will buy into this standard, some message oriented folks may stick with the complete schema. Something like this is already happening and causing problems with developers creating services that return Typed Datasets.
- Change the language - improve the language to support more abstract definitions of what a class/struct can be. If the language can support all the features of the message schema then in theory the mapping will be trivial. This is how we arrive at COmega (check the MSDN article here, or a nice summary here).
COmega was developed by MS Research and (like generics before it) it looks like it could get integrated into the runtime itself. In fact Anders Hejlsberg was interviewed on Channel9 saying that “tighter integration with data” was what they have in mind for C#3.0. If you read the comments below the video there are some strong indications that the extensions to C# that COmega presents could end up as part of the CTS.
If this does happen then the implications are massive. .NET would become the preferred platform for speaking XML. The next version of Indigo could make good use of this, providing the developer with a true picture of what inbound messages and outbound messages really contain. The XML experience in a .NET language would be far superior than any other.
To make this leap wouldn't be easy and some big changes in the type system would be required. Some of these changes may not sit well with other .NET languages - potentially a much larger change than the inclusion of generics.