2007/03/30 16:28
【 ホスティング 】
[ ホスティングの種類 ]
WCF のホスティングは、大別して以下の3種類があります。
[ ServiceHost クラス ]
WCF のホスティングを実現するのは ServiceHost クラス (System.ServiceModel) です。
このクラスをインスタンス化し、Open メソッドを呼び出すことで WCF サービスが利用できるようになります。
具体的な手順は以下の通りです。
一つの ServiceHost オブジェクトは、一つのサービス クラスに対応します。一つのサービス クラスに対して複数のエンドポイントを用意することができます。
どういうことかというと、一つのサービス クラスに対して複数のエンドポイントを用意する場合でも、 ServiceHost オブジェクトは一つであるということです。この際、各エンドポイントで異なるプロトコルを使用することも可能です。
セルフ ホスティングの場合、この一連の処理を自分で実装する必要があります。IIS や WAS によるホスティングの場合は、この処理を自分で実装する必要がありません。
なお、ServiceHost クラスは継承可能なので、ServiceHost クラスを継承した独自のクラスを作成して使用することもできます。 ( セルフ ホストでない場合でも可能です。 )
【 WCF ホストの設定 】
[ 設定方法の種類 ]
WCF ホストの設定は、コンフィギュレーションでの設定と、プログラムからの設定がサポートされています。
[ 主な設定項目 ]
WCF ホストの主な設定は以下の通りです。
BaseAddress ( ベースアドレス )
各エンドポイントのアドレスの、ベースとなるアドレスです。
Endpoint ( エンドポイント )
クライアントとの通信に関連する設定で、アドレスとバインディングとコントラクトで構成されます。
エンドポイントは一つのサービス クラスに対して複数用意することができます。また、各エンドポイントで異なるプロトコルを使用することが可能です。
Behavior ( ビヘイビア )
クライアントとの通信に関連しない設定です。
ビヘイビアには、 ServiceBehavior ( サービス ビヘイビア ) と EndpointBehavior ( エンドポイント ビヘイビア ) の2つがあります。
サービス ビヘイビアは一つのサービス クラスと対になります。一つのサービス クラスに対して複数のサービス ビヘイビアを適用することはできません。
エンドポイント ビヘイビアは一つのエンドポイントと対になります。一つのエンドポイントに対して複数のエンドポイント ビヘイビアを適用することはできません。
[ コンフィギュレーションで設定 ]
コンフィギュレーションでのWCF の設定は、 [ system.serviceModel ] セクションにて行います。
特に重要なのが [ system.serviceModel ] - [ services ] - [ service ] セクション です。
このセクションの name 属性にサービス クラスの名称を記述します。サービス クラスの ServiceBehaviorAttribute 属性のCongifurationName プロパティでコンフィギュレーション用の名称を指定し、その名称を記述することも可能です。
このセクションは一つのサービス クラスと対になります。一つのサービス クラスに対してこのセクションを複数用意することはできません。
ServiceHost オブジェクは、対応するサービス クラスの設定を行っている service セクションを、コンフィギュレーションから自動で検出してくれます。
ベースアドレス
service セクションの中に [ host ] - [ baseAddresses ] セクションを用意し、その中に [ add ] セクションを用意することで、ベースアドレスを指定することができます。 ( MSDN には baseAddress セクションを用意するように書いてありますが、これは誤りです。 )
[ add ] セクションは複数用意することが可能です。
エンドポイント
[ service ] セクションの中に [ endpoint ] セクションを用意することでエンドポイントを設定することができます。 [ endpoint ] セクションは複数存在させることが可能です。
ビヘイビア
サービス ビヘイビアは [ system.serviceModel ] - [ behaviors ] - [ serviceBehaviors ] - [behavior ] セクションで設定します。 behavior セクションの name 属性で指定した名称を [ system.serviceModel ] - [ services ] - [ service ] セクション の behaviorConfiguration 属性に指定します。
エンドポイント ビヘイビアは [ system.serviceModel ] - [ behaviors ] - [ endpointBehaviors ] - [behavior ] セクションで設定します。そして、 behavior セクションの name 属性で指定した名称を [ system.serviceModel ] - [ services ] - [ service ] - [ endpoint ] セクション の behaviorConfiguration 属性に指定します。
・サンプル
以下に、コンフィギュレーションの設定例を示します。
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name="YokoKen.WCFServices.SampleService" behaviorConfiguration="SampleServiceBehavior">
<host>
<baseAddresses>
<add baseAddress="http://localhost/WCFServices/SampleService.svc"/>
<add baseAddress="net.tcp://localhost:10000/WCFServices/SampleService.svc"/>
<add baseAddress="net.pipe://WCFServices/SampleService.svc"/>
</baseAddresses>
</host>
<endpoint name="SampleServiceHttpEndpoint"
address=""
binding="basicHttpBinding"
bindingNamespace="http://schemas.yokoken.net/WCFServices"
contract="YokoKen.WCFServices.ISampleService" />
<endpoint name="SampleServiceNetTcpEndpoint"
address=""
binding="netTcpBinding"
bindingConfiguration="SampleServiceNetTcpBinding"
bindingNamespace="http://schemas.yokoken.net/WCFServices"
contract="YokoKen.WCFServices.ITestService" />
<endpoint name="SampleServiceNetNamedPipeEndpoint"
address=""
binding="netNamedPipeBinding"
bindingConfiguration="SampleServiceNetNamedPipeBinding"
bindingNamespace="http://schemas.yokoken.net/WCFServices"
contract="YokoKen.WCFServices.ITestService" />
</service>
</services>
<bindings>
<netTcpBinding>
<binding name="SampleServiceNetTcpBinding" >
<security mode="None"/>
</binding>
</netTcpBinding>
<netNamedPipeBinding>
<binding name="SampleServiceNetNamedPipeBinding">
<security mode="None"/>
</binding>
</netNamedPipeBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="SampleServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
[ プログラムで設定 ]
プログラムで直接設定する場合、ServiceHost オブジェクトを直接操作して設定を行うことになります。
特に重要なのが ServiceHost オブジェクトの Description プロパティ です。このプロパティの型は ServiceDescription クラス (System.ServiceModel.Description) です。
ベースアドレス
ベースアドレスは、 Uri クラス (System) で表わされます。
ベースアドレスの設定は、ServiceHost オブジェクトのコンストラクタにて行います。
また、 ServiceHost オブジェクトのの BaseAddresses プロパティ にて取得のみ行うことができます。このプロパティの型は、 ReadOnlyCollection ジェネリック クラス (System.Collections.ObjectModel) で、ジェネリック引数 T には、 Uri クラスが指定されています。
エンドポイント
エンドポイントは、ServiceEndpoint クラス (System.ServiceModel.Description) で表わされます。
エンドポイントの設定は、 ServiceDescription オブジェクトの Endpoints プロパティ にて行います。このプロパティの型は ServiceEndpointCollection クラス (System.ServiceModel.Description) です。このServiceEndpointCollection オブジェクトの Add メソッド にて、 ServiceEndpoint オブジェクトを追加します。
また、 ServiceHost オブジェクトの AddServiceEndpoint メソッド でエンドポイントを追加することも可能です。
// 追記 ( 2007/03/31 )
ServiceEndpoint のインスタンスを自分で生成するのではなく、AddServiceEndpoint メソッドを使用することを推奨します。
ServiceEndpoint のインスタンスを自分で生成する場合、 Address プロパティを適切に設定してやる必要があります。この時、ベースアドレスからの相対パスでの指定ができません。絶対パスで指定する必要があります。また、 Address プロパティの設定を忘れた場合 ( つまりnull の場合 ) 、 ServiceHost オブジェクトのOpen メソッドの実行途中で NullReferenceException が発生します。この例外情報から、「 Address プロパティが null であるために例外が発生した」という情報は得られません。
AddServiceEndpoint メソッドを使用した場合、これらの問題は発生しません。メソッドの引数 address には、ベースアドレスからの相対パスを指定することができます。ベースアドレスをそのまま使いたければ string.Empty を渡すだけです。 null を指定すれば、適切な例外をスローしてくれるので、原因がすぐにわかります。
ビヘイビア
サービス ビヘイビアは、 IServiceBehavior インターフェイス (System.ServiceModel.Description) を実装したクラスで表わされます。
サービス ビヘイビアの設定は、 ServiceDescription オブジェクトの Behaviors プロパティ で行います。このプロパティの型は KeyedByTypeCollection ジェネリック クラス (System.Collections.Generic) で、ジェネリック引数 TItem には IServiceBehavior インターフェイスが指定されています。このKeyedByTypeCollection オブジェクトの Add メソッド にて、 IServiceBehavior オブジェクトを追加します。
エンドポイント ビヘイビアは、 IEndpointBehavior インターフェイス (System.ServiceModel.Description) を実装したクラスで表わされます。
エンドポイント ビヘイビアの設定は、 ServiceEndpoint オブジェクトの Behaviors プロパティ で行います。このプロパティの型は KeyedByTypeCollection ジェネリック クラスで、ジェネリック引数 TItemには IEndpointBehavior インターフェイスが指定されています。このKeyedByTypeCollection オブジェクトの Add メソッドにて、 IEndpointBehavior オブジェクトを追加します。
・サンプル
以下に、プログラムでの設定例を示します。
( 2007/03/31 : AddServiceEndpoint メソッドを使うように修正 )
// using System.ServiceModel;
// using System.ServiceModel.Channels;
// using System.ServiceModel.Description;
private static void SettingSampleServiceHost(ServiceHost sampleServiceHost)
{
const string sampleServiceBindingNamespace = "http://schemas.yokoken.net/WCFServices";
Type sampleServiceContractType = typeof(ISampleService);
Binding sampleServiceHttpBinding = new BasicHttpBinding();
sampleServiceHttpBinding.Namespace = sampleServiceBindingNamespace;
Binding sampleServiceNetTcpBinding = new NetTcpBinding(SecurityMode.None);
sampleServiceNetTcpBinding.Namespace = sampleServiceBindingNamespace;
Binding sampleServiceNetNamedPipeBinding = new NetNamedPipeBinding(NetNamedPipeSecurityMode.None);
sampleServiceNetNamedPipeBinding.Namespace = sampleServiceBindingNamespace;
ServiceMetadataBehavior sampleServiceMetadataBehavior = new ServiceMetadataBehavior();
sampleServiceMetadataBehavior.HttpGetEnabled = true;
sampleServiceHost.AddServiceEndpoint(sampleServiceContractType, sampleServiceHttpBinding, string.Empty);
sampleServiceHost.AddServiceEndpoint(sampleServiceContractType, sampleServiceNetTcpBinding, string.Empty);
sampleServiceHost.AddServiceEndpoint(sampleServiceContractType, sampleServiceNetNamedPipeBinding, string.Empty);
sampleServiceHost.Description.Behaviors.Add(sampleServiceMetadataBehavior);
}
【 セルフ ホスティング 】
冒頭でも説明したように、セルフ ホスティングは ServiceHost オブジェクトの操作を自分で実装します。
[ コンフィギュレーションで設定 ]
ServiceHost オブジェクトは、コンフィギュレーションでの設定を自動で認識します。
以下に、コンフィギュレーションで設定を行う場合のセルフ ホスト プログラムの例を示します。
// using System.ServiceModel;
// using System.ServiceModel.Dispatcher;
static void Main(string[] args)
{
Type sampleServiceType = typeof(SampleService);
using (ServiceHost sampleServiceHost = new ServiceHost(sampleServiceType))
{
sampleServiceHost.Open();
foreach (ChannelDispatcher dispatcher in sampleServiceHost.ChannelDispatchers)
{
Console.WriteLine("Listening uri: {0}", dispatcher.Listener.Uri.ToString());
}
Console.WriteLine("Enter キーを押すと終了します。");
Console.ReadLine();
sampleServiceHost.Close();
}
}
[ プログラムで設定 ]
プログラムで設定する場合は、 ServiceHost オブジェクトに対して設定を行います。
先ほどプログラムでの設定例として挙げた SettingSampleServiceHost メソッドを使って設定を行う、セルフ ホスト プログラム の例を以下に示します。
// using System.ServiceModel;
// using System.ServiceModel.Dispatcher;
static void Main(string[] args)
{
Type sampleServiceType = typeof(SampleService);
Uri[] sampleServiceBaseAddress =
new Uri[]
{
new Uri("http://localhost/WCFServices/SampleService.svc"),
new Uri("net.tcp://localhost:10000/WCFServices/SampleService.svc"),
new Uri("net.pipe://WCFServices/SampleService.svc")
};
using (ServiceHost sampleServiceHost = new ServiceHost(sampleServiceType, sampleServiceBaseAddress))
{
SettingSampleServiceHost(sampleServiceHost);
sampleServiceHost.Open();
foreach (ChannelDispatcher dispatcher in sampleServiceHost.ChannelDispatchers)
{
Console.WriteLine("Listening uri: {0}", dispatcher.Listener.Uri.ToString());
}
Console.WriteLine("Enter キーを押すと終了します。");
Console.ReadLine();
sampleServiceHost.Close();
}
}
【 IIS によるホスティング 】
IIS によるホスティングは簡単で、 ServiceHost ディレクティブを記述したsvc ファイルを用意し、コンフィギュレーションまたはプログラムにて WCF の設定を適切に行い、IIS にて仮想フォルダに配置するだけです。
IIS ホストの場合、HTTPプロトコル以外を使用するエンドポイントは使用できません。また、ベースアドレスの設定は無視され、 svc ファイルのアドレスがベースアドレスとなります。
[ コンフィギュレーションで設定 ]
Web.config にて設定を行います。特別な設定はありません。
[ プログラムで設定 ]
・内部動作
IIS によるホスティングの場合、WCF は、HttpApplication クラス (System.Web) の PostAuthorizeRequest イベント にハンドラを登録し、そのハンドラの内部で ServiceHostingEnvironment クラス (System.ServiceModel) の EnsureServiceAvailable メソッド を呼び出します。 ( 厳密には、このメソッドではなく、EnsureServiceAvailableFast メソッド ( 可視性 internal ) を直接呼び出しています。 )
このメソッドは、内部で ServiceHostFactory クラス (System.ServiceModel.Activation) の CreateServiceHost メソッド を使って ServiceHost クラスのインスタンスを生成します。
・設定方法
ServiceHostFactory クラスを継承した独自のクラスを定義し、このクラスの名称を svc ファイルの ServiceHost ディレクティブ の Factory 属性に指定します。すると、IIS は一連の内部動作の流れの中で、このクラスを使用して ServiceHost クラスのインスタンスを生成するようになります。
つまり、ServiceHostFactory クラスを継承した独自のクラスでCreateServiceHost メソッドをオーバーライドすれば、IIS が使用する ServiceHost オブジェクトをカスタマイズすることができます。これにより、コンフィギュレーションを使わずに WCF の設定を行うことができます。
IIS によるホスティングで、プログラムから設定を行う場合の、 svc ファイルの設定例を以下に示します。
<% @ServiceHost Service="YokoKen.WCFServices.SampleService" Factory="YokoKen.WCFServices.Hosts.SampleServiceHostFactory"%>
IIS によるホスティングで、プログラムから設定を行う場合の、 独自 ServiceHostFactory クラスの例を以下に示します。
using System.ServiceModel;
using System.ServiceModel.Activation;
namespace YokoKen.WCFServices.Hosts
{
public class SampleServiceHostFactory : ServiceHostFactory
{
protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
{
ServiceHost result = base.CreateServiceHost(serviceType, baseAddresses);
this.SettingSampleServiceHost(result);
return result;
}
private void SettingSampleServiceHost(ServiceHost target)
{
// 設定処理
}
}
}
【 WAS によるホスティング 】
未調査です。今後の課題ということで。
[ ホスティングの種類 ]
WCF のホスティングは、大別して以下の3種類があります。
- セルフ ホスティング
- Internet Information Services ( IIS ) によるホスティング
- Windows Process Activation Service ( WAS ) によるホスティング
[ ServiceHost クラス ]
WCF のホスティングを実現するのは ServiceHost クラス (System.ServiceModel) です。
このクラスをインスタンス化し、Open メソッドを呼び出すことで WCF サービスが利用できるようになります。
具体的な手順は以下の通りです。
- ServiceHost クラスの コンストラクタ にてサービス クラスの型情報 ( またはサービスクラスのシングルトンオブジェクト ) と0個以上のベースアドレスを指定して、ServiceHost クラスのインスタンスを生成する
- ServiceHost オブジェクトの Open メソッド を呼び出してホスティングを開始する
- なんらかの方法 ( 例えばコンソールアプリなら Console.ReadLine メソッド ) で待機状態にする
- ServiceHost オブジェクトの Close メソッド を呼び出してホスティングを終了する
一つの ServiceHost オブジェクトは、一つのサービス クラスに対応します。一つのサービス クラスに対して複数のエンドポイントを用意することができます。
どういうことかというと、一つのサービス クラスに対して複数のエンドポイントを用意する場合でも、 ServiceHost オブジェクトは一つであるということです。この際、各エンドポイントで異なるプロトコルを使用することも可能です。
セルフ ホスティングの場合、この一連の処理を自分で実装する必要があります。IIS や WAS によるホスティングの場合は、この処理を自分で実装する必要がありません。
なお、ServiceHost クラスは継承可能なので、ServiceHost クラスを継承した独自のクラスを作成して使用することもできます。 ( セルフ ホストでない場合でも可能です。 )
【 WCF ホストの設定 】
[ 設定方法の種類 ]
WCF ホストの設定は、コンフィギュレーションでの設定と、プログラムからの設定がサポートされています。
[ 主な設定項目 ]
WCF ホストの主な設定は以下の通りです。
BaseAddress ( ベースアドレス )
各エンドポイントのアドレスの、ベースとなるアドレスです。
Endpoint ( エンドポイント )
クライアントとの通信に関連する設定で、アドレスとバインディングとコントラクトで構成されます。
エンドポイントは一つのサービス クラスに対して複数用意することができます。また、各エンドポイントで異なるプロトコルを使用することが可能です。
Addresses ( アドレス )
エンドポイントのアドレスです。
アドレスは、完全パス、またはベースアドレスからの相対パスで指定します。
エンドポイントの使用するプロトコルに適合するベースアドレスが存在する場合、アドレスの設定を省略することができます。
アドレスは各エンドポイントで重複しないようにする必要があります。
Binding ( バインディング )
通信に使用するプロトコルや認証方法など、通信方法に関する設定です。
WCF では、標準でいくつかのバインディング・セットが用意されています。バインディング・セットを利用することで、設定が容易になります。バインディング セットは独自にカスタマイズすることが可能です。
また、カスタム バインディング セットを使って、バインディングの設定を本格的に設定することも可能です。
Contract ( コントラクト )
クライアントに公開するサービスのインターフェイスです。
サービス クラス、サービス クラスの基本クラス、サービス クラスが実装するインターフェイスを指定することができます。また、各エンドポイントで異なるコントラクトを設定することも可能です。
エンドポイントのアドレスです。
アドレスは、完全パス、またはベースアドレスからの相対パスで指定します。
エンドポイントの使用するプロトコルに適合するベースアドレスが存在する場合、アドレスの設定を省略することができます。
アドレスは各エンドポイントで重複しないようにする必要があります。
Binding ( バインディング )
通信に使用するプロトコルや認証方法など、通信方法に関する設定です。
WCF では、標準でいくつかのバインディング・セットが用意されています。バインディング・セットを利用することで、設定が容易になります。バインディング セットは独自にカスタマイズすることが可能です。
また、カスタム バインディング セットを使って、バインディングの設定を本格的に設定することも可能です。
Contract ( コントラクト )
クライアントに公開するサービスのインターフェイスです。
サービス クラス、サービス クラスの基本クラス、サービス クラスが実装するインターフェイスを指定することができます。また、各エンドポイントで異なるコントラクトを設定することも可能です。
Behavior ( ビヘイビア )
クライアントとの通信に関連しない設定です。
ビヘイビアには、 ServiceBehavior ( サービス ビヘイビア ) と EndpointBehavior ( エンドポイント ビヘイビア ) の2つがあります。
サービス ビヘイビアは一つのサービス クラスと対になります。一つのサービス クラスに対して複数のサービス ビヘイビアを適用することはできません。
エンドポイント ビヘイビアは一つのエンドポイントと対になります。一つのエンドポイントに対して複数のエンドポイント ビヘイビアを適用することはできません。
[ コンフィギュレーションで設定 ]
コンフィギュレーションでのWCF の設定は、 [ system.serviceModel ] セクションにて行います。
特に重要なのが [ system.serviceModel ] - [ services ] - [ service ] セクション です。
このセクションの name 属性にサービス クラスの名称を記述します。サービス クラスの ServiceBehaviorAttribute 属性のCongifurationName プロパティでコンフィギュレーション用の名称を指定し、その名称を記述することも可能です。
このセクションは一つのサービス クラスと対になります。一つのサービス クラスに対してこのセクションを複数用意することはできません。
ServiceHost オブジェクは、対応するサービス クラスの設定を行っている service セクションを、コンフィギュレーションから自動で検出してくれます。
ベースアドレス
service セクションの中に [ host ] - [ baseAddresses ] セクションを用意し、その中に [ add ] セクションを用意することで、ベースアドレスを指定することができます。 ( MSDN には baseAddress セクションを用意するように書いてありますが、これは誤りです。 )
[ add ] セクションは複数用意することが可能です。
エンドポイント
[ service ] セクションの中に [ endpoint ] セクションを用意することでエンドポイントを設定することができます。 [ endpoint ] セクションは複数存在させることが可能です。
アドレス
[ endpoint ] セクションの address 属性にて設定します。
バインディング
[ endpoint ] セクションの binding 属性にバインディング・セットの名称を設定することで、そのエンドポイントに対してバインディング・セットを適用することができます。バインディング・セットをカスタマイズする場合は、 [ system.serviceModel ] - [ bindings ] セクションの中に、カスタマイズするバインディング・セット用のセクションを用意し、更にその中に binding セクションを用意してこれを設定します。そして、 binding セクションの name 属性で指定したバインディング名称を、 endpoint セクションの bindingConfiguration 属性に指定します。
コントラクト
endpoint セクションの contract 属性にサービス コントラクトの名称を記述します。サービス コントラクトの ServiceContractAttribute 属性のCongifurationName プロパティ でコンフィギュレーション用の名称を指定し、その名称を記述することも可能です。
[ endpoint ] セクションの address 属性にて設定します。
バインディング
[ endpoint ] セクションの binding 属性にバインディング・セットの名称を設定することで、そのエンドポイントに対してバインディング・セットを適用することができます。バインディング・セットをカスタマイズする場合は、 [ system.serviceModel ] - [ bindings ] セクションの中に、カスタマイズするバインディング・セット用のセクションを用意し、更にその中に binding セクションを用意してこれを設定します。そして、 binding セクションの name 属性で指定したバインディング名称を、 endpoint セクションの bindingConfiguration 属性に指定します。
コントラクト
endpoint セクションの contract 属性にサービス コントラクトの名称を記述します。サービス コントラクトの ServiceContractAttribute 属性のCongifurationName プロパティ でコンフィギュレーション用の名称を指定し、その名称を記述することも可能です。
ビヘイビア
サービス ビヘイビアは [ system.serviceModel ] - [ behaviors ] - [ serviceBehaviors ] - [behavior ] セクションで設定します。 behavior セクションの name 属性で指定した名称を [ system.serviceModel ] - [ services ] - [ service ] セクション の behaviorConfiguration 属性に指定します。
エンドポイント ビヘイビアは [ system.serviceModel ] - [ behaviors ] - [ endpointBehaviors ] - [behavior ] セクションで設定します。そして、 behavior セクションの name 属性で指定した名称を [ system.serviceModel ] - [ services ] - [ service ] - [ endpoint ] セクション の behaviorConfiguration 属性に指定します。
・サンプル
以下に、コンフィギュレーションの設定例を示します。
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name="YokoKen.WCFServices.SampleService" behaviorConfiguration="SampleServiceBehavior">
<host>
<baseAddresses>
<add baseAddress="http://localhost/WCFServices/SampleService.svc"/>
<add baseAddress="net.tcp://localhost:10000/WCFServices/SampleService.svc"/>
<add baseAddress="net.pipe://WCFServices/SampleService.svc"/>
</baseAddresses>
</host>
<endpoint name="SampleServiceHttpEndpoint"
address=""
binding="basicHttpBinding"
bindingNamespace="http://schemas.yokoken.net/WCFServices"
contract="YokoKen.WCFServices.ISampleService" />
<endpoint name="SampleServiceNetTcpEndpoint"
address=""
binding="netTcpBinding"
bindingConfiguration="SampleServiceNetTcpBinding"
bindingNamespace="http://schemas.yokoken.net/WCFServices"
contract="YokoKen.WCFServices.ITestService" />
<endpoint name="SampleServiceNetNamedPipeEndpoint"
address=""
binding="netNamedPipeBinding"
bindingConfiguration="SampleServiceNetNamedPipeBinding"
bindingNamespace="http://schemas.yokoken.net/WCFServices"
contract="YokoKen.WCFServices.ITestService" />
</service>
</services>
<bindings>
<netTcpBinding>
<binding name="SampleServiceNetTcpBinding" >
<security mode="None"/>
</binding>
</netTcpBinding>
<netNamedPipeBinding>
<binding name="SampleServiceNetNamedPipeBinding">
<security mode="None"/>
</binding>
</netNamedPipeBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="SampleServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
[ プログラムで設定 ]
プログラムで直接設定する場合、ServiceHost オブジェクトを直接操作して設定を行うことになります。
特に重要なのが ServiceHost オブジェクトの Description プロパティ です。このプロパティの型は ServiceDescription クラス (System.ServiceModel.Description) です。
ベースアドレス
ベースアドレスは、 Uri クラス (System) で表わされます。
ベースアドレスの設定は、ServiceHost オブジェクトのコンストラクタにて行います。
また、 ServiceHost オブジェクトのの BaseAddresses プロパティ にて取得のみ行うことができます。このプロパティの型は、 ReadOnlyCollection ジェネリック クラス (System.Collections.ObjectModel) で、ジェネリック引数 T には、 Uri クラスが指定されています。
エンドポイント
エンドポイントは、ServiceEndpoint クラス (System.ServiceModel.Description) で表わされます。
エンドポイントの設定は、 ServiceDescription オブジェクトの Endpoints プロパティ にて行います。このプロパティの型は ServiceEndpointCollection クラス (System.ServiceModel.Description) です。このServiceEndpointCollection オブジェクトの Add メソッド にて、 ServiceEndpoint オブジェクトを追加します。
また、 ServiceHost オブジェクトの AddServiceEndpoint メソッド でエンドポイントを追加することも可能です。
// 追記 ( 2007/03/31 )
ServiceEndpoint のインスタンスを自分で生成するのではなく、AddServiceEndpoint メソッドを使用することを推奨します。
ServiceEndpoint のインスタンスを自分で生成する場合、 Address プロパティを適切に設定してやる必要があります。この時、ベースアドレスからの相対パスでの指定ができません。絶対パスで指定する必要があります。また、 Address プロパティの設定を忘れた場合 ( つまりnull の場合 ) 、 ServiceHost オブジェクトのOpen メソッドの実行途中で NullReferenceException が発生します。この例外情報から、「 Address プロパティが null であるために例外が発生した」という情報は得られません。
AddServiceEndpoint メソッドを使用した場合、これらの問題は発生しません。メソッドの引数 address には、ベースアドレスからの相対パスを指定することができます。ベースアドレスをそのまま使いたければ string.Empty を渡すだけです。 null を指定すれば、適切な例外をスローしてくれるので、原因がすぐにわかります。
アドレス
アドレスは、 EndpointAddress クラス (System.ServiceModel) で表わされます。
アドレスの設定は、ServiceEndpoint オブジェクトの Address プロパティ にて行います。
バインディング
バインディングは、 Binding クラス (System.ServiceModel.Channels) の派生クラスで表わされます。 Binding クラスの派生クラスは、各バインディング・セットに対応して用意されています。
バインディングの設定は、 ServiceEndpoint オブジェクトの Binding プロパティ にて行います。
コントラクト
コントラクトは、 ContractDescription クラス (System.ServiceModel.Description) で表わされます。このクラスのインスタンス生成には、GetContract メソッド を使用することもできます。
コントラクトの設定は、ServiceEndpoint クラスのコンストラクタや、 ServiceHost オブジェクトの AddServiceEndpoint メソッドの引数で行います。また、 ServiceEndpoint オブジェクトの Contract プロパティ にて取得のみ行うことができます。
アドレスは、 EndpointAddress クラス (System.ServiceModel) で表わされます。
アドレスの設定は、ServiceEndpoint オブジェクトの Address プロパティ にて行います。
バインディング
バインディングは、 Binding クラス (System.ServiceModel.Channels) の派生クラスで表わされます。 Binding クラスの派生クラスは、各バインディング・セットに対応して用意されています。
バインディングの設定は、 ServiceEndpoint オブジェクトの Binding プロパティ にて行います。
コントラクト
コントラクトは、 ContractDescription クラス (System.ServiceModel.Description) で表わされます。このクラスのインスタンス生成には、GetContract メソッド を使用することもできます。
コントラクトの設定は、ServiceEndpoint クラスのコンストラクタや、 ServiceHost オブジェクトの AddServiceEndpoint メソッドの引数で行います。また、 ServiceEndpoint オブジェクトの Contract プロパティ にて取得のみ行うことができます。
ビヘイビア
サービス ビヘイビアは、 IServiceBehavior インターフェイス (System.ServiceModel.Description) を実装したクラスで表わされます。
サービス ビヘイビアの設定は、 ServiceDescription オブジェクトの Behaviors プロパティ で行います。このプロパティの型は KeyedByTypeCollection ジェネリック クラス (System.Collections.Generic) で、ジェネリック引数 TItem には IServiceBehavior インターフェイスが指定されています。このKeyedByTypeCollection オブジェクトの Add メソッド にて、 IServiceBehavior オブジェクトを追加します。
エンドポイント ビヘイビアは、 IEndpointBehavior インターフェイス (System.ServiceModel.Description) を実装したクラスで表わされます。
エンドポイント ビヘイビアの設定は、 ServiceEndpoint オブジェクトの Behaviors プロパティ で行います。このプロパティの型は KeyedByTypeCollection ジェネリック クラスで、ジェネリック引数 TItemには IEndpointBehavior インターフェイスが指定されています。このKeyedByTypeCollection オブジェクトの Add メソッドにて、 IEndpointBehavior オブジェクトを追加します。
・サンプル
以下に、プログラムでの設定例を示します。
( 2007/03/31 : AddServiceEndpoint メソッドを使うように修正 )
// using System.ServiceModel;
// using System.ServiceModel.Channels;
// using System.ServiceModel.Description;
private static void SettingSampleServiceHost(ServiceHost sampleServiceHost)
{
const string sampleServiceBindingNamespace = "http://schemas.yokoken.net/WCFServices";
Type sampleServiceContractType = typeof(ISampleService);
Binding sampleServiceHttpBinding = new BasicHttpBinding();
sampleServiceHttpBinding.Namespace = sampleServiceBindingNamespace;
Binding sampleServiceNetTcpBinding = new NetTcpBinding(SecurityMode.None);
sampleServiceNetTcpBinding.Namespace = sampleServiceBindingNamespace;
Binding sampleServiceNetNamedPipeBinding = new NetNamedPipeBinding(NetNamedPipeSecurityMode.None);
sampleServiceNetNamedPipeBinding.Namespace = sampleServiceBindingNamespace;
ServiceMetadataBehavior sampleServiceMetadataBehavior = new ServiceMetadataBehavior();
sampleServiceMetadataBehavior.HttpGetEnabled = true;
sampleServiceHost.AddServiceEndpoint(sampleServiceContractType, sampleServiceHttpBinding, string.Empty);
sampleServiceHost.AddServiceEndpoint(sampleServiceContractType, sampleServiceNetTcpBinding, string.Empty);
sampleServiceHost.AddServiceEndpoint(sampleServiceContractType, sampleServiceNetNamedPipeBinding, string.Empty);
sampleServiceHost.Description.Behaviors.Add(sampleServiceMetadataBehavior);
}
【 セルフ ホスティング 】
冒頭でも説明したように、セルフ ホスティングは ServiceHost オブジェクトの操作を自分で実装します。
[ コンフィギュレーションで設定 ]
ServiceHost オブジェクトは、コンフィギュレーションでの設定を自動で認識します。
以下に、コンフィギュレーションで設定を行う場合のセルフ ホスト プログラムの例を示します。
// using System.ServiceModel;
// using System.ServiceModel.Dispatcher;
static void Main(string[] args)
{
Type sampleServiceType = typeof(SampleService);
using (ServiceHost sampleServiceHost = new ServiceHost(sampleServiceType))
{
sampleServiceHost.Open();
foreach (ChannelDispatcher dispatcher in sampleServiceHost.ChannelDispatchers)
{
Console.WriteLine("Listening uri: {0}", dispatcher.Listener.Uri.ToString());
}
Console.WriteLine("Enter キーを押すと終了します。");
Console.ReadLine();
sampleServiceHost.Close();
}
}
[ プログラムで設定 ]
プログラムで設定する場合は、 ServiceHost オブジェクトに対して設定を行います。
先ほどプログラムでの設定例として挙げた SettingSampleServiceHost メソッドを使って設定を行う、セルフ ホスト プログラム の例を以下に示します。
// using System.ServiceModel;
// using System.ServiceModel.Dispatcher;
static void Main(string[] args)
{
Type sampleServiceType = typeof(SampleService);
Uri[] sampleServiceBaseAddress =
new Uri[]
{
new Uri("http://localhost/WCFServices/SampleService.svc"),
new Uri("net.tcp://localhost:10000/WCFServices/SampleService.svc"),
new Uri("net.pipe://WCFServices/SampleService.svc")
};
using (ServiceHost sampleServiceHost = new ServiceHost(sampleServiceType, sampleServiceBaseAddress))
{
SettingSampleServiceHost(sampleServiceHost);
sampleServiceHost.Open();
foreach (ChannelDispatcher dispatcher in sampleServiceHost.ChannelDispatchers)
{
Console.WriteLine("Listening uri: {0}", dispatcher.Listener.Uri.ToString());
}
Console.WriteLine("Enter キーを押すと終了します。");
Console.ReadLine();
sampleServiceHost.Close();
}
}
【 IIS によるホスティング 】
IIS によるホスティングは簡単で、 ServiceHost ディレクティブを記述したsvc ファイルを用意し、コンフィギュレーションまたはプログラムにて WCF の設定を適切に行い、IIS にて仮想フォルダに配置するだけです。
IIS ホストの場合、HTTPプロトコル以外を使用するエンドポイントは使用できません。また、ベースアドレスの設定は無視され、 svc ファイルのアドレスがベースアドレスとなります。
[ コンフィギュレーションで設定 ]
Web.config にて設定を行います。特別な設定はありません。
[ プログラムで設定 ]
・内部動作
IIS によるホスティングの場合、WCF は、HttpApplication クラス (System.Web) の PostAuthorizeRequest イベント にハンドラを登録し、そのハンドラの内部で ServiceHostingEnvironment クラス (System.ServiceModel) の EnsureServiceAvailable メソッド を呼び出します。 ( 厳密には、このメソッドではなく、EnsureServiceAvailableFast メソッド ( 可視性 internal ) を直接呼び出しています。 )
このメソッドは、内部で ServiceHostFactory クラス (System.ServiceModel.Activation) の CreateServiceHost メソッド を使って ServiceHost クラスのインスタンスを生成します。
・設定方法
ServiceHostFactory クラスを継承した独自のクラスを定義し、このクラスの名称を svc ファイルの ServiceHost ディレクティブ の Factory 属性に指定します。すると、IIS は一連の内部動作の流れの中で、このクラスを使用して ServiceHost クラスのインスタンスを生成するようになります。
つまり、ServiceHostFactory クラスを継承した独自のクラスでCreateServiceHost メソッドをオーバーライドすれば、IIS が使用する ServiceHost オブジェクトをカスタマイズすることができます。これにより、コンフィギュレーションを使わずに WCF の設定を行うことができます。
IIS によるホスティングで、プログラムから設定を行う場合の、 svc ファイルの設定例を以下に示します。
<% @ServiceHost Service="YokoKen.WCFServices.SampleService" Factory="YokoKen.WCFServices.Hosts.SampleServiceHostFactory"%>
IIS によるホスティングで、プログラムから設定を行う場合の、 独自 ServiceHostFactory クラスの例を以下に示します。
using System.ServiceModel;
using System.ServiceModel.Activation;
namespace YokoKen.WCFServices.Hosts
{
public class SampleServiceHostFactory : ServiceHostFactory
{
protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
{
ServiceHost result = base.CreateServiceHost(serviceType, baseAddresses);
this.SettingSampleServiceHost(result);
return result;
}
private void SettingSampleServiceHost(ServiceHost target)
{
// 設定処理
}
}
}
【 WAS によるホスティング 】
未調査です。今後の課題ということで。
スポンサーサイト
2007/03/24 17:26
[ WCFのホストとサービスの分割 ]
WCFのホスティングは、大別して 2種類 3種類あります。ひとつは IIS によるホスティング、もう一つはセルフ ホスティングです。→ さらにWAS ( Windows Process Activation Service ) によるホスティングがありました。
IIS によるホスティングなら Web サイトとして、セルフ ホスティングならコンソールアプリケーションや Windows サービスのプロジェクトとして構築することになるかと思います。
HTTP ( またはHTTPS ) プロトコル以外を使用する場合は クライアントのプロキシ クラスを動的に生成する場合は、WCF サービスを定義したアセンブリを、ホストアプリケーションとクライアントアプリケーションの両方で参照する必要があるので、WCF サービスの定義はクラスライブラリにて行います。 ( まぁ、ホストアプリケーションに直接定義して、クライアントアプリケーションはホストアプリケーション自体を参照設定することもできますけど・・・。 )
ホスティング方法に関わらず、WCF サービスはホストアプリケーションとは切り離して、クラスライブラリにした方がいいかと思います。なぜなら、ホスティング方法が変更になっても、変更作業が容易にできるからです。
セルフ ホスティングの場合、クラスライブラリに切り離した所で何も特別な作業は必要ありません。普通にプログラミングすればいいです。
では IIS によるホスティングの場合はどうかというと、これも特別な作業は必要ありません。
強いて言うなれば、IIS によるホスティングの場合は、 svc ファイルを用意してその中で ServiceHost ディレクティブを記述する必要があるのですが、この時コードビハインドの設定ができます。しかし、 WCF サービスをクラスライブラリとした場合、当然コードビハインドは利用できません。
[ ServiceHost ディレクティブの例 ]
IIS によるホスティングで、クラスライブラリに定義した "YokoKen.WCFServices.TestService" という WCF サービスを使用する場合の、 svc ファイルの記述例を以下に示します。
<% @ServiceHost Service="YokoKen.WCFServices.TestService" %>
見ての通り、特別な記述は何もありません。コードビハインドを利用しないため、Language 属性や CodeBehind 属性は不要です。
[ 参考 ]
Directive Syntax
@ServiceHost
WCFのホスティングは、大別して 2種類 3種類あります。ひとつは IIS によるホスティング、もう一つはセルフ ホスティングです。→ さらにWAS ( Windows Process Activation Service ) によるホスティングがありました。
IIS によるホスティングなら Web サイトとして、セルフ ホスティングならコンソールアプリケーションや Windows サービスのプロジェクトとして構築することになるかと思います。
HTTP ( またはHTTPS ) プロトコル以外を使用する場合は クライアントのプロキシ クラスを動的に生成する場合は、WCF サービスを定義したアセンブリを、ホストアプリケーションとクライアントアプリケーションの両方で参照する必要があるので、WCF サービスの定義はクラスライブラリにて行います。 ( まぁ、ホストアプリケーションに直接定義して、クライアントアプリケーションはホストアプリケーション自体を参照設定することもできますけど・・・。 )
ホスティング方法に関わらず、WCF サービスはホストアプリケーションとは切り離して、クラスライブラリにした方がいいかと思います。なぜなら、ホスティング方法が変更になっても、変更作業が容易にできるからです。
セルフ ホスティングの場合、クラスライブラリに切り離した所で何も特別な作業は必要ありません。普通にプログラミングすればいいです。
では IIS によるホスティングの場合はどうかというと、これも特別な作業は必要ありません。
強いて言うなれば、IIS によるホスティングの場合は、 svc ファイルを用意してその中で ServiceHost ディレクティブを記述する必要があるのですが、この時コードビハインドの設定ができます。しかし、 WCF サービスをクラスライブラリとした場合、当然コードビハインドは利用できません。
[ ServiceHost ディレクティブの例 ]
IIS によるホスティングで、クラスライブラリに定義した "YokoKen.WCFServices.TestService" という WCF サービスを使用する場合の、 svc ファイルの記述例を以下に示します。
<% @ServiceHost Service="YokoKen.WCFServices.TestService" %>
見ての通り、特別な記述は何もありません。コードビハインドを利用しないため、Language 属性や CodeBehind 属性は不要です。
[ 参考 ]
Directive Syntax
@ServiceHost
2007/03/24 15:50
Windows SDK Update for Windows Vistaがリリースされました。
Windows SDK for Windows Vista を既にインストールしてある場合は、先にアンインストールする必要があります。
Download details: Windows SDK Update for Windows Vista
[ 過去の関連記事 ]
C#と諸々 .NET Framework 3.0 正式版 リリース
Windows SDK for Windows Vista を既にインストールしてある場合は、先にアンインストールする必要があります。
Download details: Windows SDK Update for Windows Vista
[ 過去の関連記事 ]
C#と諸々 .NET Framework 3.0 正式版 リリース
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 待ちとなります。
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 待ちとなります。
2007/03/22 17:50
Visual Studio 2005 Web Deployment Projects でドキュメント コメント ファイルが出力されない orz
プロジェクトファイル開いて [ Project ] - [ PropertyGroup ] セクションに [ DocumentationFile ] セクションを追加してその中にファイル名指定してるのに出力されない orz
ファイル名の指定方法も色々 ( 絶対パスやら相対パスやら何やら ) 試したけど出力されない orz
Web.config に [ system.codedom ] - [ compilers ] - [ compiler ] セクションを追加して /doc:file オプションを指定してやる場合は出力されるのに orz
いや、まぁこれで充分なんだけど・・・。
orz
プロジェクトファイル開いて [ Project ] - [ PropertyGroup ] セクションに [ DocumentationFile ] セクションを追加してその中にファイル名指定してるのに出力されない orz
ファイル名の指定方法も色々 ( 絶対パスやら相対パスやら何やら ) 試したけど出力されない orz
Web.config に [ system.codedom ] - [ compilers ] - [ compiler ] セクションを追加して /doc:file オプションを指定してやる場合は出力されるのに orz
いや、まぁこれで充分なんだけど・・・。
orz
2007/03/19 16:47
newpopsさんが執筆した「Windows PowerShell宣言!」という、PowerShellの書籍が07年03月28日に発売されるそうです。
これは是非、手元に置いておきたいですね！
[ 購入リンク ]
Amazon.co.jp： Windows PowerShell宣言!: 本: 吉岡 洋
[ 情報元 ]
PowerShell Memo - Windows PowerShell宣言！
これは是非、手元に置いておきたいですね！
[ 購入リンク ]
Amazon.co.jp： Windows PowerShell宣言!: 本: 吉岡 洋
[ 情報元 ]
PowerShell Memo - Windows PowerShell宣言！
2007/03/11 21:16
[ クライアントのアカウント情報を取得する ]
WCFでは、 ServiceSecurityContext クラス (System.ServiceModel) のCurrent 静的プロパティから、現在のクライアントのアカウント情報を格納する ServiceSecurityContext オブジェクトが取得できます。
この ServiceSecurityContext オブジェクトの WindowsIdentity プロパティまたは PrimaryIdentity プロパティにて、クライアントのアカウント情報を取得できます。
しかし、バインディングの設定によってはクライアントのアカウント情報を取得できません。その場合、 ServiceSecurityContext.Current は null を返します。
[ WS-Security ]
WCFではWS-Securityを利用することができます。
WS-Securityによって、SOAPメッセージの完全性、秘匿性が確保されます。
WS-Securityを有効にしている場合、クライアントのアカウント情報を取得することもできます。
WsHttpBingindバインディングセットでは、デフォルトでWS-Securityが適用されます。BasicHttpBindingバインディングセットではWS-Securityを利用することができません。
WsHttpBindingバインディングセットでは、 [ wsHttpBinding ] - [ binding ] - [ security ] セクションの mode 属性に、 "Message" または "TransportWithMessageCredential" を指定すると、WS-Securityが適用されます。これ以外の値を指定した場合、WS-Securityは適用されません。デフォルト値は "Message" です。
なお、WS-Security を適用する場合、 [ wsHttpBinding ] - [ binding ] - [ security ] - [ message ] セクションの clientCredentialType 属性にて認証方式を指定することができます。この属性に指定できる値は HttpClientCredentialType 列挙体 (System.ServiceModel) の列挙値となります。デフォルト値は "Windows" です。この属性に "None" を指定した場合、クライアントは匿名アクセスを行います。 ( ServiceSecurityContext.Current は null になりません。 )
WS-Securityは、セキュリティの強化が行われる分、通信データ量は肥大化し、SOAPメッセージでやりとりされるデータの暗号化・復号化というコストの高い処理が発生します。
SOAPメッセージの完全性、秘匿性が要求されるような場合はWS-Securityを適用し、それ以外の場合で、特にパフォーマンスが要求されるような場合はWS-Securityは適用しない方がいいかと思います。
[ WS-Securityを適用せずにクライアントの認証情報を取得する ]
WS-Securityを適用せずにクライアントの認証情報を取得したい場合、 CustomBinding バインディングセットを使用し、 [ customBinding ] - [ binding ] - [ httpTransport ] セクションの authenticationScheme 属性にて適切な認証方式を設定します。更に、authenticationScheme属性で指定した認証方式に応じて、IISの認証方法も適切に設定する必要があります ( 匿名アクセスを不可に設定することも可能 ) 。
authenticationScheme 属性に指定できる値は、 AuthenticationSchemes 列挙体 (System.Net) の列挙値となります。デフォルト値は "Anonymous" です。
ただし、"IntegratedWindowsAuthentication" ( 統合Windows認証 ) や "None" を指定すると、「ファクトリは ExactlyOne 認証しかサポートしていません」とエラーになります。
統合Windows認証の代わりには、 "Negotiate" または "Ntlm" を指定します ( 通常は、Kerberos 認証とNTLM認証をサポートする "Negotiate" を指定しておけば問題ないと思います ) 。
他にも、"Digest", "Basic", "Anonymous" を指定することができます。 "Anonymous" を指定した場合、クライアントは匿名認証を行います。 ( ServiceSecurityContext.Current は null になります。 )
WS-Security を適用せずに、Negotiate 認証を利用する場合の設定例を以下に示します。
<customBinding>
<binding name="MyServiceBinding">
<httpTransport authenticationScheme="Negotiate" />
</binding>
</customBinding>
WCFでは、 ServiceSecurityContext クラス (System.ServiceModel) のCurrent 静的プロパティから、現在のクライアントのアカウント情報を格納する ServiceSecurityContext オブジェクトが取得できます。
この ServiceSecurityContext オブジェクトの WindowsIdentity プロパティまたは PrimaryIdentity プロパティにて、クライアントのアカウント情報を取得できます。
しかし、バインディングの設定によってはクライアントのアカウント情報を取得できません。その場合、 ServiceSecurityContext.Current は null を返します。
[ WS-Security ]
WCFではWS-Securityを利用することができます。
WS-Securityによって、SOAPメッセージの完全性、秘匿性が確保されます。
WS-Securityを有効にしている場合、クライアントのアカウント情報を取得することもできます。
WsHttpBingindバインディングセットでは、デフォルトでWS-Securityが適用されます。BasicHttpBindingバインディングセットではWS-Securityを利用することができません。
WsHttpBindingバインディングセットでは、 [ wsHttpBinding ] - [ binding ] - [ security ] セクションの mode 属性に、 "Message" または "TransportWithMessageCredential" を指定すると、WS-Securityが適用されます。これ以外の値を指定した場合、WS-Securityは適用されません。デフォルト値は "Message" です。
なお、WS-Security を適用する場合、 [ wsHttpBinding ] - [ binding ] - [ security ] - [ message ] セクションの clientCredentialType 属性にて認証方式を指定することができます。この属性に指定できる値は HttpClientCredentialType 列挙体 (System.ServiceModel) の列挙値となります。デフォルト値は "Windows" です。この属性に "None" を指定した場合、クライアントは匿名アクセスを行います。 ( ServiceSecurityContext.Current は null になりません。 )
WS-Securityは、セキュリティの強化が行われる分、通信データ量は肥大化し、SOAPメッセージでやりとりされるデータの暗号化・復号化というコストの高い処理が発生します。
SOAPメッセージの完全性、秘匿性が要求されるような場合はWS-Securityを適用し、それ以外の場合で、特にパフォーマンスが要求されるような場合はWS-Securityは適用しない方がいいかと思います。
[ WS-Securityを適用せずにクライアントの認証情報を取得する ]
WS-Securityを適用せずにクライアントの認証情報を取得したい場合、 CustomBinding バインディングセットを使用し、 [ customBinding ] - [ binding ] - [ httpTransport ] セクションの authenticationScheme 属性にて適切な認証方式を設定します。更に、authenticationScheme属性で指定した認証方式に応じて、IISの認証方法も適切に設定する必要があります ( 匿名アクセスを不可に設定することも可能 ) 。
authenticationScheme 属性に指定できる値は、 AuthenticationSchemes 列挙体 (System.Net) の列挙値となります。デフォルト値は "Anonymous" です。
ただし、"IntegratedWindowsAuthentication" ( 統合Windows認証 ) や "None" を指定すると、「ファクトリは ExactlyOne 認証しかサポートしていません」とエラーになります。
統合Windows認証の代わりには、 "Negotiate" または "Ntlm" を指定します ( 通常は、Kerberos 認証とNTLM認証をサポートする "Negotiate" を指定しておけば問題ないと思います ) 。
他にも、"Digest", "Basic", "Anonymous" を指定することができます。 "Anonymous" を指定した場合、クライアントは匿名認証を行います。 ( ServiceSecurityContext.Current は null になります。 )
WS-Security を適用せずに、Negotiate 認証を利用する場合の設定例を以下に示します。
<customBinding>
<binding name="MyServiceBinding">
<httpTransport authenticationScheme="Negotiate" />
</binding>
</customBinding>
2007/03/07 23:20
開発者向けMicrosoft製品の評価版・ベータ版を集約するサイトが登場したようです。
MSDN Evaluation Center
以下、引用です。
最新のソフトウェア製品の評価版、ベータ版の入手にいちいち製品サイトをチェックいただく必要はこれからはございません。
常に提供可能な評価版、ベータ版は MSDN Evaluation Center で、関連リソースと共に用意にアクセス、入手いただけます。
MSDN Evaluation Center
以下、引用です。
最新のソフトウェア製品の評価版、ベータ版の入手にいちいち製品サイトをチェックいただく必要はこれからはございません。
常に提供可能な評価版、ベータ版は MSDN Evaluation Center で、関連リソースと共に用意にアクセス、入手いただけます。
タグ:
2007/03/07 17:48
WCF Webサービスで早速 Web 配置プロジェクト を試してみました。つっても、ほとんどデフォルト設定のままやったのですが。
で、Web配置プロジェクトの [ プロジェクト ] - [ プロパティ ] で、 [ コンパイル ] - [ このプリコンパイル済みサイトを更新可能にする ] のチェックを外した場合、うまく動きませんね。
従来の方法の場合、つまり、WCF Webサービスプロジェクトの プロパティページで [ MSBuild オプション ] - [ このプリコンパイル済みサイトを更新可能にする ] のチェックを外し [ ビルド ] - [ Web サイトの発行 ] で発行した場合、問題なく動きます。
で、出力される PrecompiledApp.config ファイルを覗いてみると、従来の方法で出力されたファイルは、 updatable 属性が False になっていませんでした。 Web 配置プロジェクトで出力されたファイルは False になっています。つまり、従来の方法だと先ほどのオプションが無視されていると。svc ファイルを覗いてみても、従来の方法で出力されたファイルは変化していません。 Web 配置プロジェクトで出力されたファイルは "これは、プリコンパイル ツールによって生成されたマーカー ファイルです。削除しないでください。" という内容に書き換えられています。
つまり、WCFでは [ このプリコンパイル済みサイトを更新可能にする ] のチェックを外すなということですかね。まぁ、WCFはUIを持たないのだからどっちでもいいんですけど ＾＾；
ちなみにこのエラー、ブラウザでアクセスしてみると以下のような例外情報が表示されます。
例外の詳細: System.ArgumentNullException: 値を Null にすることはできません。
パラメータ名: key
スタックトレースは割愛。
で、Web配置プロジェクトの [ プロジェクト ] - [ プロパティ ] で、 [ コンパイル ] - [ このプリコンパイル済みサイトを更新可能にする ] のチェックを外した場合、うまく動きませんね。
従来の方法の場合、つまり、WCF Webサービスプロジェクトの プロパティページで [ MSBuild オプション ] - [ このプリコンパイル済みサイトを更新可能にする ] のチェックを外し [ ビルド ] - [ Web サイトの発行 ] で発行した場合、問題なく動きます。
で、出力される PrecompiledApp.config ファイルを覗いてみると、従来の方法で出力されたファイルは、 updatable 属性が False になっていませんでした。 Web 配置プロジェクトで出力されたファイルは False になっています。つまり、従来の方法だと先ほどのオプションが無視されていると。svc ファイルを覗いてみても、従来の方法で出力されたファイルは変化していません。 Web 配置プロジェクトで出力されたファイルは "これは、プリコンパイル ツールによって生成されたマーカー ファイルです。削除しないでください。" という内容に書き換えられています。
つまり、WCFでは [ このプリコンパイル済みサイトを更新可能にする ] のチェックを外すなということですかね。まぁ、WCFはUIを持たないのだからどっちでもいいんですけど ＾＾；
ちなみにこのエラー、ブラウザでアクセスしてみると以下のような例外情報が表示されます。
例外の詳細: System.ArgumentNullException: 値を Null にすることはできません。
パラメータ名: key
スタックトレースは割愛。
2007/03/07 10:59
やっと出ました、 Visual Studio 2005 Service Pack 1 Update for Windows Vista ！
ダウンロードの詳細 : VS2005 SP1 Update for Vista
ダウンロードの詳細 : VS2005 SP1 Update for Vista
2007/03/05 13:58
Visual Studio 2005 Web Deployment Projects 日本語版がリリースされました。
Visual Studio 2005 Web Deployment Projects
これは中々便利かもしれません。
以下、機能の概要をホワイトペーパーから抜粋します。
・ビルド プロセスの一部としての ASP.NET 2.0 プリコンパイル
・Web プロジェクトからコンパイル済みのアセンブリを生成する際の柔軟なオプション。次の選択肢があります。
・Web サイト全体に対して単一のアセンブリを生成する。
・コンテンツ フォルダごとに 1 つのアセンブリを生成する。
・すべての UI コンポーネントに対して単一のアセンブリを生成する。
・Web サイト内のコンパイル済みファイルごとに 1 つのアセンブリを生成する。
・アセンブリの署名オプション
・カスタムのビルド前アクションおよびビルド後アクションの定義
・ビルドからのフォルダの除外
・Visual Studio のビルド構成に基づいた、Web.config ファイル (<connectionString> 要素など) の設定の変更
・セットアップ プロジェクトでの .msi ファイルの作成のサポート
Visual Studio 2005 Web Deployment Projects
これは中々便利かもしれません。
以下、機能の概要をホワイトペーパーから抜粋します。
・ビルド プロセスの一部としての ASP.NET 2.0 プリコンパイル
・Web プロジェクトからコンパイル済みのアセンブリを生成する際の柔軟なオプション。次の選択肢があります。
・Web サイト全体に対して単一のアセンブリを生成する。
・コンテンツ フォルダごとに 1 つのアセンブリを生成する。
・すべての UI コンポーネントに対して単一のアセンブリを生成する。
・Web サイト内のコンパイル済みファイルごとに 1 つのアセンブリを生成する。
・アセンブリの署名オプション
・カスタムのビルド前アクションおよびビルド後アクションの定義
・ビルドからのフォルダの除外
・Visual Studio のビルド構成に基づいた、Web.config ファイル (<connectionString> 要素など) の設定の変更
・セットアップ プロジェクトでの .msi ファイルの作成のサポート
2007/03/03 23:21
@ITさんにて「ASP.NET AJAXを理解する」という新連載がスタートしたようです。
執筆はMicrosoft デベロッパーエバンジェリストの松崎剛さんです。
ASP.NET AJAXを理解する － ＠IT
執筆はMicrosoft デベロッパーエバンジェリストの松崎剛さんです。
ASP.NET AJAXを理解する － ＠IT
Calendar
