（以下文章是最近一段時間各種搜集資料并向同事學習后站在巨人的肩膀上整理出來的，文中有列出參考文檔，還未整理完，后續(xù)會繼續(xù)整理）

一、應用間接口技術

1.文件

兩系統(tǒng)間約定文件服務器地址、文件命名規(guī)則、文件內容格式等內容，通過上傳文件到文件服務器進行數據交互。

最典型的應用場景是批量處理數據：系統(tǒng)A在當天12點之前把要處理的數據生成到一個文件，系統(tǒng)B第二天凌晨1點進行處理，并把處理結果生成到一個文件，系統(tǒng)A第二天12點再進行結果處理。這種狀況經常發(fā)生在A是事物處理型系統(tǒng)，對響應要求比較高，不適合做數據分析型的工作，而系統(tǒng)B是后臺系統(tǒng)，對處理能力要求比較高，適合做批量任務系統(tǒng)。

以上只是說明通過文件方式的數據交互，實際情況B完成任務之后，可能通過socket的方式通知A，不一定是通過文件方式。

文件方式的優(yōu)點：

(1)適合數據量大的情況，不會超時，不占用網絡帶寬。

(2)方案簡單（只要接口雙方約定好路徑、格式、處理方式即可），實現簡單、傳輸批量數據效率較高。避免了網絡傳輸，網絡協(xié)議相關的概念。

文件方式的缺點：

(1) 不太適合做實時類的業(yè)務

(2) 必須有共同的文件服務器，存在安全風險，文件可能被篡改，刪除，或者存在泄密等。

(3) 格式沒有統(tǒng)一標準，標準性差，當改變文件格式的時候，需要各個系統(tǒng)都同步做修改。

2.數據庫共享數據方式

兩系統(tǒng)間通過連接同一個數據庫服務器的同一張表進行數據交換。當系統(tǒng)A請求系統(tǒng)B處理數據的時候，系統(tǒng)A Insert一條數據，系統(tǒng)B select 系統(tǒng)A插入的數據進行處理。

數據庫方式的優(yōu)點是：

1 相比文件方式傳輸來說，因為使用的同一個數據庫，交互更加簡單。

2 由于數據庫提供相當多的操作，比如更新，回滾等。交互方式比較靈活，而且通過數據庫的事務機制，可以做成可靠性的數據交換。

數據庫方式的缺點是：

1 當連接B的系統(tǒng)越來越多的時候，由于數據庫的連接池是有限的，導致每個系統(tǒng)分配到的連接不會很多，當系統(tǒng)越來越多的時候，可能導致無可用的數據庫連接

2 一般情況，來自兩個不同公司的系統(tǒng)，不太會開放自己的數據庫給對方連接，因為這樣會有安全性影響

3.消息

基于消息中間件的接口機制主要通過消息傳遞來完成系統(tǒng)之間的協(xié)作和通信，消息中間件最突出的特點就是提供數據傳輸的可靠性和高效性，主要解決分布式的系統(tǒng)數據傳輸需求。Java消息服務（Java Message Service）是message數據傳輸的典型的實現方式。系統(tǒng)A和系統(tǒng)B通過一個消息服務器進行數據交換。系統(tǒng)A發(fā)送消息到消息服務器，如果系統(tǒng)B訂閱系統(tǒng)A發(fā)送過來的消息，消息服務器會消息推送給B。雙方約定消息格式即可。目前市場上有很多開源的jms消息中間件，比如ActiveMQ, OpenJMS。

消息方式的優(yōu)點：

1 由于jms定義了規(guī)范，有很多的開源的消息中間件可以選擇，而且比較通用，接入起來相對也比較簡單；

2 通過消息方式比較靈活，可以采取同步，異步，可靠性的消息處理，消息中間件也可以獨立出來部署。

消息方式的缺點：

1 學習jms相關的基礎知識，消息中間件的具體配置，以及實現的細節(jié)對于開發(fā)人員來說還是有一點學習成本的；

2 在大數據量的情況下，消息可能會產生積壓，導致消息延遲，消息丟失，甚至消息中間件崩潰。

4.WebService

Web service是一個平臺獨立的，低耦合的，自包含的、基于可編程的web的應用程序，可使用開放的XML（標準通用標記語言下的一個子集）標準來描述、發(fā)布、發(fā)現、協(xié)調和配置這些應用程序，用于開發(fā)分布式的互操作的應用程序。
Web Service技術， 能使得運行在不同機器上的不同應用無須借助附加的、專門的第三方軟件或硬件， 就可相互交換數據或集成。依據Web Service規(guī)范實施的應用之間， 無論它們所使用的語言、 平臺或內部協(xié)議是什么， 都可以相互交換數據。Web Service是自描述、 自包含的可用網絡模塊， 可以執(zhí)行具體的業(yè)務功能。Web Service也很容易部署， 因為它們基于一些常規(guī)的產業(yè)標準以及已有的一些技術，諸如標準通用標記語言下的子集XML、HTTP。Web Service減少了應用接口的花費。Web Service為整個企業(yè)甚至多個組織之間的業(yè)務流程的集成提供了一個通用機制。

首先客戶端從服務器的到WebService的WSDL，同時在客戶端聲稱一個代理類(Proxy Class) 這個代理類負責與WebService服務器進行Request 和Response 當一個數據（XML格式的）被封裝成SOAP格式的數據流發(fā)送到服務器端的時候，就會生成一個進程對象并且把接收到這個Request的SOAP包進行解析，然后對事物進行處理，處理結束以后再對這個計算結果進行SOAP包裝，然后把這個包作為一個Response發(fā)送給客戶端的代理類(Proxy Class)，同樣地，這個代理類也對這個SOAP包進行解析處理，繼而進行后續(xù)操作。這就是WebService的一個運行過程。

Web Service大體上分為5個層次:

1. Http傳輸信道

2. XML的數據格式

3. SOAP封裝格式

4. WSDL的描述方式

5. UDDI UDDI是一種目錄服務，企業(yè)可以使用它對Webservices進行注冊和搜索

Web Service也叫XML Web Service WebService是一種可以接收從Internet或者Intranet上的其它系統(tǒng)中傳遞過來的請求，輕量級的獨立的通訊技術。是通過SOAP在Web上提供的軟件服務，使用WSDL文件進行說明，并通過UDDI進行注冊。
XML：(Extensible Markup Language)擴展型可標記語言。面向短期的臨時數據處理、面向萬維網絡，是Soap的基礎。
Soap：(Simple Object Access Protocol)簡單對象存取協(xié)議。是XML Web Service
的通信協(xié)議。當用戶通過UDDI找到你的WSDL描述文檔后，他通過可以SOAP調用你建立的Web服務中的一個或多個操作。SOAP是XML文檔形式的調用方法的規(guī)范，它可以支持不同的底層接口，像HTTP(S)或者SMTP。
WSDL：(Web Services Description Language) WSDL 文件是一個 XML 文檔，用于說明一組 SOAP 消息以及如何交換這些消息。大多數情況下由軟件自動生成和使用。
UDDI (Universal Description, Discovery, and Integration)
是一個主要針對Web服務供應商和使用者的新項目。在用戶能夠調用Web服務之前，必須確定這個服務內包含哪些商務方法，找到被調用的接口定義，還要在服務端來編制軟件，UDDI是一種根據描述文檔來引導系統(tǒng)查找相應服務的機制。UDDI利用SOAP消息機制（標準的XML/HTTP）來發(fā)布，編輯，瀏覽以及查找注冊信息。它采用XML格式來封裝各種不同類型的數據，并且發(fā)送到注冊中心或者由注冊中心來返回需要的數據。

（）調用原理

實現一個完整的Web服務包括以下步驟：

◆ Web服務提供者設計實現Web服務，并將調試正確后的Web服務通過Web服務中介者發(fā)布，并在UDDI注冊中心注冊； （發(fā)布）
◆ Web服務請求者向Web服務中介者請求特定的服務，中介者根據請求查詢UDDI注冊中心，為請求者尋找滿足請求的服務； （發(fā)現）
◆ Web服務中介者向Web服務請求者返回滿足條件的Web服務描述信息，該描述信息用WSDL寫成，各種支持Web服務的機器都能閱讀；（發(fā)現）
◆ 利用從Web服務中介者返回的描述信息生成相應的SOAP消息，發(fā)送給Web服務提供者，以實現Web服務的調用；（綁定）
◆ Web服務提供者按SOAP消息執(zhí)行相應的Web服務，并將服務結果返回給Web服務請求者。（綁定）

（2）調用方式：

1. Net下采用GET/POST/SOAP方式動態(tài)調用WebService的簡易靈活方法(C#)
webservice 的調用有3種方式
1). httpget
2). httppost
3). httpsoap
soap 的優(yōu)點是 可以傳遞結構化的 數據，而前兩種不行。
btw, soap 最終也是使用 HTTP 傳送 XM

WebService方式的優(yōu)點：

1 適用于網絡上不同系統(tǒng)的分布式應用、標準性好、擴展性好、耦合度低；

2.內容由標準文本組成，任何平臺和程序語言都可以使用；格式的轉換基本不受限制，可以滿足不同應用系統(tǒng)的需求。

Webservice方式的缺點：

1 不適合用于實現大批量數據交互的接口。

注：以上描述還需細化，webservice有多種方式，參考：

企業(yè)服務總線（ESB）在RESTful架構集成中的作用

RESTful Webservice

Web Service進階(七)淺談SOAP Webservice和RESTful Webservice

XML+HTTP風格架構和RESTful風格架構的webService

Webservice RPC風格 SOAP,REST風格 各之間的對比

5.API

API（Application Programming Interface，應用程序編程接口）是一些預先定義的函數，目的是提供應用程序與開發(fā)人員基于某軟件或硬件得以訪問一組例程的能力，而又無需訪問源碼，或理解內部工作機制的細節(jié)。

API方式的優(yōu)點：

1 降低了系統(tǒng)復雜性；

API方式的缺點：

1.對API的學習成本；

2.必須定義統(tǒng)一的開放式API 標準，否則會提高應用代碼的維護成本。

舉例：下面具體來分析一個場景，來看看系統(tǒng)之間數據傳輸的應用

場景 目前業(yè)務人員需要導入一個大文件到系統(tǒng)A，系統(tǒng)A保存文件信息，而文件里面的明細信息需要導入到系統(tǒng)B進行分析，當系統(tǒng)B分析完成之后，需要把分析結果通知系統(tǒng)A。

A 系統(tǒng)A先保存文件到文件服務器。

B 系統(tǒng)A 通過webservice 調用系統(tǒng)B提供的服務器，把需要處理的文件名發(fā)送到系統(tǒng)B。由于文件很大，需要處理很長時間，所以B不及時處理文件，而是保存需要處理的文件名到數據庫，通過后臺定時調度機制去處理。所以B接收請求成功，立刻返回系統(tǒng)A成功。

C 系統(tǒng)B定時查詢數據庫記錄，通過記錄查找文件路徑，找到文件進行處理。這個過程很長。

D 系統(tǒng)B處理完成之后發(fā)送消息給系統(tǒng)A，告知系統(tǒng)A文件處理完成。

E 系統(tǒng)A 接收到系統(tǒng)B請求來的消息，進行展示任務結果

參考：

應用系統(tǒng)之間數據傳輸的幾種方式

遠程通信的幾種選擇（RPC，Webservice，RMI，JMS的區(qū)別）

Webservice工作原理及實例

Web Service

二、應用間數據傳輸的解決方案

1.EAI（Enterprise Application Integration，企業(yè)應用集成）

是將基于各種不同平臺、用不同方案建立的異構應用集成的一種方法和技術。EAI 通過建立底層結構，來聯(lián)系橫貫整個企業(yè)的異構系統(tǒng)、應用、數據源等，實現企業(yè)內部的 ERP、CRM、SCM、數據庫、數據倉庫，以及其他重要的內部系統(tǒng)之間無縫地共享和交換數據。有了 EAI，企業(yè)就可以將企業(yè)核心應用和新的 Internet解決方案結合在一起。

2.ETL(extraction, transformation and loading)

ETL即數據抽取（ Extract）、轉換（ Transform）、裝載（ Load）的過程。最初 ETL 的設計是為了方便建立數據市場和數據倉庫，并將它們升級為批處理方式。而下一代的 ETL 工具則在許多功能上做了擴展，使其能夠適用于企業(yè)的應用集成，并且其中的一些工具將能夠起到 EAI 某些工具的作用。 但是 ETL 還不能取代 EAI，下一代 ETL在應用集成領域中還只是 EAI的補充。但是隨著 ETL技術的發(fā)展，企業(yè)在建立基于批處理數據倉庫的系統(tǒng)集成工具時，將越來越關注對 ETL的選擇，同時 EAI和 ETL之間的界限也將變得越來越模糊。

ETL 工具適合數據集成， EAI 工具則適用于流程操作。 下一代 ETL 工具更加適用于解決兩個系統(tǒng)間數據的批量或者實時同步工作，特別是當大量巨大的數據在兩個系統(tǒng)間提取、轉換和存儲時， ETL 的優(yōu)勢更加明顯。 EAI 則適用于工作流和商業(yè)流程管理的需求，特別是擅長處理大量小事務。
對于交互式流程，如果它沒有擴展工作流的需求，沒有復雜數據的轉換的需求，或者需要批量實時數據的合并處理，則 ETL 工具將是比較好的選擇。
ETL 工具比較適合于數據集成的工作，如應用系統(tǒng)之間的數據同步和點對點的單步交互工作；需要實時數據處理的工作中包含了大量的數據處理、復雜的數據傳輸和數據運算，它同樣適合采用 ETL 工具。
上面這些工作，即便是有些具體的處理需要通過 EAI 工具編程實現，我們還是可以用 ETL 中的工具來處理。因為 ETL工具主要是通過關系型數據庫來實現大量數據操作的，所以使用這類工具來傳輸大塊的數據將取得更好的效果。
EAI 工具無疑是最適合流程集成的工具，如果流程中包含了大量的傳輸，那么它就必然包含了對業(yè)務流程的管理和實時交互的流程。

3.ESB全稱為Enterprise Service Bus，即企業(yè)服務總線。

它是傳統(tǒng)中間件技術與XML、Web服務等技術結合的產物。ESB提供了網絡中最基本的連接中樞，是構筑企業(yè)神經系統(tǒng)的必要元素。ESB的出現改變了傳統(tǒng)的軟件架構，可以提供比傳統(tǒng)中間件產品更為廉價的解決方案，同時它還可以消除不同應用之間的技術差異，讓不同的應用服務器協(xié)調運作，實現了不同服務之間的通信與整合。從功能上看，ESB提供了事件驅動和文檔導向的處理模式，以及分布式的運行管理機制，它支持基于內容的路由和過濾，具備了復雜數據的傳輸能力，并可以提供一系列的標準接口。

未完待續(xù)

三、概念解釋

1. 什么是SOA

SOA（Service-Oriented Architecture)既服務導向架構，是指為了解決在inernet環(huán)境下業(yè)務集成的需要，通過連接能完成特定任務的獨立功能實現的一種軟件系統(tǒng)架構。該定義的學術味道較濃，但其核心思想并不難理解：讓應用不受限于技術，讓企業(yè)輕松應對商業(yè)服務變化和發(fā)展的需要。目前，SOA的實現手段主要包括：Web Serice（網絡服務）、ＣＯＲＢＡ和ＪＩＮＩ等。

2. 為何要使用SOA

面向服務架構（SOA）是一種應用框架，它著眼于日常的業(yè)務應用，并將它們劃分為單獨的業(yè)務功能和流程，即所謂的服務。SOA 使用戶可以構建、部署和整合這些服務，且無需依賴應用程序及其運行計算平臺，從而提高業(yè)務流程的靈活性。這種業(yè)務靈活性可使企業(yè)加快發(fā)展速度，降低總體擁有成本，改善對及時、準確信息的訪問。SOA 有助于實現更多的資產重用、更輕松的管理和更快的開發(fā)與部署。在當今的業(yè)務環(huán)境中，變化是毫無疑問的，因此快速響應客戶需求、市場機遇和外部威脅的敏捷性比以往任何時候都更顯重要。 各種企業(yè)都認識到組件化、模塊化、互操作和可伸縮基礎設施的價值：

組件化：利用標準化的應用程序和資源服務接口

互操作：實現應用程序和/或資源之間的輕松信息交換

模塊化：混合搭配、添加刪除、業(yè)務流程與基礎設施

可伸縮：從現有資源起步，隨需添加其他資源

3. SOA與Web Service何為區(qū)別

SOA 不是Web服務

Web服務是實現SOA的方式之一。

在SOA時代下，ESB為SOA的實施提供了底層架構的技術支持。SOA從根本上來說就是要解決兩個問題:重用和異構，但是作為信息化系統(tǒng)建設永遠要面對的兩個難題，解決的方法卻并不簡單，所以SOA的體系龐大而復雜。 更重要的是ESB為分散服務提供了交互、組合和治理的基礎架構。有了它，SOA才能釋放自己的最大價值。 IBM為ESB定義了四個必備的功能:“路由器”——根據信息內容，在不同應用和服務之間進行信 息傳輸和路由;“轉換器”——進行應用之間的通信協(xié)議轉換;“翻譯機”——進行應用之間的消息格式轉換;“收發(fā)室”——處理來自不同渠道的業(yè)務事件(同步 傳輸，異步傳輸，發(fā)布/訂閱等方式)。 其中“路由器”和“收發(fā)室”都是針對服務的重用而設計的，而“轉換器”和“翻譯機”則專門用來解決異構的通信問題。 針對重用和異構這兩個難題，倪曉兵認為ESB提供了兩個核心的功能，服務的管理和數據的轉換。 那么ESB到底是什么呢?業(yè)內對ESB的定義是:它是由中間件技術實現并支持SOA的一組基礎架構，支持異構環(huán)境中的服務、消息以及基于事件的交互，并且具有適當的服務級別和可管理性。

5. SOA,ESB之間的關系

首先，ESB不是SOA。SOA的最常見的實現方式方式是SCA和JBI，而SCA的實現需要ESB，相反JBI則不需要ESB，可以參看本人對 JBI和SCA分析解讀的文章。 其次，因為IBM和Oracle（收購了BEA和SUN的牛X公司）都推崇SCA模式的SOA，因此SCA實際上已經成為SOA的事實標準，說道SOA，最先想到的就是SCA模式了。 最后，ESB是SCA架構實現不可缺少的一部分，ESB產品脫離了具體的應用外，沒有任何意義。ESB的作用在于實現服務間智能化集成與管理的中介。通過 ESB可以訪問所集成系統(tǒng)的所有已注冊服務。

6. SOA,ESB,WebService的關系

SOA是方法論，就像建筑學一樣，指導性質的；

ESB是建筑圖紙，理順整個建筑的架構；

Web S是具體的建筑材料，就好像預制板；

7. 什么是RPC?

RPC就是想實現函數調用模式的網絡化?？蛻舳司拖裾{用本地函數一樣，然后客戶端把這些參數打包之后通過網絡傳遞到服務端，服務端解包到處理過程中執(zhí)行，然后執(zhí)行的結果反饋給客戶端。 RPC（Remote Procedure Call Protocol）——遠程過程調用協(xié)議，是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協(xié)議。它假定某些傳輸協(xié)議的存在，如 TCP或UDP，以便為通信程序之間攜帶信息數據。通過它可以使函數調用模式網絡化。在OSI網絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發(fā)包括網絡分布式多程序在內的應用程序更加容易。 RPC 工作原理

運行時,一次客戶機對服務器的RPC調用,其內部操作大致有如下十步：

1.調用客戶端句柄；執(zhí)行傳送參數

2.調用本地系統(tǒng)內核發(fā)送網絡消息

3.消息傳送到遠程主機

4.服務器句柄得到消息并取得參數

5.執(zhí)行遠程過程

6.執(zhí)行的過程將結果返回服務器句柄

7.服務器句柄返回結果，調用遠程系統(tǒng)內核

8.消息傳回本地主機

9.客戶句柄由內核接收消息

10.客戶接收句柄返回的數據

8.Web Server：是一種開發(fā)web服務的技術規(guī)范，按照web services規(guī)范開發(fā)的web服務組件，可以用來進行企業(yè)應用系統(tǒng)集成。

傳輸服務：必須確保通過企業(yè)總線互連的業(yè)務流程間的消息的正確交付，傳輸還包括基于內容的路由功能。

多種服務集成方式：如HTTP ，WEB等。

通信：服務發(fā)布、訂閱，響應 請求，同步異步消息，路由和尋址等；

服務安全：認證和授權、不可否認和機密性、安全標準的支持等；

服務質量：事務，服務的可交付性等；

服務等級：性能、可用性等

參考：

ESB開發(fā)WebService接口

SOA,ESB,WebService的關系

總結

以上是生活随笔為你收集整理的应用系统间数据传输方式总结（附相关概念解释）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。