私はソフトウェア アーキテクチャについて学び始め、ESBとSCAという用語に出くわしました。これらの用語は同じ目的を果たしているように見えるため、非常に紛らわしいことがわかりました(これらのトピックの達人にはばかげているように聞こえるかもしれませんが、それでも)。
誰でも違いを説明できますか?
どんな助けでも感謝します。
私はソフトウェア アーキテクチャについて学び始め、ESBとSCAという用語に出くわしました。これらの用語は同じ目的を果たしているように見えるため、非常に紛らわしいことがわかりました(これらのトピックの達人にはばかげているように聞こえるかもしれませんが、それでも)。
誰でも違いを説明できますか?
どんな助けでも感謝します。
実際、それらは互いにかなり異なっています。ESB はエンタープライズ サービス バスの略です。これは、企業全体で使用するサービスを分離する方法のパターンです。また、メッセージ (テクノロジーではなくパターン) をさまざまなサービスにルーティングし、それらのメッセージをサービスの期待される形式とプロトコルに変換する、一種の交通警官でもあります。
SCA は Service Component Architecture の略です。IBM と Apache が共同で開発した技術です。これは、サービスをさらに一歩抽象化する方法です。たとえば、Web サービスに SOAP over HTTP を使用する場合、JMS を使用する場合、または HTTP POST で JSON を使用する場合です。これらはすべて、特定のプロトコルとペイロード/メッセージ形式を暗示しています。通常、ある時点でそのプロトコルとフォーマットに「ハードコード」する必要があります。基になるプロトコルを気にしない抽象化された形式を渡すことができたらどうでしょうか? これがSCAがあなたを買うものです。SCA API が前面にあるサービスとインターフェースします。これらのサービス定義の背後には、使用される実際のフォーマット/プロトコルがあります。
さて、これらは競合しているように聞こえますが、そうではありません。SCA のみを使用するか、ESB パターンを使用して、SOA ベースのアーキテクチャ全体を開発できます。または....それらを使用して相互に補完することもできます。
したがって、ESB を定義し、SCA インターフェースを使用して各サービスを接続できます。これにより、バスは SCA インターフェース間でメッセージを変換し、それらのサービスにメッセージをルーティングできます。また、SCA は、これらのサービスの基礎となる形式とプロトコルを隠蔽/抽象化します。
したがって、彼らは実際には互いに争っていません。異なる問題を解決するのに役立つ異なる抽象化。互いに補完し合うことができる抽象化。
製品の例として、IBM には WebSphere Enterprise Service Bus という製品がありました。ブランドが変更されたかどうかはわかりませんが、その名前で知られていたある時点で使用していました。これは、ESB パターンの実装を支援し、システムをサービスとして公開するためのツールを提供する製品でした。WESB (略称) も、サービスが SOAP/HTTP、JMS、MQ、JSON などであったとしても、これらのサービスを接続する手段として SCA を利用しました。
競合するのではなく、互いに補完し合う抽象化テクノロジの別の例として、Spring に対する SCA の利点の質問と私の回答 (およびその他の回答)を参照してください。