歡迎來到Linux教程網
Linux教程網
Linux教程網
Linux教程網
Linux教程網 >> Linux編程 >> Linux編程 >> Spring Integration入門

Spring Integration入門

日期:2017/3/1 9:52:05   编辑:Linux編程

為什麼使用Spring IntegrationSpring

Integration是Spring框架創建的又一個API,面向企業應用集成(EAI)。說到集成,並不缺“解決辦法”:硬編碼的Java客戶端、其它ESB產品,還有消息隊列等更加傳統的應用集成技術。Spring Integration對以上各種解決方法都有所改進,改進的方式有時還頗具戲劇效果。Spring Integration非常輕量、易於測試;幾乎沒有入門門檻,概念上比任何“自己編寫”的解決方法都要簡單。長遠來看,它更為靈活、更具有適應性。一旦使用,你就會戀上它。Spring Integration可以和EJB、RMI、JMS這些標准技術協同使用,能讓你在一處對復雜的解決方法進行建模,從而對標准技術有所增強。這在很大程度上簡化了這些技術的使用。由於Spring Integration非常輕量(與應用一起部署Spring Integration服務器,不用將應用部署到Spring Integration中去),而且很注重開發生命周期(方便配置的XML schema、友好的POJO形式API、與Spring框架和JEE的強大集成),所以你會發現跟其它很多的ESB產品相比,Spring Integration要更加適用。

Spring Integration本身就很強大,毋庸置疑,它從Spring框架中得到了強大的支持。比如說,配置格式無非還是Spring schema,這些配置格式反過來又為你抽象出了bean示例。Spring Integration的使用沒什麼神奇之處,你可以自信地編寫main(String [] args)方法來完成XML配置所做的一切。Spring Integration中很多對RPC和消息的可用支持都以Spring框架的支持為基礎。Spring Integration配置文件中的所有內容仍是標准的Spring 應用上下文,和通常的Spring bean一樣,它也受益於依賴注入和運行時可用的方面(Aspect)。使用Spring Integration,應用上下文就是總線了。比如這能使依賴於應用上下文事件的解決方案成為可能。這是沒有獨立“運行時”的另一個原因,因為只要上下文可用,總線就存在。

下載源碼

免費下載地址在 http://linux.linuxidc.com/

用戶名與密碼都是www.linuxidc.com

具體下載目錄在 /2013年資料/10月/17日/Spring Integration入門

下載方法見 http://www.linuxidc.com/Linux/2013-07/87684.htm

背景
企業應用集成(EAI)是集成應用之間數據和服務的一種應用技術。它解決無限的問題,解決方案也幾乎沒有窮盡。工程師們已經為這些解決方案的創建努力了數十年。就在最近,我們才確定了原則的最佳實踐,並對這些方案進行了分類。

現代EAI的模式通常要歸功於Gregor Hohpe等人編著的《企業集成模式》[1],該書對集成解決方案共有的很多集成模式進行了分類和闡述。Hohpe等人列出了四種集成風格:

  1. 文件傳輸:兩個系統生成文件,文件的有效負載就是由另一個系統處理的消息。該類風格的例子之一是針對文件輪詢目錄或FTP目錄,並處理該文件。
  2. 共享數據庫:兩個系統查詢同一個數據庫以獲取要傳遞的數據。一個例子是你部署了兩個EAR應用,它們的實體類(JPA、Hibernate等)共用同一個表。
  3. 遠程過程調用:兩個系統都暴露另一個能調用的服務。該類例子有EJB服務,或SOAP和REST服務。
  4. 消息:兩個系統連接到一個公用的消息系統,互相交換數據,並利用消息調用行為。該風格的例子就是眾所周知的中心輻射式的(hub-and-spoke)JMS架構。

這些風格迥然不同,因為沒有一種解決辦法能在任何情況下都良好運轉。這導致整個中間件領域都在基於這些模式尋求可用的解決辦法,通常被稱為企業服務總線(ESB)。ESB是最終的中間人:它知道如何使用各種語言在各種協議上調解傳遞的消息。

這些架構風格是不同的,它們各有所長。通常,JEE標准存在著不足(坦率地說,現今的任何開發平台都是一樣),與其它系統集成時這些標准並不能提供解決方案。考慮到很多項目都是維護項目,新平台中又有多少技術會使用舊服務或功能呢?少之又少,這太令人驚訝了。

JEE以及後來的Spring在簡化企業編程模型方面都有了長足的進步。JEE進行了標准化並商業化了常見企業問題——數據庫訪問、遠程過程調用、事務、認證、目錄服務等等。除了基本的RPC和消息,JEE中並沒有對EAI解決方案的直接支持。

JMS、REST和SOAP都與平台無關,但這是假設有單一的消息協議。比如說,有一個舊的主機應用,其輸入、輸出都是存放在一些FTP端點上的批處理文件,解決方案要求集成該應用就是不可能的。簡單來說:現今的中間件能很好地處理常見問題,但在特殊情況的處理上就有所不足了。對大多數公告板或電子郵件列表,還是采取訂閱流程。通常,用戶給應用發送電子郵件,應用最終接收電子郵件、針對“訂閱”解析郵件、提取發送的郵件,然後在郵件列表中登記用戶後發送響應。第一反應可能就是基於CRON或通過Quartz構建定時器應用,以輪詢電子郵件,或是為稍後使用的批處理文件去檢查FTP。這種辦法很快就會變得單調而脆弱。

之後復雜性會急劇上升。隨著時間的推移,應用變得更為重要,與商業伙伴、其它應用、其它平台集成的負擔也變得更加昂貴。對必須進行維護的系統來說,每次集成都增加了系統間點對點的新通道。最終,集成各個端點的通道就會成為一個維持不了的爛攤子、復雜的架構。

SpringSource的Spring Integration[2]簡化了編程方式,以此改進了標准的ESB。

Copyright © Linux教程網 All Rights Reserved