Freitag, 6. Dezember 2002

Lunchtime! IBM buys Rational.
2:34:30 PM      comments []

I updated my copyright notice at the bottom of the blog. The reason for that is that I found my blog to be replicated in full to another website in their design and with their copyright notice, without any backlinks to this blog and without having been asked for permission. 

I may offend a few friends over this, but there are friendly rules of conduct which I follow and on which I must insist: Quote liberally, aggregate, combine, analyze, but do not republish large portions of content in unaltered form and don't quote without linking back to the source. Brief legal excursion: There are explicit rules about what's permitted in terms of quoting other's works in just about every copyright law. The German Copyright Act and related international treaties are applicable here. For instance, it's no problem to take this entire posting and quote it elsewhere as-is. It is a problem to simply publicly republish the whole rss-feed content elsewhere. Quoting and commenting is a good thing, plain theft of intellectual property isn't.


12:41:27 PM      comments []

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]


11:17:11 AM      comments []