SSLC的运行时阶段

    更深入地理解了SOA中分层服务的重要性之后，现在让我们来集中探讨SSLC的运行时阶段。如果管理得当，这些阶段可能会提供一种关键因素，实现由SOA计划驱策的企业灵活性和敏捷性。以下部分就这些方面进行详细讨论。

    发布和供应
    SSLC的发布和供应阶段集中关注：为发布服务需要做些什么，并建立服务使用边界。特别地，这个阶段应建立SOA管理的控制点，并通过定义诸如服务接口和契约等方面促进服务重用。
    考虑发布和供应服务时，充分理解正在处理服务的哪些“片段”是非常重要的。在这个阶段，服务实现被视为设计时的静态工件，而不是供应团队的责任。供给团队应集中关注以下方面：

    服务接口
    服务接口为客户提供了一种基于标准的机制，使客户能够根据它所提供的契约访问此实现所提供的功能性。服务接口将发布服务以便使用。

    服务契约
    此契约应包含功能元数据（表示如何与服务交互）和非功能元数据（表示哪些条件和限制适用于希望使用该服务的用户）。通过确保该服务实现中未出现某些逻辑，比如使用的条件和限制，服务也就更可能通过多种方式复合，服务工程团队或企业尚未考虑到这些方式中的大多数。服务契约在运行时可作更改，而无需在实现中重新编译代码，认识到这一点很重要，诀窍就在于有效地利用这种灵活性。

    元数据和策略
    我的经验显示出，要支持一种切实启用了服务重用和复合的服务，就要定义元数据和策略。建立真正灵活的SOA环境时，元数据的管理就是求窍门所在。通过定义一系列策略，即可轻松在实现外部管理单个服务或一类服务的运行时控制。这些策略不仅定义了哪些规则适用于哪些客户，而且还在谁可在何时供应哪些内容的方面定义了服务本身。元数据驱动策略的额外优点是，它们可在动态条件下强制实施，比如用户会话上下文和消息有效载荷。
    通过集中关注SSLC的运行时需求，控制和管理开始在成功管理SOA计划中发挥越来越重要的作用。结果，应将服务发布为某种形式的注册库，使其能够支持一个服务生命周期的配置和变更管理方面。此注册库也可与一个企业存储库集成，而该存储库又可能存储了另外的一些相关信息。需要特别注意的是，控制点应该通过工具来建立，应该向现有客户通知一项服务的更改，如有需要，应建立潜在的管理策略为用户提供时间窗口，以便他们能迁移到一个新版本的服务。所有这些信息都可存放在存储库里面，并且可通过注册库向服务用户展示。

    集成和部署
    SSLC和SOA以提高灵活性和敏捷性为成功的中心原则。服务重用是达成这些目标的一种方法。如SSLC的构建和复合阶段所提到那样，服务可作为部分新服务的实现使用。这听起来似乎是显而易见的，但做出以下声明很重要：确保设计时，复合服务不会影响SSLC的集成和部署阶段的灵活性。依靠对动态装配服务的服务的服务实现来支持业务需求可能导致以下问题：在后续阶段引入更改时存在依赖项和版本不一致。因而，建议您利用动态工具，比如Business Process Modeling（BPM），来促进服务联接的往返，而不要将其嵌入服务实现。另一种方法是在服务实现中利用代理服务，而不使用真实的业务服务终端。通过利用Enterprise Service Bus公开代理服务，物理服务就可能独立于消费服务而更改。（当然，如果服务接口做出了逆向更改，用户将通过一个已建立的管理流程得到通知。）
    遗憾的是，运行时服务的动态装配不会自然而然地实现。无缝集成和部署的能力需要一个去耦的服务环境，该环境以如下需求为目标：降低服务之间或智能终端之间的点对点关系——这表示一种服务实现包含了编码逻辑，它以一种尚未明确规划（编码）的方式制约了服务的重用。另外，服务工程团队必须认识到，服务必然会随时间而更改，旧版本退役，必然会有新版本发布。在集成和部署阶段，应将注意力集中在对服务的多个版本的支持，这些版本可能需要在一段特定的时期内共存。这样的需求与先前提到的管理控制重叠，以确定适当的活动来制约服务，避免使组织的注意力蔓延到一种原始的、不受控制的生产者混乱状态，或者，如我的一位同事意味深长地指出：“在享用美味的IT糖果时，也必须咽下无味的IT蔬菜。”
    为了在SOA计划中支持这种动态性，您需要了解基于配置的路由机制（而不是硬编码终端），它有能力询问一个服务请求的有效载荷或上下文，并以一种基于配置的方法恰当地发送它。更进一步，该环境需要支持无缝的变更控制，而这样的控制提供了对变更信息的更精确审计（请记住，通过避免依从性等方面的成本，您会获得了SOA的大量财政收益！）；提供了将配置聚集到可管理组中的能力；提供了实时更改和同时会话以支持透明更改控制；当然，还提供了出现问题时进行回滚的能力。
    最后，SSLC的集成和部署阶段应支持基于角色操作的视图的概念。这些视图应允许复合服务的委托配置，而不仅仅将其可见性和变更管理功能限制在发布和供应阶段定义的服务契约之内。如果将注意力完全集中在单个服务和在这种层次上管理变更的能力，组织可能无法实现复合应用程序的全部收益，并且将处于以下危险之中：后退到传统应用程序开发的某些实践，从而导致产生一些难以监控的系统，并造成与中断-修复式的回归测试相关的关注。

    安全和管理
    组织中的计划只有在得到恰当的管理，能够响应业务需求和要求时，才能取得成功。在SOA的功能中，这必然会实现更好地理解在其中使用服务的上下文，从而为正确的客户提供更高的服务质量。通常，我会将标识专门化的经济模型视为经济中提高生产概率曲线的一种方式。这里没有必要过于深入地探究经济理论，使一种共享服务基础架构能够通过前摄性、响应性的途径理解使用需求，这种能力可提供更高水平的客户服务或适用性。在经济术语中，这可能与理解服务的聚合需求相关。
    SSLC的安全和管理阶段应允许组织通过策略，而不是服务实现，来管理安全约束。就可调用该服务的协议而言，服务策略可将这些方面表示为传输层安全性，还可利用WS-Security标准来确保互操作性。当然，低级数据安全性可通过抽象数据服务或某种形式的分布式授权引擎来管理。特别地，对SSLC来说，这种安全性是通过对策略和相关契约的管理（而非服务实现）来提供的。
    在SSLC的任何阶段，拥有流程的实时可见性都很重要。SSLC中的安全和管理阶段集中根据当前实际使用情况管理一些服务，这些服务将满足业务需求。这可能包括对性能和错误事件的SLA管理。管理此信息的能力是遵循企业或组织内已建立的管理控制点的一个重要方面。例如，考虑从假想组织购买的每一本书，您需要确保该订单对某个时间帧，并且，一些成人性质的书只应售已经过某种形式的年龄验证的人。在这种情况下，可能要实现一种服务策略，来确认已通过年龄验证，这也可通过当前客户规范的内省实现。（必须注意：在一种高利用环境中，单个服务实现可能也应该提供多个服务策略和契约，以确定其用途。）继续考虑购买一本成人书籍的例子，实际上两个策略在此有效：第一，如果该书是成人性质，需进行年龄验证；第二，一条要求在特定时间帧内发送订单的SLA。对这些SLA的任何违背都可能被报告为某种形式的异常或违规。一个成熟的SOA组织可能具有明确定义的管理流程，明确地标识控制点和异常例程，所有这些控制点和异常例程都会记录在企业存储库中，比如AquaLogic Enterprise Repository。
    建立好SLA和业务策略后，组织可利用企业仪表板式的功能，为那些要求企业运作状态可见性的用户提供即时和集中反馈。通过这种可见性，安全和管理阶段应提供运行时灵活性，以增强为客户交付的服务质量（如果当时情形要求这样的话）。一个这样的例子就是，如果一个终端不可用，或将请求发送到一个低成本通道，比如IVR（Integrated Voice Recognition），而不是高成本的CSR（Customer Sales Representatives）（大多数标准请求发到此处），在这种情况下系统“dial-down”服务的能力。

    评估
    正如政府的财政和货币政策那样，在行动付诸实践时，规划和准备随时可能发生更改。这个SSLC的最终阶段涉及一些详细的分析，分析服务是如何根据使用情况在运行时被使用的。做出这类分析和评估的目的在于使组织更好地根据实际生产影响来管理服务使用行为。
    本系列第1部分中介绍了作为服务建模方法的一部分建立的服务分类指导方针，评估阶段主要是以此方针为依据，获得生产服务并评估其使用情况。经验表明，最初为实现某种特定功能或使用级别而开发的服务，往往在实际上得到了比原始预期更充分的使用。这样的运行时更改，是组织中所期望的SOA的有机发展，但必须对其加以有效管理，以避免它对SLA和SOA的有效性产生不良影响。在评估流程中，服务工程组应确定：服务是否按预期得到利用，是否需要重新分类以维持或改善服务的期望水平。这种重新分类更改了管理一项服务从而使其能向前推进的方式，并需要在支持或投资结构上做出更改。如果该服务是水平服务，是一个最初为业务线使用而设计，而现已开始在整个企业范围内使用的服务，那么这一点尤其正确。这样的服务可重新分类为企业服务，并相应地加以管理。
    评估阶段的另一个重要方面是，利用服务基础架构，收集度量标准来论证ROI和SOA计划的成功。业务和IT收益都可通过SOA度量标准的收集得以确定。确定ROI和SOA的成本收益是一个广泛的话题，超出了本文的讨论范围（在另外一篇我打算写的文章中将会介绍）。为简明起见，SSLC相关的一条度量标准是服务的重用水平。特别地，评估SOA程序未来成功情况时，度量服务的重用频率与创建频率对比情况的度量标准非常重要。要使度量标准真正发挥效力，必须从第一天起开始捕捉相关数据，并使之能与过去的度量信息进行比较，如先前IT计划中的上市时间、重用以及中断-修复循环的减少。
    最后，SSLC的评估阶段应该用来促使下一轮候选服务与需求目录协同。使用度量标准能够直接表明需求目录中标识的依赖项是否精确地表示了实际情况。另外，服务使用和复合指出了另外的一些关系，这些关系保证了开发特定、可管理、可度量的服务。通过评估这些关系，这些服务可能会显然比单纯地通过SSLC的设计时阶段来实现容易得多。