Tibcoの何がそんなに特別なのか理解できません。
彼らのマーケティング資料は、TCPがクライアントによる受信の確認を必要としない悲観的なトランスポートプロトコルであることを強調しています。どうしてこれが真実なのか?
私にとって、Tibcoは基本的にキューに裏打ちされたTCPプロトコルです。
誰かがTibcoの主なセールスポイントを理解するのを手伝ってくれませんか?私はマネージャーに、私たちがここで完全に引き裂かれていると言って暴言を吐きかけようとしています。
Tibcoの何がそんなに特別なのか理解できません。
彼らのマーケティング資料は、TCPがクライアントによる受信の確認を必要としない悲観的なトランスポートプロトコルであることを強調しています。どうしてこれが真実なのか?
私にとって、Tibcoは基本的にキューに裏打ちされたTCPプロトコルです。
誰かがTibcoの主なセールスポイントを理解するのを手伝ってくれませんか?私はマネージャーに、私たちがここで完全に引き裂かれていると言って暴言を吐きかけようとしています。
RV (Rendezvous) が主要なメッセージング プロトコルであるため、RV (Rendezvous) を使用することになると思います。
これは、UDP ベースのブロードキャストに似たプロトコルであり、TCP よりも高速ですが、クライアントの確認応答が必ずしも必要ではありません。
それをサポートする構成 (認定されたメッセージング) があるため、TCP と UDP のどちらであるかは、実際に何をしようとしているのか次第です。
Tibco (BusinessWorks) が追加する価値は、シンプルで分かりやすいミドルウェア アプリケーション デザイナーを提供し、負荷分散されたフォールト トレラントな環境にアプリを簡単に展開できるようにすることです。あらゆる種類のコネクタ (soap、http、jdbc、jms など) を提供して、必要なものに接続し、さまざまな形式で吐き出します。
どのような用途でお使いになるのか、詳しい情報をいただけると助かります。
ps。RV の代わりに、EMS (JMS 実装) を使用します。
RV 対 EMS:
付加価値は、「信頼できるマルチキャスト」とプラットフォームに依存しないことです。すべての真ん中に rvd があるアーキテクチャ全体はちょっとばかげているので、私の意見では、ここにいる私たちと同じように、他のすべての人がそれらにお金を払っています:)
良い質問ですが、TCPソケットを介して500人のコンシューマーを接続しようとしたことがありますか?
メッセージレートも高い場合(> 10,000メッセージ/秒)、UDPを使用することになります(コピーではなく、すべてのコンシューマーへの1つのメッセージ!)。しかし、TCPの信頼性はありません。PGMまたはTRDPがそのような要件を満たしているので、TIBCORVは非常に便利で/私が知っている中で最高のものであることがわかりました。C APIは非常に高速です(10,000 msgs /秒を超える場合はJavaを忘れてください)。
もちろん、独自の信頼できるマルチキャストをロールすることもできますが、RV APIは非常に使いやすく、多くの異なるプラットフォームに移植されます。使いやすさがTCPに対する主な論拠だと思います。ジュニアプログラマーに安定した動作するRVpub/ subアプリケーションの作成方法を教えるには、1日かかります。また、TCPでも同じことを行うには1か月かかります。
rvd自体はそこにあり、見えないのに、なぜそれを心配するのでしょうか。
ファンアウトが問題にならない場合(1-1または1-5シナリオ)、代わりにTIBCO EMS(または別のJMSプロバイダー)またはAMQPを調べてください。
また、TCPに対するもう1つの実際の利点は、サブジェクト(またはJMSトピック)です。20の異なるアプリケーションを統合する場合、それは大いに役立ちます。
それは本当にあなたが誰であるか、そしてあなたの目標が何であるかに依存します. TIBCO については、金融サービス業界の競合他社の多くが、処理のために Web ベースのフロント エンドからメインフレームにメッセージを安全に送信し、株価情報などをフロント エンドに配信するために使用するメッセージング システムであったことを知っています。
私たちは、会社の上層部の 1 人が以前働いていたメッセージング製品に奇妙に似ている独自のメッセージング製品を持っていました :)
私たちには 3 億の技術予算がありましたが、2 つの大規模なデータセンターといくつかの生産センター、および開発用の 3 つのオフィスもあったことを覚えておいてください。
現在、私たちのような状況にある企業は、TIBCO のようなものをすぐに使用するのが得策であると考えるかもしれません (おそらく、その 3 億ドルのかなりの部分を節約できたはずです)。
そのような予算がなく、要求がはるかに少ない場合、それは実際に「ぼったくり」である可能性があります. しかし、私が働いていたような組織のために、そのようなシステムを自分で開発するには、その 3 億のかなりの部分を使用することになると確信しています。