做大型企業內部業務系統整合的應該都知道，Oracle SOA套件當前是應用廣泛的一個商業整合產品套件，其中包括了OSB服務匯流排， BPEL業務流程引擎，BPM業務流程管理，ODI大資料服務整合，MFT檔案傳輸平臺，基本覆蓋了業務整合和資料整合的各方面。

今天整體下Oracle OSB服務匯流排的技術原來和採用OSB進行服務註冊接入的方法流程。

OSB產品基本功能概述

訊息交換匯流排技術是為了實現企業資料共享和應用整合，提供一種基於企業服務匯流排(ESB)的資訊共享交換平臺。該技術採用面向服務體系結構(SOA)的設計思想，以資訊共享為目標，具有鬆散耦合的特點，實現了"集中式管理、分散式執行"的工作模式。透過設計標準的介面卡元件，實現各種資料庫和應用系統之間的資料共享與交換，能有效實現企業中資訊共享，並具有良好的可擴充套件性和可靠性。

Oracle的OSB匯流排包括ESB（Enterprise Service Bus）和 WSM（Web Service Management）兩大部分，是ORACLE公司的訊息交換匯流排產品。

ESB包括MOM, ORBs, RPCs, WebServices功能的新型、綜合類型中介軟體，透過配置整合；WSM包括服務管理，訊息跟蹤兩個部分。使用OSB可以很容易的將企業已有的對外功能整合進來，並且能夠整合和開發出來新的功能。

ESB服務匯流排的核心功能再做簡單總結：

服務代理和位置透明

協議轉換和遺留系統適配接入

協議轉換是ESB的一個重要功能，其中包括了HTTP，TCP，FTP，JMS，EJB，MQ，FILE，SMTP等多種協議之間轉換和適配能力。比如你可以接收一個SOAP WS服務呼叫請求，並將接收到訊息寫入到JMS；或者說你也可以透過JCA適配到某一個數據庫，將資料庫表釋出為一個Http Rest查詢服務介面。

訊息格式和內容轉換

這個一定要和協議轉換分開來談，支援多種訊息格式和型別往往就是指的可以透過transform和資料對映功能將XML，JSON，Flat File，MFL等多種訊息格式型別之間進行資料對映和轉換。舉例來說，你可以服務呼叫的輸入都是Http Rest服務介面，但是輸入可以是Json格式，而輸出可以轉換為XML文字輸出。

服務路由（包括靜態路由和動態路由）

路由是ESB中非常重要的仲裁邏輯之一。路由場景是非常普遍的。譬如，針對不同的客戶提供不同QoS的場景，執行時需根據客戶的型別將其路由到不同執行能力的服務提供者；再比如當響應訊息到達ESB時，總是需要將該響應訊息送回最初的服務請求者處。

路由可分為靜態路由和動態路由。靜態路由指得是設計時已經明確路由分支的情況，而動態路由的路由分支選擇是在執行時動態確定的。不論是靜態路由還是動態路由，路由分支的選擇一定伴隨著一個或一系列決策依據。決策依據可簡單如一個If-Else語句，也可以複雜到需要透過多維決策表並透過多次判斷才能得到最後的路由分支。

資料對映轉換（Transform）& 內容豐富(Service Enrichment)

資料對映轉換是ESB的另外一個核心功能，舉個例子來說我們根據一個標準的WSDL契約要求定義一個代理服務，而對於業務服務則是適配和連線到一個數據庫表並返回一個結果集，那麼這個WSDL結構就需要和資料庫返回結果集的業務服務間進行資料對映和轉換。

一般而言，大多數ESB產品都提供了多種資料轉換的方式，很多產商宣傳中力推的都是“拖拽式”視覺化對映的轉換方式。該功能聽起來的確很酷，看上去很直觀。但是正如我們前面所說的，ESB是一個偏向技術層整合的元件，業務人員一般不會關心XML是如何轉換成SOAP的。所以，對於開發者來說，這種“炫”功能並無太大吸引力。更重要的是，他們可能非常習慣於自己的程式語言，如Java、XSLT、ESQL和PHP等，這些語言操作起來要簡單很多。

在OSB 12C增加了視覺化的XSLT資料對映功能，XSLT是一個標準的XML轉換語言，使用XSLT實現的轉換邏輯可很輕易地在不同ESB產品間移植。幾乎所有主流商業ESB產品都支援XSLT的轉換機制。

對於內容豐富來說，舉例來說當接收到消費者的服務呼叫請求後，我們需要對輸入訊息內容進行補填再去呼叫原始的業務服務，也可能是OSB接收到Response返回訊息後，我們會進一步補充例項ID，服務狀態等資訊後再返回給服務消費方，這些都屬於內容豐富的範疇。

OSB訊息處理機制和執行原理

OSB中的服務包括代理服務（Proxy Service）和業務服務（Business Service）兩種。

業務服務一般用作將外部已有服務接入到OSB總線上，代理服務的作用是將已有服務進行重新包裝和整合，進行服務路由、邏輯處理之後對外發布新的服務。

在OSB訊息流中，一般都是透過Proxy Service對外發布服務的，客戶端透過呼叫在Proxy Service中定義好的URL來呼叫OSB總線上的服務。

當客戶端呼叫Proxy Service的時候，訊息先經過Proxy Service傳輸層（Transport）進入，傳輸層是有協議的，他可以解析和接入各種傳輸協議；然後透過繫結層（Binding）對傳輸層接入的訊息及協議進行解析 ，對訊息內容進行解析並且存放到上下文變數中，經過繫結層解析後的訊息格式一般是透過SOAP格式進行包裝並且附在以後的整個訊息流傳輸過程中，以後的處理節點就透過訪問上下文變數來檢視、獲取、編輯訊息內容和訊息結構。

OSB核心經過Pipeline管道來進行訊息路由，轉換，對映，異常處理等一系列操作，如下圖：

裡面的幾個關鍵元件為：

Pipeline表示一個訊息流轉中批次的處理邏輯Stage可以被認為是一組動作處理的容器Action是訊息流中的邏輯，它用於具體決定如何處理訊息Branch節點可以讓流程處理進入具體多個可能的處理路徑中的一個

在OSB訊息流開發過程中，對於各種功能節點都可以使用XQUERY或者XPATH語言對節點屬性、處理流程進行配置；而對於訊息流的流程控制語句也是使用XQUERY來實現的。對XQUERY和XPATH有個基本的瞭解是能夠進行訊息流深入開發的重要基礎。

XPATH是標準的XML表示式語言，用於標識或定位XML文件中的某一部分，對於很多訊息處理節點中的配置引數，都需要使用XPATH語言來表述，如對於DELETE（作用是刪除訊息中的某個元素或者屬性）處理節點，就需要使用XPATH語言來描述刪除目標元素。XQUERY是一種用於XML文件的結構化語言，用來描述迴圈和判斷、函式處理、流程處理和控制、構造SOAP訊息、處理訊息結構和內容等處理命令的一種語言。

在OSB上，一般比較複雜的處理邏輯都需要這兩種語言來實現。

OSB中對訊息結構/內容進行轉換一般透過XQUERY語言來實現，可以在WORKSHOP中使用視覺化介面進行拖拽操作來實現訊息格式轉換，然後將生成的xq檔案上傳到控制檯即可。

OSB中的其它關鍵術語進一步解釋和說明

業務服務(Business Service)

Business Service是在OSB中所定義的，用於表示希望與後端交換資訊的企業服務。簡單來說業務服務實際就是需要接入到ESB匯流排的後端原始服務。

代理服務(Proxy Service)

業務服務接入到OSB後，OSB需要封裝一遍然後再發布出去，最終釋出出去的服務即代理服務。簡單來說業務服務對消費方透明，消費方只能夠訪問代理服務，然後由OSB路由到具體的原始業務服務上面。

端點(Endpoint)

一個基於資源定位標誌符的地址。Business Service的端點是接入的外部服務的資源地址；而Proxy Service是對外發布的新服務的資源地址。注意WSDL地址和端點地址不同，在訪問到WSDL後，端點地址在WSDL的Port部分可以看到具體location。

訊息流(Message Flow)

訊息流定義了代理服務的實現。訊息流可以包括管道對和下列節點：開始、路由和分支。訊息路由、業務邏輯處理、服務編排、服務整合等操作都是在訊息流中實現，在OSB開發中，主要工作就是訊息流的開發和除錯。

管道對(Pipeline Pair)

透過“編輯訊息流”也可以新增管道對節點。管道對節點包含一個請求管道和一個響應管道。訊息流可以不包含管道對節點，也可以包含多個管道對節點：代理服務（或對服務的操作）的請求和響應管道，以及可為階段、管道和代理服務定義的錯誤處理程式管道。管道可以包括一個或多個階段，階段又可以包括操作。

階段（Stage ）

階段是操作的容器，如訊息路由、日誌記錄、訊息廣播、訊息傳送等操作都可以放到階段中操作。

動作（Action ）

動作是使用者定義的執行時的邏輯步驟，使用者需要實現的功能一般透過新增動作節點來實現，OSB已經提供了很多不同型別功能各異的預設節點，方便使用者進行訊息流開發。

路由節點（Route Node ）

路由節點是在管道對中的請求和返回之間的交換節點，主要是用於呼叫業務服務。用於定義訊息目標的容器也可以用於執行單向通訊，例如使用檔案或email作為代理服務中請求處理和應答處理的分界點當Route節點分發了請求訊息後，請求處理就認為結束，而當Route節點收到應答訊息時，表明應答處理的開始。

路由節點一般出現在管道對之後，處於管道對中的請求和應答之間。

上下文變數（Context Variables）

上下文變數是訊息進入OSB匯流排之後的儲存載體。在訊息透過傳輸層之後，繫結層會自動根據訊息協議和訊息內容，將其繫結到上下文變數中；當訊息要輸出OSB之前，OSB會根據需要自動將上下文變數中的訊息內容轉換成為符合輸出協議型別的訊息格式。

功能架構和關鍵技術原理

從OSB的功能架構圖可以看到，實際的OSB架構包括了訊息適配，統一安全管理，配置框架，服務虛擬化，服務管理幾個部分的內容。而對於實際的服務封裝（代理服務，業務服務，管道）都在服務虛擬化部分裡面，功能圖上只是列出了基於內容動態路由，訊息轉換和服務訊息鏈等幾個關鍵點。

對於OSB服務匯流排，基本支援業界常見的各種訊息服務接入。

Web Service Transports• HTTP/SOAP, REST, WS-I, WS-Security,WS-Policy, WS-Addressing• SOAP v1.2 and v1.1傳統的訊息• HTTP, JMS, AQ, MQ Native transport,EJB/RMI, Tuxedo, FTP, SMTP, File• EJB/RMI on WebSphereTransport SDK• Enterprise-specific custom transportsJCA Adpaters• Build-in Oracle EBS, Database• PeopleSoft, Siebel, JD Edwards,SAP

協同工作能力

• .NET, Tibco EMS, IBM WebSphere, Apache Axis, Cyclone B2B Interchange, iWay 5.5 adapters

統一安全管理

對於服務安全管理，最常說的就是服務的傳輸安全，訊息安全，訪問控制安全，資料安全等標準內容。而對於功能架構圖裡面主要是在強調認證、授權、身份驗證,簽名/加密幾個方面的內容。而對於OSB的安全管理體系，個人認為重點仍然要放在OWSM和安全策略上面。

OWSM是用於安全、管理和治理的策略建立的執行時框架。您可以建立策略，將它們附加到服務匯流排中的服務，並在訊息傳遞生命週期中與OWSM代理一起執行這些策略。Oracle Web服務管理器(OWSM)是服務匯流排使用的Web服務安全機制。所有新建立的資源，如業務服務和代理服務，都使用OWSM策略來保證安全性。WLS 9策略被棄用，不能用於為新的服務匯流排資源配置安全性。

服務虛擬化(Service Virtualization)

強大的服務組裝能力基本全部體現在服務虛擬化部分，即實際的服務開發和封裝，服務路由和轉換等基本都是服務虛擬化的內容，包括我們實際在OSB操作中的業務服務和代理服務的建立，訊息流的繪製（管道建立，驗證，路由，Split/Join）等操作。

具體的服務虛擬化和OSB強大的服務組裝能力基本可以參考下圖：

OSB支援的協議(Protocols)和訊息格式

這是11g裡面的一頁PPT，對於OSB支援的協議和訊息格式相對來說是相對完整，包括了對TCP(Socket)等協議的支援能力。同時對於訊息格式包括了對Json，MFL，FlatFile等各種訊息格式。

Proxy訊息處理機制

這裡面需要深入瞭解，即整個訊息處理和執行機制是如何的，具體如下：

1. 傳輸層Transport Layer（接收訊息）2. 繫結層Binding Layer (解包訊息，得到真正的訊息體）3. 代理服務Proxy Service(訊息處理邏輯）4. 繫結層Binding Layer (打包訊息，得到真正的訊息體）5. 傳輸層Transport Layer（返回和傳送訊息）

Business Service是在OSB中所定義的，用於表示希望與後端交換資訊的企業服務，理解這點相當重要。因為你既可以把外部已有的業務系統提供的WS引入並對映為一個業務服務，也可以在透過JCA等適配後將外部的業務系統能力釋出為一個業務服務。

訊息流的繪製和處理(Message Flow)

對於訊息流的繪製重點還是在管道Pipeline上，而管道核心是包括了Request請求處理，呼叫Business Service服務，Response返回三個部分的內容。管道真正將以上三個部分銜接為一個整體，也是OSB的輕量服務能力編排的重要體現。

透過管道就可以實現訊息路由，驗證和校驗，異常處理，Split/Join等操作。

訊息格式和內容轉換（Transformation）

XML to XML (XQuery or XSLT)XML to Text/Binary (XQuery)Binary to Binary (MFL)

而實際上當前我們使用最多的仍然是XQuery+XSLT進行訊息轉換。在11g的時候更多的是使用XQuery+XPath程式碼的方式進行轉換和對映，而在12c版本已經增加了XSLT的視覺化資料對映能力，這是訊息轉換這塊相對大的一個能力提升。

透過OSB進行代理服務接入

今天詳細講解下在osb console控制檯進行最簡單的代理服務封裝。在前面幾篇文章裡面已經談到過，osb console代理服務的封裝基本延續建立專案，匯入資源，建立代理服務和業務服務，繪製管道和訊息流幾個關鍵步驟，今天基於這個步驟做一個講解。

在進入到osb console控制檯後，首先透過右鍵選單建立一個新專案，在OSBProject可以看到一個完整的已經設計封裝完成的代理服務專案的目錄和資源結構，具體如下：

我們首先透過右鍵選單建立一個TestProj_Heminglu的新專案出來，然後在這個新專案下建立BusinessServices，ProxyServices，Resources三個子資料夾來分別存放代理服務，業務服務和資原始檔資訊。在將詳細建立過程前，我們先介紹下，在osb console控制檯點選右鍵選單後建立->資源後可以建立的服務和資源型別資訊。

第一個tab是服務，在服務tab裡面可以看到，可以建立代理服務，業務服務和管道。

代理服務：代理服務是在 Service Bus 上本地託管的通用中介 Web 服務的 Service Bus 定義。代理服務透過介面 (不一定等同於服務提供程式或服務使用者業務服務的介面) 與外部服務進行通訊。

業務服務：業務服務是在業務處理期間交換訊息的企業服務的 Service Bus 定義。業務服務的配置包括其介面 (服務型別), 其用於與服務生成器連線的傳輸型別和配置, 安全要求, 訊息處理, 效能最佳化和 SLA 預警規則。

第二個Tab是介面，更多的是介面契約，裡面包括了WSDL，WADL，方案，WS策略等。其中WSDL是常說的基於SOAP WS的服務介面契約，而WADL則是基於REST服務介面的服務契約。

Web 服務策略框架 (WS-Policy) 是一個基於 XML 的可擴充套件框架, 它使用特定的安全擴充套件 Web 服務的配置, 並指定 Web 服務的安全要求, 期望和功能。在 Service Bus 中, WS-Policy 的主要用途之一是在代理服務和業務服務中配置訊息級安全性。

JCA 繫結資源允許您建立透過 Oracle SOA Suite JCA 介面卡與外部服務互動的業務服務和代理服務。JCA 繫結由服務 WSDL 文件和在 Oracle JDeveloper 中建立的相應 JCA 檔案組成。在 Oracle Service Bus 控制檯中, 需要將 JCA 檔案上載到 JCA 繫結資源中才能基於該 JCA 介面卡建立業務服務或代理服務。即JCA繫結主要用於資料庫適配方面使用。

第三個Tab是轉換方面的，裡面包括了Xquery和XSLT和MFL，其中Xquery和XSLT主要用於WS服務介面，XML間的資料對映和轉換。MFL主要用於二進位制訊息流的資料對映和轉換。

XQuery 資源允許您定義用於在 XML, 非 XML 和 Java 資料型別之間轉換資料的對映, 以便快速整合異構應用程式。XQuery 資源還可以包含 XQuery 程式碼段, 以便使用 XPath 查詢 XML 文件並獲取資料。

可擴充套件樣式表語言轉換 (XSLT) 對映描述 XML 到 XML 的對映。使用“建立 XSLT 文件”對話方塊可以為 Service Bus 專案建立新的 XSLT 轉換。

MFL資源：Oracle JDeveloper 中提供的 Oracle Format Builder 允許您定義非 XML 資料記錄的訊息結構。定義二進位制記錄的層次, 欄位的佈局以及欄位和組的分組時, 該資訊將另存為訊息格式語言 (MFL) 文件, 之後可以使用該文件執行執行時轉換。使用 Format Builder 建立 MFL 文件後, 便可以透過建立 MFL 資源並將檔案上載到該資源將檔案匯入到 Oracle Service Bus 中。

剩餘的安全和其它兩個Tab不再做進一步介紹，可以建立的基礎資源介紹完成後，還是回到剛才代理服務的介紹，我們採用查詢天氣一個wsdl服務地址進行封裝，將其釋出為一個代理服務。

1. 匯入WSDL資原始檔

比如本地的查詢天氣的業務服務地址為：

http://youripaddress/globalweather.asmx?WSDL

訪問到該WSDL地址和檔案後，透過網頁另存為，將其儲存為一個本地檔案globalweather.wsdl檔案。建立一個Resource的資原始檔夾，然後右鍵資料夾，點選建立資源->介面->wsdl建立資源，資源名為globalweather.wsdl，然後點選檔案上載按鈕上傳上步儲存到本地的wsdl檔案。

2. 建立代理服務

SOAP型別化/無型別 REST嚮導中的型別化 REST (帶 WADL)

在這裡我們使用SOAP WS代理服務，對於Rest服務介面後續再做進一步詳細介紹。代理服務資源名我們定義為GetWeatherInfoSrv_Proxy，對於服務定義為基於WSDl的服務，透過選擇按鈕，搜尋，然後選中到剛才定義和匯入的WSDL資原始檔。選後對於埠/繫結，我們選擇SOAP 1.1的版本保留相容性。

對於管道部分checkbox預設選中，這樣在代理服務建立完成後會自動建立管道。具體配置完成後的參考介面如下，可以看到配置的詳細資訊。

代理服務的建立嚮導最後一步涉及到端點地址，這個端點URI是可以任意配置的，用於和外部介面互動服務消費者使用的服務介面端點地址。你可以修改這端點地址，比如模式端點地址為：

/TestProj_Heminglu/ProxyServices/GetWeatherInfoSrv_Proxy

你也可以將前面的專案路徑部分去掉，僅僅保留

/ProxyServices/GetWeatherInfoSrv_Proxy

3. 建立業務服務

注意我們訪問 http://www.webservicex.net/globalweather.asmx?WSDL 這個地址的時候，在這個檔案裡面可以看到該WS服務的提供的具體端點地址資訊，即

soap:address location="http://www.webservicex.net/globalweather.asmx"

我們實際呼叫的外部服務的端點地址資訊在建立業務服的時候要使用到。

傳輸部分注意端點地址的配置，該端點地址即為外部實際的端點地址。負載均衡演算法暫時預設不用修改。

4. 管道和訊息流繪製

在代理服務，業務服務和資原始檔全部建立和配置好，剩下的工作就是開啟管道進行訊息流的實際繪製，簡單來說就是將代理服務和業務服務銜接到一起來。中間涉及到路由，分支或異常處理等。

在開啟訊息流繪製介面後，選擇到管道節點，可以看到出現的選單中可以新增管道對，新增路由，新增條件分支等各種選擇。透過新增這些內容進行訊息流繪製。在這個案例中我們首先要新增路由，即將Proxy代理服務路由到實際提供業務能力的外部業務服務上。

實際我們要做的事情具體如下：

1. 選擇到管道節點後，在選單中選擇新增路由，增加一個路由節點RouteNode1。2. 選擇到RouteNode1節點，在出現的選單中點選編輯路由。3. 點選編輯路由後，按如下進行選單和按鈕點選新增操作-》通訊-》路由，進入到路由編輯介面。4. 在出現的編輯裡面種有一個路由到服務，選擇服務超連結，進入到服務選擇介面5. 在服務選擇介面中選擇我們剛才建立好的業務服務資訊。

在編輯路由介面注意，我們還可以在輸入和輸出增加額外的操作，比如增加日誌記錄節點等，如下：

5. 服務測試和驗證