如何設計/開發不同的外部服務/應用

Question

目前，我們正在與有可能的ESB或一些類似刀具替換我們的應用程序之一，並尋找一些見解如何最好地處理這個集成層或總線。

我們目前有消耗/與不同的外部服務和數據源，有些是通過SOAP Web服務和其他人，我們只使用一個數據庫連接傳送交互的獨立服務。該服務通過SOAP公開，我們還有其他應用程序使用此服務，但與它緊密耦合，現在我們還有其他需要使用某些外部服務的應用程序，並希望將其全部替換爲ESB或某種SOA平臺。

什麼是更換使用ESB這個「外部」服務集成層的最佳方式？我們正在考慮擁有一個'全局'契約/ API，在這個契約/ API中，我們使用的所有服務都作爲一個單一契約公開，我們使用的所有可能的操作和數據結構都暴露在一個單一的命名空間下，這是否是最好的方法接近這個？如果有的話，是否有任何工具可以幫助我們實現這一流程的自動化，還是我們基本上不得不手工製作這個合同/ API？這也意味着，對於底層服務/ API的任何更改，我們也必須更新這個新的API。

如果不是那麼我看到的另一個選擇是基本上使用'ESB'作爲'代理'層，其中我們所有的來源都是原樣顯示的，所以我們最終會得到幾個不同的'合同'/ API端點，但我並沒有真正看到它的價值。

還給了上述什麼是最好的工具？是一個完整的ESB一個矯枉過正的問題，還是我們更好地使用Apache Camel或Spring Integration之類的東西來滾動我們自己的東西？

的詳細原因：

我們目前正在與更多的積分超過5個不同的外部服務會在未來。

一對夫婦只應用在目前消費我們目前的應用程序，但在未來的幾個其他應用程序/系統將需要消耗一定的這些外部服務。

我們目前使用的通信（SOAP）的一個方法之間的這些服務，但一些應用程序可能會使用發佈/訂閱消息在未來，雖然SOAP仍將是主要使用的協議。

我是新來的ESB集成，所以我提前道歉，如果我誤解了很多這些技術和他們是爲了解決問題。

任何幫助/提示/指針將不勝感激。

謝謝。

Answer 1

您需要對隨着時間的推移想要達成的想法進行一些設計思考。

ESB引入有多種好處和潛在的缺陷。

下面是一些典型的利益/使用情況

• 當你的應用是很難改變或者有非常不同的發佈週期 - 那麼它的convenient有一個ESB中，能夠迅速採取改變中間。當您的組織購買大量COTS產品和雲服務時可能會遇到這種情況，這些產品和雲服務可能會在第二天發佈可能會打破當前API的更新。

• 如果您需要將數據從一個主數據系統調整爲多個其他系統，並且他們可能不支持相同的接口，即CRM系統可能希望通過Web服務儘快導入數據，但ERP需要數據通過db /臨時表和生產系統每週末都需要通過FTP傳送的平面文件中的數據。爲了保持主數據系統的清潔和易於維護，只需在主數據系統中實現一個單一的集成服務，然後將此接口調整爲ESB平臺中的各種其他應用程序。

• 爲保護您的敏感系統而彙集或分解來自各種來源的數據可能是一種用例。假設您有一箇舊系統，可以一次只更新一小部分信息，並且升級該系統並不值得 - 但是可以執行aggreggation或splitting或節流的集成解決方案可能是一個很好的解決方案。

其他優點和用途包括跟蹤和wire tap每封郵件系統之間傳遞的能力 - 這甚至可以與商業智能工具一起使用，以收集KPI：秒。

概念ESB還可以引入用於所有需要通信的服務的canonical message格式。如果許多應用程序與其他幾個應用程序（不僅僅是點對點）共享相同的數據 - 那麼規範消息格式的好處可能會超出成本（這可能很高）。 ESB服務器可能是useful來處理規範數據，因爲它通常非常適合從一種格式映射到另一種格式。

但是，在沒有計劃的情況下引入ESB您嘗試實現的好處並不是什麼好事，因爲它會引入開銷 - 您需要另一臺服務器來保持活力，您可能需要另一個團隊來了解所有數據流。您需要有關集成產品的特殊知識。最後，您需要能夠對其進行一些管理，以便您的ESB計劃不會偏離您預期的目標/收益。

您應該選擇一些您感到舒服的技術 - 或者認爲您可以對此感到滿意。 Apache Camel確實非常強大，我最喜歡的集成引擎 - but it's not an ESB，因爲它沒有提供可用於部署/管理/監視集成服務的運行時。您可以將它與大多數Java EE應用程序服務器一起使用，或者更好 - Apache ServiceMix（= Karaf + Camel + ActiveMQ + CXF）它是爲此任務而構建的。

彈簧集成同樣如此 - 您需要在某處運行它，應用程序服務器或其他軟件。

有很多不同的產品，不論是開源還是商業，都可以做到這些。