Signed up for this at the recommendation of my boss. I missed the first session, which was about all the cool stuff that is so easy to do with the .NET API. Things like initiating and accepting HTTP connections, sending email, getting files via FTP, etc, etc. I think this session probably would have been a lot of fun, since it's basically showing off a bunch of whiz-bang programmer toys, so I'm kind of sad I missed it. I didn't plan to stay for the third session, which was about Atlas, which looks to be MicroSoft's attempt to jump on the AJAX bandwagon.
The second session was all about WCF, the Windows Communication Foundation. Basically this is a very nice set of APIs and automated proxies that makes it possible to do RMI-ish stuff with ease. "Web services" and "service oriented architecture" being the buzzwords employed. My naive summary of WCF is: "Oh look, MicroSoft has discovered XML!" Basically, you can create code to do something, create an interface (MS word: "contract") to it, and then wrap this all up as a "service". The service can be called by any of several transports. The transports being HTTP(/S), TCP or a couple flavors of IPC. (One flavor of IPC was amusingly named "ICP". So yo, word to the juggalos!) HTTP is restricted to a text-only encoding when exchanging data, but the other transports have binary encodings which make them ~10x faster.
The major parts of a WCF service as presented were an address, a binding, and a contract. Think "ABC" or better, as the presenter astutely pointed out, think "CBA" because that's much more the order that you really care about. The contract of course specifies the interface to the service. The binding seems to specify what transport you're using. And the address what the network address of the machine providing the service is. I wasn't sure why they didn't combine the binding and the address. A typical URI can specify both reasonably nicely. I couldn't see what benefit splitting them up and giving them vague names created. It certainly allows you to access the same service over multiple bindings, but a URI allows the same thing, i.e. "http://blah.com" and "ftp://blah.com".
Another interesting part, that I'm also not entirely clear on, was how you publish your service's "contract" e.g. interface. Because if other people don't know what your interface is, they can't really use your service. XML uses DTD's for this, but I didn't hear about anything comparable in WCF. There seems to be something in the works called "UDDF", which was explained as "the yellow pages of the Internet." To me that sounds like something you're going to have to pay MS money for in order to "advertise" your network service. I'm not sure how, say, a random webserver offering a WCF service would communicate the service's interface (and thus offer the service) without using UDDF.
Despite these problems, WCF seems to be both a powerful and reasonably simple API. We'll see if it lives up to its potential. I've always been a little skeptical about the feasibility of "web services" in general. It seems to me that we need a whole lot more security and QoS guarantees before anyone would be willing to make their core business dependent on someone at the other end of a net connection. Time will tell...
Part of my attendance packet junk was a DVD-ROM with a copy of Vista Beta 2 on it, complete with legit product key sticker on the envelope. If anyone wants this, just let me know. (I asked around at the event - Beta 2 is not the same as RC1, but apparently you can upgrade Beta 2 to RC1 after installation.)