| 2007 年 8 月 28 日 面向服務(wù)的體系結構（Service-Oriented Architecture，SOA）是很多業(yè)務(wù)轉換工作的核心。很多企業(yè)采用增量式方法進(jìn)行 SOA 轉換，使用其寶貴的遺留 IT 系統作為服務(wù)提供者參與其中。解決方案架構師面臨的挑戰不僅是將 SOA 基礎設施作為促進(jìn)轉換的手段交付，而且還要確保企業(yè)級業(yè)務(wù)操作保持可靠性和兼容性。您的企業(yè)必須制定可作為 SOA 一部分的企業(yè)信息管理策略，并跨所有業(yè)務(wù)操作保持總體數據和內容的一致性。本文介紹了此類(lèi)轉換中面臨的挑戰，并將討論一些值得考慮的設計策略。 如果您的企業(yè)和大部分企業(yè)一樣，則您的業(yè)務(wù)戰略和核心競爭力分析已經(jīng)確定了需要在哪些領(lǐng)域重點(diǎn)關(guān)注業(yè)務(wù)再工程和 IT 現代化。一個(gè)典型的結果（至少對于企業(yè)的某些核心方面如此）是轉換到面向服務(wù)的業(yè)務(wù)，開(kāi)始依賴(lài) SOA。業(yè)務(wù)操作是圍繞一組服務(wù)設計的，而這要求對當前 IT 系統進(jìn)行再工程，并將其作為服務(wù)提供者加以集成。此轉換還可能引入一些新的服務(wù)提供者。目標是能夠構建新的組合應用程序（如內部工作區門(mén)戶(hù)應用程序或 Internet 商業(yè)應用程序），從而高效地處理特定的業(yè)務(wù)需求。 作為這個(gè)充滿(mǎn)挑戰的轉換工作的一部分，企業(yè)通常會(huì )開(kāi)展一系列重大的業(yè)務(wù)與 IT 項目。主要的轉換交付內容包括：
轉換的這些主要交付內容帶來(lái)了一組略微次要的派生挑戰。這些可確保企業(yè)按照其轉換意圖進(jìn)行交付，并能夠監視和適應更改，從而實(shí)現靈活性。這些轉換挑戰通常要遵循以下原則：
有些企業(yè)非常幸運，能夠在整個(gè)企業(yè)內進(jìn)行到 SOA 的業(yè)務(wù)轉換。此方法要求為主要轉換交付內容提供更富有挑戰的實(shí)現，但最終能提供一個(gè)更便于發(fā)展和開(kāi)發(fā)次要轉換交付內容的環(huán)境。當希望在整個(gè)企業(yè)內驅動(dòng)業(yè)務(wù)和 IT 變更的 C 級別的執行人員積極地幫助實(shí)現策略計劃時(shí)，通常會(huì )出現這種情況。 不過(guò)，大部分企業(yè)轉換都是增量式的——雖然很重要而且也采用了相應的策略，但是逐步進(jìn)行的。這通常意味著(zhù)將對遺留 IT 系統進(jìn)行再工程，以使其參與新業(yè)務(wù)操作的支持——例如，與其他 IT 系統進(jìn)行組合，以加速客戶(hù)訂單的直接處理。這些 IT 系統還需要執行所有（或者至少是大部分）當前功能。SOA 轉換范圍外 的業(yè)務(wù)操作將仍然繼續。 在此轉換場(chǎng)景中，必須仔細考慮 SOA IT 基礎設施的實(shí)現設計。在這些 IT 系統內的數據處理影響范圍外的數據處理，同時(shí)也受到范圍外的數據處理的影響?？傮w數據處理環(huán)境必須繼續保持可靠性和與總體業(yè)務(wù)操作的兼容性。 圖 1 中的示例顯示了三個(gè)再工程為服務(wù)提供者的遺留系統。 圖 1. 新 SOA 環(huán)境中的遺留 IT 系統  在圖 1 中，業(yè)務(wù)轉換項目已經(jīng)構建了 SOA 基礎設施，業(yè)務(wù)服務(wù)通過(guò)此基礎設施進(jìn)行發(fā)布，并供新應用程序使用。此基礎設施通常包括用于支持軟件間多協(xié)議連接、異步與同步消息流管理、消息轉換、規則執行和流程編排的中間件。已經(jīng)構建了使用這些服務(wù)的組合應用程序，甚至遺留系統本身也已經(jīng)通過(guò)新服務(wù)調用得到了增強。
要實(shí)現 SOA 基礎設施，所生成、維護和增強的主要資產(chǎn)是業(yè)務(wù)服務(wù)模型。要使用得到廣泛認可的技術(shù)來(lái)開(kāi)發(fā)該模型，如 IBM? 面向服務(wù)的建模與體系結構（Service Oriented Modeling and Architecture，有關(guān)更多信息，請參見(jiàn)參考資料）。在典型的企業(yè)中，這將混合使用自頂向下分析、自底向上分析和目標-服務(wù)建模。轉換的業(yè)務(wù)目標將派生出流程與信息體系結構，用于驅動(dòng)新業(yè)務(wù)操作的實(shí)現和支持 IT 應用程序：
流程和信息體系結構觀(guān)點(diǎn)通常一起形成并通過(guò)流程數據 (CRUD) 矩陣之類(lèi)表現出來(lái)。它們一起定義組成服務(wù)體系結構的一系列服務(wù)。服務(wù)是一組在消息數據傳入時(shí)調用的操作。服務(wù)實(shí)現執行操作數據或內容的處理（通常通過(guò)持久存儲或訪(fǎng)問(wèn)），并返回結果?？梢酝胶彤惒绞褂梅?wù)，調用通常由集成基礎設施代理。在完全分離的系統中，有些服務(wù)負責流程狀態(tài)的更改（例如，將信息表示為已請求，將客戶(hù) X 的新地址表示為已驗證）。其他服務(wù)負責對信息狀態(tài)進(jìn)行更改，確保將已經(jīng)進(jìn)行了操作的數據和內容置為所需的狀態(tài)，以作為以后的服務(wù)事件的依賴(lài)（例如，客戶(hù) X 的新運輸地址已生效）。
遺留 IT 系統無(wú)疑將作為您的企業(yè)服務(wù)提供者實(shí)現的一部分，將集成到 SOA 基礎設施中。遺留系統不僅包括傳統大型機處理，而且也包括企業(yè)資源規劃（Enterprise Resource Planning，ERP）應用程序、內部和外部 Web 應用程序、工作流應用程序、掃描與打印系統等等?？梢赃M(jìn)行很多工作來(lái)支持使用這些遺留系統并將其集成到服務(wù)提供者實(shí)現中：
為了參與 SOA 而將遺留 IT 系統公開(kāi)時(shí)，支持轉換的范圍外的業(yè)務(wù)操作的某些功能將繼續進(jìn)行數據處理。這通常要求了解和處理數據傳播和同步問(wèn)題。 用戶(hù)將繼續使用原始應用程序方法調用遺留 IT 系統，通常通過(guò)用戶(hù)界面（如大型機啞終端或已打包應用程序的 UI）。SOA 依賴(lài)于一組用于描述在 SOA 生態(tài)系統中傳遞的消息的數據模式。這些數據模式實(shí)現為集成在協(xié)作服務(wù)操作集中的物理數據消息；這可以包括運行時(shí)數據轉換和語(yǔ)義映射或消息數據的擴充。將隨后由基礎遺留 IT 系統使用和處理此數據。 可以使用 SOA 執行的流程集依賴(lài)于需要處于特定狀態(tài)的一組集合數據和內容。通過(guò) SOA 功能和遺留 IT 系統的并行處理可能會(huì )導致該狀態(tài)模型中出現不穩定的情況。 在圖 1 的示例中，此轉換允許具有直接處理能力的新 Internet 應用程序設置和管理客戶(hù)的保單。新應用程序可以觸發(fā)與客戶(hù)的接觸，并在保單快要錯過(guò)續簽期限時(shí)給出續簽協(xié)議。不過(guò)，SOA 范圍外的有些現有業(yè)務(wù)操作可能會(huì )帶來(lái)問(wèn)題?？蛻?hù)可以通過(guò)很多方式通知公司自己已搬家。盡管保單最先是通過(guò)新 Internet 應用程序購買(mǎi)的，客戶(hù)可能不會(huì )使用該 SOA 應用程序通知公司自己的地址發(fā)生變化，可能會(huì )轉而采用寄信的方式。后臺辦公流程會(huì )導致客戶(hù)的新地址僅應用到客戶(hù)關(guān)系管理（Customer Relationship Management，CRM）系統?，F有 CRM 系統的批處理會(huì )在夜間使用客戶(hù)數據更新保險聯(lián)系人管理系統。由于新的基于 SOA 的系統是圍繞類(lèi)似于實(shí)時(shí)的事務(wù)設計的，因此現在將導致同步時(shí)間問(wèn)題。在同步期間，新應用程序可以嘗試使用舊地址就續簽事宜聯(lián)系客戶(hù)，而事實(shí)上能識別上下文的響應型 SOA 應用程序應該使用新地址取消舊保單，并設立新保單與此人聯(lián)系。
從理論上而言，SOA 架構師角色應該考慮采用服務(wù)的基礎設施的設計與實(shí)現。SOA 建模技術(shù)可指導您決定流程和信息將要使用的服務(wù)，與服務(wù)提供者聯(lián)系，并構建應用程序來(lái)調用作為流程執行和數據處理一部分的服務(wù)操作。服務(wù)使用者并不管服務(wù)提供者如何實(shí)現服務(wù)，只要服務(wù)聲明自己將根據事先達成的契約（服務(wù)操作及其關(guān)聯(lián)的 QoS）處理和管理數據即可。 在特定情況下，此模型可能可行，特別在從企業(yè)外提供服務(wù)提供者實(shí)現時(shí)。本文所討論的是很多企業(yè)在目前引入 SOA 過(guò)程中所采用的具體而通用的方案。 事實(shí)上，總體解決方案架構師在 SOA 轉換中要擔當很多職責，特別在進(jìn)行增量式轉換的企業(yè)中更是如此。這些職責是在企業(yè)治理流程內進(jìn)行的；有關(guān)更多信息，請參見(jiàn)文章“SOA 治理案例”（developerWorks，2005 年 8 月）。 首先，解決方案架構師考慮 SOA 基礎設施的設計與實(shí)現；這包括確定將充當軟件系統（形成服務(wù)提供者實(shí)現的一部分）的遺留 IT 系統。其次，解決方案架構師提供用于組裝服務(wù)使用應用程序的開(kāi)發(fā)流程和環(huán)境。這包括設計模式、標準以及工具環(huán)境。而第三，解決方案架構師必須認識到承擔的全盤(pán)業(yè)務(wù)與 IT 體系結構責任。業(yè)務(wù)體系結構將說(shuō)明采用功能和契約外包的業(yè)務(wù)策略的合理性。IT 體系結構將提供支持總體業(yè)務(wù)操作所必要的 IT 系統。在任何企業(yè)（包括大型企業(yè)）中，這通常都是很大的戰術(shù)與戰略應用程序投資組合。
為了構建支持總體企業(yè)遵從性的可靠信息管理體系結構，可能考慮采用針對此問(wèn)題的各種設計策略與原則。 在業(yè)務(wù)流程分析中對范圍變更進(jìn)行規劃 在轉換項目進(jìn)行期間，經(jīng)常遇到這種情況，通過(guò)系統分析和設計發(fā)現了一些不希望出現的數據處理場(chǎng)景?？赡苄枰獙⒅霸诜秶獾臉I(yè)務(wù)操作納入范圍中，以便能夠對其進(jìn)行修改，以接納一組新系統。新的基于 SOA 的系統甚至可能需要提供內部應用程序，供這些已經(jīng)更改的業(yè)務(wù)操作使用，如用于更新某些客戶(hù)詳細信息的外部處理步驟。 當作為服務(wù)者參與的遺留 IT 系統中已得到一致認可的實(shí)體和屬性數據發(fā)生變更時(shí)，需要開(kāi)發(fā)外部處理步驟來(lái)告知 SOA。理想情況下，這應該是實(shí)時(shí)的，但此工作實(shí)際經(jīng)常以計劃批處理活動(dòng)的形式進(jìn)行。在舊式非結構化應用程序中，向遺留 IT 系統應用指令代碼來(lái)檢測數據記錄發(fā)生更改的時(shí)間的做法可能開(kāi)銷(xiāo)非常大。 您的企業(yè)必須進(jìn)行的一項工作是，要評估遺留系統所擁有的數據以及系統通知更改的相關(guān)方的能力。如果頻繁更改對 SOA 非常重要的數據，而遺留系統又無(wú)法生成記錄級別的事件觸發(fā)器（以便最好地進(jìn)行日常批量提取工作），則可能會(huì )需要進(jìn)行再工程，或替換遺留系統。確保業(yè)務(wù)服務(wù)的 QoS 與計劃的工程工作一致。說(shuō)明在進(jìn)行事先計劃的增量工程改進(jìn)工作（如從關(guān)鍵服務(wù)數據每日批處理的方式過(guò)渡到實(shí)時(shí)的消息驅動(dòng)處理）的情況下，QoS 將如何隨時(shí)間的增加提高。 信息管理服務(wù)的操作應該提供能夠應用于數據或內容的簡(jiǎn)單操作。查詢(xún) Facade 隱藏了如何訪(fǎng)問(wèn)和操作信息以及如何跨多個(gè)物理 IT 系統的細節?；旧蟻?lái)說(shuō)，查詢(xún) Facade 可以實(shí)現兩個(gè)模式來(lái)實(shí)現數據集成。由于企業(yè)中存在很多方案和遺留系統，很可能將同時(shí)使用這兩種方法來(lái)實(shí)現服務(wù)：
在 SOA 中，實(shí)際查詢(xún) Facade 可以使用各種模式實(shí)現，如聯(lián)合 與填充（有關(guān)更多信息，請參見(jiàn)參考資料中的“數據集成應用程序模式”），還可以使用服務(wù)數據對象 (Service Data Object) 和數據訪(fǎng)問(wèn)服務(wù) (Data Access Service) 等技術(shù)（請參見(jiàn)參考資料）。各個(gè)服務(wù)實(shí)現的總體設計模式將影響這些決策；有關(guān)更多信息，請參見(jiàn)“Toward a pattern language for Service-Oriented Architecture and Integration, Part 1”（developerWorks，2005 年 6 月）。但在此問(wèn)題中，將需要對實(shí)現設計進(jìn)行擴展，以讓服務(wù)更為智能化。假定已經(jīng)為遺留系統配備了發(fā)布實(shí)體數據變更的解決方案（達到認可的 QoS 水平），信息服務(wù)需要訂閱變更（哪些數據和頻率如何）并將變更應用到相應的基礎物理系統，如執行數據同步的物理系統。 而這正是在體系結構的此處做出主要實(shí)體決策。哪個(gè)遺留 IT 系統應該視為主系統，在哪些事務(wù)場(chǎng)景中應這樣處理？主數據管理技術(shù)可在此處為您的實(shí)現提供幫助，不過(guò)這些選項及決策（與遺留系統的集成能力進(jìn)行權衡）應該是體系結構定義中非常重要的部分。 到 SOA 的轉換引入了新 IT 基礎設施，其中包括集成中間件和新組合應用程序以及其他實(shí)體。業(yè)務(wù)規則不再包含在應用程序中。狀態(tài)通過(guò)業(yè)務(wù)規則的執行有效地進(jìn)行管理。作為開(kāi)發(fā)信息管理設計的一部分，必須了解業(yè)務(wù)規則邏輯的類(lèi)型和位置。 SOA 中的業(yè)務(wù)規則的類(lèi)型包括：
應該重用此類(lèi)策略，而不是重新生成業(yè)務(wù)規則。隨著(zhù) SOA 的引入，必須仔細地考慮現有業(yè)務(wù)規則和新業(yè)務(wù)規則的執行（以支持服務(wù)的可靠執行）。規則邏輯本身（無(wú)論其位于上下文中任何位置）可能需要作為服務(wù)公開(kāi)，以便能調用來(lái)維護特定處理場(chǎng)景的完整性。
做出這些決策時(shí)必須考慮的解決方案的潛在影響包括：
為了讓企業(yè)在所有操作上保持可靠性和一致，轉換項目必須開(kāi)發(fā)企業(yè)信息管理解決方案，而此方案中包括 SOA（但涉及的內容并不限于此范圍）。此解決方案應該在 SOA 中跨 IT 系統處理數據和內容的一致性和同步問(wèn)題，以便能將信息服務(wù)公開(kāi)供使用。 負責交付 SOA 轉換的解決方案架構師還必須在考慮總體受控的企業(yè)體系結構和預算的情況下，對遺留 IT 系統的功能與 SOA 的需求進(jìn)行權衡。信息管理解決方案的實(shí)現策略中的數據集成技術(shù)和主數據管理因素。
我們感謝 Rick Robinson、Patrick Dantressangle、Bob Lojek 和 Claudio Cozzi 對本文進(jìn)行審閱并提供了指導。 學(xué)習
| |||||||||||||||||||||||||||||||
聯(lián)系客服
