常用縮略詞
API：應用程序編程接口
COSMOS：社區驅動的開源系統管理
HTTP：超文本傳輸協議
REST：具象狀態傳輸
W3C：萬維網聯盟
XML：可擴展標記語言
XSD：XML 架構定義
XSLT：可擴展樣式表語言轉換
當面臨一個業務流程方面或者系統資源利用效率低的問題時，每個程序員、系統管理員、數據庫分析人員都知道應該怎麼做。他們各自使用自己的智慧錦囊，這些是他們從多年的經驗中根據已經解決的問題總結而來的。盡管這種解決問題的方法已經沿用了幾十年，但是企業架構師越來越迫切希望有一種更好的方法。他們想要采用一種健全的、可再生的、基於證據的方法來解決此類問題，甚至在第一時間預計和避免此類問題。
操作系統分析（尤其是系統優化）的准則已經湧現出來，這有助於解決這一問題。有責任的架構師越來越關注采用一些正式的方法來管理已成為企業命脈的系統。越來越多的傳統業務規則和工作流工具正在成為系統優化的正式准則，包括 IBM® ILOG® 在內，它的優化建模方法如 圖 1 所示。該優化模型列出了各種輸入（比如應滿足的需求；可用的資源；成本、收益和方法；操作約束和客戶偏好；業務目標）、一個或多個數學模型和優化引擎，以及一個帶有度量標准（比如最小化成本、最大化收益、特定資源分配和最佳的活動時間安排）的時間表或計劃。
圖 1. IBM ILOG 優化模型
查看原圖（大圖）
現在，對於實際的系統，通過各種面向服務的架構（SOA）傳輸 XML 格式的消息是極為常見的。此類系統通常采用 XML 形式表達業務規則、詞匯、分類和描述性系統。因此，優化措施的重要輸入通常來自 XML 數據集和消息統計的模式分析。為支持此類分析，懂 XML 的企業架構師可以找到廉價且靈活的方式來收集基本的信息，用於支持系統優化。本文將討論關於在操作系統分析中應用最有效的 XML 處理方法的約定和技術，並選擇了一組示例場景來說明。
使用率分析
任何系統優化最基本的輸入都是實際使用率模式。哪些操作使用得最多？有沒有什麼參數模式使用得尤為頻繁？這些可能會是優化資源或處理的備選項。在很多現代的、基於 Internet 的系統中，實際使用率由通過線路傳輸的半結構化消息表示。目前，具有此類用 XML 表示的消息已很常見，比如 SOAP Web 服務或者通過 HTTP 發布到 RESTful 端點的 XML 消息。如果您使用基於 SOAP 的 Web 服務，那麼您可能有機會使用適合於綁定級別的專門工具。所以本文中我會將焦點放在 RESTful 系統中通過 HTTP 傳輸 XML 的例子上，RESTful 系統是一種流行的系統，針對它的現成工具還不多。系統架構師需要明白如何在此類系統中執行分析，此外，這些技術在協議級別上也適合基於 SOAP 的系統。
資源預定服務
在本文的例子中，我們假設有一家虛構公司想要部署資源預定系統，員工可以發送請求來預定諸如會議室和多媒體設備之類的資源。圖 2 是一個高層次圖，演示了各種系統（包括浏覽器、移動電話和定制應用程序）如何與資源管理器服務交互。
圖 2. 資源管理器的系統概述
您可以使用網絡拓撲工具來分析各種入口點的使用率模式（例如，確定何時移動接口比普通 Web 接口用得更多）。您也可以通過使用 REST 層來進行更復雜的使用率模式分析。清單 1 中的例子展示了一個作為 HTTP POST 發布的預定請求消息。
清單 1. 示例預定請求消息
<?XML version="1.0" encoding="utf-8" ?>
<reservation XMLns="http://example.com/enterprise-reservations">
<session id="115384" user="jdoe"/>
<request timestamp="2010-03-02T15:39:50-07:00">
<resource id="room123" type="conferenceroom"/>
<purpose>Marketing meeting, and free doughnuts</purpose>
<period start="2010-03-10T10:00:00-07:00" end="2010-03-10T11:00:00-07:00"/>
</request>
</reservation>
使用 Schematron 進行分析
Schematron 對於此類分析是一個很好的工具。清單 2 就是一個 Schematron，用於生成請求時間戳和資源類型的報告。
清單 2. Schematron 生成請求時間戳和資源類型的報告
<?XML version="1.0" encoding="UTF-8"?>
<schema XMLns="http://www.ascc.Net/XML/schematron">
<title>Reservations manager usage analysis</title>
<ns uri="http://example.com/enterprise-reservations" prefix="er"/>
<pattern name="Basics requests report">
<rule context="er:reservation">
<report test="er:request/@timestamp">
Request timestamp: <value-of select="er:request/@timestamp"/>
</report>
<report test="er:resource/@type">
Requested resource type: <value-of select="er:resource/@type"/>
</report>
</rule>
</pattern>
<pattern name="Validation">
<rule context="er:reservation">
<assert test="er:session">
Request must have a session element
</assert>
</rule>
</pattern>
</schema>
我推薦您學習 Schematron，但是本文將僅解釋清單的主要結構。ns 元素是 Schematron 的名稱空間聲明機制。pattern 是一組應用於 XML 文檔的相關規則。rule 元素指定關於 XML 中特定構造的業務規則，在 context 屬性中假定使用 XSLT 模式形式。在規則中，report 元素用於記錄滿足給定條件（以 XPath 形式給出）的構造，assert 元素用於指定架構設計者期望有效的 XML 文檔要滿足的條件。根據大致經驗，Schematron assert 元素表達預期的文檔模式，而 report 元素則表達具體的模式。
如果您在預定管理器的 REST API 中實現了 清單 2 中的 Schematron，那麼您已經匯集了一個有關何時發出請求、請求何種資源的日志。您可以使用該日志來優化峰值時間，確定資源對於滿足請求是否足夠，等等。
分析場景
上一節學習了在系統分析中應用 XML 報告的基本思想，重點放在一個核心工具 Schematron 上，它已經是表達 XML 文檔模式規則最流行的方式。本節將展示構建此類基礎的各種方法，以提供更加全面的分析，為系統優化的各個方面做好准備。通過將各種簡單而富有表現力的機制聯系在一起，您可以收集常用的操作統計信息，同時獲得屬於自己的專門工具，從而在競爭中獲得優勢。
活動系統建模
在該場景中，架構師建立系統模型，以便系統團隊可以積極地監控系統的實際行為。圖 3 演示了活動系統的工作和數據流。
圖 3. 活躍系統建模場景
用於該場景的一個現有工具是 Service Modeling Language (SML)，這是由 IBM 和多家公司提議的一個標准，用於建模復雜的服務和系統，包括它們的結構、約束、策略和最佳實踐。SML 基於帶有嵌入式 Schematron 規則的 W3C XML schema (XSD)，如 圖 3 所示。架構師和開發人員可以依靠工具來將 SML 合並到系統開發和維護中，比如基於 Eclipse 的 COSMOS 項目。
利用率熱圖
優化的一個重要前提是必須深刻了解哪種服務模式和哪種資源使用最多，這類似於熱圖 的用戶體驗（現代統計工具可以生成類似熱圖）。圖 4 演示了熱圖的工作和數據流。
圖 4. 利用率熱圖場景
在本例中，每條消息都會通過報告模塊，該模塊匯集成一個報告，建立在 Schematron Validation Report Language (SVRL) 之上，SVRL 是一組有關從 Schematron 報告生成結構化輸出的約定。此輸出很容易轉換成統計分析工具（比如 IBM SPSS®）的直接輸入格式。
協議適應
一個最常見的維護要點是預期協議的變體。此類變體可能源於系統模型的差異或者客戶層的擅自變更。圖 5 演示了此案例的監控過程。
圖 5. 協議適應場景，具備異常通知功能
舉例來說，假設您使用 XSD 或 RELAX NG 中的封閉文法構造架構（並且可能用 Schematron 擴展），那麼您可能得到一個封閉的模型，它會在協議有偏差的情況下拋出異常。發生此類異常時。可以向管理員或開發人員發送通知，讓他們來審查和處理。一個類似的異常和通知方法適合於管理操作遵從性（比如說滿足規則）。
干涉結果
作為一個相當復雜的分析方法的例子，考慮一下當出現更多常規處理異常時會發生什麼情況。系統可能會通知一個代理進行特殊處理。也許會出現會議室使用沖突，代理打電話給請求方，以協商備選房間。補救措施可能相當於對初始請求進行修改，比如根據協商結果發出新的會議室請求。在本例中，有必要對初始請求和干涉結果進行分析，以便開發一種方法來自動干涉，提高代理的效率。圖 6 演示了這樣一個場景。
圖 6. 干涉結果場景
可以從其他場景中看到很多相同的工作流工具，但是在本例中，差異分析工具也比較相關輸入的模式，支持復雜的分析。
結束語
隨著 Web API 和社會媒體的普及，防火牆直接和間接地影響著企業系統設計，很多信息系統的格式服從於半結構化報告工具，這是為系統優化的監控階段做准備時要考慮的一個要點。與此同時，此類現代系統的地域性分散特征使得采用單一的系統分析和優化方法是不切實際的。對於企業架構師來說，在應用准則時進行操作系統分析是一個非常重要的進步，不過他們應該認識到，在現實中不可能實施完全一樣的准則。具有一個靈活的工具箱非常重要，讓您可以進行重新配置和重新部署，以適應新出現的場景。我希望您從本文學習到一些可能性、一些復雜性和幾種報告 XML 消息流的方式，可以支持現代系統架構中的持續改進。