現在、私たちのアプリの 1 つを ESB または類似のツールに置き換えることを検討しており、これに最も適した方法についての洞察を探していました。
現在、さまざまな外部サービスおよびデータ ソースを消費/対話するスタンドアロン サービスがあり、SOAP Web サービスを介して提供されるものもあれば、DB 接続を使用するだけのものもあります。このサービスは SOAP を介して公開されており、このサービスを使用する他のアプリがありますが、非常に密接に結合されています。外部サービスの一部を使用する必要がある他のアプリもあり、これをすべて ESB または ESB に置き換えたいと考えています。ある種の SOA プラットフォーム。
この「外部」サービス統合レイヤーを ESB に置き換える最善の方法は何でしょうか? 私たちは、使用するすべてのサービスが単一のコントラクトとして公開され、使用可能なすべての操作とデータ構造が 1 つの名前空間で公開される「グローバル」コントラクト/API を持つことを考えていましたが、これが最善の方法でしょうか?これに近づくのは？もしそうなら、このプロセスを自動化するのに役立つツールはありますか、それとも基本的にこのコントラクト/API を手作りする必要がありますか? これは、基盤となるサービス/API に変更があった場合、この新しい API も更新する必要があることを意味します。
そうでない場合、私が見る他のオプションは、基本的に「ESB」をすべてのソースがそのまま公開される「プロキシ」レイヤーとして使用することです。そのため、いくつかの異なる「コントラクト」/ API エンドポイントになりますが、これには本当に価値がありません。
また、上記を考えると、仕事に最適なツールは何ですか? 本格的な ESB はやり過ぎですか、それとも Apache Camel や Spring Integration などを使用して独自に展開する方がはるかに優れていますか?
さらにいくつかの詳細：
現在、5 つ以上の異なる外部サービスを統合しており、将来的にはさらに多くのサービスを統合する予定です。
現時点では、現在のアプリを使用するアプリは 2 つだけですが、将来的には他のいくつかのアプリ/システムがこれらの外部サービスの一部を使用する必要があります。
現在、これらのサービス間で単一の通信方式 (SOAP) を使用していますが、将来的に一部のアプリで pub/sub メッセージングが使用される可能性がありますが、SOAP が引き続き使用される主なプロトコルになります。
私は ESB 統合に慣れていないので、これらの技術の多くと、それらが解決しようとしている問題について誤解していた場合は、あらかじめお詫び申し上げます。
ヘルプ/ヒント/ポインターは大歓迎です。
ありがとう。