Extensibility

One of the frequently repeated phrases around SOA development is that SOA allows you to build composite applications that span heterogeneous environments. It's tough to put a perspective on how heterogeneous an environment can be until you look at surveys of protocol usage in the enterprise. There must be several thousand different protocols used on a daily basis, some of which are used only at a single site and some of which are used at millions of sites around the world. Of those thousands of protocols, a single, large application may be using several dozen protocols in conjunction to solve a business problem. Many of the protocols are small and insidious, creeping into an application to take care of an important but not necessarily central problem. A small handful make up the core set of protocols used to move data from system to system in bulk.

Although Microsoft is a large company, we can supply only a limited set of protocols with our products compared to the thousands of protocols that exist in the wild. Primarily, we focus in WCF on the core set of transport protocols and on the infrastructure protocols that have broad and generally applicable uses. I value very highly that all of the features needed to build an application have a consistent design and integrate with each other well. We try to cover the collection of standard protocols such that many customers will be able to get all of the features they need from a single source. Nevertheless, we're never going to be able to cover every protocol in the world and there are going to be many customers that will need to get their features from multiple sources.

That's why I consider extensibility to be a more valuable feature in WCF than any single protocol that comes in the box and that's why I spend so much time writing about how to use WCF extensibility. BizTalk is an example of a product that developed a relatively large market for third-party components so that application builders could source many of the features they needed without having to write the code themselves. My goal is to create a similarly robust developer ecosystem for WCF.

There are already partners starting to deliver into that ecosystem. IBM has published a WCF channel that lets more people talk to existing WebSphere MQ systems. Noemax has created WCF components because they see a market supplying protocols that are optimized for particular communication and consumption patterns. Developer Express wants to make developers building these applications more productive. Seeing an early market emerge based on the extensibility and consistency of the platform makes me feel good that we made the right choices about balancing the features of the product with the openness of the product.

If you're doing interesting things with WCF extensibility, then I want to know about it. I'm not going to promise to publicize every effort, but developers that make themselves heard have a lot of power to influence what gets shipped in future releases.

Next time: When Certificates are Required

Comments

• Anonymous
  October 23, 2007
  The hierarchy of channels derives from the single interface IChannel. By itself, IChannel is not particularly