Following on from my previous post about Indigo and .NET's context architecture, it seems we may have the answer as to how a rich services framework (Indigo?) is going to be made easily accessible to users... call context...
“Object context is affiliated with a specific object (or set of objects) independent of which methods are executing on that object.
Call context is affiliated with a logical control flow independent of which objects may be involved in the flow.
In Indigo, we're orienting more on call context than object context - it's simpler for developers to grok as well as more amenable to the service-oriented design style.“Don Box
Alintex Script .NET 1.2 is now available for download at www.alintex.com.
This release includes the following new features:-
- Improvements to the display of the script's public interface when using the /types option.
- Integration with the Windows shell allowing one to right-click a script in Windows Explorer in order to:-
- An optional Command Prompt menu item can be added to the Windows Explorer context menu.
Please see the What's New page in the Online User Guide for further information. The online Product Page contains a feature list and links to further information.
Alintex Script .NET is free for personal use. Commercial use of this product, which includes any use within a commercial environment, requires the purchase of a commercial license.
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.