33

一部のパートナーは、当社のソフトウェアが Enterprise Service Bus と対話する必要があると言っています。これについて少し調べた後、私の本能は、メッセージをやり取りするためのプラットフォームに依存しない方法が必要であるという単なるうわさ話だと言うことです。私はパートナーが私たちに何を言っているのかを感じようとしているだけです。ソフトウェアを流行語に準拠させようとしているだけだとパートナーの要求を却下するのは正しいですか、それとも彼らは私たちが耳を傾けるべきことを言っているのですか (流行語でエンコードされていても)?

4

6 に答える 6

38

ESB はメッセージングに基づいていますが、「単なる」メッセージングではなく、流行語でもありません。

したがって、単純な古い非同期メッセージングから始めると、初期のネットワークは非常にポイントツーポイントになる傾向がありました。各接続と宛先の各ペアを接続する (つまり、何らかの管理インターフェースを介して構成する) 必要があり、あえて何かを移動しようとすると、必ず何かが壊れました。接続ポイントは手作業で配線されていたため、これらのネットワークは高い接続密度を実現できませんでした。増分コストが高すぎて、スケーリングできませんでした。また、トポロジには多くのアクセス制御とポリシーが組み込まれていました。接続密度の欠如は、柔軟性を妨げますが、実際にはセキュリティに対するこのアプローチを支持します。

ESB は、これらの問題に対処しようとしています...

  • 宛先/サービス/リソースのランタイム解決
  • 場所の透明性
  • Any-to-Any 接続と最大接続密度
  • 冗長性、水平方向のスケーラビリティ、フェイルオーバーを考慮した設計
  • トポロジから外部化されたポリシー、アクセス制御、ルール
  • 物理メッセージング ネットワーク層の上に実装された論理メッセージング ネットワーク層
  • 共通の名前空間

したがって、顧客が ESB の互換性を求める場合、上記のようなものを求めます。アプリケーションの観点からは、これは次のことも意味します...

  • 厳密な順序で処理する必要がある、または要求を一般的なネットワーク宛先ではなく特定のノードにのみアドレス指定する必要があるなど、メッセージの類似性を回避する
  • 実行時に宛先を動的に解決する機能 (つまり、キューの別のインスタンスを追加すると、トラフィックの取得が自動的に開始され、1 つを削除して、残りのノードへのトラフィック ルート)
  • リクエスター アプリとプロバイダー アプリは、互いの "住んでいる" 場所を知ることから分離されています。リクエスタは、呼び出す必要があるサービスの数に関係なく、1 つの接続を確立します
  • トポロジではなくポリシーで承認する
  • 重複を認識して処理できるサービス プロバイダー アプリ (JMS 仕様に従って、セッション処理による「機能的重複」を参照)
  • サービス プロバイダー アプリケーションの複数のアクティブなインスタンスを実行する機能
  • 実際のトランザクションを送信せずにネットワークのステータスを照会したり、テストを実行したりできるように、サービス プロバイダー アプリケーションをインストルメント化します。

一方、クライアントがこれらのことを明確に説明できない場合は、「ESB で動作する」というボックスにチェックを入れたいだけかもしれません。

于 2010-07-01T03:12:55.480 に答える
26

流行語を使わないようにします (ただし、話題の頭字語が忍び寄るかもしれません)。

サービス/アプリケーション/メインフレーム/など... を統合したい (つまり、互いにメッセージを送信したい) 場合、かなり混乱してしまう可能性があります。ESB は、その混乱をそれ自体 (またはそれ自体) の内部に隠して、組織が混乱がなく、管理可能な何かがあるふりをすることができるようにします。次に、これにすべての機能をラップして、このような高価な製品を購入する決定を下す組織の上級者にとって、このボックスをさらに魅力的なものにします. これらの人々は通常、「何かをしている」ことを証明し、多額のお金を使う方法を知っていることを証明するために多額の費用がかかる大規模なイニシアチブを導入したいと考えています.

したがって、ESB は次のようになります。

  1. ベンダーが大金を稼ぐための手段。
  2. コンサルタントが大金を稼ぐための手段。
  3. 上級管理職 (IT ディレクターなど) が多額の費用を費やすことができることを示す方法。
  4. 混乱を隠すためのボックス。
  5. 技術チームが協力するための総合的な PITA。
于 2011-03-16T18:23:13.210 に答える
9

これについて少し調べた後、私の本能は、これはメッセージをやり取りするためのプラットフォームに依存しない方法が必要であると言っている単なる話題であると言うことです

ESB という用語は、合法的であろうとなかろうと、常に別のバズワードとうまく適合する良い言葉であるため、あなたは正しいです。ほら、それが貢献者かもしれません）

プラットフォーム ニュートラル デバイスが必要なもう 1 つの理由は、使用するサービスが、特定のマシン リソースではなく、中央の場所からエンドポイントとして常に公開されるようにするためです。ESB は、サービスの実際の物理的なエンドポイントをそれらに無関係にします。いずれにせよあまり気にするべきではありませんが、これにより、サービスを移動することができますが、それらは ESB エンドポイントを消費するだけです。

Discoveryの集中リポジトリとは別に、ESB はサービスのサイド バイ サイド バージョン管理も容易にします。私に選択肢があり、私の会社に予算があれば、IBM の x150 アプライアンスを購入していたでしょう :(

第 3 に、SoftwareAG の製品のように、より高度なバスの多くは、アダプターを介したコーディングを必要とせずに、サービスとしてメイン フレームにあるデータなどのレガシー データをネイティブに公開できます。

彼らの意図がESBが提供するすべての利点を活用することなのか、それともあなたが言ったように流行語に準拠させることなのかはわかりません.

于 2010-06-16T17:44:49.693 に答える
7

これについて少し調べた後、私の本能は、これはメッセージをやり取りするためのプラットフォームに依存しない方法が必要であると言っている単なる話題であると言うことです

それはほぼ正しいです。ESB がさらに進んで、メッセージ配信の保証、確認/確認メッセージなどの追加機能を含む場合があります。ESB が存在すると、通常、明示的または暗黙的に、以前には存在しなかった新しいプロトコルが作成されます。これは、もう 1 つの重要な考慮事項です。(つまり、メッセージのフォーマットに関して、ある種の標準またはインターフェースを設定する必要があります。)

ソフトウェアを流行語に準拠させようとしているだけだとパートナーの要求を却下するのは正しいですか、それとも彼らは私たちが耳を傾けるべきことを言っているのですか (流行語でエンコードされていても)?

最初はばかげているように思えても、常に顧客の声に耳を傾ける必要があります。通常、何が起こっているのかを判断するために少なくとも労力を費やす価値があります。行間を読むと、パートナーが意味することはおそらく、あなたのサービスを自社のサービスや製品とより簡単に統合する方法を望んでいるということです。

于 2010-06-16T17:37:58.757 に答える
6

エンタープライズ サービス バスは、システム間のメッセージングを標準的な方法で処理します。これにより、すべてのプラットフォームでまったく同じ方法でバスと通信でき、バスは特定のエンドポイントに必要な個々の通信メカニズムへの実際の変換を処理します。これは、共通のメッセージング スキームを使用してバスと対話するすべてのコードを記述し、バスが共通のスキームを取得して変換し、エンドポイントが理解できるようにすることを意味します。

于 2010-06-16T17:40:55.693 に答える
0

最も簡単な説明は、それが提供するものを説明することです:

長年にわたり、企業は、財務から人事まで、ビジネスの特定の機能を実現するために、さまざまなプラットフォームとテクノロジを取得してきました。これらのシステムはデータを共有するために相互に通信する必要があったため、ミドルウェアが接続を可能にする接着剤になりました。企業が気付く前に、彼らはこれらのシステムとミドルウェアのそれぞれのサポートと保守にお金を払っていました。ビジネスのニーズが変化したため、部門は、古いソリューションをニーズに合わせて柔軟にしようとするのではなく、特別なニーズに対応する独自のカスタム ソリューションを作成することを決定しました。いつの間にか、レガシー システム、ミドルウェア、およびカスタム ソリューションのサポートと維持にお金を払っていました。Sarbanes Oxley のような新しい法律により、企業は報告目的でより良い情報を入手できるようにする必要があります。単一のビューでは、すべてのシステムからデータをキャプチャする必要があります。さらに、CIO は現在、コストの削減と顧客サービスの向上を迫られています。明らかな解決策の 1 つは、冗長なシステム、高価なサポートとメンテナンスの契約、専門家によるサポートが必要な高コストのレガシー ソリューションを排除することです。新しいプラットフォームに移行することでこれが可能になりますが、移行が必要です。ビジネスが行っていることを再現できるターンキー ソリューションはありません。一般的なエンティティを介して情報にアクセスできるため、情報を移動する必要性に対処するために SOA が使用されます。サービス バスから AllEmployees を要求すると、それが 15 の HR システムからのものか 1 のものかを取得します。15 の HR システムが 1 つのシステムになると、呼び出しと結果は変わりません。

于 2011-03-18T20:46:01.337 に答える