是一個服務器或服務器集羣上ESB的標準實現嗎？

我已經使用了SOAP，但是我從未使用過SOA，ESB和其他企業應用程序集成模式。我發現關於ESB的文檔很混亂。是一個服務器或服務器集羣上ESB的標準實現嗎？

有些東西我不確定要用ESB來理解。我知道這是一個概念，將企業網絡描述爲公共汽車，並不是一個具體的東西，但仍然是。

我可以理解，ESB提供與舊服務的協議和消息轉換，允許編排，並且ESB完成消息目標的邏輯。但是我也將ESB想象成不同ESB服務器之間的中間件（而不僅僅是Web服務接口）。

如果我以ServiceMix爲例，我認爲在通過公共總線/協議（NMR？JMS？）交互的不同服務器上安裝多個ServiceMix平臺是很自然的。因此，我使用CAMEL（例如使用某些Web服務）創建的ServiceMix（a）上的服務可能會使用也由CAMEL創建的ServiceMix（b）上的服務。

因此，如果我的服務需要其他服務，我只需提及它的標識符，並且ESB會將我的請求路由到正確的ServiceMix平臺。

但是當我閱讀有關ServiceMix的示例時，在我看來，ServiceMix被預先用作獨立應用程序服務器。不是一組服務器。

ESB只是一個提升的應用程序服務器嗎？（分解它提供的集成功能）

實際上SOA中有多個ESB嗎？它們是否與ESB內部的協議相鏈接？或者，在ESB上實現的服務（a）必須提供像SOAP這樣的外部接口，以便ESB（b）可以使用它的服務？

來源

2012-04-23 Vincent Hiribarren

ESB經常被用作一種營銷概念，您可以將它作爲一箇中間條，在其中插入所有內容。這大大簡化了企業集成，因爲ESB內部可能會出現與之前相同的混亂情況。

通常ESB實現爲具有適配器和路由核心的應用程序服務器。我個人認爲，與一臺應用程序服務器集成並不是一個好的架構選擇。原因在於你泄露了太多的信息以便以這種方式集成到系統中。中央平臺將知道它與數據庫結構或專有連接協議集成的應用程序的內部細節。

另一方面，可以關心路由和轉換的平臺的想法是一個很好的概念，如果正確完成，它可以提供很多幫助。

我認爲一個更好的架構是在SOA中擁有公共傳輸和格式的概念，並使用依賴業務語言和思維的模型創建服務。要做到這一點，您需要在您整合的系統附近安裝適配器。這導致了一個分散的ESB，看起來更像你所描述的。請記住，儘量使公共交通和數據格式非常標準化。

我對使用消息傳遞系統作爲中央傳輸和純XML或SOAP作爲數據格式有很好的經驗。另一個不錯的選擇是REST。也可以將兩者結合起來。

Servicemix或Karaf + Camel + CXF可以爲應用程序以及路由和轉換邏輯提供適配器。另外，您可以使用駱駝和CXF將適配器嵌入到您的應用程序中。JMS或REST將允許連接容器和外部適配器。

來源

2012-04-24 08:32:10

謝謝它幫助我瞭解了ESB，但ServiceMix通常被稱爲OSGI容器，帶有CAMEL，CXF和ActiveMQ模塊，看起來更像是一個模塊/版本管理平臺。那麼它是否像通過CAMEL或CXF或消息傳遞來開發連接器和適配器以連接到ServiceMIX中的外部應用程序？這在每個稱爲ESB的產品中都是如此嗎？我可能在這裏錯過了一些關鍵點，所以如果我在這裏丟失了重要的東西，請更正 – Chakri 2014-09-08 05:07:27

是的。您使用cxf和camel以及activemq開發連接器和適配器。卡拉夫只是管理模塊。這在每個ESB產品中都不會發生。大多數ESB更單一，但有些工作是這樣的。 – 2014-09-08 06:47:01

感謝您的回覆。通過單片，我明白他們自己提供連接器/適配器，並隱藏大部分內部工作，並提供一些固定的指導原則來使用ESB和專有術語，如Oracle Service Bus或IBM Integration Bus等。如果可能的話，還請提供一些建議在構建階段依賴管理與OSGi中的運行時使用ServiceMix，因爲我已經問過 - http://stackoverflow.com/questions/25718033/dependency-management-in-osgi-bundle-servicemix – Chakri 2014-09-08 07:03:14

簡而言之，企業服務總線更多是一個架構概念。這個想法是實現業務服務方面的集成。 ESB實際上可以實現爲一組策略和指南，其中應用程序就給定的一組格式和給定的通信協議（SOAP/WS，消息傳遞等）達成一致，用於描述服務等的方式。

ESB服務器（Service Mix，IBM WebSphere Message Broker，JBoss ESB，Mule ESB，MS BizTalk Server，您的名字）本質上提供了實現這一點的工具箱。通常需要根據每種情況和企業環境來決定服務器的數量，拓撲結構，使用什麼協議/數據格式等。由批量控制的傳統/主框架系統組成的應用程序環境需要非常不同的集成設置，例如事件驅動的Java EE或.NET應用程序堆棧。

來源

2012-04-24 19:41:26

舊主題 - 但我認爲你需要圍繞消息總線系統構建一個ESB。

ESB可能提供其他訪問方式，例如HTTP，FTP等ESB固有地可以託管應用程序，或者讓您無縫連接到另一個外部應用程序，與協議無關，因爲它在內部進行中介。您可以儘可能多地縮放它。例如您可以在ESB的3個實例中部署相同的應用程序，並在面向消息的中間件上負載均衡 - 即，您將消息發送到隊列中，並且所有ESB實例都在偵聽，並且只有一個實體在點對點模型中進行拾取。然後您可以通過建立一個MoM集羣並將消息發送到任何實例來進一步擴展 - 這兩個實例都承載相同的隊列。

來源

2013-03-05 09:15:47 Soumya

是一個服務器或服務器集羣上ESB的標準實現嗎？

回答

相關問題