Recently I've been doing a "tour of the trenches", helping a major client with their web-based applications for the Insurance industry. It's taught me that there's a lot of development work that goes on in companies that doesn't relate to the overall aim of delivering business value through software, specifically around the building of "platforms".  Brad Abrams noted something similar when he went on his road trip, there are a lot of companies building custom platforms.

From my experience a lot of these platforms turn out badly since most companies can't afford the time or money to build and create successful platforms.  Rather than writing platforms, I'm looking for ways to use Other Peoples' Code to build solutions that deliver better business value.  At TechEd this week I'm interested in evaluating Office 2007, and particularly the server platform, as a platform to build on.

Looking at the domain of Insurance applications it's easy to see why lots of developers want to write a platform.  The basic flow is similar in structure to many other types of financial trading:

• An application form, with one or more wizard-like pages, containing controls with single- and cross-field validation.
• The application form is sent to a rating engine (usually authored by Underwriters) which determines whether the business will generate a quote and if so, what the value of that quote is.
• After a quote is generated there are various sequential and state-based workflows around that can occur (e.g. accepting the quote, revising the quote, "binding" the quote to make it a policy).

With that in mind I'm currently looking at Office Server 2007 as a possible platform to build on.  Here's a sketch of what I'm looking:

• Create the application form in InfoPath (giving me the single- and cross-field validation), then publish it as a HTML form using Office Forms Server (there was a session at PDC as well).
• Use Excel Services to host the spreadsheet that contains all of the logic for calculating the Quote.  Once we agree on a set of named cells/ranges in the spreadsheet, the underwriters can keep control of it.
• Use SharePoint's support for Workflow to implement the Workflow.

Obviously I'm just sketching at this stage (I still have questions about licensing, performance and flexibility are key) and I need to do some prototyping, but overall I'm interested in the possibility of being able to build basic Insurance trading applications on top of Office 2007 as a platform, dramatically reducing the amount of code I will need to write.

I'm currently pondering whether the new server-side capability of Excel 2007 could radically change the face of many financial application.  Excel is so widely used in finance that many companies could describe it as their platform.  I'm currently involved in writing a web application for a group who use Excel extensively and I frequently think if we could work more harminously with this spreadsheet we could build the application for much lower cost but equal or higher business value.

In the keynote last night they demonstrated the Windows Compute Cluster Server 2003 running Excel Services to perform Monte Carlo simulations using Microsoft Excel.  Initially I thought this was implausible, imagining the response if someone asked, "Can we set up a cluster server in order to run my Excel spreadsheets?", but on reflection I think this could make a great deal of sense.  Even though I'm suspicious about the efficiency of this kind of solution, viewed from a different perspective I think it could represent great business value. 

It's amazing to think that Windows and Office could lead to a scenario where a front-office trader could write software that can be executed in a cluster - an arena that previously seemed the domain of C++ and hard-core developers.  On the one hand it scares me, since there will be less custom C# development for me to do, but on the other hand I like it a lot since re-writing functionality that Excel already implements takes a long time and doesn't give as big a "bang for the buck".

Obviously I need to do a lot more research on Excel Services.  There's a good introduction here and some more technical details on how you can call Excel through web services.

TechEd Boston started Sunday night with Ray Ozzie admonishing us that there's a 'Services Disruption' coming and proposing the slightly tongue-twisting 'Client Server Service Synergy' (and the lesser-used companion phrase 'Client Server Service Symmetry') as the way forward, with Microsoft offering more services in future. 

Ray with the usual dramatic structure of a presentation (much like what is recommended in the "beyond bullets" book), setting up that we're heading for a new disruption in the way that we work.  He did the standard mainframe -> mini computers -> micro computers -> client/server -> the internet ("the mother of all disruptions") -> peer-peer set of disruptions, personalised through his own life experiences with Lotus Notes and Groove. There was the standard argument that we need to be on the lookout for new disruptions.

The drivers that are changing things for today are the promise of multiprocessors (32 to 1000 CPUs inside a single machine - up to "oodles" in Ray's words) the reduction in storage space and the growing ubiquity of bandwidth.  The interesting point that Ray highlighted was the fact that in the past it was research and corporate environments that drove datacentres, whereas today these were being driven by experience with consumer market through search, advertising and consumer shopping sites.  Ray's point was that the benefits of investments in these environments will be felt more widely.

He wasn't terribly specific about how this would happen, though he was trying to position Microsoft's approach as a mix between the client services approach and external services in a "client server service synergy".  He showed windows desktop search searching over the internet, SharePoint sites and the local machine as example of this.  He also showed Microsoft Dynamics using 'business mashups' with Windows Live virtual earth.  He also mentioned the online/offline architecture of Groove.  There was much mention of the Windows Live set of products.  There was a Windows Live Identity that I hadn't heard of before - I'm assuming it's a rename of Passport? It might have been the jetlag but it felt like another moment of marketing fatigue (apparently MOM will become System Server Operations Manager as well).

The presentation hall felt very much like an aircraft hangar and the regular sound of planes overhead reinforced this.  Ray was the first keynote speaker I've seen wearing a suit jacket on one of these talks.  Obviously the chip-implant wasn't powerful enough to convert him to the standard casual 'uniform' of a blue shirt and a pair of chinos.

Developer Developer Developer, the free day-long conference for developers, by developers is back for a third time on Saturday 3 June.  The call for speakers is open.  If you've got a topic that you'd love to share with other developers in the community, please submit a session.

Attendee registration will open later, but you can always view some of the videos from DDD II last October.

Jamie Cansdale's done it again- he's added Test With -> Coverage to the TestDriven.NET Visual Studio add-in.  A picture's worth 1,000 words:

Once the tests are run it launches Grant Drake's (aka KiwiDude) re-write of Jeff Key's NCoverExplorer.  The NCoverExplorer then displays full coverage stats as well as illustrating the coverage of code blocks.   Here's the output from a run over the NUnit code:

This is awesome work that will make it easier to understand and work with code.

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

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

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

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

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

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

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

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

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

Bill's initial comments:

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

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

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

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

Windows Vista Demo

"Clarity" Demos:

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

"Confidence" Demos:

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

Office 12 Demos
Word

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

PowerPoint

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

Outlook

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

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

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

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

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

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

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

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

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

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

names.Sort(String.Compare);

names.ForEach(Console.WriteLine);

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

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

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

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

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

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

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

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

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

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

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

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

Strong bodily reactions are a great way to measure the impact of new technologies.  While many US technical conference crowds like clapping when they see new features demoed, I think the best reaction is a more modest bodily reaction. I'll never forget the time I shivered after seeing Eric Gamma demonstrate the Refactoring support in Eclipse a couple of years ago.  One area of .NET 2.0 that is generating strong bodily feedback is ASP.NET 2.0's support for Custom Build Providers.

First there was Fritz dropping his jaw when he created a custom build provider that took his custom XML metadata file which he dropped into the app_code directory that automatically generated the strongly-typed classes for him.  Tonight I discovered that Kirk Allen Evans had a similarly-sized bodily reaction when he created a Custom Build Provider that automatically created XmlSerializer classes that allows you to drop a schema into the app_code directory and automatically generate the XmlSerializer class.

I'm with these guys: Custom Build Providers are cool (bodily reaction: light goosebumps).  I'm passionate about finding ways of driving application development through the use of metadata files and the Custom Build Providers are an innovative way that ASP.NET provides to support this kind of development.  The only downside I can see is that the creation of these classes is slightly 'automagical' and requires that developers understand what the framework is providing under the covers.  However, I think this initial learning curve is more than compensated for by the productivity that Custom Build providers enable.

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

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

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

Save the date - Saturday 22nd October 2005 is the next DeveloperDeveloperDeveloper day!.  We're planning another free community-driven day of talks on developer-related topics.  Craig Murphy has more details.  Jonathan Hodgson has updated the event website (including a countdown ... 84 days to go!).  There's a form you can fill in if you'd like to present a session.

For now, feel free to join in the discussion on the Channel 9 site.

Bill Wagner, fellow RD, and author of the excellent 'Essential C#' has an article on Code Project that debunks the conventional wisdom that String.Equal is better than Operator == for strings:

... for the string class, Operator == and String.Equal() will always give the same result. Period. You can use either interchangeably without affecting the behavior of your program. Which you pick will depend on your own personal style, and the compile-time types you're working with.

The == operator is strongly typed, and will only compile if both parameters are strings. That implies that there are no casts or conversions inside its implementation.  String.Equal, on the other hand, has multiple overloads.  There is a strongly-typed version, and another version that overrides the System.Object.Equals() method. If you write code that calls the override of the Object version, you will pay a small performance penalty. That penalty comes because there is a (slight) performance hit for the virtual function call, and another (slight) performance hit for the conversion. Of course, if either operand has the compile-time type of object, you'll pay for the conversion costs anyway, so it doesn't much matter.

The bottom line on equality and strings is that if you use the method that matches the compile time types you're working with, you will certainly get the expected behavior, and you'll likely get the best performance. If you want all the details, see Item 9 in Effective C#.

I'm posting this because I've had this discussion a few times and believe that Bill's explanation is the best I've seen.

I'm on the Ask The Experts stand here at TechEd (back tomorrow and Wednesday at 2pm) and the first person I spoke to today asked me how to solve a socket access permission when using a when using a tcp service with WSE 3.0 Tech Preview.  Working through this also answered a second common question people have, which is 'what's the default port number that WSE uses when "soap.tcp://localhost/" is specified as the service address?'.

The exception in questions was:

An attempt was made to access a socket in a way forbidden by its access permissions.

This occurred when I was trying to run the TCPStockService sample application and here are the key lines:

Uri address = new Uri("soap.tcp://localhost/tcpstockservice");
// This starts a TCP-based listener if there isn't one already started.
SoapReceivers.Add(new EndpointReference(address), typeof(StockService));

Digging through reflector it turns out the the constructor of the Microsoft.Web.Services3.Messaging.SoapTcpTransportOptions options sets the defaultPort:

So, 0x1f91 in Hex turns out to be 8081 in decimal, so by default the WSE tcp transport listens on port 8081 if no port is specified.  Now the exception message made more sense, since I had another application listening on port 8081.  Changing the port number, or stopping the process that was listening on port 8081 solved the problem.

Thanks to the MSDN Product Feedback centre I can send a suggestion to improve this error reporting straight through to the product team.

It's been a long time since I last posted.  I've been busy with a mix of presentations, work and life, such as:

• Helping Kalido ship version 8 release 2 of their two core products, the Kalido Dynamic Information Warehouse and the Kalido Master Data Manager. 
• Speaking at the Microsoft UK Architect Council and Architect Forum about Services on the Microsoft Platform today.  You can find the slides on the Connected Systems Architect forum page.
• Presenting to the London .NET User Group on Programming Indigo.
• Facilitating a 'park bench panel' on Smart Client vs Web Development at the Microsoft UK MSDN Roadshow in London.
• Doing plenty of behind-the-scenes or out-in-the-community work with local User Groups.

Some technical topics that have been taking my time:

• We set up CruiseControl.NET in my team at Kalido.  This just rocks.  It monitors source safe for checkins, checks the code out, runs a Nant script (these are great: you can compile the code using a solution file (instead of hassling with the vbc.exe or csc.exe directly) to build the code, then it runs our NUnit tests as well as providing coverage reporting with NCover and even duplicate code checking using Simian.  It all comes together with a tray icon that monitors what's happening on our build server and lets the whole team know if a build fails.  Tracking down the reason for failure is easy since there's a central web page that pulls together the log file from all of the tools (including comments from the source safe checkin box - finally, an easy way to see these comments!).  It's so exciting I'm rambling even while blogging about it.  The key point for me was that it only took one developer a couple of days to set up, even with no previous experience of any of these tools.
• Schema design.  I'm working on a new WSDL interface and have been playing around with various strategies to build the interface most efficiently and effectively.  More on that in future posts.
• Consolas.  Like Scott Hanselman, I love this font.  I've embarrassed myself my gushing about this to colleagues who are less aesthetically inclined than I am.  It's a mono spaced font, which is part of the Longhorn font set, especially designed for reading code on screen.  I've also set it up as the Windows Console Font as well.

I've also been enjoying time with my daughter who's now walking, starting to 'talk' and generally just getting into trouble (I spent last Saturday morning in the accident and emergency section of the local hospital after a walking accident.  The doctor said 'ah, we always see a lot of head injuries from kids who've just learnt to walk').

Around 160 delegates turned out on a sunny warm English Saturday to attend the DeveloperDeveloperDeveloper day.  Judging by the comments on Channel 9 (great to see so many UK people using that site) it seems to have been a great success.  It was great to catch up with so many different people, such as Santosh Benjamin, Phil Winstanley, Ian Cooper, Mike Taulty, Jonathan Hodgson and many other blogless, but nevertheless interesting people.  Simon Harriyott moblogged the event and was kind enough to give me a lift back into Reading.  He also continued his analysis of Australian accents in IT ("data down under").

Although I enjoyed giving my talk 'Web Services in .NET 2.0: Solving Today's Problems' I made a fundamental mistake of staying up too late the night before the talk.  Filled with the pleasure of finally having Visual Studio 2005 installed on my laptop (Jon Rowett caught the bug as well), I got carried away crafting a flashy demo with streaming JPEG images (using IXmlSerializable) and databinding to the results of the webservice calls.  As a result I was 'dog tired' as Ian Smith noticed and didn't present as well as I would have liked.  Dave Oliver wasn't so sure of the value of using IXmlSerializable to stream a large file over web services.  Lesson learnt.  Next time I'll get a good night's sleep and focus on small, easy to understand demonstrations.

The highlight of the sessions for me was seeing Brian Long go through .NET debugging capabilities.  He obviously had a command of the topic, managed to demo the command line debuggers for an hour without a single typo and had a great dry sense of humour.  He's done a lot of talks with the Developers Group here in the UK, which came out of the Borland Developers Group.  I love the fact that the .NET community has benefited from so many people with Delphi experience. 

To finish, Jon Rowett has a good write-up of the day as does Dave Oliver and Richard says "All in all, a very worthwhile way to spend a Saturday - the kind of training day that usually would cost the best part of £1000 per participant. Something I’d definitely do again if the opportunity arose."

Thanks again to Craig Murphy for taking the lead in organising the event and Jonathan Hodgson for doing the website.

If you like a free day of training on Microsoft technologies presented directly by developers with experience using technologies then sign up for the DeveloperDeveloperDeveloper day that's being held on Saturday 14 May at Microsoft's Thames Valley Park campus.  Don't wait to sign up - we're 75% full already and based on similar events in the US we're likely to sell out completely.  Microsoft have graciously provided the venue and are handling the registration and logistics, but all of the speakers are independent community developers! The www.developerday.co.uk site has a full overview of the event, the agenda and sessions and the speakers involved.

There are three different tracks with 6 presentations in each.  Here are a sample of some the talks from developers I know that I'm looking forward to:

• Alex Homer and Dave Sussman will be talking on SQL 2005 and another secret topic
• Ian Cooper, who runs the London .NET User Group, on Patterns of Data Access in .NET (here are my notes from a previous version of this talk I heard)
• Phil Winstanley, ASP.NET MVP, will be talking about preparing for ASP.NET 2.0
• Craig Murphy, Jedi Scrum Master and XML Web Services MVP, on Managing Iterative Development with Scrum
• I'll be covering What's new with Web Services in .NET 2.0.

I'm also looking forward to hearing about custom attributes in .NET, refactoring, test driven development, debugging tips and writing custom FxCop rules.

As well as the presentations it's also a great chance to network with other .NET developers.  For instance, I know that Jamie Cansdale is likely to be there, so if you've got any questions/comments for him on his fantastic TestDriven.NET addin there's an opportunity.

A big thanks to Mike Ormond and his team (Mike Pelton who first posted about the event) for providing the venue and logistics support.

I've just landed back in the UK after a three-week round the world holiday to Australia and back via Redmond for the Indigo Software Design Review (SDR) last week.  The SDR gave me a chance to play with a slightly updated Indigo build than the publicly available Indigo Community Technical Preview.  I was going to list the highlights of my week but then I saw that Omri Gazitts, from the Indigo Team, posted a list of his favourite Indigo features that maps pretty closely to what I was going to mention.  My key take-away was that the team have done a great job designing Indigo so that it is feature-rich and easy to use with good extensibility points throughout the system.

While I've been away Mike Taulty (Layers of Indigo, IInputChannel and IRequestChannel, Channel encoding and filtering messages) and William Tay (Message Tracing, Logging and Activity Management and the details of the default Indigo bindings) have both been doing some excellent job of kicking the Indigo tyres and exploring the CTP builds.

I'll write more when I get a fresh VPC image installed with the CTP bits.

As Rebecca Dias mentions, my article ("Why WSE") covering the high-level reasons to use WS-Security has been published on MSDN.  It covers the provides benefits WSE provides, such as end-to-end message-level security, content-based routing, and policy through leveraging the WS-Security, WS-Addressing, and WS-Policy specifications. 

Let Rebecca know what you think of it.

If you want a longer article on the same material I'd recommend fellow-RD and web services enthusiast, William Tay's piece on Solving Real World Business Problems with Web Services Enhancements in .NET

Microsoft Research in Cambridge have released the WSE Policy Advisor for Microsoft Web Services Enhancements (WSE) 2.0.  The Policy Advisor is an an unsupported tool that acts as a security diagnosis tool for WSE2 policy files (think of it as an FxCop for web service security policy files).  It analyses the policy file for common security vulnerabilities, provides a description on the risk and remedial advice.  It can be launched as a stand alone application or from the policy tab of the WSE Settings Visual Studio add in.  If you are intersted in WSE 2.0 and Policy then  download the Policy Advisor and run it against the sample files that ship with WSE 2.0 and send the research team feedback.

I've been a fan of using policy files to secure web services with WSE for a long time.  As Clemens says, authoring a policy file by hand is pushing things too far.  In combination with the WSE Settings add-in the Policy Advisor provides a great service for anyone wanting to understand and apply policy files, without having to get too focused on the XML angle brackets. The help file contains a list of all the problems the Policy Advisor can detect and is an excellent learning resource if you want to learn about the purpose of many of the policy elements.  For example:

This policy accepts messages with unauthenticated or elements. (Alarm)
Risk: The message is authenticated, but authentication does not cover and . Those elements are often used to implement replay protection, and should thus be authenticated. Otherwise, an attacker may intercept a message and generate a series of slightly different messages that will be accepted as distinct, genuine messages from the original sender. (The risk may be mitigated if the transport provides integrity protection, or if the recipient implements replay protection using other authenticated elements.)
Advice: Insert wse:Timestamp() and wsp:Header(wsa:MessageID) in the element in the assertion.

It also has warnings about the evil that using unencrypted UsernameTokens, though I'd highlight Keith Brown's excellent MSDN article on Securing the Username Tokens with WSE 2.0 as the best source of guidance in this area.

Here's how the tool integrates with the WSE Settings Visual Studio addin:

Below is a screenshot of the report that the Policy Advisor produces, in this case it is reporting against the secure conversation sample that ships with WSE 2.0.  The top part of the window describes the report, the bottom tree view highlights all of the issues found and the relevant policy for each problem.

Seeing Google maps today helped me realise the power of the browser as a cross-platform development environment.  I believe that the combination of client side callbacks with DHTML and JavaScript dramatically reduce the need for Java Applets or ActiveX controls in web-based applications.

The problems usually levelled at browser-based applications are that they lack the responsiveness and rich interaction experience provided by traditional forms-based applications.   I think the Google apps (Google Suggest, GMail and now Google Maps) prove this point wrong.

I was in a discussion at work today where a colleague was arguing that any browser-based application requiring rich drag-and-drop and data entry grids would have to use ActiveX controls or Java applets.  However I think that developments over recent years in cross-browser support are showing that this kind of functionality can be achieved in the browser.

Here are some links that convinced me further:

• This amazing cross-browser JavaScript DHTML API, Drag & Drop for Images and Layers.  It's a 38KB file that supports drag and drop (including making the image semi-transparent while being dragged) and a whole range of other commands.
• The ability to retrieve new data into a web page without having to refresh described in this overview of the XML HTTP Request Object and its cross-browser support (all wrapped up nicely in ASP.NET 2.0's support for client side callbacks).  What makes me laugh is how this functionality was originally provided through the Microsoft XMLHTTP object from MSXML but Mozilla and Safari have copied it with an XMLHttpRequest object - who said that IE wasn't innovative?
• A range of commercial DHTML grids such as ActiveWidget's Grid 1.0, including this sample showing editing.

I can't wait to see more development around these technologies (I'd really love FreeTextBox to use client side callbacks to autosave my blog posts to save me from losing so many posts!).

As Christian Nagel notes the INETA Europe - UK and Ireland web page launched today, including the new INETA UK and Ireland Regional Speaker Bureau.  The Regional Speaker Bureau is a collection of technology experts and highly-rated speakers who are now available to present at regional User Group events.   If you’re in the UK or Ireland and would like to hear any of these people speak at your User Group then tell your User Group co-ordinator to contact me or let me know directly (benjaminm at benjaminm.net).

INETA already has a European Speakers Bureau, but to highlight the local talent and encourage more events we’ve established the INETA UK and Ireland Regional Speakers Bureau.  This group includes:

• Peter Blackburn – SQL Server MVP co-author of Hitchhiker's Guide to SQL Server 2000 Reporting Services, currently receiving a 5-star review on amazon.com
• Jonathan Greensted – ASP.NET MVP
• Ian Griffiths – C# MVP, Technical Author and an expert on Avalon
• Rob McDonald – Technical Author, internal trainer to Microsoft and founder of co-founder of DevTrain and highly-rated conference speaker.
• Benjamin Mitchell – Regional Director
• Graham Parker – VB.NET MVP and retiring chairman of VBUG

These speakers are on top of the three existing UK members of the INETA European Speaker Bureau:

• Alex Homer – ASP.NET MVP, Technical Author, Conference Presenter
• Richard Grimes – Visual C++ MVP, Technical Author, Conference Presenter
• David Sussman – ASP.NET MVP, Technical Author, Conference Presenter

This work is part of my role as the INETA User Group Liaison for the UK and Ireland which I’ve been doing since late last year.  My aim is to further improve the .NET Community in this corner of the world by ensuring the regional User Groups get access to great speakers for their meetings.  If you know of a great speaker who’s not on the list (we’re currently looking for MVPs, MCTs, Technical Authors or anyone with a proven track-record of great presentations), or you are interested in speaking at User Group events yourself, let me know.

Mark Fussell, the WSE Program Manager posts that since the MTOM specification has moved to a full recommendation it means that it can be implemented in WSE 3.0.  This is great as it means that we'll have a way of solving the problem of how to send binary data in an efficient, interoperable way that plays nicely with the other WS-* specs .

For anyone who wants to take the pulse of the UK .NET bloggers, James Crowley who runs the Developer Fusion site, has put together a page of aggregated UK Developer blogs, with an RSS feed as well.

Ian Cooper gave a presentation last night's London .NET User Group on Data Mapping Patterns in .NET.  He explained many of the patterns from Martin Fowler's book Patterns of Enterprise Application Architecture.  He started with the basic Transaction Script pattern through to the Table Model and finally the Domain Model.  Along the way he demoed the Data Access Application Block (which to my surprise, only half the audience admitted knowing about).

I enjoyed seeing many of these patterns shown in action using nHibernate.  I haven't looked at the ORM frameworks for a while and was pleased to see how far things have developed.  Ian recommended the book 'Hibernate in Aciton' by Christian Bauer and Gavin King as a good introduction.  You can read a sample chapter and a book review on theserverside.com.

Ian's main point was that you should look to use nHibernate or another existing ORM tool rather than writing your own (avoid the ORM Vietnam issue that Ted Neward mentions), but to be careful not to see ORM tools as a hammer that makes all problems look nails.

Graham Parker, the retiring VBUG Chairman, was on before Ian talking about Java and .NET Interoperability.  I missed the start of the session but there was lot of good discussion from the attendees.  A large number of people  were aware of the Mono project and it's recent developments such as support for ASP.NET, Windows.Forms and ADO.NET.  There was also discussion about how Source Forge Source Gear are using Mono for their Vault commercial product.

Max Kington chipped in from the floor with a number of good insights based on his experience with Java.  I had a good chat with him afterwards on a range of topics from grid computing, web services to his claim that '2005 is the year of the domain specific language'.

All up another good LDNUG event.  Ingo Rammer is going to speak at the next event on Wednesday 23 February!

John Lam, together with Dominic Baier, shows how to implement a hex encoded SHA1 hash of a password plus a scope URI, as suggested by Keith Brown an improvement over WSE's default password handling for UserNameTokens.  Nice work.

In a recent Opinari email (I can't find it on his website), David Chappell defends his belief reuse is one the fundamental benefits of Service-Oriented Architecture and that SOA will be more successful than previous approaches such as object-oriented or component-oriented development.  His rationale is that services operate at a higher level of reuse than binary classes, and they solve many of the human problems that prevent reuse, such as having to have one single view of business entities and forcing reuse through 'draconian' human policies.

Here's my summary of his three major arguments:

1. Service orientation will lead to better reuse of business-oriented software because it is about sharing application functionality at a higher level than binary classes:
   • Evidence for this comes from the fact that the most successful examples of business reuse comes from packaged applications such as SAP and PeopleSoft
   • Attempts to share business classes, such as San Francisco, haven't been successful.
2. Previous approaches to re-use have failed due to human reasons rather than technology:
   • It is hard to agree on a definition of a business entity, such as customer. 
   • Even if there is agreement about the 'one right view' then it is likely to change over time.
   • It is difficult to force developers to reuse software - given a choice (or allowed to get away with it) most developers will reinvent rather than re-use.  Where reuse has been achieved with previous technologies, it was mostly through 'coercive management structures'
3. Service-orientation overcomes some of the human issues involved with reuse because:
   • Services don't require a single definition of business entity, just conformance with a particular schema. A service-consuming application may have a different view of a business entity as long as it can map to the service's view of that business entity.
   • Services can better handle changes over time.  Service-boundaries are a better way of insulating consuming applications from changes to the internal implementation than base classes and binary inheritance as there is a cleaner separation of external interface from internal implementation.
   • Since services are more explicit with their boundaries, and often these boundaries are physical, it is harder for developers to find ways around them.  This is similar to Clemens' point that well designed services do not share databases.  David's argument is that these design decisions make it easier to enforce reuse.

I like his focus on the human problems that plague reuse.  I also agree that sharing schema is a better approach than sharing class (part of the four tenets of service-orientation), and that using interfaces rather than inheritance leads to more flexibility to cope with change over time (a well-known principle).   I find the argument that service-orientation will make re-use easier to enforce less persuasive, since this seems more to do with deployment than the design philosophy (a component-oriented application could also reuse components that encapsulated a private database).

Scott Guthrie has written an excellent post about the ASP.NET 2.0 development process and the steps to Beta 2 and a 'go live' license.  This is an interesting post on two levels.  First, I love learning about how Microsoft builds software (I love the game of shipping of software and finding out ways to improve it).  Second, I think ASP.NET is an incredible product and am excited about being able to 'use it anger' (as they say in the UK) soon.

Here are my notes on the key concepts from Scott's post.  It's interesting to compare the ASP.NET 2.0 process to Hervey's description of the WSE 2.0 process.

Zero Bug Bounce (ZBB).  A point where there are no open bugs for a particular milestone that are older than 48 hours.  The point is "to push teams to sustain a high rate of bug fixing over a period of time". The present goals is to avoid pushing any bugs past Beta 2, meaning that there will be a true zero bugs bounce occurring.  There is a lot more information on the ZBB concept: Eric Gunnerson provides a definition,  Ron from the Visual C++ team talks about the three types of bounce, Larry Osterman a long-term Microosftie talks about it in the context of Zero Defects and it's also part of the Microsoft Solutions Framework (MSF).

Regression Rates.  For the managed code parts of ASP.NET the 'regression rate is around 4% -- meaning approximately 1 in 20 fixes introduces a new bug in the product'

Bug Rates.  The test team opened 514 bugs last week, and the dev team closed 648 bugs.

Automated Testing.  The team has 102,000 test cases(!).  Automated FxCop runs are done over the product.  There are two levels of check in test suites.  There are base-level unit test coverage of the product prior to checkin that have a block level code coverage of around 64% and take several hours to run.  More extensive tests are run each night and take around 12 hours to run.

Checkin process.  All code is peer-reviewed (even for senior devs).

Security push.  After the ZBB returns to zero there is:

'an in-depth multi-week security analysis of the code in the product … The goal at the end is to feel confident that the product is solid and ready to be attacked by thousands of hackers out there while running on the Internet.'

Tell and Ask Mode
In Tell mode any team is allowed to fix whichever bug they wish, but they have to be able to stand up and justify their decision to the 'central division ship room'.  This helps slow the rate of checkins, which reduces the chance of regression issues, helping the quality of the code base increase.

Ask mode means that the central division ship room must give permission to make a change.  During this mode, the stress testing can continue.  The low rate of checkins makes it easier to identify the source of stress-test failures.

Go Live License. Scott mentions that Beta 2 will provide the first 'go live' license.  I can't wait for this to happen.

Another thing I think is admirable is that the ASP.NET 2.0 release seems pretty close to what Scott mentioned back in January as Chris Garty clarified off my notes from Scott's presentation.  Although they have had to cut and descope some features (See this article from Jonathan Goodyear, fellow RD) the team look like they've done pretty well sticking to schedule.

In an interview with Mary Joe Foley, Joel Spolsky says that Indigo will make building applications easier, but it won't lead to a whole new class of applications.

If you look at the different aspects [of Longhorn], like Indigo, I'm not really even interested. It's just a big communications architecture that makes it easier for programmers to build communications things. But there's no application you can't build right now because you don't have a good communications architecture. It might be harder (without it), but it's not going to enable you to build a whole new class of applications.

I think there is some truth in this statement.  As Steve Swartz has said, Indigo is a replacement of the infrastructure and an evolution of the programming model, through simplification and a unification.   As Clemens has demonstrated that you can use existing Microsoft technologies (ASMX, MSMQ, Enterprise Services, and Remoting) to do many interesting things today.  If you need to build a service oriented application it’s worth starting today and not holding off until Indigo arrives.  However, I think Joel underplays the benefits of making the programming model for service oriented applications simpler. 

The problem with building service oriented applications today is that it takes talented developers, like Clemens to do them.  As Don has mentioned, one of Indigo's goals is to make things so easy that he will have to join MS to survive. 

The applications that are developed on Indigo may not be ‘a whole new class of applications’ (though I think it’s highly likely that the killer apps of the future will be based on top of communication technologies), but the fact they are easier to develop them should lead to more of these types of applications being developed.  This is in the same way that VB enabled an increased number of COM applications that could have been built with C++.  It’s an interesting argument as to whether VB lead to ‘a whole new class of applications’ being developed.

There are several questions that I still have about the impact of Indigo:

• Where will the business imperative to build applications that communicate more come from?  Is it that there is a demand today but businesses aren’t developing the applications because of the technical cost? 
• Will the increased ease of development encourage businesses to build applications that they haven’t considered building today?
• Will the pool of distributed application developers increase, or will Indigo just be adopted by the developers who are already building distributed applications?
• Will the increased simplicity of Indigo mean that the architectural concepts behind service orientation will be more widely used?  For example, I’m puzzled as to why MSMQ doesn’t get more love – message queuing is an important architectural design and MSMQ works very well with a very simple programming API – but I don’t see it used as widely as I think it could be.

Thoughts? Comments?

Here are the code samples I used my webcast on WSE Messaging last Monday.  The webcast will be available for download from this link soon [update: it's available by clicking on the register button and getting through the login page].

Here’s the code from the demonstrations.  The major sample – a suggestion service – is based around Keith Ballinger’s talk at TechEd San Diego and my version of this talk at TechEd The sample shows:

• A Windows Form client that sends a message to an ASMX web service.
• The webservice logs the message to a file, before sending a one-way message onto another Manager service using WSE’s support for sending SOAP messages over TCP
• The Manager Service is hosted in a Windows Form client that receives the message using the WSE ISoapInputChannel and its in-memory queue.  This means the messages aren’t displayed until the manager explicitly requests them.  The Manager Service also acts as a publisher of these messages to any service that has subscribed.  The implementation shows a simple Publish/Subscribe model using SoapServer/SoapClient.  When the messages are retrieved from the memory queue they are published to all of the subscribers.
• The Boss Eventing Service is the final Windows Form client.  It sends a Subscription message to the Manager Service and receives notifications when the Manager Service retrieves a new message.

Other resources I mentioned/recommend:

• I thoroughly recommend Aaron Skonnard's Hands On Lab on WSE Messaging (available on this page).  It provides some great walk-throughs showing all of the key features of WSE messaging (including how to build your own lightweight chat app using SOAP over TCP).
• Simon Horrell's MSDN article on WSE and messaging.
• For a full-blown WS-Eventing implementation, check out John Bristowe and Co's Plumbwork Orange project on GotDotNet.

Simon Guest lists his top 10 tips for web services interoperability between .NET and IBM WebSphere and BEA WebLogic [via Christian Weyer who comments that things will points will go away with .NET 2.0, see his series 'The web service empire strikes back' for more details]

The command pattern allows you to wrap a command inside an object so that you can pass it to another object to execute that object.  We were using a simplified version of the pattern where we had a command interface that has an Execute method and a Results property to retrieve the results:

public interface ICommand

{

      void Execute();

      string Result{ get; }

}

Objects of this type are then passed in as an IList to a CommandExecutor that loops through the commands and calls Execute on each one:

public class CommandExecutor

{

      public void Execute(IList commands)

      {

            // loop through the commands and

            // call the command.Execute method

      }

}

So we wanted to write a test that ensured that the Execute method was called on each command that we provided to the CommandExecutor.  Initially we thought about sending through a concrete Command (say a ConcatenationCommand) and determining that the result was what we expected.  However, this would have coupled our design to that particular Command - if we made a change to the results that returned we would have to update our tests.  In this case we aren't concerned about the actual result, just that Execute is called on each command.  The question was how can we test this behaviour without having to worry about a concrete Command or its result?

This is where Mock objects come in (see the original Mock paper or the Pragmatic Programmer's overview).  They allow you to test the behaviour of an object rather than just its outcome.  The idea is to create a 'fake' or stub object that validates the object was used in the way we expected.  In our case we could create a MockCommand that derives from ICommand.  We could provide a boolean property - ExecuteWasCalled - on the class that could be set inside the execute command.

public class MockCommand : ICommand

{

      public bool ExecuteWasCalled;

      public void Execute()

      { ExecuteWasCalled = true; }

      public string Result { get { return "result"; }}

}

While this would work fine, since our needs are pretty simple in this case we could use NMock which provides a way of creating a DynamicMock object based on an Interface.  The DynamicMock exposes a property that can set expectations about the behaviour of an object, such as a particular method being called.  The DyanmicMock object also has a MockInstance method that returns an instance of the Interface. Using this technique saves us having to create a concrete Mock command.  Here's the resulting code:

While I still have reservations about the extent to which MockObjects are useful, I think that NMock and its DynamicMocks are a useful technique to quickly produce loosely coupled test code.

If you'd like to understand more about how to do messaging in WSE and would like to see the  three levels of messaging within WSE in action then why not register for my first MSDN webcast here?.  I'm going to be presenting it on Mon 9 Aug at 1PM EST (GMT -8). 

I'll be covering some of the demos from the Keith Ballinger presentation from TechEd San Diego that I presented in Amsterdam, along with some new material.  Here's the abstract:

Using messaging systems to support application functionality allows technical solutions to better match business problems.  WSE 2.0 provides messaging implementations that range from low-level explicit messaging through to high-level, more transparent models.  This webcast demonstrates various messaging levels within WSE including a custom WS-Eventing sample and how message, network addresses, intermediaries and queues need to become first-class citizens of your application. Learn how messaging can enable you to create powerful web services applications that cross machine and network boundaries.

I've put these details on my updated presentations page as well.

Dave Bettin writes about his experiences doing a user group presentation on Indigo.  His main disappointment was that few attendees seemed to know about Indigo or the existing ASMX web services in .NET.  This got me thinking about how to get the message out about distributed apps, service-orientation and Indigo.  Is it the case that most developers need to be educated about the benefits of scalable, distributed, service-oriented apps or is it that they don't need these approaches to solve their business problems?

Dave's feedback is similar to Clemens' experience earlier in the year, where he spoke of the difficulties selling the relevance of Indigo today before he settled on explaining the 'why' over the how.  Both Dave and Clemens' experienced the same difficulty making the connection between Indigo and developers' jobs today.  Clemens' says that one of the barriers is that people think Indigo is only going to be relevant for 'Big Apps', when in fact it will be important to anyone who builds apps that expose functionality to other apps. 

One argument is that in order to get more interest in Indigo we need to educating developers about the benefits of services and distributed apps and get them to stop writing monolithic apps and start separating the logic across tiers and services.  We need to teach them more about the benefits of the services and distributed application approach, such as scalability.  Sam Gentile touched on this sentiment when he wrote that most .NET developers don't grok distributed computing. 

The other position regarding evangelising Indigo is mentioned by Alex Lowe in a comment on Clemens' post, is that:

Of course, we know that in the real world there are lots of applications that don't expose functionality to other applications. There are plenty of line of business applications for small and medium businesses that don't require ASMX, Remoting, and in the future Indigo.

Alex also has a summary post on his position where he says that the number of applications that need (and by extension, developers) that actually need to know about how to architect scalable applications is low.  He argues that bloggers are a distorted sample because they represent the group that need to build scalable distributed applications and they are generally well up on things.

I'm interested what other people think.  Is the problem that most developers don't understand the benefits of service-oriented distributed applications or is it that most developers are writing apps that wouldn't benefit from service-oriented distributed applications?  What business application scenarios are most likely to benefit from adopting service-orientation and Indigo?

private ISoapInputChannel channel = null;
private void Form1_Load(object sender, System.EventArgs e)
{
   // Get our channel that's listening for incoming messages
   channel = SoapTransport.StaticGetInputChannel(
      new Uri("soap.tcp://localhost:8088/admin"),
      SoapChannelCapabilities.ActivelyListening);
}

private void button1_Click(object sender, System.EventArgs e)
{
   // When we're ready, process the messages off the in-memory queue
   SoapEnvelope message = channel.Receive();
   String messageBody =
      message.GetBodyObject(typeof(String)) as String;
   this.listBox1.Items.Add( messageBody );
}

In the Form_Load event the channel is retrieved from the SoapTransport.StaticGetInputChannel method, based on the channel listening on a particular network address (in this case using tcp) with particular capabilities (the options are ActivitelyListening, meaning the channel should create a listener at that address, or None, meaning the channel should connect to an existing listener).  As messages are received they are placed in an in-memory queue managed by this channel.  When the Button_Click event is fired the next message can be retrieved from the channel by calling the Receive() method which returns a SoapEnvelope from which the body can be unpacked.

I hosted a lively session on what Service Orientated Architecture really means at TechEd Amsterdam.  While it was a Birds of a Feather session, I decided to run it as a park bench format in order to take advantage of having David Chappell, Michele Leroux Bustamante and John Hooper (blogless MCS UK Architect) come to the session.  Here were some of the interesting discussion points that came up:

• There was some agreement that SOA is a pragmatic marketing term that unites many existing architectural principles around SOAP. 
• The closest agreement about a definition for SOA was that it was based around common architectural principles of encapsulation, loose coupling and messaging.
• There was some discussion about whether asynchronous messaging was a necessary part of service orientation. My feeling is that since you can achieve synchronous patterns over asynchronous communications that having asynchronous messaging capabilities is extremely useful.
• Although it's possible that these principles could be applied without SOAP, it's the fact that Microsoft, IBM, BEA and others have agreed that SOAP will be the lowest common denominator that is the pragmatic reason behind the current push for SOA.
• David made a point that service orientation will be whatever Indigo supports when it ships.  Shipping software always wins.  I think there's a lot of merit in this argument, but to the extent that SOA is based on generic architectural principles it is worth considering using these principles in systems that are design today (as Clemens demonstrated all conference).  If SOA principles help solve your business problems today then it's definitely worth starting today rather than waiting for Indigo.
• Some delegates were suspicious that using Indigo would enable them to interoperate with other systems that didn't use Indigo.  There was some confusion about the idea that Indigo will provide an object model that can be used to develop a system that has the capability to send messages between the systems that are based on interoperable WS-* specifications.
• The four tenets of service orientation are necessary but not sufficient for a system to be considered a service oriented architecture.  Some people thought they were too technologically focussed because they were tied too closely to XML technologies.
• David mentioned that the best SOA installation he'd seen was using CORBA several years ago - it had support for finding services, common schemas etc.  Michele backed up the need for shared industry schemas based on some of her experienced.
• John Hooper was interested in Pat Helland's assertion that services should not share transactions, which led into the difference between WS-Transactions (classic two-phase commit) and WS-BusinessActivity (compensating transactions).
• A delegate who was learning about the topic came up to the chairs and spoke about what he'd learnt at TechEd.  This was great to hear and generated a lot of discussion.  Clemens' presentations clearly had some impact with many in the audience.

Here's me with David Chappell after the session.  I've been a fan of his since reading Understanding ActiveX and OLE when I started Microsoft programming.

Clemens' session on his ProseWare application at TechEd Amsterdam last week was one of the best conference sessions I've seen.  Proseware is "an industrial-strength, robust, service-oriented example application that newtelligence has designed and implemented for Microsoft".  The application clearly demonstrates how to go about building services today with currently shipping technology, reinforcing that there's no need to wait for Indigo to start building service oriented apps!  I'm hoping that we see a public release of these bits soon on MSDN.

Points that grabbed me:

• Guidance on where to use messaging patterns: Use the OneWay pattern where there is no intelligent immediate reply or no reply is needed, use Request Response pattern where a message asks a question that can be answered immediately (in under a second) and use the Duplex pattern when a message asks a question that can be answered later as the service has capacity (e.g. anything that takes over a second).
• Clemens showed how to achieving 'near enough' reliable web services with HTTP and services that use MSMQ transactional queues behind the service interface.  If there were any problems placing the message onto the queue then an exception would be returned inside a SOAP fault response.  He optimised this further by using a void response type on the web service method, even though it was not marked as OneWay, so that if there were no problems placing the message on the queue then the web service response message would be small.
• ProseWare is based around a repository of XML schema files which he uses to dynamically generated the 'message' classes in the application using pre-build steps.
• All of the service projects shared these schemas rather than having any project references linking to the binaries (services are autonomous).
• The pre-build step inserts ISerializable attributes onto the message classes so that they can work with Remoting.
• These message classes are used as the only input parameter to all of the public web service methods.  These classes leverage XML Schema's support for allowing any element or any attributes to come through, which is a powerful way of allowing for future extension to the message.  Dare goes through this in one of his previous posts.  The XML Serialization attributes look similar to this:

[System.Xml.Serialization.XmlAnyElementAttribute()]
public System.Xml.XmlElement[] Any;

[System.Xml.Serialization.XmlAnyAttributeAttribute()]
public System.Xml.XmlAttribute[] AnyAttr;

• Clemens showed how to use the properties in COM+ 1.5 in XP/2003 to set the home directory for an application, meaning it is possible to use a .NET config file to store the config. He's blogged about this previously here and here.
• He created his own object pool to create something similar to the ADO connection pooling but for COM+ objects.  He simply pops a component out of the pool and pushes it back when he's done, avoiding the excessive overhead when calling new in a COM+ environment (which has to create the pipeline connections).  He has also blogged about this JIT activation pooling here and here.
• He mentioned how LRPC, which is used under the covers in ES, is the fastest way to go cross-process on a single machine.  In order to get this benefit you need to use the JIT activation pooling in order to avoid having the performance gains wiped out by the cost of creating ServicedComponents (again, something Clemens' previously blogged).
• The nice part was that Clemens had done the hard yards and built an application installer that handled created the SQL Server and Windows user and group accounts.  He even showed where he'd found bugs in the OS and how he'd had to work around them.  Information like this is priceless (well, worth a lot of contracting dollars) if you're ever working in a situation where you need to achieve these outcomes.

Should we write test code against interfaces or something more abstract than the implementation?
James mentioned that MBUnit is a tool that allows you to test against an interface.  The question was whether you should create interfaces that enable tests to be written against them in case further implementations were created in future.  James' attitude was that this might result in wasted work ('you aint gonna need it') since you may not need it, or may not need it now.  Instead, abstract things out when you need them - don't create an interface just to test it.

James also said that an interface is not a good example of the contract of what is being done - it is the name of the method with input and outputs, but does not reflect how the method reacts to the input. James writes tests that show the real interaction between someone that calls the code and what it produces.

How much of the class should we test? Public methods only or protected and private methods as well?
Around a third of the group thought you should test protected and private methods, about another third thought that we should only test public methods.

The arguments for testing internal and protected methods:

• To ensure that the internals work. One delegate mentioned writing a test before each internal method. Someone else said the start with the public method then refactor and hide the method by turning it private.
• Another argument was An argument is that if you write a granular class with lots of private methods, then the tests should be just as granular as the thing being tested.
• The internals are the most important as they contain the biggest areas of logic, so they should be tested directly.

The argument for testing public methods:

• Private method tests inhibit refactoring - you have to refactor your tests with a change, increasing the burden and making it less likely that the tests are updaed.
• You may need to test all of the scenarios from the real world against the public method. If your class is written well then the private methods should be tested.
• If you separate the tests from the production code then you must test the public methods.
• Using public methods gives you a clear limit to the number of unit tests that you need. Public tests will get most of the issues, there's no payback from more investment by testing private and internals.

James says that there is no winning this argument. He favors testing the public interface because it decouples the test from the implementation which will discourage refactoring. However, there are cases where it doesn't make sense to expose something just to test it. He thinks it is 80/20 or 90/10 favouring testing through the public interface.

Whidbey will have friend assemblies that allow developer's to split two assemblies, this other assembly is akin to being inside the same assembly. You can do this today with a multi-module assembly built through the command line, not through Visual Studio.

How do we introduce Unit Tests to a 'legacy system' without tests?
No one in the session had seen legacy code that is easy to test if the testing hasn't been thought of upfront.  One person mentioned that they created tests for each issue logged through the help desk and then used these as a regression suite.  This also demonstrated the value of unit testing to their organisation.

James suggested drawing a line around a piece of the code that you need to change. Test it's external behaviour, make changes and ensure the tests still run. They aren't unit tests, but who cares? Create a boundary, create tests and then change. The key point was to conserve effort and only write tests on things that you are going to change.

James also mentioned a book to be published in September by Michael Feathers called 'Working Effectively With Legacy Code' that describes how to handle this difficult situation.

How to convince people to do test first? Argue against the concept that it will take too long to write the tests first?
One delegate mentioned that this is hard because the best way to convince people is to show results, which requires a practical example, which means you have to know how to do it (what classes, how to unit testing). It takes time and experience but it will work eventually.

Someone else mentioned the green bar of success (my favourite) on the screen is a big part of demonstrating it.

You have to make sure the person has the right mindset. Not everyone has a zero-defect mindset. They want to write tests more than write code.

James says the story is not about the individual developer who wrote the code and knows it works. It is about the team and the ongoing evolution and maintenance is where the tests matter. How can you be confident of your result without them? With unit tests I know they works, before I relied on something else, but now I know.

Why should we write the tests first?
James says that no one will take my word for it. What convinces people is having to test something that hasn't been created with testing as a priority. If a setup method has 20 lines of code and many objects being created and only contains a single assertion - it wasn't written with testing in mind. Someone will say it is really hard to test it.  So the next question is 'What would you do differently?'  The answer to this question is what people should do in Test First.

James said that he believes that testing has to be seen as a primary part of development. We have to incorporate test inside development. There may be QA, but they start at a different level. You have to incorporate testing as part of development.

In the PAG group they have 2,000 unit tests that get run against the library every time someone modifies the code. When James talked to the testing and QA group who do integration testing -they didn't know what to do - the unit tests did the easy part of the testing. They have to start at a higher, more complex level to start thinking about critiquing what is going on rather than I just pass 32,000 characters in a web app and it breaks. These are necessary tests, but it doesn't take a lot of skill to do these types of tests.

Someone made the point that software development lags behind electronic engineering where hardware must be tested first.

James mentioned that studies have show that Test First is 16% longer, but the quality was much higher.

How do you test a function that is dependant on other objects or libraries?
One delegate mentioned that using Dynamic Mock objects relied on finding a sweet spot.  They are useful with objects that have relationships, but the problem is that if you refactor your code then it is highly likely that a whole slew of tests that will break.  The problem is compounded with dynamic mocks since you only see this at run time rather than compile. It works well at mocking the database, but not the more dynamic

James described mock objects as the situation where object A interacts with objects B and you need some way of 'switching out' Object B to create a 'dummy response' from the calls of Object A.

James believed that if you are interacting with something complex, building the simulation of something that is complex is a worthless activity - you spend more time writing the simulator than the test and it doesn't tell you anything? Just because my mocks work, does my real system function?  James uses a rule that if mock objects have an if statement inside them then that's too far - the behavior is too complicated and there's no value (it says there are multiple situations). They do have value, but we need to separate a simulator and a mock object. For example, writing a mock JDBC implementation - that is way too complicated.  Be skeptical of spending a lot of time spending time building MockObjects.

Someone asked - 'Don't you think that it depends on the situation?' James: "I could answer everything that way"

James mentioned the Inversion of Control pattern - this is the a situation where object A depends on object B - the developer wants to be able to switch object B out as a mock or a stub - how can we do that? Inversion of control says you create the dependent object B, or a mock or stub external to object A and then pass it into object A as a interface parameter in a constructor. That's a lot of complexity to add to the initialization,  James was interested in opinions about whether the complexity is worth it?  He mentioned that some people have pushed back on the idea because of the complexity of the construction - if all you are doing this for testability (it also decouples the design) then it is too much work?  He believes that what has to happen is that we need different language structures and we will never get there if we dismiss these ideas now. In the Java world there are lots of work being done on using containers in another way.

How do you we test the database? Where do you get your data for testing? How do you unit test things that involve the database?
James thought that the problem with the database is similar to the MockObjects. It is a lot of effort to Mock out the database. Sometime it is easier to use the database than mock, you need a database to run the unit tests and you have to fill the database, read in a dump, which takes longer and is more effort.

James' experience is that at some point you write tests against the database because he wants to test that the Data Access Layer works. When he write DAL tests he uses the database. But he don't use the DB for anything that uses the DAL - he mocks them out. A technique he use to ensure he's written good unit testing is to deliberately break something and see the results.  If he finds a cascade of errors, it means he hasn't isolated the tests correctly.  He also mentioned that if he comes back to an a feature afterwards and spend a lot of time in QA it means he didn't do well enough with the tests.

With databases,  it is a good idea to  use a transaction and rollback the transaction at the end of it to ensure that.  There was some discussion about how to construct database tests.  The problem with building the database in scripts the unit tests take too long and they wont be run. How long is too long?

How long should the tests take?
There were a range of experiences including:

• Four or five machines run it each product, it takes 6 hours across machines.
• Someone else has developer tests and then smoke and build tests, it can take a long time in the nightly build.
• Another project had two CruiseControl systems that built at different intervals, running a short and long set of tests.

James thinks an hour is too long - the reason is that ideally you would be able to get very quick work around. This is how it works successfully. Waiting an hour for the feedback means that a developer could only make 8 or 10 changes a day. In that hour a number of things are accumulated. James mentioned his experience on an early project where it took 12 hours to recompile that application.  In this project if someone made a change to a header file in C++  they had to recompile, so what they'd do is create global static variables instead of the header to ensure it works before 'doing it correctly' (which was never done). Sorting out problems was very complex because it was effectively an integration nightmare..

Should all developers run all tests? It depends on the architecture - if there are subsystems you could do that. In XP it says all of the tests all of the time. James' group run 2000 tests in 340 seconds against 3 databases.

How do you manage dependence tests with the database? How to restore state with persistent storage.
It is a good idea to stub out the system so that you can test against something that you depend upon. Then when the implementation is delivered you can run the tests and it becomes clear where there is an integration problem.

One delegate spoke of how he stubs out the system, then write tests and implementation, then the stubs are removed and the real implementation of the rest of the tests are done. The platform should support this - James mentioned a project where he used 'linker polymorphism' - relied on the linker to substitute.  Another delegate said they had written something that as part of the the daily build checks out the project file, it changes the XML structure of the C# project to switch references and changes them to the actual assemblies.

How do you test concurrency? Multithreading?
These are just really hard. Testing timing problems with unit testing are hard. One delegate spoke about how he had written unit tests for a multithreaded apps and said it was one of the best examples to convince others of the value of unit tests. It took 2 months to create, but then it only took 1 day to shift it from Java to C#.

The xUnit tools should support this but don't make it any easier.

Another delegate used a timer library and extended the Nunit assertion.

Roadmap for MS
VS Team System will include unit testing support some time next year. It will have a number of integrated testing tools. The keynote yesterday showed a tool 'very much like' and 'subtly' different tool to Nunit. James will be talking about the difference.

There are load testing tools, web testing tools in there. It is a team system that is extensible by many different partners. Many partners, such as CompuWare (did a functional UI testing), doing stuff inside this 'platform' that can be extended.

Someone will write something that will allow Nunit to execute in this environment.

How do you generate tests?
Team system will create a stub test from the code. These are just boiler plate - it doesn't do analysis of the running code and propose a 'good test'

One delegate had a poor experience with a tool that created tests automatically because the tests didn't take into account the intention of the class which resulted in the tests failing. Writing the test manually is more useful as these can act as a specification for the class.

James thinks looking at the implementation to drive the tests is looking at it the wrong way. If you wrote the implementation wrong and then create tests off these, what's the value? The tests should say 'this is what the implementation should do'

People often propose this if they haven't done unit testing before.

How do you test distributed applications?
It relies on subsystems - just write tests that test the local machine, when you have to integrate it all together you might need to run tests, but these are not unit tests in this situation.

How do you unit test GUIs?
One delegate used Rational Robot - costs a fortune. If you are careful and script it then you can get away for a few builds without it breaking. SendKeys was also used.  Another person just avoided the problem by trying to get all of the functionality out, recognising that it is hard to test the UI.  Someone said that it is hard to test drag-and-drop operations.

James menioned that Robot is not good to drive development because they require the UI to be done, but it is hard to do.  NUnit Forms and NUnit ASP were also mentioned.

What frameworks can you recommend?
Nunit, csUnit, mbUnit, CLRUnit
HarnessIt (commercial)
Xunity (Commercial)

How do you do Web unit testing?
HttpUnit works, but it is Java, these can be used successfully to drive HTTP requests and do some testing on the HTML that is returned.
They suffer from many of the brittleness problems that the robot testing does - you have to use id's on the elements - but it requires a lot of thinking about how you output.

David Chappell presented a barn-storming presentation based on the idea that the future is services, that services will be called by business processes and that we need to look for a platform that will manage business processes.  He argues, convincingly that we can't expect App Servers to perform this role.  The answer comes with Business Process Platforms.  Here he positions BizTalk 2004 as the answer and goes so far as to claim that it will be the major product at future TechEd's and that getting close to business processes (through BizTalk) could be a key part of keeping your job as a developer since business processes are much harder to outsource than simple services.  You can also read David's whitepaper on BizTalk 2004.

Application Evolution
There are four waves of applications: Mainframe, client/server, multi-teir and now service oriented.  They share the idea that there is a database at the back end, but the key with services, it that they are designed with the idea they can be consumed by other applications, not just humans.  The reason why we can have services today is that we have web services  - an agreement on soap and other specs - amongst all of the vendors.  It's a huge change that we are at the start of - 4th generation.

Soap is like TCP for applications.  It took years between the start of TCP and its ubiquity: the same will happen with SOAP and web services.  It may be five years away.

To think of SOA as just about soap is folly - the reality is that going forward we will see some apps exposing their services via SOAP, but we will also see other diverse ways.  Not all apps will be SOAP.

Who calls services?
SOA talks a lot about how to build about how to define and build services and miss the point of 'who is going to call these services?'

David proposes three groups: UI (portal, asp, jsp, win forms etc), other services (we will have composite services) and business process (some central business process platform that will manage relationships between services).

The need for a Business Process Platform
Where should we build these business processes?  Is it in an app server such as J2EE container?  No, an app server all by itself is not the right place to build service-oriented service.

We are seeing a new kind of platform designed to support business processes.  In other architecture shifts we've seen new platforms - mainframe to client services produced RAD tools, the shift to tiered apps produced App Servers, and now with services we need to support business processes that drives services.

Requirements of a Business Process Platform
What do we need from a business process platform? Something that manages communications with other applications, business process implementation, scalability, modifiable business rules, process monitoring, tools for working with trading partners, cross-app authenticaiton, human interaction with business processes.

Rules change much faster than processes change - so separate out the rules from the processes.

Business Processes: Your job may depend on them
Business processes are more immune from outsourcing than the services.  So as developers we have to start caring more about business processes.  In five years time we'll need to be closer to the business or move to Bangalore.

BizTalk: A Business Process Platform
David mentioned that he had previously avoided BizTalk because he thought integration was messy, boring and 'on the side'.  However, he thinks it will move to the centre of application development.  If you believe in the move to service orientation then you have to believe that business processes that drive those processes are fundamental, therefore BizTalk will be the centre of it all.  It is about to go mainstream as the service-oriented world becomes a reality.

It's not about B2B and EAI.  These are just subsets of the larger space of business processes. 

BizTalk Engine
This is built fundamentally built around the concept of a message.  It doesn't mean only asynch, you can use RPC, but what is processed here is messages.  The incoming message comes in and is processed by a receive adapter - software that knows how to talk to a service or application (there are lots).  Here is the difference between AppServers.  AppServers just support SOAP, but not the diversity of communication technologies.

The message is processed by a receive pipeline.  It does many things, including converting it to XML. The message then comes into a MessageBox (a SQL Server database) that other engine parts subscribed to (e.g. show me all messages from this organisation).  An orchestration (the BizTalk term for a business process) retrieves the message.  It may publish a response to the MessageBox, then back through a send pipeline and a send adaptor.

BizTalk Adapters
Microsoft provides adaptors for MQSeries, SOAP and SAP.  You can make your own or buy them.

Tools
Platforms need tools.  You can build your own adaptors in the Microsoft.BizTalk.Adapter.Framework namespace (notice, a namespace, demonstrating it is a .NET application).  There's also a pipeline designer, biztalk editor (used to create XSD schemas) and a mapper (mappings and xslt transformations between schemas).

Some customers are simply happy with the mapper.

Process implementation with BizTalk Orchestration
Orchestrations compile into .NET assemblies.  It has simple shapes like if-then-else statements, loop, send, receive and parallel actions.  The process logic is simple and doesn't require a high-powered language (e.g. you don't need C# or VB.NET).  Using a graphical language is a decision that Microsoft and many others have done.

Another advantage of a graphical language is that you can use it to communicate with people that understand the business domain.

This visual language can also be authored in Viso for use by Business Analysts.  This is something that will grow over time.

Orchestrations are another reason for preferring Business Process Platforms over AppServers (which implement processes through lower level code rather than graphical representations).

State
Business processes involve people, so state may need to be maintained for a very long period of time.  So we can't use in-memory.  The Business Process platform needs to manage it.  BizTalk does this by storing state automatically and reloading it if needed.

Scope
Business processes involve transactions over long periods of time.  So BizTalk avoids locks (services shouldn't let others take locks on their data), it uses long running transactions that use compensation.  Biztalk uses scopes to manage transactions that can be atomic or long-running.

Correlation
If I send two purchase orders to a service (ERP app), how can I get the correct invoice response from the service?  You can't use request response synchronous calls because the real world doesn't work that way.  So you put in a GUID in the message, but how would this work if you can't alter the response from the service?  You could match on particular fields.  This is what BizTalk does - you define fields that should be used to match responses. 

Scalability Support
BizTalk host instances enable request to be automatically load balanced across orchestrations and MessageBoxes.

Modifiable Business Rules with the Business Rules Engine
Rules change more rapidly than processes - it makes sense to separate them.  If you are building a business process in BizTalk then you can bake process and rules together in an orchestration.  However, if your process has volatile rules, you can build the process as an orchestration and put the rules in a set of rules defined by the rules engine.  This is worth doing so that you can change and redeploy the rules easier than deploying the orchestration.

BizTalk provides a business rule composer that allows business rules to be expressed in a more natural way.  You define terms (sort of like creating an object model) and then the business process rules (like script glues object models into an app).

Process Monitoring with Health and Activity Tracking
There are two levels of monitoring: technical  and business level.  The Health and Activity monitoring tool (HAT) shows the technical side.  The business level if Business Activity Monitoring (BAM) that shows real-time information about running processes (as separate from Business Intelligence data, which is not real time). BAM is based on views on a tracking application.  Business people can use Excel to do this, developers have interfaces they can use.

The Goal: Business Process Management
There's no agreement yet on what a Business Process platform should have, but we are getting a picture.  It has to communicate with other apps, scale out, support business process implementations, workflow with human beings, modifiable business rules and process monitoring.  BizTalk 2004 is Microsoft's implementation of this.

Why is SOA more well known that BPM (Business Process Management)?  Names are confusing in this case, but there's a change coming to the way we build software.  It implies more than SOAP, it requires service for building business processes.  Biztalk is a founation for building, managing and monitoring business process, in the world today and the service oriented world to come.

Pat Helland's just finished a great presentation on services (a highly polished of the version he gave at the PDC and in other locations available online).  The highlight was him singing 'Mr CIO Guy' - a 'speculative retrospective' based on what the future could look like if the Harvard Business Review's article stating that there was no more competitive advantage in having IT were true - all to the tune of American Pie by Don McLean.  Don Box was on bass and David Chappell was on piano.   It received a standing ovation from the audience (a first for TechEd?).

The video will be available on www.pathelland.com in a couple of days.

They keynote started with 6,000 attendees finding african drums on their seats.  To paraphrase Apocalypse Now, "I love the smell of animal hide in the morning".  A group of drummers from South Africa warmed the audience up with some massage (not successful) and drumming (much more successful).  It was more exercise than some delegates in a long time.  The sound of 6000 drums around the room was an excellent start.  They were used instead of clapping to respond to cool announcements.

Accessibility

An interesting demo followed by a blind computer user, showing how special software drives an external Braille device.  Combined with screen reading software it allows him to use the computer.  Interesting demo that showed how frustrating it is to navigate web pages (even those sites designed with accessibility in mind) for blind users.

What's coming in future

The main keynote showed what was coming in the Yukon timeframe of 2006 including Windows 2003 R2, Visual Studio 2005 and SQL Server 2005.  The Longhorn timeframe was shown as 2008 (or in somewhat difficult to understand maths, "in the next 2 to 3 years").  These include Longhorn Client and Server, Office 12, and Visual Studio Orcas.

The other messages was that the focus is now on platforms, frameworks, interop and EAI tools.  So we're no longer about being a specific language developer, or just a system admin.  Now it's a more holistic view based around the 'lifecycle' (bingo!)

Visual Studio Team System Demo

A quick demo of the code coverage, unit testing and static analysis tools along with the 'whitehorse' designers.  The presenter mentioned that the Team System enables you to develop SOA (bingo!) applications.  This confused me as SOA is mostly about the design of external interfaces rather than the deployment of the application within a trust boundary.

Visual Studio Express Edition

See my previous post.

Deployment

Dynamic Systems initiative.  This allows the system to be modelled, check it against the virtual description of the environment and validate the application.  This will be part of MOM 2005, System Centre 2005 (the new SMS that integrates them all).  In Longhorn there will be one integrated management tools.

Virtual Server 2005.  Host multiple servers on the one box.  This will allow parallel test environment alongside production.  Over time there will be true virtual Windows support from Microsoft.

Voice over IP

The CommNet here has Dell machines with phone handsets that can be used to make free phone calls anywhere in the world.  It was also shown how this can intergrate with outlook to record calls and make notes that were associated with the call.  I love this kind of integration.

Mobile Development

Two guys came dressed as full-size Windows Smartphone and Pocket PC devices (what is it with these guys and costumes?) and they created a smartphone application in Visual Studio that could post a photo to their Windows Moble blog.  They showed how to use the Windows Mobile Platform and Visual Studio to build an app that posts a blog entry from a mobile phone by calling a web service.  They then uploaded the app to a central website so that users can purchase and download it via a mobile.  It downloaded and installed on the handset.  They took a photo, the handset added the location information automatically.  You can see the post here.

Jim Gray

Jim Gray spoke about Skyserver.sdss.org The goal is to get the data from one telescope online.  There is 5 years of data from scanning the sky, with the full map to be completed in 2007 (It's 10 billion records and over 2 TB in size).  It can be used by teachers and students to learn about astronomy and computational data mining.  It uses a web service (displayed in a web page).  Jim showed how these images can be inverted and can call out significant features of the image.  You can see this in action here.   It also allows for custom SQL Select statements to query the data.

They are trying to federate these archives and put it into a query.  It's skyquery that publishes a schema web service and a data query web service.  They all talk to the portal, the portal determines which of the 15 centres should answer it.  Does a query plan across repositories.  Demoed a 'transcontinental query' across Baltimore, Cambridge.  Determines the plan in the first call, executes it in the second. http://www.skyquery.net/

Jim also talked about how the answers needed to be stored in partial form.  They allow people to create databases on the portal server that can store answers queries that take a couple of days.

A second project was about CERN.  It is building an enormous accelarator in 2007.  It produces a Gig of data a second (this is the result of screening out the Terrabyte per second of original data!).    They are looking at using 64-bit processors and 10GB internet.  http://ultralight.caltech.edu.edu/lsr-winhec/  They are doing a CD per second (7.1 Gbps) at this stage with Windows 2003 64 bit version.  Disk to disk is up to 450MBps.

The big announcement from TechEd Europe is that there will be 'nominally' priced Express Editions of Visual Studio for hobbyists, students and enthusiasts, including the replacement for SQL MSDE, available in beta from the end of this week. 

Microsoft have realised that they need to make Visual Studio more available to those who want to learn to write application (perhaps not professionals).  All of the major languages will have Express Editions with Visual Studio (C#, VB.NET, C++, J#) as well as SQL Server 2005.

They will be available at a nominal low price that will not be a barrier to getting into programming windows.  As Joel said last week - Microsoft will basically give the development tools for free.

SQL 2005 Express is the replacement for MSDE.  This will be free for download from the end of this week (some more audience drumming drumming).

The focus is learning how to program, evaluate .NET, interact with students and build cool apps.

They all come with a starter kit that contains samples.  The VB one allows you to catalogue the DVD collection.  It uses Amazon's web service to pull down the artwork and details of a DVD (nice!).  The edition shows all of the standard controls.  It also ships with code snippets.  Edit and continue is also enabled (big drumming!)

The MSDN content is now going to search MSDN, MSDN online and the codewise community sites.

Strangely the demo showed the presenter copying and pasting (cargo cultist anyone?) including all sorts of declare statements to enable an image to work as the desktop background.

The intellisense will now offer to fix problems (e.g. missing trailing ')') and offer to add them for you.  Finally.  The demo also showed VB's My feature to enable quicker access to functionality.

Darrell Norton writes a review of Debugging the Development Process.  This is my all time favourite book on what the Program Manager role at Microsoft involves.  I gave it to a friend in Sydney a few years ago who was so impressed that he took a day off work to read it cover-to-cover.

It was one of three "essential reading " early MS Press books that also included:

• Code Complete by Steve McConnell (Edition 2.0 is out now).  Sam Gentile raves about this book.  I love it too.  In fact, I bought this book before I started developing professionally because I was so interested in the material.
• Dynamics of Software Development by Jim McCarthy.  The most interesting psychological take on development I've read (with great concepts like "Don't go dark" and "Don't flip the bozo bit").  David Gristwood from MS UK is presenting on concepts from this book at TechEd Amsterdam and has a reprint of Jim's article '21 Rules of Thumb - How Microsoft Develops its software'.

Before blogs these books were the only way to get close and find out more about how Microsoft develops software.

After writing about how WSE 2.0 can use policy and config files to secure web services with no lines of code, I was thinking about how 'magic' it seemed and had an aha! moment when I realised that this demonstrated the power of the Pipes and Filters pattern or aspect-oriented style approaches.  I believe that these approaches will play an important role in service-oriented applications in future.  Here are some recent quotes that back this up.

In my post about using Policy with WSE to create secure web services with no lines of code, I mentioned that this seemed like a good practical demonstration of an aspect-like approach, similar to the Pipes and Filters patterns from Gregor's book.  The policy filters are hooked into the incoming and outgoing messages pipelines are able to ensure that messages to and from the service conform to a particular policy, including retrieving tokens and signing and encrypting.  This means that the security of the service can be configured outside the service code, making for cleaner implementations.

Harry Pierson mentions that WS-Policy is aspect-like in his interview on TheServerSide.NET:

We do a lot of thinking around aspects in Web services, we just don’t call them aspects Web services, we call the Policy. All of the work around Policy is very aspect-like. If you’re spinning up a Web services with Web services enhancements, the new 2.0 stuff, there’s a Policy that defines, okay, if you want to talk to me, you have to be encrypted and digitally signed ... now I can communicate that to whomever is sending me a message. ... the WS-I engine can actually now say, okay, I’m expecting messages that [are signed and ecnrypted]  so I can actually enforce to make sure that those things have actually occurred before it ever reaches the business logic. So, that’s very aspect-like, and that’s going to be very critical going forward around service oriented architecture

Ted Neward writes about a recent presentation on Shadowfax and mentions it uses the concept of a pipeline of interceptors. He mentions that Shadowfax uses this approach to deliver functionality such as tracing, authorization, duplicate detection, instrumentation, authentication, authorizations and transactions.  Chris Garty started an interesting thread about this on the Shadowfax message board, where it was revealed that the Shadowfax team spent some time Gregor Kiczales (one of the creators of AspectJ).

This same pipeline/interception approach has been used in WSE, ASP.NET, Remoting and COM+.  Indigo will implement the same kind of approach using Channels and ChannelProviders.  I'm going to keep reading around this area to understand more about this approach and where it how it can be used successfully.

Celebrating the launch of the Web Service Enhancements (WSE) 2.0 at Tech·Ed 2004, Benjamin Mitchell and John Bristowe talk about the advanced Web services specifications that it supports, focusing on WS-Security.

I'll be on .NET Rocks! tonight talking about WSE 2.0 and building web services with Microsoft technology today.  I'll be joined by fellow Regional Director and Commonwealth Citizen, John Bristowe.  If you can't listen live, it should be available streaming on Monday.

Update: As Carl has mentioned, the streaming/download version of the show has been posted.

my previous post, Mark Naughton asked an excellent question about how he'd apply WSE 2.0 security to a particular scenario.  The answer highlights how to determine which SecurityToken to use in your environment, how to encrypt a UsernameToken with an X509 certificates with code and policy as well as handling authorization with X509 certificates and determining how to distinguish tokens received by a service.

Martin's scenario

An End User uses a Web-based UI Application (ASP.NET 1.1).
The Web Application talks to a Web Service (ASMX) for data storage and other processing.
The Web Service needs to identify the End User and the "direct" calling application (The Web UI App), since there may be more than one "direct" calling application.
We also want to sign and encrypt the Soap messages in both directions.

Since we're talking about adding security to a web service, we'll need WSE 2.0 installed on all of the calling applications. 

What's the best SecurityToken to use?
The first thing to consider is what SecurityTokens are applicable to the scenario.  Aside from custom xml or binary tokens, the three options that WSE supports out of the box are as follows.

Username Name and Password

• For - easy to construct, no distribution problems, WSE handles automatic Windows authentication and the construction of the SecurityToken.Principal for authorization.
• Against - on their own they are only as secure as the passwords.

X509 Certificate

• For - cryptographically strong, can carry extra information (e.g. certificate name). 
• Against - need to manage the distribution to clients.

Kerberos Ticket

• For - powerful cryptographically, inbuilt WSE support for authentication and creating the SecurityToken.Principal for authorization.
• Against - your application and the service you access must be running on computers joined to a Kerberos realm (e.g. not good over the Internet) unless you implement a custom security token service to issue service tickets.

So any of these tokens can identify the end user or the application - it's a matter of working out which one works best for your situation.  If you can handle the distribution and installation of X509 certificates to all of the calling applications, I'd suggest using them to sign and encrypt the message.  In your scenario, the ASP.NET web server could create a UsernameToken to represent the End User of your web application.  For best security, I'd suggest encrypting the UsernameToken with the X509 certificate (hiding the username and password/password digest).

The code would look something like this:

// ... Assume we have an X509SecurityToken and a UsernameToken, and a reference to the web service called proxy.

// Add both tokens to the SOAP envelope

proxy.RequestSoapContext.Security.Tokens.Add( x509token );

proxy.RequestSoapContext.Security.Tokens.Add( usernameToken );

/* Encrypt the username token with the X509 token.

 When encrypting, WSE looks for XML elements with an Id attribute from the http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd namespace, which the username token uses.

The "#" indicates the Id with this value is local to this message */

proxy.RequestSoapContext.Security.Elements.Add(new EncryptedData( x509token, "#" + usernameToken.Id ));

// Encrypt the message body with the X509 token to ensure no one can read it.

proxy.RequestSoapContext.Security.Elements.Add(new EncryptedData( x509token ));

// Sign the message with the X509 token to ensure its integrity

proxy.RequestSoapContext.Security.Elements.Add(new MessageSignature( x509token ));

You'll also need to decide on what token type to use when sending the signed and encrypted response.  Again, I'd recommend using an X509 certificate for the most cryptographically strong security.  The downside is that you'll need to install the certificate on each of the clients.  If you can't handle this install requirement then you are stuck with UsernameTokens.

Distinguishing the tokens on the service
Using the combination of a UsernameToken and an X509SecurityToken to represent the identity of the end user of the calling application and the identity of the calling application itself makes it easy for the web service to work out which token is which.  The web service has to search through the tokens in the RequestSoapContext.Security.Tokens collection to locate each token.  If you decided to use two username tokens for example, you would need to distinguish them somehow.  For username tokens you could achieve this through the username values, or perhaps by giving them well-know identifiers in their securityToken.Id property.  For X509 certificates you could use the certificate name.

Performing authorization
If you use a UsernameToken encrypted with the X509SecurityToken, and you don't want to send the password as plain text, then you'll need to create your own UsernameTokenManager.  This is responsible for authenticating the user and creating the SecurityToken.Principal object which can be used for authorization.  For the X509SecurityToken you can create a custom X509SecurityTokenManager and in the AuthenticateToken method, after calling the base class's implementation, then create your own generic principal and attach this to the SecurityToken.Principal (Ingo Rammer wrote an excellent article on this last September for MSDN, but it's disappeared.  You can find my notes on it here).  The benefit of doing this is, rather than just testing for the certificate name inside the service code, is that WSE Policy validation input filters inspect the SecurityToken.Principal when verifying the policy assertion.

Wrapping it all up with policy
As I've indicated in previous posts, using policy and configuration to avoid writing security code within your service is an excellent idea.   You could do that in this situation as well, except that signing the username token is a little tricky to indicate in policy (you'd have to hand-craft the policy XML file as this is a little way-off the WSE Security Settings Tool territory).   In a confidentiality assertion you'd need to modify the MessageParts elements in the policy file to indicate the UsernameToken's Id attribute.  I'll leave this as an exercise to the reader (as my daughter is about to wake up again), but Aaron Skonnard shows how you can use XPath 1.0 to achieve this in his excellent article, WS-Policy and WSE 2.0 Assertion Handlers.

Mehran Nikoo mentions the new Thames Valley User Group - looks interesting:

If you live/work near Thames Valley Park then this is for you.

The kick-off meeting is at Microsoft Campus on June 21st. Scott Guthrie (co-founder of ASP.net) and Mike Ormond (Microsoft DPE team) are among the speakers.

My TechEd conference-buddy John Bristowe has a blow-by-blow account of my CTS302 Securing Web Services with WSE 2.0 session at Teched.  Michael Earls has some notes and a couple of photos from the repeat session (which was a little fast because it turned out to be 45 minutes rather than an hour).  Aaron Skonnard mentions my first session in his TechEd trip report on his new PluralSight blog:

Benjamin Mitchell's session on Web services security using WSE was excellent. His was the clearest presentation I've seen on general security concepts along with concrete code examples.

That's going straight to the pool room. 

After covering so many other peoples' talks it feels strange to read coverage of my own talk.

In the last post I showed how it takes only 1 line of code to ensure that a web service client signs all messages with a UsernameToken by creating a send-side policy with the WSE 2.0 Security Settings Tool.  In this post I show the same feat can be achieved with an X509Token without writing a single line of code.  I also show how this functionality powers WSE's support for automatic secure conversation without having to write any code, something that blew me away the first time I saw it.

X509Tokens can be located through Policy and Config
In the last post I covered how the PolicyEnforcementOutputFilter checks the send-side policy when processing output messages through the Pipeline and attempts to find a matching token to fulfil the policy.  In the case of UsernameTokens, this means searching the SoapContext.Security.Tokens collection or looking in the PolicyEnforcementTokenCache (hence the one line of code).  However, with X509Tokens it is possible for WSE to locate the certificate without a single line of code.  The Security Settings Tool allows you to configure which X509 certificate you would like to use and stores an identifier for this key in the policy file.  This information is combined with the the <x509> element in the Microsoft.Web.Services2 config section handler that specifies which certificate store to find the token in.  So the combination of the policy file and the config file gives WSE enough information to find the correct X509 certificate without writing any security-related code within the service.

Policy saves code on the receive-side as well
Policy files can be used to save writing code on the receive-side as well.  On the receive-side the PolicyValidationInputFilter is used to validate that the incoming message meets the assertions defined in the policy file.  The policy file can perform checks such as whether the message is signed and/or encrypted with a specific token type or token as well as whether particular message parts have been signed.  If an incoming message does not satisfy these assertions then a security fault exception is raised before your service code is even executed.  As with send-side policy, the WSE 2.0 Security Settings Tool can help you author this policy, saving you from paying the XML angle bracket tax. 

The samples provided with WSE 2.0 have examples of solutions that rely on code and the same solutions using policy.  Comparing these solutions side-by-side highlights the many benefits of using policy instead of code to perform receive-side validation.  The first is that it keeps your service code much cleaner.  Second, it saves you having to remember to make the same calls at the start of each service.  Third, you can change your security configuration without having to recompile the code.

Putting it all together: automatic secure conversation
The best example I've seen of the power of no-code security through policy and configuration files is the support in WSE 2.0 for automatic secure conversation.  WSE supports the WS-SecureConversation specification that defines a SecurityContextToken that is a fast, light-weight security token that can provide message-level secure communication across multiple calls between a client and a service.  It's fast because it is based on a shared symmetric key, rather than an asymmetric key (which is over 1,000 times slower to process).  WS-SecureConversation builds upon WS-Trust which defines the notion of a Security Token Service that receives RequestSecurityToken messages and returns the issued SecurityContextToken as part of a RequestSecurityTokenResponse message.  WS-SecureConversation uses these mechanisms to request and retrieve the SecurityContextToken.  While all of this may sound a little complicated, it is possible to achieve all of this in WSE using the Security Settings Tool.  Using the ideas presented above, if you use X509Tokens then all of this can be achieved without writing any code.  This is the first demo I showed in my TechEd presentation.

Here's my take on how it performs this magic under the covers (feel free to chime in any time Hervey).  On the send-side, the PolicyEnforcementOutputFilter loads the policy file which specifies that all sent messages must be signed and encrypted with a SecurityContextToken.  I think that WSE makes an assumption that the web service can act as a SecurityTokenService and issue SecurityContextTokens (This is enabled on the service by adding the automaticSecureConversation element to the config file).  So when a SecurityContextToken assertion is found in the policy file WSE loads the SecurityContextTokenManager class and calls the LoadTokenFromSecurityTokenAssertion() method.  This method retrieves the tokens that will be used to sign the request before calling the RequestTokenFromIssuer() method that sends the RequestSecurityToken message and unpacks the SecurityContextToken from the RequestSecurityTokenResponse message sent back from the token issuer (which is often the same location as the service).  The PolicyEnforcmentOutputFilter then uses this SecurityContextToken to sign and encrypt the outgoing messages.

Phew, that certainly was a lot of digging with Reflector.  But it illustrates how powerful policy can be: you can request tokens from a token issuer and use them to sign and encrypt messages without writing a single line of code.  This blew me away the first time I saw it working (I didn't believe it until I saw the wire-level traces).  I pinged John Bristowe and Christian Weyer asking 'how does this work?  It seems like Magic but I know it can't be'.  When I thought about it more I realised that this was a demonstration of the power of the concepts such as aspect oriented programming or the Pipes and Filters pattern from Gregor Hohpe's Enterprise Integration Patterns.  More on this in a future post.

Making more of a good thing: custom policy assertions
As well as using the built-in WS-SecurityPolicy features that WSE enables with its Security Settings Tool, it is also possible to create your own custom policy assertions as John Bristowe has demonstrated.  Aaron Skonnard also has more about custom policy assertions.  WSE has great extensibility hooks that let you write code that uses your own policy assertions, allowing you to write validation code in one location that can be hooked into your service through the config file without having to reference it in your code.

While playing with the WSE Security Settings Wizard I discovered that the generated policy requires a DerivedKeyToken to be used to sign the messages rather than the original security tokens.  This is a good thing, but isn't obvious from the wizard screens.  I thought I'd provide some background on what derived keys are, why they are useful and how to ensure your WSE services use them through code or policy. 

Derived Keys: what are they and why are they useful?
Using a derived key is a good thing as it means a different key is used to sign and/or encrypt each message.  Changing the key each time makes it more difficult to perform a ciphertext-only attack.  The DerivedKey can use many different algorithms to generate the key.  WSE 2.0 uses the algorithm defined in the WS-SecureConversation specification, which creates the derived key by performing a SHA1 hash over the original key (in the case below, a reference to the key), along with the combination of a label and a nonce value (a unique value that's seen only once).  Here's what a DerivedKeyToken based upon a UsernameToken looks like on the wire:

<wssc:DerivedKeyToken wsu:Id="SecurityToken-d06a92f7-990c-43a4-a996-f8f3a359e450" wssc:Algorithm="http://schemas.xmlsoap.org/ws/2004/04/security/sc/dk/p_sha1" xmlns:wssc="http://schemas.xmlsoap.org/ws/2004/04/sc">
   <wsse:SecurityTokenReference>
   <wsse:Reference URI="#SecurityToken-6c059c7a-c748-44b1-b957-4b927dd2a8f3" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken" />
   </wsse:SecurityTokenReference>
   <wssc:Generation>0</wssc:Generation>
   <wssc:Length>16</wssc:Length>
   <wssc:Label>WS-SecureConversation</wssc:Label>
   <wsse:Nonce>mDRVPaA7343zsrMjD+CatA==</wsse:Nonce>
</wssc:DerivedKeyToken>

See Martin Gudgin's MSDN article on Using WS-Trust and WS-SecureConversation for further information.

Ensuring compliance with the WSE generated policy
To comply with the server-side policy that the WSE Security Settings Wizard generates you can either create a derived token in your code or use a send-side policy.  The advantage of using the send-side policy is that it requires fewer lines of code and provides the potential to change the security configuration in future without having to recompile the code.

Signing a message using a DerivedKeyToken with code
Creating a DerivedKeyToken requires two more lines of code than would be required to sign a message with a standard user name token.  The first extra line creates the DerivedKeyToken and the second line adds it to the RequestSoapContext.Security.Tokens collection so that it will appear on the wire when WSE sends the message.  Here's the code:

// Create the username token and add it to the message headers
UsernameToken usernameToken = new UsernameToken("TechedClient", "TechEd2004!", PasswordOption.SendPlainText );
proxy.RequestSoapContext.Security.Tokens.Add( usernameToken );

// Create a derived token, based on our username token
DerivedKeyToken derivedToken = new DerivedKeyToken( usernameToken );

// Add the derived key token to the message headers
proxy.RequestSoapContext.Security.Tokens.Add( derivedToken );

// Sign the message with the derived key token.
proxy.RequestSoapContext.Security.Elements.Add( new MessageSignature( derivedToken ) );

Signing a message using a DerivedKeyToken with send-side Policy
The simplest way to ensure that a message is sent using a DerivedKeyToken based on a UsernameToken is to use the WSE Security Setting Tool to create a policy file on the client specifying that output messages should be signed with a UsernameToken.  When WSE sends the message through its pipeline the PolicyEnforcementOutputFilter will create a DerivedToken based on the UsernameToken and sign the message with it.  For this to work, WSE needs to know where to find the UsernameToken to base the DerivedKeyToken on.  WSE first searches for a matching token in the SoapContext.Security.Tokens collection and if it doesn't find any there it looks in the PolicyEnforcementSecurityTokenCache. 

So you can either use the first two lines of the sample code above, or the following:

// Create the username token and add it to the message headers
UsernameToken usernameToken = new UsernameToken("TechedClient", "TechEd2004!", PasswordOption.SendPlainText );
PolicyEnforcementSecurityTokenCache.GlobalCache.Add( usernameToken );

The advantage of using the PolicyEnforcementSecurityTokenCache is that the username token can more easily be attached to any message leaving the client, regardless of which service is being used (e.g. it is independent of the webservice the message is being sent to, unlike the SoapContext which is related to a specific webservice address).  The second advantage is that if you later decide to sign with X509SecurityTokens rather than UsernameTokens then you wouldn't need to change any code or recompile (the UsernameToken in the GlobalCache would simply not be used).  I'll write more about this topic in a future post.

Jim Newkirk got his 'day in the sun' to speak about Test Driven Development and the tool out in public promoting Test Driven Development and the tools support he's been involved with using Microsoft Visual Studio Team System.

He started out with a quick audience poll of how many people had heard of Test Driven Development (around 80%) and how many were actually using it (about 30%). So a clear victory for marketing over behaviour change there!

The Two Tenets of Test Driven Development:

• Never write a single line of code unless you have a failing unit test.  The goal is to take requirements and express them as test
• Eliminate duplication

How to do TDD
Jim starts by blocking out 4 - 8 hour sessions of development. He spends 15 - 20 minutes at the start of each session thinking about what he is going to do and brainstorming a list of unit tests.

A key part is not to get hung up on completeness, you can always add more later. The purpose of the tests is to describe completion requirements.

The flow of a TDD session: Red, Green, Refactor
The process is:

• Start by writing a test for a new capability
• Compile
• Fix any compile errors
• Run the test and see it fail
• Write the code to make the test pass
• Refactor as needed (clean up any duplication)

The purpose is about how to use the functionality, not how to implement it! The process allows you to build confidence through having a set of tests that pass.

The most successful way to do test is to do it before the development. If you start it first then you need to think about how to test.

Features in Visual Studio Team Systems
Jim used a stack example to demonstrate the process of TDD as well as the support in Visual Stuido Team systems. The first test looked as follows:

[TestClass]
Public class StackFixture
{
   [TestMethod]
   Public void IsEmpty()
   {
      Stack stack = new Stack();
      Assert.IsTrue(stack.IsEmpty);
   }
}

So, the same approach as NUnit, just with new names!

One cool feature was writing a class name followed by a method name that didn't exist yet. After compiling, Jim used a 'smart tag' to choose to create the method stub inside the target class. It wrote this stub and had a 'NotImplementedException' inside it. This is functionality similar to Eclipse and is good to see.

When developing with WSE it is often useful to be able to see what is going out on the wire.  Changes in the WSE 2.0 release mean that is no longer possible to use tracing tools such as tcpTrace and MSSoapT.  Christop Schittko has a good post on the background to this problem and shows how to use the inbuilt-WSE trace capabilities to get around it.  There's also another solution, which is to use Mindreef SOAPScope's WebProxy, and as I was writing this I noticed that Mike Taulty has also posted his WSE 2.0 trace tool, which has become my new default favourite.

Background
The previous approach to tracing in WSE was to listen on a one port with a tracing tool, then forward the request onto another port.  WSE 2.0 now checks to make sure that the WS-Addressing To header in the SOAP message matches the address in the HTTP Header.  This means the existing tracing tools will return a fault.

The SOAPScope solution
SOAPScope has implemented it's own version of System.Net.WebProxy that allows proxying to localhost.  It also means that the address in the SOAP envelope matches the address in the HTTP header.  To use it you just need to add the following to the client's config file:

<system.net>
   <defaultProxy>
      <proxy proxyaddress="http://benjaminm:5049" bypassonlocal="false"/>
      <module type="Mindreef.Net.WebProxyEx, MrTools, Version=3.0.0.0, Culture=neutral, PublicKeyToken=90f6595dbbe888f3" />
   </defaultProxy>
</system.net>

Mike Taulty's solution
Mike has written a new WSE 2.0 Trace Tool that uses custom input and output filters into the WSE Pipeline. These filters copy the message into a new SOAP envelop and post it a tracing 'web' service listening on the a tcp port, using the SOAP Messaging (soap.tcp:\\) support within WSE 2.0.  Using it requires adding the following to the config file:

<microsoft.web.services2>
  <filters>
    <output>
      <add type="WSETracingFilter.WSEOutputFilter,WSETracingFilter, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=1c1f2f7177e1ff79" />
    </output>
    <input>
      <add type="WSETracingFilter.WSEInputFilter,WSETracingFilter, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=1c1f2f7177e1ff79" />
    </input>
  </filters>
</microsoft.web.services2>

It's very nice! I'm going to be using it tomorrow in my talk at TechEd.

Clemens' talk was about managing state across multiple layers within a .NET application. His message was that there are many types or state and many approaches to dealing with it. It's not just about the ASP.NET session object! He covered a definitions of services, state and its types as well as how to manage state including transactions.

Statelessness doesn't really exist
Stateless doesn't really exist. Everything is stateful when it runs. Just because a component doesn't remember anything across calls doesn't mean there isn't a state penalty. Keeping information on the stack is a way of maintaining state.

Definition of services
A service is autonomous -lives and can be deployed by itself.

A service has its own store. It might be as system with 20 modules having 20 databases.

A service is not XML and SOAP. This is just one way of talking to services.

Services shouldn't share databases
One of the gems I picked up from the talk was that we shouldn't necessarily tightly couple everything at the database layer by putting it all in one place. Sometimes this is done for speed, but the benefit may disappear if you put it in a cluster.

Martin Fowler posted about this today:

The recent rise of Service Oriented Architecture seems to mean very different things to different people, but one plausible thread is a rise of autonomous applications with their own ApplicationDatabase that communicate through service interfaces - effectively replacing shared database integration with rpc or messaging based integration. I'm very sympathetic to this view, particularly favoring integration through messaging - which is why I encouraged the development of EIP. In this view of the world the integration database is no longer the default assumption.

What is state?
All the data an application needs to remember. It can be:

• volatile (the stack manages volatile state)
• transient (a stock ticker)
• permanent.

Transient state may contain useful data
Clemens mentioned that transient data may contain useful data that is worth storing. An example is the contents of a shopping cart at an online store. Keeping this data can provide useful information about the behaviour of people on a site (how many don't complete an order?).

Don Box and Doug Purdy did a 'keynote' for the Connected Systems Track.  They started out by asking what questions the audience wanted to see.  A great set of questions were proposed and the answers contained some of the most valuable content in the session.  Here are my notes on their answers, and some they didn't get time to do.

How does WSE 2.0 fit in with the Indigo direction?
It lets you use the protocols we have today.  WSE takes your ASMX investment and keeps you in the game as we do this protocol work.  If you don't track the protocols it may not be so important. 

Indigo will be the primary technology for using the WS-* specifications in future.  WSE takes your ASMX investment and lets you add support for those specifications today.

What's the future of DIME?
MTOM.  DIME was an experiment - we were on the wrong track that didn't support security.  Microsoft got together and did PASWA that became MTOM.  It will be in Indigo and other MS technologies.

WS-Security vs. SAML?
There are many different kinds of tokens that may be used, such as Username, X509 certificates and Kerberos tokens.  Don said it was unlikely that a token type, like SAML will become the 'single token format to rule them all'.  No definite answer on where the SAML support was.  As I learnt on Saturday, trying to implement SAML support is a non-trivial exercise - it would be nice if there was a clear statement from Microsoft on when it will be supported in the platform (so that you don't have to share my dll in order for us to use it when we talk).  I think it will be part of the identity management work in future.

How successful is WSE at interop?
Microsoft do bake-offs with WSE where they get all the vendors in a room and try and make the specifications work.  There wasn't a definite answer other than this.

How do you talk SOAP from a Windows Service?
Don's answer was that you do the hard work to host ASMX inside a service then put an ASMX façade and call into the service with ES or Remoting.

I thought this missed the point that the recently released WSE 2.0 supports Soap Messaging, which allows you to implement SOAP messaging over TCP.  I think this would be a far easier way of hosting SOAP within a windows services.

What is the technology to replace COM+ in the long term?
ES investment will keep working.  Deployment, interception and synchronization are being brought forward into Indigo.  Many of the ES semantics are a direct correlation with the Indigo model.  Doug mentioned that ES programmers will be the most prepared to work with Indigo when it ships.

Is there an issue with the verbosity of web services payload?
Don's answer was that Indigo will 'negotiate up' and switch to a faster way of communicating if the other endpoint uses Indigo.  How they do this is to be seen (there were comments at the PDC that the first Indigo call will be a policy request to see if the other end is an Indigo endpoint).  Don mentioned that the industry is having a hard time defining binary protocols that allow user definition are difficult.  Binary protocols that support user defined structures are hard.

How do we discover services and determine policy at run time?
Don mentioned that UDDI was a solution you could use today.  In a show of hands only 4 of 200 attendees were using UDDI (2% adoption?).  According to Don it makes some hapy, but some customers want more.  They want a more flexible model for describing things without having to use the tModel (which is hard to grok).  There also other groups want to discover services on devices, so WS-Discovery is where Microsoft are headed.  It is a small spec that is easy to understand that can be easily implemented.

Will we need to continue to be plumbers to do web services security?
I thought this was a great answer:

For a while.  WSE makes it easier, but if things go wrong you'll need a plumber.  We have not done our job in Indigo if people have to understand the protocols.  Your common developer needs to solve business problems, not the protocol problems.  Indigo is adding value without focussing on the protocols. 

No matter how good WSE does, since we are ironing out the interop you'll still need to read WS-Sec.  Now at least we only need plumbers when things go wrong.

What's the migration path to SO?
This was really the content of Richard Turner's talk in the track, he's also written a great post on detailing prescriptive guidance on preparing to upgrade to Indigo.  The basic message is don't do tricky things.  If you are doing something that was hard to figure out, maybe that was for a reason.  So things like SoapExtensions or custom message sinks in Remoting are not going to upgrade well.  There's lots of material out there that shows that Microsoft have a 'good story' on upgrading from various technologies.

Unanswered questions:

• What is the MSMQ equivalent for COM+?  Is MSMQ going away?
• How does EIF fit into SOA?
• Strategies for native to managed interop?
• Will Indigo support mailslots?
• Are there any application blocks for SOA?
• How do we handle events across appdomains?
• Security - you have authentication and authorization - what about any attacks through the channel - filtering content? Content-awareness in firewalls?

I'm with all of the 'Blue Shirts', speakers and the Microsoft staff, in the keynote overflow room, sharing the experience of watching Steve Ballmer on a video screen.  Here are some key points:

• He's looking trimmer. A gasp of 'Atkins!' went around the room.
• Key messages - do more with less.
• The next 10 years are going to be even greater than the last.
• Only Pfizer spends more than Microsoft on R&D.
• Remember 10 years ago TCP/IP was a separate business to the OS.
• Integration is the key. How many data access layers does Microsoft need.
• How can we narrow down the skillset required to know how to use the products. Integrate to reduce the overhead required to use the platform.
• Windows XP SP2 has taken priority over Longhorn recently.
• It used to be 'features, features, features' now it's 'listen, listen, listen'.
• Watson is one of the biggest advances in computing. Being able to send crash reports to Microsoft means there is a statistical way of rating the issues that users are having.
• Integrated innovation and customer responsiveness to do more with less.
• Security is key focus.
• Spam is too cheap to send - we need to add cost and burden. Using techniques like making the sender prove who they are.
• Interoperability has been a key focus. Microsoft has done more than most people have ever given them credit for in integration. Microsoft is absolutely behind the XML stack as an open standard. The 'best and most important thing to happen to our industry'. It's an 'architected' way of doing interoperability. The old way was writing XML to connect each system.
• Microsoft Office beta web services - allow Office to be a smart end client to web services.
• Becky Dias gets on stage.
• WSE 2.0 is released! Also the Microsoft Office Information Bridge are entering Beta.  Basically web services integrated with Microsoft Office task pane.
• She's clicked on someone's name in Outlook. A task pane has come up with a form that lets her do a stock trade, calling a webservice and gets an ID back again, all without leaving Outlook.
• Demoing policy. Not sure if the audience are getting this. But it's very cool. We don't have to right code anymore. Definitely should have spent more time polishing the WSE Settings Tool wizard screens.
• .NET has more than 50% of the US market. Customers think it is 66% more reliable, 70% think it is faster, 2.7x people think it is more secure.
• The VSIP program has been increased. Oracle and SAP and TibCo will use Visual Studio for their platforms.
• Visual Studio 'Team System' - now trying to do more as part of the software development life cycle. Group development, modelling, testing and deployment.
• It looks like we now get bug tracking within Visual Studio.
• Showing a Whitehorse style screen that diagrams the deployment of the application and can check to ensure that it will work in that environment.  It produces 'build errors' when you compile it.
• Can specify that the system passes build rules, static analysis and unit tests. 
• Finally we have unit tests that are part of the build system (this got a clap!).  Now we know what James Newkirk has been doing at Microsoft!  Rewriting NUnit!
• Also includes code coverage tools as well (another clap)
• There's also a security version of FxCop that is built into 'Visual Studio Team System' based on Microsoft Research's work on Secure Computing Initiative.
• But wait, there's more .... load testing as well (more claps!)
• Back to the Information worker.  Steve has the feeling that SharePoint Team Server, Portal Server, Office and Live Meeting haven't been as well adopted as they should have.
• There will be advances in searching as a result of 'strong competition' (see Google)
• Why choose Microsoft over Linux or Java? More integreated innovation, better responsiveness and trustworthiness, partnerships, choice (more applications, better interoperability).

Overall I was a little disappointed that 'Crazy Steve' didn't make an appearance.  There was no sweat, no ranting, no cheering with the crowd.

Scott's a very funny man and hosted a very entertaining session on code generation.  My jet lag really kicked in at the start of this session, so you might like to see Peter Provost's blog for more coverage as well as Jon Galloway:

• Jon Lam talked about the 'usability tax' from using XML. XSLT is a programming language that is hard to maintain. He prefers using PERL for writing code. XML is hard for humans to maintain.
• Scott started by talking about the CodeDOM as being 'the opposite of terse'.
• Discussion about the line between creating a generic engine versus just solving the problem with code. How do we deal with the trade-off between producing a solution to the current problem versus creating a generic non-specific approach.
• Computer languages are for people to work with, so we write in C#. It is a code generator that produces IL that produces assembly code to run. We want a higher level language to build software.
• 3 kinds of code-generation: Wizard skeleton, Compiler - template and generics, Modelling - result is not a model but an assembly
• Some discussion about whether generators were useful for producing quick and dirty one-off situations.
• Discussion about what the output of code generation should be. Is it the code files, or is it the compiled DLL?
• How do you manage changes - should you do it at compile time or run time? What about it you need to modify things after they have been generated? Should you make them plugins, use interfaces or work with the config files.
• Sometimes code-generation make it hard for others to maintain.
• Don't do the rules engine that solve the 'verbs' problem. Think about the nouns.

How Corillian do code generation:

• Scott talked about how Corillian do it. They model the nouns in a visual tool using an XML schema underneath that can be extended and allows you to create your own vocabulary. The elements on the schema come from another namespace that includes domain specific attributes.
• They then we use a free-ware tool called code-smith which lets you write code-generation syntax in an ASP.NET syntax (<% for each … %> to output the data). They use that to create the code (rather than HTML in the ASP example).
• They created an XML schema adapter that looks at an XML schema and gives you a collection of top-level types and subtypes. Then all the different places where they have domain-specific knowledge they use 'aspects' by placing that logic inside the setters and getters.
• The schema describes the contract between asp.net and the host and the asp.net and the front end like the device that it displays on.
• The adapter reads the schema and presents it in a friendlier way. The CodeSmith studio is an IDE for doing this. It has adapters that takes anything that presents a collection (e.g. a database), then for each table in tables - generate the code.
• The easiest way to jump into code generation it is to use the strongly-typed collection classes that comes from CodeSmith - accounts in ArrayLists should become an accounts object - it allows you to simulate the behaviour of generics now.
• Any time in the schema with max-occurs unbounded - we know it is an array and autogenerate a strongly-typed object it.
• The business people edit the XML in XML spy. Corillian separate domain objects from the message. They have a WSDL explorer. They use WSDL and a custom binding to generate the whole banking services. The proxy is generated from the WSDL - binds domain objects, messages and verbs.
• In future they are looking at using schematron that describe restrictions (e.g. saying something is an integer is not the same as saying it is a social security number). The intention is that the attribute on an element in the schema maps through an attribute in .NET.
• Scott's belief was that anything in the schema should be carried forward because the metadata should not be lost.

If you're at TechEd and would like to catch up with me I'm on MSN Instant Messenger at benjamin AT benjamin DOT net.   I'm especially interested in anyone who's doing work or got thoughts on web services, Indigo or extreme programming. 

I'm also on Scott Hansleman's Microsoft Regional Director Bingo card (available from booths 49-50 in the Pavillion) so come and say hello and I'll help you win a prize. 

Roy was concerned that this represented the 'cult of the worshipping masses' and that we 'should not be handing out autographs, but software, tips, tricks and code'.  Well, happilly I can report that the goal of the Bingo game is to encourage attendees to talk to the Regional Directors.  It's sending the signal that we're here to connect with attendees and share experiences and transfer knowledge.

Meeting the RDS at TechEd is just like a .NET rocks episode but live and in person.

Here are some of my tips on how to make the most of the week at TechEd.

Make a session plan.  Know your entry and exit points.  TechEd is sold out.  Not only that, it is overbooked.  Expect to be sitting in the aisle if you aren't clear about which sessions you are going to and how to get there.  Spend some time learning the floor plan on the first day so you can get between rooms without getting lost. 

Don't stare too long watching the PowerPoint slides.  Every attendee is going to get a DVD with the slides and audio after the show (it will likely be on the web as well), so don't cram your schedule too full with sessions.  Pick the key sessions to attend, you can watch the others later.

Connect with people about the technology.  Instead of going to the breakout sessions, make sure you spend time in the Cabana areas and the Community Lounge.  The Cabana areas are small presentation areas where you can 'heckle' (well, ask questions and interact) the presenter.  The Microsoft stand in the Exhibit Hall has   many key people from the product groups at the event.  They are here to meet you, answer your questions and help you understand the technology.  Take advantage of this chance to have one on one conversations.

Speak to the Presenters, Authors or Regional Directors you see.  Don't be afraid to approach these people if you see them.  They are at the event to answer your questions and find out about your experience.  Use them. 

Focus on questions you'd like to have answered and areas of knowledge you'd like to improve.  Aside from the above, I think there's also a RIO networking area where you can go and find experts who can answer your question.  There are lots of key people from most of the Microsoft teams at the events and they are here to talk with you.   Spend some one on one time with experts rather than just sitting in the audience. 

There was a panel discussion with John Bristowe, Scott Hanselman, Joe Homnick, Joe Lindsay, Terry Mohn, Ted Neward.  the highlight for me was that there still isn't good tool support, or a good story from Microsoft, on how to manage services once they have been deployed.  Other points:

• Scott mentioned that his company provide services to 30% of all online US Banks and 50% of them rely on web services. So they are out there and being used.
• An excellent point was made there isn't good tool support (or a good story from Microsoft) on how to manage services once they are deployed. The tools to ensure that services are up and running and providing guaranteed levels of services are not here yet.
• There was some discussion about whether we should care about angle brackets or not. Scott made the point that we should focus on Infoset. John Bristowe made the point that it can be useful to understand the specs and know what is happening on the wire.
• Ted mentioned that editing WSDL is too hard and no-one at the event other than Scott had actually done it. Scott made the point that most of us had edited HTML files because we did not like the way FrontPage formatted them, so why hadn't anyone done the same with their WSDL?
• Some good points from the more business-focussed members of the panel that they are more interested in tools making developers productive than in having developers that understand the plumbing in web services.
• Discussion about what the definition of SOA is. Answers included 'components with a longer wire', 'objects with explicit boundaries', 'hooking shit together'.  I had a useful discussion aftewards with Joe Homnick that helped me see that SOA is most useful as a concept when talking with businesses about how to architect projects.  As I've mentioned before I'm still not convinced that SOA is definable, but it is based on top of good architectural concepts such as encapsulation, data hiding, loose-coupling, service discovery, messaging patterns and asynchronous processing.  So if we need to call this SOA in order to get all excited about these topics then it may be a necessary evil.
• I followed with the question 'what problems is SOA trying to solve?' answers included high-level re-use and interoperability.
• Discussion about location transparency not being a good idea. Ted suggested the original idea was really about being able to write code without having to know the location of the components, rather than hiding the fact that this was an expensive cross-network call to a component.
• Discussion about the fact that Amazon uses Web Services well but that XML over HTTP is more popular than their SOAP implementation. There was some discussion about alternatives to SOAP such as REST, but they were seen as more limited compared to SOAP. The key for me is that tool vendors need to implement great tools for SOAP so that it is easy to use as these competing approaches.
• The more business focussed members of the panel made the point that the technology is not the main thing, it's supporting business functions. For them the point of the Interoperability work is that it les them go out and buy products that they know can talk together.

Ted Neward gave the keynote at our WS-Interoperability Day even today.  Here are some of the points he made:

• It's important to learn from the past, in terms of previous distributed computing approaches, when looking at Service Oriented architecture and web services.
• One of the key things that made HTTP a ubiquitous approach to solving interoperability problems was that it was simple.  For me this highlighted the fact that it is essential that good developer programming models be developed over the top of the WS-* standards so that it's simple for developers to take advantage of the functionality without necessarily having to be a plumber. 
• It is important that vendors continue to work together and not start developing their own non-standard features.  Ted mentioned that vendors are currently being driven to ensure compatibility in order to make money from the new approaches, but once a market it established they may start fracturing away by adding their own non-standard implementations.  Dare covered this in his post detailing the SQL standards.
• Ted made the point that Objects work better when they are deployed together because they need to talk together.  Good objects are well factored and make a lot of calls.  This means that the same techniques does not extend well to situations where objects are distributed.
• The fastest call that can be made to a network is around 1000 times slower than a local in-process call.  This can raise to 10,000 times slower when the network is involved.  To illustrate what this means, Ted used the analogy that this was similar to his 20 minute commute to work taking 70 days (his math).
• SOA is just a new way to get developers to listen to the worn-out message that  'Distributed Objects Don't Work'
• Interoperable systems work best when the architecture is built from the centre out.  If you start at the .NET and work towards Java for example it's likely that you'll find you've implemented something that is incompatible.
• The problem with starting from the inside out is that WSDL, which provides the definitions, is hard to work with and you really need a tool to author it.

I flew into San Diego last night where Michele Leroux Bustamante had agreed to meet me at the airport.  The plane was an hour and a half late and I was wondering if she'd still be there or even recognise me.  Turns out I needn't have worried she'd be in the group with the three laptops and the wireless router:

That's Anant Kadiyala, Michele and Heinrich Gantenbein getting in all the preparation time they could before our interop demo.

I'm presenting a TechEd session in the Connected Systems track on how to use Web Services Enhancements 2.0 to secure web services.  TechEd looks like being a mini-WSE festival, with Aaron Skonnard doing the pre-conference on Sunday, Keith "My blog has gone" Ballinger talking up a storm on messaging over multiple machines and networks, plus loads of other applied web services talks.

In my session I'm going to cover all of the security features in WSE using as many code demonstrations as I can fit it.  I'll cover the basics such as security tokens, signing and encrypting before moving on to more advanced topics such as token issuing and establishing secure conversations.  I'll show how WSE 2.0 allows all of this to be done with code as well as policy and configuration files.  The best part is that straight afterwards you'll be able to go and do some Hands On Labs authored by Aaron Skonnard covering these topics.  How's that for in-depth educational experience?

Here's the official description

CTS302 Connected Systems: Using Web Services Enhancements v2.0 (WSE) to Secure Web Services
Wednesday, May 26 2:00 PM- 3:15 PM, Room 10
Speaker(s): Benjamin Mitchell
Track(s): Connected Systems, Developer Tools and Technologies, Security
Web Services are being used to cross application boundaries, especially between enterprises. Such interactions need to be secure. See how to use WSE v2.0 and the security protocols that it implements to secure Web service interactions within and beyond the Trust domain

For those interested in doing some background reading before the event, I strongly recommend WS-Security Drilldown in Web Services Enhancements 2.0 by Don Smith.  Rebecca Dias thinks its the best article she's read on WS-Security and I'd agree.  Also Hervey Wilson's blog mentions some truly magical features that will whet your appetite for what you could see.

Martin Gudgin points to the Working Group Draft of the WS-I Basic Security Profile.  I believe that the web services security will play a major role in increasing the adoption of web services in future.  It's great to see the WS-I behind a push for greater interoperability in web services security.

Web services security enables message level security, through signing and encrypting parts of a message, so that secure communication can be established even across public networks such as the Internet.  Increasing support and compliance for this security infrastructure across platforms and development languages will lead to even greater adoption of web services.

I'm hoping that they develop test cases that can be used to prove compliance to the standard, similar to those already developed for the WS-I Basic Profile.  In preparations for this Saturday's Web Services Interoperability Day Michele Leroux Bustamante has had to assume the role of 'human interoperability tester'.