Well, I really do not have any big secrets to uncover, but I wanted to point you WCF developers to an extremely useful tool: sgen.exe.

In itself the tool is quite handy, since you can pre-generate and compile serialization code that would otherwise be generated and compiled by WCF during runtime. The cost for doing this (while only during startup) is quite significant, so using sgen.exe, you can avoid this penalty.

The by far best part of sgen.exe is, however, the '/keep' switch. If you turn this on, WCF keeps the source code for the custom IXmlSerializable implementation, and you can tweak, adjust or - in my case - debug - your serialization process.

There is the obvious question on why FastInfoset and - more importantly for me at this time - why on Indigo (WCF)?

A lot of customers - particularly in the financial industry - have expressed their concern about XML and its 'bloatiness': it is simply to verbose to be useful in 10M, 100M or even Gigabyte sized transactions. This makes a lot of sense and thus, FastInfoset (and similar efficent XML initiatives) were born out of this need.

Sun has been behind FastInfoset from its inception and the current JWSDP and the Glassfish application server fully support FI. It has been a clearly stated goal that we see FI as our strategic binary Infoset representation scheme and we would like to achieve ubiquity.

To achieve such ubiquity, it is mandatory to cover as much server and client platforms as possible. With FI being available for the Java platform - supported and open source - this goal is actually achievable. But in order to be truely successful, it is also necessary to enable non-Java platforms to exchange messages in FI. FIFI aims at just that: to enable FI processing for .NET 2.0 and FI message exchange for WCF.

Reminder: the FIFI BOF at JavaONE is tomorrow, May 17, at 9:30pm in Hall E.

Huh? How are these two things related at all?

Well ... On last Friday I had a terrible Hard Drive crash, eliminating about 10 days worth of FIFI coding. That resulted - obviously - a lot of unhappy coding over the weekend. Fortunately, I was able to redo pretty much all code loss by Monday morning... which shows that trying to get a completely new MessageEncoder working with WCF is a lot of reengineering and much less actual coding (thank the gods of Redmond Kobol for stop and continue in Visual Studio).

Anyway, with some substantial help from Paul and my rejuvenated FIFI code, we got RPC/encoded working.

As for doc/lit: the deserialization framework in .NET 2.0 is quite complex. Having said that, here is a little question for anybody knowledgable about the XmlFormatter (and/or DataContractSerializer et al.):

How does WCF deserialize the SOAP message Body exactly?

If you know the answer, please let me know.

Coming back to the original question: a hard drive crash prompted me to recode portions of FIFI, enabling me essentially to dig a little deeper into the WCF stack. And the glass is half-full.

WS-Addressing is as of today eleveated to a full W3C recommendation.

Congratulations to Marc Hadley ... (for making the web services world a little bloatier )

My final project for this quarter's Stanford course (MS&E 201: Dynamic Systems) is going to be quite interesting. We will try to understand the dynamics behind open source adoption and the challenges it brings for Microsoft.

You might know that StAX (JSR 173) and the System.Xml.XmlReader/Writer classes are quite similar, at the very least in scope. A very interesting difference (that gave me a lot of grief in porting/implementing these APIs) is the way namespace attributes are being treated.

In StAX, namespace attributes are typically dealt with through different calls than those used for 'normal' attributes. This special treatment also comes with a table, where defined namespaces can be stored and referenced. In .NET, a namespace attribute is just another attribute, but they also have an XML namespace table, managing prefixes and scope.

While the differences are only significant on layer 8 and 9 of the ISO stack (politics and religion), porting from one to the other API is quite interesting and - at times - forces you to think about the infoset in new ways.

WCF can be quite annoying - that is, it sometimes does thing in a way I personally don't like.

While happily coding FIFI (the Fast Infoset implementation for WCF that will be demoed on JavaOne), I noticed that the System.ServiceModel.Message.Write(XmlWriter) method does not use WriteStartDocument and WriteEndDocument. This is quite annoying, since nodes in FI need to be properly terminated. Sigh ...

XML and Web services are loosely coupled, right? And loosely coupled and object references do usually not play nice together...

This is quite interesting: It looks like you can preserve object references and pass them along when setting the preserveObjectReference flag to true in a new DataContractSerializer.

I will play around with this and see how this looks on the wire ... stay tuned.

Lauren Wood sent me this web link.

Internet Net Neutrality

I wrote this a few years ago, just months after moving to the U.S. I was in San Diego at that time, at the 49th IETF meeting. One afternoon, I had some time, so I decided to drive to the U.S.-Mexican border. It was quite an experience, and quickly afterwards I sat down in a small outdoor cafe to write down some thoughts that I had back then. I just found this piece when cleaning up my home directory.

Sadly, the House Commitee on Energy & Commerce decided to strike down the provisions in a draft bill that would have allowed the FCC to stop ISPs and telco from extorting customers and web service providers. The arguments of the ISPs are hypocritical: the lack of such provision will allow them to stifle innovation, effectively shut down or limit competition (like e.g. Vonage VoIP service, or the next generation of media delivery).

I sincerely hope that other commitees of the House and maybe other parts of Congress in general will handle this ciritical situation with a better understanding of the technological and commercial ramifications. I also hope that Rep. Markey will not bow down to this defeat, but instead fight for his very sensible provisions elsewhere.