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.