Rebecca Dias is a PM on the Advanced Web Services team.  She's shifted her blog to a new location.  She has a whole grab bag of WSE goodies posted on her blog from a Web Services conference day.

Tim Ewald provides a useful overview of how WSE fits with ASMX web services, Scott Short has a good PowerPoint on WSE Security - explaining about Security Tokens and WS-SecureConversation.

Best of all though are the two Hands On Labs used at TechEd 2003 and written by Aaron Skonnard.  The first describes how to use the SOAP TCP supports, similar to his previous article.  The second provides information on how to use WS-Policy to author policy for web services.  This is a particularly good document as this feature isn't mentioned in many places (yet).

WS-Policy and WS-SecurityPolicy solve the problem of tying code too closely to the security: controlling access to the code is a separate concern from what the code does.  With Policies it is possible to place the security information in a file instead of inside compiled code. So if you decide that a method needs to allow users in the 'Broker' role and not 'Traders' you can make this change in the policyCache.xml file, without having to recompile your code.

It took me a while to understand this.  My first attempt at securing web services with WSE was to set the Thread.Principal to a GenericPrincipal object that I created, and then use the [PrincipalPermission(SecurityAction.Demand,Role="Banker")] attribute above my method.  However, with policies, I can set this in a policy file, like:

<wsp:Policy wsu:Id="TradersOnly">
 <Integrity wsp:Usage="wsp:Required"
  xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext">
  <TokenInfo>
   <SecurityToken>
    <TokenType>UsernameToken</TokenType>
    <Claims>
     <wse:Role value="Traders"
      wse:xmlns="http://microsoft.com/wse/2003/06"/>
    </Claims>
   </SecurityToken>
  </TokenInfo>
 </Integrity>
</wsp:Policy>

Now all I need to know is how to get this working with a custom SecurityContext token (or how to achieve the same effect with a custom assertion handler).  In this case the role information is probably not going to be passed in the SOAP message with the SecurityContext token - it will be cached on the server, so I'm not sure how policy will work in this situation.  More study required ...

It's great to see Eric Gunnerson doing some usability testing on the default C# project templates.  He correctly spots that the:

I know this code has been around for a while, but Craig Andera's 'Last Configuration Handler I'll Ever Need' article is very useful.  He creates a class that implements the IConfigurationSectionHandler interface and uses deserialization to take the config file information and squirt it into a class.  It makes it simple to use a configuration section of a config file as well as making it easy to access these values from a class withoutout having to write any code to hook the class up.  Very nice.

In the September MSDN Magazine Aaron Skonnard provides an excellent explanation of TCP messaging support in WSE 2.0.  He explains the SoapSender/SoapReceiver classes, which provide low-level control over the messaging (you have to manually create a message to send back if you want to support request-response style messaging), as well as the SoapClient/SoapService classes (that provide methods that make it easier to do things like request-response style messaging).

A lot of my Java developer friends give Microsoft a hard time about the design of the .NET Framework Class Library.  Especially with test-first development it would have been easier if the framework used Interfaces rather than classes. 

For example, in ADO.NET it is difficult to write interface-based code because all of the classes are based on the concrete ADO.NET managed provider.  For example, if you want to populate a DataAdapter you have to know what kind of database you are talking to rather than being able to use an abstract DataAdapter and decide at run time what time of database you want to use.  This is because there is no DataAdapter interface, there are only the concrete DataAdapter classes - OdbcDataAdapter, SqlDataAdapter.  Abstract ADO.NET is an open source project that provides a set of interfaces that overcome this problem (as well as the issue of creating connections and handling exceptions).  More recently Microsoft have updated their Data Access patterns block with an Abstract Factory pattern, making it easier to write NUnit tests against different database providers (as Steve Maine notes)

Jon Lam has a good posting that Unit Tests of the UI are difficult because of the lack of interfaces.  In the comments, Joe Beda from Microsoft offers reasons why Microsoft prefers classes over interfaces:

Generally, classes are preferred over interfaces for a variety of reasons. I'm not the expert here, but versioning is definitely the big reason. Since you can have "default" implementations to go along with a virtual on a base class, you can add new functions in v.Next and provide a default implementation. With an interface, once you ship that interface you are stuck with it forever. You can't add new methods to that interface.

Also, any time that you pass that interface to the "system" there is an implied contract about how and when the system calls you back on that interface.