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.

One thought on “Channels 101: Get with the MEP

  1. jim

    great blog,I am looking for the next part of the really shed light on the indigo about what is going on under the cover


Leave a Reply

Your email address will not be published. Required fields are marked *