James Newkirk lead a Birds of a Feather session on Test Driven Development.  The room was packed to the rafters, showing that Unit Testing is starting to reach a critical mass.  Here are my notes on the discussion from the session which covered how to write tests, how to use tests against legacy systems, how to test against the database and many other topics.

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.

Along with Jan Erik Sandberg (founder of the Norwegian Extreme Programming Forum) I'll be running two Chalk and Talk sessions on Extreme Programming at TechEd Europe.  We're going to use a 'Fishbowl' format, sometimes described as a Park Bench Panel.  Ward Cunningham describes this format as 'very much like a wiki for people who happen to be largish in number and stuck in the same room’

Here's how the format will work: we'll start with a panel of speakers (James Newkirk will be with us for the first session at least) 'in the goldfish bowl' on chairs at the front of the room, along with one empty chair.  The rules are that those in the audience, outside the fishbowl, are only allowed to ask questions.  If you would like to say something then we'll encourage you to walk up and sit in the empty chair.  At this point discussion stops until one of the panelist leaves so there's always an empty chair.

Here's the blurb:

Are you interested in Extreme Programming?  Have you thought about starting an XP project?  Do you want to know what works, what doesn’t, what the risks are?  This Chalk-&-Talk is a great opportunity to meet with other interested and experienced practitioners.  We’ll use a ‘fishbowl’ discussion format – an extreme way of having an active group discussion described by Ward Cunningham as ‘very much like a wiki for people who happen to be largish in number and stuck in the same room’.
Wed 30 June 2004, 08:30 - 09:45 Room S
Fri 2 Jul, 16:15 - 17:30 Room S

Here's the list of all of the Birds of a Feather presentations planned for TechEd Europe.  I'm going to be talking on "Service Orientation - what does it really mean" next Thurs 1 July at 18:15, Room R.  The BoF sessions  are often the best value sessions at TechEd since they are a chance to talk with other practitioners about the practice of software development, rather than simply features of products.  It's worth planning them into your schedule as the demand has been high and the room being used is likely to fill up.

I'm going to be hosting a BoF on "Service Orientation, What does it really mean?".   It will be a chance to go over the great definition debate, to look at what problems SO is trying to solve and how to do it today.  Here's the blurb:

Service Orientation receives much hype, but what does it really mean? Is it always the best approach? does it mean message orientation? is it necessarily tied to web services and XML? how do we architect SOA solutions? How de we partition?

Here's the full BoF schedule (the conference site list is a little out of date):

BOF001	James Newkirk "Integrating Unit Testing Practices in the Software Development Lifecycle"	30.06.2004 10:15 – 11:30	Room R
BOF002	Peter Koen "Enhancing SQL Server Performance"	29.06.2004 16:30 – 17:45	Room R
BOF002	Peter Koen "Enhancing SQL Server Performance"	30.06.2004 12:00-13:15	Room R
BOF003	Frans Bouma "O/R Mapping and .NET"	30.06.2004 14:45 – 16:00	Room R
BOF004	Bernhard Tritsch "Terminal Services in Large Enterprises"	29.06.2004 18:15 – 19:30	Room R
BOF004	Bernhard Tritsch "Terminal Services in Large Enterprises"	30.06.2004 16:30 – 17:45	Room R
BOF005	Thomas Lee "MSF and MOF – What's in it for me?"	30.06.2004 18:15 – 19:30	Room R
BOF005	Thomas Lee "MSF and MOF – What's in it for me?"	01.07.2004 08:30 – 09:45	Room R
BOF006	Jackie Goldstein "MS Patterns & Practices – Are They Relevant to Me?"	01.07.2004 10:15 – 11:30	Room R
BOF007	Damir Tomicic "INETA Europe – Yesterday, Today and Tomorrow"	01.07.2004 12:00 – 13:15	Room R
BOF008	Peter Koen "Hacking a Webserver"	01.07.2004 14:45 – 16:00	Room R
BOF008	Peter Koen "Hacking a Webserver"	02.07.2004 08:30 – 09:45	Room R
BOF009	Holger Schwichtenberg "Experiences with WSH and Other Windows Scripting Technologies"	01.07.2004 16:30 – 17:45	Room R
BOF010	Jackie Goldstein "Now What Are They Going to do to My VB"	30.06.2004 08:30 – 09:45	Room R
BOF011	Michiel van Otegem ".NET Coding Standards, Should I Use Them?"	02.07.2004 12:00 – 13:15	Room R
BOF012	Benjamin Mitchell "Service Orientation: What Does it Really Mean?"	01.07.2004 18:15 – 19:30	Room R
BOF013	Igor Milovanovic "Aspect-Oriented Programming (AOP) and .NET"	02.07.2004 10:15 – 11:30	Room R
BOF014	Hagai Schaffer "Accessing Legacy Application from within MS Office through IBF"	02.07.2004 14:45 – 16:00	Room R
BOF015	Ciprian Jichici "Reporting Services - The BI Reporting Platform"	02.07.2004 16:15 – 17:30	Room R

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.

John Bristowe and I are featured on MSDN TV enthusing about the launch of WSE 2.0.  It was filmed in the Cabana areas at TechEd 2.0.   Here's the blurb:

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.

You can also read the transcript.  You can tell that John and I aren't from Microsoft since we don't use 'so' enough when starting our sentences

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.

SecretGeek announces a sexy new methodology - TODO Driven Development [via Mike Gunderloy].  There's a full description of the process (there's even tool support in Visual Studio 2003!) and this at the end:

Does giving it a name make it legitimate? Can I write a book on this and do a lecture tour now?

Too funny. 

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.