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

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

• 應(yīng)用程序本質(zhì)上是異構(gòu)的，它們使用不同的語言開發(fā)，在不同的OS上運(yùn)行，理解不同的數(shù)據(jù)格式。
• 應(yīng)用程序發(fā)生了很大的變化，它們進(jìn)行了升級，并且它們的API隨時間而變化。
• 他們需要以可靠和安全的方式通過網(wǎng)絡(luò)交換數(shù)據(jù)。

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

整合風(fēng)格：

文件傳輸

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

共享數(shù)據(jù)庫

在這里，應(yīng)用程序使用通用的數(shù)據(jù)庫架構(gòu)。

訊息傳遞

實(shí)體在想要交換數(shù)據(jù)的應(yīng)用程序之間進(jìn)行中介。 它的工作是接受生產(chǎn)者的消息，然后傳遞給消費(fèi)者。 消息傳遞有助于在集成應(yīng)用程序時實(shí)現(xiàn)松散耦合。 它將連接的應(yīng)用程序與隨時間變化的API更改/升級隔離。

RPC

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

下一組模式討論消息系統(tǒng)：

信息

消息的結(jié)構(gòu)由所使用的消息傳遞系統(tǒng)很好地定義。 它通常包含標(biāo)題和正文部分。

訊息頻道

通道是產(chǎn)生消息的媒介。 它們是通常的隊列和主題。

管道和過濾器

當(dāng)需要在將消息傳遞到消費(fèi)者應(yīng)用程序之前對其進(jìn)行處理時，此模式很有用。

訊息路由器

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

訊息翻譯器

翻譯器用于更改消息的格式。 在接收方應(yīng)用程序理解XML的同時，發(fā)送方應(yīng)用程序可能會發(fā)送CSV數(shù)據(jù)，在這種情況下，我們需要在接收方應(yīng)用程序之前執(zhí)行轉(zhuǎn)換器，以完成CSV到XML的轉(zhuǎn)換。

消息端點(diǎn)

端點(diǎn)是幫助應(yīng)用程序與之交互的組件
消息傳遞系統(tǒng)。它們具有用于與之通信的內(nèi)置協(xié)議
消息傳遞系統(tǒng)。它們是消息產(chǎn)生者和消費(fèi)者。

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

對等2對等

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

發(fā)布訂閱

向所有訂閱用戶廣播消息的頻道。 主題屬于發(fā)布訂閱性質(zhì)。

死信頻道

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

訊息橋

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

保證交貨

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

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

命令訊息

這些指定接收方應(yīng)調(diào)用的方法或功能。 考慮使用XML的情況，根節(jié)點(diǎn)可以指定方法名稱，而子元素可以指定方法調(diào)用的參數(shù)。

文件訊息

當(dāng)發(fā)送方傳遞數(shù)據(jù)但不知道接收方應(yīng)如何處理時。

活動訊息

發(fā)件人發(fā)送有關(guān)其末尾發(fā)生的更改的通知消息。
在這里，接收者可以選擇忽略它或?qū)ζ渥龀龇磻?yīng)。

要求回覆

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

相關(guān)標(biāo)識符

如果響應(yīng)是異步接收的，則用于關(guān)聯(lián)
響應(yīng)及其相應(yīng)的請求。

路由模式

基于內(nèi)容的路由

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

訊息篩選器

當(dāng)接收方僅對具有某些屬性的消息感興趣時，則需要應(yīng)用過濾器。 此功能通常隨消息傳遞系統(tǒng)內(nèi)置。

分離器

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

聚合器

聚合器的作用與拆分器相反。 它關(guān)聯(lián)并合并類似的消息。

轉(zhuǎn)型模式

內(nèi)容豐富

擴(kuò)充器負(fù)責(zé)向消息中添加其他信息。
如果不存在所有用于處理消息的數(shù)據(jù)，則需要這樣做。

內(nèi)容過濾

內(nèi)容過濾器執(zhí)行相反的操作，即從郵件中刪除不需要的數(shù)據(jù)。

歸一化

規(guī)范化器負(fù)責(zé)轉(zhuǎn)換到達(dá)不同位置的消息
格式轉(zhuǎn)換為通用格式。 您的應(yīng)用程序需要具有接受能力 JSON，XML，CSV等格式的數(shù)據(jù)，但是處理邏輯只能理解XML，在這種情況下，您需要使用規(guī)范化器。

端點(diǎn)模式

交易客戶

交易客戶有助于與外部交易服務(wù)進(jìn)行協(xié)調(diào)。

郵件調(diào)度程序

消息分派器是接收者將到達(dá)的消息分派給工作人員的一種模式。 工人負(fù)責(zé)處理消息。

事件驅(qū)動的消費(fèi)者

在此，接收者在消息傳遞系統(tǒng)上注冊一個操作；
在收到消息后，消息傳遞系統(tǒng)將調(diào)用該操作。

系統(tǒng)管理模式：這些模式指定了有效監(jiān)視和管理系統(tǒng)的方式。

車輛改道

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

絲錐

在這里，消息被復(fù)制到通道，隨后被檢索以進(jìn)行檢查或分析。

留言庫

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

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

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

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

總結(jié)

以上是生活随笔為你收集整理的企业集成模式简介的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。