SOA解決方案中涉及的遺留系統的設計策略(4)

　　要考慮的設計策略

　　為了構建支援總體企業遵從性的可靠資訊管理體系結構，可能考慮採用針對此問題的各種設計策略與原則。

　　在業務流程分析中對範圍變更進行規劃

　　在轉換專案進行期間，經常遇到這種情況，通過系統分析和設計發現了一些不希望出現的資料處理場景。可能需要將之前在範圍之外的業務操作納入範圍中，以便能夠對其進行修改，以接納一組新系統。新的基於SOA的系統甚至可能需要提供內部應用程式，供這些已經更改的業務操作使用，如用於更新某些客戶詳細資訊的外部處理步驟。

　　釋出和訂閱遺留實體變更

　　當作為服務者參與的遺留IT系統中已得到一致認可的實體和屬性資料發生變更時，需要開發外部處理步驟來告知SOA。理想情況下，這應該是實時的，但此工作實際經常以計劃批處理活動的形式進行。在舊式非結構化應用程式中，向遺留IT系統應用指令程式碼來檢測資料記錄發生更改的時間的做法可能開銷非常大。

　　您的企業必須進行的一項工作是，要評估遺留系統所擁有的資料以及系統通知更改的相關方的能力。如果頻繁更改對SOA非常重要的資料，而遺留系統又無法生成記錄級別的事件觸發器（以便最好地進行日常批量提取工作），則可能會需要進行再工程，或替換遺留系統。確保業務服務的QoS與計劃的工程工作一致。說明在進行事先計劃的增量工程改進工作（如從關鍵服務資料每日批處理的方式過渡到實時的訊息驅動處理）的情況下，QoS將如何隨時間的增加提高。

　　資訊服務查詢Facade

　　資訊管理服務的操作應該提供能夠應用於資料或內容的簡單操作。查詢Facade隱藏瞭如何訪問和操作資訊以及如何跨多個物理IT系統的細節。基本上來說，查詢Facade可以實現兩個模式來實現資料整合。由於企業中存在很多方案和遺留系統，很可能將同時使用這兩種方法來實現服務：

　　·將資料帶到查詢中。將變化慢的資訊整理到承載資料儲存區（例如，倉庫），並在其中對資料進行操作。可以在此處使用提取、轉換和載入（Extract, Transform, and Load，ETL）技術。
　　·將查詢帶到資料中。對於快速變化的事務資料，操作必須進入物理源中對其進行操作。可以使用聯結器和介面卡技術來進行此類訪問（例如讀取和更新）。

　　在SOA中，實際查詢Facade可以使用各種模式實現，如聯合與填充（有關更多資訊，請參見參考資料中的“資料整合應用程式模式”），還可以使用服務資料物件 (Service Data Object) 和資料訪問服務(Data Access Service)等技術（請參見參考資料）。各個服務實現的總體設計模式將影響這些決策；有關更多資訊，請參見“Toward a pattern language for Service-Oriented Architecture and Integration, Part 1”（developerWorks，2005年6月）。但在此問題中，將需要對實現設計進行擴充套件，以讓服務更為智慧化。假定已經為遺留系統配備了釋出實體資料變更的解決方案（達到認可的QoS水平），資訊服務需要訂閱變更（哪些資料和頻率如何）並將變更應用到相應的基礎物理系統，如執行資料同步的物理系統。

　　而這正是在體系結構的此處做出主要實體決策。哪個遺留IT系統應該視為主系統，在哪些事務場景中應這樣處理？主資料管理技術可在此處為您的實現提供幫助，不過這些選項及決策（與遺留系統的整合能力進行權衡）應該是體系結構定義中非常重要的部分。

　　業務規則放置

　　到SOA的轉換引入了新IT基礎設施，其中包括整合中介軟體和新組合應用程式以及其他實體。業務規則不再包含在應用程式中。狀態通過業務規則的執行有效地進行管理。作為開發資訊管理設計的一部分，必須瞭解業務規則邏輯的型別和位置。

　　SOA中的業務規則的型別包括：

　　·引用完整性規則
　　·應用程式行為規則
　　·跨應用程式完整性規則
　　·事務處理業務邏輯規則
　　·資料實體處理規則，如儲存過程

　　應該重用此類策略，而不是重新生成業務規則。隨著SOA的引入，必須仔細地考慮現有業務規則和新業務規則的執行（以支援服務的可靠執行）。規則邏輯本身（無論其位於上下文中任何位置）可能需要作為服務公開，以便能呼叫來維護特定處理場景的完整性。

　　潛在設計策略影響

　　做出這些決策時必須考慮的解決方案的潛在影響包括：

　　·雙金鑰處理。通過引入SOA而獲得的業務領域的效率需要與額外的資料輸入任務（從而增加了資料輸入錯誤的風險）進行權衡。但這可能是用於處理資料同步時間確定場景的唯一選項。通常並不會輕視這些場景。您的企業需要建立人頭計算來執行事件驅動的雙金鑰生成，從而避免由於夜間批量更新造成的時間延遲。需要通過在系統中開發自動介面來幫助進行資料同步，以抵消此成本。這個迴圈分析應該評估實現自動化介面（特別測試）所需的時間是否對總體交付時間表造成影響。
　　·不必要的反饋迴圈。對CRM系統中的客戶記錄的更新之後緊跟對SOA的手動或自動呼叫，以告知其他應用程式這個意外的客戶資料變更。為了更新客戶，SOA將呼叫其資訊服務，該服務本身將呼叫原始CRM系統並更新客戶資料。根據用法模型不同，資訊服務體系結構需要實現不同樣式的update customer操作。
　　·範圍漸變。定義SOA範圍宣告時，缺乏遺留IT系統的知識，不瞭解哪些流程和資訊管理功能一定將更改。服務模型的派生對遺留分析起到促進作用，只會發現需要更多的SOA基礎設施實現。在定義業務服務和工程計劃的整體範圍前，需要考慮發現階段的預算和規劃。

　　結束語

　　本文列出了一些重要領域，您需要關注這些領域，以便成功交付引入SOA的業務轉換專案。業務轉換對SOA的挑戰非常重要。大部分企業都通過引入SOA基礎設施（能以此為基礎構建組合應用程式）以增量的方式進行轉換。他們使用遺留IT系統實現服務提供者。

　　為了讓企業在所有操作上保持可靠性和一致，轉換專案必須開發企業資訊管理解決方案，而此方案中包括SOA（但涉及的內容並不限於此範圍）。此解決方案應該在SOA中跨IT系統處理資料和內容的一致性和同步問題，以便能將資訊服務公開供使用。

　　負責交付SOA轉換的解決方案架構師還必須在考慮總體受控的企業體系結構和預算的情況下，對遺留IT系統的功能與SOA的需求進行權衡。資訊管理解決方案的實現策略中的資料整合技術和主資料管理因素。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-406864/，如需轉載，請註明出處，否則將追究法律責任。