• 1.服务契约
• 服务契约定义了服务的操作,即服务类所发布的接口方法。服务契约为服务提供正式的 WSDL接口。通过[ServiceContract]与[OperationContract]属性,就可以定义服务契约。默认的操作名称是从类和方法名得来的,不过也可以在定义这些属性的时候指定。服务契约支持3 种消息交换模式:请求一响应模式、单向模式和双工模式。
请求一响应模式的操作契约会令客户端的调用阻塞,也就是客户端等待服务操作结束,
• 请求一响应模式的操作契约会令客户端的调用阻塞,也就是客户端等待服务操作结束,然后才重新得到执行控制权。因此,这种模式的契约只应该用于服务调用相对快速且用户愿意等待相应结果的情况下。使用请求一响应消息交换模式时,如果服务请求的执行时间很长,客户端可以使用.NET异步模式来避免阻塞等待。
• 单向操作契约名符其实,是单向的,这种服务不会向客户端返回结果。服务操作的返回值类型必须为void,而且要在[OperationContract]属性上做[IsOneWay=true]的标记。单向契约可以在任何传输方式上实现,包括MSMQ
• 双工操作契约,对客户端与服务之间的请求与相应的执行进行了解耦,从而具有最大的自由度与最高的性能。客户端与服务之间的双工信道建立完毕后,无论是客户端还是服务都可以发起消息传递*这种模式非常适于用来对客户端作通知功能。
• 2.数据契约
• 数据契约定义了服务的应用层数据接口。凡是标有[DataComract]和[DataMember]属性的类,均会被包含在代表服务契约的WSDL中的XML模式定义(XSD)部分。其他数据类型也可以通过WSDL对外发布,如基本类型及标有[Serializable]的类型,由于[DataContract]对于序列化的规则是针对互通性设计的,WCF将其作为首选的序列化机制
• 具有[DataMember]的类成员,会被包含在一个数据契约中。这是严格按照自愿原则进行的,因此只有标有此属性的成员才会被包含在契约中。这也令[DataContract]较[Serializable] 更适宜作为序列化机制,毕竟后者会造成服务的内部结构被披露给外部。
• 契约也支持类的层次结构,其命名空间会伴随整个层次机构。为了支持多态及包含其他 对象的容器,WCF允许服务公布一系列己知类型,数据契约的设计也考虑了版本控制问题。 只要遵循一定的规则,即使向契约中添加了新成员,现有的客户端仍能继续工作.
• 3.消息契约
• 消息契约是定义于操作之上的契约,用于访问SOAP消息头及消息体。消息的数据类型, 可以通过[DataContract]或[Serializable]定义(有类型消息),也可以简单地定为Message类型 (无类型消息)。有类型消息之上,可以定义[MessageHeader]与[MessageBody]属性。消息的数 据结构在设计阶段可以是未知的,以取得最大的灵活度,无类型消息也能够访问SOAP消息 头和消息体。