Monthly Archives: April 2005

Tradition, tradition!

Lauren and I are hosting a (non-)traditional “8th night seder” on Saturday, and I’ve never made charoset before. So I e-mailed my Mom for the recipe and here was the response:

Apples, nuts and cinnamon, make charoset chop chop chop. Also wine, brown sugar vanilla extract if you want. Enjoy.

Love ya,

The thing I love most about family recipes is the exact proportions. 🙂

Channels 101: Get with the MEP

Last week I gave an overview of Indigo layering. In the next few posts I’ll guide you through these layers from the bottom up. We’ll start by writing a custom transport. Then we’ll add layered channels on top of this transport, and progressively work our way up the stack to a typed Service and Proxy implementation.

A fundamental concept at the Channel Layer is that of a Message Exchange Pattern (often referred to as “MEP”). There are three basic MEPs supported at the Channel Layer:

  1. Datagram: In this MEP, messages are “fire and forget”. It’s like when I send a postcard to my Mom. Just because I put the postcard in a mailbox does not mean that she received it. It may have gone to the incorrect address, or thrown out in the post office if she was on a long vacation, or eaten by a dog. I need to get any confirmation of successful delivery out of band (with a followup telephone call for example). Datagram is a fundamental building block for Messaging, as you can build arbitrary protocols on top of it (including reliable protocols, secure protocols, etc).

Datagram Message Exchange

  1. Request-Response: This is the most common MEP on the web today. It consists of a single message being sent, followed by a single response to that message. RPC calls are request-response, as are browser GETs. If I had paid for Delivery Confirmation on the postcard I sent my Mom, then I would have been using this MEP (with the confirmation as my response). This pattern is also known as half-duplex.

Request-Response Message Exchange

  1. Duplex: Duplex is equivalent to bi-directional datagram communication. Duplex communication is what we are used to in daily conversation. When I’m talking to a co-worker, we are free to speak at any time. We can comment at any time, and are engaging in an unrestricted ordering of “messages” between us. Note that delivery is still unreliable, and data can still be lost (if one of us is daydreaming or otherwise distracted).

Duplex Message Exchange

Each of these MEPs also have a session-ful variant. A session is an object that provides correlation for the MEP. Session is very useful for classifying data. It turns out that we use the concept of session constantly in our daily lives. Take as an example the conversations I have with my boss. As per our above definitions, when we converse we engage in Duplex communication. During a daily triage meeting we’ll talk about current issues for Indigo, and over lunch we’ll discuss the 520 commute. Each of these topics can be thought of as a session that subdivides our communication. While in the real world sessions often bleed into one another, in Indigo we can keep your session state localized to a given Channel. This gives you a total of 6 MEPs (Datagram, Request-Response, Duplex, Datagram+Session, Request-Response+Session, or Duplex+Session).

Some transports support multiple MEPs. For example, SOAP-over-TCP supports Datagram, Datagram+Session, and Duplex+Session. SOAP-over HTTP supports Datagram and Request-Response.

For our example, we are going to build a transport based on the User Datagram Protocol, so the MEP we will support is Datagram. The next step is to create an IChannelFactory and IListenerFactory to implement our Channels.

Spam Wars!

Senior year of college, I took a class on “Web Programming in Java”. One of the projects was to create a promotion site for a fictional movie. I came up with:

You need to have Java installed, and I apologize in advance if there’s a broken link at the end of a game (you may need to replace “” with “”). If I can divine my old password to the system (I didn’t even realize the site still existed until today) I’ll try and fix it. Until then, have fun with some crazy Kenny Wolf humor.

Baking a Seven Layer Service Cake

Indigo is constructed with layering as a central design principle. This means that in essence Indigo is actually a collection of sub-frameworks, each of which can be supplemented by ISV code (or replaced completely for that matter). Each framework is defined by two things:

  1. Fundamental unit(s) of data
  2. Transformations that can be applied to said data

Which (as you might be thinking) is another way of saying an object is defined by its members and its methods. This is true, but it’s more difficult (but very important) to stay focused on consistent pivots when constructing clean frameworks.

MessagesIndigo is built around the concept of a Message object. The structure of a Message object loosely represents a SOAP envelope, and consists of two distinct parts: the message’s body and an extensible collection of headers. The body is application-defined data, and headers are added/processed by infrastructure (and can also be used by the application). Access to a header or the body is achieved through XmlReader, as it contains structured data. It is this structured primitive which is the core of Indigo’s power (and which departs from the classic networking primitive of a byte array). It allows for extensible, interoperable protocols to be built, and for data contracts to be established.

At a high level, Indigo consists of two larger frameworks: the Typed Layer, and the Channel Layer.
Indigo Architecture

The fundamental unit of data for the Channel Layer is Message. Channels are used to Send and Receive Messages. Channels come in two forms: Transport Channels and Layered Channels.

Transport Channels perform the actual send/receive of the Message to a network resource, including any necessary serialization.

Layered Channels perform a function based on the Message passed in, and then delegate further modification and transmission to their Inner Channel. So as you can see, even within a layer we have layers 🙂 Some examples of Layered Channels include Protocol Channels that use Message headers and infrastructure Messages to establish a higher-level protocol (such as WS-ReliableMessaging), and Reshaping Channels for changing the Message Exchange Pattern (such as converting an underlying [Send Channel, Receive Channel] pair into a Duplex Channel).

Message is a very flexible object, but to fully utilize it requires knowledge of Infosets and XML. What most developers instead will likely interface with is the Typed Layer. The fundamental unit of data for the Typed Layer is a CLR class. In the Typed Layer you create CLR objects that implement Services and Typed Proxies. The Typed Layer converts parameters and return values into Message objects and method calls into Channel calls. In this way, the Typed Layer builds on the functionality of the Channel Layer, and can transparently leverage any changes/improvements made to Channels.

Next I’ll provide an example to give you a flavor of this layering in action, stay tuned!

Stick 'em up!

Never a dull moment in Redmond, WA. At 5:30 I pulled out of my garage to scoop up Lauren and head home. And hit bumper to bumper traffic right outside my building (for the first time in 5 years). About 10 minutes (and about 1000 feet) later, Lauren informed me that there was a robbery at a nearby bank. First time the FBI has laid foot on Overlake plaza I bet!

What's on your mind?

Releasing the Indigo Preview has involved a mix of excitement and angst. It’s great to be able to talk publicly about a product I’ve toiled so long on. Yet I’m most curious (and I’ll admit, a little nervous) to hear what parts of Indigo users really like and, just as important, those areas where we’ve fallen short.

Fortunately we have 2 great areas for you to provide feedback:

  • The Indigo newsgroup ( winfx.indigo). Posts are being actively monitored by both the product team and other Indigo early adopters. It’s a great forum for asking questions about your prototypes or having a general discussion about Indigo design patterns.
  • Ladybug (more formally known as the “MSDN Product Feedback Center”) is available for reporting bugs, making suggestions, and tracking feedback. Bugs filed here make it back to us in development so that we can fix them! Remember to choose “Indigo” in the Product/Technology dropdown when you enter your issue.

So take a spin, and please let us know what you think. Operators (or at least developers, PMs, and testers playing the role of operators) really are standing by.

Work your Cardio!

Lauren and I spent yesterday afternoon in front of the X-box. But instead of kicking alien butt in Halo 2, we were the ones getting our butts kicked by Maya, the innocent looking personal trainer of Yourself Fitness. The game will utilize whatever props you have around the house (hand weights, step, exercise balls, etc), and target a 45-60 minute workout for cardio, flexibility, upper, or lower body workout. Yesterday we did the upper body workout with hand weights. In 45 minutes I was more worn down than from my normal 90 minute gym run. Maya provides inspiration (“work your cardio!”), but is also relentless (“I want you to feel muscle fatigue with this one”, “do it right!”). She never needs more than 10 seconds of rest, so why should you? While I was skeptical at first, I must say that it’s a killer workout, and awfully convenient to fit into your schedule.

In related news, it seems Dance Dance Revolution has gotten recent press on its health benefits, and is even being used in child weight studies. While I can see DDR working your cardio, after experiencing nonstop sets of lunges, squats, and curls, I’d put my money on Maya in a head-to-head jelly your muscles competition.

Who wants to work on Indigo? I do!

A couple of things attracted me to the Indigo team 3+ years ago. First was getting to work on a fully multi-threaded, asynchronous distributed platform, and the technical challenges inherent in such a project. The second was helping design interoperable WS-* protocols and work with other vendors to get our platforms to interoperate. But most important was the story behind the fly codename, which goes like this:

In the beginning there was a Web Services project at Microsoft started under the codename “Green”. Then on a sunny day in the fall of 2000, inspiration struck. Two of the founding members of Green (Robert Wahbe and John Shewchuk) were driving on 101 south of Mountain View and passed the following billboard:

Indigo Billboard

Robert and John knew they had found a winner. They returned to Redmond with the new codename proposal and it has stuck to this day.

If you want to help me, Don Box, Brad Lovering, Martin Gudgin, Steve Maine, Mike Vernal, Doug Purdy, and others ship Indigo, we currently have about 20 jobs available in development, test, and program management.

Bindings vs. Transports, live on ESPN

If you’re not familiar with the “ABCs of Indigo” (Address, Binding, and Contract), please click here for background on some basic Indigo terminology and concepts.

When users first start playing with Indigo, there are two common approaches to the system: those that want to trace a message exchange from the “top” (by building a Service), and those that want to start at the “bottom” (by tracing the Message as it enters the system and makes its way up to the typed ServiceMethod). Those in the latter camp generally start by hunting for transports, which put your messages on the proverbial wire.

A few notes about transports in Indigo:

  • Transports need to be considered in the greater context of a binding. A binding is simply an ordered list of binding elements. There are binding elements for reliability, security, transaction flow, and transports. When I talk about a transport (such as HTTP), you will likely be interfacing with it through its binding element (e.g. HttpTransportBindingElement).
  • Indigo includes 4 transports in the Community Tech Preview:
    1. HTTP (for cross machine interoperable messaging)
    2. TCP (for cross machine Indigo to Indigo messaging)
    3. Named Pipes (for on machine Indigo to Indigo messaging)
    4. MSMQ (for queued messaging)
  • Transports are responsible for encoding+transmitting messages (on Send/Request), and receiving+decoding messages (on Receive/ReceiveReply). Indigo is architected so that transports can delegate the task of translating between a Message and a byte array to an encoder.
  • Indigo includes 3 encoders: Text, Binary, and MTOM. Each encoder is associated with an implementation of XmlReader and XmlWriter, as well as a SOAP version. By default, HTTP uses the text encoder, and TCP/Named Pipes use the binary encoder. However, an Indigo transport can be used with any encoder (either built-in or custom).
  • The combinatoric possibilities involved in constructing a binding can be staggering, so Indigo includes a small number of predefined bindings that you can use for most common scenarios. The documentation gives a good high-level overview of what scenario each binding is intended for and the various tradeoffs inherent in using each one. Each predefined binding has a transport binding element associated with it, though it may only expose a subset of the properties available directly on the transport binding element itself.

While Indigo at its core is “transport agnostic” there are of course implications to choosing each transport. Up next, I’ll discuss what some of these implications are in a home networking scenario.