Yasser Shohoud : Technology

WCF Custom Channel Ecosystem

yassers — Mon, 10 Apr 2006 12:05:00 GMT

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.

Moving lots of data

yassers — Sun, 22 Jan 2006 06:19:00 GMT

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

yassers — Mon, 09 Jan 2006 00:14:00 GMT

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

yassers — Fri, 30 Dec 2005 04:13:00 GMT

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

yassers — Tue, 29 Nov 2005 19:31:00 GMT

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

yassers — Sat, 22 Oct 2005 18:31:00 GMT

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.

Meet the WCF Channel Model - Part 1

yassers — Wed, 12 Oct 2005 17:37:00 GMT

For the past 5 months or so, I’ve been working on the WCF Core Communications team (with Kenny, Matt, and Steve) where we focus on WCF transports and hosting features. In this period, I’ve learned a lot about the WCF channel model and I’m still learning a lot. I want to share some of what I’ve learned with you on this blog. So here’s a first of what I hope to be many posts on this topic. Kenny also has several posts about this subject on his blog.

The WCF runtime consists of two layers: The channel stack and the dispatcher/proxy. The channel stack is responsible for sending/receiving messages between the sender and receiver while the dispatcher/proxy layer is responsible for translating those messages to/from service method calls.

The channel stack is where WCF gets a lot of its power and versatility. It’s similar to the traditional OSI model in that there are cleanly separated layers with each layer using the services of, and only calling on, the next layer down. It’s also very different from the OSI model in that there aren’t n well defined layers each with their specific role. Instead, there are two types of channels with implementations of these types allowed to compose in different ways depending on the application’s needs.

At the bottom of the stack is a transport adapter channel (aka a transport) whose role is to adapt an underlying transport to WCF’s channel model. For example, WCF ships with HTTP, TCP, Named Pipes, Peer to Peer, and MSMQ transport adapters allowing you to use any of these technologies as a means of transporting messages between sender and receiver. Each transport adapter can use an encoder that transforms WCF messages to the appropriate format for the transport. WCF ships with three encoders: text XML, binary XML, and MTOM. You can mix and match transport adapters and encoders unless the transport adapter has some restriction on the type of encoder it needs.

Above the transport adapter is zero or more protocol channels. These are channels that perform some kind of message transformation as a means of communicating with the equivalent protocol channel on the other side. For example, WCF ships with security, reliable messaging, and transaction flow channels. Each of these channels add/read headers to/from the message and some of them modify message content and even send their own messages (reliable messaging sends ACK messages).

One of the key differences between WCF and existing distributed app technologies like ASMX or ES, is this ability to use any transport (through transport adapters) and compose any number of protocol implementations within the communications stack. .NET Remoting has similar features (extensibility allowing you to plug in custom transport channels and chains of message sinks that could act as protocols) but WCF takes this further by providing a richer channel model that captures the fundamental communication patterns (input, output, duplex, request/reply).

So why is all this flexibility and extensibility good? Those of you who know me will know I’m a pragmatic guy so I would not say something is good just because it’s cool technology. WCF is the next generation distributed applications framework. It will be used for a long time and for many diverse scenarios many of which we don’t even know yet. Product extensibility is essential in this case to satisfy such diverse scenarios. For example WCF/WSE 3.0 interop over HTTP is supported by WCF out of the box but there are some scenarios where customers may want to interoperate over TCP. In our PDC talk, Kenny showed a custom TCP transport adapter that allows Indigo to talk to WSE 3.0 over TCP. The fact that it was possible, and relatively easy (OK, Kenny owns our TCP transport adapter so he knows this stuff inside out) to enable such a scenario speaks volumes for WCF’s channel extensibility. Another powerful scenario is when a customer wants to use WCF to communicate with a existing system that exposes its functions only through a proprietary network API. The customer can write a custom transport adapter that adapts the proprietary network API to WCF’s channel model allowing WCF developers to access the existing system without having to learn a new API.

These rich scenarios are what excite me the most about WCF’s channel extensibility. As more customers start playing with WCF, I think we’ll see a proliferation of custom channels both from ISV’s as well as within the enterprise.

It's fun being a test engineer on Indigo

yassers — Tue, 22 Mar 2005 17:33:00 GMT

Recently, I spent a few days writing test cases for the MetadataExchange endpoint feature in Indigo. This started as a way to help out our overly thin-stretched test team so that we can get this feature in Indigo Beta1. It has since turned into an educational experience for me.

It’s increased my, already tremendous, appreciation of the work our testers do. Not only do they think about and design test cases to achieve optimum coverage with minimal number of test cases, they also write and maintain sophisticated distributed test frameworks (complete with distributed shared state and synchronization) for automating Indigo tests. This framework is so versatile and powerful that I think it would make a useful product for anyone testing distributed applications.

Going forward, this is experience will be extremely useful for me when making test case suggestions to our test team and when reviewing test specifications.

Want to join the Indigo test team? See Indigo Needs Testers.

ASMX documentation

yassers — Wed, 26 Jan 2005 22:35:00 GMT

I'm currently reviewing the docs for Whidbey version of ASMX (ASP.NET Web services). What are the top 1 - 3 ASMX docs topics that you'd like to see improved?
I'm enabling comments for a while so you can reply to this. I'm sure I'll have to turn them off again though because I get spammed.

Disabling Comments

yassers — Fri, 31 Dec 2004 16:06:00 GMT

My blog has recently been subjected to "comment spam" so I'm disabling comments again. It's a shame because I love to hear your opinions/questions but I have over 300 spam comments just in the last week.

Let's all become cavemen

yassers — Thu, 11 Nov 2004 02:11:00 GMT

I just came across a statement made by a prominent industry figure about how WS-* is becoming so complex that it is not practical to implement a WS-* architecture with no tool/stack support. Well, what's wrong with relying on tools/stacks? Isn't that how humans have made progress? That is, a specialized few focus on a complex area and produce a useful package that can be used by others in tackling completely different complexity etc. Does a construction engineer have to understand the inner workings of all construction tools? Seems to me that if we start eschewing tools as a principal, we will all end up more or less cavemen. I'd rather use tools.

Web services features in .NET 2.0 (VS Connections talk)

yassers — Wed, 10 Nov 2004 22:24:00 GMT

My VS Connections talk's slides and code are available here.

Web services and large content in .NET 2.0

yassers — Wed, 10 Nov 2004 16:05:00 GMT

There are a couple of features in .NET 2.0 (Whidbey) that help solve the problems of dealing with large data. The two main issues with sending large data in Web service messages are: 1. working set (memory) due to buffering by the serialization engine and 2. bandwidth consumption due to 33% inflation after Base64 encoding.

Chunking to constrain working set
First, let's talk about working set. In .NET 2.0, you can implement IXmlSerializable on both client and server side and use that to chunk data to/from the network. This allows you send/receive arbitrarily large content without consuming arbitrarily large working set. Here's an example:

On the server side, here's what you do to chunk large content back to the client:

First: The Web method needs to turn off ASP.NET buffering and return a type that implements IXmlSerializable:

[WebMethod]

[SoapDocumentMethod(ParameterStyle= SoapParameterStyle.Bare)]

public SongStream DownloadSong(DownloadAuthorization Authorization, string filePath)

{

//turn off response buffering

HttpContext.Current.Response.Buffer = false;

//return song

SongStream song = new SongStream(filePath);

return song;

}

Second: The type that implements IXmlSerializable needs to send chunks in its WriteXml method:

[XmlSchemaProvider("MySchema")]

public class SongStream : IXmlSerializable

{

private const string ns = "http://demos.teched2004.com/webservices";

private string filePath;

public SongStream()

{

//default constructor for serializer

}

public SongStream(string filePath)

{

this.filePath = filePath;

}

public static XmlQualifiedName MySchema(XmlSchemaSet xs)

{

//this method is called by the framework to get the schema for this type

// here we return an existing schema from disk

XmlSerializer schemaSerializer = new XmlSerializer(typeof(XmlSchema));

string xsdPath = null;

xsdPath = HttpContext.Current.Server.MapPath("SongStream.xsd");

XmlSchema s = (XmlSchema)schemaSerializer.Deserialize(

new XmlTextReader(xsdPath), null);

xs.XmlResolver = new XmlUrlResolver();

xs.Add(s);

return new XmlQualifiedName("songStream", ns);

}

void IXmlSerializable.WriteXml(System.Xml.XmlWriter writer)

{

//this is the chunking part

//note that ASP.NET buffering must be turned off for this to really chunk

int bufferSize = 4096;

char[] songBytes = new char[bufferSize];

FileStream inFile = File.Open(this.filePath, FileMode.Open, FileAccess.Read);

long length = inFile.Length;

//write filename

writer.WriteElementString("fileName", ns, Path.GetFileNameWithoutExtension(this.filePath));

//write size

writer.WriteElementString("size", ns, length.ToString());

//write song bytes

writer.WriteStartElement("song", ns);

StreamReader sr = new StreamReader(inFile, true);

int readLen = sr.Read(songBytes, 0, bufferSize);

while (readLen > 0)

{

writer.WriteStartElement("chunk", ns);

writer.WriteChars(songBytes, 0, readLen);

writer.WriteEndElement();

writer.Flush();

readLen = sr.Read(songBytes, 0, bufferSize);

}

writer.WriteEndElement();

inFile.Close();

}

System.Xml.Schema.XmlSchema IXmlSerializable.GetSchema()

{

throw new System.NotImplementedException();

}

void IXmlSerializable.ReadXml(System.Xml.XmlReader reader)

{

throw new System.NotImplementedException();

}

On the client side, here's what you do to chunk large content from the server:

First: The Web service method named DownloadSong in the proxy must be changed to return a type that implements IXmlSerializable. You can use a SchemaImporterExtension to do this automatically when the proxy is generated, for now, let's just assume you somehow edited the proxy code and changed it to return a type named SongFile which resides on the client and implements IXmlSerializable.

Second: The type used on the client that implements IXmlSerializable (in this case called SongFile) needs to read chunks from the network stream and write them to disk to avoid arbitrarily large buffers. This particular implementation also fires progress events which can be used to update a UI e.g. a progress bar.

public class SongFile : IXmlSerializable

{

public static event ProgressMade OnProgress;

public SongFile()

{

}

private const string ns = "http://demos.teched2004.com/webservices";

public static string MusicPath;

private string filePath;

private double size;

void IXmlSerializable.ReadXml(System.Xml.XmlReader reader)

{

reader.ReadStartElement("DownloadSongResult", ns);

ReadFileName(reader);

ReadSongSize(reader);

ReadAndSaveSong(reader);

reader.ReadEndElement();

}

void ReadFileName(XmlReader reader)

{

string fileName = reader.ReadElementString("fileName", ns);

this.filePath =

Path.Combine(MusicPath, Path.ChangeExtension(fileName, ".mp3"));

}

void ReadSongSize(XmlReader reader)

{

this.size = Convert.ToDouble(reader.ReadElementString("size", ns));

}

void ReadAndSaveSong(XmlReader reader)

{

FileStream outFile = File.Open(

this.filePath, FileMode.Create, FileAccess.Write);

string songBase64;

byte[] songBytes;

reader.ReadStartElement("song", ns);

double totalRead=0;

while(true)

{

if (reader.IsStartElement("chunk", ns))

{

songBase64 = reader.ReadElementString();

totalRead += songBase64.Length;

songBytes = Convert.FromBase64String(songBase64);

outFile.Write(songBytes, 0, songBytes.Length);

outFile.Flush();

if (OnProgress != null)

{

OnProgress(100 * (totalRead / size));

}

else

{

break;

}

outFile.Close();

reader.ReadEndElement();

}

public void Play()

{

System.Diagnostics.Process.Start(this.filePath);

}

By the way, you can implement IXmlSerializable today in .NET 1.0 and 1.1 and use it to chunk content. In .NET 2.0 we improve the experience by allowing you to emit a meaningful schema and introducing SchemaImporterExtensions which allow you to generate the right code on the client side.

Reducing Bandwidth Utilization
IIS 6.0 makes it easy to compress replies including Web services replies. In .NET 2.0, the client will automatically tell the server that it accepts gzip compression and it will automatically decompress replies. This lets you send Base64 encoded data (text) and compress it which can reduce its size by up to 10 : 1. Note that we don't have a client side compression feature so if you are sending Base64 data from the client and you want to compress it, you would need to use 3rd party compression library or roll your own.

I'm speaking at VS Connections

yassers — Thu, 23 Sep 2004 20:38:00 GMT

I got asked today to give a talk at VS Connections in Vegas. My talk will cover the new Web services and serialization features in .NET Framework 2.0. In addition to the features already released in Beta 1, there's going to be a few new ones and one particularly important/useful feature.

Weather service back online

yassers — Sun, 29 Aug 2004 22:42:00 GMT

I've also finally gotten around to putting up my Weather service (for the 3rd time). It's live at http://www.learnxmlws.com/services/Weather.asmx and registered with UDDI in the VS-friendly way.