【IT168 专稿】当内置WCF编码器无法满足我们的要求的时候,可以根据本文介绍的方法创建一个定制的编码器,然后将其作为插件使用即可。
对于现代的程序设计来说,压缩处理几乎已经变成一个完整的设计步骤,因为串行化数据的压缩能够很好为数据瘦身,从而降低网络流量导致的花销。可以进行无缝压缩的方法有很多,不过都很难上手,并且很难成功运行,这些方法包括:
·建立在客户端和服务端进行数据数据压缩和解压缩的代理工厂。
·在服务器端添加代码,以便在实体串行化之后压缩成字节数组,然后再将其发送出去。
·在客户端进行逆过程,即添加用于解压缩的代码,以便将压缩后的字节数组转换成预定义类型。
·定制代码以便在客户端试图对响应进行解压之前判断服务器返回的是否为压缩后的响应,代码如下所示:
if (WebResponse.ContentEncoding.ToLower().Contains("gzip"))
responseStream = new GZipStream(responseStream,
CompressionMode.Decompress);
else if(WebResponse.ContentEncoding.ToLower().Contains("deflate"))
responseStream = new DeflateStream(
responseStream,CompressionMode.Decompress);
1.术语和类
下面,我们首先对下文中用到的一些处理消息和编码的术语进行简单的解释:
·消息:即包含请求和响应数据的对象。
·捆绑技术:定义数据跨端点传输方式的一个规范。它包含协议、消息编码器和端点。
·端点:接收/发送端口。
·消息编码器:消息编码器的作用是把一个消息实例串行化为一系列字节。特定消息应该使用定义在消息编码捆绑元素中的消息编码器。
WCF自身包含三个消息编码器,分别为Binary、Text 和MTOM(Message Transmission Optimization Mechanism ,消息传输优化机制)。 消息编码器首先对出站的消息进行序列化处理,然后将序列化的消息传递给传输层。另一端的消息编码器从传输层收到序列化的消息后,执行定制的行为,然后将解序列化的消息传递给协议层/发起调用的应用程序。
虽然消息编码器位于传输层,但是却无法为所有的客户端所用。幸运的是,我们可以使用WCF的端点来很轻松地克服这个问题。 我们可以设计多个端点来满足不同的客户端的需求。因此,我们可以使用多个编码器(有或者没有压缩),并让客户端根据自身情况来决定使用哪些编码器。
一个理想的解决方案是,在WCF通信双方的信道中,拿出一个信道用以识别数据是否被压缩了,如果是的话,就对压缩后的数据进行解压处理,这样就能够进行无缝的数据传输了。
有趣的是,这种定制的编码处理对于核心WCF服务开发人员来说是透明的,我们只想把定制的编码器简单挂接到客户和服务器端即可。
以下捆绑元素来自于MessageEncodingBindingElement类,这个类提供了Binary、Text和MTOM编码:
·TextMessageEncodingBindingElement:这个捆绑元素很少用到,因为对于消息来说,其编码效果是最差的。尤其是当传输大量的文本时,其效率极差,会耗费大量的网络和时间资源。
·BinaryMessageEncodingBindingElement:这个捆绑元素用得较广,因为它不仅支持消息版本控制,同时还能对基于二进制的消息进行编码。
·MTOMMessageEncodingBindingElement:这个捆绑最适合于二进制信息数据的传输。
这些捆绑元素会创建一个MessageEncoderFactory,随后MessageEncoderFactory创建单个MessageEncoder实例来把消息序列化为字节。