So, I am back from 1 1/2 weeks in Norway and 1 week of self-imposed abstinence from all things related to work, because I was in severe danger from getting into a burnout condition. 4 weeks of writing a book under pressure and then doing a monster tour isn't healthy. So, I haven't even looked at what's going on in blogland.
What I did is to finally play with my XBox that I got for my birthday. By now, I have almost finished Halo (fantastic game). The only thing that I can't get past is the ending sequence, which is a bit too much arcade-style for me. Same goes for "007 Agent under fire", where I am also stuck at the final scene :)
So, in the last two days or so, I've started to look at the DM mailing lists again (after a long while where the lists just piled up in a folder in Exchange) and have a nice little conversation with Ingo on binary XML serialization, which I am going to pull into blogland now (I simply assume Ingo is cool with that).
A little conversation on binary serialization for XML
Ingo Rammer: we'd need the W3C to come out with a standardized format for binary serialization of the XML infoset as I don't really believe in angle brackets for .NET to .NET communication. Performance still matters.
Clemens: I am strictly against any binary serialization format for XML. Consider this: Hammer an XML document into a block of marble and bury that block of marble in your backyard. With some luck, someone will find that block in 2000 years. They'll be able to figure out your XML document. This wouldn't be true for anything binary. The longevity of binary formats is about 10 years, text works for some 4000 years now.
Ingo: Good point. When using XML as a persistent data format: agreed. But especially for SOAP (be it RPC or message oriented), where a single message has quite a short lifespan, binary serialization would improve performance both in terms of network load and in terms of parsing time. Also I guess the number of times where you would need to get access the exact representation of an RPC call you did some hundred years ago is quite limited. In fact, even if you would be able to read it, you maybe won't have access to its exact semantics or the state of the system at this time.
Clemens: You are leaving out one very important aspect here, Ingo. We need to integrate not only laterally across systems, but also across the time axis. When I write a system today and deploy it, it will have to be integrated into other systems from that point on. The best system will eventually have to be replaced in, say, 7-10 years, max. There is no guarantee any vendor can honestly give you that anything they do in a binary format will be supported in that time frame. Binary formats have severe drawbacks. They depend on byte-orders, data type representations, bitness, etc. It may be okay for today to say that everything ought to be binary for speed, but the fact of the matter is that you are paying for this with integration problems in the future -- as we're seeing at present and which is the primary motivation for people flocking towards text based data representations.
The least that we need is a text-based (XML) manifest that references binary data for any transmission where binary formats make sense: multimedia streams, for instance. So, WS-Attachments (I guess that's the most recent name) makes a whole lot of sense here, but I don't think that a fully binary format does make a lot of sense. In the end, we'd be going back to having a common network data representation format along the lines of DCE RPC and/or CORBA IIOP, which will, in the end, require a huge set of infrastructure to make it work. Interoperability across systems with binary data has failed.
I do agree with you, however, for vertical integration on the same technology stack. For interconnecting backend servers, binary data is the best choice. However, for these high-speed connections, the entire idea of SOAP may not be a good one. Systems with a need for very high speed connectivity and deep integration are typically one system distributed over multiple machines. I think that wiring up components of the same system via DCOM, IIOP or .NET Remoting is and remains a valid choice.
.... to be continued ...
10:54:27 AM 
|
|
