Here's my story about Web Services and WSE that I gave to a Visual Basic User Group in Manchester last night:

• SOAP is a way of communicating over internet friendly protocols
• Web Services is based on simple standards that made it easy to get companies to commit to the standard.
• There were many gaps in the initial Web Service building blocks.  Now there are many specifications that plug the gap - the key is making it easy for developers and developer tools to adopt these specifications.
• WSE is the implementation of many of these emerging specifications.
• WSE makes it easy to secure web services without having to secure the wire through:
  • Encryption
  • Signing
  • Exchanging security tokens.
• WSE also shows some interesting new approaches:
  • Using policies.  Allows administrators or others to apply security settings without having to recompile code.
  • Addressing.  Introduces the idea of routing web services, allows developers to virtualise the network.
• The programming model may change in future, but it's likely that the XML on the wire will change less.
  • Luckily the programming model is relatively simple.

I also recommend Werner Vogel's article Web Services are NOT Distributed Objects.

All of the Tech Ed 2003 talks are available online.  There are some great presentations on WSE, including Keith Ballinger talking about WS-SecureConversation.  Presentations like these are useful for filling the gaps in the WSE 2 Tech Preview documentation.

Microsoft's ability to provide such a wealth of content is one of the main reasons I like developing for their platform.  What other vendor provides this level of its supports for developers?

I had an experience this week with .NET where most of the day was spent working with the configuration and setup rather than on the business logic.  I was working with a team to implement the web service security framework I’ve been developing.  There are a number of assemblies in the project – one http module, a metadata module and another with the WSE filters.    The team I was working with were trying to use the ‘Copy Local’ property of assembly references in Visual Studio to copy assemblies from a central third party assembly directory to the project’s local folders.  This was the root of many of our problems, as the better way to achieve this goal is to use the GAC.

We basically ran into problems because we redeployed updated assemblies to the local project, rather than the central third party assembly directory.  When we compiled our project it overwrote our updated assemblies in the local project with the older assemblies in the third party directory.  It took us a while to understand that this was going on.  We first noticed that the updated assemblies had been replaced with older assemblies.   We removed all of the references from Visual Studio but it was still happening.  A MCS consultant gave us some assistance and showed how to use Ildasm.exe to view the assembly manifest – this shows what the assembly knows about rather than what Visual Studio knows about.  This then helped us work out what was going on.

I really enjoy picking up tips using Ildasm.exe to see what's going on under the covers.  I find working around others is a great way of doing this.  Knowing what's going on under the covers takes a lot of work, but it's rewarding when the knolwedge helps solve problems.  Eric sink has just written a great article on the benefits of understanding what's going on under the covers rather than relying on higher level tools.

Tools like reflector and Ildasm.exe are great at getting a handle on what is going on under the covers.  Yesterday I read the readme to reflector and realised that you can use it to display which virtual functions are overridden locally in a class and which are inherited by the base class (shown by different coloured member names).  It’s also possible to search for all references to a member within the loaded assemblies.  I think this is the best tool for browsing projects – better than the object browser and the class view combined.  This screen shot shows how you can find sub types as well as seeing which methods are implemented locally (black members) and those that are implemented in base classes (green).

Tim Bacon has another good post on his blog about the techniques someone playing the coaching role in an XP team can use to persuade, influence and help other team members.  Similar to the idea of a Project Manager at Microsoft, Tim notes that an XP Coach often has responsibility without authority.  Tim's list is comprehensive and insightful and covers many of the techniques I studied in counselling psychology topics at University. 

I like the fact that he pushes using open ended style approaches rather than more didactic approaches.  Using more of a Socratic approach is a much better way of encouraging people to grow and develop in intellectual pursuits like programming.  I'm sometimes surprised by the level of posturing, ego and insecurity amongst many IT professionals - a lot of energy seems to go into defending a position of expert rather than into producing results or helping others with their knowledge.

It's encouraging to me that there are people like Tim out there who are focussed on using good communication techniques to help other developers achieve their potential.  It's interesting that he mentions listening is a key part of this.  I think it is a mistake that some developers believe that gruffness or snap-decisions are better than reflection, questioning and thinking.  I'm interested to know how Tim views the difference between the activities an XP coach might perform and those of a mentor.  I know on Tuesday night we spoke about one difference being that as an XP coach you also have to be a performing member of the programming team in order to garner the team's respect (through 'having skin in the game' in the words of Alan Cooper).

In browsing around tonight I also found an excellent blog entry from Morris Sims a Microsoft Employee on doing what you love.   He mentions the importance of having mentors that adapted to his strengths and weaknesses, making a bet on yourself and taking risks.  Ed Kaim also adds to this the idea of 'just doing it'.  I'm certainly taking this to heart at the moment getting out there and presenting to the developer community and extending my contacts.  I'm presenting on WSE again to a group in Manchester next week.

In other news, I had a great time today working with another developer to integrate work I had done into their project - it was another experience of pair programming, sharing knowledge, working efficiently and getting things done.

Last night I went to another Extreme Tuesday Club (XTC) at the Old Bank of England pub in London.  I've been attending for the last few months and the club's been going for over four years.  It's a free event open to anyone interested in extreme programming or agile development.

It's one of the most interesting and intelligent groups of developers I've met.  I know a lot of people might be turned off about a bunch of programmers talking shop in a pub.  However, I find that when people get together and share a passionate it's very exciting and interesting.  It's quite comon to see people pull their laptops out and start programming.  Many of them are active in the Open Source community - a great line I overheard was "sorry guys, go to go - I have to do some Open Source".

The people differ in their range of experience with XP programming.  Some members hold PhD's in Computer Science and have been doing XP since it began, others have read some books and want to know more.   In the past few months several key international figures have also dropped by including Martin Fowler, Erich Gamma and Alistair Cockburn.

Here's an indication of the kinds of topics I talked about last night:

• The strengths and weaknesses of strongly-typed and weakly-typed languages.  What are the relative merits of Ruby and Python? I also got my first insight into the 'two axes of typing - strong versus weak, and dynamic versus static'. Dynamic languages let you assign a value without declaring the type of the variable first (such as Perl and Python).  Perl is considered a weakly typed language because you can put another value type into the variable, whereas Python is a strongly typed language as it will only allow values of the original type,
• What does involved with the concept of a Coach in XP?  Should there be a designated coach in each team or should everyone try and help any other team member in difficulty?  The notion is that coaching is a process not a role.
• I met Tim Bacon, who bills himself as an XP coach, for the first time after reading many of his postings.  It was fantastic to hear someone else involved in programming talk about how 'emotions are what interest him most'.
• Sometimes the role of a coach can be to listen to someone and validate them, listening to their anxieties: it can be difficult to talk on this level to the managers or team leads.
• How to handle a situation where the project's success revolves around one key individual.  This was referred to as the 'Bus Test' - how many developers would have to be hit by a bus before the project was in trouble.  We discussed a situation where a key devloper had been removed from a project in order that the team and the project continue more successfully.
• Does a team celebration negatively impact future performance?  One group had recently delivered their project and had a day on a yacht as a celebration.  Their manager had challenged them - was the day of team building successful since their performance in the weeks since had been lower than before.  One point of view was that it wasn't the effect afterwards, but the motivating property of the reward prior.  Others felt that it was the motivating quality of the reward in the eyes of the other teams in the company.
• A discussion on Refactoring and the GOF books have made a significant contribution to the developer community.  Refactoring was really about the practice of what programmers do everyday.  Someone described it as like learning how to cook properly after years of reading a cookbook.  It's like if you are a brick-layer finding out there are different ways to lay bricks.  The benefit of the refactoring approach is that it is language independent - it's about why you do something. One of the most useful ideas in Refactoring is the notion of smells - a sense that the code has some problems. 
• A general complaint from many of the members moving from Java into C# is that Microsoft doesn't have good support for refactoring in C#.  The belief is that Microsoft are interested in the Visual Basic style developers who want to have GUIs and Wizards that help them achieve tasks.

All up a fantastic evening in the pub.

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.