转自http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0912_boughannam/0912_boughannam.html

一个 “智能” 企业必须拥有运营商业智能（Operational Business Intelligence，OBI）。在本文中，我们将描述一个用于实现智能企业的可重用 OBI 框架，解释如何捕获并定义时间轴/里程碑模式，以便自动化运营业务管理和灵活的 OBI 应用程序的构建。时间轴/里程碑模式对企业内的许多业务流程的运营都十分关键，这些业务流程包括订单跟踪、产品发布、实现、服务提供等。本文定义了一个时间轴模式的模型及其行为，并描述了几种用于将该模型及其逻辑封装为可重用的智能组件的方法。这里描述的概念将展示通用（可重用）运行时引擎的构建块，用于处理基于时间轴的运营管理解决方案。

智能企业应该拥有运营商业智能

业务驱动因素要求构建适应性强的敏捷企业 —— 由于可以理解当前发生的事情（拥有环境意识），这种企业能够更快速、更智能地运行，能够迅速地感知和响应 机遇和威胁，能够在重要项目的生命周期中跟踪和追踪 它们。环境意识、感知和响应、跟踪和追踪是运营商业智能的几个例子。运营商业智能使企业能够更快速、更智能地运行，因为它有助于缩小以下两件事情之间的时间差距：知道或预测到某件事；某个人、设备或组织单位对这件事采取行动。为实现运营商业智能，企业希望能够通过从可重用的组件轻松组装应用程序来构建灵活的 OBI 应用程序，并针对某个特定的问题领域轻松配置 OBI 应用程序。本文将展示一个允许企业实现这个目标的系统和方法。

Business Activity Monitoring (BAM)、Business Process Management (BPM) 和 Business Event Processing (BEP) 等现有技术联合起来向企业提供 OBI 解决方案。但是，在这些技术的几乎所有部署中，都需要针对具体企业进行大量的定制。许多解决方案试图减少这种定制，并且可能提供了一些模板，用于解决特定业务领域的常见问题，比如银行业、制造业和证券经纪业。由于初始部署需要高度的系统集成，因此许多企业都聘请擅长 BAM、BPM 和 BEP 的专家来实现解决方案，这使得这些解决方案的成本非常高昂。

有一种方法可以减少构建 OBI 应用程序所需的大量定制，即发现许多 OBI 场景都通用的底层模式，并将这些模式捕获为可重用的、可轻松定制的组件。本文建议的架构的一个重要创新就是发现这样一个事实：时间轴/里程碑模式是运营管理的一个关键底层模式，各种业务活动的运营管理可以作为一个时间轴建模和管理，在这个时间轴中，只有时间轴上的各个里程碑得到满足，该时间轴的最终目标和最后期限才能得到满足。这个时间轴模型的行为包括每个里程碑需要的动作（包括正常运营的动作和里程碑未按期完成而造成的异常运营的动作）。

本文将时间轴/里程碑模式及其行为定义为一个可重用的软件组件。本文还将展示一个用于构建灵活的 OBI 应用程序的方法和系统，它们只需对一些可重用的组件（比如本文描述的时间轴组件对象）进行少量的定制。

有一点很重要：本文介绍的时间轴模式并不局限于为企业构建 OBI 应用程序，它还可以用于其它领域和应用程序。本文定义的时间轴模式组件及其行为可以用于许多其他应用程序，包括跟踪个人时间轴里程碑和生成的自动化时间轴异常处理动作。

回页首

时间轴/里程碑模式 —— 一个宝贵的运营管理工具

如果您不遵循计划，即使是最好的计划也毫无用处。制定计划后，您需要一种方法来针对该计划监控进展，即检查实际进度的日期是否与计划一致。里程碑是用于监控进展的工件。一个里程碑表示一个清晰具体的成就，您可以检查该里程碑是否在给定的日期和时间实现。通常，多个里程碑被附加到一个时间轴上的具体日期，从而形成一个项目计划。

用于管理运营活动时，里程碑通常与特定事件的发生和动作规则相关联。例如，运营团队通过检查某些特定事件是否发生来验证一个里程碑是否完成。如果遇到一个里程碑在最后期限到达时仍未完成的异常情况，将生成各种警报并发送到与该里程碑的完成相关的团队成员。与此里程碑关联的其他动作可能在正常运营期间发生，而并不只是出现在发生异常时。例如，一个发送提醒通知的动作可能被计划用来通知其他成员：某个里程碑的最后期限正在迫近，该里程碑必须在最后期限之前完成。以下示例展示了一个使用时间轴和里程碑的运营管理场景。

时间轴/里程碑模式是一个在多个业务活动管理场景（例如订单跟踪、实现、服务提供等）中使用的关键底层运营管理模式。各种业务流程活动的运营管理可以作为一个带有多个里程碑、关联通知和其他动作规则的时间轴建模并管理。

现有的运营管理应用程序没有明确表示和重用时间轴模式。相反，这种运营管理所需的逻辑通常被硬编码到其他应用程序逻辑中，因而难以实现重用。本文通过明确定义一个时间轴模式的新颖模型来捕获时间轴运营模式，这个模型不仅包含时间轴的结构，还包含它的行为，这些行为包含处理时间轴活动所固有的逻辑和规则。本文还将定义一些方法，用于将这个时间轴模型及其逻辑封装为可重用的智能组件。这些组件之所以智能，是因为它们能意识到自己的目标，预先定制所需的信息，在目标没有实现时采取适当的动作，并持续检查目标是否实现。

新产品公告示例

我们来检查一个真实的示例 —— New Product Announcement (NPA) 流程，借此阐释本文的核心理念。（参见 [1] 和 [2] 了解 NPA 流程的更多细节。）研发和销售产品的公司通常会公告某个新产品将在未来的某个日期允许订购，我们将该日期称为 Day of Announcement (DOA)。在 DOA，在线目录中将提供产品和价格信息，客户和业务伙伴可以从在线目录采购该产品。支持这些公告的流程涉及企业中的多个组织和应用程序。公告流程通常在产品被发布为 “普遍可用” 的几个星期之前启动。各个品牌的产品开发团队很早就定义了产品信息的初稿，这个初稿将随着时间不断修改完善。当 DOA 接近时，公告筹备（运营）团队跨多个相关组织管理这个流程，确保这个产品的信息正确、完整，产品和价格已经设置，并在相关的实现和制造系统中推广并设置。DOA 之前的几天很关键，活动每小时都受到监控，以确保事件和活动之间出现交接（hand-off）。

图 1 展示了这个时间轴和各种里程碑，必须完成这些里程碑才能支持产品公告。

图 1. 产品公告时间轴

在这个示例中，这个产品结构必须至少在 DOA 的前 14 天确定（在研发产品结构的企业应用程序中设置状态标记 “FINAL”）。在另一个处理产品定价的应用程序中，该产品必须至少在 DOA 的前 8 天定价，这个价格必须至少在 DOA 的前 4 天发布（到实现系统）。图 1 中的其他里程碑与实现系统里程碑相关，它们必须在 DOA 之前的各自最后期限之前就绪。

通常，通过检查某些事件来验证某个里程碑是否完成。如果某个里程碑在最后期限到来之时没有完成，各种警报将生成并发送。对于每个里程碑，有一组可以被配置的关联动作（图 1 中的 A 圆圈）。例如，如图 1 所示，一个提醒警报在里程碑日期前 7 天生成，另外 3 个延迟警报分别在里程碑最后期限之后的第 1、3、和 7 天生成。

回页首

用于为智能企业实现一个灵活的、可重用的 OBI 框架的架构

本文描述的概念用于帮助自动化运营业务管理和灵活的 OBI 应用程序的构建。借助本文介绍的架构概念，OBI 应用程序可以从这里定义的可重用组件轻松组装，并可以针对一个特定的问题领域轻松配置。

本文的核心理念就是捕获基于时间轴的运营管理问题中的重复部分并使其可重用，即：

1. 捕获时间轴的结构（模型）及其里程碑、事件和通知。
2. 捕获时间轴活动处理的固有逻辑和规则。
3. 将模型和逻辑封装为可重用的组件。

时间轴组件在构建时和运行时被配置为活动实体，在这些活动实体中，每个里程碑都知道它需要订阅什么外部事件，预先执行订阅，并捕获和处理进入的事件。另外，每个里程碑知道需要发送什么通知，应该在最后期限之前还是之后发送通知。

时间轴/里程碑模型

本文将定义一个时间轴/里程碑模型。图 2 展示了这个模型的示例。

图 2. 时间轴/里程碑模型示例

在这个模型中，一个时间轴定义为一个列表，或者一个里程碑集合。里程碑是具有以下属性的对象：

• Name：里程碑的名称，例如 Price_Released。
• Deadline：里程碑必须完成的最后日期。
• State：里程碑的状态，完成状态为 “Done”。
• Description：描述这个里程碑表示的活动的文本。
• Output Events：里程碑发布的事件（通知）。

  Timer-based events (timed notifications)：由 Milestone 设置的定时器事件驱动并包含作为主体的 Notification 消息。

  • Name：基于定时器的事件或动作的名称。
  • Timestamp：这个动作必须发生的时间，可能与里程碑最后期限相关。
  • Notification：由这个里程碑动作发送的通知消息。

    通知类型、接收人、主题、主体 SQL、发送源

• Completion Expression：关于事件内容的 XPATH 表达式。如果这个表达式的值为 true，则表示该里程碑项目完成。
• Input Events：事件里程碑监听/订阅：
  • Subscribe expression，这个表达式允许里程碑订阅或接收它感兴趣的输入事件。例如，XPATH 表达式 /timeline/NPA/Event/Price 表明我们对所有 NPA Price 事件都感兴趣。当某个 Milestone 服务在运行时启动时，它将运行其启动代码（如 图 3 所示）。
  这个代码的第一步是订阅外部事件。在这个步骤中，这个里程碑将创建一条订阅消息（例如，它能够使用 WS-Notification 标准来创建订阅消息），将消息发送到一个 Publish 和 Subscribe 代理（例如，WS-Notification 标准中的 Notification Broker）。我们将在稍后解释这个架构的组件交互时详细介绍这方面的内容。
• Metrics/KPI：跟踪这个里程碑的指标列表。

作为这个模型的一部分，我们将一个里程碑的行为定义为驱动该里程碑的逻辑，如图 3 中的流所示。当被封装为可重用的服务时，这个流表示里程碑的运行时逻辑。当我们稍后介绍里程碑和各种系统组件的运行时交互时，这个流（或行为）就更有意义了。

图 3. 里程碑逻辑流

实现时间轴/里程碑模式

图 4 展示了实现时间轴/里程碑模式的系统的上下文。这个系统拥有一个构建时组件和一个运行时组件。构建时组件帮助用户定制时间轴/里程碑模型以创建一个特定于用户的模型。用户将这个特定于用户的模型部署到运行时组件，运行时组件根据指定的规则跟踪并管理里程碑。

在构建时，业务用户配置此前描述的通用时间轴/里程碑模型以适应其特定的问题领域。例如，一个熟悉 New Product Announcement (NPA) 流程的业务用户可以指定为了理解和管理流程性能而需要跟踪的关键里程碑。如前所述，时间轴/里程碑模型还包含管理流程需要执行的动作和通知。构建时工具还允许业务用户定义和指定需要的事件，并将这些事件映射到里程碑。业务用户无需为从企业中的各种元素（应用程序、数据库、文件等）捕获和生成业务事件操心。IT 开发人员仍旧必须编写自定义代码（适配器）和配置来监控企业中的各种事件源，并转换这些事件的原始表示以生成业务用户定义的业务事件。业务用户还可以为此前介绍的里程碑模型中定义的每个里程碑定义关键性能指标（KPI）。

作为构建时活动的结果，一个特定于用户的时间轴/里程碑模型被定义并生成。例如，用户可以指定和生成时间轴/里程碑模型，以便管理操作并支持 NPA 流程。

图 4. 时间轴/里程碑系统的构建时和运行时组件

这个工具允许业务用户将生成的特定于用户的时间轴/里程碑模型部署到运行时环境中。这个特定于用户的应用程序（例如，NPA 应用程序）作为一个具有多个里程碑服务的时间轴服务（例如，NPA 时间轴）运行。每个单独的流程实例中的每个里程碑都通过时间轴和里程碑服务跟踪，生成适当的警报、通知和用户报告并发送到有关人员，并将里程碑的状态及其 KPI 提交到仪表板。

在下一小节中，我将介绍这些服务如何与运行时系统的其余部分交互。在运行时，由应用程序监控的数据被转换为业务事件（事件消息）并被时间轴/里程碑应用程序服务利用。有些数据（比如来自事务或其他消息传送系统的信息）可能已经使用了事件格式。其他数据（尤其是关系数据库或平面文件中的数据）必须被映射为事件。有许多工具和适配器可以用于实现这种事件映射功能。

综上所述，构建和运行一个时间轴/里程碑运营管理应用程序的步骤如下：

1. 业务用户定制时间轴/里程碑模型以创建一个特定于用户的模型，并定义该模型需要的业务事件。
2. IT 开发人员创建和部署监控企业中的各种事件源所需的 “适配器” 组件并生成所需的业务事件。
3. 业务用户将自定义模型部署到运行时环境中。

组件交互

这个架构定义的系统的组件交互在 图 4 中展示。在这个示例中，我们假定这样一个事件驱动架构：异步消息（或通知）通过消息或通知代理在系统的组件之间交换。OASIS Web Services Notification (WS-N) 规范（参见 [3][4][5]）通常在事件驱动架构中用作通知标准。通知是将场景（situation）的有关信息传递给其他服务的单向消息。场景是被一方注意到且与其他各方有关的事件。我们的系统遵循一个通知模式，它是一个涉及使用者注册和事件后续传播的交互模式。

图 5. 时间轴/里程碑系统的运行时组件交互图表

在这个架构的一个具体实现中，本文描述的系统可能使用多个通知生成者和多个通知使用者。这个系统的组件描述如下：

• 发布者：创建通知消息的实体。发布者通常与外部信息和事件源存在接口，并将有关事件打包到一条通知消息中。发布者通常向消息添加一个主题头部，根据通知的主题模型或分类模式确定该消息的类别。发布者是通知的生成者，发布者服务负责将通知发送给适当的使用者。通知使用者是接收由通知生成者分发的通知的实体。
• 通知代理：不会创建通知消息，但代表一个或多个发布者管理通知流程。一个通知代理包含一个订阅管理器，用于管理 Query、Delete 或 Renew 订阅的请求。订阅是表示通知使用者和通知生成者之间的关系的实体。订阅记录这样一个事实：通知使用者对通知生成者能够提供的部分或所有通知感兴趣。订阅者是请求创建订阅的实体，它发送一条 Subscribe Request Message 到通知代理。Subscribe Request Message 识别通知使用者。订阅者可以同时充当使用者和订阅者（代表自己订阅），或者代表独立的使用者订阅（第三方订阅）。

在我们的系统中，时间轴和里程碑服务充当通知使用者，因为它们对接收某些通知感兴趣。它们还充当订阅者，因为它们会订阅感兴趣的通知。另外，它们还是通知生成者，因为它们生成通知消息。

系统中的其他服务大部分是通知使用者，并且包括：

• 定时器服务：定时器/调度器服务是订阅定时器类型通知的通知使用者。它发送一个警报或一个定时器，以便唤醒一个已指定的时间。另外，它在唤醒的同时发送关联的通知消息到系统的其他组件。
• 电子邮件服务：订阅具有一个电子邮件主题的通知，当该服务接收到一条通知消息时，它通过电子邮件发送该消息。
• 指标/KPI 服务：收集 KPI 指标的计数。
• 仪表板服务：管理向仪表板发送通知。
• 日志服务：能够订阅某种类型的通知，并记录它们以满足历史查询和调试需求。

启动和警报通知场景

以下步骤对应于 图 5 中的交互图表，描述一个启动场景和一个警报通知场景中的交互步骤。尽管有许多场景，但启动和警报场景对于解释系统在运行时的工作方式已经足够了。

1. 时间轴服务订阅其感兴趣的所有事件。它将末端时间轴里程碑中定义的订阅表达式用作订阅表达式中的订阅过滤器。
2. 在某个时间，发布者发布时间轴服务已经订阅的通知消息。发布者将这条消息发送到通知代理。
3. 通知代理将消息发送到时间轴服务。
4. 时间轴服务启动它管理的所有底层里程碑。
5. 每个里程碑服务都订阅该里程碑感兴趣的事件。
6. 里程碑发送通知消息以建立它的所有警报定时器和通知。通知消息的内容是定时器启动时将发送的实际电子邮件消息。它包含一个主题，表明它是一个电子邮件通知。
7. 通知代理将这些定时器通知消息发送到定时器服务。定时器服务将定时器设置为指定的时间戳。
8. 当定时器时间戳到达时，定时器服务将警报发送到代理。
9. 电子邮件服务订阅所有具有 “send email” 主题的通知。它接收这些通知并通过它的电子邮件服务器发送它们。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-664875/，如需转载，请注明出处，否则将追究法律责任。