【正文】 SCA 主要是針對在面向服務(wù)的計算環(huán)境里組件的實現(xiàn)方法。服務(wù)提供用于實現(xiàn) SOA 的基礎(chǔ)，設(shè)計良好的服務(wù)接口可以對 SOA 的實現(xiàn)起到促進作用，而設(shè)計糟糕的接口則會極大地使得工作復雜化。使用采用請求 響應(yīng)交互模式的同步協(xié)議，并定義最終用戶可理解的異常。很多業(yè)務(wù) 流程需要直接對使用同步綁定調(diào)用的服務(wù)返回的異常信息進行分析，以便恰當?shù)囟ㄏ蚝罄m(xù)處理。如果相關(guān)的信息駐留在多個 EIS上，則應(yīng)該首先定義物理系統(tǒng)特定的接口，以對信息類型相關(guān)的事務(wù)進行分組，然后將這些接口聚合為單個接口。服務(wù)大量增加反過來會導致服務(wù)治理問題，從而使得更難獲得有效的重用。 另一個方法涉及到為系統(tǒng)上的每個事務(wù)定義新接口。例如，我們可以定義名為 MyService 的服務(wù)，該服務(wù)具有單個接口，為該物理機上運行的所有事務(wù)定義操作。定義為單個服務(wù)接口一部分的操作應(yīng)該通過其操作的數(shù)據(jù)從語義上相關(guān)。反過來，采用很少的服務(wù)（或者單個服務(wù)）來包含大量操作也同樣表明服務(wù)粒度不恰當。定義為單個服務(wù)接口一部分的操作應(yīng)該從語義上相關(guān)。 因此，應(yīng)采用統(tǒng)一的標準業(yè)務(wù)服務(wù)最佳方式是使用自頂向下方法，可對總體有宏觀把握，更利于服務(wù)的規(guī)劃和整合。盡管此方法可以加速各個服務(wù)的實現(xiàn)，但這對整個 SOA 項目通常都意味著問題。 許多開發(fā)人員喜歡使用自底向上技術(shù)來加速 SOA 項目中的服務(wù)開發(fā)。如果有必要，各應(yīng)用系統(tǒng)可以使青海工程建設(shè)領(lǐng)域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 32 頁 共 117 頁 用自底向上技術(shù)來通過方便的應(yīng)用程序編程接口（ Application Programming Interface，以下簡稱 API）公開現(xiàn)有代碼。 ? 中間相遇 此方法對前面兩個方法進行了結(jié)合。 ? 自底向上 從各應(yīng)用系統(tǒng)中現(xiàn)有代碼定義和創(chuàng)建服務(wù)。 圖 313. 服務(wù)注冊庫管理 青海工程建設(shè)領(lǐng)域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 31 頁 共 117 頁 圖 314. 服務(wù)注冊信息描述 基于 AESB 的實現(xiàn)方案 由上所述，可見金蝶 AESB 具備上述企業(yè)服務(wù)總線所需要的技術(shù)能力，在本項目我們將采用 AESB搭建的 ESB 基礎(chǔ)平臺，建立 ESB 接口規(guī)范、開發(fā)規(guī)范和管理規(guī)范。 青海工程建設(shè)領(lǐng)域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 30 頁 共 117 頁 圖 312. 消息加密 服務(wù)的注冊和管理 AESB 服務(wù)注冊庫以 UDDI 標準為基礎(chǔ)，并在此之上加入了自身的擴展。 圖 311. 消息壓縮與解壓 ? 消息加密 AESB 支持在消息傳輸過程中對消息進行加密，保證消息傳輸?shù)陌踩浴６?wù)器在傳輸大尺寸對象消息時已經(jīng)內(nèi)置了對斷點續(xù)傳的支持。 因為普通消息在傳輸時實現(xiàn)了消息切分，所以能夠支持斷點續(xù)傳。 圖 310. 消息切分與組合 ? 斷點續(xù)傳 斷點續(xù)傳指的是在消息傳輸過程中，由于網(wǎng)絡(luò)原因?qū)е孪鬏斨袛啵斁W(wǎng)絡(luò)恢復時，不需要重新傳輸整個消息，而只是 從中斷的位置傳送即可。 青海工程建設(shè)領(lǐng)域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 29 頁 共 117 頁 ? 消息切分 AESB 支持將一個大的消息切分成多個小塊發(fā)送，在目的節(jié)點重新組合成完整的消息。 AMQ 提供智能路由功能，在選擇路徑時可根據(jù)路徑的長度等情況進行綜合考慮，以保障消息以最快速度傳送到目的地。 可靠消息傳輸 AESB 的底層消息傳輸，基于 AMQ，能夠提供可靠、穩(wěn)定、安全的消息傳輸。在上述的例子中，通過動態(tài)的元數(shù)據(jù)變更，將傳入數(shù)據(jù)的元數(shù)據(jù)屬性名稱分別修改成 ID 和 Name 即可。而 SDO 數(shù)據(jù)格式是帶有元數(shù)據(jù)的。 例如，某個服務(wù)的提供者提供了一個接口，接收一個描述人員信息的對象為參數(shù)，這個人員信息的描述如下： id 身份證號 Name 姓名 而服務(wù)的請求者，在發(fā)起請求的時候，傳遞的描述人員的信息如下： Shenfenzhenghao 身份證號 青海工程建設(shè)領(lǐng)域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 28 頁 共 117 頁 MINGCHENG 姓名 在數(shù)據(jù)被傳遞給服務(wù)的提供者時，必須經(jīng)過數(shù)據(jù)的轉(zhuǎn)換。 動態(tài)元數(shù)據(jù) AESB 通過 SDO 方式對服務(wù)所產(chǎn)生的數(shù)據(jù)進行包裝。當在復雜的業(yè)務(wù)場景下，需要通過腳本方式完成相應(yīng)功能時，通過 DSL 抽象和定制語法規(guī)則，以非常自然語言和業(yè)務(wù)化的方式定制腳本。否則 ,打印 0。 例如，在某些業(yè)務(wù)場景下，需要判斷某個閥值進行條件判斷，用 Java 代碼表述如下： If ( tag 100) { (―1‖)。 青海工程建設(shè)領(lǐng)域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 27 頁 共 117 頁 基于 DSL的腳本引擎 領(lǐng)域特定語言（ Domain Specification Language，以下簡稱 DSL）是指一種面向函數(shù)編程的理念。 SDO 數(shù)據(jù)模 型具備如下的三個優(yōu)點： ? 弱類型 ? 自描述 ? 操作可回朔 AESB 擴展了 SDO 規(guī)范，實現(xiàn)動態(tài)元數(shù)據(jù)支持的 SDO 模型。 SDO 是信息的容器，設(shè)計用于提升開放標準和互操作性。簡單來說， SDO 就是旨在提供這樣一種數(shù)據(jù)對象：它像橡皮泥一樣，可以根據(jù)實際的數(shù)據(jù)源決定它的實際表現(xiàn)。軟件 =服務(wù) +數(shù)據(jù)， SCA 更加關(guān)注業(yè)務(wù)邏輯，而 SDO 則更側(cè)重于業(yè)務(wù)數(shù)據(jù)。 AESB 可支持的技術(shù)模型有： ? JCA ? Web 服務(wù) ? JMS SDO 數(shù)據(jù)模型 SCA 中的一個關(guān)鍵推動因素是服務(wù)數(shù)據(jù)對象（ Service Data Object，以下簡稱 SDO）。 AESB 實現(xiàn)了 SCA 規(guī)范，并作為整體體 系中的一個重要的基礎(chǔ)引擎。對于構(gòu)件，青海工程建設(shè)領(lǐng)域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 26 頁 共 117 頁 不僅包括不同的編程語言，也包括這些語言使用的框架和環(huán)境。 SCA 模型中定義的構(gòu)件、合成服務(wù)、相關(guān)子系統(tǒng)和組成元素及其之間的關(guān)系，最終需要使用基于 XML 的部署文件進行描述和打包，并部署到 SCA 域中，這樣才能構(gòu)成完成具體業(yè)務(wù)和服務(wù)的運行環(huán)境。 Composite 是發(fā)布服務(wù)的構(gòu)件單元，它比 Component 多了接口、綁定及連接線的內(nèi)容。 合成服務(wù)（ Composite）用于組裝 SCA 元素到一個邏輯組中，在 SCA 域中，這是一個基本的合成單位。實現(xiàn)可以依賴另一個構(gòu)件的服務(wù)接口，稱為引用（ reference）。構(gòu)件組成一個實現(xiàn)的可配置實例，這個實現(xiàn)是一段代碼，可以提供業(yè)務(wù)功能。 圖 38. SCA 體系結(jié)構(gòu) SCA 組裝模型由一系列定義 SCA 域的配置的元件組成，包括服務(wù)構(gòu)件的組裝、連接關(guān)系及描述它們?nèi)绾芜B接的相關(guān)元件。這些合成的應(yīng)用可以包含新實現(xiàn)的服務(wù)，也可以包含已有系統(tǒng)提供的業(yè)務(wù)功能。 青海工程建設(shè)領(lǐng)域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 25 頁 共 117 頁 SCA 服務(wù)封裝體系 服務(wù)組件框架 （ Service Component Architecture，以下簡稱 SCA）提供了一種編程模型，可以支持基于 SOA 的應(yīng)用程序?qū)崿F(xiàn)。 事件驅(qū)動架構(gòu) 事件驅(qū)動架構(gòu)（ Event Driven Architecture，以下簡稱 EDA)中，通過一系列的構(gòu)件來為需要簡單的事件管理功能的大型應(yīng)用提供解決方案，它所能提供的功能包括事件生成、事件訂閱 /發(fā)布、事件處理、事件持久化和事件查詢等，用戶可通過簡單的配置方式，訂閱自己感興趣的 EDA 事件。 圖 37. SOA 中的服務(wù)地址透明和服務(wù)實現(xiàn)透明 通過服務(wù)地址透明和服務(wù)實現(xiàn)透明這兩大特性，可以保證服務(wù)請求者和服務(wù)提供者之間的松散耦合。 通過這樣的自治和聯(lián)邦的部署體系，對于一個大型的應(yīng)用集成平臺的搭建，帶來如下的優(yōu)勢： ? 可以分業(yè)務(wù)領(lǐng)域，分業(yè)務(wù)主體獨立實現(xiàn) ? 可以分部門、分級次的逐步實現(xiàn) ? 獨立主題共同形成整體聯(lián)邦 ? 實現(xiàn)統(tǒng)一、跨業(yè)務(wù)邊界、跨業(yè)務(wù)單元的集成 ? 避免一次投資過大 ? 提高平臺項目可控性 ? 降低整體平臺風險 青海工程建設(shè)領(lǐng)域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 24 頁 共 117 頁 服務(wù)地址透明 一個應(yīng)用的某個基于具體的中間件平臺和具體技術(shù)的功能接口，被接入到 AESB 平臺中， AESB 會將該功能接口以服務(wù)的方式進行封裝，并注冊到 AESB 服務(wù)注冊目錄。多個自治網(wǎng)絡(luò)一起，構(gòu)成一個 AESB 聯(lián)邦網(wǎng)絡(luò)。 多個這樣的智能網(wǎng)絡(luò)，可以通過用戶指定的策略和方式，在多個智能網(wǎng)絡(luò)中的 AESB 服務(wù)器之間，建立連接，實現(xiàn)多個 AESB 智能網(wǎng)絡(luò)的互聯(lián)互通。 聯(lián)邦和自治部署體系 AESB 可以以一個 AESB 服務(wù)器為中心，連接多個 AESB 接入代理（ Agent），組成一個 AESB 智能網(wǎng)絡(luò)。 事 務(wù)服務(wù) 進行全局事務(wù)管理。 通 訊服務(wù) 處理與客戶端的通訊，支持 HTTP、 HTTPS、 RMI／ IIOP 等通信協(xié)議。 AESB 微內(nèi)核基于 JMX 技術(shù)構(gòu)建，提供了基礎(chǔ)的線程、通訊、資源和事務(wù)服務(wù)，其他 擴展服務(wù)如安全服務(wù)、監(jiān)控服務(wù)、集群服務(wù)、 JDBC 服務(wù)、部署服務(wù)等可以通過可插拔的方式加入進來。微內(nèi)核就好比一個原先過度忙碌的商務(wù)經(jīng)理，通過將工作分給其他人，這位經(jīng)理可以將他的能力更有效地用于重要的商務(wù)工作中去，并集中于其他一些任務(wù)，例如開辟新的商務(wù)分支等。 AESB 的微內(nèi)核就是這種“內(nèi)核”的內(nèi)核，它是用來構(gòu)建 AESB 的基礎(chǔ)。 AESB 借鑒操作系統(tǒng)的這種精妙設(shè)計，將微內(nèi)核體系引入到產(chǎn)品實現(xiàn)中來。將通常與內(nèi)核集成在一起的系統(tǒng)服務(wù)層被分離出來，變成可以根據(jù)需求加入的選件，這樣就可提供更好的可擴展性和更加有效的應(yīng)用環(huán)境。 AESB 作為一個功能服務(wù)的請求者和服務(wù)功能提供者的橋梁，以松耦合的方式實現(xiàn)服務(wù)與服務(wù)之間的集成，實現(xiàn)服務(wù)的地址透明化和協(xié)議透明化。之上是 AESB 的幾個核心基礎(chǔ)引擎，以及為實現(xiàn)應(yīng)用接入而出廠定制支持的服務(wù)構(gòu)件。 AESB 產(chǎn)品特性 金蝶 Apusic Enterprise Service Bus （簡稱 AESB）具備面向服務(wù)、面向消息、事件驅(qū)動的特性，具備上述企業(yè)服務(wù)總線所需要的技術(shù)能力，是一個在 SOA 架構(gòu)中充當服務(wù)間智能化集成與管理中介的靈活敏捷的基礎(chǔ)平臺。它必須能夠統(tǒng)一服務(wù)測量標準并理解服務(wù)性能。通過利用動態(tài)連接， SRR 能夠使企業(yè)的 ESB 在請求到達時找到最適合的端點，從而支持動態(tài) SOA 與松耦合。它在整個監(jiān)管生命周期中通過用戶、用戶類型和服務(wù)發(fā)布地點來進行監(jiān)管。 監(jiān)管 SRR 需要在整個 SOA 產(chǎn)品的生命周期中進行管理，從開發(fā)、測試、生產(chǎn)直到結(jié)束。企業(yè)必須確保在考慮 SRR 的時候，不僅僅支持服務(wù)發(fā)現(xiàn)和服務(wù)重用，同時還支持在各個領(lǐng)域彼此關(guān)聯(lián)的服務(wù)，例如， 元數(shù)據(jù)管理。企業(yè)如果決定構(gòu)建 SRR，就應(yīng)該努力獲得以下這些能力： 發(fā) 布與查找服務(wù) 青海工程建設(shè)領(lǐng)域項目信息和信用信息公開平臺規(guī)劃建議書 金蝶中間件 第 20 頁 共 117 頁 SRR 需要具備在各部分發(fā)布與查找服務(wù)的能力，這種能力是重用的關(guān)鍵。為 了獲得 SOA收益，注冊中心和存儲庫都是必須的 —— 企業(yè)需要同時具備這兩種能力，才能實現(xiàn)所需的價值。 服務(wù)注冊中心能夠回答“什么是服務(wù)”以及“服務(wù)定位于何處”的問題。它使得業(yè)務(wù)、服務(wù)以及 SOA 基礎(chǔ)架構(gòu)元素之間的交互可以集中化管理，并統(tǒng)一了監(jiān)管服務(wù)供應(yīng)商、用戶和服務(wù)之間進行交互的標準和原則。一個應(yīng)用能夠在其調(diào)用服務(wù)之前核查 SRR，確定滿足功能和性能要求的最合適的服務(wù)。 SRR 是存儲已用、計劃使用或想要了解的系統(tǒng) (或其他機構(gòu)系統(tǒng) )中的服務(wù)信息的地方。要實現(xiàn)服務(wù)的重用，就必須對服務(wù)進行管理。位置和 傳輸協(xié)議透明是 SOA 與傳統(tǒng)的面向接口的 IT 架構(gòu)的區(qū)別之一。一旦服務(wù)組件的傳輸協(xié)議改變，客戶端也必須修改相應(yīng)的傳輸協(xié)議。 同理，目前已有的遺留系統(tǒng)的服務(wù)組件如 EJB、 Web Service、 JMS 都只能接收特殊的傳輸協(xié)議，如EJB 只能接收 RMI 的傳輸協(xié)議， Web Service 只能接收 SOAP 的傳輸協(xié)議， JMS 組件只接收 JMS 的傳輸協(xié)議。如果某個服務(wù)組件的 URL 位置改變了，那么客戶端程序必須要做相應(yīng)的修改，否則整個集成就不能工作了。 協(xié)議轉(zhuǎn)換 已有的遺留系統(tǒng)的服務(wù)組件如 EJB、 Web Service、 JMS 的發(fā)布都是和特定的應(yīng)用服務(wù)器綁定在一起的。 ? 不同種類的框架之間的互操作性：源應(yīng)用程序和目標應(yīng)用程序可在不同種類的環(huán)境中運行而不必處理有關(guān)它們相應(yīng)的框架的通信和執(zhí)行問題。這使源系統(tǒng)和目標系統(tǒng)能夠同時運行而不必等待對方。相同的信息可被并行地傳遞給許多訂戶?？梢允褂? JMS 來訪問分布于不同種類的系統(tǒng)中的業(yè)務(wù)邏輯。 Web 服務(wù)被定義為請求者與提供者之間的必需的業(yè)務(wù)接口而不是所有業(yè)務(wù)請求的共同管道。請求者從代理那里了解它必須從提供者那里收發(fā)的信 息結(jié)構(gòu)以及訪問該服務(wù)所用的協(xié)議。 SOA 有松耦合的三方：提供者、代理和請求