SOA与SaaS:构架与服务两者将在何处相遇？

newmaker

欢迎访问e展厅 展厅 3 CIO信息化管理展厅 电子商务/企业门户, IT运维管理, 制造执行系统MES, 流程管理BPR/BPM, SOA/SaaS/云计算, ... 随着SaaS的愈发火热，加之SOA的继续深入，这两种概念开始引出了一些新的混淆，市场上越来越多的人在谈论SOA产品在SaaS方面的能力。最近的一篇由对象管理组织(OMG)SOA联盟所完成的，针对首席信息官和首席技术官的调查指出，市场上存在着这样一种期待，那就是SOA改变了软件厂商的市场，因此重要的软件可以通过SaaS使用SOA的方法提供给大家。 但是，拥有清晰的定义是十分重要的事情，Current Analysis有限公司应用软件程序基础设施首席分析师Bradley F. Shimmin这样说道。 “我确实是把SaaS看作一个传递机制，这个传递机制指出单个实例/多个承租的应用软件程序，”他说。“而且我将SOA视为开发松散的耦合的软件的哲学框架。因此，SOA包括了一切关于软件是如何被架构起来的东西，而SaaS是一切关于软件是如何被应用的。” Shimmin观察了有关SOA和SaaS之间的混淆的一部分，这些混淆是源于当我们谈及服务的时候我们没有清晰的指明我们的意思造成的。 “也许这个问题滋生于服务这个词语，”他解释说。“在SaaS当中，他表示应用程序可以像任何服务一样被传递，就像你家中电话的语音一样，看起来似乎就是为你的需求量体裁衣得到的，也是你可以一定层度上客户化的东西。而SOA的定义和这个无丝毫的联系。SOA支持的服务，都是些离散的可以再使用的事务处理，这些事务处理合起来就组成了一个业务流程，是从基本的系统中提取出来的抽象代码。” ZapThink有限公司高级分析师Jason Bloomberg，赞同有关SOA和SaaS的混淆是针对于两者的不同点没有清晰的定义以及在结合使用时就出现了的问题。 “在SOA和SaaS的关系之中有大量混淆的地方。” Bloomberg说道。“SOA是一个框架的方法，而SaaS是一种传递模型。服务通过SaaS传递模型传递也许可能也许不可能达到松散的耦合以及像我们在谈及SOA的时候谈到的类似于Web服务的订立了标准的服务。大体上来说，这些服务的种类是不同的，但是我们在市场上正在寻找能够通过SaaS的方法进行传递的合约化服务的汇合点。” Bloomberg还叙述说传统的用SaaS传递应用软件程序的方法的功能已经通过网络接口实现了。最近SaaS开始试图融合Web服务，使得它可以在没有用户接口的情况下通过网络服务进行传递，但是，这种传递的方法还不是SOA。 “通过SaaS传递Web服务并不需要SOA。”Bloomberg是这样说的。 不过，Bloomberg以及其他的本文采访过的分析人士都认为SOA的方法是对SaaS有好处的。 “SOA带给SaaS的既有松散的耦合，也有约定化的、能够治理的服务。”Bloomberg解释说。“这些服务都经过约定，而且都于政策的元数据相关联，这样可以对服务提供者和服务使用者之间的关系进行约束。举例来说，这些政策也许指明的是服务需求的质量，再使用的指南或者是版本政策。” 对于版本政策的需要更加凸显了SOA能够为SaaS软件厂商提供价值的重要。他说。 “我们假设，你通过SaaS提供一个Web服务，而且你有很多顾客在使用这项服务。现在，到了该将这项服务升级的时间了。对于所有的客户而言这会发生什么呢?让他们将所有的工作停下来?他们需要手动升级他们的软件吗?每一个选项都代表着服务使用者和服务提供商之间的紧密联系——在这种情况下SOA能够解决的问题。” 提供给SaaS的SOA方法是能够解决这个问题的。Bloomberg说道，因为SOA可以提供“一个适当的事先定义好的版本政策，这样会规定用户必须每个月都要用一些规定的步骤去保证他们都在使用最新的软件。例如，通过自动的下载一个升级，在用户下载的第二天，服务将自动更新版本。现在，对于客户而言，自动化保持一个或者所有的版本和服务器同步更新是可以实现的。这就实现了松散的耦合的运作，以及一个SOA有力运转的证明。”(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (12/4/2007)