Finally, with a lot of help from sgen.exe and a number of very talented inidividuals, I got the complex types to work this morning. The biggest issue was the way WCF compares Strings:
Java does sttring interning, .NET does not do this by default (this is why (object) string1 == (object) string2 is without further consideration a bad idea). Within the XML serialization framework however, WCF uses a NameTable to "atomize" (i.e. intern) strings. The Reader must return interned versions of the name, localName, namespace, etc. or the string comparisons in the generated classes will fail. Here is a sample from the generated code:

while (Reader.NodeType != System.Xml.XmlNodeType.EndElement &&
        Reader.NodeType != System.Xml.XmlNodeType.None) {

    if (Reader.NodeType == System.Xml.XmlNodeType.Element) {
        if (!paramsRead[0] && ((object) Reader.LocalName ==  (object)id4_agedHelloResponse &&
                (object) Reader.NamespaceURI == (object)id2_Item)) {
            o.@agedHelloResponse = Read4_agedHelloResponse(false, true);
            paramsRead[0] = true;
        }
        else {
            UnknownNode((object)o, @":agedHelloResponse");
        }
    }
    else {
        UnknownNode((object)o, @":agedHelloResponse");
    }
}

After fixing the Properties on XmlFiReader, it can now deserialize complex objects, and - as such - also use doc/lit in addition to rpc.

Here are the slides for the BOF.

FIFI-BOF-2535.pdf (424.64 KB)

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