SOA面临的新挑战

    许多报告和文章都指出了SOA给组织带来的益处。然而，任何新技术都会同时带来新挑战。特别地，SOA SSLC和相关管理流程必须为应对这些挑战做好准备。下一节介绍了一系列挑战，一些是好的，另一些是不好的，但所有这些挑战对于使服务工程团队获得更好的理解来说都很重要。

    变更
    前一节讲述了SSLC的运行时阶段，以及它们与组织SOA计划的关联方式。有一个常规因素与SSLC一样重要，需要引起特别注意：变更——业务演化中无法避免也必不可少的组成部分。准确理解SSLC是一种很好的方式，可为变更做好准备，还可为实现SOA计划提供一致的方法论。管理SOA和SSLC中的变更带来了全新的变更管理挑战。特别地，将服务引入组织带来了许多新抽象，需要仔细加以考虑。像服务契约和策略等概念，要求用另一种方式来思考功能是如何开发的。这将需要付出时间和实践来把这一点做好，直到共享服务团队可在整个组织范围内促进某种形式的一致性采用。
    SOA还引入了这样一种可能性，在某个特定的时间，组织在生产中可能拥有多个版本的服务实现。这种想法不适于很多组织，也带来了管理和支持挑战：应该在多长时间内为用户的应用程序的先前版本提供支持、更改版本却不造成有害的逆向效应的能力，以及通知用户即将进行更改的能力。我遇到的很多组织都只是通过管理“强制”用户迁移到最新的服务版本，从而解决这些问题。尽管这确实是一个解决方案，但是一个更成熟的组织可以为用户提供一个机会窗口，使其能够在需要时才转到最新的版本，通过一个服务注册库提供对以前版本的支持，并利用服务契约的灵活性提供无缝的变更控制、请求转换等等。您需要记住，SOA是用来提高组织敏捷性的。要求应用程序团队升级到服务的各发布点可能会被认为对此类敏捷性有害。

    打包应用程序
    SOA计划在组织中取得成功的另一项新挑战可能来自令人出乎意料的地方；就是现有的打包应用程序。目前，大多数供应商为其产品中默认启用的功能提供web服务接口。取决于组织中这些打包应用程序的大小，它们可能引入数以百计的服务，这些服务可能并不符合您所建立的服务指导方针。未被结构化的服务的涌入可能会对SOA计划的成功造成严重破坏。这些服务可能不符合SLA需求，可能需要通过与企业组相对的业务线进行管理，并且可能导致依从性方面的问题。如果所公开的服务发布自核心企业系统，比如CRM、Data Warehouses和ERP，那么这一点尤其正确。强烈建议组织建立管理模型的一个方面，来明确地处理应公开并相应地管理哪些服务。此类方法之一可能是：通过SSLC的发布和供应阶段提供额外的服务策略或契约，来控制打包应用程序。与安全和管理阶段的一些准备工作相结合，此方法可能减轻您组织中难以管理的服务的增殖。

    服务契约
    将服务契约视为实现服务的一部分时，大多数时候，除契约帮助确定服务使用的事实以外，您实际上并未对其给予充分的考虑。事实确实如此，而人们往往未能意识到服务契约是一份正式的、有约束力的协议，可能会制约未来的灵活性。由定义可知，一份契约是两方或多方采用一种特定行为方式的约束性协议。不论您喜欢与否，通过建立服务控制，生产者和消费者都将受到其特定规则的管理。
    回到我们的需求目录，目录中确定出我们希望开发服务，按一种输入普通订单规范来接受。这种规范模式构成了您所公开的、有约束力的契约的一部分。所有用户都必须为服务提供这种规范，将其作为一个输入参数。必须谨慎，确保模式未允许过高的灵活性，如果灵活性过高，就会导致调用一项服务的方法的变换。特别灵活的契约将造成这样的后果：在尝试调试或维护服务时，服务将变得脆弱，并越来越难以处理。
    在积极的方面，服务契约为确保您的服务能得到迅速和有效利用提供了一种很好的方法。通过设计不涉及业务逻辑和运行时决策的服务实现，服务更可能被用来作为复合服务的部分。通过认识到服务可拥有多个契约，且这些契约决定了如何在运行时使用这些服务，这类收益可得到进一步实现。此概念与面向对象（OO）程序设计中的多态性（polymorphism） 相似。服务设计中的非常好的实践允许需求在契约级别独立演进，从而保持服务实现的简单和整洁。策略和契约自身可能拥有多对多关系，并且多个服务可能实现同一契约，弄清楚这一点后，服务拥有多个契约的理念可得到进一步的扩展。此时就可利用服务存储库按需调整的能力，从而管理系统的运行时操作。真正的松耦合需要服务基础架构中存在多对多关系。在我看来，这是一种强大的概念，只是在SOA计划中仍处于其幼年时期。
    遗憾的是，通过利用运行时契约和策略所获得的全部收益包含一些技术限制。特别地，WSDL目前无法对所有组织需要的功能和非功能性需求提供全面支持。此外，WS-Policy规范仍然所欠缺：它只为交换策略信息提供了一个可互操作的容器，但并未提供支持来指定策略行为。我相信，随着组织中SOA采用和技术的继续成熟，这些限制不久之后就会得到改变。

    元数据
    根据我的经验，从长远角度来看，组织SOA计划的成功取决于它如何管理和利用元数据。尽管许多组织将通过上市时间的缩短、服务重用等方面受益于SOA计划，但我相信，将可证实组织中元数据的使用就是短期成功和长期改造间的差异。元数据描述了服务以及那些服务的用户如何与之交互，从而提供了灵活性，以便集中关注通过复合连续满足业务需求，从而创建共享服务。
    对元数据的理解可帮助组织避免将管理和流程硬编码到工具与实现之中，并允许了资源的动态发现。组织必须能够利用SOA基础架构来获取很多信息，而不仅仅是服务细节。必须建立一个元数据存储库来支持所有SOA工件，并允许描述环境中的流程和操作上下文。有效管理元数据的能力将与在整个管理流程中建立恰当、可度量的控制点直接相关。

结束语

    为了在组织中利用SOA计划的全部益处，采纳以下观念非常关键：运行时中的服务是一项企业资产，可被编目和跟踪。这不仅有助于构建您的共享服务目录和缩短上市时间，而且还可连续地作为SOA支出的合理证据。如果您无法通过SOA平台跟踪和度量收益以及成本节约情况，那么将来的成本收益决策就可能仅限于主观信息。
     通过共享服务的精确运行时管理，组织将改善其SOA计划的效力。与传统软件开发不同，SOA主要关注构建可重用的原子服务上，这些服务通过契约和策略促进灵活性。通过成功的设计和一致的建模方法论，面向服务的运行时方面应更加关注组织中已有的服务基础架构。
     除了可靠的设计实践和运行时实践外，组织还应认识到SOA也带来了新的挑战，必须通过一致的管理模型和包容的思想加以有效管理。通过包容环境的一些确定因素（如变更），您的SOA计划应提供有机的增长——这些增长只与组织保持竞争优势并被视为行业领袖的期望相匹配。此后，所有的变更都与创新相关，而创新则是具有与众不同的想法。若管理得当，SOA可成为此类变更的关键组件。
    最后，作为一种架构范例，SOA的目标在于促进重用，允许企业更快地将新产品推向市场。作为一种方法论，SOA要求对组织如何快速地适应变更有深入理解。SSLC的运行时方面与构建组织的灵活性直接相关。本文尝试了提出以下见解：企业要如何通过仔细分析当前需求和面向服务的设计实践来达成此目标。