【導讀】未定義書簽。未定義書簽。

　　

【正文】 平臺規(guī)劃建議書 金蝶中間件 第 25 頁 共 117 頁 SCA 服務封裝體系 服務組件框架 （ Service Component Architecture，以下簡稱 SCA）提供了一種編程模型，可以支持基于 SOA 的應用程序實現。它是基于這樣的思想：業(yè)務功能以一系列服務形式提供，可以組裝在一起，創(chuàng)建一個解決方案，以解決業(yè)務需求。這些合成的應用可以包含新實現的服務，也可以包含已有系統提供的業(yè)務功能。 SCA 提供的模型，支持服務合成，以及新服務構件的創(chuàng)建， 其中可以包括已有應用功能在 SCA 合成服務中使用。 圖 38. SCA 體系結構 SCA 組裝模型由一系列定義 SCA 域的配置的元件組成，包括服務構件的組裝、連接關系及描述它們如何連接的相關元件。 SCA 的一個基本元件是構件（ ponent），是一個基本構造單元。構件組成一個實現的可配置實例，這個實現是一段代碼，可以提供業(yè)務功能。業(yè)務功能可以被其它構件使用，稱為服務接口（ service interface）。實現可以依賴另一個構件的服務接口，稱為引用（ reference）。實現可以有可設置的屬性，這些屬性值會影響業(yè)務功 能的執(zhí)行。 合成服務（ Composite）用于組裝 SCA 元素到一個邏輯組中，在 SCA 域中，這是一個基本的合成單位。合成服務包含一組構件、服務、引用和連接線，再加一組屬性，用于配置構件。 Composite 是發(fā)布服務的構件單元，它比 Component 多了接口、綁定及連接線的內容。接口是定義了一個或多個業(yè)務功能，這些業(yè)務功能由服務提供，并由構件通過引用使用；綁定是描述了服務的獲取方式， SCA 支持多個綁定類型，如 SCA 服務、 WS、無狀態(tài)會話 EJB、數據庫存儲過程、 EIS 服務等；合成服務內的連線，是用來連接源構件的引用到目的構件的服務。 SCA 模型中定義的構件、合成服務、相關子系統和組成元素及其之間的關系，最終需要使用基于 XML 的部署文件進行描述和打包，并部署到 SCA 域中，這樣才能構成完成具體業(yè)務和服務的運行環(huán)境。 SCA 是一種模型，可以支持實現服務構件的各種技術，連接服務構件的各種存取方法。對于構件，青海工程建設領域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 26 頁 共 117 頁 不僅包括不同的編程語言，也包括這些語言使用的框架和環(huán)境。對于存取方法 SCA 合成操作支持各種通訊，服務存取技術，如： WS、 MQ、 RPC。 AESB 實現了 SCA 規(guī)范，并作為整體體 系中的一個重要的基礎引擎。通過 SCA 規(guī)范的方式，對應用系統所暴露出來的各種基于不同的編程語言和技術模型的功能接口進行包裝，將這些功能借口以標準化的方式，封裝成一個個業(yè)務服務，并注冊到 AESB 服務注冊目錄中。 AESB 可支持的技術模型有： ? JCA ? Web 服務 ? JMS SDO 數據模型 SCA 中的一個關鍵推動因素是服務數據對象（ Service Data Object，以下簡稱 SDO）。 SDO 其實與 SCA 是一對具有對應關系的規(guī)范。軟件 =服務 +數據， SCA 更加關注業(yè)務邏輯，而 SDO 則更側重于業(yè)務數據。 SDO 是一種針對在不同的數據源之間使用統一的數據編程模型的規(guī)范說明。簡單來說， SDO 就是旨在提供這樣一種數據對象：它像橡皮泥一樣，可以根據實際的數據源決定它的實際表現。而在使用過程中不必考慮其實際類型和構建方法。 SDO 是信息的容器，設計用于提升開放標準和互操作性。 SDO 提供了在整個企業(yè)應用程序中表示信息的方法，是一種針對在不同的數據源之間使用統一的數據編程模型的規(guī)范說明，為通用的應用程序提供健壯 (robust)的支持，是應用程序、工具、框架等更容易的進行數據的增、刪、查、改、約束、更新等操作。 SDO 數據模 型具備如下的三個優(yōu)點： ? 弱類型 ? 自描述 ? 操作可回朔 AESB 擴展了 SDO 規(guī)范，實現動態(tài)元數據支持的 SDO 模型。 AESB 采用了 SDO 數據模型，對各種服務所產生的數據進行統一封裝。 青海工程建設領域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 27 頁 共 117 頁 基于 DSL的腳本引擎 領域特定語言（ Domain Specification Language，以下簡稱 DSL）是指一種面向函數編程的理念。通過 DSL，可以根據使用者自身的習慣來訂制編程語言規(guī)則，以業(yè)務化的方式，降低編程語言的可理解性，增強編程語言的可讀性。 例如，在某些業(yè)務場景下，需要判斷某個閥值進行條件判斷，用 Java 代碼表述如下： If ( tag 100) { (―1‖)。 } else { (―0‖) } 通過 DSL 對語法進行抽象和再定義之后，這個條件判斷可以表述為： 如果 tag 大于 100,打印 1。否則 ,打印 0。 AESB 所提供的腳本引擎，基于實現 DSL 功能的函數編程語言 Apusic Elite。當在復雜的業(yè)務場景下，需要通過腳本方式完成相應功能時，通過 DSL 抽象和定制語法規(guī)則，以非常自然語言和業(yè)務化的方式定制腳本。這樣，平臺的主導權從程序員手中，移交到了業(yè)務人員手中。 動態(tài)元數據 AESB 通過 SDO 方式對服務所產生的數據進行包裝。當數據從一個服務傳遞到另一個服務的時候，需要進行數據的轉換，使數據從一個服務可以識別的信息變更為另一個服務可以識別的信息。 例如，某個服務的提供者提供了一個接口，接收一個描述人員信息的對象為參數，這個人員信息的描述如下： id 身份證號 Name 姓名 而服務的請求者，在發(fā)起請求的時候，傳遞的描述人員的信息如下： Shenfenzhenghao 身份證號 青海工程建設領域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 28 頁 共 117 頁 MINGCHENG 姓名 在數據被傳遞給服務的提供者時，必須經過數據的轉換。 服務的請求者將數據傳入時，會被 AESB 封裝成 SDO 數據格式。而 SDO 數據格式是帶有元數據的。這個時候的數據轉換，就是將傳入數據的元數據，按照目標數據格式的元數據進行變遷和轉換。在上述的例子中，通過動態(tài)的元數據變更，將傳入數據的元數據屬性名稱分別修改成 ID 和 Name 即可。 AESB 對每一個接入到平臺中的服務數據的元數據進行統一的管理，通過一系列的元數據變更和變遷，使得不同系統間同語義的異構數據能夠進行相互轉換，相互傳遞。 可靠消息傳輸 AESB 的底層消息傳輸，基于 AMQ，能夠提供可靠、穩(wěn)定、安全的消息傳輸。 ? 智能路由 在一個拓撲網絡中，消息傳輸的路徑直接影響到消息的傳輸效率。 AMQ 提供智能路由功能，在選擇路徑時可根據路徑的長度等情況進行綜合考慮，以保障消息以最快速度傳送到目的地。 如在一個由烏魯木齊 (A)、北京 (B)、哈爾濱 (C)、成都 (D)、南昌 (E)五個路由節(jié)點組成的網絡中： 圖 39. 由 AMQ 組成的消息網絡 有消息需要從 A 發(fā)送到 E，在這個網絡中， A 到 E 有 2 條傳輸路徑，分別是： a)ABCE； b)ADE AMQ 智能路由會首先選擇最短的傳輸路徑，也就是 ADE 路徑傳輸消息。 青海工程建設領域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 29 頁 共 117 頁 ? 消息切分 AESB 支持將一個大的消息切分成多個小塊發(fā)送，在目的節(jié)點重新組合成完整的消息。同樣，被切分的消息將獲得集群及智能路由帶來的好處，充分利用網絡帶寬。 圖 310. 消息切分與組合 ? 斷點續(xù)傳 斷點續(xù)傳指的是在消息傳輸過程中，由于網絡原因導致消息傳輸中斷，當網絡恢復時，不需要重新傳輸整個消息，而只是 從中斷的位置傳送即可。 AESB 支持普通消息和大尺寸對象消息，兩種消息都支持傳輸時的斷點續(xù)傳。 因為普通消息在傳輸時實現了消息切分，所以能夠支持斷點續(xù)傳。即消息被傳送中途出現網絡故障時，仍可在故障恢復重新連線后，將后續(xù)的消息片段重新發(fā)送，不必將整個消息重新發(fā)送。而服務器在傳輸大尺寸對象消息時已經內置了對斷點續(xù)傳的支持。 ? 消息壓縮 AESB 提供數據壓縮 API，方便用戶在收發(fā)消息時對消息進行壓縮和解壓縮，以提高消息傳輸效率，這可以提升大消息的傳輸效率。 圖 311. 消息壓縮與解壓 ? 消息加密 AESB 支持在消息傳輸過程中對消息進行加密，保證消息傳輸的安全性。加密的密碼由用戶進行設置。 青海工程建設領域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 30 頁 共 117 頁 圖 312. 消息加密 服務的注冊和管理 AESB 服務注冊庫以 UDDI 標準為基礎，并在此之上加入了自身的擴展。 AESB 通過 SRR，可以進行服務的注冊、導入、導出、代理 Web 服務和服務的發(fā)現、查找等功能，并將進一步加強服務的管理及監(jiān)管功能。 圖 313. 服務注冊庫管理 青海工程建設領域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 31 頁 共 117 頁 圖 314. 服務注冊信息描述 基于 AESB 的實現方案 由上所述，可見金蝶 AESB 具備上述企業(yè)服務總線所需要的技術能力，在本項目我們將采用 AESB搭建的 ESB 基礎平臺，建立 ESB 接口規(guī)范、開發(fā)規(guī)范和管理規(guī)范。 統一標準服務 1) 設 計和開發(fā)方法 服務接口的設計有三種方法： ? 自頂向下 使用此方法時，設計人員從整體考慮，定義服務接口，然后，由各應用系統完成服務實現。 ? 自底向上 從各應用系統中現有代碼定義和創(chuàng)建服務。使用此方法時，通常將選擇各應用系統中現有的組件生成服務。 ? 中間相遇 此方法對前面兩個方法進行了結合。設計人員首先定義服務接口。如果有必要，各應用系統可以使青海工程建設領域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 32 頁 共 117 頁 用自底向上技術來通過方便的應用程序編程接口（ Application Programming Interface，以下簡稱 API）公開現有代碼。然后將編寫在新設計的接口和舊接口之間進行轉換的代碼。 許多開發(fā)人員喜歡使用自底向上技術來加速 SOA 項目中的服務開發(fā)。他們將首先開發(fā)新服務的實現，然后將使用強大的代碼生成向導來為這些服務創(chuàng)建接口。盡管此方法可以加速各個服務的實現，但這對整個 SOA 項目通常都意味著問題。之所以出現問題，是因為自底向上生成經常會得到無法重用的類型定義以及多個定義為表示語義等效信息的類型。 因此，應采用統一的標準業(yè)務服務最佳方式是使用自頂向下方法，可對總體有宏觀把握，更利于服務的規(guī)劃和整合。 2) 服 務 粒度 服務 接口通常應該包含多個操作。定義為單個服務接口一部分的操作應該從語義上相關。僅包含單個操作或少量操作的大部分服務都表明服務粒度不恰當。反過來，采用很少的服務（或者單個服務）來包含大量操作也同樣表明服務粒度不恰當。 服務接口通常應該包含多個操作。定義為單個服務接口一部分的操作應該通過其操作的數據從語義上相關。 每個事務都可以公開為單個操作。例如，我們可以定義名為 MyService 的服務，該服務具有單個接口，為該物理機上運行的所有事務定義操作。這樣會產生具有數十個操作的接口，此方法使得服務難于理解，因此會難于 在業(yè)務流程中重用最終導致出現同一個服務存在很多個版本。 另一個方法涉及到為系統上的每個事務定義新接口。這樣會得到很多接口，而且最終會存在使用這些接口的很多服務。服務大量增加反過來會導致服務治理問題，從而使得更難獲得有效的重用。 最好的方法是，通過對語義相關的事務進行分組來定義服務接口。如果相關的信息駐留在多個 EIS上，則應該首先定義物理系統特定的接口，以對信息類型相關的事務進行分組，然后將這些接口聚合為單個接口。 3) 異 常 的使用 服務通常由面向最終用戶的應用程序（需要向最終用戶提供關于異常的信息）調用。很多業(yè)務 流程需要直接對使用同步綁定調用的服務返回的異常信息進行分析，以便恰當地定向后續(xù)處理。在這種情況下，應該始終盡量利用使用異常的請求 響應操作設計接口。使用采用請求 響應交互模式的同步協議，并定義最終用戶可理解的異常。 青海工程建設領域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 33 頁 共 117 頁 SOA 允許企業(yè)以靈活的方式發(fā)展其 IT 基礎設施。服務提供用于實現 SOA 的基礎，設計良好的服務接口可以對 SOA 的實現起到促進作用，而設計糟糕的接口則會極大地使得工作復雜化。 接入方式 AESB 通過 SCA 規(guī)范的方式，對應用系統所暴露出來的各種基于不同的編程語言和技術模型的功能接口進行包裝 ，將這些功能借口以標準化的方式，封裝成一個個業(yè)務服務，并注冊到 AESB 服務注冊目錄中。 SCA 主要是針對在面向服務的計算環(huán)境里組件的實現方法。同時，它強調了這些組件與現有的平臺，組件之間的關聯，并描述怎樣通過已有的技術、平臺甚至于現有的組件來實現面向服