I came across this interesting article on how Jim Allchin has championed developing Windows Vista in a more agile way.  He mentioned several times in his PDC keynote that Microsoft had changed the way they were developing software, but didn't provide many details.  Here's an example:

We feel very confident about broad availability [of Windows Vista] by the end of 2006. Now, why do we feel that confidence? We feel the confidence because we re-did the way we were building Windows. During the last two years, we completely re-engineered engineering

Microsoft have always prided itself that it understood how to ship software, so it's interesting to see them reflecting on the problems with their current approaches and how they can be improved.

Here are some interesting points:

• They have reduced the amount of time spent integrating components together by sorting out the dependency between components.  Knowing these dependencies, and working on minimising them (sounds like architecture to me), is enabling Microsoft to leave up components that don't pass 'quality gates'
• They are reducing the idea that 'pulling an all nighter' and being a heroic developer is something to admire:

In 2001 Microsoft made a documentary film celebrating the creation of Windows XP, which remains the latest full update of Windows. When Mr. Allchin previewed the film, it confirmed some of his misgivings about the Windows culture. He saw the eleventh-hour heroics needed to finish the product and get it to customers. Mr. Allchin ordered the film to be burned.

• Bill Gates being was worried about upsetting the status-quo, 'taxing' the developers with process and was concerned about backlash from the developer teams.
• They are finding a lot of value in automated testing tools.  One thought that has been bouncing around my head since the PDC is the comment that Jeffrey Richter made about the problem where a method was added to a class as an instance method, when all other methods were static and the constructor was private, which meant that the instance method could never been used.  As Jeffrey Richter said, it's clear that the developer had not written a single test to check his (I know it was as a he - the guy owns up to the mistake in Brad Abrams' excellent new book 'Framework Design Guidelines') work!  Clearly Microsoft have a way to go in getting test infected.
• Reducing the build time of the product has meant they are getting greater feedback more quickly.

Recently I've been in the position of working with an ex-IBM Architect and an ex-Microsoft Dev Lead. It's been interesting to see the differences in backgrounds and perspectives, which broadly fall into the differences between Architecture and low-level system Development.  An example was a discussion about finding the distance between a point and a rectangle.  The Developer had come up with a patented approach to solving the problem in an extremely efficient way, but the Architect wanted to know why the problem only considered rectangles, and whether it couldn't have been abstracted further to consider many different types of shapes.

The discussions have helped me see the value of both approaches, but overall, the need to architect a solution well, since it is easier to find faster algorithms, but if things haven't been architected well it's a great burden to refactor the structure of the code.

In the keynote yesterday, Don Box and Chris Anderson showed how Indigo can be used in a REST style by sending Plain Old XML (POX) over HTTP.  It’s a great testament to the quality of the Indigo extensibility architecture that they could do this.  By supporting both the REST and SOAP styles it takes the heat out of the debate that one is better than the other.

One of the Hands On Labs goes through the code they used in detail.  The example uses a HTTP GET request to return a plain XML payload, in this case a RSS feed.  An extra level of detail was the fact that the RSS added a custom element indicating an 'adult content rating' system, which was signed.  There were several interesting points from the Hands On Lab.

One complexity around supporting a REST style with Indigo comes from the fact that the HTTP GET request does not have any WS-Address-style action.  To get around this you can use the mapAddresssHeadersToHttpHeaders attribute of the HttpBindingElelement to make the URI of the HTTP GET request the To value on the Indigo Message object.

Since no action is specified on the HTTP GET request the ServiceContract needs to trap any unmatched action using the OperationContract's Action named parameter:

public interface IRestStyleRequestResponse
{
   [OperationContract(Action="*")]
   Message GetRequest(Message request);
}

Since the HTTP GET request on the HTTP transport in Indigo usually returns a description of the service, this needs to be turned off using the Description property of an instance of the ServiceHost type:

// service is an instance of ServiceHost
// stop the HTTP GET returning the site description.
service.Description.Behaviors.Remove(typeof(ServiceMetadataBehavior));

To hook in this binding a custom BindingElement extension was written.  The lab walked through creating a IChannelFactory and IListenerFactory and the rest of the necessary objects as part of the WCF stack.   Just before the transport binding element in the Binding stack there's a custom encoder which does the job of writing out the Message to the wire as plain XML, rather than a SOAP message (as Don Box said yesterday, 'it lathers the SOAP off the message on the way out and SOAPs up the message on the way back in').

Office 12 was unvieled for the first time during the Bill Gates' PDC keynote.  The main thing of note was a simplified user interface devoid of menus and toolbars and replaced with task-focussed tabs and the 'ribbon' bar.  The big question: does this represent a great leap forward in goal-focussed usability or will this be the 'New Coke' moment for Office?

Bill's initial comments:

• Promise of previous PDCs has been realised.  2000 was about .NET and XML Web Service, 2003 was Avalon (Windows Presentation Foundation) and Indigo (Windows Communication Framework) and Longhorn (Vista).  A shame that Hailstorm and ObjectSpaces have been so quickly forgotten, but software is a cut throat game.
• .NET is the most popular development platform in the word
• XML has been core and has gone through three phases: surface support in terms of tools that worked with it, then platform level support in terms of .NET and XML web services, then core in terms of integration with SQL Server and Office.
• XML has become persuasive.  RSS has given us notifications, XML Schemas are being used to create industry schemas and now with WS-* the enabling of protocols to handle security and other requirements.
• Standard comments about 'an exciting time', 'still not halfway through the PC revolution'.  "Best industry in the world", "exciting times"
• PC shipments are up 15% on last year to 200 million units a year.

Funny things that came up on the closed captions on the video screen as Bill spoke:

• 'Intel a mir a cash mode' -  'IntelliMirror cache mode'
• 'Things like our asses are driving up to do this' (RSS)
• Sin yer jistic (synergistic)

Overall I was incredible impressed that the subtitles kept pace and did such an accurate job.

Windows Vista Demo

"Clarity" Demos:

• Task bar now shows preview of documents when you mouse over them.
• Alt+Tab now shows a 'flip view' that shows a strip with the same document previews.
• Windows Key and Space Bar shows a 'stacked' window view with the windows stacked three deep.
• Quick search shows in all explorer views, plus the desktop sidebar.  Interestingly it now appears at the bottom of the start bar.  It will show search results in place and search the desktop and the internet.
• The thumbnail of files shows up in explorer view.
• The search on the explorer will search document metadata (e.g. author) and text - although unfortunately there was no visual highlighting of where the search appeared.
• Virtual folders are supported.  They are defined with XML files (simple elements like cope and tags) and allow you to see all documents on the PC.  These can be organised by metadata in a couple of new ways (stack, keywords, author).
• Documents can be 'painted' with metadata by dragging and dropping.
• The side bar (think side bar, same clock as PDC 2003) hosts gadgets, written in DHTML, script or WCF).
• Gadgets are a new feature that allows information to be displayed on a laptop lid (such as flight information, or ability to control music).  Some need the laptop to be powered, some don’t.

"Confidence" Demos:

• Phishing sites have increased 500%.  IE 7 has some new features to show phishing sites.  For example, if the site uses an IP address the address bar turns yellow and there is a security icon that warns this may be a phishing site.
• Clicking on the security warning allows you to report this site as a potential phishing site.
• Microsoft is going to host a phishing site review group that will investigate the possible phishing site votes (and similar, 'this is not a phishing site' link)
• The dynamic protection service which powers this feature is opt-in.  If a site has been reported and judged to be a phishing site then the address bar goes red and comes up with a warning.
• IE7 also has tab, as well as an 'all tabs view' where you have the ability to view all open tabs in a thumbnail view.  They can be saved as a common set - so you could save your favourite 5 sites as a set and open them up each morning.
• RSS is built into the browser.  This works with the platform RSS store so the sidebar can display the RSS feeds as well.  Viewing the xml feed behind the RSS shows up with a nicely formatted page.
• Microsoft CRM is using RSS to send notifications via RSS.

Office 12 Demos
Word

• Word used to have 1500 commands and 35 toolbars.  9 out of 10 request for features in Office were features already in the product.
• No more toolbars or menus!  There's now a 'ribbon' area that is task based - so you might be 'insert'ing in word or using tables.
• The keyboard shortcuts are still available, they just don't seem visible on any of the screens.
• The team think that 60 - 80% of the features are available in the new tabs.
• The tabs do make some tasks, like adding a header or footer much easier to use.
• There are improved tool tips with more text to explain the features.
• Using the Tables tab in Excel allows you to format tables in Excel.  Selecting the table formatting example shows the formatting in place (I didn't see how to undo this command)
• Apparently they are finding people don't need much training to use the product.  They 'don't need training wheels'.  It will be interesting to see how this flies with large company's IT directors.
• Word has a nice feature to insert drop-downs, showing the formatting in place.
• There is still a File menu.  It has useful features like Finalize that let you clear up hidden text, comments and other features.

PowerPoint

• Improved shape support - automatically converts bullet points into different graphics (cycle of boxes, graph with points on them).

Outlook

• Still has the command bars!
• Is now focused around a to-do list.  Now easier to create tasks off email.  Ability to flag email with a time to follow up so that they appear in the tasks.  Should improve some of the Getting Things Done style work.
• RSS feeds are built in.
• Support for different office documents and SharePoint emails.
• Attachments can be viewed in place.

Thoughts on the new interface
It will be interesting to see the responses since it is quite a change from the current Office user interface, though I think it is a positive change - ever time I visit my dad he always has 17 toolbars in word, with one button on each of them because the toolbars terrify him so much.  The new user interface will protect him from that kind of advanced customisation.

The user interface definitely seems to work much better than it would appear when initially viewed.  It will be interesting to see how corporate customers react and whether they think the new interface will be as intuitive as it is claimed, or whether the possible re-training costs might be an inhibitor to adoption.

At the end of Jeffrey Richter's talk yesterday he showed the depth to which Microsoft has gone to ensure that Windows runs all applications well.  He an exe file called armymen.exe (here's another mention of it) that was actually just a renamed copy of Notepad.exe.  It had three subfolders, each with a zero byte file in it.  When he clicked on it, Windows XP resized the screen to 640 x 480 at 16 colours and disabled that ALT + Tab task switching.  Closing the task returned the screen to normal. 

Under the covers, Windows has some hard-coded logic that checks for the name 'armymen' and the related directories and files and adjusts the screen accordingly.

This highlights the lengths that Microsoft have gone to in order that all applications continue to run.  It also makes me glad that I'm not writing operating systems.

Jim Johnson showed how System.Transacations will allow developers to use Transactions to write more reliable software in simple way that will work across different transaction coordinators while ensuring that performance cost of distributed transactions is only paid if the code uses them.  I had a great time talking with Jim at the last PDC and it was exciting to see him demonstrating this technology that will ship with .NET 2.0, as well as a demo of the transactional file system that's coming with Longhorn Server.

Transactions: Ensuring reliability and resilience
Jim spoke about the philosophy behind the System.Transactions work.  He views transactions as a reliability aid that helps developer write resilient applications that can recover from errors and return to a consistent state, even in the face of scalability and concurrency challenges.
 
Jim showed two methods that were both written to correctly handle multithreading and concurrency, but that they may not work correctly if one depends on the other, since it would require code to trap errors and handle rollbacks.  He argued that transactions provide a simple way of ensuring that the two could work together in an atomic way, behaving correctly even in the case of errors, without a lot of complex code, which is the major use case for System.Transactions.
 
System.Transactions: an efficient, unified managed code object model
The goals behind System.Transaction are to make transactions ubiquitous.  In order to do that they had to make using transactions simpler for developers and overcome the perception that they were too slow.  They have answered the complexity problem by designing a managed code object model in System.Transactions that uses the same code to work with both local in-memory transactions and distributed transactions.  They have reduced the performance issues by ensuring that transactions only enlist the necessary resource managers.
 
Using a transaction involves some fairly simple code: 

Jeffrey Richter combines a deep technical knowledge of .NET with a great sense of humour and honesty about where things went bad, to provide a useful overview of what's new in C# 2.0 and .NET 2.0.  I find sessions like this useful in learning the story or intention behind features in the new technology, in a way that helps me understand them better.

The morning session covered an introduction to the new features in .NET 2.0 mostly around generics and anonymous methods.  Seeing some demos on the new yield statement helped me understand more about how it works.  He showed how you could use the yield statement to recursively walk all of the files and directories in the file system.  The demo was simply writing out the paths to the console window and as it was running there were obvious pauses in its performance.  Jeffrey said that these pauses were likely to be due to garbage collections, which highlighted that the ease of use of the yield statement came at the cost of performance (a class was created per directory/file which put a lot of pressure on the working set and garbage collection).  Jeffrey mentioned the C# team have a solution which reduces the performance costs of iterators but it wont ship until after C# 2.0.

He mentioned that another approach to getting the flexibility provided by the yield statement without the poor performance, was to use generics and anonymous methods instead.  For example, many of the generic collection types in .NET such as Array and List have useful generic delegate types, such as ForEach(Action<T>), FindAll(Predicate<T>) as Sort(Comparison<T>). 

As an example, I can sort a list of string types and print them to the screen in just two lines of code using this techniques:

List<string> names = new List<string>(new String[]{ "Timothy", "Benjamin", "Samuel" });

names.Sort(String.Compare);

names.ForEach(Console.WriteLine);

Whilst I've enjoyed these methods before I did enjoy hearing Jeffrey's positioning of these techniques as a pattern to use instead of the yield statement.  Jeffrey also mentioned that Microsoft had received many requests to add richer generic functionality to the generic collection classes.  His company, Wintellect, have been engaged by Microsoft to write these collections and make them available for free download, and they are currently available as the PowerCollection library.  Jeffrey believes that this functionality might eventually be made part of the Framework Class Library in future versions of .NET.

The great thing about Jeffrey's presentation is that draws on his experience as a consultant to the CLR team.  For instance, he mentioned that having different security levels on properties, a 'new' feature for C# 2.0, was originally part of .NET 1.0 Beta 1 but that it was removed since the C# team viewed properties as just a special kind of field.  From this perspective, having a different accessor made no sense.  But as Jeffrey said, after a large amount of customer features, the C# team has put this feature back. it just took them five years.

Jeffrey is also not afraid to mention the things that the CLR team have done badly.  He spoke about the justification for the static class feature of .NET 2.0.  Apparently in .NET 1.0 the Environment class that only had static methods, but late in the beta cycle a developer added a HasShutDownStarted method but forgot to make it static.  On top of this the Environment class had a private constructor so it was impossible for anyone to create a new instance of the Environment class and call this method.  The worst part of this is that it showed that the developer had not written a single test to check the method that he added!  If they had written a single test they would have seen that they could not have compiled the code that tried to write this method.

The session helped me see the benefits in understanding how a particular language feature works, particularly understanding whether it involves the language compiler or involves the CLR.  This knowledge provides the background behind some of the constraints on the features (such as why you can have a catch block inside an iterator).  The tension between the language compilers and the CLR was highlighted in the recent post-beta 2 changes to more fully support Nullable types in the CLR.  Don Box's idea last year was that many of the changes going forward are going to be driven by 'syntactic sugar' using the language compilers, while Jeffrey was more upbeat that there's still innovation happening inside .NET and the CLR.

Jeffrey is razor-sharp technically and very funny.  My favourite comments so was "Indigo loves using attributes.  They use attributes so much that you no longer have to write code"

The afternoon session started with a coverage of partial types, before spending a long time on CLR hosting and how the SQL team helped ensure that the CLR could be hosted in a secure and reliable way.  While Jeffrey is able to explain this stuff really well, it was a hard slog to keep up with the section on Constrained Execution Regions ... so I've nipped off to watch David Solomon and Mark Russinovich's Windows Internals section (or Sysinternals tools seminar as it seems to be).

I did a presentation on Indigo to the VBUG London group last night.  The turn out was pretty good, although it was obvious that many English football fans were missing (though they probably would have enjoyed the User Group more than the humiliating defeat).

Off the top of my head, here are the things that keep standing out for me about Indigo:

• The power of separating choices about the binding from the code that a developer writes.  Being able to switch from the tcp with a binary encoding, to reliable messaging over HTTP, to MSMQ just by changing the configuration file is great.
• The simplicity of the programming model.  The majority of the functionality that required Enterprise Services, such as Instancing and Sessions, are available using attributes on either an interface/class or a method such as ServiceBehavior or OperationBehavior.
• The fact that the details of the protocols are hidden under the covers.  Instead of focussing on the WS-* protocols, the focus is on the functionality required.  This has taken me a while to get my head around after having used WSE, which is powerful, but involved having to understand a lot of the details of the underlying protocols.

I'm looking forwad to some of the Level 400 sessions at the PDC, such as Kenny Woolf's presentation on Channels.

As Mehran noticed, I couldn't help but show off the Refactor! tool that's shipping for free in Visual Basic 2005.  This was in response to an attendee who believed that Visual Studio was 'a multi-megabyte bloated version of notepad'. 

Mike Taulty has a sign-up page for UK PDC Attendee Bingo.  I'm going to be at PDC and it would be great to catch up with others, especially those from the UK.  There's already a very interesting bunch of people heading over from the UK whom I look forward to catching up with.

Kirk Allen Evans has an interesting post about proposing a distributed architecture for a client where he finds, after doing performance testing, that the speed difference between different transports reduces as the amount of work done within each call increases.  Based primarily on this finding he's recommending ASMX web services as a better strategy than using COM+/Enterprise Services for his client.

I remember coming across this arguement at TechEd 2004 in Amsterdam where Christian Weyer spoke about some Thinktecture research which showed that the difference in speed between Web Services and other distributed technologies (remoting, enterprise services/COM+) was significant if the work done in the distributed call was minimal, but once a reasonable amount of work was being done the performance difference became less and less important.  Worrying about the speed of the transport without thinking about the amount of work done in each call is a little bit like worrying how fast a car can rev if you have it in neutral.

Of course, this is all keeping with the long-known guidance from the Indigo team, which is to start with ASMX and only go to other options if you need specific features that they provide.  Richard Turner's recent white paper provides more details.

I've been blog-lite while I prepared and then gave my Indigo presentation to the London .NET User Group.  The audience seemed to enjoy it and I had a good time presenting it.  Some quick points:

• The selling point of the Indigo Service model is that it is simple and easy to use.  The benefits for developers is that they get all the benefits of enterprise-quality features such as transactions, reliable messaging and security without having to write any code.  Letting Microsoft do the plumbing allows developers more time to write code that focuses on solving complex and interesting business problems.
• I took on board Clemens' experience and started talking about the 'why' of distributed technologies before delving into how Indigo works.  Luckily this group was very switched on.  I got some good questions about the performance of Indigo across AppDomains/Processes/Machines.
• Someone asked me to provide some background on why Enterprise Services are a better choice than Remoting for communicating between components on the local machine.  Clemens' has some more information on it here and here. 

Doing a presentation where you don't have the current version of the software to demo is a challenge (the PDC Indigo bits are from an older, M4 build, which has been substantially refactored in the now-being-coded M5 build, so there's not a lot of value in showing demos with the PDC bit).  In order to get some code samples I had to transcribe screen shots from the PDC videos (difficult since Steve Swartz didn't use word-wrap in Visual Studio).  I'm filled with (even more) respect for Don Box and Steve Swartz's presentation skills after realizing they managed to do four Indigo presentations at the PDC without even compiling, let alone running any of the applications.

Given the PowerPoint dependence and Clemens' reports on the complexity of the topic I decide I'd have to resort to audience bribery.  I drew on my experience in TheatreSports and brought several bags of Minties from the Australia Shop at Covent Garden (to my horror I discovered today that they are made in New Zealand!) and threw them to the audience whenever I detected the signs of PowerPoint-induced lethargy.

As preparation for my Indigo presentation at the London .NET User Group next Monday, I thought I'd write a couple of posts about Indigo, starting with 'The Road To Indigo'.

Indigo is a new technology that represents on the unification of existing distributed application technology.  It takes Remoting, Enterprise Services, Web Services and Microsoft Message Queue and combines them into a single area of platform-level technology.  In fact, Microsoft has literally taken all of the teams responsible for these technologies and put them in the same building.  Instead of thinking of Indigo as a completely new technology, think of it as the next version of all the existing approaches where all of the best features of each are combined into a single managed-code programming model.  Here's a diagram showing the progression of these technologies:

Indigo also lets you chose the way you want to build applications without tying you in.  Indigo supports and encourages building service-oriented applications using messages based on SOAP.  However, Indigo still supports you and provides features even if you want to create distributed applications using a distributed component approach using remote procedure calls.  Choosing one approach over the other doesn't mean giving up features such as message-level encryption or transactions.  As Ingo Rammer says, Indigo recognises that you shouldn't be locked into 'a specific programming model, a serialization model, a transport model, or even just a serialization format'.

When I was clarifying the Microsoft Messaging Message I said I'd watch the PDC DAT 420 presentation on BizTalk and Indigo.  As my PDC DVDs arrived this week I didn't have to download the presentation I finally got around to watching it.  Here are the key points I took from the presentation:

• From a BizTalk perspective, Indigo is the vehicle that will provide secure, reliable transacted services (over more than just http).
• Indigo is an API, BizTalk is a set of tools.  Indigo will natively integrated into the next version of BizTalk after BizTalk 2004.  The demos showed a prototype Indigo adapter that worked with BizTalk 2004.
• BizTalk has been achieving reliable services through the BizTalk Framework 2.  In future this will be deprecated and replaced with WS-ReliableMessaging, which will be provided by Indigo.
• BizTalk will use the security model built into Indigo to enable WS-Security support for Username tokens and X509 certificates that can be easily configured through attributes, configuration files and policy.

The presentation helped me understand that Indigo is the plumbing.  A lot of business functionality will require the use of tools that take advantage of that plumbing, such as BizTalk.  So I was interested a few days later to see an announcement that the BizTalk Orchestration will ship as part of Indigo in Longhorn.  As the article points out, BizTalk seems to debut features that eventually become part of the plumbing. 

I really enjoyed the presentation, and not just because Scott Woodgate has such a pleasing accent to listen to (New Zealand, so similar to Australian with stranger vowels).   The BizTalk 2004 health and activity monitor combined with the Orchestration debugger were great features.  I can imagine that these would reduce a lot of the pain with administrating and developing complex service-oriented systems.  I'm hoping that I'll get to benefit from these tools on future projects.

Suresh Kumar has posted a newsgroup exchange from Don Box and Scott Woodgate that cover most of the points from the talk on how BizTalk will take advantage of the features provided by Indigo.  Suresh also has some other good posts on general BizTalk 2004 resources, BizTalk and Publish/Subscribe and XML Web Services in BizTalk 2004 including talk of a WSE adapter for BizTalk later this year.   If I could find his RSS feed I'd subscribe.

Tonight was my first bloggers dinner and quite a night.  I was the first one to sign up and the last one to arrive as Chris Anderson worked out.  What was most surprising was that other than Chris, Don and Ian 'I have no blog comments because I hand-coded my blog myself' Griffiths, I only met a few other bloggers (Chris has a better list).  A lot of blow-in blog readers!  But all are welcome and everyone's company was appreciated.

By the time I rolled up the only chair left was next to Don himself.  Luckily I'd boned up on things to talk about (John 'Policy' Bristowe also primed with a couple of last questions via instant messenge) and managed to garner the following:

• I started off with asking how do you communicate semantic intent with policy?  Don's response was: you don't.  You do it out of band with the telephone.  It's what humans are for.  There are a lot of people trying to apply formal methods to determine the structural correctness of the messages, but the intent is something that humans will work out.
• WS-Addressing.  I raised my beef about it being all well an good to have an opaque string as the address, but where was the protocol binding.  Apparently Indigo is going to use the simple URL style scheme, so a tcp address will look like tcp://domainname etc.
• The important of the Endpoint references is to provide a SOAP cookie style mechanism without having to get into the URL hackery such as query strings.
• Someone said "it just felt unusual to send text-based messages around - isn't that slow?".  Don's response was that the first time he had sex it felt weird, the next time better and now he couldn't imagine it any other way.
• What's different between the M4 and M5 releases of Indigo (Clemens seems to know a lot about this)?  Apparently the programming model has been refactored toto make it more unified and simpler (great news here).  The System.MessageBus.Servicess library has changed significantly because what was there was just not as good as it could have been.  I hope this means better terminology than DatagramPortTypeAttribute and DialogPortTypeAttribute, which always seemed a bit complex to me.
• What's the best way to approach Indigo today?  If you want to learn about indigo today in a way that will pay of in the future, don't worry too much about the high level details.  If you work from the wire level back up it will be most useful (this is least likely to change). 
• The focus with V1 of Indigo is proving that they can get great performance with messaging.
• We discussed Clemens' idea that because Indigo uses a streaming reader over the message body, it may be possible that on intermediary/endpoint may start sending onto another intermediary/endpoint before the full message is received.  Don mentioned that there's no reason to think that the message may ever finish.  Queue zen-like moment of poignant reflection and silence.  'Sort of like one giant Congo-line of a message throughout the Internet' I said.  Don didn't say it but I felt him think 'Yes, Grashopper'.
• We spoke about the fact that my pregnant wife who has always been worried about the size of my head, thought that Don was the only person I have on my PDC photowall that had a larger head than me.  Don said his head was larger than mine in more ways than one.  We agreed that his head was impressive, but he was leaning forward in the photo and clearly his head was not awesomely large (at least physically).
• I suggested Don try the Cinnamon Club for dinner.  We had the Axxiant Xmas dinner there and it was very good (though it was late and I had been drinking ... ).

Afterwards some of us moved off to the pub ...

MSMQ kind of semantics can be implemented [in Indigo] in two ways:  They can be implemented inside a channel, or out in an application serving as an intermediary.

Indigo comes with a channel called the reliable channel that implements point-to-point buffering, point-to point-queuing - so that you can be on a laptop sending messages to me.  The messages stay in a buffer. Later your app goes away, I connect, the messages get sent to me, I reply, the messages sit in a buffer, later your app comes out and drains them.

Or I can build a queue intermediary.  Indigo V1 will ship with a queue class that you can put in an intermediary sitting at an address.  You can put messages to that and you can pull messages from it.

So those are the two options depending on whether you think of a transport kind of thing - so the semantics of me talking to you - or whether it’s a real thing that sits between your and app and the user of the app, where many people may be writing to the same queue and many apps might be reading from it.

Over time - Indigo is a long plan - in Indigo v1 we will be releasing classes, so that you can build queues.  Over time we will be implementing 'queue services' - full bore services that known about clusters and the whole thing.  Parts of MSMQ wont be in v1.  The programmer part will be, but the big old configurable server side wont be.

So, the programming model is there for V1, but a replacement for the enterprise aspects of MSMQ will have to wait until the future.  This would cover the apps where I've message queue in the past (basically a private queue that one app can post to independent of another that reads the messages off), though its not (yet) the replacement to Tibco I was hoping for.

What's the relationship between Indigo, MSMQ, BizTalk and  SQL Server "Yukon" Service Broker?  When and where is each technology appropriate?
Basically it depends what type of application you are trying to build and what environment it needs to run in.  Here's a chart adapted from the DAT406 session:

Technology	Indigo	MSMQ	"Yukon" Service Broker
Environment	Any WS-* compliant endpoint	Windows NT	Yukon on both ends
Application	Any distributed application	Any Async NT Application	Database applications
Message Store	In memory or DB persistent store (Yukon/SQL Server 2000)	MSMQ Message Store (NT File System)	Built into Yukon
Type of Message	Persistent and non-persistent dialogs	Reliable, Express and Transactional Messaging	Transactional messaging only
Protocol	Various	Various	TCP only

Where does BizTalk come into it?
BizTalk is a product that that builds upon other technologies in the Microsoft platform.  As BWill says in comments on a previous post, choosing BizTalk or Indigo will be a question of how much of the infrastructure you want to build yourself.  BizTalk has connectors for MSMQ currently, in future it may connect to Indigo or possibly to Yukon Service Broker.  BizTalk 2004 is currently in Beta it's on a different release schedule than the other products.

Where does Yukon Service Broker fit?
Here's Roger Wolter's answer from the DAT406: Building Reliable Asychronous Database Applications with Yukon:

The key to keep in mind is that Service Broker is a database application framework, not a messaging system.  Yeah we send messages to other databases, but if you're building a messaging infrastructure there's not enough in Service Broker to satisfy your needs.  If you are building a queued, asynchronous database application and you wanted to use reliable messaging to scale out that application, Service Broker is the answer.

There were some hostile questions in the DAT406 session about why it was necessary to put a messaging layer in the database.  John Cavnar-Jonson (who definitely needs a blog) calls it an 'abomination' in the Developmentor Indigo discussion list.  Personally, I think it's part of a Dr. Evil style plan from the SQL team - if they were to add a spreadsheet to the product then a great majority of the world's applications wouldn't need an OS letting the SQL team achieve world domination.  Seriously though, there seem to be several good reasons:

• Developers that know SQL can now  develop queued, asynchronous database apps.  The ability to have asynchronous queues is a very nice architectural feature.  Being able to achieve this with SQL syntax like BEGIN DIALOG ... FROM SERVICE ... TO SERVICE is pretty cool.

• It's all in the one box.  Everything happens within the database.  Backup, restore, installation, configuration, monitoring and security are all there in the one location.  So deployment of the database is deployment of the messaging system etc. (no need to hassle with MSMQ installs).

• The  message broker is the database.  It's easy to query the status of messages, processing the queues is as simple as writing a stored procedure, the database can efficiently throttle the queue processing resources and it's possible to farm out message processing work to another machine since all that is required to process a queue is a DB connection string.

• It's fast. The Service Broker is fast because there's no need for two-phase commits for transactional messaging, there's no need to cross processes to get to the messaging platform and if the send and receive queues are in the same database then it's very fast.

Neils Berglund from Developmentor has been teaching Yukon for a while to Microsoft employees (such as Tim Sneath) and has an excellent sample chapter on Yukon Service Broker that's available for free download.

How does MSMQ fit into the longer term picture?
BWill says in my comments that the Indigo team has shared the love and embraced the MSMQ team into its building.  John Cavnar-Jonson did some research at the PDC:

I completely disagree with the idea that Indigo offers all of the functionality of MSMQ. I discussed this exact question at the PDC with Steve Swartz, Mike Vernal, and Anand (whose last name I don't recall, but he's an MSMQ program manager).  Indigo will offer reliable messaging (which is a huge improvement over current web service technology), but it will not be a full-fledged message queuing system.

As I reported from the PDC, the message was:

"We are not building the uber queuing system - we are not a replacement yet for MSMQ - we have support for routing, but we aren't replacing CISCO, we support eventing but we aren't a replacement for Tibco."

I think there's more to be said in this space.  It's likely that this is about achieving an Indigo V1 release (primarily about unifying the three different programming models and baking WS-* specification support into the platform) and then targeting more ambitious goals with future releases.

Which parts of Indigo will ship in Whidbey and which bit will ship before or with Longhorn?
Basically, System.Transaction will be in Whidbey, the rest later.  I'm still digesting Don's WSV302 Indigo Part2: Secure, Reliable, Transacted Services and Jim Johnson's Transactional Programming on the Windows Platform presentations to understand this more deeply.

Given that the last version of WSE will be wire-level compatible with Indigo and that a future version of WSE is likely to support WS-ReliableMessaging, what are the benefits of Indigo other than the simplified programming model?
Even though I love WSE I'm following the words of Hervey and accepting that WSE is V.Last++.  This question was me fishing for what features Indigo will provide me with as an architect/developer that I can't get from WSE.  BWill mentions:

Advantages of Indigo over WSE: three off the top of my head are performance, integration, and support [it's part of the platform rather than WSE's 2+1 support policy]. I'm sure there are others. Also, note that there is no guarantee that every feature in Indigo will also be WSE.

So, no bites as to what the extra functionality of Indigo might be, so I'm still fishing (e.g. digging deeper into the Longhorn SDK Indigo Samples).  Of course, Indigo has learnt from WSE, so the Indigo programming model will also be nicer (though the WSE programming model is already small and well refactored).

Indigo is committed to supporting WS-* standards and interoperability, but what extra functionality will be available if the whole environment is made up of Indigo boxes?
I'm still trying to get a feel for what features and functionality might be available in Indigo.  BWill mentions the fact that Indigo will likely run faster in an all-Indigo environment. 

Indigo does offer Peer to Peer functionality
Robert Scoble tells us:

I stopped in on Don Box yesterday and he gave me a demo. Indigo is going to radically change how we think of Internet technologies. Imagine something that looks like a website, but that doesn't require a centralized server. Now you're getting your mind around what Indigo could do. Indigo is designed to take advantage of our always on, always connected computers.

It's not difficult to spot an Evangelist with a marketing strength is it :)? Sounds like a simple programming model on top of existing network stacks opens up opportunities to use the Internet for more than just the web browsers against a central web server.  I think I'll review WSV306 Indigo and Peer to Peer apps on the train this week.

A month after the Indigo 'Kimono opening' at the PDC there's still a lack of clarity about what Indigo is, how it relates to other messaging technologies and what's the best way to start developing applications today.  While a lot of this was covered at the PDC my perception is that some of the message hasn't been ack'd successfully from the audience.  [Update: See my more recent post 'More on the Microsoft Messaging message' for some answers to these questions]

The Longhorn DevelopMentor mailing list had an excellent exchange yesterday on Indigo, which has lead me to highlight some areas where I'd like a clearer message:

• What's the relationship between Indigo, MSMQ, BizTalk and SQL Server Service Broker?  When and where is each technology appropriate? (Thanks to John Cavnar-Johnson for highlighting this)
• How does MSMQ fit into the Indigo longer term picture? Is MSMQ for within the Enterprise or will it focus more on outside the Enterprise messaging?
• In terms of EAI technologies, where should we look for this functionality - Indigo or BizTalk?
• Which parts of Indigo are going to ship in Whidbey and which bits will come in Longhorn?
• Given that the last version of WSE will be wire-level compatible with Indigo and that a future version of WSE is likely to support WS-ReliableMessaging, what are the benefits of Indigo other than the simplified programming model?
• Indigo is committed to supporting WS-* standards and interoperability, but what extra functionality will be available if the whole environment is made up of Indigo boxes?

I'm  know some of these were addressed at the PDC.  I'm still digesting some of it (for example, the PDC DAT406 presentation on the "Yukon" Service Broker shows how MSMQ, Indigo and Service Broker are positioned, though not BizTalk).  Other questions I'm still researching.

Many others have noted that the PDC Sessions are available online as streaming audio with synchronized PPT and demos, so who do I think I am posting it again? Well, here's my value-add: it's possible to download the Windows Media streaming audio and the demo videos using a free tool called Net Transport.  I'm using this to max out my broadband connection as well as letting me relive the PDC sessions I was too worn out to make when I was at the conference, on my daily four hour train commute.  Today I spent time on the train with Anders, tomorrow more Don and I'm considering using Doug Purdy's presentation as my new motivational tape to help me get out of bed in the morning.

To start each PDC folder has a file with a 0Media.asx file, which is an xml file containing links to all of the media files in the presentation.  Net Transport expands the xml and starts downloading the individual files.  It's even possible to pause the downloads.  Here's the link for Don's overview of Indigo for example  (you can test the accuracy of my transcription of Don's talk at the same time!).  Once you've downloaded the files, edit the Media0.asx file to use local paths to the individual files and launch it in Windows Media Player.  You'll have to move the slides yourself, but it makes it feel more like a slide night.

If I had more time I'd adapt early & adopter's script to download the slides to download all of the streaming content.

I've just listened to Ander's PDC presentation on C# 2.0 (TLS320).  C# is incredibly cool, the new features are great and it's amazingly useful to have Anders explain them.  Languages enhancements are as exciting for a developer as a better quality hammer is to a carpenter.

What's interesting about language enhancements is that to take advantage of them you have to teach your brain to think more like a compiler.  The Java language exam is probably the best example of this that I've come across.  Initially I thought that having to answer questions that the compiler would check was a waste of time.  Luckily a Java development mate of mine argued that it was important, especially in becoming a better developer.  Having done the exam, I have to agree with my mate that there are real benefits from being able to look at code and know how the compiler would treat it.

So listening to Anders it isn't just exciting to know that they've developed a compiler that knows how to compile impressive statements, but also realising that I'll have to train my head to do the same thing.  Luckily I find learning things like this a real pleasure.   Having new C# syntax to learn and play with is like a bright blue sunny sky for me after the grey clouds of my current project (arguing with a developer who stubbornly insisted that GOTOs were the best way to code a particular method).  Sure this looks a bit scary now, but I can't wait to get familiar with the syntax and to start developing with this extra power:

Some random points from Anders speech:

• Generics  These are great in general and I can't wait to be able to use them in anger.  I have a brilliant C++ developer mate who said he wont switch to another language unless he can use collections without having to cast.  Hopefully he'll be swayed.  I also like the use of the T.default and null checking that is thrown away by the JITer if it's a value type.
• Anonymous methods Anonymous methods seem similar to Java's anonymous classes.  Dare says: "[Anonymous methods] fix the lack of anonymous inner classes in C# by adding anonymous methods for use in the exact same situations most people use anonymous inner classes for".  It was good to understand how the implementation works under the covers to allow anonymous methods to access the parameters of the outer methods (Steve Maine waxed lyrical about this feature and lambda methods on the bus back from Universal Studios, now I finally understand his passion).  I love the idea of passing code as a parameter.
• Iterators I did once try and implement these in VB6 and it was a horror, so I'm glad the story is that writing iterators that can be consumed by the foreach statement is now easy.  Also, statements like foreach (Item x in Items.Subrange(10, 20)) are just cool.
• Partial types Anders explained there were two main reasons for this feature.  I was wondering since Juval Lowry couldn't really see much point in them when he did the .NET radio show pre-PDC. Basically they help people who generate code - the generated class can be regenerated without breaking code written in the other part of the partial class, and where there are long classes (though this is a bad idea in general).  It's also a key part of the XAML story. 
• Other enhancements Finally C# lets us have different accessibility levels on property set's and get's, so the set can be internal and the get is public.  This just feels more right.

As part of a new consulting engagement I started today, I found out that the latest version of the .NET Solution Build & Deployment Process & Tools has a visual designer for MSBuild Files.  The Tools are writtien by Andy Reeves, from Microsoft UK's Solution Development Centre and were the basis for the extensions included with MSBuild.  The download page also has more about why MSBuild was chosen over NAnt.  John Lam has also posted about the NAnt community's reaction to MSBuild.

The new engagement involves 4 hours train travel each day, so I'm going to have to kurb my blogging to get to bed.

Browsing the Longhorn newsgroups, I found a post by David Solomon saying that the Inside Windows 2000/XP/Server 2003 Interactive Video Tutorials CD-ROM was included in the PDC bags.  I had seen this CD in its innocuous blue cover, but I didn't realise that has 12 hours of video presentations, as well as an e-book version of Inside Windows 2000 version 3, and retails for US$950.

The content is really good.  This is great stuff for me as I need to improve my knowledge of Windows internals.  I would have liked to have attended Dave's pre-conference but I felt I had to hear the Web Services story.  Now with the videos on my laptop I can go through the material at my own pace. I'll never be bored on a train again.

When I met the Longhorn Shell Team at Meet The Experts at the PDC I told them I had read Adam Bar's 'Proudly Serving My Corporate Masters', a great book on his 10 years as a developer at Microsoft (that's available to read online).  He left Microsoft frustrated with the fact that Windows never had a proper shell environment.  Well, it turns out that Adam's going back to Microsoft to join the Longhorn Shell Team.

Others have also been impressed with the new shell capabilities, code named MONAD, specifically the ability to deal with objects rather than text streams.  Larry O'Brien says it was the best demo he saw at the PDC, even though the demo was on a bus to venue. As he says 'sysadmin scripting: priceless'

Don Box is a great speaker, but as Scott Hanselman and Steve Maine and this post demonstrate, sometimes understanding and explaining the reasons behind his tenets can be difficult.  As an intellectual entertainment and learning exercise, I'm throwing my hat into the ring, trying to answer a commentor on Scott's website who asked what is meant by Don's tenet of 'Share Schema, Not Type' (actually it was 'share schema, not class'), or as I like to ask 'Why should I use web services (with schema and WSDL) over .NET remoting or DCOM?'.

Steve's Answer
Steve's answer goes like this:

• Types came from the land of COM and were all about binary implementations of interfaces.  Interfaces described the methods that could be called on an object, so they were all about behaviour.
• There were two problems with Types.  Firstly, since they just described behaviour, it was hard to make sure that all implementations of the interface produced the same behaviour (that they were semantically consistent).  Secondly, that once published the interface was immutable and hard to extend.
• Schema are from the land of Web Services and are all about describing the layout of a message. Schema communicate state and nothing about behaviour.  Contracts are the way that schema describe behaviour by specifying the format of input and output of messages that are sent to a service.
• Schema solve the problems of Types.  Schema can extend types by using the open content model.  Schema can ensure semantic consistency across implementations by specifying the schema of the input and output messages.

I like Steve's story, but I'm not sure it's the answer.  The open content model is one approach for extending schemas, though it still works like COM and requires that the newest version provide all of the content required for all previous versions, so I'm not sure how much of a victory this is for the schema approach.  Also, I'm not sure of the differences in terms of semantic consistency, between a COM interface that defines the types of input parameter and output parameters from a method, and contracts based on schema that defines the format of input and output messages of a service. 

Scott's Answer
Scott's answer was that types are unique and immutable and require the sharing of an assembly, whereas schema is a description of the XML content that acts like a contract between parties that can be used without the need for an assembly.  I think this emphasis on avoiding a binary assembly is closer to what Don was talking about.

What was Don thinking?
In Don's PDC Session “Indigo": Services and the Future of Distributed Applications, (slides here) session, Don's tenet was 'Share schema, not class: Integration based on message formats and exchange patterns, not classes and objects' (see Tenet 3 of  my transcript of Don's talk at the PDC, which now seems less comprehensible than I'd hoped).  In his MSDN article Don restates it as "Services share schema and contract, not class". 

"Classes are convenient abstractions as they share both structure and behavior in a single named unit. Service-oriented development has no such construct. Rather, services interact based solely on schemas (for structures) and contracts (for behaviors). Every service advertises a contract that describes the structure of messages it can send and/or receive as well as some degree of ordering constraints over those messages. This strict separation between structure and behavior vastly simplifies deployment"

So, I think the advice behind Don's tenet is to build services using the service-oriented approach (using schema and WSDL to bind the input and output message) rather than an object oriented approach (DCOM or .NET remoting).  This is because it is easier to evolve the structure of the input and output messages using schema rather than having to redeploying an assembly or a binary interface description (*.tlb).

Don's argument is that service-oriented approaches can evolve more flexibly because they can use "features such as XML element wildcards (like xsd:any) and optional SOAP header blocks to evolve a service in ways that do not break already deployed code."  I'm not entirely convinced that COM didn't provide a similar level of flexibility as the xsd:any wildcard (e.g. using As Object in VB).  The optional SOAP headers seems feasible.

What do I think?
I think that interoperability across binary platforms is the key reason to favour schema and contracts over classes.  Object-orientation and types are all about binary representations that are just too difficult to get all of the binary platform vendors to agree on.  Schema provides a machine verifiable mechanism that currently uses text representations which are the lowest common denominator and can be implemented across all platforms.

Within a platform, I think using schema and contracts (web services) over classes (DCOM/remoting) wins on pragmatic grounds because schema and contracts seem easier to deploy (no binary object copying required), debug (it's easy to sniff the packets on the wire to work out what's going on) and evolve (using schema and wildcards seem easier to work with than interfaces in COM, especially when with the XML versioning improvments in Whidbey).

Well, it's been an amazing PDC.  Before I came I thought it would be mostly about the sessions and the technology, but it's also about catching up with people, making new relationships and socialising.  So many times I've thought that I'll have to wait for the DVD to review the material and let it all settle in my head.  The time here has mostly been about understanding the general directions and seeing the motivations and directions for the technology.  As one friend said, "why go to the sessions to watch the PowerPoint when I can go to the Microsoft Product Pavillion and get a Product Manager or Lead Developer to take me through it?"

Some outstanding points;

• Meeting Chris Sells and Steve Maine in person.
• Catching up with all the bloggers shown on my photo blog roll.
• Chating with the Microsoft employees at the Pavillion, the sessions and in the speaker lounge.
• Seeing Jamie Cansdale get the opportunity to demo his NUnit Addin and other tools to Anders Hejlsberg (inventor of C#) and James Newkirk one of the creators of NUnit.
• Seeing my blog stats go through the roof.
• Spending an evening at Universal Studios and managing to ride only th escalators as I was so busy catching up with other bloggers that the rides had shut by the time I got there.
• The end of having to guess what Indigo is.

I'm really excited to see the new technology and to get on board the Indigo wave.

In the panel on Indigo a question was asked about how far Microsoft were going to go in making Indigo support pub sub messaging and competing with Tibco.  The answer was that Microsoft wanted to go all the way, but they couldn't do it all in V1.  The core infrastructure will be there in V1, but it will get easier to access in future versions.

It's 8:30am and there's a room full of geeks wanting to get deep down and dirty into the Web Service protocols.  Omri is the Product Unit Manager for the Advanced Web Services group, so he's the man responsible for the WSE team.  He demonstrated the secure, reliable and transacted demo that Bill Gates gave with IBM on 17 September.  The slides for this session are available.

Positioning Indigo's Protocols
The wire protocols that Indigo uses are key to interoperability story.  Omri is positioning Indigo as the Internet's L7 protocol, comparing Web Services as the top of an Internet stack above XML on top of HTTP on top of TCP on top of IP and onwards.  Microsoft see Indigo as supporting applications between mobile devices, P2P, B2B and EAI style applications.

The Secure, Reliable and Transacted Demo
The demo between Microsoft and IBM showed a commitment to interoperability, as well as a commitment to making sure the protocols involved in web services were royalty free.  The demo was a Supply Chain Management application involving a supplier managing inventory and ordering parts from an auto manufacturer.  It demonstrated security, reliability and transactions in an interoperable way.

MindReef  SoapScope - a better SoapTrace packet sniffer 
Omri showed the messages flying on the wire using MindReef SoapScope, the same tool that Scott Hanselman used in his Learning To Love WSDL presentation at TechEd 2003 (the funniest presentation I've listened to).  Werner also recommends it.  It looks like this is a better approach than MSSoapTrace, which is so buggy that it makes development a horror.  Are Microsoft going to fill this hole?

Web Service Design Principles

General-purpose, composable protocol framework.  Web services allow a building block approach, rather than a monolithic stack like DCOM.  The use of SOAP headers allows the various specifications to be improved and versioned in isolation, without having to redo everything.  Omri mentioned that making the specifications composable was a challenge.  He pointed out that WS-Attachement which was based on the idea of using MIME attachments, based on email, was a mistake that couldn't be combined with other SOAP specifications, like security that relied on SOAP headers.  It became clear that to add security to attachments they would have to reinvent many of the same ideas used to secure SOAP messages: a better model would be to put the attachment within the SOAP envelope so that WS-Security using SOAP headers would provide security.  Omri mentioned that they had learnt from their mistake and were proposing MTOM (message transmission optimization mechanism) as a SOAP-based attachment specification.  As Martin Gudgin says, DIME is dead.

Architecture is meta-data driven, policy based.   WSDL provides some meta-data about a server such as the basic information about messages and ports.  However, this is not enough to describe what the service needs.  This is where policy comes in.  Policy provides another way of expressing the extra metadata that a service needs ( Basically schema is not enough to describe what the service requires).  You can say things like I am a service that requires strong 128 key encryption.  Also, I support HTTP but I am inside a trust domain with you so I can go faster by UDP or TCP.  Deployment information and info about a service that can't be captured in WSDL is in policy.

Protocols are factored from both transports and applications semantics.  Basically web services place information from the transport into the soap message, so rather than using HTTP request response model based on HTTP headers, the information is placed inside the SOAP message to provide abstraction from the transport. 

Architecture allows intermediaries.  Having intermediaries is useful for routing and other reasons.

Uniform data model for protocols/content.  The same infoset is used for both the header and the body.  It allows for header and body-based content-based routing.

Broad industry partnership.  Nothing was going to get off the ground without interop.  Interop was necessary for a transformational change. Omri says that Microsoft knows interop is essential if Web Services are going to be a revolutionary technology.

WS-Addressing
Addressing is a core part of the architecture, the work horse of the stack.  It provides a mechanism to encapsulate identity information in an XML end point reference. There is a basic <Address> element that is the network address of the resource.  There's also the <ReferenceProperties> element that can be used for extra information.

The idea is to allow people to host more than one service at a particular network address.  So if there is a service facade it can host multiple services, without having to do ugly bizarre things with the URLs.  The addressing mechanisms are transport neutral and the internal resource organisation is opaque.

The header has to have a to and action.  It can also have a From, ReplyTo, FaultTo, MessageId (a unique id) and RelatesTo (that provides a way to correlate the message).

Attachments: WS-Policy, WS-PolicyAssertions, WS-PolicyAttachments
Policy provides a framework for making statements about resources.  The policy can say that the service requires (such as transports and security).  Policy can also be used at runtime to make sure that the messages meet these requirements. 

WS-PolicyAssertions provide some basic requirements that can be expressed such as TextEncoding, Language, SpecVersion (Uri asserting compliance with a namespace spec) and MessagePredicate (XPath statements about the message)..  WS-PolicyAttachments solves to the problem of how to attach policy to an endpoint (e.g. matching an address with a policy).

WS-MetadataExchange
This addresses how to get metadata from another endpoint.  There isn't yet a specification to cover this although the demo used a simple get to retrieve policy, WSDL and schema.  It was implemented in the bits using a simple GET mechanism.  Kevin Hammond mentions some more details of how Indigo is doing it in the current bits.

WS-Trust
This defines how to broker existing trust relationships.  It defines how to exchange security tokens using a security token service.  The specification details a RequestSecurityToken message that is sent to a trust service, that replies with with a RequestSecurityTokenResponse.  This is currently supported in WSE and Hervey Wilson, the lead developer has posted a code sample that demonstrates it.  WS-Trust is one of the building blocks of WS-SecureConversation.  

WS-SecureConversation
WS-SecureConversation defines a mechanism to allow clients to make multiple calls to a web service, without incurring the overhead of asymmetric encryption.  It involves using a SecurityContext token based on symmetric encryption.  Think of it as a security 'session' object.  The token can be received using WS-Trust to request one from a security token service, or from having one party create one, or through negotiation.

WS-SecurityPolicy
This specification allows for policy statements about security tokens.  It can be used to specify the types of tokens, the confidentiality or encryption requirements, the algorithms to use and the which parts of the message require signing or encryption.

WS-ReliableMessaging: better QoS, less code
Reliable messaging allows developers not to worry about an inconsistent network.  It provides ExactlyOnce and in order messaging that saves developers from having to write code to worry about lost, duplicated or delayed messages or endpoint failure.  Sent messages are stored in a persistent local store and are only removed when an ACK is received from the server, otherwise they are retransmitted.  Early and Adopter have more discussion. Rebecca Dias has a Starbucks metaphor for the specification-challenged.

Transactions
Transactions are described by two specifications, WS-AtomicTransactions and WS-BusinessActivity, based on the WS-Coordination.

WS-Coordination.  The common parts of the two-following specifications.  It deals with how to set up a context for the transaction, based on WS-Addressing.

WS-AtomicTransactions.  This is the standard two-phase commit (prepare, rollback or commit) using web services.  It uses locks to prevent others accessing resources.  It works best inside an organisation where you can trust the locks to be used correctly.  Don Box calls this the 'anti-availability protocol'

WS-BusinessActivity.  This is a more flexible approach that doesn't use rollbacks or locks.  Instead transactions can be reversed using compensating actions.  In this way the system continously moves forward, there is no need to roll something back (if money was credited into one account, but something else in the transaction failed, post a credit to correct it rather than using a transaction to lock and roll back the initial credit).  It also removes the need for complete agreement between all resources before committing.  Omri's example was a transaction that books a flight, hotel and car for the PDC.  If the car isn't available, he still wants to make the trip and use a bus or a taxi, but there's no need to cancel the booking.  This approach is best for loosely coupled (think external web services) situations, but isn't in the PDC Indigo bits (they think it's important, they just couldn't do it in time).

Omri has announced he will repeat his session on "Indigo: the Web Services Protocols and Architecture" which is great.  Martin Gudgin says that they are demonstrating the sample from the Gates/IBM demo (I want these bits in WSE!).  I saw the comments on the WS-Transaction specs that I'll blog on tomorrow (or I'll beg Drew, who does a very, very thorough job of session notes, to go).  I'd like to sponsor Drew to go to conference I can't make it to in future).

I was so busy catching up with people over lunch I got there late and was sitting in the corridor watching the TV again.  Even though I spoke with Omri last night at Meet the Experts, I didn't recognise his voice and the TV only shows the PowerPoint from the smaller rooms.  I thought that it was Don Box with a shot voice from singing with Band On The Runtime.

ObjectSpaces introduces a mapping layer that separates the business logic from the data access logic to reduce the amount of code to maintain.  It's a declarative mapping between objects and relational tables.  It makes sense when you have a strong or large business logic layer.  It will be available in Whidbey.  They will also have a nice User Interface in Visual Studio to help with the mapping.  I've heard from some ThoughtWorks friends that it's not as good as the Java versions or Neo, an open source product from ThoughtWorks (this guy may have been biased ;)

It works with mapping files to tranlsate from an object query/update to a SQL query/update.  The idea is that objects are responsible for saving their own data and can just call a .Persist method to save the data to the database.  One of the examples is showing how to use GetObjectSet to execute query strings against the objects.  It's a new query language called OPath that lets you write select statements such as this to return data:

It's being given by Luca Bolognese who has promised that his goal is to avoid PowerPoint hypnosis and aim to make sure that no one falls asleep.  He's Italian (yes, really) and a very funny speaker.  However, his accent can sound funny.  He's reading out SQL statements and adding an 'a' to every word, so when he's reading SQL statement it sounds like 'selecta ... froma ... exista'

Classic quote:  Someone asked why they ar eusing OPath rather than XPath.  He said 'we used XPath in the prototype and gave it to the group of programmers, and they came back and said it was too hard.  So we did a search and replace to switch the slashes with dots and they loved it'.  Actually it appears that the two are different problem domains.

I'm sitting with Peter Provost (by chance, the photographer of many of the photos in my photo blog roll), soaking up the blogging energy that he's emitting.  He's actually writing the source code as we see it (a true touch typing programming god!) so perhaps he'll post it later (Peter's notes are now available).

Update: Paul Wilson left a comment pointing to more examples in his article on ObjectSpaces. 

Steve Millet is talking about the improvements in the Indigo model for security tokens.  The good news is that the madness has stopped: when a UsernameToken is validated you only need to return a bool rather than the password.  WSE 1.0 and 2.0 require the password to be returned allowing WSE to work out whether they match.   This was uncomfortable for several reasons, such as the fact the password might have been hashed, or just the fact that sharing the password back with the framework feels like a 'boundary violation'.  I'm glad that we're seeing the end of this bizarre API practice.

Other interesting tidbits were that SAML tokens will be available in Indigo.  Now, if they were only in WSE ...

Existing WSE/ASMX applications are likely to have a good upgrade path to Indigo, with similar security attributes.  There are also extensibility hooks in Indigo to do custom security token handling, so there's an upgrade path for WSE (though this is almost certainly having to write code).

The message from Joe Long a PUM with XML Enterprise Services is that there's an easy migration path from existing applications to Indigo.  The changes are mostly using different namespaces and attributes.  Most of the code inside methods stays the same, except for .NET remoting where instead of using 'new' inside a method the developer has to explicitly state that the object is created remotely

Key Questions

• I have an app - how do I make binary work with Indigo?
• Now how do I move the code to Indigo
• If I start writing a new app today, what should I do to best set myself up to move to Indigo?

There are two approaches to integrating:

• Teach the infrastructure new protocols. Put WS-Security into the existing infrastructure like DCOM and MSMQ
• Teach new infrastructure with existing protocols.  The problem is that these protocols don't interop or work over internet.

Various points

• ASMX code migration is basically just a matter of changing the namespaces and attributes, the code within the methods just work.
• .NET remoting requires similar basic changes.  Is .NET Remoting dead?  No, it's used inside the same process, creating objects and treating them like local objects.  The only difference is the new - you have to declare whether you're doing it locally or remote.  Channels or sinks are not supported, but most of the time these were used to overcome limitations in the platform.  Now things are better.
• There will be a new version of WSE (WSE 3.0?) before Indigo is releases.  The latest version of WSE will also be supported.

WSE code migration

•  Migrating WSE code to Indigo may require a non-trivial development investment.
• There will be whitepapers saying how to migrate.

The key PDC message, or welcome to the Service Oriented World

• Objects are appropriate within boundaries
• Services are appropriate across and within boundaries

What to do today

Build services using ASMX

• Enhance your ASMX service with WSE if you need the WSE feature set and you can accept the support policy

Use object technology in a service’s implementation

• Use Enterprise Services if you need ES rich feature set, you are communicating between components on the local machine and have performance issues with ASMX or WSE
• Use .NET Remoting if you need to integrate with an existing proprietary protocol, you are communicating in-process, cross app domain
  Use System.Messaging if you need the reliable messaging and queuing features in MSMQ

Things to watch out for today

ASMX

• Avoid or abstract using low-level extensibility such as the HTTP Context object

.NET Remoting

• Avoid or abstract using low-level extensibility such as .NET Remoting sinks and channels

Enterprise Services

• Avoid passing object references inside of ES
• Do not use COM+ APIs – use System.EnterpriseServices
• Do not use MSMQ APIs – use System.Messaging

I've been on a mission this PDC - to build a photo blogroll of all the bloggers I read who I've met at the PDC.  I'm happy to say that I've now launched it.

I saw Chris Sells pull his laptop out and start coding with someone on the Windows Form table.  Anders was talking to a bunch of people about C# and all just about all of the Indigo team was there.  I could name drop and say that I enjoyed talking with Ingo, Don, Omri and others, but I wont as that would be showing off.  I got to meet Brent Rector who autographed my copy of his book (the first time I've ever had a book signed!).

It was such a lot of fun.  Once I'd exhausted all of the questions I could think of I sat down to eat (I needed real food after missing lunch and trying to get by on sugar in many different forms).  At that point I noticed a big whiteboard sign: Longhorn Shell Team.  No one was talking to the guys so I went up and said 'are you going to make the shell a first-class citizen in Windows so that my Java friends will stop buying the Mac for its Unix shell'.  Happily the answer was yes.  This is great as it's been a long time problem with Windows that it doesn't have a decent shell architecture.  Adam Barr wrote about this in his book 'Proudly Serving My Corporate Masters'.  The shell guys were really pumped and visibly passionate about what they are up to (creating a new scripting language, manipulating the system through objects with properties rather than text).

After exhausting every question I could think of with James Newkirk, I walked over the black shag pile carpet to the Indigo area of the Microsoft pavilion.  Jim Johnson saw me hovering and asked me if I had any questions.  I said I was a WSE afficianado and wanted to join the wave and learn more about Indigo.

Jim is an architect working on the transactions within Indigo.  Jim is a really nice guy and took me through the WS-specs (Jim was on the working groups that wrote them) that relate to transactions:

• WS-Coordination - the foundation of the transaction 'stack'.  It's concerned with associating an activity identifier with a set of messages.
• WS-AtomicTransactions - This defines a protocol that allows existing transaction systems (think MS and IBM) to wrap their proprietary protocols in an interoperable way.  We talked about how exposing transaction locks outside service boundaries was not something that you want to do very often.  Jim pointed out that within an organisation's boundaries it is useful to be able to achieve two-phase commit using web services protocols.
• WS-BusinessActivity - this is the long running compensating transactions.

We spoke about how these specifications were going to be made available to developers.  It turns out the object model to manipulate these transactions will ship around Whidbey and some of the low level implementation would ship with Indigo.  Don mentioned these topics in his talk this afternoon.

Jim was an incredibly interesting and open guy.  He spoke with a lot of passion about what he's currently interested in - making transactions available automatically to all managed objects.  He had a great, almost Socratic way of talking about topics, for example "Imagine a world where transactions took a millionth of a second", "Imagine a world without catch statements, or where there was no clean up necessary within the catch statement".  Each time he let me try and think through what things meant or what would be possible.  It was so fascinating that I completely forgot about lunch.

We also spoke about more general career topics.  He believed it was important to find a question that you could think deeply about, then find a group of people who are doing it and finally have a passion for shipping software.  I really enjoyed the opportunity to talk with Jim.

I spent the mornig in the Microsoft Pavillion in the Expo hall.  There are real live Microsoft architects and developers available to chat with.  There were more Microsoft staff than delegates, so I took the opportunity to chat with James Newkirk who works for the Patterns group.  He is also the author of NUnit, so I feel a debt to him for the joy that the 'green bar' has brought to my life.  Steve Maine was wondering whether James is now a Microsoft employee, and I'm happy to say he's joined Microsoft to help bring Test-Driven and Agile ideas to the world of .NET developers (he didn't say that, but I'm joining the dots here).  He's writing a new book Test Driven Development in Microsoft .NET that will be released next March, there was a sample chapter available in the Pavillion.  Here are some of the points that came up:

• He's not a fan of Mock Objects because he thinks that in general they are too complicated and don't pay back the investment required to use them.
• The book goes through how to use test-driven development on n-tier applications.  To test the database they decided on using ADO.NET DataSets.
• One pattern to use when doing test-driven development against the database is to use transactions.  In the startup of each test a transaction is started, then in the the completion of the tests the transaction is rolled back.  This saves polluting the database with test data and is quicker than waiting for the database to clean itself up.
• The patterns group are going to create new .NET sample applications that demonstrate the practices and good architecture.  The Duwamish Books example was driven by the desire to demonstrate features rather than architecture.  I'm looking forward to seeing what they come up with.
• We spoke about the work of Gregor Hohpe's new book Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions.  Gregor has already contributed to the MS Patterns group on Enterprise Solution Patterns with Microsoft .NET.  James said it's likely the Patterns group will pick up more of Gregor's work on in future.
• I pulled out my laptop and spoke about the brilliance of Reflector.

The fatigue is showing: I got the session code and the room number mixed up so went off looking for a non-existent room and have ended up sitting in the corridor watching the television.  I met Doug at the Microsoft pavillion before the session and he's in fine form (so excited that he's losing his voice).

Some key points:

• Serialization is not the same as XML programming.  Xml programming is using XSD to get CLR type.  Serialization is about saving a CRL type to XSD or to another CLR type.
• Indigo uses a new attribute [DataContract] instead of [Serializable].  This is part of the general shift from the framework doing things invisibly, or by magic, to the new approach where the developer must opt-in.  Developers must mark up the class with [DataContract] and the members with [DataMember].  Like other attributes in Indigo, these attributes don't care about the CLR's visibility because serializing into XML is not the same as controlling access to objects.
• It's possible to deserialize one CLR type into a different CLR type provided that the serialization class and member names match.
• [DataMember(VersionAdded = 2)] allows you to support versioning in schema.

How to version schemas
A group is added to the schema called 'UnknownData'.  The previous approach that Doug mentioned at TechEd was the open content model. The downside of the open content model is that you lose the checking in future versions.  UnknownData uses the open content model, but it includes a version number which means you can continue to extend the schema.  This works in an interoperable way.

It seemed like too much of a fight to get to all the sessions today, so I skipped one set of sessions to spend some time in the Hands On Labs area.  It's a huge room full of computers loaded with all of the latest bits (the longhorn build, the Visual Studio Whidbey files), so it's much faster than installing them all on a laptop.  Each machine has a booklet of labs that can be walked through.  It's a nice break from the presentations and a useful way to build familiarity with the new concepts.

I did the Indigo track and built my first Indigo application which was like an improved way of using the SoapSender/SoapReceiver from WSE.

I just saw Don Box have to ask to be let into his own session.  The security guy didn't believe he was the speaker so Don had to show his ID pass.

There was a massive traffic jam in the corridor - I went down to the wrong level and have ended up on the floor outside watching the TV.  I'm not sure why Microsoft didn't just leave this session in the same as the last one.  Still I'm thankful for being able to see and hear the message.  My legs are cramping though amongst the small space I have.

Drew is doing an excellent job of covering all of this.  I'm typing as fast as I can so that I can work through it later.

I took extensive notes from Don Box's WSV201 Indigo overview here.  I put them on a separate page because of their length.  Between these notes and Tim Sneath notes you've basically got a transcript.  Here are some questions I've still got

What shall we do about WS-ReliableMessaging and WS-Transactions and WS-Federation before Indigo ships?
Indigo is meant to ship with Longhorn, which Don admitted was still 'a few weeks away' yesterday.  So what are we going to do in the Interim?  Since we know Hervey and Keith from the WSE team have been working all summer on WS-Federation, WS-Reliable Messaging and WS-Transactions I'm assuming these bits exist today within Microsoft.  Will we be able to see them or will we have to wait for Indigo?

How does Indigo fit with existing EAI technologies?
We got the message yesterday that Microsoft are building the service bits that if they didn't write, we'd all write again ourselves (or have already written).  I'm still interested to see how for Indigo will go.  As Don said yesterday:

"We are not building the uber queuing system - we are not a replacement yet for MSMQ - we have support for routing, but we aren't replacing CISCO, we support eventing but we aren't a replacement for Tibco."

I'm looking forward to understanding exactly how far Indigo will go, and where we might still need to use MSMQ and Tibco.

Is Remoting really dead in applications or does it just suck at Interop?
There's been a lot of discussion about whether Remoting is dead.  I'm not a big user of remoting, preferring WSE, but I'm not sure that it's fair to say that remoting will have no future.  As Ingo mentions, Indigo will support whichever method you want. 

Brent Rector's book that was given out with the CDs shows that Indigo has RemoteObject services which are an improvement on the .NET remoting model.   The same decision matrix is involved with RemoteObjects vs. Web Services as with .NET Remoting and Web Services.  RemoteObjects are useful where both ends of the wire share the same Indigo platform and when you need to marshal the object across machine boundaries.

Wow, a whole room full of bloggers.  I'm filled with a sudden fear of what would happen if there was an accident that wiped the room out.  Imagine blogging silence.  My original warm happy glow (as a result of meeting Rory) gradually subsides through the session as I realised what a political and grumpy bunch some bloggers are (Joel agreed).  See Randy Holloway for more detailed technical details.

Solving the problem of posting to different engines
Clemens is talking about how he decided to use metablog api that allowed cross-posting between DasBlog and .Text.  It uses XML RPC.  A fantastic solution from a while ago says Clemens, it's time is over.  Many of the blogging engines have custom extensions that make it hard to cross post.

Clemens likes Userland for their spirt but not their technical ignorance.  They are stuck with a 1997 view of XML, they ignor the namespaces and ignore the angle brackets.  Apparently it was Dave, not the rest of the Userland crew.  Clemens believes that Dave is ignorant of the XML advances.

Atom is a community effort that is trying to solve these things (someone asks, 'What's the problem Atom was trying to solve?'  'Dave Winer' someone yells out).  Clemens concern is that there is a 'comunity discussion' that may go nowhere.  We could either wait or we could define our own standard.  DasBlog, .Text are the dominant engines (in the .NET space), SharpReader, RSSBandit and Newsgator are the major readers.  Perhaps a 'standard' can be created rather than waiting. Scoble reminds us of Don Box's comment that 'the only spec that matters is a spec that is being used'.  The mood is that Clemens and Scott should go away and work it out between themselves.

Robert Scoble 'I'm already getting a bit overloaded now [reading feeds 600 RSS feeds] - I think 1200 is the maximum'.  It's reassuring for all of us to know there are limits.

Clemens is asking Scoble how much the Microsoft Marketers might pay for a WinFS RSS application. Scoble: $50. 

How did Scoble start blogging?
Scoble said MSN have been asking him why he blogs.  He started with FrontPage 97 and had to know a lot about a server and the technology, not could enough for his mum.  The problem originally was that no-one would see a blog - he had to add his blog to the search engine.  People want to see a visit straight away.  Dave used to refresh weblogs.com and view each post as a way of getting the freshest comment.  On Saturdays Scoble still does this.  On his first post 3.5 years ago he got 15 visits straight away, which fed his ego enough to keep feeding the machine.

There's some great stuff in this road map presented by Brad Abrams and Jeffrey Richter.  It's clear that Microsoft have been doing more work on the patterns, speed improvements (the team must love being able to tune a V1.1). The session was an overview of the trolley load of goodies that come with the Whidbey release of the CLR. Brad Abrams mentioned his goal of making sure that the framework uses consistent design patterns. An example of this is the WinFX poster that shows how all of the technologies relate.

How .NET is being adopted

• 60% of the fortune 100 have .NET
• 70M machines have .NET Framework
• NET has had about 100% growth a month this year, recently growing to 300% growth per month

Brad mentioned that blogs and .NET user groups are helping to contribute to the success of the .NET framework (along with over 400 books).

Trustworthy Computing
Trustworthy Commitment is big deal for Microsoft. A few years ago security was just a feature of the product, with a single feature team. Microsoft now understand that security is a horizontal foundation that is thought about in each spec and code review. It's all part of the Trustworthy computing model. Some visible impacts: 1000's of hours of review, external parties have come in to audit the security code. The goals is to help developers build secure apps on top of the platform. This is where the Prescriptive Architectural Guidance comes from.

Base Innovations
These are the most important parts of the system:

• It works seamlessly on 64-bit support. Writing managed code is an investment that will pay off in future.
• Performance. Making the runtime faster to start up. Also raw throughput on ASP.NET - fastest response time possible (optimising the environment and code paths)
• Edit and Continue is here.
• 70's innovation - coloured consoles. This could open up a whole new field for games developers.

Generics
Added new IL instructions and changed metadata tables to get support for Generics, so VB can share it as well. It's also in C++ (why this is better than templates I'll have to look up). Generics have also been added to the common language runtime, which means that all the 3rd party languages can adopt generics (e.g. Eiffel).

Data Access
ADO.NET has no model changes. This is so incredible that it's worth repeating: Microsoft have not invented a new way of doing architecture in the Whidby version of the Framework. (this is extrordinary given the changes that have happened in the past - where did they shift the ADO guys too - surely they would have been itching to do some improvements), the focus is advanced features and performance.
System.XML is core to the platform. There are some performance improvements (from 50 - 100+% for different areas especially XSLT). Also support for Xquery for better support.

ObjectSpaces
ObjectSpaces. Treat rows and columns as an object graph. Based on an xml file that defines the mapping between the relational and the object representation. It basically creates an domain/business object wrapper around the database.  Having to remember the ordinals for rows in a columns is annoying. However, with ObjectSpaces the first things is to set up a connection

ObjectSpace os = new ObjectSpace(myConnections, myMappings);
foreach((customer c in os.GetObjectSet<Customer>( "city = Seatle")){
Console.WriteLine(c.name);
}

Data Acces - System.Data.SqlServer
The integration with Yukon looks like it uses the attributes, such as :
[SqlTrigger("EmailReview"), "Reviews", "FOR INSERT")].

The example Jeff showed how easy it is to write a stored procedure that sends and email when a new review is posted to a database. This used to be a horror in previous version of SQL Server. Just knowing that extended stored procs wont bring the machine down in a bunch of flames is big deal. This could seriously impact consulting revenues!

ASP.NET 2.0
A major release for ASP.NET. The team went away and looked at common code and controls that teams did. The goal was to reduce the plumbing code by 70%. This has been achieved with page framework, 40 new controls

Casini - the old Personal Web Service is back. This times its 100% managed code. It picks a random port each time it's run to protect from someone trying to hack into it (don't they trust developers to lock down their machine )

Where did all the code go?

Building Blocks
They build a range of "Building Block" APIS
Membership control (username/password, resetting the password)
RoleManager (control access based on role)
Personalisation (customize the layout of the site. You can define a class (e.g profile containing name and zip code) that is associated with the logged in user).
SiteNavigation - tracking how the users move between pages
SiteCounters - useful for sites that are paid based on behaviour such as view
Management - IT department get a page or email if there's something going wrong on the site.

The provide an abstract Provide Model Design Pattern that controls the storage of the data behind these controls. Very, very nice.

Page Framework Features
MasterPages - eack. Sounds like some of the FrontPage guys escaped and let loose the nasty FrontPage themes into the ASP.NET page
Themes/Skins - separate the UI from the logic so that it's easy to skin without changing code (like the themes in DasBlog)
AdaptiveUI - all of the controls will render to small handheld devices

Control Buckets (over 40 new controls)
Leverage the previous features to do tings like Security, Data, Navigation, Web Parts. These controls know how to talk to the underlying controls. One example was the bread crumbs links at the top of page.

Innovations on the Web
ASMX performance is being improved through making sure the server side requests per seconds is much better. Secondly there's a smaller working set required on the client to call a web services. They've also notice that web service calls must be asynchronous (the button shouldn't stick down while the web service is working). You need to use a thread pool. This is a little complicated for some developers with the IAsyncResult pattern, so that now this is much easier - this should be the main stream way to call webservices. It ends up just looking like an event.

.NET Remoting - authenticated and encrypted channels. I wonder whether this is WS-Security compliant? It doesn't have to be since remoting is about two .NET machines rather than interops.

System.Net - this has better 'network awareness'. For example Outlook 11 detects the type of network and adjust the experience based on that. FTP protocol support has also been added.

Client Tier with Windows Forms - System.Windows.Forms
Lots of developers wanted to move to Windows Forms, however deployment of client applications is still too difficult. .NET started to make it easier (each assembly has it's own metadata). Whidbey is concluding this story : click-once. It should be as easy to deploy a forms project to clients as it is to deploy a web server. 

XP Theme support has been added. Finally you can look like Office (why is this always a couple of months after the Office release?).  Apparently the Office team will be here this week showing how to make the Outlook interface in 100% managed code.

Longhorn Related

Windows Forms app will work great on Longhorn.  There will be a two-way interop with Avalon.  You can use Avalon markup and mentions win form controls, or you can use win forms on Avalon.

Don and Chris demoed the API underneath Longhorn.  Don achieved his aim of getting a VP to use a text editor to build a demo live.  The demos were very DM/Box with many text editors shown to build the code.  Great coding, a little slow in some of the delivery.

Now onto Longhorn.  Basically APIs in longhorn are a simple set of managed API.

Aero User Interface
The demo started with a simple HelloWorld window, to which they added text boxes, click events, enlarged all of the controls (they're vector graphics), rotated them and set the transparency so that a video could play underneath the controls.

There's a new idea of separating the C# style code from the layout information.  It seems very similar to the code-behind pages in ASP.NET.  The layout information uses XAML (pronounced zamel) an XML syntax to set the properties of the controls (now that I think of it, this seems like an improved version of the form layout information from the old days of VB6)

They also demoed the MSBuild tool.  This is an XML-based build system.  It uses three types of things - properties, tasks and item.  As Scott Hanselman says, 'Holy crap it smells like NAnt.  Wow, writing these build files is xml and is 90% the same concept as Nant.  Learn and use Nant now (I say) and use MSBuild soon.'

The demo showed how to do this using new namespaces such as as MSAvalon.Windows, MSAvalon.Windows.Controls that seemed to be in assemblies such as PresentationCore.dll, PresentationFramework.dlll and WindowsBase.dll

Here's some of the XAML to get a feel for it:

<window xmlns="http://schemas.microsoft.com/2003/xaml"
xmlns:def="Definition"
Def:Class="PDC.MyWindo"
Text = "Hello,world"
Visible = "true"
>
<Visible source="c:\clouds.wmv" Stretch="Fill" RepeatCount="…." >
<TextPanel DockPanel.Dock="Fill" Transform="rotate 10 scale 2.3 2.3">I can embed <Bold>really</Bold> text
 <TextBox id="bob" width="2in" Height="20pt"/>
 <Button Click="Pushed">Push me I'm a cliean</Button>
</TextPanel>

WinFS Search Demo
Don got Jim Allchin to write the code to search the file system and return the items using the Longhorn controls.  Nothing really that amazing here at the API level - it's a nice simple Find method that returns a set of objects that can be iterated through.

Using Indigo to post to Don's Blog
A demo using Indigo to post to Don's weblog.  I'm puzzled as to the the API under the cover (I'm assuming it's using a web service).  Indigo looks like a nicer API on top of the web services.  As Scott mentions, the

Using Indigo to post to the sidebar
Seemed to be a way of using Indigo to post the the sidebar of the desktop.  Similar to using WSE with tcp channels, there was a bit of hassling around with the code to get it set up.

We finally got to see Aero, the Longhorn User Interface. Overall, my interest is in how the flashy graphics will help people get their job done.  Having movies display in a document, and showing them moving in the thumbnails doesn't seem that useful.  Video in general is hard to get information from - it's difficult to condense in time.  I'm concerned the focus is on cool rather than productive. Good features:

• The back button is visible at the top of most windows.  This is a good feature to come from the rise of web browsers, since we know the back button is the most frequently used button.
• There are navigation breadcrumbs at the top of each screen (e.g. my documents, my photos).  You can click on any of these links and get a drop down of other choices at this level.
• In the search results it is possible to get a group of results, called a stack, which is indicated with a pile of papers that varies its height by the number of documents, as well as providing a count.
• When sharing a document the menu shows the name of others on the network that you can share with.  I liked this.

More troubling usability points:

• The side bar at the side of the desktop.  This looked a lot like the Active Desktop from IE 4.0 days (ignoring the opacity of the window).  It displayed an RSS feed, buddy list and a slide show.  I'm not really sure how far this progresses things.  The buddy list was not realistically large, the slide show was irrelevant (in terms of helping people be more productive).
• The top of each window displays the actions that can choose from, similar to XP (except they were hidden on the left hand side).  I'm wondering how useful this will be (I'm imagining you can turn it off).
• The bar at the top of each window displays the name and the back button.  It takes up about 10 - 20% of the screen real estate.  I'm wondering whether the information content justifies thie size.
• The menu has slipped from the top of the screen to under the bar area at the top of the window.  I'm hoping there will be some mouse 'gravity' around these menus as it would seem easier to go to the edge of the window for these key features.

Well, we've had clapping so far for the following:

• The CTRL+ALT+DEL login prompt.  I'm serious.  I think some delegates were so excited they just had to get it out of their system.

My first Bill Gates keynote today.  It's amazing to sit amongst 7,000 developers watching this.  There are 16 massive video screens display shots of the presenters and the PowerPoint slides.

Here are some points that struck me from Bill's speech:

• Microsoft are serious about using software to help them improve any aspect of the user experience that in unsatisfactory.
• The crash reports have helped Microsoft work with video driver makes and computer manufacturers to improve the quality of drivers that ship on machine.  There was a graph showing a reduction from 80,000 crash reports to under a couple of thousand for a particular driver.  It's great to think that this number of computer crashes are being reduced.
• The application crash reports that are sent to Microsoft are available to application developers at winqual.microsoft.com
• The personal computer in 2006 will be a 4-6 GHz machine with 2GB of RAM a 1 TB disk with 1GB networking and 54 Mb wireless.  I'm already excited about asking for a new laptop with this spec from my boss.

A great video was shown on the history of the software  "Software Futures" with Bill Clinton (talking about the number of websites when he was present), Warren Buffet (on Bill Gates missing the software boat) and the inventor of the Newton (on how the modern handhelds).  He ended with a joke about a future episode showing the dangerous, challenging world of database development, over a shot of the Oracle yacht.

This session was on the Patterns and Practices Group at Microsoft.  It was hosted by Jackie Goldstein and included James Newkirk (originally ThoughtWorks, and now Dev Lead for the Patterns group.  Aside: he's writing an exciting looking book on Test First Development in .NET) and another guy from the team. 

Easier to Contribute
Several participants mentioned wanting to make it easier to contribute changes to the patterns and application blocks. So that if a company makes changes they don't need to maintain them separately in their own versions.  The team is looking at using the community workspaces.  James Newkirk mentioned using the Adapter pattern to switch between the shipped source code and any local revisions.

Improve the Help Files
The documentation is currently very class based, what the members and classes are, rather than on how to use them.  Sometimes the samples are too simple and don't show how to use the advanced features.

Some of the QuickStart/JumpStarts are too difficult, especially the User Interface Process (UIP) model based on the Model View Controller pattern.  One participant mentioned integrating the help files into the Visual Studio collections.

An MCT trainer asked for Microsoft Official Content (MOC) that used the patterns group.  The MS people said they are trying to get out there and integrate it with MOC courseware.

Conflict between RAD perspective and Architecture
Visual Studio promotes a RAD, drag-and-drop, visual-designer backed RAD tool.  One participant said they'd like a Visual Studio Add In to help integrate the patterns.  Often the keynotes at the PDC are the quick RAD solutions and this comes across as what Microsoft thinks is Best Practice.  Guidance is harder to market.  One of the Microsoft guys said that marketing the RAD features was a more important goal for Visual Studio than marketing the architecture.  Marketing the Architecture is harder.

Integration with the Visual Studio and Language Teams
Apparently the community around the patterns group (bloggers and speakers like Scott Stansfield from Vertigo) had forced the the Visual Studio and Language teams to work closer with the Patterns Group.  There is a disconnect between internal Microsoft Groups.  The Patterns group said they didn't know that the ASP.NET Starter Kits existed until after they were released).

FX Cop for Architecture
Someone asked for an Architecture Cop like a FX Cop.  Apparently someone in the patterns group also had this idea.  I'd like to see improved checklists as a first step on this one.

Why isn't there more focus on the GoF Patterns?
James Newkirk said they will highlight them as they use it.

Brad Abrams mentions at the Rotor BOF session mentions that Rotor (a free, fully functional implementation of the ECMA #335 standard for a common language infrastructure.) has moved from a skunkworks projects to being fully managed by the CLR team.  When code is checked into the CLR there are tests that determine whether it might break anything  in the Rotor Unix build.  They are looking to release a Whidbey version of Rotor after Whidbey has shipped (someone mentioned September 2004).  Other points:

• There's also a community site at http://sscli.net 
• There's a rotor list at the developmentor site.
• Intel does stuff with Rotor (some of the guys were in the session)
• It's focussed on academic, non-commercial use.  For acedemics and those that are interested in getting under the covers and understanding how .NET works.  The license forbids re-releasing or using it in a commercial product.
• I know a lot of people who use it to run the CLR on Mac OS X
• It's popular with grad students working on Rotor for thesis topics like garbage collection tuning.
• It's for people who want to 'fix' who the CLR, for example Chris Sells got some research funding to look at deterministic finalization.

Brad Abrams wanted to know whether anyone was interested in using the JIT compiler and making it available in the Rotor distribution - you couldn't modify it but it would allow for better performance.

It's interesting to see this effort from Microsoft based on building a community of interested people.  Quotes: 'If you blog it they will come'

I know that Developers aren't renowned for dress sense, but I've seen an alarming number of developers today wearing socks and sandals.  Now there's just no need for this kind of tragic fashion sense.  Just say no.

Tim was talking and Don was typing. I guess Marting was blogging (I couldn't see - I was on the floor at the back with the power outputs).

Aside: recently I've been watching lots of these presenters using Windows Media. It has an excellent - play at 1.4x button that means you can listen to an hours presentation in 43 odd minutes. It's great - the presenter's pauses go away and it's surprisingly understandable. However Tim Ewald is the only guy who this doesn't work for!

You can play at the Raw XML level in SOAP messaging
You can, but it's messy - you have to handle the SOAP processing rules (headers, actors, etc) yourself. The benefits are that you can play in XML rather than object land - you can use transforms, Xath queries etc.

Various ways of using the objects discussed in the first part of the day were mentioned. Essentially similar to Don's MSDN TV presentation.

But working this way in a live demo is hard
Much fun was had trying to map a WSDL schema back into an ASMX page with the correct WebMethod parameters. Don eventually made Tim go back to the PowerPoint slides while he had a go. By now (near the end) they still haven't got it working (showing that this is a hard core thing to do. Evidence: MSDN does it but required Tim Ewald to implement it . This is gratifying, as I spent a night trying to generate my own provider of the Amazon web service so that I could demo the Amazon web service at talks where there was no Internet, but I gave up after a couple of hours hassle.

SoapExtensions
A description of how to use SoapExtensions to ease the problems of processing the Mandatory headers in SOAP messages. See Tim's article Mandatory Headers in ASP.NET Web Services in May 2003 MSDN Magazine

The Do's of .NET Web Services

• Build web services using ASMX - it can support objects or XML focussed web services equally well.
• Enterprise Services are good within your service, but not exposed externally.
• .NET Remoting is for cross-application domains. Ergo, only with two .NET end points.
• Use WSE for advanced protocols support

The Don’ts of .NET Web Services

• Don't use SOAP formatter for .NET Remoting. This seems like an emerging theme of this PDC. Don't wrote "ever" in horror-film style red writing (the pen tool in PowerPoint) after this point. Remoting is about the .NET type system and not interoperability.  It's funny that in this sesssion we're being told about the limitations of Remoting, while upstairs Rocky Lhakota is talking about how to do it.
• Don't marshal object references in ES/COM+. A no brainer.
• Use RPC/encoded in WSDL. See Yasser's article RPC/Literal and Freedom of Choice on MSDN for the rationale (also see my post to the WSE group on why rpc/literal is not supported in .NET).

WSE is 100% Goodness
Tim showed how WSE provide filters in the input/output filter that serialize/deserialize objects and SOAP headers.  They built a sample project that modified the filters that are applied by default.  He also showed how to use the RequestSoapContext inside the ASMX WebMethod and how to set the client up to call this method using WSE.

WS-Addressing
Don mentions that interop with Tibco was one of the motivations.

WS-Security
5 slides, 20 minutes.  Brain is dead now.

The XML and Web Services Perspective continues with Don, Tim and Martin.  Heavy going after lunch,but much better than the first session.  This session had more useful content that matched the audiences level of understanding (a very advanced audience).

The future of Remoting: SoapFormating SOAP stack
SoapFormatter is dead.  It is the one part of the .NET platform that we'd recall if we were available.  It is the SOAP stack underneath .NET remoting.  .NET remoting works in situations where you have .NET on both sides of the pipe ('living the COM dream without reference counting' as Don say). is one part of the .NET platform that we'd recall if we were able to.

What is SOAP about?
SOAP is primarily about extensibility, it is designed to allow us to evolve services.  The service provider and consumer may evolve at different times.  It is important that the server is able to evolve the service without disrupting the established clients.

SOAP 1.2 will be the last version of the protocol.  Ever.
There's wont ever be another version of the SOAP protocol.  SOAP 1.2 is the last version that we will ever need.  Don justifies this with two arguments.  Firstly, no one gets a third chance at it.  SOAP 1.1 is here and will be with us for a long, long time, we wont get rid of it.  SOAP 1.2 is here and we should move to it but this will happen slowly (like the conversion of IPv4 to IPv6).  It wont be practical to support more versions of SOAP.

SOAP 1.2 is in the next version of .NET, would have been in earlier (Windows 2003) if it was in a final state as a specification.

SOAP is not just for serialized object graphs
SOAP can be used to serialize an object graph, but this is a lifestyle choice, a subject decision.  There's nothing about SOAP that says it has to be like this.

SOAP Headers and SOAP 1.2
SOAP has headers that are extensible.  They are meant for the ultimate receiver rather than any intermediaries.  The headers have the mustUnderstand element which means that it must be processed successfully, as well as an actor tag that specifies which intermediary is designed to process the message.

Because the headers must be processed before the body is processed, most of the SOAP stack implementations buffer the headers and then stream the body.

SOAP 1.2 adds the s:relay attribute which means that the header is targeted for the current intermediary, but that it can be ignored.  However, if it isn't processed it shouldn't be removed from the message - it should be passed on to the next intermediary (presumably changing the actor tag on the way).

There's also a well-known URI 'http://schemas.xmlsoap.org/soap/envelope/next' means the next intermediary should process it.  As Don says, 'everyone plays the role of next - it's the Iunkown of SOAP'.

WSDL
Don made us stand up and recite 'WSDL sounds really fun, please tell us how it works'.  WSDL is more difficult.  Don mentions several times that many of the flexibility points in WSDL were because they weren't sure that Web Services would end up using XML Schema as the type descriptions, and SOAP as the binding.  WSDL provides for other type descriptions and bindings, but XML Schema and SOAP are the most common.

Some very funny stuff when they went through Doc/Literal RPC/encoded choices in the WSDL.  Basically at each attribute Don said 'there is no other way'.  Good laugh, obviously everyone in the room understood that document/literal is the way to go.

Don also joked about the '.NET WSDL parser'.  If you run the WSDL.exe tool before adding the binding then if it's successful there will be a 'no classes generated' message, but at least no exception.

AXM Security and Web Services
Tim did some great debugging of IIS and the directory to solve a permissions problem.  When it failed first time, Don made the joke that it was not a failure but was 'locked down by default'.  Don also made the point that the way the problem was attacked was to change the server until the client message came through (through giving anonymous access to the virtual directory), rather than the better approach which is to give the security credentials to the client (through using the proxy object).

Polymorphic data and serialization
Tim made the point that WSDL generation mandates knowledge of all types at compile time.  If you want to use derived types then you have to use the [XmlInclude] attribute so that the SOAP receiver understands where it must look to see if a type has a derivation somewhere.  The alternative is that the SOAP stack would have to look through all of the referenced assemblies.

Wow, my first US PDC lunch.  The meal area is enormous, with teams of waiters running around like Ants.  I had the pleasure of dining with Ian Griffiths and Mathew Adams, authors of the great Programming .NET Windows Forms from O'Reilly.  Ian was one of my interviewers for my current job.  Getting interviewed by an O'Reilly author was certainly intimidating, lucky Ian's a top guy. 

I also saw Robert Hess from the .NET Show (he's looking older these days - I remember the launch of IE 3.0 hosted by him!) and Ingo Rammer around the traps.  Martin Fowler was even having lunch on his own (could this ever happen at a Java/XP/Agile conference?).  Hopefully I'll get the courage to talk to him later in the week (he's on the architecture panel on Thurs.)

Obviously there's a lot of camaraderie between these guys, all having worked at DevelopMentor together in the last millenium. While this adds for a good feeling between audience and presenters there's also an element of pranks and mucking around that sometimes has seemed more fun to the presenters than the audience.

At the most interesting point in the session, where Tim finally got away from the keyboard to talk passionately about Schema, the point was sabotaged by a sniggering Martin and Don typing behind Tim's back on the screen. This was OK, but we didn't get the benefit of hearing the end of Tim's point. I don't mind the presenters having a good time, but not at the expense of the audience.

Note: I missed breakfast this morning which may have contributed to these feelings.

This session was slow-moving in the morning. All of the content has been available on MSDN or shown in MSDN TV episodes (e.g. Passing XML data inside the CLR). However, as a colleague mentioned, the first 2 hours of this talk were the full day of a previous PDC pre-con session, so it shows how things have developed.

Here are some points that stood out:

• The XML stack is built on protocols in the following ways: unicode + uri, XML 1.0, XML Namespaces, XML Infoset, XPath, XML Schema and XSLT/ These map very nicely to System.Text, System.Uri, System.Xml, System.Xml.XPath, System.Xml.XmlSchema, System.Xml.Ssl
• The XmlReader API shows three things that are not part of the XML Infoset specifications:
  - IsEmptyElement (that can tell the difference between <tag></tag> and <tag/>)
  - QuoteChar (returns the quote character used around an attribute, such as single quote ' or double quote ")
  - WhitespaceHandler (gets or sets how the whitespace is handled - an enum that uses All, None or Significant). Tim mentioned this was useful in the MSDN xml work he's been doing.
   
• The XmlWriter is a stack-based approach to writing the XmlDocument.WriteEndDocument will close up any opened elements (stitch the patient up now that the operation is over).
   
• Implementing an XmlReader over data is a difficult job, using it is much easier.
   
• The design of the DOM classes is poor because it was written by people who wrote parsers. Some particularly nasty parts: having to create elements off the document, and having to use ImportNode to bring a document. Don also mentioned that XmlElement.InnerText is a shortcut for XmlDocument.CreateTextNode. It made me feel much, much better to know that Don thinks this was a crap API.
   
• Tim's rules for structuring schema documents: 
  - use BlockDefault="#all" to forbids substitution, extension, restriction
  - use only global elements declarations, so that the one element means the same thing regardless of where it occurs in a document (e.g. <person> means the same thing wherever it is in the XML document). See Ruminations on XML Schema from Don's blog in May.

The flight over seemed to be a good time for some people such as Tim Sneath to trying out noise cancelling headphones.  I'm afraid to admit it but I used the lo-tech ear plugs to get a couple of hours sleep, watched the movies on the back of the chair rather than from the DVD in a laptop and left my laptop in the overhead locker the whole flight.

I enjoyed the luddite pleasure of a good book, Design Patterns Explained.  It's written with Java and C++ in mind, but since C# is Java the examples are a breeze to work through.  It presents a good case of why functional-based programming, where analysis is looking for nouns and verbs to turn into objects and methods, wont cut it anymore.  I recommend the book to anyone looking for a good introduction to Design Patterns.  As they say, sentences like these from the GoF book make sense as individual words, but it's hard to really get what they mean:

Purpose of the Bridge pattern: To decouple an abstraction from its implementation so that the two can vary independently. source

The book does a great job of explaining this.

Random thought: I'd also forgotten how strange US cheese is.  I'm sure cheese isn't naturally orange.

Rather than say thank you to Jeff, I thought I'd honour his wish to see photos of the t-shirts at unique landmarks as we make our way to the PDC:

My appetite has been whetted for Doug Purdy's XmlSerializer presentation 'A tale of two type systems' at the PDC next Tuesday.  I was talking with a customer today about how to version schemas in web services.  It's a problem they haven't addressed yet as everything is still in the first version.

I've seen Doug's TechEd presentation on loosely coupled web services and his MSDN TV episode.  I understand that changing the namespace is not a versioning mechanism - it changes the type system.

Doug's suggestion then was to use the open content model and author version schemas with a version attribute and places in the document where we can put any content.  Then clients can use the switch statement and decide how to handle the message using the highest version number they understand.

What I really miss with this approach is that it loses all of the goodness of schema type checking once the open content elements are used.  It's like you can have schema versioning only for the first version of message, once extra content is added it isn't described or validated.  I like the idea of a schema validation saving me write application code to achieve the same result (or in the case of XML firewalls, having them do the validation).

Radovan argued against this open content approach, saying that subtyping would be better. In his Doug says in his post:

The approaches that I suggest are the best ones using the existing Xml Serialization engine provided in v1 and v1.1 of the Framework. There are ways to "seal" off and extend an open content model in such a way that you don't really need to switch on a version element (although you may want to include the version information in the instance document regardless). But these mechanisms are not supported by the XmlSerializer currently.

I'm really hoping that more schema versioning options will be part of the surprises Doug's got in store in his Tuesday  talk "Indigo": Using XSD, CLR Types, and Serialization in Web Services should be informative.

With the PDC sold-out, the rehearsals ongoing I think it's time to deal with the difficult issues: how to communicate the excitement about the event with loved ones.  Rory has already blogged about spending the night out at a bar thinking about his love for ASP.NET rather than talking with friends. 

Has anyone else found a successful way of communicating the pleasure of new concepts/technologies in development to their partners?  While on holiday last week I re-read Richter's applied .NET and Juval Lowry's fantastic .NET Component Development.  After a great Italian meal and a bottle of house wine I could contain my enthusiasm no longer and bored my pregnant wife with a passionate monologue about the 'fascinating' topic of generational garbage collection.

Does anyone else have any suggestions?

I'm hoping there won’t be too much sighing and spontaneous applause at new product features.  At the first PDC I went to in Australia in 1996 we watched a video of the US keynote where the speaker had to repeatedly stop while the audience applauded at the new features (cross-language debugging I recall).  This level of raw emotion is a bit embarrassing to an Australian audience.  After getting over the initial silence, eventually each applause moment was met with laughter.  Let's keep it in perspective: as good as the technology is, it's just technology and there's still (hopefully) a job for developers to do at the end of the day.

Why is always more important than what ...Technical people are smart and used to figuring out things on their own. ... What they can't figure out is what was going on in your [the designer's] mind when you wrote a feature, and knowing that [the designer's intention] is the most important part.

As an audience we can use this time before Microsoft open the Kimono to start thinking about what Microsoft's strategies are in each of the areas (OS/dev tools/Web Services) and what design challenges they have to think about.  This helps generate questions so that when we're listening to the endless days of PowerPoint we have a reason to listen and engage.  As Dare has mentioned there's plenty of opportunities to ask the Microsoft developers questions at these conferences (like at Tuesday night's Ask the Experts).  Doing some work before hand to develop understanding and frame some questions is a good investment.

Tim Sneath has already started the questioning, asking will Yukon kill the business tier and put in the database?  Mehran isn't convinced, but it is the dialogue that is important. 

Background to Indigo:

• Read the speculations, and more speculations and  work out what is known from the session outlines

• Try and understand the WS-* standards that Indigo will be based on, especially WS-ReliableMessaging.

• Look at the EAI vendors and work out what problems they are currently solving that Indigo will try and solve.  I suggest the CapeClear's whitepapers site especially the Web Services and EAI paper on Web Services technologies and it's impact on applicaiton integration and Web Services Messaging Strategy.  Jorgen Thelin CapeClear's Chief Scientist has recently joined the Indigo team. 

• Get up to speed on the Architectural buzz-words: Message Oriented Middleware (MOM), Service Oriented Architecture (SOA).  Roger Session's latest ObjectWatch newsletter has a crack at defining What is SOA.  Clemens is a great source of information, as is Ingo's recent architecture briefings: 'SOAP is not a remote procedure call' and one on using other message patterns than just request/response.

• Enterprise Integration Patterns - a site by Gregor Hohpe from ThoughtWorks, describing 65 patterns to do with Enterprise Integration in a vendor-neutral way.  Going through this material should help fill us in on the space that Microsoft are trying to move Indigo into.  For example, since we know Indigo is a message bus, why not find out what a message bus is and how they can be usefully used in projects.

Specific questions I've got based on WSE:

• We know that WSE is a small 'bouquet of flowers' for us as developers, but what have Microsoft learned from WSE that they are going to put into Indigo?
• Will Indigo have the same modular, open approach to its architecture as WSE?  Will it be made of the same 'pliable building materials'?
• Gregor mentions that 'config file hell' is a major problem in Enterprise Integration projects.  Will Indigo be doing anything to address this (like WSE's very helpful Visual Studio Add-In and user tools?

Continuing the theme of what the .NET community can benefit from the Java community comes news there will be a version of IntelliJ for C#.  IntelliJ is regarded as the best Java IDE by many people. Here's Martin Fowler's response:

"I know lots of ThoughtWorkers who are dying for this tool. While Visual Studio has a lot of nice features, the programming capabilities seem primitive when you've used a tool like IntelliJ or Eclipse. Of course, I find I really miss the refactoring capabilities, but there's much more than just the refactoring that makes IntelliJ such a stunning tool. Having a tool like this as a plug in to Visual Studio will make .NET programming much better."

I also noticed today that Martin Fowler is coming to the PDC to be part of an architecture discussion panel on What is Service-Oriented Analysis and Design?

Larry O'Brien suggests that Microsoft and Microsoft developers look at what they can learn from the Java community.  The key point for me is when Microsoft will support proper refactoring tools within their development environment.  Martin Fowler, who wrote the first major book on the topic, defines Refactoring as:

“…the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”

When combined with the practice of Test Driven Development (supported by automated testing frameworks like NUnit) Refactoring is an essential tool in any developers tool kit.  If you take the position that software development is a craft then Refactoring is like a painter discovering a new type of brush, or a carpenter discovering a new type of hammer.

The Eclipse project, an IBM backed project to develop a new IDE, they have superb support for refactoring, as shown on their help page.  While there are products available for .NET such as C# Refactory, they are still too buggy to use reliably.  I'm hoping that we'll be seeing the addition of Refactoring to Whidbey at the PDC.  Actually, after Googling on it I found that Alan Dean, fellow UK-based Microsoft Developer and PDC attendee has done the hard work of reading the PDC abstracts which state:

Visual C# "Whidbey" includes improvements to the code editor and debugger that cater to the code-focused needs of the C# developer. With support for refactoring in the code editor, advanced visualizations in the debugger, and more, Visual C# "Whidbey" supplements its modern syntax and component-oriented features with new and powerful productivity-enhancing IDE features. Source

The other point that I enjoyed Larry's article was that Java and Open Source have a much better sense of community:

With GotDotNet and other sites in "The .NET Code Wise Community," Microsoft’s presence is palpable and can be somewhat stifling, like a sanctioned school event where the principal is sitting in a corner reading a magazine.

This is definitely something I notice when visiting the Extreme Tuesday Club in comparison to the Microsoft User Groups.