mule in action翻译25 : 4.3.2 压缩数据

mule in action翻译25 : 4.3.2 压缩数据

     以字节的形式表示消息,消息可能会变的比较大,甚至会大到几乎不能正常通过网络发送。例如,JMS消息提供者应当避免发布太“重”的消息;当你的消息开始超过几百KB时,就应当考虑进行压缩。如今XML成为了消息系统中payload的常见形式,XML是适合进行压缩的,压缩后可以大幅减小数据体积。

    

   在mule中如何压缩数据?假使你必须向一个JMS队列发送大的字符串,监听队列的消息消费者则期望你在发送之前对数据进行压缩。这种情况下,gzipcompress-transformer 是你较好的选择。下面的列表中,展示了如何使用它。

Listing4.3 Compressing a payload using gzip

<string-to-byte-array-transformer/>
<gzip-compress-transformer/>
<jms:outbound-endpoint
queue="compressedDataQueue"
connector-ref="dataJmsConnector"/>

 

   上面为什么要使用两个转换器?为什么不直接应用gzip-compresstransformer?在gzip-compress-transformer 之前使用 string-to-byte-array-transformer的原因是比较微妙的。endpoint接收到一个java.lang.String类型的payload后,由于String类实现了序列化接口,压缩器会首先把String进行序列化,然后再压缩它。但是你想向JMS队列发送的是压缩后的字符串,而不是压缩的序列化对象。这正是首先使用string-to-byte-arraytransformer的原因。

 

   相反地,如果接受数据的是Mule JMS inbound endpoint, 事实上你必须使用好几个转换器--要以相反的顺序使用上面的列表中转换器对应的“返回”转换器。下面列表是个示例:

Listing4.4 Uncompressing a payload using gzip

<jms:inbound-endpoint queue="compressedDataQueue" connector-ref="dataJmsConnector"/>
<gzip-uncompress-transformer/>
<byte-array-to-string-transformer/>

 

   目前学习到的都是进行payload类型转换的转换器,下一节学习可以修改消息属性的转换器。

 

 

你可能感兴趣的:(mule,ESB)