Thoughts from integrating with WSDK. 

It shouldn't be very surprising that I am currently integrating my web services extensions with the WSDK with the goal of making that available shortly after WSDK ships. However, it's no as easy as I thought it would be, because the extensibility pipeline model that MS layered on top of the SoapExtensions requires a different approach for quite a few things that I've done. I could just leave my things the way they are and have them function side-by-side with the WSDK's pipeline (that works), but I want to take advantage of the pipeline's relative independence of the ASP.NET request/response cage, which I find increasingly limiting. Also, integrating Kerberos into the WSDK's WS-Security framework is a real challenge, because I may have to go all the way down into writing an algorithm wrapper based on the stuff in the System.Security.Cryptography namespace. However -- I really want to get this working and therefore I will ;)

A new terminology set.

While working on this, I have found that a lot of terminology that I am using here is massively confusing: "client", "server", "input", "output", "request", "response", "proxy", "stub", "endpoint", "router" and quite a few more terms are ambiguous and depend on your current point of view and on what you are just building.

I find it more helpful to focus on the message and look at it as something that starts empty, grows and shrinks (and grows and shrinks) as it goes through a unidirectional pipeline of message-part producers and message-part-consumers and whose processing ends when the message is empty again. Request/response is a special case where the message flow originates and ends at the same place. The pipeline elements (producers/consumers) are connected by local ("through the stack") and remote ("over the wire")  connectors. A server-side "request handler" as it's currently known is simply a message-part consumer taking stuff from the body and sticking stuff back into the body.

Here's the terminology set I am currently playing around with:

• Message Producer: Acts on information from the system environment or state and possibly adds information to a message.
• Message Consumer: Acts on and removes information from the message and possibly alters the system environment or state.
• Service Acquisition Filter: A message producer that acquires system state to flow information about a service (eg. picks up a COM+ transaction context or the current security principal)
• Service Enlistment Filter: A message consumer that reads and service information from a message and enlists into a service or creates a new service (eg. picks up a TIP URI and creates a service domain or creates a security context from a serialized authentication package)
• Fork: In case message processing cannot proceed without additional information or in case a filter wants to split the message into separate flows, any pipeline can fork off new pipeline instances to request information or flow information to additional destinations. A fork is blocking if it can't proceed in its current state and otherwise non-blocking.

A proxy is a message producer. A stub is a message consumer. A logging sink is a message consumer. A filter that adds timestamp information is a message producer. A filter that reads timestamp information is a message consumer. A client-side authentication extension (sending path) is a service acquisition filter. A server-side authentication extension (receiving path) is a service enlistment filter. The inverse of a "service enlistment filter" is just another "service acquisition filter", which acquires the service state and possibly disassociates the action from the service -- reversely, the same relationship exists.

Anyone still with me?

[Disregard the first two comments showing up below. The comments feature of radio is confused with my blog]