4

私が現在関わっているプロジェクトでは、プレゼンテーション層コンポーネント (つまり Web アプリケーション) によって消費される Web サービスにビジネス ロジックを実装する必要があります。

同社には Enterprise Service Bus があり、開発された最新のほぼすべての Web サービスがこのバスを通じて公開されています。ESB を介していつサービスを公開するかについて何人かの同僚に尋ねたところ、次のような回答が得られました。

  • ESB がある場合は、それを介してすべてを公開します。負荷分散や場所の透過性など、いくつかの利点があります。
  • ESB がプロキシとしてのみ機能する場合 (つまり、メッセージ変換を行わない場合) は使用しないでください。ESB に過負荷がかかり、パフォーマンスが低下します。ポイントツーポイント接続を行う方がよいでしょう。
  • プロトコル変換がある場合 (ストアド プロシージャを SOAP サービスとして公開するなど)、ESB を介してコンポーネントを公開する必要があります。これが存在しない場合は、Point-to-Point を使用することをお勧めします。

したがって、いつ Web サービスを公開するか、公開しないかについて、一般的な合意やベスト プラクティスがあるかどうかに興味があります。読書/参照は大きな助けになります。

4

1 に答える 1

7

私の見解では、SOA テクノロジで 4 年間の経験を積んだ後、ESB を使用すると常にシステムに負荷がかかります。これは、新しいレイヤーを追加して、すべての通信をそこに通すためです。変換 (メッセージングまたはプロトコルのいずれか) とルーティングは、ESB なしで達成するのは難しくありません。ポイント ツー ポイント通信のスループットは少し高くなります。ビジネスプロセスの自動化でも同じことが起こります.ESBを必要とせずにそこに到達する方法があります.

一方、ESB の使用には、企業の範囲内でいくつかの利点がありますが、それはビジョンと戦略の範囲内でなければなりません。最良の例の 1 つは、幅広いツールを使用して長い間取り組んできた会社です。それぞれのツールは特定の目的のために使用され、会社はサイロで作業するチームに分散され、チームは他のチームから分離されています。チーム間のやり取りが複雑で遅くなるのは久しぶりです。十分に計画された SOA 戦略は、これらすべてのツールを統合し、それらをより意味のある軽量アイテムに置き換え始めるのに役立ちます。

したがって、私見ですが、企業戦略なしに単一のプロジェクトでいくつかの「問題」を解決するためだけにESBを使用することは良い考えではありません。最終的に、問題がそうでない場合、 SOAという言葉は会社で禁止されます。 SOA 自体は、むしろビジョンと企業戦略の欠如によるものです。

ESB の使用に関して私が見つけた唯一の経験則は次のとおりです。単一のプロジェクトでの変換、ルーティング、ビジネス プロセスの自動化 (人間の介入の有無にかかわらず) などの要件は、SOA への移行の兆候ではありません (ほとんどすべてのプロジェクト)。変換、ルーティング、ビジネス プロセスの自動化を実行する必要があります) が、これらのニーズが企業全体のニーズである場合は、技術的な観点ではなく、ビジネスの観点から考える価値があります。ビジネスの視点がなければ、SOA は失敗します。

これは非常に幅広いトピックであり、議論は何年にもわたって続く可能性があります。さらに読むためのリンクをいくつかお勧めします。

于 2012-08-09T16:03:51.793 に答える