I’m working on a “SOA-Like” system, which lives and exchange data in the xml-envelope form which many of us knows as 

   1: <Envelope>
   2:     <AuthData name="" pwd="" />
   3:     <ContextData name="" />
   4:     <Input>
   5:         <FirstNode />
   6:         <FirstNode />
   7:         <SecondNode />
   8:     </Input>
   9:     <Output>
  10:         <ThirdNode />
  11:         <FourthNode />
  12:         <FourthNode />
  13:     </Output>
  14: </Envelope>

I’m starting from an xsd schema which describes the envelope and each “Message” which will be enclosed in the “Input” part, then the operation-result message will be returned as a child of “Output” node. Until now everything could be fine, a standard Envelope, ESB-Message, or what else you want to name it, but a standard situation. But here my problems begins.

First of all, I cannot use a DataContract-fashion-class and the DataContractSerializer, because for the DataContract context it’s impossible to render an xml as above where child nodes are “variables” in the sense of I have a container, in my case the “Input” Object, which could have childs, maybe represented by a form of xmltype-anonymoustype array of objects, every time I can write a collection, an array in the form of:

   1: <Input>
   2:     <FirstNodeCollection>
   3:         <FirstNode />
   4:         <FirstNode />
   5:     </FirstNodeCollection>
   6: </Input>

in this way my objects hierarchy must be InputObject -> FirstNodeCollection -> FirtsNodeObject. I hate this way of representing the objects, but DataContract-fashion-classes and DataContractSerializer, could not produce a different “rendering”

Second, If I want to use the XmlSerializer instead of the DataContractSerializer, first I have to fill my classes of a lot of attributes, and even here, I can have some troubles, even if the only object which natively support the above representation is just the XmlSerializer.

Well, the XmlSerializer could help me, but the first thing which makes me hate it, is the fact that for each Type which it’ll represent, the XmlSerializer will generate a Temp assembly containing the ad-hoc serializer for that Type, and this is the thing which makes me really angry and hungry..of what?? of a normal, well driven, serialization API!

Personally I don’t know which makes Microsoft to choiche this kind of implementation about the DataContractSerializer, but I cannot believe there’s not an easy, more customizable way of doing it. Yes, someone could say me : “Hey, look at the IXmlSerializable interface” but this is a RAW implementation, this makes me think an Italian way to say, (..orrible translation..) “doing everything or doing nothing”, I try to explain it.. saying this I’m saying that Microsoft could makes a Monster, complicated over-rich API, or a simplest, it doesn’t know a “middle way” of doing things.

So, here I’m starting my provocation: why we cannot implement a simple new serialization API? maybe we could make in the beginning simple, and then let it grow and become more complicated! Maybe we could learn something from some JAVA implementation… I hope I can find anyone which wants to talk about, and maybe, start to think to implement something!

Ciao

Technorati Tag: ,