sOA经常被吹捧为企业用于解决应用程序灵活性和高维护成本问题的万能药，常常被视为帮助企业提高其it投资回报(returnoninvestment，roi)的方法。

引言

it体系结构已非常成熟，它是一种成功处理典型it问题的方法。体系结构中一个受到很大重视的相对较新的分支是面向服务的体系结构(sOA)。sOA经常被吹捧为企业用于解决应用程序灵活性和高维护成本问题的万能药，常常被视为帮助企业提高其it投资回报(returnoninvestment，roi)的方法。sOA是用于进行it系统设计以确保业务目标与it一致的主要体系结构样式，允许构建具有弹性的it系统来满足新的和不断变化的业务需求。

sOA的优点(如提高灵活性、互操作性以及降低维护成本)得到了广泛的宣传，且经受住了时间的考验。这个成功记录让越来越多的企业开始跟着采用sOA，努力想获得这些好处。企业宣布启用sOA将导致sOA活动的增加，如对遗留应用程序进行转换和现代化工作，从而实现以服务为中心，并遵循sOA的原则和最佳实践。但sOA倡导者和采用者在应用sOA时需要保持警惕，因为采用sOA的过程并不总是一帆风顺或完全不出问题。在本文中，您将了解各种常见问题，如果架构师和开发团队在未进行全面而细致的前期工作的情况下贸然尝试采用sOA就可能遇到这些问题。

正如模式是获得反复成功的明确选择，反模式会带来很容易导致失败的失误。在开发人员和架构师尝试全面了解sOA最佳实践时，同样要重视sOA采用过程中的常见失误。

最常见的失误包括：

注意供应商专有服务产品。不要局限于实际上具有专有特征的sOA供应商产品;这可能会导致失去真正sOA的互操作性和灵活性好处。

寻求使用开放标准的稳定性。行业中的最新开放标准规范并不一定是最稳定的;因此，可能并不成熟，不适合采用。

仔细评估遗留资产现代化工作。选择特定遗留系统进行现代化工作时，请从企业的全局出发进行考虑。sOA过渡中的竖井(silo)方法可能导致出现冗余。

避免“瀑布”式开发和缺少服务版本控制的情况。sOA过渡本质上应该具有迭代的特征。服务生命周期管理应该具有维护服务的多个版本的功能。

了解遗留系统的技术限制。在进行遗留资产现代化工作前，请充分考虑遗留系统的所有技术限制。

不要将sOA等同于web服务。了解sOA(一种体系结构样式)和web服务(一组sOA实现标准)间的差异。

避免采用竖井方法处理服务创建和所有关系。理解传统应用程序开发和基于sOA的开发之间的范式转换。

避免使用细粒度服务。与细粒度应用程序编程接口(applicationprograminterfaces，api)相比，服务是更高级的抽象。服务应该为粗粒度的，且与业务一致。

避免点到点调用。使sOA生态系统具有可管理性，且组件间采用松散耦合方式。加入中介层，以处理服务发现和调用，并协调不同sOA实现间的基础技术差异。

避免不遵循标准的情况。采用稳定的、经过验证的行业特定标准。此方法将为您的sOA带来互操作性的好处。

使用冗余数据存储。将重点放在数据整合策略上。通过创建虚拟数据服务来提供数据冗余性。

避免使用“大爆炸”方法。对于复杂sOA过渡，请完全避免使用“大爆炸”方法。请充分认识到，最好的平稳sOA过渡是通过采用迭代方法实现的，并尊重这一事实。

分配服务所有关系。不要让服务孤立。为其提供一个环境，让某个业务部门作为其所有者。此所有关系使得有人负责维护非功能性服务质量。

进行sOA治理。授权治理组织管理整个服务生命周期。

[1][5][6][7][8]下一页