SOA借鉴设计模式

日期: 2008-01-24 作者:Juishl 来源:TechTarget中国

  做软件设计的,就算没有机会仔细研究过设计模式,多少都听说过“四人帮(Gang of Four)”的《Design Pattern》。“设计模式”的四个伟大的作者,把面向对象软件设计的代码复用推向一个新的高度,第一次将设计模式规范化,并提升到理论高度。虽然软件设计模式针对的是代码片段的复用,而SOA实施中讨论的是服务的复用,是软件开发中两个不同层次的问题,但是因为面向对象的软件设计也是SOA的一大支柱,所以这里有共性,设计模式许多好的思路,在SOA的服务复用中值得借鉴。
 
  在面向对象软件设计中,具体的应用软件是用许许多多的类(Class)代码来构建。设计模式理论就是指导如何有效的组织类代码形成具体应用软件。譬如说,通过Strategy Pattern定义一系列的算法封装类,使它们可相互替换,使得算法的变化可独立于使用它的客户;通过Composite Pattern将对象组合成树形结构以表示部分-整体的结构,让客户对单个对象和复合对象的使用具有一致性。在SOA实施中,具体的应用系统由许多按照良好接口定义的服务构成,通过何种有效的方式来组织这些服务,同样需要理论指导,或者说同样可以定义SOA的模式。譬如说,能否定义有效的模式把低层次的服务组装成高层次的服务,同时兼顾低层次服务的可替换性,以保持足够的业务灵活度。
 
  在定义SOA模式的时候,还可以借鉴设计模式的诸多原则。譬如说,面向对象软件设计中的里氏替换原则(Liskov substitution principle),对父类的调用同样适用于子类(Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.) 。同样的原则,对于SOA也是非常有意义的,在原有服务基础上扩展功能的服务应该保持良好的兼容性,让原有系统的服务——消费关系无需改变就能适用新服务。以此为例,许多成熟原则的运用能加速SOA的演进。
 
  等同设计模式的作用,定义SOA的模式,其实是利用模式来共享专家知识。SOA作为新生事物,刚开始的时候,只有少数经验丰富的技术专家和业务专家能够掌握其精髓,熟练运用到具体的业务领域,构建优秀的SOA系统。如果从专家们实施的成功项目中提炼出SOA运用的最佳实践,也就是“模式”,通过广泛的推广模式运用,就相当于快速复制专家经验。一方面,经验不够丰富的人不会因为白手起家而无所适从,他们可以基于模式做SOA实施,提高成功率,在学习专家经验的同时提高自身水平;另一方面,模式让SOA作为专家知识载体,在广泛的运用过程中,有机会进一步得到修正和提升,千锤百炼后最终更加完善适用。
 
  那么,谁会推动模式的定义呢?作为专家知识载体的模式,可能会分别来自于SOA平台工具厂商,开发社区,以及企业。这三个来源对模式定义的侧重点会有所差异:平台工具厂商会定义最大限度利用其平台特性的模式,并辅以相应的开发工具;开发社区往往讨论通用的模式,帮助形成定义模式的标准;企业的模式定义最实用,而且和行业应用紧密结合。不管何种来源,模式定义殊途同归的结果是加速SOA系统构建知识的普及。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

作者

Juishl
Juishl

相关推荐

  • 事件驱动框架和SOA在空军的应用

    空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。

  • 应用开发策略选择

    每个软件架构师,开发经理和开发人员都很可能遇到过软件设计和开发中“自上之下vs.自下而上”的争论。正确的答案其实是,这里并没有单一的最佳方案。

  • 揭秘New Relic APM技术细节

    New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响

  • 仅凭SOA和云无法解决业务数据管理风险问题

    SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。