解析如何避免在SOA采用过程中的常见失误(1)

引言

IT 体系结构已非常成熟，它是一种成功处理典型 IT 问题的方法。体系结构中一个受到很大重视的相对较新的分支是面向服务的体系结构 (SOA)。SOA 经常被吹捧为企业用于解决应用程序灵活性和高维护成本问题的万能药，常常被视为帮助企业提高其 IT 投资回报(Return On Investment，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 的开发之间的范式转换。
• 避免使用细粒度服务。与细粒度应用程序编程接口(Application Program Interfaces，API)相比，服务是更高级的抽象。服务应该为粗粒度的，且与业务一致。
• 避免点到点调用。使 SOA 生态系统具有可管理性，且组件间采用松散耦合方式。加入中介层，以处理服务发现和调用，并协调不同 SOA 实现间的基础技术差异。
• 避免不遵循标准的情况。采用稳定的、经过验证的行业特定标准。此方法将为您的 SOA 带来互操作性的好处。
• 使用冗余数据存储。将重点放在数据整合策略上。通过创建虚拟数据服务来提供数据冗余性。
• 避免使用“大爆炸”方法。对于复杂 SOA 过渡，请完全避免使用“大爆炸”方法。请充分认识到，最好的平稳 SOA 过渡是通过采用迭代方法实现的，并尊重这一事实。
• 分配服务所有关系。不要让服务孤立。为其提供一个环境，让某个业务部门作为其所有者。此所有关系使得有人负责维护非功能性服务质量。
• 进行 SOA 治理。授权治理组织管理整个服务生命周期。

供应商专有服务产品

SOA 的基本原则之一是，它能跨各种异类功能和基础设施环境提供服务互操作性。尽管 SOA 产品供应商正在进行大量的开发工作，以提供功能和基础设施服务组件，但这些产品经常会采用其提供的服务的专有形式。购买这些产品并将这些产品作为其 SOA 的基础的企业可能很快就发现自己被限制在了供应商服务组件的专有特性内。

SOA 是基于业务需求定义的，具有突出的互操作性和灵活的服务即插即用功能。绝不应该使用其服务并不基于稳定的开放标准的专有供应商产品来损害这种灵活性。请注意，除非供应商的 SOA 产品符合制定得非常完善的开放标准，以此作为其提供的服务实现的基础，否则，在使用这些产品时就应该格外小心。为了实现基于 SOA 的过渡的长期成功，必须为其实现支持、采用和实施开放标准。

开放标准的稳定性

那么，为了真正获得服务间互操作性的好处，您的 SOA 实现必须遵循被广泛接受的现有开放标准(例如 WS-* 规范)，而不管是对服务从头开发、重用还是从供应商购买。

任何基于 SOA 的开发工作都必须仔细地分析已确定要遵循和采用的开放标准集。如果确定的开放标准仅处于设计或规范级别，而更为成熟稳定的版本尚未发布和广泛采用，则 SOA 可能会遭遇传统的维护困境。随着每个标准规范的新版本的发布，业务应用程序还将需要进行恰当的更改，以与标准保持一致。如果标准没有得到广泛接受，或仅由一个供应商提出且尚未得到行业内大幅度的认可，同样的问题可能会变得更为关键。

不过，市场上被看好的最新开放标准并不一定是可采用的最佳标准。它仍然要经历自己逐渐成熟并被主流供应商采用的过程。至少，它必须具有定义良好的路线图，以过渡到稳定成熟的版本。

遗留资产现代化

遗留资产现代化是企业采用 SOA 时的一个重要方面。任何过去数十年使用 IT 系统的企业都一定具有帮助其开展业务的遗留应用程序。遗留系统可以存在于基础设施级别，也可以存在于操作级别;例如，运行企业人力资源(Human Resource，HR)系统的 IBM CICS® 大型机。遗留系统还可能以特定基础设施组件和操作环境上运行的过时软件或编写质量较差的软件应用程序的形式存在。

当企业采取行动对其 IT 基础设施进行现代化工作并使其与业务要求保持一致时，IT 团队需在为过渡到基于 SOA 的投资组合构建业务用例前对现有的遗留系统进行更为深入的分析。此类分析经常采用竖井方式执行，而这意味着将选取特定的独立业务域进行临时性的遗留资产现代化工作。

如果在没有全面考虑整个企业的情况下或在没有考虑依赖关系和相关业务域或能力的情况下进行遗留资产现代化工作，则可能创建重复的服务和应用程序编程接口(Application Program Interface，API)。这种重复的情况源自缺乏对现有服务投资组合的详细分析。必须使用 80-20 原则对现有服务进行仔细分析：如果可满足当前现代化要求至少 80% 的所需功能的现有服务仅需要 20% 的工作就能完全从头构建，则最好通过以现有服务为基础实现新要求。

如果企业 IT 组织的操作方法是通过采用竖井 SOA 遗留资产现代化工作进行的，则能从 SOA 得到的潜在好处可能就会大打折扣。即，如果在没有评估整个系统的情况下进行自动化工作，很可能无法得到真正的 SOA。在这些业务模型类型中，SOA 并不是适合采用的好方法。尽管进行了相关的工作，但 SOA 的业务价值将很难得到业务涉众的认可。

“瀑布”式开发和缺少服务版本控制

采用瀑布式方法可能是在进行 SOA 工作的过程中的常见问题之一。瀑布方法应用于传统应用程序开发时，就意味着存在严格的开发序列(如解决方案概要、宏观设计、微观设计)，要依次进行开发、编码和单元测试(Develop, Code, and Unit Test，DCUT)。对 SOA 采用这种方法可能导致创建仅能部署一次的服务，而无法在以后对其进行重用。

SOA 不能一蹴而就。企业应该以迭代的方式过渡到 SOA，要进行阶段划分，并创建计划良好的转换路线图。路线图确定最活跃的业务领域，SOA 采用工作可以在其中对业务和 IT 的需求进行结合。此过渡可以在业务域级别上进行;经过标识并随后采用类似方式开发的服务可从迭代开发获益。

根据迭代方法的要求，服务必须具有定义良好的生命周期，如图 1 中所示。

图 1. SOA 中服务的生命周期

此生命周期的一部分涉及到对您开发的每个服务进行版本控制。有版本控制的服务可确保该服务的升级并不需要重新测试应用程序使用的所有其他服务。服务版本控制能为服务的不同使用者提供服务水平协议(Service-Level Agreement，SLA)的不同级别支持，另外还具有其他很多好处。服务版本控制还允许对服务进行迭代开发，并能基于业务功能需求进行持续的改进和增强。

对于大型的面向服务的企业，服务版本控制应该成为服务管理生命周期不可或缺的一部分。因此，企业的 IT 环境的操作功能要具有可靠的 SOA 管理基础设施这一点非常重要。如果不能满足此要求，则会对面向服务的企业的增长造成严重的限制。

服务版本控制也属于 SOA 治理的讨论范畴之内，我们稍后将对 SOA 治理进行讨论。不过，对于刚刚开始进行 SOA 开发的人员而言，常常会忽略对版本控制加以考虑，因此我们将这个问题在此单独列出。