サービス コントラクトの設計Designing Service Contracts

ここでは、サービス コントラクトの概要、定義方法、使用できる操作 (および基になるメッセージ交換の影響)、使用するデータ型、およびシナリオの要件を満たす操作を設計する際に役立つその他の問題について説明します。This topic describes what service contracts are, how they are defined, what operations are available (and the implications for the underlying message exchanges), what data types are used, and other issues that help you design operations that satisfy the requirements of your scenario.

サービス コントラクトの作成Creating a Service Contract

サービスは複数の操作を公開します。Services expose a number of operations. Windows Communication Foundation (WCF) アプリケーションでメソッドを作成することをマークすることによって、操作を定義、OperationContractAttribute属性。In Windows Communication Foundation (WCF) applications, define the operations by creating a method and marking it with the OperationContractAttribute attribute. 次に、サービス コントラクトを作成するために、ServiceContractAttribute 属性でマークされたインターフェイス内で操作を宣言するか、この属性でマークされたクラス内で操作を定義することにより、操作をグループ化します Then, to create a service contract, group together your operations, either by declaring them within an interface marked with the ServiceContractAttribute attribute, or by defining them in a class marked with the same attribute. (基本的な例では、次を参照してください。方法。サービス コントラクトを定義する)。(For a basic example, see How to: Define a Service Contract.)

すべてのメソッドがない、OperationContractAttribute属性は、サービス操作ではありませんし、WCF サービスによって公開されていません。Any methods that do not have a OperationContractAttribute attribute are not service operations and are not exposed by WCF services.

ここでは、サービス コントラクトの設計時に決定すべき以下のポイントについて説明します。This topic describes the following decision points when designing a service contract:

  • クラスとインターフェイスのどちらを使用するかWhether to use classes or interfaces.

  • 交換するデータ型の指定方法How to specify the data types you want to exchange.

  • 使用できる交換パターンの種類The types of exchange patterns you can use.

  • コントラクトのセキュリティ要件の部分を明示的に作成できるかどうかWhether you can make explicit security requirements part of the contract.

  • 操作の入力と出力の制限The restrictions for operation inputs and outputs.

クラスとインターフェイスClasses or Interfaces

機能のグループ化を表すクラスとインターフェイスの両方と、両方を使用して WCF サービス コントラクトを定義するため、します。Both classes and interfaces represent a grouping of functionality and, therefore, both can be used to define a WCF service contract. ただし、インターフェイスはサービス コントラクトを直接モデル化するため、インターフェイスを使用することをお勧めします。However, it is recommended that you use interfaces because they directly model service contracts. 実装のないインターフェイスは、特定のシグネチャを持つメソッドのグループ化を定義しているにすぎません。Without an implementation, interfaces do no more than define a grouping of methods with certain signatures. サービス コントラクト インターフェイスを実装し、WCF サービスを実装しています。Implement a service contract interface and you have implemented a WCF service.

サービス コントラクト インターフェイスには、次のようにマネージド インターフェイスのあらゆる利点がもたらされます。All the benefits of managed interfaces apply to service contract interfaces:

  • サービス コントラクト インターフェイスでは、他のサービス コントラクト インターフェイスをいくつでも拡張できます。Service contract interfaces can extend any number of other service contract interfaces.

  • これらのサービス コントラクト インターフェイスを実装することにより、1 つのクラスでサービス コントラクトをいくつでも実装できます。A single class can implement any number of service contracts by implementing those service contract interfaces.

  • インターフェイスの実装を変更することにより、同じサービス コントラクトを引き続き使用したまま、そのコントラクトの実装を変更できます。You can modify the implementation of a service contract by changing the interface implementation, while the service contract remains the same.

  • 以前のインターフェイスと新しいインターフェイスを実装することで、サービスをバージョン管理できます。You can version your service by implementing the old interface and the new one. 以前のクライアントは元のバージョンに接続し、新しいクライアントは新しいバージョンに接続できます。Old clients connect to the original version, while newer clients can connect to the newer version.

注意

他のサービス コントラクト インターフェイスから継承した場合、操作のプロパティ (名前や名前空間など) をオーバーライドすることはできません。When inheriting from other service contract interfaces, you cannot override operation properties, such as the name or namespace. これを行う場合は、現在のサービス コントラクトに新しい操作を作成します。If you attempt to do so, you create a new operation in the current service contract.

インターフェイスを使用して、サービス コントラクトを作成する例は、次を参照してください。方法。サービス コントラクト インターフェイスを作成です。For an example of using an interface to create a service contract, see How to: Create a Service with a Contract Interface.

クラスを使用すると、サービス コントラクトの定義と実装を一度に行うことができます。You can, however, use a class to define a service contract and implement that contract at the same time. ServiceContractAttributeOperationContractAttribute をそれぞれクラスとクラスのメソッドに直接適用してサービスを作成する方法には、サービスを迅速かつ簡単に作成できるという利点があります。The advantage of creating your services by applying ServiceContractAttribute and OperationContractAttribute directly to the class and the methods on the class, respectively, is speed and simplicity. 欠点は、マネージド クラスでは複数の継承をサポートしていないため、サービス コントラクトを一度に 1 つしか実装できないことです。The disadvantages are that managed classes do not support multiple inheritance, and as a result they can only implement one service contract at a time. また、クラスまたはメソッド シグネチャに変更を加えると、そのサービスのパブリック コントラクトが変更されるため、変更されていないクライアントがサービスを使用できなくなることがあります。In addition, any modification to the class or method signatures modifies the public contract for that service, which can prevent unmodified clients from using your service. 詳細については、次を参照してください。 Implementing Service Contractsします。For more information, see Implementing Service Contracts.

クラスを使用して、サービス コントラクトを作成し、同時に実装されているは、次を参照してください。方法。コントラクト クラスを使用してサービスを作成です。For an example that uses a class to create a service contract and implements it at the same time, see How to: Create a Service with a Contract Class.

これで、サービス コントラクトを定義する際に、インターフェイスを使用した場合とクラスを使用した場合の違いがわかりました。At this point, you should understand the difference between defining your service contract by using an interface and by using a class. 次に、サービスとクライアント間で受け渡しできるデータを決定します。The next step is deciding what data can be passed back and forth between a service and its clients.

パラメーターと戻り値Parameters and Return Values

各操作は戻り値とパラメーターを持ちます (戻り値とパラメーターが void の場合も含まれます)。Each operation has a return value and a parameter, even if these are void. ただし、オブジェクトへの参照をオブジェクト間で渡すことができるローカル メソッドとは異なり、サービス操作ではオブジェクトへの参照を渡しません。However, unlike a local method, in which you can pass references to objects from one object to another, service operations do not pass references to objects. 代わりに、オブジェクトのコピーを渡します。Instead, they pass copies of the objects.

これが重要なのは、パラメーターまたは戻り値で使用される各型がシリアル化可能でなければならないためです。つまり、その型のオブジェクトをバイト ストリームに変換でき、バイト ストリームからオブジェクトに変換できる必要があります。This is significant because each type used in a parameter or return value must be serializable; that is, it must be possible to convert an object of that type into a stream of bytes and from a stream of bytes into an object.

プリミティブ型は既定でシリアル化可能であり、.NET Framework の多くの型も同様です。Primitive types are serializable by default, as are many types in the .NET Framework.

注意

操作シグネチャのパラメーター名の値はコントラクトに含まれ、大文字と小文字が区別されます。The value of the parameter names in the operation signature are part of the contract and are case sensitive. ローカルでは同じパラメーター名を使用するが、公開されるメタデータでは名前を変更する場合は、System.ServiceModel.MessageParameterAttribute を参照してください。If you want to use the same parameter name locally but modify the name in the published metadata, see the System.ServiceModel.MessageParameterAttribute.

データ コントラクトData Contracts

Windows Communication Foundation (WCF) アプリケーションのようなサービス指向アプリケーションは、Microsoft と Microsoft 以外のプラットフォームの両方のクライアント アプリケーションの場合は、できる限り多くの相互運用する設計されています。Service-oriented applications like Windows Communication Foundation (WCF) applications are designed to interoperate with the widest possible number of client applications on both Microsoft and non-Microsoft platforms. 最大限の相互運用性を実現するために、使用する型を DataContractAttribute 属性と DataMemberAttribute 属性でマークして、データ コントラクトを作成することをお勧めします。データ コントラクトは、サービス コントラクトの一部であり、サービス操作で交換するデータを記述したものです。For the widest possible interoperability, it is recommended that you mark your types with the DataContractAttribute and DataMemberAttribute attributes to create a data contract, which is the portion of the service contract that describes the data that your service operations exchange.

データ コントラクトは opt-in 方式のコントラクトは。データ コントラクト属性を明示的に適用されない限り、シリアル化型またはデータ メンバーはありません。Data contracts are opt-in style contracts: No type or data member is serialized unless you explicitly apply the data contract attribute. データ コントラクトは、マネージ コードのアクセス スコープに関連は。プライベート データ メンバーをシリアル化およびパブリックにアクセスする他の場所で送信されることができます。Data contracts are unrelated to the access scope of the managed code: Private data members can be serialized and sent elsewhere to be accessed publicly. (データ コントラクトの基本的な例を参照してください。方法。クラスまたは構造体に基本的なデータ コントラクトを作成)。WCF では、操作の機能を有効にする、基になる SOAP メッセージの定義に加え、シリアル化、データ型のメッセージの本文の出入りを処理します。(For a basic example of a data contract, see How to: Create a Basic Data Contract for a Class or Structure.) WCF handles the definition of the underlying SOAP messages that enable the operation's functionality as well as the serialization of your data types into and out of the body of the messages. 使用するデータ型がシリアル化可能であれば、操作の設計時に、基盤となるメッセージ交換インフラストラクチャについて考える必要はありません。As long as your data types are serializable, you do not need to think about the underlying message exchange infrastructure when designing your operations.

一般的な WCF アプリケーションを使用しますが、DataContractAttributeDataMemberAttribute属性操作については、データ コントラクトを作成するその他のシリアル化メカニズムを使用することができます。Although the typical WCF application uses the DataContractAttribute and DataMemberAttribute attributes to create data contracts for operations, you can use other serialization mechanisms. ISerializableSerializableAttribute、および IXmlSerializable の各標準機構はすべて、基になる SOAP メッセージへのデータ型のシリアル化を処理します。このメッセージはアプリケーション間でデータ型を伝達します。The standard ISerializable, SerializableAttribute and IXmlSerializable mechanisms all work to handle the serialization of your data types into the underlying SOAP messages that carry them from one application to another. 使用するデータ型で特別なサポートが必要な場合は、さらに多くのシリアル化方法を使用できます。You can employ more serialization strategies if your data types require special support. WCF アプリケーションでのデータ型のシリアル化の選択肢の詳細については、次を参照してください。 Data Transfer in Service Contracts にを指定するします。For more information about the choices for serialization of data types in WCF applications, see Specifying Data Transfer in Service Contracts.

メッセージ交換へのパラメーターと戻り値のマッピングMapping Parameters and Return Values to Message Exchanges

サービス操作は、特定の標準セキュリティ、トランザクション、およびセッション関連の機能をサポートするためにアプリケーションが必要とするデータに加え、アプリケーション データをやり取りする SOAP メッセージの基になる交換によってサポートされます。Service operations are supported by an underlying exchange of SOAP messages that transfer application data back and forth, in addition to the data required by the application to support certain standard security, transaction, and session-related features. これは大文字と小文字であるため、サービス操作のシグネチャは、基になるによって決まりますメッセージ交換パターン(MEP) データ転送と操作に必要な機能をサポートすることができます。Because this is the case, the signature of a service operation dictates a certain underlying message exchange pattern (MEP) that can support the data transfer and the features an operation requires. 3 つのパターンを指定するには、WCF プログラミング モデルで: 要求/応答、一方向と双方向メッセージ パターン。You can specify three patterns in the WCF programming model: request/reply, one-way, and duplex message patterns.

要求/応答Request/Reply

要求/応答パターンでは、要求の送信側 (クライアント アプリケーション) は、その要求に関連付けられた応答を受信します。A request/reply pattern is one in which a request sender (a client application) receives a reply with which the request is correlated. このパターンでは、1 つの操作において、1 つ以上のパラメーターを操作に渡し、戻り値を呼び出し元に返すことができるため、このパターンが既定の MEP となります。This is the default MEP because it supports an operation in which one or more parameters are passed to the operation and a return value is passed back to the caller. たとえば、次の C# コード例は、文字列を 1 つ受け取り、文字列を返す基本的なサービス操作を示しています。For example, the following C# code example shows a basic service operation that takes one string and returns a string.

[OperationContractAttribute]  
string Hello(string greeting);  

次のコードは同等の Visual Basic コードです。The following is the equivalent Visual Basic code.

<OperationContractAttribute()>  
Function Hello (ByVal greeting As String) As String  

この操作シグネチャは、基になるメッセージ交換の形式を指定しています。This operation signature dictates the form of underlying message exchange. 相関関係がない場合、WCF は戻り値の対象とする操作を特定できません。If no correlation existed, WCF cannot determine for which operation the return value is intended.

返すサービス操作を別の基になるメッセージ パターンを指定しない限りもメモvoid(Nothing Visual Basic で) 要求/応答メッセージ交換が。Note that unless you specify a different underlying message pattern, even service operations that return void (Nothing in Visual Basic) are request/reply message exchanges. クライアントが操作を非同期で呼び出していない場合、通常、メッセージが空の場合でも、戻りメッセージを受信するまでクライアントは処理を中止します。The result for your operation is that unless a client invokes the operation asynchronously, the client stops processing until the return message is received, even though that message is empty in the normal case. クライアントが応答で空のメッセージを受信するまで制御が戻らない操作の C# コード例を次に示します。The following C# code example shows an operation that does not return until the client has received an empty message in response.

[OperationContractAttribute]  
void Hello(string greeting);  

次のコードは同等の Visual Basic コードです。The following is the equivalent Visual Basic code.

<OperationContractAttribute()>  
Sub Hello (ByVal greeting As String)  

上記の例では、実行に時間のかかる操作の場合に、クライアントのパフォーマンスと応答性が低下するおそれがありますが、要求/応答操作で void を返す場合でも、この操作には利点があります。The preceding example can slow client performance and responsiveness if the operation takes a long time to perform, but there are advantages to request/reply operations even when they return void. 最も明らかな利点は、応答メッセージで SOAP エラーを返すことが可能であるということです。これにより、通信と処理のどちらで発生したかに関係なく、サービス関連の何らかのエラー状態が発生したことがわかります。The most obvious one is that SOAP faults can be returned in the response message, which indicates that some service-related error condition has occurred, whether in communication or processing. サービス コントラクトに指定された SOAP エラーは、FaultException<TDetail> オブジェクトとしてクライアント アプリケーションに渡されます。このオブジェクトの型パラメーターは、サービス コントラクトで指定された型です。SOAP faults that are specified in a service contract are passed to the client application as a FaultException<TDetail> object, where the type parameter is the type specified in the service contract. これによりエラー状態に関するクライアントに通知の WCF サービスで簡単。This makes notifying clients about error conditions in WCF services easy. 例外、SOAP エラー、およびエラー処理の詳細については、次を参照してください。を指定すると処理のエラー コントラクトおよびサービスのします。For more information about exceptions, SOAP faults, and error handling, see Specifying and Handling Faults in Contracts and Services. 要求/応答サービスおよびクライアントの例を表示するには、次を参照してください。方法。要求/応答コントラクトを作成するします。To see an example of a request/reply service and client, see How to: Create a Request-Reply Contract. 要求/応答パターンに関する問題の詳細については、次を参照してください。要求/応答サービスします。For more information about issues with the request-reply pattern, see Request-Reply Services.

一方向One-way

WCF サービス アプリケーションのクライアントが必要があります、操作が完了するを待たず、SOAP エラーを処理しない場合、操作が一方向メッセージ パターンを指定できます。If the client of a WCF service application should not wait for the operation to complete and does not process SOAP faults, the operation can specify a one-way message pattern. 一方向の操作をクライアントが操作を起動し、WCF メッセージをネットワークに後の処理を続行できます。A one-way operation is one in which a client invokes an operation and continues processing after WCF writes the message to the network. 通常、これは、送信メッセージで送信するデータが膨大な量でない限り、(データ送信時にエラーが発生しなければ) クライアントはほぼすぐに実行を続けることを意味します。Typically this means that unless the data being sent in the outbound message is extremely large the client continues running almost immediately (unless there is an error sending the data). この種のメッセージ交換パターンでは、クライアントからサービス アプリケーションへのイベントのような動作をサポートします。This type of message exchange pattern supports event-like behavior from a client to a service application.

1 つのメッセージを送信し、何も受信しないメッセージ交換では、void 以外の戻り値を指定したサービス操作をサポートすることはできません。この場合、InvalidOperationException 例外がスローされます。A message exchange in which one message is sent and none are received cannot support a service operation that specifies a return value other than void; in this case an InvalidOperationException exception is thrown.

戻りメッセージがないということは、処理または通信時のエラーを示すために SOAP エラーを返すこともできないということです No return message also means that there can be no SOAP fault returned to indicate any errors in processing or communication. (操作が一方向操作の場合にエラー情報を伝達するには、双方向メッセージ交換パターンが必要です)。(Communicating error information when operations are one-way operations requires a duplex message exchange pattern.)

void を返す操作で一方向メッセージ交換を指定するには、次の C# コード例に示すように、IsOneWay プロパティを true に設定します。To specify a one-way message exchange for an operation that returns void, set the IsOneWay property to true, as in the following C# code example.

[OperationContractAttribute(IsOneWay=true)]  
void Hello(string greeting);  

次のコードは同等の Visual Basic コードです。The following is the equivalent Visual Basic code.

<OperationContractAttribute(IsOneWay := True)>  
Sub Hello (ByVal greeting As String)  

このメソッドは、前述の要求/応答の例と同じです。ただし、IsOneWay プロパティを true に設定するということは、メソッドは同じでも、サービス操作は戻りメッセージを送信せず、送信メッセージがチャネル レイヤーに渡されると、すぐにクライアントに制御が戻ることを意味します。This method is identical to the preceding request/reply example, but setting the IsOneWay property to true means that although the method is identical, the service operation does not send a return message and clients return immediately once the outbound message has been handed to the channel layer. 例については、「方法: 一方向コントラクトを作成するします。For an example, see How to: Create a One-Way Contract. 一方向パターンの詳細については、次を参照してください。一方向サービスします。For more information about the one-way pattern, see One-Way Services.

二重Duplex

双方向パターンの特徴は、一方向メッセージングと要求/応答メッセージングのどちらを使用しているかに関係なく、サービスとクライアントが共に独立して、相互にメッセージを送信できるという点です。A duplex pattern is characterized by the ability of both the service and the client to send messages to each other independently whether using one-way or request/reply messaging. 二方向通信のこの形式は、サービスがクライアントと直接通信する必要がある場合や、イベントのような動作など、メッセージを交換するどちらの側も非同期で動作できるようにする場合に役立ちます。This form of two-way communication is useful for services that must communicate directly to the client or for providing an asynchronous experience to either side of a message exchange, including event-like behavior.

双方向パターンでは、クライアントと通信するための機構が別途必要になるため、要求/応答パターンや一方向パターンに比べると若干複雑になります。The duplex pattern is slightly more complex than the request/reply or one-way patterns because of the additional mechanism for communicating with the client.

双方向コントラクトを設計する場合、コールバック コントラクトも設計し、そのコールバック コントラクトの型を、サービス コントラクトをマークする CallbackContract 属性の ServiceContractAttribute プロパティに割り当てる必要があります。To design a duplex contract, you must also design a callback contract and assign the type of that callback contract to the CallbackContract property of the ServiceContractAttribute attribute that marks your service contract.

双方向パターンを実装するには、クライアントで呼び出されるメソッド宣言を含む 2 つ目のインターフェイスを作成する必要があります。To implement a duplex pattern, you must create a second interface that contains the method declarations that are called on the client.

サービス、およびそのサービスにアクセスするクライアントの作成の例は、次を参照してください。方法。双方向コントラクトを作成する方法。双方向コントラクトでサービスへのアクセスします。For an example of creating a service, and a client that accesses that service, see How to: Create a Duplex Contract and How to: Access Services with a Duplex Contract. 実際のサンプルでは、次を参照してください。双方向します。For a working sample, see Duplex. 双方向コントラクトを使用して問題の詳細については、次を参照してください。双方向サービスします。For more information about issues using duplex contracts, see Duplex Services.

注意事項

サービスは、双方向メッセージを受信すると、その受信メッセージの ReplyTo 要素を参照して応答の送信先を決定します。When a service receives a duplex message, it looks at the ReplyTo element in that incoming message to determine where to send the reply. メッセージの受信に使用するチャネルがセキュリティで保護されていない場合、信頼関係のないクライアントが対象コンピューターの ReplyTo を使用して悪意のあるメッセージを送信し、その対象コンピューターのサービス拒否 (DOS: Denial Of Service) を引き起こすおそれがあります。If the channel that is used to receive the message is not secured, then an untrusted client could send a malicious message with a target machine's ReplyTo, leading to a denial of service (DOS) of that target machine.

Out パラメーターと Ref パラメーターOut and Ref Parameters

ほとんどの場合で使用できますinパラメーター (ByVal Visual basic) とoutrefパラメーター (ByRef Visual Basic で)。In most cases, you can use in parameters (ByVal in Visual Basic) and out and ref parameters (ByRef in Visual Basic). out パラメーターと ref パラメーターは、操作からデータが返されることを示すため、操作シグネチャが void を返す場合でも、次のような操作シグネチャによって要求/応答操作が必要であることを指定します。Because both out and ref parameters indicate that data is returned from an operation, an operation signature such as the following specifies that a request/reply operation is required even though the operation signature returns void.

[ServiceContractAttribute]  
public interface IMyContract  
{  
  [OperationContractAttribute]  
  public void PopulateData(ref CustomDataType data);  
}  

次のコードは同等の Visual Basic コードです。The following is the equivalent Visual Basic code.

<ServiceContractAttribute()> _  
Public Interface IMyContract  
  <OperationContractAttribute()> _  
  Public Sub PopulateData(ByRef data As CustomDataType)  
End Interface  

唯一の例外は、シグネチャに特定の構造体が含まれている場合です。The only exceptions are those cases in which your signature has a particular structure. たとえば、NetMsmqBinding バインディングを使用してクライアントと通信できるのは、操作の宣言に使用されたメソッドが void を返す場合だけです。戻り値、ref パラメーター、または out パラメーターのいずれであるかに関係なく、出力値を指定することはできません。For example, you can use the NetMsmqBinding binding to communicate with clients only if the method used to declare an operation returns void; there can be no output value, whether it is a return value, ref, or out parameter.

また、out パラメーターまたは ref パラメーターを使用する場合、操作には基になる応答メッセージが必要です。このメッセージが変更されたオブジェクトを返します。In addition, using out or ref parameters requires that the operation have an underlying response message to carry back the modified object. 操作が一方向操作の場合、実行時に InvalidOperationException 例外がスローされます。If your operation is a one-way operation, an InvalidOperationException exception is thrown at runtime.

コントラクトでのメッセージ保護レベルの指定Specify Message Protection Level on the Contract

コントラクトの設計時に、コントラクトを実装するサービスのメッセージ保護レベルも決定する必要があります。When designing your contract, you must also decide the message protection level of services that implement your contract. これは、メッセージ セキュリティをコントラクトのエンドポイントのバインディングに適用する場合にのみ必要です。This is necessary only if message security is applied to the binding in the contract's endpoint. バインディングのセキュリティが無効になっている場合 (つまり、システム指定のバインディングで System.ServiceModel.SecurityMode の値が SecurityMode.None に設定されている場合)、コントラクトのメッセージ保護レベルを決定する必要はありません。If the binding has security turned off (that is, if the system-provided binding sets the System.ServiceModel.SecurityMode to the value SecurityMode.None) then you do not have to decide on the message protection level for the contract. ほとんどの場合、メッセージ レベルのセキュリティが適用されたシステム指定のバインディングは、十分な保護レベルを備えているため、操作ごとまたはメッセージごとに保護レベルを検討する必要はありません。In most cases, system-provided bindings with message-level security applied provide a sufficient protection level and you do not have to consider the protection level for each operation or for each message.

保護レベルは、サービスをサポートするメッセージ (またはメッセージ部分) が署名されるのか、署名および暗号化されるのか、または署名と暗号化なしで送信されるのかを指定する値です。The protection level is a value that specifies whether the messages (or message parts) that support a service are signed, signed and encrypted, or sent without signatures or encryption. 保護レベルは、さまざまなスコープで設定できます。サービス レベルの操作、またはメッセージ部分内のメッセージの特定の操作。The protection level can be set at various scopes: At the service level, for a particular operation, for a message within that operation, or a message part. あるスコープで設定された値は、明示的にオーバーライドしない限り、そのスコープよりも小さなスコープの既定値になります。Values set at one scope become the default value for smaller scopes unless explicitly overridden. コントラクトに必要とされる最小限の保護レベルをバインディング構成で提供できない場合は、例外がスローされます。If a binding configuration cannot provide the required minimum protection level for the contract, an exception is thrown. 保護レベルの値がコントラクトで明示的に設定されていない場合、バインディングのメッセージ セキュリティが有効であれば、バインド構成によってすべてのメッセージの保護レベルが制御されます。And when no protection level values are explicitly set on the contract, the binding configuration controls the protection level for all messages if the binding has message security. これが既定の動作です。This is the default behavior.

重要

一般に、コントラクトのさまざまなスコープを完全な保護レベルである ProtectionLevel.EncryptAndSign よりも下のレベルに明示的に設定するかどうかは、パフォーマンスの向上と引き換えに、ある程度のセキュリティで妥協できるかどうかという判断によって決まります。Deciding whether to explicitly set various scopes of a contract to less than the full protection level of ProtectionLevel.EncryptAndSign is generally a decision that trades some degree of security for increased performance. このような場合、操作および操作で交換するデータの価値に焦点を絞って判断を下す必要があります。In these cases, your decisions must revolve around your operations and the value of the data they exchange. 詳細については、次を参照してください。 Securing Servicesします。For more information, see Securing Services.

たとえば、次のコード例では、ProtectionLevel も、コントラクトの ProtectionLevel プロパティも設定していません。For example, the following code example does not set either the ProtectionLevel or the ProtectionLevel property on the contract.

[ServiceContract]  
public interface ISampleService  
{  
  [OperationContractAttribute]  
  public string GetString();  
  
  [OperationContractAttribute]  
  public int GetInt();    
}  

次のコードは同等の Visual Basic コードです。The following is the equivalent Visual Basic code.

<ServiceContractAttribute()> _  
Public Interface ISampleService  
  
  <OperationContractAttribute()> _  
  Public Function GetString()As String  
  
  <OperationContractAttribute()> _  
  Public Function GetData() As Integer  
  
End Interface  

既定の ISampleService (既定の WSHttpBindingSystem.ServiceModel.SecurityMode) を使用するエンドポイントの Message 実装とやり取りする場合は、暗号化と署名が既定の保護レベルであるため、すべてのメッセージが暗号化および署名されます。When interacting with an ISampleService implementation in an endpoint with a default WSHttpBinding (the default System.ServiceModel.SecurityMode, which is Message), all messages are encrypted and signed because this is the default protection level. ただし、既定の ISampleService (既定の BasicHttpBindingSecurityMode) を使用して None サービスを使用すると、すべてのメッセージがテキストとして送信されます。これは、このバインディングにはセキュリティがないため、保護レベルが無視されるためです (つまり、メッセージの暗号化も署名も行われません)。However, when an ISampleService service is used with a default BasicHttpBinding (the default SecurityMode, which is None), all messages are sent as text because there is no security for this binding and so the protection level is ignored (that is, the messages are neither encrypted nor signed). SecurityModeMessage に変更すると、これがこのバインディングの既定の保護レベルになるため、これらのメッセージは暗号化および署名されるようになります。If the SecurityMode was changed to Message, then these messages would be encrypted and signed (because that would now be the binding's default protection level).

コントラクトの保護要件を明示的に指定または調整する場合は、ProtectionLevel プロパティ (またはより小さなスコープの ProtectionLevel プロパティのいずれか) をサービス コントラクトに必要なレベルに設定します。If you want to explicitly specify or adjust the protection requirements for your contract, set the ProtectionLevel property (or any of the ProtectionLevel properties at a smaller scope) to the level your service contract requires. この場合、明示的な設定を使用するには、使用するスコープに少なくともその設定をサポートするバインディングが必要です。In this case, using an explicit setting requires the binding to support that setting at a minimum for the scope used. たとえば、次のコード例では、ProtectionLevel 操作の GetGuid の値を明示的に指定しています。For example, the following code example specifies one ProtectionLevel value explicitly, for the GetGuid operation.

[ServiceContract]  
public interface IExplicitProtectionLevelSampleService  
{  
  [OperationContractAttribute]  
  public string GetString();  
  
  [OperationContractAttribute(ProtectionLevel=ProtectionLevel.None)]  
  public int GetInt();    
  [OperationContractAttribute(ProtectionLevel=ProtectionLevel.EncryptAndSign)]  
  public int GetGuid();    
}  

次のコードは同等の Visual Basic コードです。The following is the equivalent Visual Basic code.

<ServiceContract()> _   
Public Interface IExplicitProtectionLevelSampleService   
    <OperationContract()> _   
    Public Function GetString() As String   
    End Function   
  
    <OperationContract(ProtectionLevel := ProtectionLevel.None)> _   
    Public Function GetInt() As Integer   
    End Function   
  
    <OperationContractAttribute(ProtectionLevel := ProtectionLevel.EncryptAndSign)> _   
    Public Function GetGuid() As Integer   
    End Function   
  
End Interface  

この IExplicitProtectionLevelSampleService コントラクトを実装し、既定の WSHttpBinding (既定の System.ServiceModel.SecurityModeMessage) を使用するエンドポイントを持つサービスの動作は次のようになります。A service that implements this IExplicitProtectionLevelSampleService contract and has an endpoint that uses the default WSHttpBinding (the default System.ServiceModel.SecurityMode, which is Message) has the following behavior:

  • GetString 操作のメッセージは、暗号化および署名されます。The GetString operation messages are encrypted and signed.

  • GetInt 操作のメッセージは、暗号化も署名もされない (プレーン) テキストとして送信されます。The GetInt operation messages are sent as unencrypted and unsigned (that is, plain) text.

  • GetGuid 操作の System.Guid は、暗号化および署名されたメッセージで返されます。The GetGuid operation System.Guid is returned in a message that is encrypted and signed.

保護レベルとその使用方法の詳細については、次を参照してください。について保護レベルします。For more information about protection levels and how to use them, see Understanding Protection Level. セキュリティの詳細については、次を参照してください。 Securing Servicesします。For more information about security, see Securing Services.

操作シグネチャのその他の要件Other Operation Signature Requirements

アプリケーションの一部の機能では、特定の種類の操作シグネチャを必要とします。Some application features require a particular kind of operation signature. たとえば、NetMsmqBinding バインディングは、永続的なサービスとクライアントをサポートします。永続的なサービスとクライアントでは、通信の途中でアプリケーションを再起動し、メッセージを失うことなく、アプリケーションが中止された場所を検出できます For example, the NetMsmqBinding binding supports durable services and clients, in which an application can restart in the middle of communication and pick up where it left off without missing any messages. (詳細については、次を参照してくださいWCF のキュー。)。ただし、永続的操作では、in パラメーターを 1 つしか受け取ることができず、戻り値を持つこともできません。(For more information, see Queues in WCF.) However, durable operations must take only one in parameter and have no return value.

もう 1 つの例として、操作における Stream 型の使用が挙げられます。Another example is the use of Stream types in operations. Stream パラメーターにはメッセージの本文全体が含まれるため、入力または出力 (つまり、ref パラメーター、out パラメーター、または戻り値) が Stream 型である場合、操作で指定された入力または出力に限定する必要があります。Because the Stream parameter includes the entire message body, if an input or an output (that is, ref parameter, out parameter, or return value) is of type Stream, then it must be the only input or output specified in your operation. また、パラメーターまたは戻り値の型は StreamSystem.ServiceModel.Channels.MessageSystem.Xml.Serialization.IXmlSerializable のいずれかである必要があります。In addition, the parameter or return type must be either Stream, System.ServiceModel.Channels.Message, or System.Xml.Serialization.IXmlSerializable. ストリームの詳細については、次を参照してください。 Large Data and Streamingします。For more information about streams, see Large Data and Streaming.

名前、名前空間、および難読化Names, Namespaces, and Obfuscation

コントラクトおよび操作の定義内の .NET 型の名前や名前空間は、コントラクトが WSDL に変換されるとき、およびコントラクト メッセージが作成および送信されるときに重要になります。The names and namespaces of the .NET types in the definition of contracts and operations are significant when contracts are converted into WSDL and when contract messages are created and sent. したがって、サービス コントラクトの名前と名前空間は、NameNamespaceServiceContractAttributeOperationContractAttribute などの、すべてのサポート対象コントラクト属性や、他のコントラクト属性の DataContractAttribute プロパティと DataMemberAttribute プロパティを使用して明示的に設定することを強くお勧めします。Therefore, it is strongly recommended that service contract names and namespaces are explicitly set using the Name and Namespace properties of all supporting contract attributes such as the ServiceContractAttribute, OperationContractAttribute, DataContractAttribute, DataMemberAttribute, and other contract attributes.

この 1 つの結果として、名前と名前空間が明示的に設定されていない場合、アセンブリで IL 難読化を使用すると、コントラクトの型名と名前空間が変更され、その結果、WSDL が変更され、通常はネットワークでのメッセージ交換に失敗します。One result of this is that if the names and namespaces are not explicitly set, the use of IL obfuscation on the assembly alters the contract type names and namespaces and results in modified WSDL and wire exchanges that typically fail. コントラクトの名前と名前空間を明示的に設定せずに難読化を使用する場合は、ObfuscationAttribute 属性と ObfuscateAssemblyAttribute 属性を使用して、コントラクトの型名と名前空間が変更されないようにします。If you do not set the contract names and namespaces explicitly but do intend to use obfuscation, use the ObfuscationAttribute and ObfuscateAssemblyAttribute attributes to prevent the modification of the contract type names and namespaces.

関連項目See also