（如下文章是最近一段時間各類蒐集資料並向同事學習後站在巨人的肩膀上整理出來的，文中有列出參考文檔，還未整理完，後續會繼續整理）html
1、應用間接口技術
1.文件
兩系統間約定文件服務器地址、文件命名規則、文件內容格式等內容，經過上傳文件到文件服務器進行數據交互。web
最典型的應用場景是批量處理數據：系統A在當天12點以前把要處理的數據生成到一個文件，系統B次日凌晨1點進行處理，並把處理結果生成到一個文件，系統A次日12點再進行結果處理。這種情況常常發生在A是事物處理型系統，對響應要求比較高，不適合作數據分析型的工做，而系統B是後臺系統，對處理能力要求比較高，適合作批量任務系統。數據庫
以上只是說明經過文件方式的數據交互，實際狀況B完成任務以後，可能經過socket的方式通知A，不必定是經過文件方式。編程
文件方式的優勢：安全
(1)適合數據量大的狀況，不會超時，不佔用網絡帶寬。服務器
(2)方案簡單（只要接口雙方約定好路徑、格式、處理方式便可），實現簡單、傳輸批量數據效率較高。避免了網絡傳輸，網絡協議相關的概念。網絡
文件方式的缺點：架構
(1) 不太適合作實時類的業務框架
(2) 必須有共同的文件服務器，存在安全風險，文件可能被篡改，刪除，或者存在泄密等。異步
(3) 格式沒有統一標準，標準性差，當改變文件格式的時候，須要各個系統都同步作修改。
2.數據庫共享數據方式
兩系統間經過鏈接同一個數據庫服務器的同一張表進行數據交換。當系統A請求系統B處理數據的時候，系統A Insert一條數據，系統B select 系統A插入的數據進行處理。
數據庫方式的優勢是：
1 相比文件方式傳輸來講，由於使用的同一個數據庫，交互更加簡單。
2 因爲數據庫提供至關多的操做，好比更新，回滾等。交互方式比較靈活，並且經過數據庫的事務機制，能夠作成可靠性的數據交換。
數據庫方式的缺點是：
1 當鏈接B的系統愈來愈多的時候，因爲數據庫的鏈接池是有限的，致使每一個系統分配到的鏈接不會不少，當系統愈來愈多的時候，可能致使無可用的數據庫鏈接
2 通常狀況，來自兩個不一樣公司的系統，不太會開放本身的數據庫給對方鏈接，由於這樣會有安全性影響
3.消息
基於消息中間件的接口機制主要經過消息傳遞來完成系統之間的協做和通訊，消息中間件最突出的特色就是提供數據傳輸的可靠性和高效性，主要解決分佈式的系統數據傳輸需求。Java消息服務（Java Message Service）是message數據傳輸的典型的實現方式。系統A和系統B經過一個消息服務器進行數據交換。系統A發送消息到消息服務器，若是系統B訂閱系統A發送過來的消息，消息服務器會消息推送給B。雙方約定消息格式便可。目前市場上有不少開源的jms消息中間件，好比 ActiveMQ, OpenJMS 。
消息方式的優勢：
1 因爲jms定義了規範，有不少的開源的消息中間件能夠選擇，並且比較通用，接入起來相對也比較簡單；
2 經過消息方式比較靈活，能夠採起同步，異步，可靠性的消息處理，消息中間件也能夠獨立出來部署。
消息方式的缺點：
1 學習jms相關的基礎知識，消息中間件的具體配置，以及實現的細節對於開發人員來講仍是有一點學習成本的；
2 在大數據量的狀況下，消息可能會產生積壓，致使消息延遲，消息丟失，甚至消息中間件崩潰。
4.WebService
Web service是一個平臺獨立的，低耦合的，自包含的、基於可編程的web的應用程序，可以使用開放的XML（標準通用標記語言下的一個子集）標準來描述、發佈、發現、協調和配置這些應用程序，用於開發分佈式的互操做的應用程序。
Web Service技術， 能使得運行在不一樣機器上的不一樣應用無須藉助附加的、專門的第三方軟件或硬件， 就可相互交換數據或集成。依據Web Service規範實施的應用之間， 不管它們所使用的語言、 平臺或內部協議是什麼， 均可以相互交換數據。Web Service是自描述、 自包含的可用網絡模塊， 能夠執行具體的業務功能。Web Service也很容易部署， 由於它們基於一些常規的產業標準以及已有的一些技術，諸如標準通用標記語言下的子集XML、HTTP。Web Service減小了應用接口的花費。Web Service爲整個企業甚至多個組織之間的業務流程的集成提供了一個通用機制。
首先客戶端從服務器的到WebService的WSDL，同時在客戶端聲稱一個代理類(Proxy Class) 這個代理類負責與WebService服務器進行Request 和Response 當一個數據（XML格式的）被封裝成SOAP格式的數據流發送到服務器端的時候，就會生成一個進程對象而且把接收到這個Request的SOAP包進行解析，而後對事物進行處理，處理結束之後再對這個計算結果進行SOAP包裝，而後把這個包做爲一個Response發送給客戶端的代理類(Proxy Class)，一樣地，這個代理類也對這個SOAP包進行解析處理，繼而進行後續操做。這就是WebService的一個運行過程。
Web Service大致上分爲5個層次:
1. Http傳輸信道
2. XML的數據格式
3. SOAP封裝格式
4. WSDL的描述方式
5. UDDI UDDI是一種目錄服務，企業可使用它對Webservices進行註冊和搜索
Web Service也叫XML Web Service WebService是一種能夠接收從Internet或者Intranet上的其它系統中傳遞過來的請求，輕量級的獨立的通信技術。是經過SOAP在Web上提供的軟件服務，使用WSDL文件進行說明，並經過UDDI進行註冊。
XML：(Extensible Markup Language)擴展型可標記語言。面向短時間的臨時數據處理、面向萬維網絡，是Soap的基礎。
Soap：(Simple Object Access Protocol)簡單對象存取協議。是XML Web Service 的通訊協議。當用戶經過UDDI找到你的WSDL描述文檔後，他經過能夠SOAP調用你創建的Web服務中的一個或多個操做。SOAP是XML文檔形式的調用方法的規範，它能夠支持不一樣的底層接口，像HTTP(S)或者SMTP。
WSDL：(Web Services Description Language) WSDL 文件是一個 XML 文檔，用於說明一組 SOAP 消息以及如何交換這些消息。大多數狀況下由軟件自動生成和使用。
UDDI (Universal Description, Discovery, and Integration) 是一個主要針對Web服務供應商和使用者的新項目。在用戶可以調用Web服務以前，必須肯定這個服務內包含哪些商務方法，找到被調用的接口定義，還要在服務端來編制軟件，UDDI是一種根據描述文檔來引導系統查找相應服務的機制。UDDI利用SOAP消息機制（標準的XML/HTTP）來發布，編輯，瀏覽以及查找註冊信息。它採用XML格式來封裝各類不一樣類型的數據，而且發送到註冊中心或者由註冊中心來返回須要的數據。
（）調用原理
實現一個完整的Web服務包括如下步驟：
◆ Web服務提供者設計實現Web服務，並將調試正確後的Web服務經過Web服務中介者發佈，並在UDDI註冊中心註冊； （發佈）
◆ Web服務請求者向Web服務中介者請求特定的服務，中介者根據請求查詢UDDI註冊中心，爲請求者尋找知足請求的服務； （發現）
◆ Web服務中介者向Web服務請求者返回知足條件的Web服務描述信息，該描述信息用WSDL寫成，各類支持Web服務的機器都能閱讀；（發現）
◆ 利用從Web服務中介者返回的描述信息生成相應的SOAP消息，發送給Web服務提供者，以實現Web服務的調用；（綁定）
◆ Web服務提供者按SOAP消息執行相應的Web服務，並將服務結果返回給Web服務請求者。（綁定）
（2）調用方式：
1. Net下采用GET/POST/SOAP方式動態調用WebService的簡易靈活方法(C#)
webservice 的調用有3種方式
1). httpget
2). httppost
3). httpsoap
soap 的優勢是 能夠傳遞結構化的 數據，而前兩種不行。
btw, soap 最終也是使用 HTTP 傳送 XM
WebService方式的優勢：
1 適用於網絡上不一樣系統的分佈式應用、標準性好、擴展性好、耦合度低；
2.內容由標準文本組成，任何平臺和程序語言均可以使用；格式的轉換基本不受限制，能夠知足不一樣應用系統的需求。
Webservice方式的缺點：
1 不適合用於實現大批量數據交互的接口。
注：以上描述還需細化，webservice有多種方式，參考：
企業服務總線（ESB）在RESTful架構集成中的做用
RESTful Webservice
Web Service進階(七)淺談SOAP Webservice和RESTful Webservice
XML+HTTP風格架構和RESTful風格架構的webService
Webservice RPC風格 SOAP,REST風格 各之間的對比
5.API
API（Application Programming Interface，應用程序編程接口）是一些預先定義的函數，目的是提供應用程序與開發人員基於某軟件或硬件得以訪問一組例程的能力，而又無需訪問源碼，或理解內部工做機制的細節。
API方式的優勢：
1 下降了系統複雜性；
API方式的缺點：
1.對API的學習成本；
2.必須定義統一的開放式API 標準，不然會提升應用代碼的維護成本。
舉例：下面具體來分析一個場景，來看看系統之間數據傳輸的應用
場景 目前業務人員須要導入一個大文件到系統A，系統A保存文件信息，而文件裏面的明細信息須要導入到系統B進行分析，當系統B分析完成以後，須要把分析結果通知系統A。
A 系統A先保存文件到文件服務器。
B 系統A 經過webservice 調用系統B提供的服務器，把須要處理的文件名發送到系統B。因爲文件很大，須要處理很長時間，因此B不及時處理文件，而是保存須要處理的文件名到數據庫，經過後臺定時調度機制去處理。因此B接收請求成功，馬上返回系統A成功。
C 系統B定時查詢數據庫記錄，經過記錄查找文件路徑，找到文件進行處理。這個過程很長。
D 系統B處理完成以後發送消息給系統A，告知系統A文件處理完成。
E 系統A 接收到系統B請求來的消息，進行展現任務結果
參考：
應用系統之間數據傳輸的幾種方式
遠程通訊的幾種選擇（RPC，Webservice，RMI，JMS的區別）
Webservice工做原理及實例
Web Service
2、應用間數據傳輸的解決方案
1.EAI（Enterprise Application Integration，企業應用集成）
是將基於各類不一樣平臺、用不一樣方案創建的異構應用集成的一種方法和技術。EAI 經過創建底層結構，來聯繫橫貫整個企業的異構系統、應用、數據源等，實現企業內部的 ERP、CRM、SCM、數據庫、數據倉庫，以及其餘重要的內部系統之間無縫地共享和交換數據。有了 EAI，企業就能夠將企業核心應用和新的 Internet解決方案結合在一塊兒。
2.ETL(extraction, transformation and loading)
ETL即數據抽取（ Extract）、轉換（ Transform）、裝載（ Load）的過程。最初 ETL 的設計是爲了方便創建數據市場和數據倉庫，並將它們升級爲批處理方式。而下一代的 ETL 工具則在許多功能上作了擴展，使其可以適用於企業的應用集成，而且其中的一些工具將可以起到 EAI 某些工具的做用。 可是 ETL 還不能取代 EAI，下一代 ETL在應用集成領域中還只是 EAI的補充。可是隨着 ETL技術的發展，企業在創建基於批處理數據倉庫的系統集成工具時，將愈來愈關注對 ETL的選擇，同時 EAI和 ETL之間的界限也將變得愈來愈模糊。
ETL 工具適合數據集成， EAI 工具則適用於流程操做。 下一代 ETL 工具更加適用於解決兩個系統間數據的批量或者實時同步工做，特別是當大量巨大的數據在兩個系統間提取、轉換和存儲時， ETL 的優點更加明顯。 EAI 則適用於工做流和商業流程管理的需求，特別是擅長處理大量小事務。
對於交互式流程，若是它沒有擴展工做流的需求，沒有複雜數據的轉換的需求，或者須要批量實時數據的合併處理，則 ETL 工具將是比較好的選擇。
ETL 工具比較適合於數據集成的工做，如應用系統之間的數據同步和點對點的單步交互工做；須要實時數據處理的工做中包含了大量的數據處理、複雜的數據傳輸和數據運算，它一樣適合採用 ETL 工具。
上面這些工做，即使是有些具體的處理須要經過 EAI 工具編程實現，咱們仍是能夠用 ETL 中的工具來處理。由於 ETL工具主要是經過關係型數據庫來實現大量數據操做的，因此使用這類工具來傳輸大塊的數據將取得更好的效果。
EAI 工具無疑是最適合流程集成的工具，若是流程中包含了大量的傳輸，那麼它就必然包含了對業務流程的管理和實時交互的流程。
3.ESB全稱爲Enterprise Service Bus，即企業服務總線。
它是傳統中間件技術與XML、Web服務等技術結合的產物。ESB提供了網絡中最基本的鏈接中樞，是構築企業神經系統的必要元素。ESB的出現改變了傳統的軟件架構，能夠提供比傳統中間件產品更爲廉價的解決方案，同時它還能夠消除不一樣應用之間的技術差別，讓不一樣的應用服務器協調運做，實現了不一樣服務之間的通訊與整合。從功能上看，ESB提供了事件驅動和文檔導向的處理模式，以及分佈式的運行管理機制，它支持基於內容的路由和過濾，具有了複雜數據的傳輸能力，並能夠提供一系列的標準接口。
未完待續
3、概念解釋
1. 什麼是SOA
SOA（Service-Oriented Architecture)既服務導向架構，是指爲了解決在inernet環境下業務集成的須要，經過鏈接能完成特定任務的獨立功能實現的一種軟件系統架構。該定義的學術味道較濃，但其核心思想並不難理解：讓應用不受限於技術，讓企業輕鬆應對商業服務變化和發展的須要。目前，SOA的實現手段主要包括：Web Serice（網絡服務）、ＣＯＲＢＡ和ＪＩＮＩ等。
2. 爲什麼要使用SOA
面向服務架構（SOA）是一種應用框架，它着眼於平常的業務應用，並將它們劃分爲單獨的業務功能和流程，即所謂的服務。SOA 使用戶能夠構建、部署和整合這些服務，且無需依賴應用程序及其運行計算平臺，從而提升業務流程的靈活性。這種業務靈活性可以使企業加快發展速度，下降整體擁有成本，改善對及時、準確信息的訪問。SOA 有助於實現更多的資產重用、更輕鬆的管理和更快的開發與部署。在當今的業務環境中，變化是毫無疑問的，所以快速響應客戶需求、市場機遇和外部威脅的敏捷性比以往任什麼時候候都更顯重要。 各類企業都認識到組件化、模塊化、互操做和可伸縮基礎設施的價值：
組件化：利用標準化的應用程序和資源服務接口
互操做：實現應用程序和/或資源之間的輕鬆信息交換
模塊化：混合搭配、添加刪除、業務流程與基礎設施
可伸縮：從現有資源起步，隨需添加其餘資源
3. SOA與Web Service何爲區別
SOA 不是Web服務
Web服務是實現SOA的方式之一。
在SOA時代下，ESB爲SOA的實施提供了底層架構的技術支持。SOA從根本上來講就是要解決兩個問題:重用和異構，可是做爲信息化系統建設永遠要面對的兩個難題，解決的方法卻並不簡單，因此SOA的體系龐大而複雜。 更重要的是ESB爲分散服務提供了交互、組合和治理的基礎架構。有了它，SOA才能釋放本身的最大價值。 IBM爲ESB定義了四個必備的功能:「路由器」——根據信息內容，在不一樣應用和服務之間進行信 息傳輸和路由;「轉換器」——進行應用之間的通訊協議轉換;「翻譯機」——進行應用之間的消息格式轉換;「收發室」——處理來自不一樣渠道的業務事件(同步 傳輸，異步傳輸，發佈/訂閱等方式)。 其中「路由器」和「收發室」都是針對服務的重用而設計的，而「轉換器」和「翻譯機」則專門用來解決異構的通訊問題。 針對重用和異構這兩個難題，倪曉兵認爲ESB提供了兩個核心的功能，服務的管理和數據的轉換。 那麼ESB究竟是什麼呢?業內對ESB的定義是:它是由中間件技術實現並支持SOA的一組基礎架構，支持異構環境中的服務、消息以及基於事件的交互，而且具備適當的服務級別和可管理性。
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能夠訪問所集成系統的全部已註冊服務。
6. SOA,ESB,WebService的關係
SOA是方法論，就像建築學同樣，指導性質的；
ESB是建築圖紙，理順整個建築的架構；
Web S是具體的建築材料，就好像預製板；
7. 什麼是RPC?
RPC就是想實現函數調用模式的網絡化。客戶端就像調用本地函數同樣，而後客戶端把這些參數打包以後經過網絡傳遞到服務端，服務端解包處處理過程當中執行，而後執行的結果反饋給客戶端。 RPC（Remote Procedure Call Protocol）——遠程過程調用協議，是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。它假定某些傳輸協議的存在，如 TCP或UDP，以便爲通訊程序之間攜帶信息數據。經過它可使函數調用模式網絡化。在OSI網絡通訊模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分佈式多程序在內的應用程序更加容易。 RPC 工做原理
運行時,一次客戶機對服務器的RPC調用,其內部操做大體有以下十步：
1.調用客戶端句柄；執行傳送參數
2.調用本地系統內核發送網絡消息
3.消息傳送到遠程主機
4.服務器句柄獲得消息並取得參數
5.執行遠程過程
6.執行的過程將結果返回服務器句柄
7.服務器句柄返回結果，調用遠程系統內核
8.消息傳回本地主機
9.客戶句柄由內核接收消息
10.客戶接收句柄返回的數據
8.Web Server：是一種開發web服務的技術規範，按照web services規範開發的web服務組件，能夠用來進行企業應用系統集成。
傳輸服務： 必須確保經過企業總線互連的業務流程間的消息的正確交付，傳輸還包括基於內容的路由功能。
多種服務集成方式：如HTTP ，WEB等。
通訊：服務發佈、訂閱，響應 請求，同步異步消息，路由和尋址等；
服務安全： 認證和受權、不能否認和機密性、安全標準的支持等；
服務質量： 事務，服務的可交付性等；
服務等級： 性能、可用性等
參考：
ESB開發WebService接口
SOA,ESB,WebService的關係