WS-Addressing is one of the newer WS-* specifications. The specification brings us closer to the reality of sending SOAP messages across multiple transports in an interoperable way. Going down the plumbing level with WS-Addressing helped me highlight the gap between the specification and implementations. Along the way there's a great SOAP Mail sample application using WSE 2.0 that highlights some of the promise of being able to send SOAP messages via HTTP and SMTP ...

There's been lots of talk about offshore development recently.  Larry O'Brien is chatting with John Montgomery about whether he'll still have a job as an independent developer , Rory reports that Dell have moved their call centre back from India.  The pragmatic programmers have released a t-shirt advertising their 'how to keep your job' with the slogan 'My programming job went offshore, and all I got was this lousy T-shirt'.  The current project I'm working on has bought their offshore development team on shore.

On top of all of this I notice today that Chris Stevenson, who's been the source of many good insights into .NET/Java/XP/Agile development at the Extreme Tuesday Club and who is also from my home town of Adelaide, South Australia, is going the other way and is moving to India for 6 months.  Funny old world.  I can't wait to read about Chris' experiences.

 

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.

Roy's at it again, campaigning for IntelliJ and asking Visual Studio to take notice and compete with the advanced developer experience provided by the IntelliJ IDE:

 "I felt like I was not coding alone ... if you decide you should have a new method ... you just type the method name and provide its parameters if necessary.  IDEA will prompt you with an unobtrusive popup with a suggestion to create a new method ... the method will be created in the corresponding class with the proper method signature (including correct parameters), so that you can implement it later"

I saw the same feature demoed by Erich Gamma, (the G in the GoF Patterns book!) when he came to London to talk about Eclipse.  I was so impressed the hairs on my arm stood up.  Forget clapping at the PDC, you know a feature is good when your body reacts with goose bumps.  As I mentioned in a previous post about refactoring, I think this feature would solve a lot of the frustration that Randy mentioned where Visual Studio's Intellisense clobbers any new methods or properties written in tests before the object exists.  It's the difference between thinking of the IDE as a text editor and thinking of it as a developer tool.

Luckily, IntelliJ are developing an IntelliC# add-in for Visual Studio that will bring its intelligence to .NET.  I can't wait to get it.

As Roy laments, what's Visual Studio doing?  I remember the glory days, back when Jim McCarthy (of Dynamics of Software Development fame) was working with the Visual C++ team making the IDE great.  Where's the passion, the spirit, the sense of competition gone?  For all the talk at the PDC there was noticeably little about Orcas, the Visual Studio version after Whidbey.  Visual Studio is good, but it can be even greater.  Let's hope that good things are in store.

Ted Neward has some great advice about how to review a technical manuscript that I wanted to highlight.  I'm using my 4-hour train commute to review a technical book that I'm pretty excited about.  Ted's article was helpful.  He also has a great way of looking at technical books - positioning books as a deal between a book and a reader:

when I write a book, I'm offering the reader a deal: "You trade me $40 of your hard-earned cash and roughly 40-80 hours of your non-refundable time, and in return, I will give you something you didn't have before, some knowledge that you find useful." If my book doesn't keep my end of the bargain, the reader takes it back to the store, but can never get back the time spent, and so is left feeling cheated and upset. In some books, the classics like "Design Patterns", or K&R, or "Rapid Development", the deal is so obviously lopsided in the reader's favor that these books go on people's shelves right next to the monitor, for frequent perusal. But the thing to realize is that it's all about the deal. Does the book fulfil its end of the bargain?

Searching for and finding books that keep their end of the bargain is one of my key passions.

 As Tim Sneath spotted, I did another YAWP (Yet Another WSE Presentation) to the .NET Exchange User Group at Microsoft UK campus in Reading last night.  I'm doing a number of presentations around the UK in the next month (though I think John Bristowe's record of 20 YAWPs a year is safe), details on my presentations page.  Here are my slides and some of my demos. 

Web services are being adopted in the wild
There certainly is a lot of material to cover in web services from the specifications to the implementation, so we only briefly touched on Indigo.  There were 30 or so developers there. Starting with the mandatory 'polling' questions I was surprised that around 60% of them had used web services already.  Of that group about a third had added some form of security (HTTPS, VPN or internal network).  There were some good questions in the group ('Can I use WS-Security in a PHP application?  Will Microsoft compete with Tibco and the EAI vendors with Indigo and/or BizTalk?  Has Don Box stopped using the term GXA?)

Blogs are a great way to learn about Web Services
I mentioned that blogging is a great way of tracking what's happening web services. I showed how:

• Omri Gazitts a PM on the Indigo team, talks about web services attachements and that DIME is still the best choice for today, but MTOM is Microsoft's preferred approach for the future.
• Hervey Wilson, WSE lead developer, has said that WS-ReliableMessaging is coming in a future release of WSE and writes great content about lots of other topics.
• Rebecca Dias, Product Manager for WSE, has mentioned as a result of feedback at the PDC, "Attachments will be abstracted away [in WSE 2.0] so that migration to MTOM will be more seemless(sic)"

How to get started reading blogs
First download a news aggregator like SharpReader or RSSBandit then download my modified OPML file.  It contains many Microsoft bloggers as well as other web service related blogs (including those on Matt Powell's list).

I also promised a link to the code that downloads all of the PDC powerpoint presentations.

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.

With all the recent interest in the refactoring in C# in Whidbey, it's interesting to look at its natural complement, Test Driven Development (TDD).  TDD is one of the best practices to come out of Extreme Programming and Agile Methodologies.  When Refactoring combined with TDD are tools that can fundamentally change how developers work as well as changing the way they design.  This post threads together posts on TDD and Refactoring from a ThoughtWorks and a Microsoft perspective that show the benefits and effects of TDD and Refactoring.

Some ThoughtWorks experience with TDD and Refactoring
Dan North, a ThoughtWorker, has an article in the Java Developers Journal called Test-Driven Development Is Not About Testing,  his major point is that 'it's not about the tests; it's about seeing how little you actually need to do and how cleanly you can do it!'  Jeremy Stell-Smith, also ThoughtWorker, has a reply post TddIsOnlyOnePieceOfThePuzzle where he makes the following statements about TDD:

• TDD is a tactical thing.  It helps developers from adding unnecessary complexity and allows them to think about how the code will be used before other developers use it.
• It's important to refactor while using TDD to reduce duplication to keep the system clean.
• If a system has good automated testing and loose relationships between classes, then tests can give good feedback about the extent of damage that a change to the system might bring.
• Tests work best when they test small isolated areas of functionality that shouldn't break if anything else changes.  For this reason, unit tests are easier to manage that end-to-end integration tests

There are also some points that Jeremy makes that seem a bit 'religious' such as 'changing your mind later is about as expensive as changing it later'.  This just doesn't seem rational, but perhaps I'm just arguing for a shades of grey rather than this black and white style statement.  I know that TDD makes it easier to make a change, or to measure the impact of a change, but it's still better to make changes as early as possible because it is more expensive to make changes later.  However, I think that his assertion that 'tests must be as fine grained as possible so that most changes no matter how radical don't affect many tests' seems a fine goal, but is hard to achieve.

Early Microsoft experience with TDD
Chris Anderson points to Randy, a friend of his within Microsoft who's reflecting on his experience with TDD.  Randy says that it takes a lot of discipline to stop writing code before a test case that uses it and that Visual Studio is a hindrance when working test first because the intellisense stops being helpful when the writing test code for methods that don't yet exist (Roy wrote a good post showing how IntelliJ handles this situation in a much cleverer way, hopefull Microsoft will pick this up and copy extend it).  Randy also talks highlights how TDD can be difficult:

 ... it's a completely different ball game when you're changing the behavior of code as opposed to writing entirely new code. Say you've written a sizable body of code with inter-related classes and non-trivial implementations of whatever. Now suppose you want to make a fundamental change to one of the more central class's behaviors ...  substantial build breaks where methods no longer exist, because the functionality they provided has been made unnecessary ... doing test first in this case is tricky. You can start by changing the test that exercises the fundamental class in the new way, and then changing the fundamental class to pass the test. Unfortunately, then you've got build breaks across your entire project, and fixing those involve work that should also be done in test-first fashion. The way I did this was to exclude all the other files from the project, get the fundamental tests working again, and slowly re-introduce the other functionality, tests first of course, fixing/updating as I go. Maybe it's the same amount of work in the end, but it feels more cumbersome

From my experience and the developers I've talked to at the Extreme Tuesday Club, if the code is difficult to test then it can highlight weaknesses in the design of the code (such as it being too tightly coupled).  Put another way, designing code with testing in mind often leads to code that is better designed.  The pain that Randy highlights when working with inter-related classes encourages a designs that are more loosely-related so that they can be more easily tested. 

Mock Objects is an approach to making testing easier in large complex systems.  As the authors of the definitive paper on Mock Objects say testing can improve code "by preserving encapsulation, reducing global dependencies, and clarifying the interactions between classes."  More on that in a future post.

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.

Chris Sells and Larry O'Brien are both having a crisis of confidence over their role as authors or information providers in the new world of blogging, Google and RSS.  I think its a good time to look at what value they add and what's important in helping developers learn. Says Chris in Time For An Exciting Career In Electronics:

what I'm best at in the whole world has either become completely unnecessary or incredibly easy. The skill that I spent most of the last 10 years learning was to look at a group of types, APIs, reference docs, headers, source code, etc., distill it down to a set of architectural intensions and then to weave a story through the whole thing to make sense of it for developers that weren't able to glean the intensions themselves (most often because they had real jobs). I call this exhaustive search for intention officially at an end. I'm not longer needed except as a gatherer for those not yet facile in RSS aggregators (which, luckily for me, is still a large number : ).

And Larry in 'Being run over by the cluetrain':

With the whole gamut of Internet-based communication (Websites, newsgroups and mailing lists, Google, email, and blogs), the typical path between technical question and answer has become much more direct. ... Independent authors and teachers have traditionally exploited the very inefficiencies that are being paved over by these technologies. The community no longer has the same incentive to pay money for magazines, books, seminars, and mentoring / consulting: they get the same substance faster and cheaper, if perhaps not with the same style, context, and specificity.

The mistake being made here is to think that the value of authors is based around converying factual knowledge.  The advent of encylcopedias didn't reduce the need for teachers.  There's a big difference between transferring information and helping people learn.   I think it's a great thing that technical authors can now move up the tree away from technical answers and onto higher order tasks like helping people learn how to adapt to the new technologies (that seem to be changing every three years).

I also think both of these guys sell themselves short.  Even though Chris knows about the intentions behind the software, there's always a market for someone who can tell a story and transfer this information to others.  At the PDC, most of what Don had to say has been written somewhere else previously, but I'll still pay for the experience of hearing him tell the story.  Heck, I've read most of Chris' online articles, but I still paid for his latest book (I wanted the convenience of the book and I wanted to have him tell me the whole story about windows forms, not just part of it)

I'd  also say the valuable skill that Chris has is not his own deep knowledge of the intent behind APIs, but his ability to transfer this knowledge of the intent to me.  Larry's book has the right idea - 'Thinking in .NET', not 101 code examples.  I want these guys to help me think, and learn how to think about the problem, not just to find the answer.

What's clear to me, after 19 Microsoft Certified Professional exams (including sitting the core MCSD exam for the third time), is that knowledge expires fairly quickly, whereas knowing how to learn continues to pay back.  This is exactly what Chris has written about in Learning How To Learn.  I can't believe he thinks he'll be replaced just because some of the MS tech team are blogging themselves.   Maybe he just needs a hug.

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).