問題タブ [esb]

非常に複雑な質問で申し訳ありませんが、これは私がしばらく研究してきたことであり、それは本当に私を苛立たせています。今日の時代には、100万のサービスがあり、サービスを実装する1つの方法はクロスプラットフォーム（SOAP）であり、簡単に構築できるように感じます（.NET、Java、およびその他のフレームワークのおかげです）。ただし、これらのテクノロジーは5〜10年間コミュニティに存在していますが、私たちは常に同じ問題に悩まされています（または少なくとも私はそうです）。

1. 識別（追跡サービス）-UDDI; たとえば、サービスについて説明しているwikiと、サービスドキュメントを保持しているリポジトリにある同じドキュメントのPDFバージョンがあるにもかかわらず、今月3回、サービスがある場所を同僚に思い出させる必要がありました。 。
2. スケーラビリティ-すぐに使用できるクラスタリング。組織として、私たちはサービスの利用を監視し、このサービスがより多くのRAM、より多くのCPU、より多くのインターフェースを必要とするかどうかのような決定を下すためだけに管理者に支払うことに多額のお金を費やしています。これをどのように負荷分散しますか？
3. 監視-エラーログなど。1人の顧客にのみ影響するように見えるバグが発生している理由を確認するために、サービスのトレースを設定する必要がある回数を数えられません。または、例外をシリアル化し、例外をdbsに記録するために、ロジックをサービスにコーディングする必要があります。優雅に失敗するなど。
4. 展開-簡単に展開できます。5つの負荷分散サーバーにDLLをデプロイするこの方法はありません

これらの問題のそれぞれは、組織によって実装されたある種のカスタムソリューションを必要とします。＃1のドキュメントとUDDI。＃2の仮想化と負荷分散のハードウェア/ソフトウェア。＃3のトレース、データベース/ログへの例外の書き込みなど。＃4のカスタム展開ソフトウェア。私は中規模の組織で働いています。Sun、Google、またはMicrosoftの規模の企業がこれらのジレンマにどのように取り組むか想像さえできません。

私のビジョンは非現実的かもしれませんが、上記のすべてを管理するサーバークラスターの上にフレームワーク自体が存在することを夢見ています。BizTalkの機能の一部をWCFサービスの実装者（キャッシュ、ホスティング、監視など）に拡張しているように見えるため、MicrosoftのAppFabricについて読むことに夢中になりました。しかし、私が見たところ、それが生きているとは感じていません。開発者と組織が、クラスター間で簡単に拡張でき、クラスターに簡単に展開でき、識別可能で、場合によってはバージョン管理可能なサービスを作成するのに役立つオールインワンソリューションを夢見ています。

ですから、この投稿が私の夢についてのものであるという意味ではありません。実際に質問があります。手始めに、私の夢/完全に非現実的なものが欲しいですか？さらに、サービスを開発するための新しいより独自の方法（BizTalk）に制限されることなく、これらの問題を解決しようとするソリューションはありますか？最後に、完全なSOA / ESBソリューションに関して、現在または将来の市場で最も可能性のあるものはどこにあると思いますか？

Java クライアントからのサブスクリプションを許可する .Net 用の優れた無料サービス バスはありますか? 私は NServiceBus を使用しており、流暢な API とシンプルさが気に入っていますが、Java クライアントや Web サービス ベースの接続用の WCF 統合をサポートしていません。

ありがとう！

私は会社の電気通信製品の 1 つの新しいバージョンを設計し始めており、負荷分散とスケーラビリティを提供するために、ある種の (.NET オープン ソース) ESB を検討していました。リレーショナル データベースを回避し、(おそらく) 非トランザクション キューを分散インメモリ キャッシュ (Velocity や memcached など) にフィードすることで、システムのスループットを向上させたいと考えています。

リアルタイム システムでこのようなアーキテクチャを使用したことはありません。また、日々の開発の単純さで得られるものと比べて、スループットが失われるのではないかと心配しています (このアプリではこれが非常に重要です)。

私は NServiceBus で遊んだだけなので、それ (またはその兄弟) がリアルタイムの SQL を使用しないアプリケーションの基盤として適しているかどうかはわかりません。どう思いますか？

これらの製品をどのように判断すればよいですか？代わりに商用アプリを購入するか、疫病のように ESB を避けるか、または他のアプローチを使用する必要がありますか?

システムの設計上の問題を解決するためのアイデア/パターンを探しています。まもなく作業を開始します。システムの特定の領域間で通信するために、ある種のメッセージング（おそらくMSMQ）を使用する必要があることは間違いありません。車輪の再発明はしたくありませんが、同時に、仕事に適したツールを使用していることを確認したいと思います。私はNServiceBusをいじくり回して読んでいて、それが何をするのか非常に感銘を受けていますが、それが私が達成しようとしていることを意図しているのかどうかはわかりません。

これは、システムが実行する必要があることの（うまくいけば）非常に単純で概念的な説明です。

クライアントがメッセージを送信できるサービスがあります。サービスは「ファイアアンドフォーゲット」です。クライアントが返す可能性が最も高いのは、成功または失敗を示す可能性のあるものです（成功とはメッセージが受信されたことです）。

各メッセージの処理/処理は重要であり、かなりのシステムリソースを消費する可能性があります。このため、同時に処理できるのはXメッセージのみです。Xは構成可能な値です（システム仕様などに基づく）。着信メッセージは、処理される「順番」になるまでキューに保存されます。

クライアントごとに、メッセージを順番に処理する必要があります（FIFO）。ただし、一部のクライアントは、たとえば一定期間接続が失われた場合など、多数のメッセージを連続して（数千以上）送信する場合があります。このため、メッセージはクライアント間でラウンドロビン方式で処理する必要があります。つまり、クライアントがゴージしたり、飢えたりすることはできません。したがって、システムは特定のクライアントのキューを照会するか、クライアントごとに個別のキューを作成して（コンパイル時にクライアントが認識されないため、自動的に）、それらから順番にプルする必要があります。

私の現在の考えは、実際にはバニラMSMQを使用し、メッセージを受け入れて1つ以上のキューに書き込むサービスを作成し、キューからメッセージを読み取って処理/処理するプロセスを作成する必要があるということです。ただし、NServicebusのようなもので得られる信頼性、監査、拡張性、および構成の容易さは非常に魅力的に見えます。

ESBはその仕事にとって間違ったツールですか？私が見なければならない他の技術やパターンはありますか？

アップデート

いくつかの説明。

「順番に」メッセージを処理することに関して-単一のクライアントのコンテキストでは、メッセージは受信された順序で絶対に処理される必要があります。正確な理由を説明するのは複雑ですが、これは確固たる要件です。クライアントごとに1つのメッセージだけが同時に処理されることになると言うのを怠りました。したがって、10個のワーカースレッドがあり、処理を待機しているメッセージが1つのクライアントだけであったとしても、一度に処理されるのはそれらのメッセージの1つだけであり、競合状態の心配はありません。

これは一般的にバニラMSMQで可能であると思います。つまり、メッセージのリストをキューに入れて、常に最も古いものを最初に取得することができます。

また、ラウンドロビン注文のユースケースを明確にしたいと思いました。この例では、メッセージを送信する2つのクライアント（AとB）と、1つのワーカースレッドしかありません。すべてのキューが空です。クライアントAは一晩で接続を失ったため、午前8時にサービスに1000件のメッセージを送信します。これらのメッセージはキューに入れられ、ワーカースレッドは最も古いメッセージを取得して処理を開始します。この最初のメッセージが処理されている間、クライアントBはメッセージをサービスに送信します。サービスはキューに入れられます（前述のように、おそらく別のキューにあります）。クライアントAの最初のメッセージの処理が完了すると、ロジックはクライアントBにメッセージがあるかどうか（クライアントBの「ターン」）をチェックし、メッセージが見つかったので次に処理する必要があります。

その間にクライアントBがメッセージを送信しなかった場合、ワーカーはクライアントAのメッセージを一度に1つずつ処理し続け、処理後に常に他のクライアントキューに待機中のメッセージが含まれているかどうかを確認して、クライアントが不足していないことを確認します。

ESBとこの問題の間に不一致があるかもしれないと私がまだ感じているのは、ESBがサービス間の通信を容易にするように設計されていることです。私が達成しようとしているのは、メッセージング/通信と選択的キューイングシステムの組み合わせです。

問題 - Mule の異なるバージョン (Mule 2.0 と 2.2.0 など) を同じサーバーにデプロイできますか?

それらはさまざまなアプリケーションに使用されます。

1. それが原因で衝突が発生することはありますか？
2. そのようにする前に、前提条件に注意する必要があります
3. これに潜在的なリスクはありますか？

ありがとう ：）

私はMULEESBを使用したプロジェクトに取り組んでいます。

私が作業しているアプリケーションの現在のシナリオは

最初のアプリケーションから、xml msgsをpeoplesoft（2番目のアプリケーションとして機能）に直接送信できますが、すべてのメッセージがpeoplesoft側で受信されることを保証するものではありません。

そのため、最初のアプリケーションと2番目のアプリケーションの間にMULEを使用することにしました。これは良い選択ですか？

peoplesoftが送信されたすべてのメッセージを受信できるように、アーキテクチャのより良い選択を手伝っていただけませんか

助けを楽しみにしています。

ありがとう

次の問題があります: リモート ブローカー (データセンター内) に転送するローカル ActiveMQ ブローカーを使用するサイトがいくつかあります。この接続はしばしば不安定で、月に数回、一度に数分から数時間ダウンします。

したがって、現時点でリモート ブローカにアクセスできない場合、メッセージはローカル ブローカで待機する必要があります。

次の ActiveMQ 構成があります。

これにより、ローカル ブローカー (トピック MySpecialTopic) からリモート ブローカーにメッセージが転送されます。これは、接続が安定している場合に機能します。

ただし、ローカルブローカーがリモートブローカーとの接続を失うように、インターネット接続を一時的に無効にしようとしました。その時点で、新しいメッセージを送信しました。このメッセージはローカル ブローカーのキューに入れられましたが、ローカル ブローカーが再接続した後でも、リモート ブローカーには届きませんでした。

ActiveMQ 構成に欠けているものはありますか?

ありがとう！

ねえ、
Apache Camel があるのに、なぜ Apache ServiceMix や Mule などの他のソリューションを使用する必要があるのでしょうか?
これらの製品と比較して、Apache Camel でできないことはありますか?
Mule/ServiceMix をいつ使用し、いつ Camel を使用するか?

私は新しいサイトの計画段階にあります-それは私たちが構築したいくつかのモバイルアプリの拡張です。ユーザーにコミュニケーションの中心点を提供し、モバイルアプリを使用したくない/使用できないユーザー向けの機能も提供したいと考えています。追加しようとしている機能の1つは、SOバッジシステムと本質的に類似したレピュテーションシステムです。私たちはSOAを使用するようにシステムを設計しています。

このロジックのすべてを目立たないチャンクとしてメインアプリにコーディングする必要はありません。これを達成するための手段を作成することを考えています。これにより、評判を得るための新しいしきい値とルールを定義し、それらを何らかのサービスに注入することができます。これまで私がこれを行うことを考えた2つの方法は次のとおりです。

1. ユーザーアクションの特定の特性を探して応答するには、これは、「プラグイン」アワード定義を実行し、満たされているしきい値をチェックして適切に応答できるサービスを実行することを意味します。
2. ユーザーがアクションを実行したときにイベントを発生させるには、それらのイベントをリッスンし、適切に応答します。これらのアクションを実行するサービスは、潜在的に別々のサーバー上の別々のアプリドメインで実行されているため、これらのイベントをリッスンして応答する中央メッセージバスがあることを確認できる唯一の方法は、MassTransit、nServiceBus、Rhino.Esbなどを使用することです。 。

サービスバスの使用は、それを必要としないアプリケーションに非常に簡単に不適切に設計される可能性があることを知っています。ほとんどの場合、異種の異種システムを統合しない限り、新しいシステムを設計するときにサービスバスは必要ないでしょう。しかし、これを行うための最良の方法に関するオプションについては少し迷っています。私は、サービスがバックグラウンドで常にDbをハンマーで叩くという考えは好きではありません。しかし、それは早い段階で、後で、もっと単純になるかもしれないように聞こえます。私は考えるのが怖いです！

ここで誰かがこのようなシステムを設計しましたか？どのようにしてこれを達成しましたか？システムがユーザーのバーストに対処できる必要がある場合があると予想されるため、高スループットを実現するように設計しています。

次の機能を実行するソフトウェアが必要です
。1。単一のエンドポイントをクライアントに提供します（複数のサービスエンドポイントから抽出します）
2。着信要求のキューを保持します
3.複数のマシン上の複数のサービスエンドポイント間で負荷を分散します
4 。これらのエンドポイントの可用性を制御します
。5。最大CPSまたは最大メッセージキューサイズに達したときにクライアントに読み取り可能なエラーを
提供します。6。キューサイズと既知のサービスエンドポイントのパフォーマンスに基づいて、メッセージ処理時間の予測を提供します。

これは、.NETベースでWCFに適している必要があります。ロードバランサーとESBが混在していると思います。そのようなタイプの既存の製品（OSSプロジェクト）に名前を付けていただけますか？