問題タブ [ws-reliablemessaging]

この記事 (「Windows Communication Foundation」セクションの後半) で、著者は、WCF での一方向の送信は本質的に UDP であると提案しています。これは正しいです？この記事の内容に基づいて、サービス操作を「一方向」としてマークすることは、UDP を使用していることを意味すると想定する必要がありますか?

さらに、UDP を WS-ReliableMessaging と組み合わせて使用​​して、トランスポート プロトコルのこれらの側面を自分で作成する必要をなくすことを提案しています。 、この記事の提案に従って、「一方向」と WS-ReliableMessaging を使用するだけでいいのです!? 私には少し遠いように聞こえます...

それで、ここでの取引は何ですか？この記事が示唆していることの警告は何ですか?

小さなプロジェクトで Web サービスを公開しています。wsdl は、実装クラスの注釈を使用して、JAX-WS ランタイムによってオンザフライで生成されます。

何かにフラグを立てて、信頼できるメッセージングの側面を単に「オン」にしたいと思っていました。私は、ある種の Java ソースおよび/または補足 xml ファイルにいくつかの注釈を挿入できると考えていました。

私が持っている質問:

1) 「Metro」のすべてが JDK に統合されていますか。

2) RM (Reliable Messaging) には、メッセージを失うことなくクラッシュや再起動に耐えられるように、ある種の永続的なキューが含まれていますか? 標準の JDK が提供する JAX-WS は、何らかの SQL ベースのデータベース ストレージを通じて、これをどのように処理しますか?

3) WSDL ファイルを作成せずに RM を実行できますか?

4) スタンドアロンの組み込み Tomcat を使用して、アプリケーションに WS-RM を提供できますか?

5) 組み込みの Tomcat を介してアプリケーションに WS-RM を与えることに最も近いサンプルを知っている人はいますか?

ps。RTFM は機能しませんでした。

信頼できるリクエスト返信では、返信が承認され信頼できるものであることを理解しています。なんらかの理由で、応答メッセージが 8 回すべての試行 (デフォルトの再試行回数は 8 回) で継続的に失敗した場合、チャネルに障害が発生します。

サーバー側のサービス メソッドでは、応答が失敗した場合に対処する必要がありますが、サービス メソッドが WCF コンテキストを認識していないため、これを達成する方法がわかりません。

ClientBase から独自のプロキシを実装できるため、クライアントであり、プロキシ自体でサービス メソッドを呼び出すと、障害を処理するのがはるかに簡単になるようです。

http://msdn.microsoft.com/en-us/library/aa480191.aspxを読み、検索しましたが、具体的なものは何も見つかりません。

実験のために、VS2012で.NET4.5を使用して単純な「HelloWorld」WCFサービスとクライアントを作成しました。サーバーはコンソールアプリケーションでホストされ、net.tcpバインディングを使用します。非同期リクエストのバースト（合計700リクエスト）をサーバーに送信するクライアントコードを作成しました。サービスの信頼できるセッション機能をオンにするまで、すべてがうまくいきました。オンにした後、サービスの実行が突然非常に遅くなり、700の要求を完了するのに私のマシンでほぼ1分かかりました。同時実行パラメーターとスロットルパラメーター（以下を参照）を微調整しようとしましたが、役に立ちませんでした。

なぜこれが起こるのか誰かが知っていますか？これを回避する方法はありますか？

信頼性の高いセッション機能をオフにした場合、またはサービス呼び出しを同期させた場合、速度低下は発生しませんでした。したがって、WCFがWS-ReliableMessagingモードで保留中のリクエストを処理する方法に関連している可能性があると思います。

編集：これは、netTcpBindingをwsHttpBindingに変更したときにも発生しませんでした。この場合、wsHttpBindingはnetTcpBindingよりもはるかに高速であるため、これは非常に奇妙です。

編集：サーバー側でPerfmon.exeを実行すると、上記の場合、「スレッド数」が8から100を超えて徐々に増加することがわかります。

編集：私のPC（ローカルネットワーク）で測定されたスループット。ケース1のパフォーマンスは非常に遅く、実際には役に立たないことがわかります。

1. 非同期+NetTcpBinding/信頼性の高いスループット->約 14コール/秒（70ミリ秒/コール）
2. 非同期+WsHttp/信頼できるスループット->7957呼び出し/秒（0.12ミリ秒/呼び出し）
3. 同期+NetTcpBinding/信頼性の高いスループット->3986呼び出し/秒（0.25ミリ秒/呼び出し）

以下は、実験で使用したサーバーとクライアントのコードと構成です。

サーバ：

クライアント：

サーバーのApp.config：

クライアントのApp.config：

Web サービスを介して動的受信者リストへの通知メッセージの配信を保証するプロジェクトを予定しています。現在、他の変換、ルーティング、およびプロキシの要件に Synapse を使用しています。Synapse または WSO2 がタスクに適している場合は、引き続き使用したいと考えています。

Synapse/WSO2 は、単一の受信者への配信を保証する WS-ReliableMessaging を提供し、RecipientList メディエーターを提供します。ただし、この 2 つを組み合わせる方法は明らかではありません。

受信者ごとに保証された配信が必要です。

WSO2 はこれを提供しますか?

1 つのオプションとして、Message Store/Message Processor パターンを使用することがあります。メッセージの複製がメッセージ ストアにダンプされる可能性があります。受信者ごとに 1 つずつ、目的の受信者の URL が埋め込まれています (カスタム メディエーターを使用する可能性があります)。Message Processor は、各メッセージ クローンを目的の受信者に送信できます。しかし、重要な質問があります。Message Processor は、最初に失敗した送信で停止し、その送信のみを再試行し続け、キュー内のすべてのメッセージをブロックしますか? 私の推測では、最初に失敗したメッセージが成功するまでブロックされると思います。

I have WCF service which uses WS-reliable messaging. I would like to write some python scripts that connect to this service using suds soap client but it seems that suds doesn't support reliable messaging out of the box. Does anybody tried to use suds with reliable messaging? Do I have to write some logic for handshaking like CreateSequence,TerminateSequece and so on? Or maybe there are another python soap clients which support WS-reliable messageing?

Thanks in advance.

gsoapライブラリをWS-Reliable Messaging使用してソープ クライアントを実装し、WS-Security一方向のリモート アクションを呼び出します。

すべての SOAP メッセージ ( CreateSequence、実際のメッセージCloseSequence)には<wsse:Security>、SOAP ヘッダーにTerminateSequenceパケット以外の要素があります。何か不足していますか？

私のコード(SSCCE)は次のようになります: