In preparation for the London Bloggers Dinner with Don Box and Chris Anderson on Monday (see the report of this dinner, and what went on at the pub afterwards), I thought I’d get up to speed and make some notes of the key points made in Don’s interview on the ServerSide.NET.  To my mind this is the best interview I've seen or read about Indigo.

I'm posting these notes mainly so that I can have them handy in SharpReader when I'm offline and in case others might find them useful.  You can see the interview and download the full transcript on the ServerSide.NET site.

What is Indigo? 

• A connective tissue between programs.  It makes it simple for developers to put a message oriented façade on the edge of your application to allow easy communication with others.

Positioning Remoting and ASMX web services

• The problem with .NET remoting was that even though it supported interfaces, it really worked best when both ends of the pipe shared code such as assemblies or DLLs to integrate.  Sharing types like this turns out hard to manage because you often don’t have control over the deployment versioning and testing at each end of the pipe.
• ASMX Web Services (including WSE) are more flexible because they use WSDL and schema which is more adaptable to change than the OO style type interface used in remoting.  ASMX is proving more popular than remoting in the field because it is actually a simpler model and simplicity is a feature.
• Developers should go down the path of integration using messaging because it is simpler and more flexible, but support for remoting won’t go away.
• You don’t have to use XML Schemas and WSDL to describe structures and contracts, but that’s the practical way that everybody does it.
• The problem with components was that they tried to do the right thing separating interface and implementation, but it was too easy to ‘leak’ object concepts and require the sharing of types.

Do components have a place in the world?  

• Don argues that the world is simpler if you think about objects, which are great for programming software that gets integrated, tested and deployed, more or less as an atomic unit and services, which are the central abstraction for deployed, autonomous pieces of software.  Given this perspective he suggests there may not be a place for components.

What’s the difference between service-oriented programming and service oriented architecture?

• SOA is the buzz word du jour, system message bus will probably be next, whereas service-oriented programming is more focussed on the reality of the code.
• Service oriented programming is about four ideas:

1. Boundaries are explicit.  In Indigo you have to place attributes on your code that you want publicly exposed
2. Services are autonomous.  Indigo doesn’t assume you’ll deploy a whole system as a single unit.  Each service should be secure and reliable as a stand-alone unit.
3. Share schema and contract, not class.  It’s too easy to mix up interfaces and implementation, so it’s a better idea to separate schema and contract into two distinct ideas.  Schemas are defined in XML Schema language, and contracts, which are message exchange patterns, are defined in WSDL.
4. Compatibility based on Policy.  To know that services are compatible you have to care about other things than just the signature of the messages.  WS-Policy is supported in Indigo and provides a way to share this over the wire in an interoperable way.

Does Policy impose versioning restrictions?

• Policy is similar to marker interfaces in Java or C#.  You have to have a stable name that is immutable that is decoupled from the actual signatures.  Both parties have to agree on the name and it has very strict version requirements.
• WS-Policy provides a way to declare compatibility with any number of versions of a given policy assertion.  The logic engine is able to determine if party A’s assertion lines up with party B’s assertion.
• In the PDC bits you can see the first message sent on the wire is a ‘get policy’ message.

Can policy be used to create versioning schemas?

• There are three policy specs:

• WS-Policy which is the XML form for writing a logic expression
• WS-PolicyAttachment, which provides a way of taking those expressions and applying them to a particular domain
• WS-PolicyAssertion which contains a small number of concrete assertions that plug into the expressions defined in WS-Policy.

• WS-PolicyAssertion contains an assertion called Spec Version that can be used to determine compatibility at the naming level.  It’s looser than strict or nominal type equivalence that is used in C# and Java.  It provides some flexibility, not complete flexibility and Policy is used to do the version negotiation.

Are there situations where the Indigo approach doesn’t work well?

• In future the service-oriented programming model may be a practical way of doing things like cross-process, cross-app-domain or even within a single exe.
• The focus is making sure Indigo has a solid model that can be implemented and scale down well.  Objects took a ‘near’ metaphor and tried to stretch it out, Indigo is trying to take a ‘far’ metaphor and shrink it.  Indigo is striving to have very low performance costs within a single exe.

What are the performance optimizations being worked on now?

• The team is very focused on make sure that the I/O implementation is as well tuned as possible.  They want to make sure we can get bytes in, in XML and other forms, in to and out of an app domain as fast as humanly possible. 
• They want to make sure that it’s not tied to a specific protocol, such as HTTP.
• The idea is ‘I create a message here, I need it to appear in your program as fast as possible’.
• Performance is an important goal for the first release.

WSE and Indigo

• WSE is the vehicle to give developers access to implementations of the WS-* protocols as quickly as possible.
• The goal is still to integrate them into the .NET platform, but sometimes the platform has to ship before standards are set, which is why WSE will have a future post-Indigo.
• Post-Indigo WSE may be used to track protocol evolution on top of the Indigo infrastructure rather than just the ASMX infrastructure.

Will Indigo do anything new at the wire level?

• Indigo is about the software productization of ideas (such as the WS-* specs) rather than interesting new wire protocols.  For example, transactions on the wire will use WS-AtomicTransactions but within the service they are doing a lot to make transactions easier to use from managed code with extremely efficient implementations.

What's a Microsoft Regional Director?  Fellow RD Jon Box answers this well.  Clemens also has a good post. Basically Microsoft Regional Directors are independent developers and architects, volunteers chosen for their leadership in their local technology circles. You've probably seen many of them at conferences, read their blogs, or heard them on .NET Rocks.

I'm looking forward to continuing to spread the word about .NET, web services and Indigo in the coming year.  As shown on my presentations page, I'm doing a talk on WSE to the VBUG group in Ipswich on Feb 3, then a talk on Indigo in London to the .NET UK user group on Feb 23.

John Bristowe, recent MVP, fellow YAWP'er and lover of Australian Red Wine posts about his conversion of another person to the love of WS-Policy.  I've been a long-term (well for around six months, which qualifies as long-term in WS-* land) lover of Policy. Policy just keeps getting better in Indigo with metadata exchange in Indigo, but the movement needs to start now.  I think we need a slogan or song.  'People for Policy' or something like that.

John also cheekily suggests that I may have a 'showdown' with Klaus Aschenbrenner after his article on WSE 2.0 security.  I'm more that happy to share the SoapContext with anyone else who's into WSE - there's always room for more pipes and filters in the message pipeline!.  Also from John's blog I've discovered Morten Abrahamsen is doing a great job blogging about WSE topics.

Wow.  4 posts in a single evening - I'm feeling a bit Robert Scoble all of a sudden.

If you care about designing web services and believe in the 'share schema and contracts, not class' mantra then you'll be interested in XML versioning.  I mentioned pre-PDC that this was a big issue.  At the PDC Doug Purdy presented one approach that Whidbey Indigo will use to enable versioning with web services.

Just this week Dare Obasanjo has published 'On Versioning XML Vocabularies' and tonight I noticed that Dave Orchid from BEA also attacks the topic with his post 'Providing Compatible Schema Evolution'. 

In fact Dave Orchid's whole site seems excellent (it's my weekend homework since I've only recently subscribed and his feed doesn't contain the full articles so I can't read him on the train).  One good point I noticed was in this post:

'Schema authors tend to make tightly coupled Web services because they can't fully version or evolve them'. 

Avoiding this problem will be key if web services are to realize the promises they are offering today.

Russ Lewis blogs about David Sussman's ASP.NET 2.0 talk at the London DNUG last night.  I was off on a Microsoft Solution Framework training course with Axxiant so I couldn't make it, but Russ has done a great report.  In the comments he left on my site Russ says that it was one of my YAWPs (Yet Another WSE Presentation) that made him start blogging. 

Good to see that I'm encouraging the community in my own small way.  Keep up the blogging Russ!

Microsoft have four buildings on a large business park alongside Oracle (who have more buildings, highlighting one difference between companies).  The Microsoft campus is as much like a university as the real world can get.   I'm surprised by how much I enjoy being able to wear jeans to work, and how different it is to see everyone in casual clothes (too long around banks and large companies).

Ever since I read Peopleware I've been interested to see how quality companies organise their workspaces.  Joel Spolsky has written about the importance of developer offices and how an architect designed the Fog Creek offices.

The Microsoft buildings are light and spacious with desks around the windows of the building and meeting rooms in the middle of floors - so everyone has a good view of the outside world.  There's the standard (or dot-com standard) Aeron chairs and wireless networking inside the building.  I read somewhere they even change the air in the air conditioning system more regularly than most offices (so there is something in the air).   Perhaps it's no wonder Microsoft have won the number one place to work in the UK for the last two years.

There's also the standard Microsoft perks like the free soft drinks, several cafés, a pool table and table hockey (seeing all of this transported me back in my mind to my dot-com days around Sydney).  I found it hard to get used to the idea that it's probably a good thing for people to be able to relax and enjoy themselves at work.

As Matthew Reynolds reports, Microsoft have recently had Ricky Gervais, aka David Brent from The Office do a motivational video.  The large 'motivational' posters containing his photo and quotes in the hallways have distracted me several times.

Rory would be pleased that the toilets are very clean and pleasant consistent with his bathroom report from Redmond.

From Ted Neward's blog comes the news that he's now the Editor-In-Chief for the new .NET community site TheServerSide.NET.  It's the .NET port of the TheServerSide, a vibrant Java community, but it's backed by companies such as Microsoft and Developmentor.  Ted's aiming to do the following with the site:

1. Create a place where the hard questions can be asked.
2. Promote J2EE/.NET interoperability.
3. Promote open source .NET projects.

Some good points already:

• An excellent sets of interviews, with transcripts, such as Don Box on Indigo, Scott Guthrie on ASP.NET and some guy from Borland. 
• A good set of articles from DevelopMentor trainers such as:
  •  Justin Ghetland on Unit Testing in .NET showing a Visual Studio Addin that still has the NUnit green and red traffic lights.  Any thoughts Jamie Cansdale?
  • Stuart Charlton on Autonomous Services dealing with SOA and the ROX holy trinity of relational, object and xml technologies.
• Pre-release chapters from the Microsoft Patterns & Practices group on Remoting and Managed Code Performance.

This looks like a great addition to the .NET community and already has some quality content.  The only downside, and this is a major one in my view, is the lack of an RSS feed - the front page only has an RDF feed that wont work in SharpReader.   What's going on there?

At last night's Extreme Tuesday Club meeting we talked about the use of Gold Cards as a way of handling problems that can arise in successful Extreme Programming teams.  The idea of Gold Cards was presented in this paper from XP Universe 2001 which came out of the original Connextra team (an early and influential London XP team).

When an XP team is functioning successfully and doing paired programming, frequent releases and working at a constant it can be difficult to find time to do individual investigation on new approaches to problems.  There are several difficulties for a successful XP team:

• It can be difficult to take time out and think about new and innovative approaches to a problem.
• Often innovative new ideas come from individuals thinking laterally rather than a team focussed on task completion.
• Sometimes pairing and the team work made it hard to highlight positive contributions of individuals, or to handle performance reviews.

The Gold Card was a way of overcoming these problems.  The index card is a core part of XP planning, used to write User Stories and drive development.  The Gold Card is simply an index card that allows a developer to spend some a day of solo time investigating a topic of their choice, ideally with some business benefits.  They used this system:

• Each developer had two Gold Cards each month, so about 10% of work time.
• During the morning stand-up meeting a developer could elect to use the Gold Card
• The developer writes on the card what they want to achieve and provides an update at the next morning's stand-up meeting as well as on the Wiki.

Part of the discussion last night was how one global financial bank allow their developers to do skunkworks style tasks on Friday afternoon.  Gold Cards provide a mechanism for time-shifting this idea.

Gold Cards helped promote a 'praise culture' within the group.  It also proved a successful motivation tool.  On top of this there were significant business benefits, such as reducing project risk, increasing development efficiency and most surprisingly, generating a business opportunity that became the company's major product.

Finally, Ian Griffiths has a blog (RSS).  For those not in the know, Ian is UK-based, a Developmentor trainer, an O'Reilly author, a co-author and friend of Chris Sells, an associate consultant with my company, Axxiant, and the guy who interviewed me for my job at Axxiant (there was a stressful interview).  Ian also writes great email.

Glad to see his great sense of humour is already shining through in his recent post:

"I used to know a lot about C++ ... not only did I buy my own copy of the C++ spec, I actually referred to it from time to time. How sad can one man get? Despite this, I continued to learn new and often surprising things about the C++ programming language on an alarmingly regular basis, right up until I discovered that I preferred C#."

I recently came across Fate Hani's Bile Blog on the Java Community (via Joe Walnes, an XTC attendee who's book was biled).  It's opinionated, rude, mostly negative, full of overgeneralizations and contains some foul language.  It is also sometimes informative, entertaining and funny.  Imagine a darker version of Rory who swears and has a bad attitude. 

Some topical posts that give a feel for the site's contents:

• Die petstores die.  The world has enough pet stores already.
• The codehaus of crack.  I mentioned this group in a list of things I liked (from afar) about the Java Community.  Seems that all communities have their good points and bad points.
• Mock obsession.  Mocking frameworks like JDBC isn't the way to go.
• FOAF can FOAD.   Echoing Jon Udell's thoughts that this isn't the way to go.
• ThoughtWorks: The new BodySnatchers.  "The training program at ThoughtWorks must be a modern day marvel of human engineering. It takes in as input fresh young bodies, and at the other end spits out those same bodies with their previous mental contents erased, to be replaced with one of the six possible variants of the MartinFowler template."

The Application Integration and EAI Architecture guidelines I mentioned in the last post seem to me to be an answer to Michael Earl's Plea to Microsoft Architects because they talk about problems that really matter today and how you can apply currently-shipping technologies to solve these problems.  The guidelines have contributions from a great bunch of Microsoft Architects (at least I think they qualify for this title) such as Maarten Mullender, Keith Short and Pat Helland (who have given some top presentations at TechEd and PDC recently).

Don Box has already responded to Michael by saying he'd like to see a list of top 10 MSFT bloggers who are focussing on helping people apply shipping bits to the problems that matter.  I agree, but think part of the problem is that many of these guys aren't blogging but are writing great content for MSDN Enterprise Development site (nice reorganisation) or the Patterns and Practices group.  For better or worse, blogging seems better suited to short, time-relevant information such as thinking about the design of upcoming technologies.   The problem is that blogging helps make a topic seem alive and current and creates a sense of community.  It would be nice to combine these benefits of blogging with high quality content already available.

Adding life to the Patterns and Practices content
I'd like to see some way of using blogging and the community to increase the value that comes from the Patterns and Practices and MSDN material.  Every time I go back to it I'm impressed with the content, but sometimes it seems impenetrable, and well, a little dull.  I wonder what can be done to bring it to life and get more dialogue going in the community? 

I know that the Patterns and Practices group are now doing webcasts (disclaimer: I haven't had a chance to participate yet). Perhaps there could be some more focussed community involvement or debate around the architectures or concepts?  I know that Shadowfax, the Patterns and Practices group's project to apply service oriented solutions with currently shipping technology, is available for download.  Perhaps there could be some key questions the group are looking for feedback on?

Perhaps there needs to be a pub architecture club, similar to the Extreme Tuesday Club (now open in Brisbane, Australia).  Either that or find some way to get the like of Pat Helland or Maarten Mullender to start blogging?

The ever-active Patterns and Practices group have released Guidelines for Application Integration focussing on EAI Architectures.   It provides useful coverage of all of many of the issues involved in integrating applications.

The guidelines covers the levels of application integration, such as business process, data and communications-level integration.  It defines the capabilities required at each of these levels.  It also covers security and operational considerations before finally showing how to map Microsoft Technologies to application integration capabilities.

The guide is useful because it deals with concepts from an abstract perspective rather than a technology-centric approach.  All of this is likely to be useful in a service-oriented (it's just not PC to say SOA anymore) world.  The architectural concepts and business issues identified are independent of the technical implementations such as Indigo.

Apologies for the lack of technical content of late (and in this post).  Today I finished my engagement on the project that involved a 4 hour commute, tomorrow I'm flying to Gifhorn, a small town in Germany, to spend the Christmas week with my wife and her family.  I'm hoping to have more time and energy to blog again in the New Year (before our first child is born in April)

Happy Christmas to everyone in the blogosphere.

Mary and Tom Poppendieck's have a book on Lean Software Development that's really excited me of late.  I was reading it while I was thinking about how the project I just finished on could be improved in future iterations.

Lean Software Development takes ideas from Lean Manufacturing can be applied to software development.  Their website has an excellent range of presentations and publications.  The one I first read, which I think is as good as the book, is 'The predicability paradox'.  It goes through their eight keys to lean thinking:

• Start early. Focus on establishing good communication between the group and about the problem.
• Learn constantly.  Look for end-to-end slices of functionality that you can build, test and deliver to learn more about the problem.
• Delay commitment.  Use encapsulation, loose coupling, refactoring and automated testing to make it easier to change code.
• Deliver fast. Focus on being able to deliver fast (e.g. automated build and deployment) through excellent operational discipline (source code control, build tool) in order to get quicker feedback.
• Eliminate waste.  Focus on customer value and remove wasted processes.
• Empower the team.  Avoid central control, focus on self-directed workers.
• Build integrity in.  Write the tests at the start.
• Avoid sub-optimization. Sometimes breaking a complex task into small parts leads to sub-optimum solutions.  Make sure you measure the right things and set the correct goals.

For some reason this just seemed to speak to me in ways that some of the other writing on Agile/Extreme hasn't in the past.