Speculating on Indigo and .NET's Context Architecture

Indigo is a codename for a new technology being announced at the Microsoft Professional Developers Conference (PDC) in October 2003

Amongst the many problems limiting the wide spread use of web services, has been the lack of supporting infrastructure relating to (amongst others) security, addressing and policy. 

With that infrastructure now largely in place, and with a new emphasis in Web Services Enhancements (WSE) 2.0 on web services being about standards based contracts between services (XML messaging), rather than the calling of methods (RPC over HTTP), the stage is surely set for the release of a (non-web method based) services framework.  A framework that architecturally removes the “web“ from “web services“ by being transport independent.  Where you can apply rich WS infrastructure to services no matter where they are - in-process, on a network or on the web.

But a services framework is worth nothing (in the wider community) without a way for developers to easily apply it.

My guess, therefore, was that Microsoft would release an easy to use, rich services framework based on WSE 2.0 and .NET's context architecture.  One where a developer could apply an aspect of a service through a context attribute.  Other than through an aspects based solution (AOP), how else can you provide functionality (other than through inheritance) to existing code?

However, Don Box's statement about .NET's context architecture being a “dead end“ would seem to indicate that using context attributes might not be the way.  Certainly the issues with AOP on procedural code would leave such an implementation fragile.  Are all those aspects truly orthogonal?  IsContextOK?

Perhaps the answer is a reflection attribute based SOAP extension mechanism - next month will tell.