下面把装的过程中遇到的一点需要注意的地方记录下来,希望其他兄弟不要在这里被卡哈 ..

          其实就是别忘了在装Vs2008sp1 补丁之前一定要将Win2008的补丁打全 .否则 莫名其妙的装不过去 .

          够简单吧??  但是要是不知道到的话能累死你 。  反正我是郁闷了半天。特此纪念一下吧。。

http://blogs.ittoolbox.com/visualbasic/dotnet/archives/wcf-and-soa-getting-there-from-here-18438

      面向服务的架构也就是我们常说的SOA对软件研发而言是一个非常重要的改变。它使我们对已经建立的项目的看法也发生了改变。这种变化决不仅仅是肤浅的我们必须考虑谁是SOA的听众等各种因素（吹嘘软件支持SOA架构），或者具体的应用SOA我们能够解决哪些特定的业务问题。

     传统上来说，SOA被理解为将软件看作是服务，这就意味着我们必须提供大量的服务给更宽泛的使用者，免费的或者收费的。Google是个将SAAS（软件看作是服务）作为他们的Open API 和许多免费产品的指导思想的绝佳例子。随着时间的流逝，SAAD思想的设计者不断的鼓励人们一遍遍的进行着这种挑战：如何去以一种可重用的方式去暴露服务，怎样提高这些服务的安全性以便与使他们货币化（转换为商业价值），还有怎样允许不同技术背景的客户们能够使用这些服务。 这些年来，软件框架被发明了，软件技术也发展了很多，在提出SOA架构以前，人们一直正在思考着服务会变成什么样。 .

      我不十分确信是有人创造了SOA架构，这是随着IT界的发展大家普遍认识到的，并且冠以SOA的技术名词。有人声称基于个人的技术和模式来支持SOA架构，但是我认为SOA是有机的推导出来的一个范例，它的好处远远大与在实施过程中可能会遇到的挑战和可能会花费的费用。SOA真正的引起大家的关注是从90年代末到21世纪初，作为可管理的框架和主流得Web应用框架最终发展到这个阶段，微软意识到了这种趋势得强大性，创建了一整套新的创建基于Web服务应用得方法，并且与2001年ASP.Net 1.0一起发布。

      asp.net具有一些新技术的特点，（微软提出并且得到承认成为了标准）被大家广泛接受为Webservice。其中的一些技术，早期版本得SOAP等，已经在早期得Microsoft's DNA architecture for Visual Studio 6项目研发人员中得到了应用。但是当asp.net1.0发布后，Soap与其他必要得技术一起使Web service成为对与没有资金建立Windows IIS server得人员真正得有用的技术。

       在我们认识SOA之前，中间件产品如Vitria BusinessWare等都属于这个范畴。 厂商们需要话费大量的资金去建立这些中间件解决方案，以便于可以和不同的技术之间相互协作。这是非常巨大的，昂贵的，不十分灵活的解决方案，常常需要很大的开发团队，以及维护瓶颈。.不要被“如果用的好的话，他们会做的非常的好” 这句话误导。这些中间件方案是定位在解决特定需求（一旦特定需求满足，整个工作结束）的问题， 这种问题远没有满足产品需求那样复杂。

       当Asp.net发布后，一位记者表露了WebService对他来说以为着什么，他说：“WebService 就是一种面向大众得中间件”。 没有比他这种说法更贴切得了。Web Service 技术，比如SOAP确实是对系统不熟悉得人相互交互成为可能。在SOAP发布后得不长时间内，中间件厂商竞相将SOAP集成到他们得产品中。这看起来有点近乎疯狂，但这确实满足了在传统得没有使用SOAP技术得系统与新的已经在使用WebServer技术得系统之前建立一座桥梁得目的。

        在当时那种环境下，面向服务得架构依然没有像现在一样成为普遍得词汇，在此之前，如果你在谈论SOA，实际上你在谈论得是WebService 或者中间件，随着这两种技术的发展，他们之间不断的发生碰撞，越来越多的人开始意识到SOA的蓝图是什么样子,WebService不仅仅是一项技术，或者一个工具，而是一种从内到外的做事情的方式。

        微软在这一时期表现的意气风发。作为SOAP和Web Service的主要的支持者之一(可以说微软在这些技术上投入了很大的赌注)，微软持续的努力推动这些技术的进步，进而使SOA成为可能，在一伙儿天才的努力推动下，微软决定将 named-pipes, TCP-binary remoting, DCOM, MSMQ 等等这些技术结合起来创建一种可重用的，可插拔的框架用以支持进程间的协作与交流，但是却没有达到令人振奋的效果。在传输过程中，进程间往往需要将一些共有的或者私有的信息格式添加进来。如果我们能够在运行时去制定这些传输方式和信息格式，而在设计时只关心我们的业务实现的话，这种问题就能够更高好的解决。

正式在这种思想的指引下WCF应运而生了。WCF一开始是打算绑定到Longhorn操作系统与2004年发布的。如果当时longhorn操作系统如期发布，可能Wcf就会成为Longhorn操作系统的特定技术了。然而现实是Longhorn操作系统（Vista，Windows Server2008）的发布却一再延期，高层们意识到让用户们去等待WCF发布的代价太大了。结果，WCF被作为.Net Framework 3.0 的一步分与2006年秋发布，并且可以兼容Winxp系统和Win2003 系统，这样，重点就转到了这个关键的Framework是否能如期的发布。

       对微软走向SOA的道路来说，Longhorn系统发布的一再延期却成为最有益得事情，假如WCF真的作为Longhorn的一个特性发布，企业用户可能会怀疑微软有“挤牛奶”之嫌，进而对WCF在微软SOA道路上的重要性产生怀疑。然而现实情况是WCF是微软不懈余力的在面向服务这块领域上下的赌注的核心和前沿。

       有一小部分坚定的用户对微软的任何事情都十分狂热，而大部分的微软用户都只是信任微软的技术，而采取观望的态度。   微软在WCF方面做的比较漂亮的地方是使用户们认识到WCF 是由Web Service发展来得。在此之前WebService已经出现了近十年了，WCF只是是它变得更精巧。这使的一方面这少部分的狂热者不会对WCF失望，另一方面他们带来的好处也是不可否认的。

       WCF带来的最大的好出就是相互协作的能力，它这么重要是因为微软意识到没有任何一种技术可以在企业服务市场独自垄断，这就意味着可以与其他技术很好的协作变得十分重要，也正因为此SOAP等等的这类技术变得不可或缺，使用这些技术所面临的问题是在必须达到好的互操作性这种抽象的层面上令人畏缩，也正是由于此，中间件产品市场才会逐年增长。随着WCF的发布，将结束这一混乱，令人畏缩的时代。

SOA的强大之处之一就是他天生的具有很好的可扩展性。每一个SOA都可以被看作建设更大的应用的基础。大块的功能可以被分散到可管理的和经济上可依靠的子系统中。这种分散使我们能将注意力更加集中在需求的获取和相关功能的开发上，从而提高系统的可依靠性。同时，通过可以提供可以用在任何客户端上的稳定的功能模块（比如GUI，Website，或者其他的SOA应用中）。SOA天生的具有横向的和纵向的可伸缩性，进而使N层架构的真正有点被体现出来。

       SOA的功能十分的强大，就像Ben Parker说得那样强大的力量意味着更大的责任。SOA不是免费的，要达到如此的进程间互操作性，需要的代价是更加的抽象.向上述的那样，SOA也不是适合与任何的阿系统或应用。你必须在商业需求的增长和可扩展性与性能以及资源的利用上作出权衡。SOA的应用肯定不会向客户端应用那样迅速，也不想数据库解决方案那么”苗条“。架构师和经理们需要做的是确保应用SOA在合适的地方。
（翻译此文有两个目的 ，1 加深自己对SOA与WCF的理解。2 锻炼自己的E文 。呵呵 肯定有一些是翻译的不妥的地方，希望大家批评指正，对大家有利的地方希望大家吸收，更希望不会被我误导。 嘻嘻！：））