クライアントスタブは.NETWSEによってWSDLから生成されますか？スレッドセーフですか？
もちろん、「スレッドセーフ」は厳密に定義された用語である必要はないので、少なくとも次のことに興味があります。
同じスタブクラスの異なるインスタンスに、シングルスレッド実行と同じ効果的な動作で、異なるスレッドから同時にアクセスできますか？
同じスタブクラスの単一のインスタンスは、異なるスレッドから同時にアクセスでき、同じ呼び出しがシングルスレッド実行で任意の方法でインターリーブされるのと同じ効果的な動作をしますか？
まあ、それはスレッドセーフですか、という簡単な答えはイエスです。その理由は、サービスのサーバー側は、スレッド機能に関してクライアント接続よりも多くのことを言う必要があるためです。クライアントは、サーバーが理解できる方法で要求をレイアウトする単なるプロキシです。それは何も知りません。これは基本クラスであり、サーバーへの接続以外の外部アクセスはありません。サーバーが複数の接続を許可している限り、問題はありません。したがって、リソースの競合はありません（サーバーがすべての要求を処理できることを除いて）。
クライアント側では、複数のスレッドで同じクラスを使用することができますが、インスタンスは異なります。これは、各トランザクションをアトミックにするために、おそらく推奨されるシナリオです。共有インスタンスでは、クラス自体のアクセスを中心に独自のスレッドロックを処理する必要があります。そうしないと、コード内部のリソースで競合状態が発生する可能性があります。
非同期呼び出しを行う機能もあります。wsdlツールによって生成されたスタブは、begin、end invokeメソッドを作成します。これにより、コールバックメソッドを提供して、リクエストを効果的に送信し、応答を待たずにコードを続行できるようになります。これは、単一インスタンスを使用する2番目のシナリオにおそらく最適です。
ただし、サーバーコンポーネントのコーディング方法にも依存します。Webサービスの場合は、複数のリクエストを同時に送信できるはずです。ただし、ソケットベースのサービスの場合は、複数の着信接続を処理したり、たとえばソケットを作成したりするために、側で追加のコーディングを行う必要がある場合があります。
つまり、はい、異なるインスタンスは、サーバー側が複数の同時接続を処理できるという制限内で、シングルスレッド実行と同じように動作します。
シングルインスタンスに関しては、提供されているコールバックプロセスを使用すると、あまり頭を悩ませることなく、目的のプロセスを取得できる場合があります。ただし、サーバー側のコードの制限にも制限されています。
サーバーの制限について説明する理由は、アウトバウンドホストからの接続数を制限するWebサービスを構築する会社があるため、スループットがこれによって制限されるためです。したがって、使用できる有効なスレッドの数が減るか、廃止されます。