本文目的
需求变化是软件开发过程中的一大难题，我们经常扼腕叹息：面对变化，我们的软件为何如此不堪一击？我们常常在众多需求变化导致的功能爆炸中疲于奔命，甚至迷失自我！这到底为什么？面对"拥抱变化"这种得呐喊，我们的感受应该是震耳欲聋，还是振聋发聩？如果你仍在困惑，可以来看一看WCF是如何摆脱这种困境的！
序幕
小王效力于北京的一家系统集成公司，该公司内部有一个WCF服务为各个部门所共用，小王便是WCF服务的开发和维护人员。起初大家在一个办公楼工作，共用一个局域网，WCF运行的非常好，小王也因此获得了公司上下的一致好评。此时他们的WCF的使用状态如下图所示：
起初小王以为公司都在一个局域网之中，考虑到性能，WCF最早采用的是NetTcpBinding的绑定方式，契约部分是根据自己的业务需要开发的， 而他为服务公布的最早的地址为：net.tcp://127.0.0.1:6547/Service。他最早是用代码方式将服务托管到一个Console程序中的，托管代码如下：
ServiceHost host = new ServiceHost(typeof(ServiceLib.Service));
NetTcpBinding bind = new NetTcpBinding();
Uri address = new Uri("net.tcp://127.0.0.1:6547/Service");
host.AddServiceEndpoint(typeof(Contracts.IService), bind, address);
而此时大家所使用的客户端代码均为：
NetTcpBinding bind = new NetTcpBinding();
EndpointAddress address = new EndpointAddress("net.tcp://127.0.0.1:6547/Service");
Proxys.IService ws = new Proxys.ServiceClient(bind, address);
这样一种情况下，小王的WCF服务与各个部门之间可谓是其乐融融。可好景不长。各位看官，请看下文：
使用范围扩大
随着近几年公司业务的持续发展，公司在唐山的业务量非常大，所以在唐山成立了一个办事处，而该办事处同样需要使用小王的WCF服务，可原本出乎小王意料的事情发生了：唐山办事处和公司总部处于不同的网络，如果还使用tcp这种传输方式，就不适用了。公司头们为这事也挺犯愁，本来以为还要劳烦小王大改一通，没想到小王却说："小意思，马上解决问题！"他首先和公司网络管理人员联系，将WCF服务所在主机配置１个公网IP为202.120.120.3,然后再托管程序的代码中增加几行
BasicHttpBinding bind = new BasicHttpBinding();
Uri address = new Uri("http:// 202.120.120.3:80/Service");
host.AddServiceEndpoint(typeof(Contracts.IService), bind, address);