科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网CIO与应用频道SOA领域 微软拒绝被忽略

SOA领域 微软拒绝被忽略

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

当你在考虑服务型架构(service-oriented architecture,下称SOA)的厂商时,你脑海中出现的第一个名字或许不会是微软公司(Microsoft,下称微软)。在大多数情况下,这仅仅意味着客户端的Office应用程序使用基于Web服务集的协议与服务器端相对应的程序进行通信。

来源:支点网 2009年2月6日

关键字: 伟库网 SOA

  • 评论
  • 分享微博
  • 分享邮件

  当你在考虑服务型架构(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也能为开发商提供此类理论上的便利,并且一开始还在服务器上一统天下,但最终在桌面电脑上却乏人问津了。

  大中小打印此文关闭窗口

  输入您的搜索字词:

  相关信息

  相关评论

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章