软件质量保证SOA实现中的4个最差实践

关键字：SOA

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

　　过分强调低级别的代码

　　上榜理由：重用性差，难以根据业务的变化迅速地做出反应。

　　解决办法：关注业务级别的服务。将整个系统切分成逻辑的构建单元——即所谓的服务——将创建出一个随业务需求一道成长的可持续解决方案。Jake Freivald将服务分为3层：细粒度服务、粗粒度服务和全局服务。并写道：

　　当组织过于强调细粒度的服务时，其结果就是有太多无法聚合成业务层服务的服务。照这种方式编码，将创建出难以维护或复用、低效且复杂的流程

　　集中设计和部署

　　上榜理由：其一，知识依赖个人，当这些人离开时，知识也随之一起离开;其二，个人不可能熟悉所有系统，当需要设计和构建服务的系统超出其知识范围时，难以设计出好的服务。

　　解决办法：分散服务创建。服务的分散化和本地维护，这使得粗粒度和全局服务的开发者不必时刻关心底层信息资产，而且底层服务开发者的变更不会影响到整个系统

　　撕碎并替换遗留软件

　　上榜理由：只看到了数据的重要性，却没有意识到遗留应用同样也是信息资产之一。并且由于对数据迁移的困难估计不足，造成项目延误，更有甚者直接有损于日常业务。

　　解决办法：重用为王。只要遗留系统还能工作，就不要管它。为技术而升级技术永远不是一个好的业务选择。

　　购买没有支持的软件

　　上榜理由：缺乏对操作SOA软件的足够认识，很可能会构建出过于复杂的系统，以及没有为任务选择合适的工具。

　　解决办法：要成功，就要有支持。就算企业有SOA架构师来帮助组织来建立SOA的原则，但要想成功，依旧需要把工作落到实处。

　　组织设计的成果是消息转换还是消息分拆，到底有多大影响?最好预先花时间把这搞明白，免得再在架构上线运行之后去去和

　　效率问题相纠缠。通过足够支持的保驾护航，组织可以避免开发出过于复杂的系统，并知道哪个工具是针对哪项工作的合适工具。

原文转自：http://www.ltesting.net