Joe Long’s talk on the plan for migrating existing applications to Indigo was, for me, the most interesting talk of the day. I was especially interested in how he contextualized today’s implementation of WSE with respect to the eventual Indigo-oriented future.

I had previously seen WSE as sort of this pre-Indigo technology, and thought that Indigo would be positioned as WSE on steroids. To a degree, this is true, but I’ve learned that Indigo is in actuality much more than that. The most important takeaway from Joe’s talk was the following: while it’s true that migrating the final version of WSE to Indigo will not require code changes, migrating from version to version of WSE may require a non-trivial amount of development effort.

What this means is that if you’re currently developing applications that are leveraging WSE today and also have a reasonable expectation of longevity, you need to budget time to evolve your WSE code because future versions of WSE may not be backward-compatible.

WSE is a “preview” technology. It’s around to allow those customers who have an immediate need for the features that WSE provides today, and is intended to provide a competitive edge for early adopters. Inherent in this is the idea because of WSE’s status as a preview technology, it will change over time. Furthermore, those changes may break code that you’ve already written, and if you want to retain that competitive edge you will need to build time in the project schedule to upgrade to future versions of WSE as they become available.

Eventually, between now and the time that Indigo ships, WSE will stabilize and grow into the feature set that will be what we now know as Indigo. If you take the time to stay current with WSE as it evolves, your eventual transition to Indigo will be simple. However, the amount of effort required to keep up with WSE as it evolves may be non-trivial. It would be great if we could quantify this in some way, but that’s almost impossible. WSE is a toolset for those who require the competitive advantage (and are willing to assume the risks) that come with life on the bleeding edge of web services technology.

I just went to Hillel Cooperman’s session on AERO, the new Longhorn user experience. Hillel  is rivaling Doug Purdy as my favorite presenter thus far at the PDC.

There were a couple of guys I work with who were sort of surprised that I wanted to go to this presentation. Their attitude was “we build software for the corporate enterprise. Our customers don’t treat usability as a high priority”. That’s a misguided idea: usability is an important concern in any software system, corporate or consumer. Software that presents a great user experience makes for happier users and lower support costs (the best question is the one that you don’t have to answer).

Check out the new Aero UX guidelines at http://msdn.microsoft.com/longhorn/understanding/ux

One of the great things about being here at this PDC is the way that you get information straight from the source. For example, going to a presentation on the new C# features is cool – going to a presentation on those features that’s being given by the guy who designed the language is even better.

Anders Heijlsberg (the man so smart I can’t even spell his last name) did a really fantastic job and gave a very consumable presentation. Even though he cruised through fairly abstract academic topics like the difference between open and closed generic types, anonymous procedures, and outer local variable captures, I still felt that the presentation was “down to earth” and pretty grokable by people who might have accidentally left their PhD’s in their hotel rooms.

Once I get my Whidbey box set up, I’m going to be playing around quite a bit with this stuff. I’ll post code samples when I create them.

Exciting data point: the implementation of generics in Whidbey are REALLY fast. Anders did a demo comparing an ArrayList to a List<int>, with the generic implementation being almost twice as fast as the loosely-typed implementation. The performance gains come from the fact that since the JITed is operating directly on integer data types there’s no boxing/unboxing overhead. And since all retrieval operation on the generic type are typed in terms of int’s, the generic implementation eliminates the need to downcast as well as the associated performance cost thereof.

The generic implementation is really heavily optimized to reduce code footprint. Unlike generic implementations that do compile-time type expansion (like *cough* Java), there’s always only one instance of a given generic type present in the IL – in other words, the IL is itself generic. Actual instances of a closed generic type are created only as necessary – so if you declare List<int>, List<float>, List<Foo> and List<Bar> but only do a runtime instantiation of List<Bar>, the other 3 closed typed won’t incur any additional performance overhead. This is a substantial improvement over C++ templates, which did compile-time expansion. In the C++ world, the compiler would have actually instantiated those other types even though they were never actually used at runtime.

Once a particular closed generic type is actually instantiated at runtime, there are additional optimizations that the runtime takes to reduce the amount of overhead required to JIT-compile the code. When the closed generic type is parameterized in terms of value types, the JIT will generate new code for that type. If it didn’t do this, you’d incur the overhead of boxing and runtime performance would suffer. However, when a closed generic type is parameterized only in terms of reference types, the JIT will reuse the native instructions for all possible instantiations of that generic. That is, List<Foo>, List<Bar>, and List<Baz> will actually all use the same JITed code underneath the hood.

There are other cool things in store as well…briefly, the implementation of anonymous proc’s in Whidbey are full-on lambda forms with full support for capturing outer local variables. I can’t wait to start playing with these!

I learned something really interesting in the Indigo talk that I did manage to go to -- although Indigo is very closely tied to the logical model of the XML Infoset (basically it assumes XML 1.0 + Namespaces as the logical lingua franca), there's no requirement for that logical model to be persisted as a text-based stream of UTF-8 encoded characters. Indigo is actually wire-format agnostic, relying on a formatting mechanism similar to that of .NET Remoting's infrastructure to handle reading and writing an infoset to the wire.

I would imagine that most Indigo scenarios would use the standard UTF-8 encoded XML wire format for communication. This text-based representation is great for readability and interoperability. However, there are some downsides to this wire format -- it's expensive to parse, costly to transmit, and is a generally inefficient representation. There are times when these characteristics are not desirable.

For example, say you're deploying two services that coexist within the same AppDomain. In this case, it makes no sense to use UTF-8 encoded XML as the communication format -- it's just too expensive, and you don't need the benefits of readability and interoperability that the formats provide. It's specifically for cases like this -- where performance trumps interop -- that Indigo's support for custom wire formats become useful.

The specifics of this extensibility point won't be covered until Thursday, but I do know that Whidbey will support some sort of binary XML representation. This binary form will be isomorphic to regular text-encoded XML (and probably can be readily converted to text for debugging purposes), but has a smaller memory footprint and parses faster than text.

There are other uses for binary XML inside outside of Indigo. I think portions of the Avalon stack use a custom binary representation of their XML vocabulary to minimize download times for tricke-feed applications (which are apparently now called "Drizzle Download"). If I remember correctly, this new format is called BAML (binary Application Markup Lanugage)...

It will be interesting to see how the decision to support binary XML will be taken up by the community. There's already been a lot of debate about this -- I imagine that the "XMLness" of binary XML will continue to be debated for some time.

There’s all sorts of nifty stuff that will be blogged about incessantly by other people. Some non-standard things that stuck out in my mind:

• The number of .NET languages is increasing. Explicitly mentioned in slideware are things like Ruby.NET and P# -- which is a .NET implementation of Prolog. Hopefully S# (Smalltalk.NET) will be out soon. Eric also mentioned that there are only 20 letters left in the English alphabet that have yet to be “sharpified”…and all the good ones are going fast
• Longhorn will have an inherent concept of physical location – and a rich set of API’s for manipulating location data. While this is obviously most interesting to the mobile control developers, it’s fun to start imagining what can be done on the server…now that the mobile devices know where they are, it’s time for servers to start figuring out all the “interesting” things that are near that location. And of course, the most interesting part of that problem is defining what “interesting” is…
• ASP.NET 2.0 is starting to look a lot like Sharepoint Portal, at least from the user’s view. Themed sites, web parts that contain little chunks of functionality, and rampant personalization. Very cool!
• Finally, the VB Smart Client demo UI had a distinctly Mac-like look and feel J

I’m going to skip the Yukon keynote in favor of the hands-on labs. I’m going to go try to write some Indigo code.

[12:31 am] I knew this session would be good when I ran into Benajamin Mitchell totally by happenstance. We’d been playing email tag all day, and then there we were, sitting in the same row. I’ve had good luck meeting people today.

Don’s talk was good. It was essentially a futher investigation of the same things he touched on at the XML DevCon back in July (I have my notes for that in my archive which I can’t get to right now…). Essentially, the message boils down to this: object-oriented programming was a good metaphor for building systems that reside in memory, but that metaphor breaks down when you think about trying to build distributed systems that are stable over time. During the 90’s, MS and others tried to “stretch” the interface-based object metaphor and make it a legitimate distributed platform, but nobody’s succeeded. The problem is that OO systems assume too much shared infrastructure and don’t provide a way of answering the question “what happens when that infrastructure changes?”

The problem is that distributed systems don’t respect logical boundaries. In the real world, there are boundaries that govern human interaction – a point which DBox drove home by hauling a volunteer up on stage and violating both his personal space as well as his privacy (Don asked him how much money he made last year – in front of 1000+ people). Needless to say, that relationship didn’t last very long. If there are logical boundaries that govern human interaction, why aren’t there similar logical boundaries that govern the interaction of software components?

Indigo is a set of API’s that make it easy to create service-oriented software systems on the .NET platform. These API’s are built around four guiding principles:

1. Boundaries are explicit. Developers opt-in to exposing service functionality.

2. Services are autonomous. Services must be able to be deployed, versioned, secured, and consumed independently.

3. Services share schemas and contracts, not classes and types. Integration is based upon message formats and message exchange patterns, not interface congruence and binary compatibility.

4. Policy-based compatibility. Instead of a common centralized type system, services use policy to reference well-known semantic elements via XML elements and URI’s.

Number 3 begs the question “what the difference between a schema and a type?” Schemas speak solely in terms of wire format – they define the legitimate contents of a message. Unlike types, which can include both state and behavior, schemas only deal with state. Also, types are absolute – IMarshal is IMarshal, no matter where you are – where as schemas are relative to the client (each client might enforce similar but different schemas on incoming data according to their own needs.

These four design tenets give rise to four areas of note when it comes to writing code:

1. Boundaries are explicitly stated in Indigo. Everything that gets exposed to the outside world is done so via metadata, which is orthogonal to the CLR’s notion of accessability. This maintains a mental separation between the internal and external views of the object, as well as making it easier to special-case the inproc scenarios. Consider the following code, which I hurredly copied from the demo:

using System.ServiceModel;
using System.Runtime.Serialization;

[ DataContract ] //Indicates that this CLR type has a
                 //corresponding schema representation
                 //More on this in Doug Purdy’s session…

public class Person
{

    [DataMember] //opt in!
    private int age;

    [DataMember] //opt in!
    private string name { get{} set{} }
}

[Service] //explicit opt-in mechanism
public class MyService
{

   [ServiceMethod] //note that this is applied to a private method!
                   //Accessability to services is independent from CLR
                   //accessibility. This lets to treat the in-proc
                   //scenario differently

   private void f(Person p){}
   public void g(){}
}

2) Indigo and unification -- the grand unified XML architecture. In the 1.x framework, there are at least 3 API’s for doing interservice communication (ASMX, .NET remoting, and Enterprise Services). These 3 disparate API’s will be semantically combined in Indigo. One API to rule them all!

3) Indigo and Interoperability. Indigo is built with the full knowledge the not everyone will have Indigo. On the wire, it speaks purely WS-* compliant XML, making it interoperable with other implementations of those specs.

4) Indigo and Continuity. There’s a large amount of non-Indigo code already out there, and Microsoft recognizes this. Although the PDC bits do not include this functionality, there will be ways to interop Indigo with COM+, MSMQ, and Enterprise Services.

Going forward, the best way to future-proof your existing applications is to make sure that they communicate with the outside world via ASMX/WSE. Although these implementations are not perfect, they are least flawed. Inside of that boundary (where you have control of the deployment and evolution of the system), use Remoting or ES as needed. But whenever you’re going to be talking to another entity that’s outside of your direct control, communicating with that entity via the existing Web Services technologies will ease your transition to Indigo.

More on these topics tomorrow after the Indigo drill-downs, which I will be attending with great vigor.

[12:05am] Somewhere deep inside me is lurking a post about Don Box’s Indigo talk…part of it was spawned this afternoon, but I don’t have the gumption to write about that right now.

I thought about writing a detailed followup to tonight’s Blogger BOF, but then I realized that just about everyone else in the blogosphere would be doing the same thing. And since I can’t seem to get online at the hotel right now, by the time you actually read this everyone else will have already covered all the interesting bits. So I’m going to hold off on extensive commentary for now. The only thing that I will say is that the content of the session was less than I had hoped for (or maybe it was too much, since I didn’t expect much content at all). No disrespect to Robert McLaws (thanks for putting that together), but I personally didn’t get too much out of the session itself. I had hoped it would be more of a “Hi, I blog, you blog, let’s hang out” session, but it devolved into a discussion on transparent blog categorization and aggregation – both of which are really hard problems and neither of which I think will be solved elegantly until we come to a more fundamental understanding of how to do better semantic processing of natural language content.

I did enjoy meeting a few people, though. I finally got to meet Drew Robbins, the man behind PDC Bloggers. He’s a really nice guy who’s devoted a lot of his personal time and energy to building the distributed community in which we all participate. I also enjoyed meeting Jamie Cansdale, the guy who wrote the utterly fantastic NUnit Add-In for Visual Studio. That guy has saved me a huge amount of time with his great add-in, and he’s a really interesting guy to talk to as well. He was kind enough to show me a little demo of the next version of the NUnit add-in – which brings back my favorite part of the NUnit GUI: The Green Bar of Goodness. Other notables were DonXML, Rory, Don Browning, Benjamin Mitchell and of course BTJ. Overall, it was really fun to meet these people in person and finally associate faces with RSS feeds. I’m looking to do more of that at the party on Wednesday night.

Speaking of great Microsoft community members, I got to chat a little bit with Brad Abrams on the way back to hotel. He’s another MS blogger whom I actively read and respect. Ironically, we didn’t talk too much tech – more commenting on how funny it was that our hotel was hosting two big events at the same time – one being the PDC, the other being the Mercedes Benz fashion show. In the hotel bar, it’s pretty easy to tell who’s here for which event J

Thus far, this conference is exactly what I was hoping for – lots of great new information, good times, and good people. Looking forward to more of the same tomorrow!

[7:23am] My 7am wakeup call came early today. I stayed up too late reading that “Developer Introduction to Longhorn” book they gave us yesterday.

One thing I forgot to blog about yesterday: I heard a rumor that James W. Newkirk (XP guru and co-author of NUnit) had been hired away from thoughtworks and is now working for MS. Anybody know anything about this?

Update: I talked to a Thoughworks guy about this -- the rumor is true; Jim Newkirk now works for Microsoft Patterns and Practices. This may not be news to some people, but it's certainly news to me.

Bounced over to the session on programming Yukon with Managed code (decided to skip the technical overview of ASP.NET 2.0, since that information will be publicly available soon enough).

By now, most people are aware that Yukon will allow them to write CLR code and host it inside the database. From the opening remarks of this presentation, it’s pretty apparent that MS is keen on this new ability to host business logic code inside the database – which is an interesting departure from architectural best practices of the past several years (which were, basically, “don’t put business logic in stored procedures”). There’s definitely a performance benefit to keeping code close to the data – and security gets a lot easier, too. The question is, how scalable is this deployment scenario?

From a code perspective, it seems pretty straightforward. Whidbey has a SqlServer project type, which automatically adds a reference to SqlAccess.dll. Inside this .dll is the implementation of the ADO.NET In-Process provider. Through this provider, the managed code inside of Yukon can talk to ADO.NET using standard ADO.NET syntax – except that the in-proc provider has no remoting boundaries to cross, so getting data in and out of this provider is bloody fast.

There’s a new [SqlFunction] attribute that you can use to expose instance methods to SQL Server – and the integration between Yukon and Whidbey will take care of installing the output assembly into Yukon. It’s unclear to me how those bits get shipped onto the local SQL server if you’re developing on a remote SQL server – I don’t know if the code gets shipped and then compiled on the server, or if the compiled assembly is somehow downloaded to the SQL Server instance.

Interesting things you need to do to make your own SQL UDT:

1)      Slap a [SqlUserDefinedType] attribute

2)      Implement INullable (since everything can be nullable in SQL)

3)      Implement a Parse() and ToString() methods.

4)      Compile.

Once the assembly is installed, it’s integrated into T-SQL. The CONVERT() function will delegate to your type’s Parse() method. You can call other methods on your type from within a SELECT statement via C++-style scope resolution, e.g:

use MyAssembly.MyNamespace;
declare @foo AS MyUDT

SET @foo = CONVERT( “HelloWorld”, MyUDT)
SELECT @foo::GetMessage

Other nifty things: streaming Table-Valued functions build in managed code (provide SQL Server with an iterator and it can stream rows from an arbitrary datasource and other SQL statements can consume this data as if it was a table). For example, you might create a custom managed TVF implementation backed by a data file in an arbitrary format and use the streaming API’s in System.File.IO to read in your data. This TVF can then be used in other SQL statements, just like any other TVF implemented in T-SQL.

I finally made it to the PDC at about 11:47am…too late to hear the keynotes, but early enough to be first in line to get the Longhorn bits. I shared a bus ride from the hotel with Peter Drayton (blog?), who’s a PM on the CLR team – specifically, he works on  ROTOR. We chatted a little bit about Eiffel and some Australian researchers who had taken the ROTOR sources and implemented support for design-by-contract all the way through the stack (from the assembly metadata tables all the way through the JIT up to the reflection layer. There’s a lot of interesting things happening in academia around .NET, and some of these will inevitably end up in MS products.

Time for the “Intro to Avalon” session!

Here’s a picture of me, so if you see me running around the PDC, feel free to say hi!

I woke up this morning all ready to head out to catch my flight to L.A. I packed all the necessary items, including all the things I usually forget – like the charger for my iPod, for example. What I *did* forget about was that today was the day we switch back to Standard Time. So now I’m enjoying the Bonus Hour that we get every fall…this might be the first time that I’m actually on time for a flight :)

I guess now is as good of a time as any to set my own expectations to what I’m expecting to get out of this conference. There’s so much information that’s going to be thrown at me – it’s definitely going to be like drinking from a firehose. Fortunately, I love that sort of thing.

Like everyone else, I’m going to this conference with the full expectation of being blown away Longhorn. I’m also aware that great expectation bring with them the possibility of great disappointment. Frankly, I’m not expecting to be blown away by the bits themselves as they currently stand – it’s still very early in the development lifecycle and I don’t expect the version that they’re going to show us to have a whole lot of spit and polish associated with it. What I am expecting is the Microsoft leadership will communicate a solid, concrete vision for what Longhorn will and will not do for me. I want to see a clear roadmap to the future, and I expect MS to have a concrete plan for executing on their vision. I want to be able to come away from this PDC knowing what I need to do to position myself at the head of pack when Longhorn does eventually ship.

With respect to specific technologies, I’m expecting a lot out of the Indigo sessions. I’ve been privy to some information already, so I know quite a bit about what Indigo will do. I’m looking to come away from the Indigo sessions with some good ideas about how to incorporate the functionality that Indigo will provide into a large-scale solution. While I’m really excited to get down into the nuts and bolts of Indigo, I’m hoping that they’ll spend some time elucidating the business case for Indigo – if only because that’s something that I, as a code geek, sometimes have a hard time communicating to customers.

I’m also looking to meet some members of the community – both inside the Big House and out. The Blogger BOF will be a riot, I’m sure. I can’t wait to meet the people behind the blogs I read on a daily basis. I’m also planning on attending some of the Patterns and Practices sessions. My day job is developing framework application blocks that often find themselves both complementing and competing with the MS blocks. I’m very interested in seeing what the community has to say about MS P&P – are they relevant, or too ivory-tower to be of any real use?

Finally, I’m fully expecting this week to be a hell of a lot of fun. It almost pains me to say this, but this really is my idea of a good time. Traveling to a sunny new city, learning a whole lot about things I’m really passionate about, meeting new people, and seeing cool new toys – what more could you ask for?