Yasser Shohoud

What I've Been Up To

2009-02-17T18:21:00Z

I've been away from blogging for a loong time so have some catching up to do. I spent most of last year building out the new Dallas Microsoft Technology Center while delivering customer engagements and working on a few side projects. The MTC build out is mostly done (a few items remain but I'm spending little time on it) and has turned out pretty nice. You can see a synth of the reception area here but you really have to come visit and see it for yourself. Recently, the Dallas Morning News wrote a nice article about the Dallas MTC and what we do for customers. On Friday 2/13, we hosted a minority students day here in the Microsoft Las Colinas campus (see here) and we had the kids visit the MTC where we exposed them to different careers within the tech industry. It was a lot of fun and I was surprised a few times to find out that kids have used our technologies e.g. XBox 360, Zune, Windows movie maker (hey maybe we're doing good marketing with this age group after all!). The local NBC channel was here and some of us were on the news that night.
Now that the facility is built, it's time to shape and define my team and make sure we stay sharp and on top of our game. As for what I'm doing now, I'm still doing customer engagements mostly around .NET architecture and development and SharePoint. I'm also getting a lot of exposure to infrastructure including server/storage hardware and networking as I manage the partners that provide us with equipment for our MTC. Just recently I was recruited to help build the next generation MTC tools on Dynamics CRM so I'm about to start learning CRM.
Outside of work, I've started school again, this time for an MBA. My first course is on Operations Management which I'm finding quite interesting thus far. I'm planning to be done in 3 years assuming I can take 5 courses per year which hopefully I can do.

Big week for Dallas MTC

2008-11-15T21:27:00Z

This week is shaping up to be a big week for the Dallas MTC. Monday we have our official launch party where we expect 285 attendees from Micrsosoft and partners (we've been operational since 10/6 but we're now making it official). Then Tuesday thru Thursday we have the World Wide MTC Summit where managers from all 16 world-wide MTCs get together to share best practices and plan for the year ahead. Thursday and Friday we have another major event with the MTC partners. Not to mention a few customer engagements going on next week as well. It'll be crazy busy and lots of fun :-)

Getting back into blogging

2008-11-07T17:36:00Z

It's been over a year since I last blogged over on yassers.com. I'm trying to get back into it now and will move my blog back here to MSDN blogs. I know what you're thinking: "he moves around too much" and I agree with you :-) Not only am I moving my blog for the second time in as many years, I've also physically moved twice in the last two years. The first move was when I moved from Seattle (where I worked on the WCF team) to Austin (where I worked on the Austin Microsoft Technology Center team). About a year after that, Microsoft decided to move the Austin MTC to Dallas for very good reasons. So I picked up and moved again to the Dallas area (I live in Grapevine, TX which is about 12 miles from the office in Irving, TX).

I spent most of the last year building out the new MTC in Dallas and we just recently moved in. It's an awesome place to work and I'll be blogging about that more in the weeks to come. I also plan to blog about the various technologies we have at the MTC as well as some of the new technologies Microsoft is announcing. Thanks for reading!

Blog moved

2006-09-14T04:34:00Z

I've moved my web site and blog to yassers.com. The blog is at http://blog.yassers.com. Some of the more recent entries on this blog (the ones included in this blogs current RSS feed) are duplicated there as well.

What Exactly Is BizTalk?

2006-07-25T21:21:00Z

I now work as a Technology Architect at the Microsoft Technology Center in Austin which is part of the Microsoft Sales org. In this role I help customers understand how to architect solutions to their business problems/needs using Microsoft technologies. As a result I'm learning a lot of technologies that, as a member of the WCF product team, I just wasn't focused on in the past few years. When I learn a new technology I like to start by coming up with (or learning) a short and accurate description of that technology's focus, i.e. what is it for?

One of the technologies I'm (re)learning is BizTalk Server. So I looked around for a short and accurate description of what BizTalk is. I knew what it was, but I wanted a 2 - 3 sentence description. I found some interesting documents like the BizTalk Overview and David Chappell's excellent Understanding BizTalk Server 2006 (a must read). While those docs offered valuable information, I couldn't find the sentences I was looking for. This is probably due in part to my coming from a development background and wanting to relate things back to the developer world. So I came up with this short and, in my opinion, accurate description:

BizTalk is to business process automation what Visual Studio and the .NET Framework are to application development. It is a runtime and tools that enable you to automate and manage business processes more productively.

That's basically it. If I only get 10 seconds to explain what BizTalk is to a customer, the above description is what I'm most comfortable with. If I have more time, I would elaborate on that description as follows.

The term "application development" is worth further exploration. Looking at the kinds of applications that people build with Visual Studio and the .NET Framework today, the vast majority are focused on specific tasks rather than end to end processes. Not to say that such applications are isolated, they're actually often connected to other apps or data sources via Web services or other means. But the focus of the app is to automate a particular task or set of related tasks and the connectivity serves that purpose. However the business reality is that businesses run on processes which span multiple tasks and of course people. So to automate a business process end-to-end you wind up wanting to connect some of the applications that were written to automate the tasks that make up that business process. As an example, consider the task of updating contact information in the company's address book for a newly hired employee. That employee may launch a .NET desktop app or go to an intranet Web site and enter they home address, cell phone number, emergency contact etc. Now zoom out and look at the big picture and what you see is an end-to-end on-boarding process that includes things like provisioning credentials, certificates, smart card, automatic deposit setup, hardware procurement, office furniture procurement, 401K account setup, setting up a mentor, and the variety of other things a new employee needs to get/set up. The address book update app automates one task in the end to end process but there's no app that automates the entire process. BizTalk Server allows you to connect existing apps that automate the various tasks of this process and automate the tasks or parts that don't yet have automation to form a complete end-to-end process automation solution. It also gives you an operational or runtime view of that automation allowing you to see all the moving parts from one vantage point and start/stop/change/maintain them.

While it's certainly possible to build VS and .NET apps that automate end-to-end business processes, it's not the most productive use of the customer's/developer's time because they'd have to reinvent (or re-implement) several wheels in the process. It's a bit like building an document management Web site using nothing but ASP.NET: You can do it, but you can do it a lot better and faster if you used Windows SharePoint Services (WSS). The operations folks would also love you for it because of the management features they get out of the box with WSS.

Living In Austin

2006-06-25T16:47:00Z

On Saturday 6/17 I boarded a flight from Seattle to Austin and I didn't have a return ticket. You see, for family reasons I moved to Austin and joined the Microsoft Technology Center. The goal of the MTC is to help customers map their business problems to solutions based on Microsoft products and services. MTC Architects work with customers in three primary ways: Strategy Briefings (1day), Architecture Design Sessions(2days), and Proof-of-Concept Workshop(2-3weeks). You can read more about these activities at the above link, but basically they are about giving the customer the big picture of Microsoft technologies that can help with their business problems, drilling deeper into customer needs and architecting a solution to meet those needs, and building a proof of concept of that solution with the customer's own developers.
Needless to say, this role is quite different from my previous role on the WCF product team and I'm excited about that change and looking forward to spending a lot more time with customers and getting first hand experience with the customer-facing side of Microsoft. It's only been a week but I'm already having a ton of fun. For my first two weeks I'm shadowing Christian Thilmany in a POC based on Windows Sharepoing Services and Microsoft Office Sharepoint Server. Both technologies and in beta and I have no prior hands-on experience with them so I'm learning and having fun doing it. In addition to the exciting work, people on the MTC team have been warmly welcoming me and offering assistance whenever I need it.
Besides the exciting new role and the great team, Austin has some bonus features. There are some really great schools here (we're looking to live in NW Austin around Canyon Vista Middle and Westwood High Schools), UT Austin is a high ranking university, and the Austin live music scene provides some unique entertainment opportunities. Yesterday I discovered another bonus feature: Twisty roads. Moving here from Seattle's East Side (foot hills of the Cascades), I was worried I won't find good places to ride my bike. So yesterday I went out exploring and I found several well paved, twisty roads that were nearly empty at 5PM on a Saturday. In fact I got tired and turned back before the road showed any signs of ending. Turns out because Austin is in the Texas Hill Country, there are plenty of hills, canyons, and lakes and and abundance of twisty roads. Couple that with the drier and warmer weather, and you're pretty close to sport bike rider's heaven! I'm already loving it here.

More on the WCF RSS Sample

2006-06-21T21:31:00Z

Last week we put up a sample named WCF RSS Toolkit on wcf.netfx3.com and I posted a sample service using it here. Since I wrote most of the toolkit’s code I thought I’d talk a bit about its goals, design and the future. There were two primary goals for this sample:

To explore/prototype RSS/Atom support in WCF and get customer feedback
Provide a sample to show WCF developers how to expose a service as RSS and Atom over HTTP GET using WCF v1

Note the “and” not “or” in #2, meaning the same service implementation can be exposed as RSS, Atom, or any other format simultaneously. If you know WCF, you’ll know this means generating multiple wire formats (RSS, Atom, whatever) from the same contract which can be done with some extensibility. The key is to not rely on the contract projecting the desired info set, rather to transform whatever info set projected by the contract to the desired info set. That transformation would be different depending on the desired wire format.

To make it easier for developers to emit RSS and Atom, I defined a DataContract with some of the commonly used RSS/Atom data and I defined a transform from that DataContract’s info set to RSS and another transform to Atom. All of this is pluggable/replaceable: You can use your own DataContract if you like, the transforms will transform what they recognize and copy the rest out as extension elements. You can also plug in your own transform to support new formats. Since it’s source, it’s also customizable so you can modify the DataContract and/or the transform if you don’t like how I make DataContract members to RSS/Atom elements.

There was also the HTTP GET part of the equation. WCF’s HTTP transport supports GET out of the box but there are other places in the stack that need to be extended for the scenarios I had in mind. For example, dispatching to the right operation based on the path segment following the endpoint’s address in the request URL. Also, parsing the request query string and decoding parameters from it. And of course, supporting ETag and Last-Modified HTTP header. All of these are commonly needed in RSS/Atom scenarios and when we do build RSS/Atom support into WCF, we will have these features. For the sample however, the first two are included in the sample but the last one isn’t. The good news is that the WCF HTTP transport gives you full read/write access to HTTP headers via the Message properties HttpRequestMessageProperty and HttpResponseMessageProperty so you could build ETag support on top of the current WCF bits. In fact, one of the benefits of having the RSS toolkit sample source code is it gives you a starting point that you can take and modify with ETag support and other features you want. You can even publish you modified sample for the community to learn from and use.

WCF RSS Sample

2006-06-15T19:22:00Z

Mark is looking for some sample code for the recently released WCF RSS Toolkit. I've put the readme up here. I won't repeat the whole readme here but here's a peek at the programming model. There are several shortcuts for feeds from databases and feeds using existing data types so you should really check out the readme.

An example service:

using System;
using System.ServiceModel;
using System.Collections.Generic;
using Microsoft.ServiceModel.Samples.Syndication;
namespace Microsoft.ServiceModel.Samples.Syndication
{

    [ServiceContract]
    public class ItemListService
    {
       [OperationContract]
       ContentFeed<FeedItem> GetItemList()
       {

//instantiate the feed
ContentFeed<FeedItem> feed = new ContentFeed<FeedItem>();

//populate the list of feed items
feed.FeedItems = GenerateItemList();

            //set some feed-level properties
            feed.FeedAuthor = wcfuser@contoso.com;
            feed.FeedTitle = "WCF Item List!";

...

//return the feed
return feed;

}

ItemList<FeedItem> GenerateItemList()

{

ItemList<FeedItem> list = new ItemList<FeedItem>();

FeedItem item1 = new FeedItem();
item1.ItemTitle = "This is item 1";

...

list.Add(item1);

...

return list;

}

To expose RSS, Atom and SOAP endpoints in code (see readme and samples in toolkit for config-based and hosting in IIS examples):

using System.ServiceModel;
using Microsoft.ServiceModel.Samples.Syndication;
namespace Microsoft.ServiceModel.Samples.Syndication
{

class Program
{

static void Main(string[] args)
{

            ContentFeedHost host = new ContentFeedHost(
                typeof(ItemListService),
                new Uri("http://localhost:8077/ItemListService"));

//endpoints defined in code

            // RSS endpoint will be listening at
            //http://localhost:8077/ItemListService/rss
            host.AddRssEndpoint(typeof(ItemListService), "rss");

            // Atom endpoint will be listening at
            //http://localhost:8077/ItemListService/atom
            host.AddAtomEndpoint(typeof(ItemListService), "atom");

            // WS-* SOAP endpoint will be listening at
            //http://localhost:8077/ItemListService/soap
            host.AddServiceEndpoint(typeof(ItemListService),
                                    new WsHttpBinding(), "soap");

host.Open();

            Console.WriteLine("Service started ...");
            Console.WriteLine("Press [Enter] to exit");
            Console.ReadLine();

host.Close();

}

Enjoy!

WCF Custom Channel Ecosystem

2006-04-10T15:05:00Z

Back in January, a few of us on the WCF team kicked off a side project dubbed "the channel ecosystem project". The goal is to create a community and an ecosystem around WCF custom channels. The first step was to make it easier for developers to build custom channels. To do this we decided to provide detailed documentation, samples, and a couple of tools. We've been creating this content over the last 3 - 4 months as a part-time effort next to our full-time jobs. Thanks to the hard work of many people, the content is now in a state where it can be shared with the world as a pre-release to solicit feedback. It's been published on windowscommunication.net. The samples are also linked from the samples gallery.
We want to hear your feedback on this content as well as what else you'd like to see to help you build custom channels. Send feedback to ces at microsoft.com.

It's here

2006-03-12T08:35:00Z

I came home today to find a large box waiting for me; it's my new iMac G5! This is the 20" intel dual core version and it's absolutely stunning. Now I must admit that this is my first Apple computer. My first computer was a Texas Instruments TI 99/4A (complete with the Extended Basic cartridge). My second computer was a Commodore 128. After that it's been PCs, PS/2s. and more PCs. But now I own a Mac and I'm glad I do. This computer is a pleasing to look at and fun to use. But the thing that's most amazing thus far is how easy it is to use evening for scenarios that I thought would be considered "advanced". It took less than 15 minutes from the minute I started opening the box till I was browsing the Web on my wireless LAN. I then decided to go all out and attempt to connect to my home file server to get to my music and photos. Now this is a task I don't take lightly. Every single time I try to do this with a new or newly reinstalled Windows computer it never works the first time. I typically have to do hacks like use the server's IP address or put an entry in the hosts file. Of course I expected it to be doubly hard on a Mac because I've never used one of these before and, well, it's a Mac so how could it possibly be easier to talk to a Windows server than from a Windows PC? Well, I fumbled along until I found the help, I searched for connecting to Windows PCs and I found a sequence of 3 steps that supposedly end in seeing the Windows PC and its shares. Oddly enough, I followed those steps and there was my home server and its shares right there on my Mac! That's just amazing. Next, I decided to try and connect my cell phone and my wife's cell phone to the Mac using Bluetooth. Painlessly, everything worked the first time. This machine brings new meaning to the words "it just works". I put in The Matrix DVD and fiddled around with the iPod-shaped remote control. The 10' UI is smooth and clean and video playback on the 20" screen makes for a great viewing experience. But the built-in speakers are weak and have poor bass. Guess I need to buy a nicer pair of speakers. Then my kids came and we played with the photo booth app. This is a little app that lets you take pictures with the built-in camera and apply one of about 20 silly effects. The app has a clever trick to make up for poor lighting: It uses the massive 20" LCD as a flash turning it bright white for a second while the camera takes a picture. My kids loved playing around and making silly faces. We then took the pictures into iPhoto and made a slideshow with transitions and music. Took two minutes and turned out great. Wow. Best of all, there are absolutely no wires except for the power cord (my wife is really impressed by that). I want to keep it clean so I'll look for a pair of wireless speakers. I'm looking forward to learning more about Mac OS/X and using it for all sorts of fun projects.

Moving lots of data

2006-01-22T09:19:00Z

Recently I've been getting lots of questions about moving large files (or lots of data) between a WCF service and client. The question comes in multiple forms, e.g.

How do I send a file that's many GB in size from the service to the client?
Should I use MTOM to send large files?
I have a huge object graph and I want to send it over the wire, how should I do it?

So let's explore the problems associated with moving lots of data and the solutions offered by WCF.
Problem: Bandwidth Utilization
Sending gigabytes of data means lots of bandwidth usage. While that may not be a problem if it happens infrequently on a 100 Mbit or 1 Gigabit LAN, it is definitely an issue when bandwidth is scarce and/or is being paid for. In interop scenarios, where messages are encoded as text XML, the encoding of binary data using Base64 exacerbates the problem because it inflates the size by 1/3. There are three solutions to this problem depending on your scenario. First, compression could really help especially if the data is text or gets encoded as text (using Base64). Compression/decompression can be implemented using a custom WCF encoder/decoder (and IIS 6 offers built-in response compression). Second, you can avoid using text encoding when interop is not required. WCF provides a binary encoding which is far more bandwidth-efficient than the text encoding especially when sending binary data. Third, if you want interop and you need to send large binary content, you can use MTOM which allows you to send the binary content outside of the SOAP envelope (as a separate part of a multi-part MIME message) without Base64 encoding it.

Problem: Memory Utilization
By default, WCF buffers messages to support protocols like WS-ReliableMessaging and WS-Security that require buffered messages. For extremely large messages this can lead to out-of-memory conditions especially on servers that try to send or receive multiple of those messages simultaneously. Fortunately, WCF supports streaming on HTTP, TCP, and Named Pipes allowing you to send infinitely large messages without hitting out-of-memory exceptions (actually, message size is constrained to Int64.MaxValue or 9,223,372,036,854,775,807 but hopefully that's infinite as far as your app is concerned).

Problem: Recovering from Failures
So what happens if half way through sending your 4GB stream the TCP connection fails? Well, your app must catch the exception and recover. If the other side has been processing the stream as it receives it (e.g. saving it to disk) you may be able to have the sending app coordinate with the receiving app to figure out what was the last received byte and restart from there.
Another alternative is to use Reliable Messaging to recover from connection failures. RM will detect the failure and automatically re-establish a connection and resend the failed message. The problem here is that when you're streaming, the entire stream is one message so resending means basically starting over. Another problem, is that RM requires buffering (so it can resend on failure) so it doesn't work with streaming! The solution is to use chunking. This is where the sending application divides up the 4GB file into say 1 million messages each 4KB in size and sends them in buffered mode. The receiving application reconsitutes the file by appending all 1 million messages to form the original 4GB file. Here, RM buffers only a few of the 4KB messages at a time. In case of a failure, RM will automatically resend the 1 or few failed messages. The chunking/dechunking functionality can be encapsulated in a general purpose chunking channel that lets the applications program against a Stream and handles the chunking under the covers. This is what my sample chunking channel from PDC does. Note that because of the chunking and the protocol overhead added by RM, the resulting throughput is expected to be lower than direct streaming. However, you are getting reliability which comes in handy when the connection fails especially when you're almost done sending the 4GB and don't want to start all over!

To summarize, my recommendations are:
1. Use binary encoding if you have WCF on both sides or MTOM if you need interop.
2. Consider compression if you are forced to use text encoding or if the data itself is highly compressible (e.g. large text data).
3. Use streaming, or if you want reliability, use chunking. One restriction to keep in mind is that to stream, there can be only one parameter (or return value, depending on which direction you're streaming) and it must be of a type that derives from System.IO.Stream.

Meet the Channel Model: ICommunicationObject

2006-01-09T03:14:00Z

A Common a State Machine

Objects that deal with communication, e.g. sockets, usually present a state machine whose state transitions relate to allocating network resources, making or accepting connections, closing connections and aborting communication. The channel state machine provides a uniform model of the states of a communication object that abstracts the underlying implementation of that object. The interface provides a set of states, state transition methods, and state transition events. All channels, channel factories and channel listeners implement the channel state machine.

ICommunicationObject

ICommunicationObject is a CLR interface that describes the channel state machine contract:

public interface ICommunicationObject : IDisposable
{
    CommunicationState State { get; }

    event EventHandler Closed;
    event EventHandler Closing;
    event EventHandler Faulted;
    event EventHandler Opened;
    event EventHandler Opening;

    void Abort();

    void Close();
    void Close(TimeSpan timeout);
    IAsyncResult BeginClose(AsyncCallback callback, object state);
    IAsyncResult BeginClose(TimeSpan timeout, 
                            AsyncCallback callback, object state);
    void EndClose(IAsyncResult result);

    void Open();
    void Open(TimeSpan timeout);
    IAsyncResult BeginOpen(AsyncCallback callback, object state);
    IAsyncResult BeginOpen(TimeSpan timeout, 
                           AsyncCallback callback, object state);
    void EndOpen(IAsyncResult result);
}

The events Closed, Closing, Faulted, Opened and Opening signal an external observer after a state transition occurs.
The methods Abort, Close, and Open (and their async equivalents) cause state transitions.
The state property returns the current state as defined by CommunicationState:

public enum CommunicationState
{
    Created,
    Opening,
    Opened,
    Closing,
    Closed,
    Faulted
}

An ICommunicationObject starts out in the Created state where it’s various properties can be configured. Once in the Opened state, the object is usable for sending and/or receiving messages but its properties are considered immutable. If an unrecoverable error occurs, the object transitions to the Faulted state where it can be inspected for information about the error and ultimately closed. When in the Closed state the object has essentially reached the end of the state machine. In general, once an object transitions from one state to the next, it does not go back to a previous state.

States and Transition
The figure below shows the ICommunicationObject states and state transitions. State transitions can be caused by calling one of the three methods: Abort, Open, or Close. They could also be caused by calling other implementation-specific methods. Transitioning to the Faulted state could happen as a result of errors while opening or after having opened the communication object. Every ICommunicationObject starts out in the Created state. In this state, an application can configure the object by setting its properties (e.g. setting the address of a channel listener by calling its SetUri method). Once an object is in a state other than Created, it is considered immutable. For example, calling SetUri on a channel listener in the Opened state should throw an InvalidOperationException.

WCF provides an abstract base class named CommunicationObject which implements ICommunicationObject and acts as the base of all channel objects. That will be the subject of my next posting on the channel model.

WCF Architecture Overview

2005-12-30T07:13:00Z

This is a document I wrote a while ago and has been sitting around waiting to be published. Well, it finally is! Enjoy.

Looking for people who want to change the world

2005-11-29T22:31:00Z

We have a few open positions on the Indigo (WCF) team for people who want to change the world. In this role, you would get the opportunity to really change how millions of developers write distributed applications (if you're a distributed app developer yourself, you know that's a big part of your world!). I'm not exaggerating here, we're not just talking tweaks or incremental improvements, I really mean significant change.
We're looking for program managers to help innovate, design, build and ship Indigo v1 and future versions/technologies in the distributed applications space. We have positions for both experienced folks and recent college grads. If you or someone you know is interested, just email me at yassers@microsoft.com.

Meet the WCF Channel Model – Part 2

2005-10-22T21:31:00Z

Most WCF developers won’t interact directly with channels or have to think about them much. The Service Model, WCF’s programming model, provides abstractions that layer on top of channels to give a “method and typed parameters” programming model. However, many developers will want to write custom channels for the reasons I mentioned in my previous post. For those developers, it’s interesting to understand how the channels are used (indirectly) by a developer building a WCF service and/or client.

WCF services and clients are based on the concept of endpoints. An endpoint consists of an address, a binding and a contract. The address is the endpoint’s network location (the where). The binding specifies how the endpoint communicates with the world (the how) and the contract is the collection of operations the endpoint exposes (the what). For the purpose of this discussion, the binding is the most interesting of the three.

A service developer defines an endpoint by specifying its three components. For example:

public static void Main()
{
ServiceHost host = new ServiceHost(typeof(StreamServer));

host.AddEndpoint(
             typeof(IStreamService),
             new ChunkingTcpBinding(),
             new Uri("net.tcp://localhost/StreamService"));

host.Open();

Console.WriteLine("stream server started....");
Console.ReadLine();
}

The call to host.AddEndpoint defines the endpoint. The call to host.Open creates the channel stack that will listen for and process messages targeted at the endpoint. Each binding is really a collection of binding elements each contributing to building the channel stack. For example, this is the ChunkingTcpBinding:

public class ChunkingTcpBinding : Binding
{
public ChunkingTcpBinding()
{
       ...
}
public override BindingElementCollection CreateBindingElements()
{
      BindingElementCollection col =
                new BindingElementCollection();
      ChunkingBindingElement cbe = new ChunkingBindingElement();
      TcpTransportBindingElement tcp =
                new TcpTransportBindingElement();
      tcp.TransferMode = TransferMode.Buffered;
      tcp.MaxMessageSize = Int32.MaxValue;
      col.Add(cbe);
      col.Add(tcp);
      return col.Clone();
   }

}

Each binding element inherits from BindingElement which has a couple of interesting methods:

public abstract class BindingElement
{

   public virtual IChannelListener<TChannel>
           BuildChannelListener<TChannel>(ChannelBuildContext context)
                          where TChannel : class, IChannel
   {
   }

   public virtual IChannelFactory<TChannel>
           BuildChannelFactory<TChannel>(ChannelBuildContext context)
   {
   }

... other methods not shown ...

}

The Service Model calls BuildChannelListener to get back a ChannelListener that is added to the channel stack to listen for incoming channels. Think of an incoming channel as an incoming connection request. Once established, it can be used for receiving messages. Here it is visually:

On the send side (e.g. on the client side), the Service Model calls BuildChannelFactory to get back a ChannelFactory. A ChannelFactory is used to build a channel that can be used for sending messages. Here is this part visually:

You may be wondering why there are two factory abstractions: binding element and channelfactory/channellistener. Turns out there are different two categories of things one may want to do in a factory class that creates channels and those two categories are best separated in two factories. The categories are: programming model-specific work and channel-specific work. Programming model-specific work that belongs in binding elements includes things like varying behavior based on settings on the endpoint’s contract or implementation and reading from config. Channel-specific work that belongs in channel factories/listeners includes things like pooling resources across channels (e.g. network connections).

The next interesting thing to talk about is how channel factories create channels and the concept of channel shapes. That will be the subject of my next posting.