今天繼續整理下Oracle SOA 12c套件中，涉及到OSB服務匯流排部分的關鍵技術特性。在講OSB部分關鍵技術特性前，先整理下SOA 12c的一些新特性說明。

Oracle SOA 12c新特性說明

對於Oracle SOA產品套件SOA 12c版本，是Oracle本身iPaaS雲平臺戰略的核心組成部分。特別是12c版本擴充套件了雲端整合， 移動應用整合和物聯網IoT整合三方面的重要能力。

新發布的版本中包括簡化和縮短新整合開發時間以及大幅提高響應速度的特性。開發人員現在可以利用端到端的 JSON 支援提高效能，並可在整合流程中直接使用 JavaScript。新的記憶體中特性極大改善了事務效能，新的 B2B 最佳化進一步提升了事務處理速度，便於合作伙伴協作。在流分析領域，Oracle Stream Explorer 提供了簡化的業務友好的方法以及先進的機器學習能力。

為了視覺化整合流程可以訪問的分析，還向 Oracle SOA Suite 的 Business Activity Monitoring 功能添加了新的自定義功能，以便更好地協調分析和客戶特定的關鍵績效指標。該整合平臺還引入了一些新特性，可以最大程度提高正常執行時間，診斷和調優整合環境，並使 SOA 部署能更好地應對異常和過載。

對於雲，移動移動，IOT三方面的核心能力增強可以描述為：

Cloud Integration - Rapidly integrate a growing list of cloud applications with existing applicationsMobile Integration - Mobile enable enterprise applications and servicesIoT Integration - Connect Internet of Things (IoT) devices to existing systems

今天不打算對以上內容做詳細介紹，主要還是想從企業資訊化內部服務匯流排平臺和SOA架構體系搭建過程中，採用Oracle SOA 12c帶來的新特效能力提升。

1. 擴充套件了多Http Rest API 介面，Json資料格式和Open API服務接入能力的惡支援。這個不僅僅是移動和IOT應用，在企業內部資訊系統整合也可以採用，同時增加了Http Rest介面和傳統SOAP WebService介面間的介面協議轉化能力，XML和JSON資料格式的轉化能力。

2. 整個開發環境仍然是基於Jdeveloper，但是整個宣告書，嚮導式開發更加完善，在這塊11g服務設計開發方法在大步驟上沒有太大變化，存在的是一些細節上的易用性調整。

3. 在OSB設計上有一個重大的變化就是，元件中增加了資源類別包括了Pipeline和Spit-Join，對於這塊的能力原來是整合在Proxy Service裡面的，現在單獨剝離出來可以複用。

3.提升CEP複雜事件處理視覺化設計能力，訊息處理，EDN事件網路的視覺化設計能力明顯增強。

4.服務複用能力提升：SOA最大的一個作用就是服務共享和服務複用，因此在12c裡面可以看到對於OSB和BPEL都增加了複用重用方面的能力。對於OSB設計增加了服務模版和基於模組開始新設計的能力，對於BPEL則進一步增加和完善了可複用的SubProcess子流程的設計和定義。

5. 除錯和測試能力的增強，可以靈活的設定斷點對服務設計結果進行Debug，並實時觀察每個節點輸出。與JavaIDE中的偵錯程式相同，SOA偵錯程式提供了諸如stepping into，out，over等，同時提供了變數檢視器，也能實時修改變數值。

6. 各種對商用軟體的介面卡能力的增強，如SAP R3，JDEwards，MSMQ，也包括雲端SaaS應用的整合和適配，如Saleforce整合和適配等。

7. 資料對映和適配能力的增強，包括Xquery Mapper，XSLT Mapper等。

8. 管控治理能力的提升，包括儀表盤，管理和監控，效能最佳化，服務執行例項檢視等。提供統一的檢視，對整合進行監控和管理，端到端的例項跟蹤，一站式的系統和業務管理方案。

9.效能增強，Oracle SOA 12c引入了一個全新的特性稱之為“構件延遲載入“。這是一個很棒的特性，允許資原始檔或元件在第一次使用時才被真正載入，這能夠極大提升伺服器的啟動速度特別是當SOA域中部署了大量服務構件的時候。

10.大檔案傳輸能力增強，在Oracle SOA 12c中增加了Oracle MFT檔案傳輸模組，可以實現對大檔案多執行緒，併發傳輸，同時實現檔案傳輸整個過程的視覺化排程和任務管理能力。

11.雲端整合能力增強，Oracle SOA 12c致力於簡化、加速並最佳化與各種雲端應用的整合，不僅會提供基於標準化的整合平臺用於連線，更提供了強大的一整套解決方案用於解決審計、合規、安全和治理等。

服務快取

對於一個用Java開發的Soap WebSerivice服務介面，我將這個WS服務透過OSB代理服務接入到OSB服務匯流排，但是在使用壓力測試工具進行測試的時候，發現了一個奇怪的現象，即對OSB封裝後的服務進行壓測的效能還好於對原生服務進行壓力測試的效能，而這裡面的一個關鍵就是OSB本身的服務快取策略起作用了。

Oracle OSB結果快取的工作原理

具體的配置也很簡單，即我們在透過OSB封裝服務的時候，在建立完成Business Service業務服務後，在業務服務的高階設定和選項裡面有一項就是Result Caching，我們把這項勾選為Supported就可以啟用服務結果集快取了。在快取的設定中還有兩個重要的專案，即：

快取標記ID - 我們是以哪個ID作為快取專案唯一標記。快取過期時間設定 - 快取的過期時間設定

透過以上步驟後，我們即完成了一個OSB服務的快取設定。當我們在進行壓力測試的時候，就會發現呼叫OSB上封裝後的服務效能遠好於對原生服務的呼叫。比如我們呼叫一個供應商查詢資訊服務，當指定了0001作為ID進行查詢後，在快取生效週期裡面再有其它訪問請求使用0001去查詢供應商，則可以直接從快取返回。

快取項的監控和快取資料瀏覽

Oracle Coherence 為有關快取伺服器的 JMX 和報表提供了很好的 API，這是監視巨大負載生產環境的必經之路。但對於開發環境和其他重要監視情形，可以使用 Coherence Console。

Coherence Console 是 Coherence 自帶的一個命令列實用程式，可連線到特定的 Coherence 伺服器。這是一個很好的工具，可以檢查哪些伺服器參與了叢集，還可以瀏覽快取資料。

啟用程序外獨立快取伺服器

現在，我們已經啟用了服務快取，因此具有更好的吞吐效能，並且可以在系統中應對更多使用者。但要記住，我們仍在使用程序內策略，這意味著我們將相同的 JVM 記憶體用於快取項、WebLogic 服務（如 JDBC 或 JMS），以及 Oracle Service Bus 物件（如轉換、代理服務和業務服務）。

如果將快取使用提升至一個很高的量，可能很容易出現記憶體耗盡的情況，這就會犧牲掉 Enterprise Service Bus 中的所有其他服務，甚至是未使用快取功能的服務。

要解決這一問題，可以使用外部 Coherence 伺服器，即擁有自己的 Coherence 伺服器的專用 JVM。該解決方案可以提高整體架構的可伸縮性，支援更復雜的 Coherence 叢集基礎架構。Coherence 叢集配置不在本文討論範圍之內，但本文對於可以針對自己的情形能實現哪些目標以及進行哪些調整提供了思路。

服務流量控制

首先還是說下最簡單的場景，假設有A和B兩個業務服務，如果A的優先順序高於B的優先順序，那麼在實際的業務呼叫過程中往往就存在如下場景。

1. 在資源出現瓶頸的情況下，由於B的併發呼叫量大導致B的TPS高，而A的服務響應反而慢。2. 在資源沒有瓶頸的情況下，由於B訪問量的增加導致了A的實際響應速度變慢

不管是哪種場景都可以看到，在實際OSB處理業務或資源受限的情況下，其中包括了OSB本身的計算和JVM記憶體資源，也包括了實際的網路頻寬資源。如何最大限度地保證高優先順序的服務的快速響應？或者說如何在併發量增加的時候，為了保證平臺的正常穩定執行，如何對低優先順序的服務進行限流直至熔斷。

傳統廠商的產品中也可以設定處理的優先順序，但是以訊息優先順序居多，透過控制訊息的處理頻率和密度，間接實現對處理資源的使用。Oracle OSB除了設定訊息的優先順序之外，更加重要的是可以調控不同SLA等級的服務請求在OSB上所佔用的CPU和記憶體資源比例，真正實現了處理資源的分配和管理。

Oracle SOA套件中的OSB產品在前端接入和後端呼叫業務系統兩個層面提供流量控制的能力，在配置前端接入的ProxyService和後端業務系統呼叫的BusinessService時可以指定相應的DispatchPolicy實現流量控制。OSB底層透過使用WebLogic中的Work Manager為流量控制提供最大並行執行數量、最大排隊等待的請求數量、以及在所有請求超過系統處理能力的情況下按比例分配OSB的執行資源。具體核心步驟為:

1. 首先要建立WorkManager工作管理器元件，並進行流量控制策略標準定義。2. 在進行服務設計的時候，在ProxyService或BusinessService的分派策略定義中選擇第1步定義策略。

具體關鍵引數設定說明如下：

1）請求類-資源佔比策略2）最小執行緒數約束：為解決死鎖問題而分配的最小執行緒數3）最大執行緒約束：可以分配用來執行請求的最大併發執行緒數4）容量約束：開始拒絕服務呼叫請求前可以排隊或執行的請求總數5）阻塞執行緒操作：如何檢測阻塞執行緒，已經發生問題後需要執行的操作

從上面引數設定也可以看到OSB更多的是基於服務請求併發，SLA等級和資源分配三者進行流量控制，有效的保障服務和OSB平臺的可靠性，提升高優先順序服務的響應效率。但是實際上對於資源的佔用，一方面是服務併發請求和訪問量大會大量的佔用資源，同時服務請求的訊息體容量大也會大量的佔用資源，對於第二種情況當前在OSB上是服務馬上靈活配置的。

JMS訊息管理

WebLogic JMS是整合在WebLogic Server中的企業級訊息系統。WebLogic Server符合JAVA規範,並透過Sun Microsystems J2EE 認證。作為WebLogic的一部分,當然WebLogic JMS Server也完全遵從JMS規範,還支援叢集,並可以應用於實際企業系統。

上圖中可以看到WebLogic JMS Server主要元件有: WebLogic JMS servers(用於訊息通訊),, 後備儲存(用於持久訊息儲存,基於檔案或者JDBC資料庫)。

對於WebLogic JMS Server 主要具備如下突出優勢：

極大提高的效能訊息儲存持久化分散式DestinationUnit of Order自動的透明客戶端重連線儲存轉發SAF

在WLS中，訊息服務由JMS Server實現，JMS實現對訊息的接收和傳送。在Weblogic 中建立JMS Server的介面參考如下：

持久化訊息訂閱

持久化訂閱是Weblogic JMS的另外一個重要功能，它可以確保即使訊息接收者有時處於離線狀態，也能正確的接收到訊息。

對於訊息訂閱者是否線上是根據其Java物件是否存在來判斷的，在預設情況下，訊息訂閱者不是持久化的，但是管理員可以配置訊息是否持久化，以及持久化到哪裡。

對於訊息持久化的應用場景主要是 應用開發需要用到持久化訂閱，或者說需要保證訊息訂閱方伺服器重啟的情況下也不造成任何的訊息丟失。

訊息持久化的工作機制如下圖，即如果訊息訂閱客戶端是活動狀態的，訊息會正常釋出；如果訊息訂閱客戶端是離線的，當其再次處於活動狀態時，使用其ID來重新獲取和釋出訊息。

介面卡

技術類介面卡

技術介面卡是最流行、最常用的與多個企業和自行開發應用整合的機制之一，投資最少，極易使用和維護。這些類別的介面卡可實現與檔案/FTP、資料庫、JMS 目標、套接字等資料來源的雙向整合。

對於FTP類介面卡當前更多是實現採集檔案資料到目標，或者將源資料輸出到檔案，而並不是實現端到端的檔案傳輸式整合，因此Oracle SOA 12c套件新增加了Oracle MFT檔案傳輸管理來專門實現對於檔案傳輸的整合。對於資料庫整合，重點也是透過資料庫適配後查詢資料庫資料或將輸入寫入到資料庫表中，同時還支援對於儲存過程的適配能力，這在老的版本中就已經支援。

對於大資料整合，在前面已經講過，Oracle專門提供了ODI解決方式來實現大資料整合，ODI解決方案可以理解為ETL+WebService服務能力的整合，既實現的服務的管理監控和鑑權，又實現了大資料量下的高效資料整合和傳輸。

對於訊息整合，當前的訊息中介軟體實現包括了基於JMS標準和基於AMQP兩種標準的，對於JMS標準的即實現都對Weblogic JMS,Oracle AQ和ActiveMQ等訊息中介軟體的整合。而對於AMQP的則類似於RabbitMQ和Kafka，對於AMQP整合是否支援暫時還沒有進一步研究。

在新版本中，SOA Suite 介面卡可實現與 Microsoft MQ、Coherence Data Grid 和 LDAP V3 Directory 伺服器的整合。

Oracle JCA Adapter for FilesOracle JCA Adapter for FTPOracle JCA Adapter for JMSOracle JCA Adapter for DatabaseOracle JCA Adapter for AQ（Oracle 高階佇列）Oracle JCA Adapter for MQOracle JCA Adapter for SocketOracle JCA Adapter for MSMQ New!Oracle JCA Adapter for Coherence New!(Oracle叢集物件）Oracle JCA Adapter for LDAP New!

雲端應用介面卡

為了讓客戶能夠輕鬆、自信地將更多管道轉換成無差錯報價，然後將其推進成後端的訂單，以及透過一組豐富的整合加強與客戶體驗系統中其他應用的協作，Oracle 推出了 Oracle Cloud Adapter for Oracle Sales Cloud。

作為 Oracle 領先的跨渠道營銷解決方案，Oracle Eloqua 讓營銷人員能夠計劃和執行自動化營銷活動。透過 Oracle Cloud Adapter for Oracle Eloqua Cloud Service，Oracle Eloqua 可與任何 SaaS 或內部部署 CRM 應用整合，從而實現統一的客戶資料管理，更快地將營銷線索發展成銷售商機。

Oracle 人力資本管理雲讓組織能夠找到、培養和留住最優秀的人才，管理工作與生活解決方案，並提高運營效率。Oracle Cloud Adapter for Oracle HCM Cloud 將幫助組織簡化 HR 流程與其他人才管理、福利和薪資自動化、培訓以及工時和專案管理系統之間的整合。

這些適用於 SaaS 應用的全新雲介面卡（Oracle 銷售雲介面卡、Oracle Eloqua 雲介面卡和 Oracle HCM 雲介面卡）提供了豐富、直觀的設計時功能以及執行時效率。Oracle 透過在領先的整合平臺 Oracle SOA Suite 12c 上釋出這些雲介面卡，將其雲擴充套件到內部部署整合解決方案組合。

雲端介面卡簡化和加速了企業內部應用和SaaS雲應用的整合過程，企業可以用最小的成本和開發週期實現企業內外系統間業務和資料的協同，除了Oracle自己的SaaS應用，當然還提供類似Salesforce等SaaS整合。

雲端整合最大的好處就是可以更好的實現企業將部分應用遷移為SaaS應用，同時透過雲端整合很好的解決了SaaS應用和企業內部應用間的業務和資料互動問題，在整個企業業務域和端到端流程來看，任何一個業務系統都很難封閉孤立存在，而是和其它上下游系統之間存在大量的業務和資料互動。有了這種雲端整合和適配能力，就能夠很好的實現企業內外系統間的高效協同。

舉個簡單的例子就是當我們有一個銷售人員入職的時候，我們在內部HR維護了人員後資訊會自動同步到線上CRM應用軟體中，同時對於線上CRM產生的銷售訂單資訊會自動同步回我們的ERP系統，有了這種自動化的整合和協同將減輕我們大量的重複錄入工作量。

對於當前雲介面卡主要包括瞭如下：

Oracle Cloud Adapter for AribaOracle Cloud Adapter for EloquaOracle Cloud Adapter for ERPOracle Cloud Adapter for NetSuiteOracle Cloud Adapter for RightNowOracle Cloud Adapter for SalesCloudOracle Cloud Adapter for SalesforceOracle Cloud Adapter for ServiceNowOracle Cloud Adapter for SuccessFactors

對於這些整合器當前在國內企業內外整合中使用的並不多，但是也可以看到在12c版本對雲端SaaS整合能力，服務開放能力的顯著增強，從對傳統的B2B應用整合能力已經提升到對主流的SaaS應用的雲端適配。

傳統企業商用套件適配

Oracle 整合介面卡有助於透過產品目錄中提供的各種企業介面卡加快與內部部署的 ERP 系統和企業應用（如 E-Business Suite、SAP、Siebel 和 J.D.Edwards）的整合。所有這些介面卡都是基於標準的行業級元件，具有豐富的設計時內省功能。

對於和Oracle ERP的適配對於SOA套件本身已經整合在裡面，同時SOA套件還支援和各大主流的商用套件的適配，有自己已經收購的廠家，也有類似SAP ERP軟體的適配。同時整個適配覆蓋了ERP，CRM，HR，供應鏈等各類主流的企業常用商用套件系統。

在商用軟體中，對於Oracle ERP本身提供介面表方式進行整合相對容易，而對於類似SAP ERP軟體都是提供了自己私有標準的RFC或IDOC介面，同時底層資料還是以物件形式進行儲存，在這種情況下就更加需要標準介面和這些ERP軟體內部進行協同和互動。

Oracle Adapter for SAP R/3 提供了與 SAP R/3 系統全面、雙向、基於標準的實時連線。該介面卡同時支援 JCA 和 Web 服務標準，可用於建立開放、可重用的面向服務的應用 (SOA)。透過與 SAP 之間高速、低影響、非侵入式的訪問公開 SAP 所含關鍵業務邏輯和資料以供重用，這是構建成功的電子商務應用或整合企業的關鍵。

當前對於企業應用軟體適配主要包括了：

Oracle Adapter for E-Business Suite (PDF)Oracle Integration Adapter for JD Edwards World New!Oracle Integration Adapter for SAP R/3 New!Oracle Adapter for J.D.Edwards OneWorldOracle Adapter for PeopleSoftOracle Adapter for SAP R/3 (SAP JCo 3.0)Oracle Adapter for Siebel

對於ERP類的軟體適配，當前遇到最多的仍然是和Oracle ERP，SAP R/3的適配，對於國內大企業ERP實施也是基本以這兩類ERP軟體為主。

大型機和CDC介面卡

大型機和 CDC 介面卡提供了與原有系統和事務處理系統（如 IMS、CICS、VSAM 或 Tuxedo）的實時連線和整合。它還支援從原有系統/大型機和其他流行資料來源（如 Adabas、DB2、SQL Server 或 IMB/DB）捕獲更改的資料。

這類整合應該在傳統的金融行業使用的比較多，而實際在當前企業中應用的已經相當少，企業私有云推進中可以看到對於小型機都越來越少用，更多全部已經是X86伺服器搭建的IaaS雲化資源池。

Oracle® Application Server Adapters for IMS/TMOracle® Application Server Adapters for IMS/DBOracle® Application Server Adapters for CICSOracle® Application Server Adapters for VSAMOracle® Application Server Adapters for Tuxedo

這類適配是傳統ESB服務匯流排的優勢，即對大量遺留系統，遺留訊息，交易，事務處理類中介軟體的適配。

Oracle BPEL設計器服務元件

Service components是使用BPEL構建組合服務或應用時候的重要構造單元。在BPEL設計器中，有如下的服務元件是可用的，具體包括了：

1)BPEL流程：提供對同步或非同步流程的組裝，編排和儲存能力。2)業務規則：基於業務規則來設計業務決策和分支路由3)人工工作流：提供了人工工作流稽核節點的整合能力4)Mediators route events (messages) between different components5)標準Java API介面的整合能力

在BPEL設計中還有一類Binding元件，該類元件建立了SOA元件和外部之間的連線，有兩種型別：

1)服務：provide the outside world with an entry point，包括了SOAP/HTTP or a JCA adapter2)參考：即該元件本身需要引用哪些內部元件或能力才能夠最終釋出服務到外部。

對於在BPEL設計器中可以使用的Binding元件，具體說明如下：

API管理和API閘道器

今天介紹下Oracle SOA套件中的API Management部分的內容，對於API Management按Oracle的說法更多是在12c版本大量增加了雲端SaaS應用和移動類應用整合能力後，從企業內部系統暴露的需要和外部應用互動的介面本身的全生命週期管理角度出發，同時兼顧API介面本身的安全性管理而推出的一個產品。

對於Oracle API Management可以看到和當前網際網路推出的Open API開放能力服務平臺很類似，一個是更加強調了API從註冊釋出到最終能力開放的全過程，一個是進一步實現從SOAP服務到Rest服務的介面輕量化，同時結合企業安全策略和DMZ區部署要求，實現徹底的服務安全控制能力。

基於官方材料，Oracle API Management分為三個方面的子產品和內容，具體包括了API Manager，API Catalog和API Gateway，下面主要對這三個產品進行分開介紹和說明。

Oracle API Manager

對於Oracle API Manager簡單來說就是實現API的建立和釋出，後續的管理和健康，即API介面服務的全生命週期管理能力。隨著API介面的增加，對API介面的統一管理就越來越重要，這裡面不僅僅是實現API介面服務的後期統一管理和監控，也包括了可以將內部的API介面快速的註冊併發布為WebService服務介面。

對於Oracle API Manager的關鍵能力包括了：

1.快速建立API服務：Allows users to easily create APIs2.安全管理：Provides the ability to secure APIs3.API的編輯和服務釋出：Enables easy API editing and publishing4.API的快速發現：Facilitates the discovery and use of APIs5.API服務的訪問和接入控制：Controls the access to APIs at runtime6.API服務執行監控能力：Monitor and statistics about API performance and activity7.同時支援SOAP和Rest服務：Supports both REST and SOAP APIs

Oracle API Catalog

對於Oracle API Catalog簡單點來理解就是API介面的服務目錄庫，即需要實現對API介面服務的元資料管理，服務查詢，服務檢視檢視，服務多維度瀏覽等關鍵能力。對於元資料管理可以詳細的看到介面服務的輸入，輸入，消費方法，安全要求，使用樣例等資訊，這個和當前主流網際網路釋出的服務能力開放平臺自服務和服務訂購頁面看到的內容很類似。

Oracle API Catalog (OAC)允許組織輕鬆構建其API的目錄，以便為應用程式開發提供可見性。OAC包括一個用於API服務資產庫的簡單元模型，這個元模型可以透過API介面服務呼叫自動解析和計算，同時為使用者提供透過檢索OAC服務目錄就能夠清晰的瞭解服務輸入，輸出和詳細定義資訊的能力，以方便使用者評估開放的API服務能力介面能否滿足業務需求。

OAC透過各種自動化功能來簡化流程和最佳化重用，以促進API服務的消費和使用，其核心能力包括：

1.提供透過API介面自動計算API服務元資料的能力2.提供API介面服務的編輯和服務釋出能力3.簡化了API介面在JDeveloper開發環境中的使用

Oracle API GateWay

Oracle API閘道器是一個基於標準的、策略驅動的、獨立的API安全性和管理解決方案，它使組織能夠透過連線所有相關係統之間的差異和管理互動來安全地和快速地採用雲、移動和SOA服務。Oracle API閘道器保護、加速、整合和路由XML和其他型別的資料，以一種簡單易用的方式來最小化整合成本、降低所有權成本，減少與SOA和雲基礎設施相關的部署風險。它是管理內部使用者和應用程式資產如何公開的控制點，包括與Oracle融合中介軟體安全架構的其他方面的外圍安全性和整合。

對於API GateWay可以看到Oracle更加強調了簡單服務代理和安全策略設定方面的內容，在老的版本Enterprise Gateway產品中，同樣著重介紹了安全方面的隔離能力，具體安全隔離如下圖：

Oracle的SOA安全解決方案是圍繞一個通用的、基於標準的安全模型(ws - policy)構建的。Oracle企業閘道器首先擷取DMZ中的web服務請求。如果該請求被Oracle企業閘道器接受，它將傳遞給Oracle服務匯流排(OSB)，它提供額外的安全性(如果需要)、web服務端點虛擬化、通訊協議中介和資料格式轉換。最後，OSB將請求重定向到適當的web服務端點，該端點由Oracle web服務管理器(OWSM)代理(最後一英里安全性)保護。

對於API GateWay的業務功能和用例場景，可以參考下圖描述，其中主要包括了API安全和API管理兩個方面的內容，除了安全外可以看到在SLA，Qos等方面的能力進一步提升和增強。

大訊息流處理Stream

對於Oracle OSB服務總線上的大資料或大訊息處理，可以採用Content Streaming或附件方式進行處理，這兩種方式可以看到都是不去解析實際的訊息體內容，而將其作為資料流進行處理。

1.利用Streaming Body Content處理大訊息

OSB提供了一種解決方法，即是採用一種稱為Content Streaming的方式來支援大訊息的傳輸，要深入理解這個功能並不容易，作為第一步，你可以理解成body不XML解析，因此省掉了解析的時間，也省掉了記憶體上的大消耗。而方法你只需要在Proxy Service上設定Enable Content Streaming即可。

對於處理訊息內容，您可以指定管道流內容而不是將其載入到記憶體中。當您為管道啟用內容流時，您將指定是否將流內容緩衝為記憶體或磁碟檔案，作為處理訊息的中間步驟。這些臨時檔案的建立可能會影響效能。

當啟用流選項時，內容流只應用於$ body變數。

通常情況下，對於Content Streaming內容流的啟用一般用於以下場景：

a)當處理一個大的內容訊息體的時候。b)在使用情況下，服務匯流排訪問有效載荷少量次數？c)對於基於內容的路由無需轉換; 由於部分解析可以獲取更好的效能。

對於使用Content Streaming內容流處理方式的最佳實踐

a)Assign, insert, and replace actionsb)Java callouts：Use the results to pass input argumentsc)MFL transformations:使用結果來轉換非常大的負載，而不需要首先將輸入作為XML Bean實現

對於XSL轉換，為了執行轉換，所有輸入都是完全實現的，因此，您必須確保輸入足夠小，以便能夠完全地實現並由XSLT處理器處理。使用非常大的MFL輸入，您應該使用MFL服務，而不是MFL階段操作來執行MFL to XML的轉換。不要使用測試控制檯測試具有非常大內容訊息的管道，因為內容將完全實現，可能導致記憶體異常，導致測試控制檯視窗變慢。

在執行時，處理大型訊息會受到底層傳輸的限制。例如，傳輸的訊息大小處理限制。注意，JVM和RMI設定限制了傳輸接收大訊息的能力。

2. 透過流模式來處理附件訊息Streaming Attachments

對於處理訊息附件，可以將服務匯流排頁面MIME附件指定為磁碟，然後對內容進行流處理，而不是快取記憶體中的附件，並將它們解析為XML。當使用大型附件時，這是特別有利的。使用這種方法，服務匯流排只快取標頭，並將訊息有效負載的其餘部分公開為一個流，其中較小的部分可以一次讀取。透過消除對大記憶體緩衝區的需求，流傳輸可以提高服務的可伸縮性。

當啟用管道時，設定應用於處理入站請求訊息。對於HTTP業務服務，設定應用於處理出站響應訊息。以下操作允許傳送和支援流媒體附件:

a)路由，動態路由和路由表b)釋出，動態釋出和釋出表

啟用流時，所有附件(包括二進位制、文字和XML)都被處理為不透明的資料，這意味著您不能基於附件的XML內容執行XQuery或XPath表示式操作。

Inbound Message Handling

當服務匯流排接收入站訊息並將其配置為流附件時，每個MIME附件的內容被儲存到磁碟上的一個單獨的檔案中。然後將$Attachement變數的值設定為每個附件的標準MIME標頭，包括內容id、內容型別、內容轉換編碼、內容描述、內容位置和內容配置，在附件元素下新增。

Outbound Response Message Handling

當服務匯流排處理出站訊息並將其配置為流附件時，每個MIME附件的內容被儲存到磁碟上的單獨檔案中。然後，服務匯流排以類似於入站請求的方式初始化$附件訊息上下文變數(參見入站訊息處理)。

大檔案傳輸MFT

首先要注意到Oracle MFT可管理的檔案傳輸模組是在SOA Suite 12c裡面新增加一個元件模組，主要就是用於企業內部門間以及企業和外部合作伙伴間的檔案傳輸和交換。即高效，安全的實現端到端的檔案傳輸，任務管理，排程和傳輸狀態監控能力。

即使在當今動態的、面向事件的業務環境當中，對各類檔案進行沒有大小限制的高效傳輸都是任何整合策略的核心內容。透過一個統一的、可靠的受管檔案傳輸解決方案來綜合離散的合作伙伴的解決方案，能夠幫助企業企業節省大量的時間和金錢。不斷增長的檔案大小和數量，尤其是在雲環境當中，需要特殊的方式來處理檔案的稽核、重放和安全問題，以滿足業務和監管的需求。

Oracle MFT與Oracle WebLogic Server、Oracle SOA套件和Oracle身份認證管理整合，為使用者很方便的進行企業級檔案傳輸平臺的安裝、配置和部署。

Oracle受管檔案傳輸(MFT)為企業內部各個部門與外部合作伙伴之間提供安全的檔案交換和管理。它在端到端的檔案傳輸當中避免對不安全檔案的意外訪問。它非常易於使用，尤其是針對非技術人員，使用者可以利用更多的資源管理檔案的傳輸。MFT的報告功能使使用者快速掌握檔案傳輸的狀態，在需要的時候進行重新的提交。使用者也能夠使用SSH/FTP反向代理保護DMZ中的資料。

注意MFT是端到端的檔案傳輸解決方案，而不是簡單的OSB或BPEL裡面的FTP檔案適配。要明白在沒有MFT檔案傳輸的時候，要實現兩個FTP檔案伺服器之間的檔案傳輸和交換，採用BPEL進行服務設計的時候仍然是相當麻煩的，首先要講檔案上傳到中間儲存，再講檔案從中間儲存轉發到目標伺服器。而基於MFT進行設計，以上動作則變成最簡單的端到端設計模式。

MFT檔案傳輸本身具備的大檔案處理特性，具體可以總結為：

1.端到端的審計、控制和報告2.內建的安全、身份管理、LDAP和PGP加密3.壓縮、排程和全面的檔案處理框架4.輕量級、面向雲平臺的Web頁面設計器和管理工具5.可擴充套件的端點支援：嵌入的SSH、FTP、檔案、SOAP6與SOA和B2B的整合7.高可用性和叢集，包括DMZ反向代理8.支援針對大檔案的面向雲平臺的應用