時間軸/里程碑模式

轉自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/，如需轉載，請註明出處，否則將追究法律責任。