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.

Steven Maine describes a war story from a colleague about a client-run project using XP Methodologies.  It's a useful warning about the dangers of doing XP without understanding or using all of the practices.  The project Steve's talking about have been going 10 weeks with no releases and 'since the customer is using these so-called “XP methodologies”, there’s no hard and fast documentation as to what the agreed upon scope actually is.' 

In the XP Refactored: The case against XP the authors mention that one of the problems with XP is that it is a high-discipline methodology in that all of the core 12 XP practices need to be implemented if the project is to be successful.  I think the bigger risk with XP is that it's an excuse for crazy style project management (think glorified cowboy coding).  XP is not a methodology that validates projects that have no methodology.  For example the idea is not 'don't do any documentation', it's 'just do the documentation that it necessary'.  I'm not sure that any (sane) person would advocate not having some written form of customer requirements (even if they are just 3 x 5 index cards on a wall).

In the project Steve mentions there's no mention of any of the practices actually being used.  As he identifies:

XP might be great in theory but often times has issues with practical application. However, most horror stories I’ve heard that involve using “XP methodologies” are in fact about problems that stem from using “mostly XP” or “sort of XP”

Steve suggests that focussing on releasing to the customers is an important concept that would have reduced the risk of scope creep.  I agree that it's a good practice, but there's also the concept of the Planning Game, User Stories and the idea of project velocity.  Yesterday I found this  presentation from on how the BBC's interactive TV group used XP/Agile practices to negotiate the scope of projects.  Basically they tracked the project's velocity - how many user stories were being completed each week.  They estimated the cost of the features the customer was asking for and when it was clear the features were too ambitious they re-negotiated.   This is the same concept as principled negotiation that Steve McConnell mentioned years ago in his book Rapid Development

Hopefully this lack of understanding about XP wont rub off on the good ideas that the methodology advocates (especially test first development).  As the software reality site mentions:

Agile proponent Alistair Cockburn describes XP as a "high discipline methodology". In a discussion on the Wiki web, he also suggested that most teams that say they're doing XP don't actually do all the practices.

As XP increases in popularity and hits the mainstream, more and more teams will attempt XP, probably without a clear understanding of what is really involved. They will most likely be drawn in by XP's "low discipline" practices (such as no big up-front design and minimal documentation), but without applying the high discipline practices that act as an essential safety net (such as unit testing, pair programming, collective ownership and constant refactoring).

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.

Here's a good post to the microsoft.web.services.enhancements newsgroup on creating X.509 Certificates with the Open SSL toolkit that can interoperate between WSE and Java.

Open SSL is an open source tool that I've seen used in a couple of production situations and I mean to look into it more.