我有一個關於集成設計的問題。我們正在採用使用JBoss Fuse Service Works套件的SOA。現在，它的提出一個大問題：當我們開發新服務/應用程序，我們是否應該爲了在SOA平臺上託管而遷移應用程序？
我們應承載它的保險絲服務的工作原理和發展它的基礎上專門開關場？這一決定導致了所有的業務邏輯將在開關站 
放在另外，我們開發了基於獨立平臺的新服務/應用程序（它可以是任何開源框架，可能使REST，SOAP服務）。這個決定導致該服務擁有自己的業務邏輯。 
任何想法？
使用ESB時總要記住的一件事是ESB是一個集成服務器而不是應用程序服務器。 ESB在那裏促進各種應用程序之間的通信。如果您在ESB中構建應用程序，則ESB現在將綁定到該應用程序，簡而言之，ESB不應該包含業務邏輯。
一個ESB旨在做到以下幾點：
讓人困惑的部分是ESB可以「託管」業務邏輯，但它不是合適的地方。讓我解釋。大多數企業都有幾個軟件包，如CRM，客戶端數據庫和市場營銷數據庫。 CRM可以有一個用於搜索某人的SOAP接口，客戶端數據庫可能需要SQL查詢，市場營銷數據庫可能有一個REST接口。所有這些系統及其接口都稱爲提供者/生產者。
如果我想創建一個人員記錄的企業級搜索，將需要一個搜索工具來與所有提供者接口進行交互）。這是ESB最有意義的地方。
在這種情況下，一種方法可能是設計一個用於執行企業範圍搜索的SOAP Web服務。您將創建一個新的服務，它具有執行搜索所需的操作和數據結構，但您不會直接公開提供程序接口。始終在ESB上使用抽象。新服務將其操作和數據結構映射到提供者數據結構。
所以你將有一個服務，可以調用三個接口。這樣做的最大優點是，例如，當您將客戶數據庫升級爲使用REST服務時，您可以更改從企業範圍服務到客戶數據庫接口的映射，而無需更改其他服務。
想想這樣。在ESB上公開抽象服務時，如果不將數據使用者綁定到特定提供程序，則可以在後端更改thr提供程序並重新映射。你的消費者不會受到影響。
一個這樣的現實世界的例子是，當銀行有不同的銀行業務後端，但他們使用IFX協議相互溝通。數據提供者是信用卡機器，ATM還是SAP銀行模塊並不重要。他們都說IFX。
所以在你的情況下去選項二。讓應用程序承載業務邏輯和ESB託管集成。
希望這會有所幫助。