当你在考虑服务型架构(service-oriented archITecture，下称SOA)的厂商时，你脑海中出现的第一个名字或许不会是微软公司(Microsoft，下称微软)。尽管微软的Windows操作系统在桌面电脑上一统天下，并且在服务器市场上也是咄咄逼人，但是与SOA紧密相连的名字却依然是Java和Linux。

　　不过，微软是不会甘居人后的，为了改变这一切，它制订了宏伟的计划。微软已经进入了企业服务总线(ESB)市场，在SOA治理方面也已有所行动，并且它还和管理厂商展开了密切合作。近来，它还雄心勃勃地宣布，公司将要推出的技术可以让每个人都变身为软件开发师，届时微软将成为整个B2B网络服务业的中心。

　　遥望总线

　　微软总部一向对外宣称，他们从来都是支持SOA的。它将SOA视作了商业流程管理(BPM)的基础，而不仅仅是一个终端。从某种程度上来说，这倒是没错。对于SOA以及建立在SOA之上的许多Web服务标准，微软很早就表示了支持的立场。

　　大部分人都认为SOA是一种构架方式，而不是一种特定的产品。微软走得更远，它甚至不把ESB当作产品来看待。当下，许多厂商都提供独立的ESB，多数人也认为ESB是SOA的核心组成部分，但微软的看法却并非没有道理。它的做法是将ESB的功能分散到了好几种产品身上，这种情况只有在微软的世界里才会看到。

　　分解ESB并不一定是什么坏事。从传统上讲，ESB一直被分成了至少两大块：服务激活(service enablement)先将一些程序打散成为可再次使用的组件，然后服务编排(service orchestration)再将它们重新整合成复合程序。更重要的是，ESB通常是运行于多个服务器之上，而BPM通过只作为运行于服务编排上的第三层，管理由人和机器执行的任务。

　　微软拆散程序的方式与上述方法不同。BIzTalk Server会负责从激活到编排再到BPM的所有整合任务。不管是单独使用SOA还是BPM，要开发应用程序都需要用到Visual Studio，而InfoPath和SQL Server则会提供大多数ESB都具备的XML转换、路由以及管理任务功能，不过，这些都可由Web服务管理器来完成。

　　对于多数踌躇于微软SOA的用户而言，服务激活是最大的问题。大部分用于SOA的应用程序服务器都是基于Java Enterprise EdITion来设计的，但微软使用的却是.Net，这就带来了兼容性的问题，也就是说，为某一个平台编写的程序很难应用到另一个平台上。不过，两个平台之间仍可以通过标准的Web服务或各种适配器来共享数据。

　　其他厂商的ESB能与.Net对接，BIzTalk也能在其他环境下应用。和多数ESB一样，BizTalk包括的适配器让它能够识别信息格式和其他应用程序使用的应用编程界面(API)。微软提供的适配器虽然没有竞争对手多，但它却能识别Java Message Service这种许多其他SOA内部使用的格式。

　　在微软自己的应用软件之中，最重要的适配器是针对Windows Communication Foundation(WCF)架构的。该架构用于开发在3.0版.Net之下运行的分布式应用程序。在纯Windows的环境下，ESB就显得有些多余了，因为松耦合的SOA原则可以被应用到内部的组件上。这样一来，应用程序就可充分利用多核芯片的优势，而使用Windows的程序员开发起SOA程序来也会轻松得多。

　　SCA和WCF并不能直接兼容，但它们都使用了部分的WS-*架构，因此，利用任何一者开发出的程序都可与网络服务挂钩。不过，在数据层面也会出现兼容问题。SCA使用的是Service Data Objects(SDO)架构，一些厂商正致力于扩大这一架构，以便能在其中实现通用数据的集成。然而，微软却没有加入这个队伍，不过它倒是推出了一个名字与之类似的产品，叫做Server Data Objects，该产品用于Windows服务器的远程访问API。

　　微软还打算将适配器分开出售，而不是将它们与BPM或ESB绑定在一起。这个市场的潜力比SOA要大得多，因为它意味着可以通过标准的网络服务提供对旧有系统的访问。这些服务往往能够通过基于浏览器的富因特网应用程序(RIA)进行访问，这就相当于赋予了大型机应用程序一个Ajax界面。不过，利用标准化的API也可组建混搭程序，最终还能开发完整的商业流程管理(BPM)类型的程序，微软将这种办法称之为“增量式SOA”。而客户端程序也不止浏览器这一种，微软还表示要将所有的Office应用程序都打造成Web服务消费程序。

　　在大多数情况下，这仅仅意味着客户端的Office应用程序使用基于Web服务集的协议与服务器端相对应的程序进行通信。与Exchange相连的Outlook客户端程序便是如此，但现在微软已经将这一措施推广到了与SharePoint通信的大多数Office应用程序上。与Exchange/Outlook的封闭式系统不同，微软力图将SharePoint/Office打造成为一个更加开放的平台，让企业内部的程序也能进行访问。

　　规划未来

　　目前，多数RIA都使用Ajax，但微软希望程序开发商最终能把许多RIA转移到它新推出的Silverlight平台上。与ActiveX和Windows媒体播放器等早期客户端技术不同，微软的Silverlight具有跨平台(支持苹果机)和跨浏览器(能与Firefox、Opera及Safari兼容)的功能。

　　显然，微软的目的是要将浏览器边缘化，它希望RIA的开发商能瞄准一个更加丰富的平台。然而，Ajax的广泛兼容性意味着它仍将是公共互联网上应用程序的首要平台，像Flash之类的平台目前还只能充当配角。在负责浏览器脚本标准的组织欧洲计算机制造商协会(ECMA)中，微软与非营利性组织Mozilla Foundation正在就未来浏览器脚本的问题争得热火朝天。

　　在企业内部网中，有关标准化的争斗则不那么激烈：基于Web的应用程序只需支持标准的企业图象即可，不需要照顾到每个用户。然而，即便在这个领域，Silverlight还是遭到了对手Flash和Curl强硬阻击。微软希望Silverlight能获得程序开发商们的青睐，因为他们不管是为浏览器、Web服务器还是一般的Windows程序进行开发工作，都可以使用同样的工具，如Visual Studio和C#。不过，微软可得看到Java的前车之鉴。当初Java也能为开发商提供此类理论上的便利，并且一开始还在服务器上一统天下，但最终在桌面电脑上却乏人问津了。

　　从长远上看，微软许诺给SOA开发商的好处远不止常规性的编程语言。微软的目标对象甚至不仅仅局限于程序开发商，它想的是将程序开发向所有用户开放，包括那些不具备编程技术的普通人。去年6月，微软公布了代号为Oslo的技术蓝图，这一蓝图在很大程度上借鉴了BPM建模工具，后者不再用一串串的代码来描述业务流程，而是改用了像操作流程图一样的图表。

　　Oslo进一步扩大了BPM建模的范畴，它连计算流程也包括在内——一开始只限于用于SOA的复合应用程序，但最终将包涵在Windows服务器或桌面电脑上运行的任何程序。微软表示，Oslo的目的不仅是要让编码变得更加简单，在它修成正果之日，许多程序根本就不再需要编码了。用于实现这一宏伟计划的解释程序将出现在未来的.Net框架中，而Oslo建模工具将被植入其他程序中，包括BizTalk和Visual Studio。

　　不过，说一千道一万，Oslo离瓜熟蒂落还差得远。据说今年微软会推出测试版的一些产品，但公司对于最终产品的发布日期却并未有个明确的表示，预计我们可能还得再等上好几年。微软曾透露Oslo将用于Visual Studio 10，可现在就连Visual Studio 9还仍然处于测试阶段。

　　自然垄断

　　BizTalk Services是微软SOA战略中最雄心勃勃的一个环节，微软将其称作互联网服务总线(ISB)。微软宣称，BizTalk Services将成为真正基于标准的ESB，它具备企业内部ESB的所有功能。与Oslo相同，BizTalk Services还未正式投放市场，甚至连上市的时间也还没有确定，不过它听起来更加实际一些，因为客户现在就能登陆labs.biztalk.net对它进行在线测试。

　　微软计划针对完全不同的两个市场分两步推出ISB。公司的第一批目标客户，是需要将应用程序与商业伙伴或第三方进行整合但却有心无力的企业。根据微软的计划，企业以后就不需要再与不同网络上的多种Web服务打交道了，它们只需要找到微软即可。

　　微软的第二步计划是，将SOA和BPM向那些无法承受ESB的企业开放。它的推销说词和其他软件即服务(SaaS)供应商的承诺如出一辙。

　　在第二步上，微软将可能面临最强硬的挑战，对手不仅仅是SaaS供应商，还包括传统的SOA及应用程序平台厂商。随着ESB的迅速商品化，红帽公司、MuleSource公司以及由太阳公司提供支持的OpenESB都推出了开源ESB，微软可能已经失去先机了。在将SOA作为一种服务来销售的业务中，微软面临的最大对手是Salesforce，虽然后者并不比微软先行多久。

　　“软件加服务”的概念显然让微软受益不少：它不仅给公司带来了两条收入渠道，更重要的是，它让微软把桌面电脑软件领域内的庞大势力伸展到了服务领域中。不过，对于客户而言，这也许并不是个好消息。SaaS的最大卖点之一，就是它不需要在本地硬盘上安装软件。虽然如今几乎每台桌面电脑上都安有Windows和Office，但如果将某项服务与Windows Server产品过于密切地联系在一起，那带来的好处可能就要大打折扣了。