On the road to building a custom channel, we're going to need to make use of a lot of small but very important pieces of the WCF object model. The piece that I will be talking about for a few days this week is the B in the ABC's: bindings. Bindings are a little mysterious because how to make use of them seems to change quite a bit from one preview release to another. I think that bindings are getting very close to the end of this long journey though and will remain pretty much unchanged to Version 1 and forever beyond.
The first part of bindings that I'll show off is the binding element. A binding element corresponds to a configurable entity that is part of the channel stack.
public abstract class BindingElement { protected BindingElement(); protected BindingElement(BindingElement elementToBeCloned); public virtual IChannelFactory<TChannel> BuildChannelFactory<TChannel>(BindingContext context); public virtual bool CanBuildChannelFactory<TChannel>(BindingContext context); public abstract BindingElement Clone(); public abstract T GetProperty<T>(BindingContext context) where T : class; }
There are only a few methods that make up a binding element so I can go over them individually. Two methods that get a lot of use are CanBuildChannelFactory and BuildChannelFactory. Channel factories are a subject for the not-too-distant future, but in short these methods are responsible for validating that the configuration we have is going to lead to a valid channel stack and actually building that channel stack. These methods are going to appear in other classes as well to do the work of tying together channels.
Binding elements are somewhat interchangeable pieces and to promote that mix-and-match behavior without causing too many headaches, we require that every binding element support duplicating itself. That appears as a Clone method on the element and a copy constructor for implementing cloning. Then, there are two ways of configuring how the binding element behaves. The author of the binding element class is going to add some properties or methods that let you directly manipulate settings. We also have a GetProperty method that allows configuring the binding element by having it look at other resources that have been placed into the binding.
The binding context is actually not that important for the sample channel that I'll be building in future posts, so I will hold off on describing contexts until later. I will also leave the in-depth description of the GetProperty method until talking about some of the channels we have that actually make use of this lookup mechanism.
One kind of binding element that we do need in the channel sample is a binding element that describes how to encode messages. That's where we'll pick up for tomorrow's post.
Next time: Encoding Messages
I kind of glossed over the subject of timeouts before although I did call them out as an extra tricky point of the object model. Timeouts don't just help with performance; they also play a role in the usability and security of channels. That makes it important to understand how timeouts are used and how to choose a good timeout value.
The first rule of timeouts is that any operation that is potentially lengthy must have a timeout. Methods that don't take a timeout should delegate to versions that do take a timeout. Methods that don't take a timeout and can't delegate to another version simply must never, ever do any work that can block. Otherwise, you have a weak point that is going to lower the reliability of your application and can make you vulnerable to Denial of Service attacks.
In CommunicationObject, the Open() and Close() methods use timeout values that come from the appropriately named DefaultOpenTimeout and DefaultCloseTimeout properties. The implementation of Open() is just to call Open(DefaultOpenTimeout) and similarly for Close(). The OnOpening() and OnOpened() methods have no equivalent with a timeout. That means they must not block! Do anything that could potentially block in OnOpen() instead.
The second rule of timeouts is that they are the total limit for an operation's run time inclusive of any retry attempts.
Bad scenario: Your Open() operation is called with a timeout of 60 seconds. You pass that value to your OpenSocket function, which you'll then retry 4 more times in a loop. Don't do this! If each call to OpenSocket gets its own timeout, then you could spend in excess of 5 minutes in this function.
Worse scenario: Someone retries your Open function 3 more times in a loop. The retries multiply together and now you have to wait 20 minutes.
Just right scenario: You measure that the first call to OpenSocket failed after 25 seconds. You then retry OpenSocket, but this time you give it a timeout of 60 - 25 = 35 seconds. Eventually, you'll either hit your maximum number of times to retry or you'll reduce your timeout to 0 seconds. Even if retries are nested within retries, you have a tight bound on the total operation time.
This leads to a very easy rule for using timeouts: just worry about the time you can afford for high-level operations. Everyone else will simply spend whatever time they have left.
Next time: The Ties that Bind Us, Part 1: BindingElement
In the original post introducing ICommunicationObject I claimed that the abstract base class helps you run our required state machine. Today, I'll explain exactly how CommunicationObject enforces the state machine model. Combined with the post yesterday showing how to use the state machine to protect your code, we'll be ready to start looking deeper into the WCF channel object model in the future. Once you master the state machine, learning how to build a custom channel is just a matter of learning how to implement more interfaces. All of the basic object management concepts are going to be the same no matter what kind of channel you're dealing with.
CommunicationObject implements all of the events and methods associated with the state machine in ICommunicationObject. Behind the scenes, CommunicationObject keeps the state machine updated and calls into your code to hook into state transitions. Each operation splits into three methods so that you can do work before, during, or after the operation. After a state transition, the base class sends out an event notification that the transition occurred.
Let's say that someone calls Open() on your object. Here's how CommunicationObject handles the call:
Most of the time you'll just put code OnOpen() unless you have to do some setup work.
Important note: The code to fire the events is in the base class implementations of OnOpening() and OnOpened(). You must call the base class methods at some point or else! We try to check that you've done the right thing and throw an error if something looks fishy.
Closing works exactly the same way except you'll get a call to either OnClose() or OnAbort() depending on how the close operation was invoked. I've got a post coming up that will demystify the differences between closing and aborting. Faulting is even simpler because it's a one transition operation. After a fault is detected, the state machine moves to the Faulted state, your OnFaulted() method is called, and finally the Faulted event is sent.
Next time: Thinking about Timeout and Retry Policy
Yesterday, I introduced the ICommunicationObject state machine and mentioned that we had a base class called CommunicationObject to take care of some of the state machine details for you. Today, I'll show off one of the ways that CommunicationObject deals with state.
When you're writing a channel, many of the operations that you'll be implementing are only safe to call when the channel is in a particular state. As I said before, once a channel has been opened, you can't change any of its configuration settings. It's a really bad idea to try to read or write from a channel after it's been closed. It isn't much better to try to read or write from a channel before it's been opened.
You can invent your own reasons for why an operation should only work when in certain states. CommunicationObject helps you enforce these state requirements with three methods.
protected void ThrowIfDisposed(); protected void ThrowIfDisposedOrImmutable(); protected void ThrowIfDisposedOrNotOpen();
These methods are almost self-documenting although there are a few quirks. The first quirk is that all of the methods will throw if the state is Faulted, even though being faulted is not quite the same thing as being disposed. This is probably what you wanted though because very few channel operations should continue to work after a fault.
Here's how the methods decide whether to throw:
And, here's how the methods decide what to throw:
Next time: Lifecycle of a Channel
Earlier today the February WinFX Community Technology Preview went live. The last few CTPs have been focusing on driving to a stable quality level. This month's release finally drops in many of the changes we've been making in the meantime. Check out the list of breaking changes if you run into problems updating your programs to work with the new bits.
Here's a few other important links for this release:
Windows SDK
WinFX Development Tools for Visual Studio
Workflow Extensions
And of course, the very important release notes.
This release is available to everyone, no subscription required.
In the Windows Communication Foundation, there are a few classes that are so fundamental that they are a supertype of almost every other class you have to deal with. For the world of WCF channels, ICommunicationObject is that class.
public interface ICommunicationObject : IDisposable { CommunicationState State { get; } event EventHandler Closed; event EventHandler Closing; event EventHandler Faulted; event EventHandler Opened; event EventHandler Opening; void Abort(); IAsyncResult BeginClose(AsyncCallback callback, object state); IAsyncResult BeginClose(TimeSpan timeout, AsyncCallback callback, object state); IAsyncResult BeginOpen(AsyncCallback callback, object state); IAsyncResult BeginOpen(TimeSpan timeout, AsyncCallback callback, object state); void Close(); void Close(TimeSpan timeout); void EndClose(IAsyncResult result); void EndOpen(IAsyncResult result); void Open(); void Open(TimeSpan timeout); }
The role of a communication object is to implement a particular state machine we use to model communication resources. It isn't really intuitive looking at ICommunicationObject what that state machine is, how to use it, or how to implement it. That's unfortunate. Those of you working with channels directly will need to know how the state machine works. At the higher levels of service and abstraction in WCF though, some of these details are hidden.
The three main states to worry about are Created, Opened, and Closed. A communication object starts in the Created state where you can fiddle with its settings to configure the resource. Once a communication object leaves the Created state, it's too late to be changing settings or modifying the channel stack. At this point the object is said to be immutable. The most common way to leave the Created state is to engage the communication resource by calling the synchronous Open() method or the asynchronous BeginOpen() method. Long time Windows programmers will recognize this common synchronous/asynchronous pattern; everyone else will have to wait a few weeks until I have time to cover this pattern and our asynchronous helper classes. When you're done with the resource, you can clean it up by calling the Close() method, again in both synchronous or asynchronous versions.
Common pitfall: The IDisposable implementation will typically delegate to calling the Close() method. It's generally better if you close network resources explicitly when you're done using them. You might create a race condition if you defer cleaning up resources until some arbitrary point in the future.
Tricky point: Although we've just covered everything but the Abort() method and Faulted state, the two are not connected. Calling Abort() is just a more impatient way of telling the resource to close. The Faulted state indicates that something has gone wrong with the resource and it can no longer be used.
Extra tricky point: The method overloads without a timeout do not mean that the timeout is infinite. They instead should timeout after some reasonable default. This is very, very important. Getting this wrong in an implementation can break many of our Denial of Service mitigations for slow or resource hogging clients.
Life gets better if you use the corresponding base class, CommunicationObject. This will help take care of running the state machine. For the rest of the week, I'll be looking at the state machine and support classes in more detail to show off all of the states and transitions.
Next time: Don't Like it? Throw it Out!
Every time you want to send someone a message, that message first has to make its way through something we call the channel stack. A channel is just an object that implements some particular interfaces for handling messages. The channel stack is a collection of these channel objects, which you can visualize as being stack one atop another. When sending a message, each channel passes the send request down to the next lower channel until the bottommost channel actually transmits the message. Receiving a message works the opposite way. The bottommost channel receives some bytes, creates a message, and then that message bubbles up through the channel stack until it reaches the application.
Here's the concept in a picture:
There are actually two kinds of channels in this diagram. The bottommost channel is called a transport and is responsible for converting between a message and bytes on the network. There can only be one transport in the channel stack and it must be the channel at the bottom because once you convert the message to bytes, you don't have a message object anymore to give to another channel. You also really need a transport because eventually you have to stop passing the message around between channels and send it out to someone. We support out-of-the-box a number of basic transports such as TCP/IP and HTTP.
All of the channels on top of the transport are called protocol channels. A protocol channel transforms a message into a different message, such as the chunking channel we looked at before. Putting protocol channels in the channel stack allows you to change what content you put on the network without changing how you actually go about putting bits on the network. The big advantage you get with the WCF channel stack over other networking technologies is flexibility. Since the channels are all accessed through the same few basic interfaces, it's possible to do some fairly dramatic reconfigurations of the channel stack without changing any of the application code. Over the next month I'll be doing a whirlwind tour of the interfaces involved in creating, connecting, and using channels.
Next time: Introducing ICommunicationObject
Although fewer than one-fifth of you read these posts in an HTML-rich browser, I decided to spend some time tweaking the visual style a bit to rid myself of that burning blue default color. Actually, I'm told that due to the way RSS hit tracking works, it's probably an even lower percentage that enjoy the browser experience. However, I want to make sure that even this tiny minority has a soothing and relaxing Indigo-hued page to look at every morning. The fact that I have to look at the HTML pages for management tasks may have played a tiny role as well; a miniscule factor in comparison to increasing your enjoyment I assure you.
In addition to the new color scheme, the text should also take advantage of the new fonts in Vista/Office 2007 should you happen to have either of those installed. There's no default Indigo theme so the changes are primarily done through a custom stylesheet. Let me know if something appears funny in your favorite browser or if you've spotted obvious goofs. I'll also take any style suggestions you may have, though please no more that involve editing every previous post :)
One of the fundamental things that has followed us around through more product name changes than you can shake a stick at is that a service endpoint basically boils down into three things:
Address
Binding
Contract
Formerly the Indigo ABC's, I guess these are now the WCFABCs (it really just flows off the tongue when pronounced as a word).
A service is nothing but a blob of code that runs somewhere in the world. The connection points where a service interacts with someone else are called endpoints.
The only thing that identifies an endpoint is that it has some URL for an address. That's pretty much all you need to know about addresses to survive in the new WCF world. Addresses are where things take place.
At a particular address, both sides need to use the same network protocols so that the two can exchange messages. The binding wraps a particular group of protocols together to describe the right way to put messages on the wire and the right way to take those messages back off the wire on the other side. I suppose that bindings are a little more complicated than addresses because I basically started this blog to talk about this binding business and I just punted a few of the lower priority topics to May. Bindings are how things take place.
Once you have an address and binding, you can start actually exchanging messages between the client and server. The particular set of messages that one side can send and the other side will understand is called the contract. Putting together the right contract is even more complicated than designing the right binding, so you're pretty much on your own here. Contracts are what things take place.
Here's the essence of a WCF service in just 10 words:
Addresses are where,
Bindings are how,
and
Contracts are what.
Next time: One of these Things is Not Like the Others (Channel vs. Transport)
In this series, I've gone through one set of problems that we encounter with buffered transfers, and a different set of problems that we encounter with streamed transfers. Each mode has its advantages, although it would be really nice if we could combine the strengths of both. Buffered transfers give us flexibility in choosing the security mechanism. Streamed transfers are more scalable. It turns out there is a way to essentially combine the properties of both modes. Even better, we can fix one more performance problem by doing so.
Steve's service has a problem that is hard to notice until you move from a development environment to a deployed environment. The problem comes from the system requirement that we must support clients over flaky connections. Reliable messaging is used to guarantee that messages are retransmitted if there is a connection problem. However, reliable messaging is done at the message level, and small errors can cause a retransmission of an entire large message. Bad things will happen if a client has a connection with a high error rate relative to the size of the message. The server will continuously retransmit the message until the send operation times out, tying up server resources without making any progress sending data to the client.
A way to solve all of these problems is to redefine what we use as a message. Chunking is a technique that splits a large message into many smaller messages. Since the messages are now small, we can use buffered transfers without worrying about increased memory use. Since we have buffered transfers, we don't have to worry about changing the security mode or channel shape. And, we can apply reliable messaging to each individual chunk so that a message failure only requires the server to retransmit a small message.
Here's a look at the same architecture, from the SOAP level down, with chunking instead of streaming. Since buffered transfers can use either message or transport security, I've left the security at the transport level:
Tomorrow, I'll conclude this little series by looking at a few more performance problems that are hard to notice until you have dozens of clients hitting your server.
Next time: Slicing the Windows Communication Foundation Technology Stack, Part 6
To answer a question I've heard a couple times now, WCF is almost entirely written in C#. And, almost every line of that C# is managed, type-safe, and verifiable. There's very little in WCF that you can't do with just the Base Class Libraries in the 2.0 .NET Framework. It takes millions of lines of code to do it all though, so I do hope that you find using WCF an attractive proposition compared to providing the equivalent support yourself.
Pretty much all of the code that I'll be posting to this blog will be in C# as well. That isn't to suggest that we've made it to difficult to use WCF from other languages. In fact, a lot of interesting things can be done with just the XML configuration files, which are totally independent of the language you use for your application. In the future, Microsoft may have specialized languages for writing distributed applications that blow C# out of the water. However, the language of choice today for writing highly-performant network applications using WCF is probably going to be C#. You can use MC++, VB.NET, or your other favorite language, but it might not be as fun and easy.
Special note: this advice applies even if you have Visual Basic Professional.
This is an interruption of your regularly scheduled post to take a little breather from the current series and evenly finish off the week. I've got a few of these lighter posts to sprinkle in now and then when there's some free time. We'll be back to slicing our WCF example tomorrow and conclude the series on Friday.
Yesterday, we looked at an architecture change from a buffered transport strategy to a streamed transport strategy. Making this change improved the scalability of the service by eliminating the large memory allocation for each concurrent connection. I mentioned last time that one consequence of making this change is the need to switch from message security to transport security.
A consequence that I didn't mention is that changing the transport transfer mode from buffered to streamed also changes how we expose the TCP/IP transport to your code. WCF has a number of built-in design patterns for sending and receiving messages, called 'channel shapes'. I will be going into detail about channel shapes in a few weeks, but what's important to know is that changing the transfer mode causes the TCP transport to use a different channel shape. To update the application code, you will either need to change the channel shape you expect to get back or use a shim that implements one channel shape in terms of other shapes.
Using a streamed transfer mode is not the only way to avoid the cost of buffering large messages. Next time, I'll reslice the problem and present an architecture that doesn't require changing the security mechanism or channel shape.
Next time: Slicing the Windows Communication Foundation Technology Stack, Part 5
Continuing with the same seemingly simple web service scenario as before, last time we saw an obvious problem and solution with our proposed architecture. The problem I want to talk about this time is a little more difficult to solve.
Suppose that against all odds, Steve's map service actually becomes quite popular and several users are connecting and downloading maps at a time. On the server side, we start to notice a steady increase in allocated memory as the number of simultaneously connected clients grows larger. Some memory growth is expected since we have to pay for all of those connections, but what Steve actually sees is multiple megabytes of growth per client. The map server is quickly swamped by its own popularity and goes down. What went wrong?
One thing that is probably going wrong is that the server is buffering all of the map data in memory while sending the maps out. Since those maps are large, it takes a while to deliver a map, and there are many clients, these buffers fill up a lot of server memory. WCF supports multiple modes for transferring data. In buffered mode, messages are turned into a byte array from which data is read and sent across the transport. In streamed mode, we can dribble a little bit of the message out at a time without having to allocate a buffer the size of the message. Even in streamed mode, the SOAP headers are buffered because we need all of them before we can process the message. However, headers are usually small compared to the size of the message bodies. Streaming transfers are an obvious solution to this buffer allocation problem.
The problem is, we can't just switch from buffered to streamed mode with this architecture. Our security is provided by message security at the SOAP level. Message security requires us to use buffered mode so that we can process the protected messages. The solution is to switch from security at the message level to security at the transport level so that we can enable streaming. There are tradeoffs to this approach that I'll talk about in the future, but for now let's change the architecture to use transport security which is applied to the stream as it goes across the network.
Here's a sketch of the new architecture:
Now, we get a much smaller growth rate of allocated memory and can support many more clients with the same hardware.
Streamed transfers have the same problems with proxy servers as I mentioned before. The decision to use a streamed or buffered transfer mode is a point-to-point decision. A proxy server or other intermediary is going to choose a transfer mode according to the system policy of the administrator.
Next time: Slicing the Windows Communication Foundation Technology Stack, Part 4
Yesterday I introduced a simple web service scenario along with one way to solve the scenario using WCF. If you actually tried to use that architecture though, you would quickly run into a couple of problems.
The first problem is common and I hope that it will be easy to diagnose when the problem is occurring. The transports we ship with WCF try to be secure out of the box. Each of the standard transports has a security setting (called MaxMessageSize in earlier preview releases and MaxReceivedMessageSize in later preview releases) that limits the maximum size of a SOAP message that the transport will attempt to receive. Once a message exceeds this limit, the transport raises a fault and stops receiving data. This limits Denial of Service attacks that try to fill up system memory by sending your service a never-ending message. By default, we conservatively put this security setting at 64 kilobytes.
This poses an obvious problem for our scenario that is going to be sending large blobs of data in messages. When the transport faults, you'll get a nice exception and trace on the receiving end telling you that there was an overly large message. The solution is to tune the quota value for this setting on the transport. Since we expect to receive large messages in this scenario, and we're willing to spend the additional memory, we can increase this setting to avoid the problem. The maximum size is a 64-bit value in case a message size of 4 gigabytes is not enough for everyone.
One thing to be aware of is that intermediate channels and transports can also have policies controlling maximum message size. If you are connecting through a proxy server that has a limited message size, then changing this setting on the endpoints cannot help you send larger messages. The setting on an endpoint does not push through intermediary connections. Proxy server administrators control their own quota settings through system policy.
The other problems with this scenario are performance related and require thinking about how transports interact with higher-level web service features.
Next time: Slicing the Windows Communication Foundation Technology Stack, Part 3
Now it's time to start digging a little deeper into the guts of WCF. I decided to make up a simple scenario that just happens to exercise lots of WCF technologies. Since I'm not going to be writing about the various WS-Whatever standards for a while, I'll go easy on the application and service level protocols except for a couple of standards that impact decisions about the channel and transport layer.
Steve has a really big data problem. He wants to deliver customized maps to people over the Internet. He's going to expose a service that lets people send their location and a query as a request. He'll send them back a map image and markers that describe points of interest on the map. I'm sure that Robert Scoble knows a thousand companies with this business plan, but let's pretend that Steve thinks he can actually make money providing this service. Steve wants to authenticate users and make sure that they've paid him. Steve also wants to make sure that users get the maps that they've requested even when they're using a flaky cellular phone as their network provider. And, he wants make sure that no one else can see or tamper with the maps or queries.
A couple of the requirements jump out as triggering obvious technology needs. Since we need to guarantee that messages arrive, we'll use reliable message. Since we need confidentiality and integrity, we'll use SOAP security with some kind of trust scheme to provide the authentication. It's also important to think about the performance of the scenario since we are transferring large messages. Bandwidth is an issue so we'll use an efficient binary encoder for the messages with a lightweight TCP/IP transport. This architecture gets a lot of things right, but we'll talk later about what it gets wrong.
Here's a quick sketch of what we've got so far:
I've indicated a couple of slices in the technology stack that correspond to different conceptual layers in WCF. Off the top of the picture is the logic for the actual application and any application-level protocols that we might use, such as WS-Federation. Below that are services like reliable messaging and security. These provide the assurance that some complicated property is taken care of for us. Below that at the messaging layer, there are technologies for constructing an envelope containing data and an address for delivery. At the very bottom is the transport layer that is responsible for actually sending the data to the correct address.
Next time: Slicing the Windows Communication Foundation Technology Stack, Part 2
After a quick diversion to introduce WCF, I wanted to go back and finish introducing myself. I promise that this is the last introductory post in my queue. WCF has so much to talk about that I can fill every day between now and when Vista comes out just focusing on the channels and transports area!
Before coming to Microsoft, I spent several years working on computational biology at Virginia Tech. What does computational biology have to do with communications frameworks? Well, not much exactly, at least not directly. It was a bit of an unusual transition to come work for a software company. However, computational biology, like many scientific applications, has a huge need for raw computing horsepower. We needed far more resources than were available on the typical desktop computer to attack problems at the state of the art. At the same time though, we still had to make the applications available from every user's desktop.
The obvious solution to this problem was to build distributed computing applications that let scientists access supercomputer resources from anywhere in the world. We wasted a year building a distributed system that was brittle and slow. Today, you can use WCF to link together two programs with a highly-performant, robust, and reliable communications infrastructure in a couple of hours. If that's not good enough, with WCF you can also in a couple of seconds then enable encryption and authentication, apply compression and chunking, change how messages are encoded, or even swap out the entire technology stack for how messages get from Point A to Point B. I would really love to have had WCF five or ten years ago. Those troubled times gave me a passion for platform solutions that make writing programs suck less.
It's also an unusual transition to come from an academic lab to go to a group that actually ships products. What's different though is that the Indigo team is a high-powered one compared to many other teams at Microsoft. Last week I was walking down the hall to the kitchen for some more iced tea, and along the way, there were four Architects chatting in people's offices. This building has a serious concentration of talent.
Next time: Slicing the Windows Communication Foundation Technology Stack, Part 1
When I say that I work on the Windows Communication Foundation team, a lot of people ask me the deep and piercing question:
"What's that?"
Sometimes I try to prompt them with the former codename 'Indigo', figuring that they just haven't heard the latest renaming news. This is usually followed by some awkward silence until I launch into a description of the evidently more famous technology also coming together at the same time: Avalon. Who knew that people were so excited about having their close buttons rendered in 3D? It's not so bad when your parents don't know what you're working on, but it stings a little when even people at Microsoft haven't heard about this exciting technology.
WCF is a delicious concoction of XML, network technologies, SOAP, Web Services standards, and a special blend of essential oils extracted from Don Box. If you have a program written with managed code, and you need that program to talk with another program, then WCF may be the right technology for you. Do you consider any of these attributes important?
Interoperability
Performance
Reliability
Security
Hosting
DeploymentActivation
Easy development
Long-term support
If so, then think about using WCF for your communication needs.
WCF is a technology that is shipping in the Vista timeframe. However, WCF also targets running on the XP and 2003 Server platforms as long as you've got the 2.0 .NET Framework installed. If you're too impatient to wait for Vista, then you can start using WCF today, starting with the January CTP release.
All of my discussions over the next several weeks will deal with the preview releases. As we get closer to shipping the magical Version 1.0, I'll also talk about the design changes we've been making along the way.
Next time: Hello World, Part 2
Hey everybody, I'm Dr. Nicholas Allen, and I'm a Program Manager at Microsoft on the Windows Communication Foundation team (formerly known by the much hipper name 'Indigo'). For those of you that don't know what a PM does, check out the very extensive description by Steven Sinofsky, which talks about the different kinds and roles of PMs here at Microsoft. In short though, I make sure that WCF has the right features at the right quality for my particular feature area.
That's a pretty open-ended job description because delivering a platform library like WCF involves a lot more than just giving you some assemblies to run. We have a commitment to provide you with the extensibility, usability, and documentation that lets you build applications on top of our platform that we've never even dreamed of. Microsoft is serious about making WCF the platform of the future that you can pick up and use whenever you need to make two programs talk to each other. There's a real challenge to provide powerful, well-thought out APIs that you can use in your applications today, and that you'll still be using 10 years from now.
Over the next several weeks I'll be doing a deep-dive into the heart of the WCF technology stack. The features that I work on are the transports and channels all the way down at the bottom of the stack. Two people down here with me are Yasser Shohoud and Kenny Wolf so check out their blogs as well. There's going to be a little bit of topic duplication between us, but I hope you're going to find all of our perspectives interesting. Right now it's hard to find technical details about what happens in the guts of WCF and we're going to change that.
Now hopefully, most people aren't going to need to know a lot of details about the technology at this level. We want the IT professional to build business applications without having to worry at all about how we sling bits around. However, every WCF message ultimately goes through channels and out through a transport. If we could somehow turn off these interfaces so that they no longer worked, then everything would grind to halt. As you can imagine, these classes also form a very important integration point whenever you want to build an application that goes beyond our core scenarios.
This week I'll concentrate on some lighter topics before focusing on the technical details of WCF.
Next time: Windows Communication Foundation Big Picture