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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　服務(wù)同時支持身份驗證和授權(quán)碼？

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

　　設(shè)計時和運行時都支持服務(wù)版本控制嗎？

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

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

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

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

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

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

　　服務(wù)注冊層

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　集成架構(gòu)遵循

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

　　需要詢問的關(guān)于集成層的幾個樣例評估問題是：

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

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

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

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

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

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

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

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

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

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

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

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