ITPub博客

首页 > Linux操作系统 > Linux操作系统 > SOA实现中的4个最差实践

SOA实现中的4个最差实践

原创 Linux操作系统 作者:isoa 时间:2009-03-20 14:10:13 0 删除 编辑

在铺天盖地的SOA宣传文章中,最佳实践是出现频率最高的词汇之一。相比起来,最差实践就没那么风光了。但是,俗话说得好“吃一堑,长一智”,看看别人犯过的错,未尝对自己没有帮助。最近,Information Builders的市场副总裁Jake Freivald就撰文介绍了SOA实现中常见的4种最差实践,并针对每个实践给出了解决方案:

  1. 过分强调低级别的代码
    • 上榜理由:重用性差,难以根据业务的变化迅速地做出反应。
    • 解决办法:关注业务级别的服务。将整个系统切分成逻辑的构建单元——即所谓的服务——将创建出一个随业务需求一道成长的可持续解决方案。Jake Freivald将服务分为3层:细粒度服务、粗粒度服务和全局服务。并写道:
      当组织过于强调细粒度的服务时,其结果就是有太多无法聚合成业务层服务的服务。照这种方式编码,将创建出难以维护或复用、低效且复杂的流程
  2. 集中设计和部署
    • 上榜理由:其一,知识依赖个人,当这些人离开时,知识也随之一起离开;其二,个人不可能熟悉所有系统,当需要设计和构建服务的系统超出其知识范围时,难以设计出好的服务。
    • 解决办法:分散服务创建。服务的分散化和本地维护,这使得粗粒度和全局服务的开发者不必时刻关心底层信息资产,而且底层服务开发者的变更不会影响到整个系统
  3. 撕碎并替换遗留软件
    • 上榜理由:只看到了数据的重要性,却没有意识到遗留应用同样也是信息资产之一。并且由于对数据迁移的困难估计不足,造成项目延误,更有甚者直接有损于日常业务。
    • 解决办法:重用为王。只要遗留系统还能工作,就不要管它。为技术而升级技术永远不是一个好的业务选择。
  4. 购买没有支持的软件
    • 上榜理由:缺乏对操作SOA软件的足够认识,很可能会构建出过于复杂的系统,以及没有为任务选择合适的工具。
    • 解决办法:要成功,就要有支持。就算企业有SOA架构师来帮助组织来建立SOA的原则,但要想成功,依旧需要把工作落到实处。
      组织设计的成果是消息转换还是消息分拆,到底有多大影响?最好预先花时间把这搞明白,免得再在架构上线运行之后去去和效率问题相纠缠。通过足够支持的保驾护航,组织可以避免开发出过于复杂的系统,并知道哪个工具是针对哪项工作的合适工具。

Loraine Lawson对这篇文章评论

Freivald特别提到了与“使用SOA作为一种集成解决方案”相关的最差实践。现在,我知道,有些人说SOA不应该用作集成。其总的观点是避免点对点、紧耦合的方式。但是,如果做得好,SOA可以解决很多你的集成问题。

Jignesh Shah则对于Freivald的“分散服务创建”表示出了不同看法(注:见该文的评论部分)

看到服务的“集中设计和部署”被列为一个最差实践着实令人觉得有趣。我们越来越多地看到客户建立“共享服务”组织给他们乳臭未干的SOA来掌舵和提供动力。这样一个组织负责围绕企业范围内的核心系统识别、设计和交付服务。这有几个好处,包括可以全盘考虑整个企业的服务组合的塑形,简化资助模型,以及打通政策壁垒。

这样一个组织要对他们准备在其之上构建服务的系统非常了解,Freivald在这一点上是对的。这是为什么实际常常选择集成团队作为SOA共享服务组织的原因。这个小组有企业的视角,有处理核心系统的经验,理解异构环境下的挑战,并拥有所要求的中间件相关的技术技能。

Freivald建议的“分散服务创建”方法实际要求一个理想化的公司,在那里,他人利益排在每个小组利益的前面。这在大多数开始建立SOA的大型组织中实在难以出现。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14780828/viewspace-573218/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-07-07

  • 博文量
    251
  • 访问量
    296209