在此博客文章中，我們將介紹一些企業集成模式。 這些是旨在解決集成挑戰的已知設計模式。 閱讀此書后，您將可以設計集成解決方案。

EIP（簡而言之）是已知的設計模式，可為應用程序集成過程中遇到的問題/問題提供解決方案。 我想到的一個顯而易見的問題是，在集成應用程序時我們需要處理哪些問題/問題？

• 應用程序本質上是異構的，它們使用不同的語言開發，在不同的OS上運行，理解不同的數據格式。
• 應用程序發生了很大的變化，它們進行了升級，并且它們的API隨時間而變化。
• 他們需要以可靠和安全的方式通過網絡交換數據。

EIP分為以下類別。 鄰近這些，還指定了用于引用這些模式的符號。

整合風格：

文件傳輸

在這種模式下，應用程序使用文件交換信息，文件在某個公共位置共享。

共享數據庫

在這里，應用程序使用通用的數據庫架構。

訊息傳遞

實體在想要交換數據的應用程序之間進行中介。 它的工作是接受生產者的消息，然后傳遞給消費者。 消息傳遞有助于在集成應用程序時實現松散耦合。 它將連接的應用程序與隨時間變化的API更改/升級隔離。

RPC

在此應用程序中，使用接口公開其功能，調用者需要知道這些并使用存根調用它們。 除了RPC以外，以上三種機制本質上都是異步的。

下一組模式討論消息系統：

信息

消息的結構由所使用的消息傳遞系統很好地定義。 它通常包含標題和正文部分。

訊息頻道

通道是產生消息的媒介。 它們是通常的隊列和主題。

管道和過濾器

當需要在將消息傳遞到消費者應用程序之前對其進行處理時，此模式很有用。

訊息路由器

當發送方應用程序不知道接收方在哪個通道上時
已訂閱。 在兩者之間使用路由器在網絡上傳遞消息。 正確的頻道。 它具有路由規則，該規則決定消息的位置 應交付。

訊息翻譯器

翻譯器用于更改消息的格式。 在接收方應用程序理解XML的同時，發送方應用程序可能會發送CSV數據，在這種情況下，我們需要在接收方應用程序之前執行轉換器，以完成CSV到XML的轉換。

消息端點

端點是幫助應用程序與之交互的組件
消息傳遞系統。它們具有用于與之通信的內置協議
消息傳遞系統。它們是消息產生者和消費者。

通道模式：這些模式討論消息傳遞通道的屬性。

對等2對等

向單個使用者傳遞消息的渠道。 例子是一個隊列

發布訂閱

向所有訂閱用戶廣播消息的頻道。 主題屬于發布訂閱性質。

死信頻道

用于移動無法處理的消息的通道。 消費者無法理解或消息過期的情況。 從監視和管理的角度來看，這很重要。

訊息橋

這些是橋接不同消息傳遞系統的通道適配器。 考慮有兩種企業系統的情況，一種使用Mircosoft的MQ，而另一種使用IBM的MQ服務器。 在那里，您需要一個可以連接這些橋梁的橋梁。

保證交貨

持久性通道用于保證消息傳遞。 萬一消息系統崩潰，它將丟失內存中存在的所有消息。 因此，通常會備份通道的持久性存儲，其中存儲了通道中的所有消息。

消息構造模式：這些模式用于指定消息的意圖。 接收者收到消息后該怎么辦？

命令訊息

這些指定接收方應調用的方法或功能。 考慮使用XML的情況，根節點可以指定方法名稱，而子元素可以指定方法調用的參數。

文件訊息

當發送方傳遞數據但不知道接收方應如何處理時。

活動訊息

發件人發送有關其末尾發生的更改的通知消息。
在這里，接收者可以選擇忽略它或對其做出反應。

要求回覆

在這種情況下，發送者希望得到回復。 消息可能由兩部分組成，一部分包含請求，另一部分由接收者填充，即響應。

相關標識符

如果響應是異步接收的，則用于關聯
響應及其相應的請求。

路由模式

基于內容的路由

檢查消息以確定正確的通道。 使用XML的地方，規則是用XPath編寫的。

訊息篩選器

當接收方僅對具有某些屬性的消息感興趣時，則需要應用過濾器。 此功能通常隨消息傳遞系統內置。

分離器

如果消息批量到達。 需要使用拆分器將消息分解為可以單獨處理的部分。

聚合器

聚合器的作用與拆分器相反。 它關聯并合并類似的消息。

轉型模式

內容豐富

擴充器負責向消息中添加其他信息。
如果不存在所有用于處理消息的數據，則需要這樣做。

內容過濾

內容過濾器執行相反的操作，即從郵件中刪除不需要的數據。

歸一化

規范化器負責轉換到達不同位置的消息
格式轉換為通用格式。 您的應用程序需要具有接受能力 JSON，XML，CSV等格式的數據，但是處理邏輯只能理解XML，在這種情況下，您需要使用規范化器。

端點模式

交易客戶

交易客戶有助于與外部交易服務進行協調。

郵件調度程序

消息分派器是接收者將到達的消息分派給工作人員的一種模式。 工人負責處理消息。

事件驅動的消費者

在此，接收者在消息傳遞系統上注冊一個操作；
在收到消息后，消息傳遞系統將調用該操作。

系統管理模式：這些模式指定了有效監視和管理系統的方式。

車輛改道

顧名思義，將更改消息的路徑以執行諸如驗證，日志記錄等活動。這種額外的處理是基于控制的，出于性能原因可以將其關閉。

絲錐

在這里，消息被復制到通道，隨后被檢索以進行檢查或分析。

留言庫

當消息從接收者傳遞到處理單元時，整個消息或消息的一部分（標頭或消息主體的某些屬性）都存儲在中央位置。

要深入了解更多信息，請訪問eaipatterns.com，它已經詳細闡述了這些模式。 在接下來的博客文章中，我們還將研究Apache Camel，它為許多這些模式提供了實現。

參考： NS.Infra博客上我們JCG合作伙伴 Abhishek Jain的企業集成模式簡介 。

翻譯自: https://www.javacodegeeks.com/2012/11/introduction-to-enterprise-integration-patterns.html