C#と諸々 WCFサービスのインスタンスコンテキストモード

WCFサービスのインスタンスコンテキストモード

[ .NET ] Windows Communication Foundation

2007/03/23 02:09

[ インスタンスコンテキストモード ]
WCFでは、サービスのインスタンス化方式が3種類あります。

クライアント毎にサービスのインスタンスを生成
クライアントを識別しサービスのインスタンスを生成し、クライアントが一連の処理を終えるまで ( クライアントのサービスプロキシオブジェクトがクローズするまで ) インスタンスを保持します。

要求毎にサービスのインスタンスを生成
サービスのメソッドが呼び出される度にサービスのインスタンスを生成します。一つのインスタンスは一度のメソッド呼び出しにしか使用されません。

シングルトン
サービスのインスタンスは常に一つだけ存在し、すべてのクライアントの要求に対して同一のインスタンスが使用されます。

従来のASP.NET Webサービスでは、「要求毎にサービスのインスタンスを生成」する方式しかサポートしていませんでした。.NET Remoting では、3つ全ての方式をサポートしていました。

WCFでは、完全にこの3つの方式をサポートしています。Webサービスでもクライアント毎にサービスのインスタンスを生成したり ( .NET Remoting の CAO における、リースやスポンサーといった概念はないようです。 ) シングルトンにすることができます。

WCFでは、既定で「クライアント毎にサービスのインスタンスを生成」する方式が適用されます。

[ インスタンスコンテキストモードの指定 ]
インスタンスコンテキストモードを指定するには、サービスクラスの属性として ServiceBehaviorAttribute クラス (System.ServiceModel) を付加し、この属性の InstanceContextMode プロパティを設定します。このプロパティの型は InstanceContextMode 列挙体 (System.ServiceModel) です。
InstanceContextMode 列挙体には以下の３つの列挙値が用意されています。これらは、この記事の最初に挙げた3つの方式と関連付けされています。 ( デフォルトは "PerSession" 。 )

InstanceContextMode.PerSession
クライアント毎にサービスのインスタンスを生成

InstanceContextMode.PerCall
要求毎にサービスのインスタンスを生成

InstanceContextMode.Single
シングルトン

[ セッションモード ]
インスタンスコンテキストモードが "PerSession" に設定されている場合、サービスコントラクトの ServiceContractAttribute 属性の SessionMode プロパティが "Required" または "Allowed" に設定されている必要があります。このプロパティの型は SessionMode 列挙体 (System.ServiceModel) です。 ( デフォルトは "Allowed" 。 )

[ スロットルの設定 ]
[ behaviors ] - [ serviceBehaviors ] - [ behavior ] セクションに属する [ serviceThrottling ] セクションの各属性 ( プログラムコードで扱うのなら ServiceThrottlingBehavior クラス (System.ServiceModel.Description) の各プロパティ ) でスロットルの設定を行うことができます。

maxConcurrentCalls
一つのサービスインスタンスに対して可能な同時呼び出しの最大値です。
この値を超える要求は、待機状態 ( 順番待ち ) となります。
デフォルトは16です。

maxConcurrentInstances
同時に存在できるサービスインスタンスの最大値です。
この値を超える要求は、待機状態 ( 順番待ち ) となります。
デフォルトは Int32.MaxValue です。

maxConcurrentSessions
一つのサービスに対して可能な同時呼び出しの最大値です。
この値を超える要求は、待機状態 ( 順番待ち ) となります。
デフォルトは10です。

[ リリースインスタンスモード ]
インスタンスコンテキストモードが "PerSession" 、あるいは "Single" に設定されている場合、特定のオペレーションコントラクトが呼び出された際に、サービスインスタンスを強制的に解放するよう設定することができます。
この設定を行うには、サービスクラスのオペレーションコントラクトの属性として OperationBehaviorAttribute クラス (System.ServiceModel) を付加し、この属性の ReleaseInstanceMode プロパティを設定します。このプロパティの型は ReleaseInstanceMode 列挙体 (System.ServiceModel) です。この列挙体には以下の4つの値があります。 ( デフォルトは "None" 。 )

BeforeCall
オペレーションコントラクトが呼び出される前に、強制的にサービスインスタンスを解放します。

AfterCall
オペレーションコントラクトが呼び出された後に、強制的にサービスインスタンスを解放します。

BeforeAndAfterCall
オペレーションコントラクトが呼び出される前と呼び出された後の両方で、強制的にサービスインスタンスを解放します。

None
サービスインスタンスの解放は行いません。

[ クライアントのサービスプロキシオブジェクトからの解放要求 ]
インスタンスコンテキストモードが "PerSession" に設定されている場合、クライアントのサービスプロキシオブジェクトがクローズすると、サービスインスタンスも自動で解放されます。
ただし、サービスクラスの ServiceBehaviorAttribute 属性の AutomaticSessionShutdown プロパティが "false" に設定されている場合は、解放は行われません。 ( デフォルトは "true" 。 )
「クライアントのサービスプロキシオブジェクトがクローズする」というのは、サービスプロキシクラスが実装する ICommunicationObject インターフェイス (System.ServiceModel) の Close メソッドのことです。
( もう少し細かいことを言えば、クライアントのサービスプロキシクラスが WSDL ファイルから自動生成されたクラスなら ClientBase ジェネリッククラス (System.ServiceModel) の Close メソッド、クライアントのサービスプロキシクラスが ChannelFactory ジェネリッククラス (System.ServiceModel) の CreateChannel メソッドから動的に生成されたクラスなら、そのクラスが実装した ICommunicationObject インターフェイス (System.ServiceModel) の Close メソッドってトコです。 )

[ 解放について ]
リリースインスタンスモードを設定したオペレーションコントラクトによって解放されたサービスインスタンスや、クライアントのサービスプロキシオブジェクトがクローズしたため解放されたサービスインスタンスが、IDisposable インターフェイスを実装している場合、即座に IDisposable.Dispose メソッドが呼び出されます。 ( IDisposable インターフェイスを実装していない場合は当然Disposeメソッドの呼び出しは行われません。 )
その後、サービスインスタンスは GC 待ちとなります。

もう眠いから、サンプルプログラムは後日公開予定

あくまでも予定だからね！

タグ: .NET C# WCF

トラックバック(0) | コメント(3) |

<< Windows SDK Update for Windows Vista リリース | ホーム | Web Deployment Projectsでドキュメントコメントファイルが… >>

コメント一覧

突然のコメント失礼します。
WCF関連の情報が少ない中、いつも参考にさせて頂いています。
WCFのサイトを作成されるとのことなので、大変楽しみにしています。
おそらく日本初？のWCFサイトになるかと思いますので期待大です。
自分も日々苦心しながらWCFと格闘しています。
その中で以下のような現象が発生したのでもしこれらに関して何かご存知
でしたら教えて頂けると有難いです。

wsHttpBindingでInstanceContextMode.PerSessionな設定で、
<reliableSession enabled="false">の場合ではインスタンスが呼び出し毎に作成され、
<reliableSession enabled="true">だとクライアント毎に作成されるという現象になっています。
netTcpBindingの場合はreliableSessionに関係なく、クライアント毎に作成されbasicHttpBinding
ではそもそもreliableSessionが設定できないため、呼び出し毎の作成しかできませんでした。
（サービスクラスのコンストラクタとメソッド中でカウンターを作成して確認）

また
basicHttpBindingでmessageEncoding="Mtom"の場合、500件程度のデータセットを返すようなある程度
大きなサイズのデータの送信では途中でエラーが発生しました。
（Mtomリーダーの作成に失敗しました。）
同様のデータでもwsHttpBindingでは発生しませんでした。
（やはりbasicHttpBindingでは正規な使用法ではないからでしょうか。）

2007.04.13 20:17　URL | ほにゃ #90LdKUd6　[ 編集 ]

ほにゃさん、はじめまして！
コメントありがとうございます＾＾

WCFのサイトはまだ準備段階でして ( しかもあまり捗ってない＾＾； ) 、気長に待って頂ければ幸いです m(＿＿)m

InstanceContextMode.PerSessionについてですが、ReliableSession の設定によっては、インスタンスが呼び出しごとに生成されてしまうというのは見落としていました。貴重な情報を提供して頂き、ありがとうございます m(＿＿)m
ちょっと調べてみましたが、バインディングセットによっては、セッションがサポートされていなかったり、セッションの有効・無効が ReliableSession に依存したりするようです。
例えば、WSHttpBindingはReliableSession が有効な場合のみセッションがサポートされます。BasicHttpBinding ではサポートされません。NetTcpBinding や NetNamedPipeBinding では、ReliableSession とは無関係に常にサポートされます。

次に、大容量データの通信で、WsHttpBinding では成功し、BasicHttpBinding では失敗するという件ですが、これはWsHttpBinding で WS-ReliableMessage によって高信頼な通信が行われるからかと思います。 ( あくまで予想ですが＾＾； )
WS-ReliableMessage も、先ほどの ReliableSession 属性によって設定します。BasicHttpBinding は WS-ReliableMessage をサポートしていませんので、大容量データの通信でデータの破損が生じたのかもしれません。データの破損率はネットワークの帯域等によるかと思います。
以前、WS-ReliableMessage を適用せずにイントラネット上で 100MB 程のデータを通信するテストを行ったことがありますが、その時は一度もそのような現象が発生しませんでした。 ( まぁ、たまたまかもしれませんがｗせいぜい10回くらいしか試してなかったし＾＾； )

2007.04.14 01:43　URL | よこけん #Ay6tTHf6　[ 編集 ]

ほにゃです。
素早い返信ありがとうございます！

またわざわざ調べて頂いて恐縮です。おかげでインスタンスの件はもやもやがすっきりしました。
Mtomの件はそういえばBasicHttpBindingの送信で画像データが欠損するデモサイトがありましたね・・
相互運用などでやむ得ない場合以外は通常のアプリ用途ではNetTcpBindingまたはWsHttpBindingを利用した方がよさげですね。
サイトの件はご苦労されてるようで・・・ブログでも全然構いませんので情報をバシバシ載せてください！
ただ出始めの頃のASPみたいにユーザー主体の情報交換の場があればWCFの情報も集まるかもですね！
（MSDNのフォーラムとかあるようですが敷居が高いのか、繁盛していないようです・・）

2007.04.16 20:02　URL | ほにゃ #90LdKUd6　[ 編集 ]