I was getting a little interested in learning more about how the Indigo/WCF transport listener architecture works. This is what I found so far:

The center of this is the TransportListenerFactory. Its inheritance tree can be found on MSDN but here is a quick overview:

System.Object
   System.ServiceModel.Channels.CommunicationObject
      System.ServiceModel.Channels.ChannelManagerBase
         System.ServiceModel.Channels.ListenerFactoryBase
            System.ServiceModel.Channels.TransportListenerFactory
               System.ServiceModel.Channels.ConnectionOrientedTransportListenerFactory
                  System.ServiceModel.Channels.NamedPipeListenerFactory
                  System.ServiceModel.Channels.TcpListenerFactory
               System.ServiceModel.Channels.HttpListenerFactory
               System.ServiceModel.Channels.MsmqListenerFactoryBase
               System.ServiceModel.Channels.PeerListenerFactory

Now let's look at a self-hosted example: You first create your ServiceHost and then decorate it with the endpoint and binding information. Custom bindings are most interesting, since you can see a little of what's going on under the cover. Encoding and Transport Channels are required, and you need to add your transport binding last. Also you MUST properly configure the EndpointListener; in particular you need to select the right transport protocol prefix (e.g. http:// for HTTP or net.tcp:// for SOAP over TCP). The EndpointListeners themselves point (Factory property) to the transport factory.

It seems reasonable to assume that the relevant optimizations (e.g. connection multiplexing, pooling) are implemented in the TransportListenerFactory class which is abstract.

Another guess on my part is that I expect that the HTTP listener factory has some special implementation, since it needs to address IIS6 hosting and self-hosted environments.

Here is a very interesting analysis of the debate between proponents of the OpenDocument format and Microsoft:

http://en.wikipedia.org/wiki/Open_Office_XML

It's a little geeky and doesn't carry much importance, but I just liked it from a political point of view...

NetBeans 5.0 Beta on Windows Vista September 2005 CTP:

I used the 1.5.0 update 5 JDK (from http://java.sun.com/) and the recently released NB installer ... worked like a charm and even the bugs are the same as under 2003 and XP. The icons in the file chooser dialog were also matched to the new Vista UI .. looked nice.

If you are as lazy in activating Windows, as I am, you might also run into this problem:

When Longhorn hits the activation grace period, it will not log you in, unless you activate. To do this over the internet Vista will use your Internet Explorer proxy settings. So far so good, but what if that happens on the road with different proxy requirements?

Windows 2003 and XP would let you manually set the right proxy if it failed on the first attempt. Not so Vista: you cannot change the proxy settings in the activation dialog.

Here is the solution: Click on "Buy a new License Key Online" and IE will try to connect (and fail). You can however go into "Tools -> Internet Options" and correct your proxy settings.

Now here is a continuation of my little science project "How does TCP Transport work in Indigo?"

I noticed that the preamble that contains the location URL and the content type has a few length headers:

Now the $64000 question is what are the initial 00 01 00 01 02? And also: are the above fields really identifiers, and if so, what other are there (e.g. 00, 01, 03, ..?) Any takers?

The new NetBeans web services client is quite nice. It is now almost as easy as with Visual Studio to integrate a web service into your application: After pointing the IDE to the WSDL, it generates the necessary proxies and you can then integrate them by right clicking your methods in the source editor and add web operations:

This works right out of the box with ASP.NET 2.0 web services, although it has some issues with complex types (like e.g. an ArrayList). Those get deserialized as SOAPElements which is workable, but requires some SOAP DOM coding.

Indigo (WCF) web services seem to have more issues - I guess this is related to Microsoft splitting up the WSDL into some smaller files (wsdl1, xsd0, etc.)

If you are looking for a Java IDE, please take a look at the latest Netbeans 5.0 beta: http://www.netbeans.org/

Some of the new features:

• Support for Tomcat, Sun Application Server, BEA WebLogic and JBoss
• Massively improved GUI builder (Matisse)
• Web Services client support built-in
• Web Frameworks (JSF or Struts), including palette drag-and-drop

I will post more about this a little later.

It seems obvious that the data in our web services needs to be framed. In the good old days, where all transport was HTTP this was rather trivial: HTTP headers are rich, and can describe Content-Type, Length etc.

But what happens if you select e.g. the net.tcp transport channel in Indigo?

Well, after pointing ethereal to the wire exchange, I came to the following conclusions:

• All session relevant settings (charset, etc.) are exchanged during the connection setup
• The length of the data is framed based on the relative TCP sequence number:
  • The initial relative TCP sequence number is 1
  • The next relative TCP sequence number is computed by adding the number of Bytes in the packet to the current TCP sequence number.

Interesting approach - standard TCP framing.

During PDC, I learned that the WS-Policy vocabulary in WCF (formerly "Indigo") can be extended through IPolicyImporter/IPolicyExporter and IWSDLConverter. I guess I will play around with this in the next couple of week ...

Meanwhile, anybody who did this already?

Rob Relyea published a somewhat more comprehensive step-by-step list to get a Vista system loaded with WinFX and Visual Studio. Check it here.

NOTE: Everything except the Vista OS is publicly available, so go around, tell your friends and spread the bits.

UPDATE: Another important issue I ran into: When trying to install the VS2005 Beta 2 on Vista, it constantly failed and the installation stopped with an error when trying to install the MSXML 6.0 component. The solution is to install the MSXML 6.0 parser before you install VS 2005 Beta 2. The installer can be found in the VS directory in the subfolder wcu\msxml.