Spring Integration入門

為什麼使用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。