[原创]WCF技术剖析之十七：消息（Message）详解（下篇）
[爱心链接：拯救一个25岁身患急性白血病的女孩[内有苏州电视台经济频道《天天山海经》为此录制的节目视频（苏州话）]]《WCF技术剖析（卷1）》自出版近20天以来，得到了园子里的朋友和广大WCF爱好者的一致好评，并被卓越网计算机书店作为首页推荐，在这里对大家的支持表示感谢。同时我将一直坚持这个博文系列，与大家分享我对WCF一些感悟和学习经验。在《消息（Message）详解》系列的上篇和中篇，先后对消息版本、详细创建、状态机和基于消息的基本操作（读取、写入、拷贝、关闭）进行了深入剖析，接下来我们来谈谈消息的另一个重要组成部分：消息报头（Message Header）。
按照SOAP1.1或者SOAP1.2规范，一个SOAP消息由若干SOAP报头和一个SOAP主体构成，SOAP主体是SOAP消息的有效负载，一个SOAP消息必须包含一个唯一的消息主体。SOAP报头是可选的，一个SOAP消息可以包含一个或者多个SOAP报头，SOAP报头一般用于承载一些控制信息。消息一经创建，其主体内容不能改变，而SOAP报头则可以自由地添加、修改和删除。正是因为SOAP的这种具有高度可扩展的设计，使得SOAP成为实现SOA的首选（有这么一种说法SOAP= SOA Protocol）。
按照SOAP 1.2规范，一个SOAP报头集合由一系列XML元素组成，每一个报头元素的名称为Header，命名空间为http://www.w3.org/2003/05/soap-envelope。每一个报头元素可以包含任意的属性（Attribute）和子元素。在WCF中，定义了一系列类型用于表示SOAP报头。
一、MessageHeaders、MessageHeaderInfo、MessageHeader和MessageHeader<T>
在Message类中，消息报头集合通过只读属性Headers表示，类型为System.ServiceModel.Channels.MessageHeaders。MessageHeaders本质上就是一个System.ServiceModel.Channels.MessageHeaderInfo集合。
1: public abstract class Message : IDisposable<!--CRLF-->
2: { <!--CRLF-->
3: //其他成员<!--CRLF-->
4: public abstract MessageHeaders Headers { get; }<!--CRLF-->
5: } <!--CRLF-->
1: public sealed class MessageHeaders : IEnumerable<MessageHeaderInfo>, IEnumerable<!--CRLF-->
2: { <!--CRLF-->
3: //省略成员<!--CRLF-->
4: } <!--CRLF-->
MessageHeaderInfo是一个抽象类型，是所有消息报头的基类，定义了一系列消息SOAP报头的基本属性。其中Name和Namespace分别表示报头的名称和命名空间，Actor、MustUnderstand、Reply与SOAP 1.1或者SOAP 1.2规定SOAP报头同名属性对应。需要对SOAP规范进行深入了解的读者可以从W3C官方网站下载相关文档。
1: public abstract class MessageHeaderInfo<!--CRLF-->
2: { <!--CRLF-->
3: protected MessageHeaderInfo();<!--CRLF-->
4: <!--CRLF-->
5: public abstract string Actor { get; }<!--CRLF-->
6: public abstract bool IsReferenceParameter { get; }<!--CRLF-->
7: public abstract bool MustUnderstand { get; }<!--CRLF-->
8: public abstract string Name { get; }<!--CRLF-->
9: public abstract string Namespace { get; }<!--CRLF-->
10: public abstract bool Relay { get; }<!--CRLF-->
11: } <!--CRLF-->
当我们针对消息报头编程的时候，使用到的是另一个继承自MessageHeaderInfo的抽象类：System.ServiceModel.Channels.MessageHeader。除了实现MessageHeaderInfo定义的抽象只读属性外，MessageHeader中定义了一系列工厂方法（CreateHeader）方便开发人员创建MessageHeader对象。这些CreateHeader方法接受一个可序列化的对象，并以此作为消息报头的内容，WCF内部会负责从对象到XML InfoSet的序列化工作。此外，可以通过相应的WriteHeader方法对MessageHeader对象执行写操作。MessageHeader定义如下：
1: public abstract class MessageHeader : MessageHeaderInfo<!--CRLF-->
2: { <!--CRLF-->
3: public static MessageHeader CreateHeader(string name, string ns, object value);<!--CRLF-->
4: public static MessageHeader CreateHeader(string name, string ns, object value, bool mustUnderstand);<!--CRLF-->
5: //其他CreateHeader方法<!--CRLF-->
6: <!--CRLF-->
7: public void WriteHeader(XmlDictionaryWriter writer, MessageVersion messageVersion);<!--CRLF-->
8: public void WriteHeader(XmlWriter writer, MessageVersion messageVersion);<!--CRLF-->
9: //其他WriteHeader方法<!--CRLF-->
10: <!--CRLF-->
11: public override string Actor { get; }<!--CRLF-->
12: public override bool IsReferenceParameter { get; }<!--CRLF-->
13: public override bool MustUnderstand { get; }<!--CRLF-->
14: public override bool Relay { get; }<!--CRLF-->
15: } <!--CRLF-->
除了MessageHeader，WCF还提供一个非常有价值的泛型类：System.ServiceModel. MessageHeader<T>，泛型参数T表示报头内容对应的类型，MessageHeader<T>为我们提供了强类型的报头创建方式。由于Message的Headers属性是一个MessageHeaderInfo的集合，MessageHeader<T>并不能直接作为Message对象的消息报头。GetUntypedHeader方法提供了从MessageHeader<T>对象到MessageHeader对象的转换。MessageHeader<T>定义如下：
1: public class MessageHeader<T><!--CRLF-->
2: { <!--CRLF-->
3: public MessageHeader();<!--CRLF-->
4: public MessageHeader(T content);<!--CRLF-->
5: public MessageHeader(T content, bool mustUnderstand, string actor, bool relay);<!--CRLF-->
6: public MessageHeader GetUntypedHeader(string name, string ns);<!--CRLF-->
7: <!--CRLF-->
8: public string Actor { get; set; }<!--CRLF-->
9: public T Content { get; set; }<!--CRLF-->
10: public bool MustUnderstand { get; set; }<!--CRLF-->
11: public bool Relay { get; set; }<!--CRLF-->
12: } <!--CRLF-->
接下来，我们通过一个简单的例子演示如何为一个Message对象添加报头。假设在一个WCF应用中，我们需要在客户端和服务端之间传递一些上下文（Context）的信息，比如当前用户的相关信息。为此我定义一个ApplicationContext类，这是一个集合数据契约（关于集合数据契约，可以参考我的文章：泛型数据契约和集合数据契约）。ApplicationContext是一个字典，为了简单起见，key和value均使用字符串。ApplicationContext不能被创建（构造函数被私有化），只能通过静态只读属性Current得到。当前ApplicationContext存入CallContext从而实现了在线程范围内共享的目的。在ApplicationContext中定义了两个属性UserName和Department，表示用户名称和所在部门。3个常量分别表示ApplicationContext存储于CallContext的Key，以及置于MessageHeader后对应的名称和命名空间。
1: [CollectionDataContract(Namespace = "http://www.artech.com/", ItemName = "Context", KeyName = "Key", ValueName = "Value")]<!--CRLF-->
2: public class ApplicationContext : Dictionary<string, string><!--CRLF-->
3: { <!--CRLF-->
4: private const string callContextKey = "__applicationContext";<!--CRLF-->
5: public const string HeaderLocalName = "ApplicationContext";<!--CRLF-->
6: public const string HeaderNamespace = "http://www.artech.com/";<!--CRLF-->
7: <!--CRLF-->
8: private ApplicationContext()<!--CRLF-->
9: { } <!--CRLF-->
10: <!--CRLF-->
11: public static ApplicationContext Current<!--CRLF-->
12: { <!--CRLF-->
13: get <!--CRLF-->
14: { <!--CRLF-->
15: if (CallContext.GetData(callContextKey) == null)<!--CRLF-->
16: { <!--CRLF-->
17: CallContext.SetData(callContextKey, new ApplicationContext());<!--CRLF-->
18: } <!--CRLF-->
19: return (ApplicationContext)CallContext.GetData(callContextKey);<!--CRLF-->
20: } <!--CRLF-->
21: } <!--CRLF-->
22: <!--CRLF-->
23: public string UserName<!--CRLF-->
24: { <!--CRLF-->
25: get <!--CRLF-->
26: { <!--CRLF-->
27: if (!this.ContainsKey("__username"))<!--CRLF-->
28: { <!--CRLF-->
29: return string.Empty;<!--CRLF-->
30: } <!--CRLF-->
31: return this["__username"];<!--CRLF-->
32: } <!--CRLF-->
33: set <!--CRLF-->
34: { <!--CRLF-->
35: this["__username"] = value;<!--CRLF-->
36: } <!--CRLF-->
37: } <!--CRLF-->
38: <!--CRLF-->
39: public string Department<!--CRLF-->
40: { <!--CRLF-->
41: get <!--CRLF-->
42: { <!--CRLF-->
43: if (!this.ContainsKey("__department"))<!--CRLF-->
44: { <!--CRLF-->
45: return string.Empty;<!--CRLF-->
46: } <!--CRLF-->
47: return this["__department"];<!--CRLF-->
48: } <!--CRLF-->
49: set <!--CRLF-->
50: { <!--CRLF-->
51: this["__department"] = value;<!--CRLF-->
52: } <!--CRLF-->
53: } <!--CRLF-->
54: } <!--CRLF-->
在下面代码中，首先对当前ApplicationContext进行相应的设置，然后创建MessageHeader<ApplicationContext>对象。通过调用GetUntypedHeader转换成MessageHeader对象之后，将其添加到Message的Headers属性集合中。后面是生成的SOAP消息。
1: Message message = Message.CreateMessage(MessageVersion.Default, "http://www.artech.com/myaction");<!--CRLF-->
2: ApplicationContext.Current.UserName = "Foo";<!--CRLF-->
3: ApplicationContext.Current.Department = "IT";<!--CRLF-->
4: MessageHeader<ApplicationContext> header = new MessageHeader<ApplicationContext>(ApplicationContext.Current);<!--CRLF-->
5: message.Headers.Add(header.GetUntypedHeader(ApplicationContext.HeaderLocalName, ApplicationContext.HeaderNamespace)); <!--CRLF-->
6: WriteMessage(message, @"e:\message.xml");<!--CRLF-->
1: <s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope"><!--CRLF-->
2: <s:Header><!--CRLF-->
3: <a:Action s:mustUnderstand="1">http://www.artech.com/myaction</a:Action><!--CRLF-->
4: <ApplicationContext xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.artech.com/"><!--CRLF-->
5: <Context><!--CRLF-->
6: <Key>__username</Key><!--CRLF-->
7: <Value>Foo</Value><!--CRLF-->
8: </Context><!--CRLF-->
9: <Context><!--CRLF-->
10: <Key>__department</Key><!--CRLF-->
11: <Value>IT</Value><!--CRLF-->
12: </Context><!--CRLF-->
13: </ApplicationContext><!--CRLF-->
14: </s:Header><!--CRLF-->
15: <s:Body /><!--CRLF-->
16: </s:Envelope><!--CRLF-->
二、实例演示：通过消息报头传递上下文信息
在演示添加消息报头的例子中，创建了一个ApplicationContext，这个类型将继续为本案例服务。上面仅仅是演示如果为一个现成的Message对象添加相应的报头，在本例中，我们将演示在一个具体的WCF应用中如何通过添加消息报头的方式从客户端向服务端传递一些上下文信息。
上面我们定义的ApplicationContext借助于CallContext实现了同一线程内数据的上下文消息的共享。由于CallContext的实现方式是将数据存储于当前线程的TLS（Thread Local Storage）中，所以它仅仅在客户端或者服务端执行的线程中有效。现在我们希望相同的上下文信息能够在客户端和服务端之间传递，毫无疑问，我们只有唯一的办法：就是将信息存放在请求消息和回复消息中。图1大体上演示了具体的实现机制。
客户端的每次服务调用，会将当前ApplicationContext封装成MessageHeader，存放到出栈消息（Outbound Message）的SOAP报头中；服务端在接收到入栈消息（InBound message）后，将其取出，作为服务端的当前ApplicationContext。由此实现了客户端向服务端的上下文传递。从服务端向客户端上下文传递的实现与此类似：服务端将当前ApplicationContext植入出栈消息（Outbound Message）的SOAP报头中，接收到该消息的客户端将其取出，覆盖掉现有上下文的值。
图1 上下文信息传递在消息交换中的实现
我们知道了如何实现消息报头的创建，现在需要解决的是如何将创建的消息报头植入到出栈和入栈消息报头集合中。我们可以借助System.ServiceModel.OperationContext实现这样的功能。OperationContext代表当前操作执行的上下文，定义了一系列与当前操作执行有关的上下文属性，其中就包含出栈和入栈消息报头集合。对于一个请求-回复模式服务调用来讲，IncomingMessageHeaders和OutgoingMessageHeaders对于客户端分别代表回复和请求消息的SOAP报头，对于服务端则与此相反。
注： OperationContext代表服务操作执行的上下文。通过OperationContext可以得到出栈和入栈消息的SOAP报头列表、消息属性或者HTTP报头。对于Duplex服务，在服务端可以通过OperationContext得到回调对象。此外通过OperationContext还可以得到基于当前执行的安全方面的属性一起的其他相关信息。
评论