業(yè)務流程和精編層

　　應用程序架構的評估要考慮業(yè)務流程和精編功能。評估人員應該檢查組織，查看他們是否采用任何業(yè)務流程層和運行時引擎來編排他們的業(yè)務服務/應用程序功能。以下幾點用于評估這個架構層。

　　如果組織使用了任何自主流程流或工作流層，通過將其移植到外部 BPEL 設計工具和運行時引擎來檢查它是否遵循 BPEL 標準。識別在開放標準運行是引擎上運行這樣的自主工作流需要遵循的步驟和程序。

　　組織是否擁有任何自動為部署而生成 BPEL 運行時代碼的業(yè)務流程建模工具？

　　檢查遵循 BPEL 的運行時引擎如何實現(xiàn)為一個可伸縮的成熟產(chǎn)品，并擁有補償、業(yè)務和技術異常處理功能以及指標、交易量監(jiān)控功能。

　　檢查當前流程流是否支持調(diào)用人工任務、選擇器、業(yè)務規(guī)則和 ESB。

　　檢查 BPEL 流程流和服務交互是如何實現(xiàn)的：它們是緊密耦合還是松散耦合的？BPEL 流程本身可以使用開放標準呈現(xiàn)嗎？

　　服務和呈現(xiàn)功能

　　現(xiàn)在，我們將從另一個角度檢查如何評估系統(tǒng)和應用程序的架構：它如何與作為接口和 API 的服務或呈現(xiàn)功能相關。服務成熟度從以下幾點確定：

　　如何訪問服務？是通過 Web 服務或 SCA 接口這樣的開放技術標準嗎？

　　服務如何通過底層系統(tǒng)實現(xiàn)，它們是緊密耦合的還是松散耦合的？

　　組織的邊界服務遵循 ACCORD、HiPAA 等行業(yè)標準進行企業(yè)數(shù)據(jù)共享和訪問嗎？

　　服務使用適當?shù)姆纸夂土６燃墑e實現(xiàn)嗎？

　　服務同時支持同步和異步調(diào)用嗎？

　　服務同時支持異常處理和故障恢復嗎？

　　服務同時支持身份驗證和授權碼？

　　服務在設計時和運行時都有在注冊表中發(fā)布的條件嗎？

　　設計時和運行時都支持服務版本控制嗎？

　　技術服務如何組織，以及應用程序服務或業(yè)務服務在實現(xiàn)業(yè)務交易時如何與這些技術服務交互？

　　業(yè)務規(guī)則

　　本小節(jié)評估應用程序的架構與業(yè)務規(guī)則之間的關系。業(yè)務規(guī)則是如何實現(xiàn)的？它們與系統(tǒng)緊密耦合且不能被外部化嗎？盡管有些實現(xiàn)是松散耦合的，但它們?nèi)耘f不能被外部化，要修改規(guī)則需要代碼級別的修改。有些實現(xiàn)被松散耦合和外部化，但使用一個自主規(guī)則引擎和自主編程框架。有些業(yè)務規(guī)則也是松散耦合和外部化的，它們的編程模型遵循 JSR94 等標準，規(guī)則可以隨業(yè)務要求輕松改變。以下幾點用于評估解決方案的架構中采用的業(yè)務規(guī)則的強度。

　　規(guī)則引擎是如何構建的？它是純 Java 類或 EJBs 嗎？它實現(xiàn)為一個可伸縮的成熟產(chǎn)品，具有在線編輯和完整的生命周期管理支持嗎？

　　現(xiàn)有規(guī)則引擎支持第三方規(guī)則引擎連接，以便添加新的規(guī)則或將現(xiàn)有規(guī)則傳輸?shù)降谌揭鎲幔?/p>

　　檢查這個規(guī)則組件是否可以呈現(xiàn)為一個 Web 服務或 SCA 服務，以便從外部 BPEL 流程流編排（orchestrate）或從第三方客戶機調(diào)用。

　　服務注冊層

　　服務注冊表提供服務的注冊、元數(shù)據(jù)的管理和自動化服務。這個層根據(jù)以下問題的答案進行評估：

　　是否正在使用一個注冊表？如果沒有，使用共享服務的各方如何知道服務的可用性和功能？如何維護服務信息以避免不必要的復制？

　　有什么政策來確保注冊表的正確使用？

　　如何在注冊表內(nèi)部和外部定義和管理服務元數(shù)據(jù)？設計中考慮了未來可能出現(xiàn)的長期需求了嗎？

　　在 SOA 生命周期（從開始到結束）中的哪個階段使用這個注冊表？

　　服務訪問控制和更改管理政策是如何治理的？是否有適當?shù)目刂苼砥胶獍踩?、可修改性、以及遵?IT 和其他標準？

　　注冊表正用于服務調(diào)用的動態(tài)路由（比如，故障轉移、負載平衡和應用程序分區(qū)）嗎？如果是，注冊表安裝是單個故障點嗎？它滿足性能和故障轉移時間要求嗎？

　　注冊表是公開的還是私有的？注冊表實現(xiàn)能恰當?shù)靥幚韮?nèi)部和外部服務之間的區(qū)別嗎？

　　數(shù)據(jù)和數(shù)據(jù)訪問層

　　這個小節(jié)評估應用程序的架構與數(shù)據(jù)和數(shù)據(jù)訪問之間的關系。進行這個小節(jié)的評估時要考慮以下幾點：

　　數(shù)據(jù)模型有多健壯和多靈活？它遵循成熟的行業(yè)標準嗎？可以輕松添加新的數(shù)據(jù)元素嗎？

　　數(shù)據(jù)訪問層使用什么實現(xiàn)？它是緊密耦合且使用自主框架嗎？它是松散耦合且遵循諸如開源數(shù)據(jù)對象之類的成熟框架嗎？

　　組織利用 toplink、hibernate 或 iBatis 等對象關系映射工具嗎？

　　如果一個數(shù)據(jù)資源庫跨企業(yè)分發(fā)，它遵循哪種機制來允許對應用程序的訪問？

　　要支持 “信息即服務”，組織需要利用哪些種類的工具或產(chǎn)品？

　　企業(yè)數(shù)據(jù)架構如何通過更少的數(shù)據(jù)延遲幫助處理從事務型數(shù)據(jù)到分析型數(shù)據(jù)的轉換？

　　企業(yè)數(shù)據(jù)架構如何幫助對數(shù)據(jù)進行分析性處理，以便根據(jù)需要向業(yè)務用戶交付信息？

　　集成架構遵循

　　這個小節(jié)從以下角度評估應用程序的架構：它與包含第三方和遺留系統(tǒng)的應用程序、組件和服務的集成之間的關系。評估集成層的成熟度時應考慮以下幾點。

　　需要詢問的關于集成層的幾個樣例評估問題是：

　　集成層的健壯程度如何？它實現(xiàn)為一個可伸縮的成熟產(chǎn)品嗎？或者，它基于一個按需（as-needed）基礎，使用一個開源 API 或使用多個連接器和適配器來實現(xiàn)嗎？

　　受到支持的集成架構模式是什么？它將使用 ESB、hub and spoke、或者 point-to-point 嗎？

　　集成層支持的功能有哪些，比如消息路由、數(shù)據(jù)格式轉換、針對所有服務的中央安全網(wǎng)關？它將支持發(fā)布和訂閱消息模型和消息聚合嗎？

　　集成層與系統(tǒng)或應用程序的其余部分松散耦合或緊密耦合的程度如何？

　　組織當前支持哪些不同類型的集成規(guī)范/標準/框架？例如，它支持 RPC、RMI、SOAP/JMS 或 SOAP/HTTP 嗎？

　　集成層支持異常處理、事件管理、審計、日志記錄等輔助功能并支持訪問控制嗎？

　　當前遵循的應用程序架構提供了一個條件來將這個集成層引入到擁有具有集成架構的成熟解決方案的層之間嗎？

　　我們特意通過獲取關于下面的問題的信息來采集關于遺留應用程序集成在企業(yè)內(nèi)部發(fā)生方式的信息：

　　為新系統(tǒng)和遺留系統(tǒng)的集成采用了什么機制？我們尋找的機制包括屏幕搜刮器、Web 服務調(diào)用、帶有用于遺留平臺的適配器的 ESB、消息傳遞系統(tǒng)、直接遺留軟件 API 調(diào)用、特定于技術的網(wǎng)關和橋接。

　　已選擇的機制是如何根據(jù)復雜性和實現(xiàn)成本進行比較的？

　　根據(jù)預期的調(diào)用數(shù)量、理想的響應時間，已選擇的機制滿足系統(tǒng)性能要求嗎？

　　訪問控制和數(shù)據(jù)隱私等安全要求在現(xiàn)有和遺留系統(tǒng)中都得到滿足了嗎？