Sorry to burst the party balloon, Ingo, but Cape Clear's runtime library has had XML, SOAP and Call interceptors built in as first class citizens for over 2 years since v2.0!
They have allowed our users to do all the things you describe, I think - pluggable transports, pluggable serializers, pluggable routng, pluggable message processors, pluggable message transformers, pluggable sub-protocol handlers, and pretty much pluggable everything else!
We even have partners shipping product written using this framework approach.
Nice to see .NET finally catching up! ;-)
Of course, using features like WSE or other forms of interceptors/plugins to implement the layered Web Services sub-protocols such as WS-Security, WS-Policy, and WS-* on top of a stable but extensible core runtime is the only way to build an SOAP/XML platform IMHO.
As part of my Web Services security tutorial, I present a module of the talk about the concept of Interceptor, how they fit together client-side and server-side, comparing and contracting .NET WSE, JAX-RPC (SOAP) Interceptors and Cape Clear's runtime interceptor framework, and how all this can be used to easily customize or add extensions to Web Service calls.
As Ingo says, it's definitely a cool approach.
All content is
Copyright (c) 2010 Jorgen Thelin. All rights reserved.
The opinions expressed here represent my own views
and not necessarily those of my current, prior or future employer(s).
Content is provided "as-is", without any representations or warrenties of any kind.
Contents of the Weblog Feed are
licensed under a
Creative Commons License.