先說說hessian有什么優點和缺點
一、優點：
比 Java 原生的對象序列化/反序列化速度更快, 序列化出來以后的數據更小.序列化協議跟應用層協議無關, 可以將 Hessian 序列化以后的數據放在 HTTP Body 里, 也可以放在 DUBBO 里, 或者直接用 Socket 傳輸。Hessian協議和web service常用的SOAP協議類似，也是將協議報文封裝在HTTP封包中，通過HTTP信道進行傳輸的。因此Hessian協議具有與SOAP協議同樣的優點，即傳輸不受防火牆的限制（防火牆通常不限制HTTP信道），不需要配置防火牆。Hessian類似於Webservice，但是它不使用soap協議，它把協議報文封裝到http封包中，通過HTTP信道傳輸。是一種高效簡潔的遠程調用框架，它采用的是二進制RPC協議（Binary），具有輕量、傳輸量小、平台無關的特點，特別適合於目前網絡帶寬比較小的手機網絡應用項目。簡單易用，面向接口，通過接口暴露服務，jar包只有200、300k，效率高，復雜對象序列化速度僅次於RMI，簡單對象序列化優於RMI，二進制傳輸多語言支持。為什么序列化后數據更小呢？因為：
它把本地格式的數據編碼為二進制數據，僅用一個字符作為結構化標記，HBWSP封裝后的數據增量明顯小於SOAP封裝后的數據增量。並且相對於SOAP，Hessian協議的外部數據表示有3個顯著的優勢：
1）采用簡單的結構化標記。簡單的結構化標記減少了編碼、解碼操作對內存的占用量。編碼時，只需寫少量的數據，就可以標記結構；解碼時，只需讀少量的數據就可以確定結構。而且，簡單的結構化標記減少了編碼后的數據增量。
2）采用定長的字節記錄值。用定長的字節記錄值，解碼時，就可以使用位操作從固定長度的位獲得值。這樣不僅操作簡單，而且可以獲得較高的性能。
3）采用引用取代重復遇到的對象。使用引用取代重復遇到的對象可以避免對重復對象的編碼，而且也減少了編碼后的數據量。
因此使用Hessian協議傳輸數據量比SOAP協議要小得多。實踐證明，傳輸同樣的對象Hessian協議傳輸的數據量比SOAP協議低一個數量級。因此Hessian協議比SOAP協議更適用於分布式應用系統間大數據量的數據交換
Hessian是通過servlet提供遠程服務，完全使用動態代理來實現的,推薦采用面向接口編程，因此，Hessian服務建議通過接口暴露。hessian已經支持Java，Flash/Flex，Python，C++，.NET C#，D，Erlang，PHP，Ruby，Objective C。
二、缺點
如果service層中返回的對象是復雜對象,使用它就會削弱Hessian的傳輸量小的優點，而且也會增加Hessian客戶端的代碼量。既然它是把對象序列化為二進制流的形式在http信道中傳輸，那么對於安全性高的應用不應該采用hessian(比如網上支付等)。缺乏安全機制，傳輸沒有加密處理， 異常機制不完善，總是報一些錯誤，錯誤原因也是千奇百怪，提示信息不足， 事務處理欠缺， 版本問題，spring 2.5.6對照3.1.3版，spring 3對照4.0及以上版本，需要使用spring MVC。
關於hession和其他通訊RPC方式的一些比較
1.和dubbo對比：dubbo支持多種遠程調用方式，例如dubbo RPC（二進制序列化 + tcp協議）、http invoker（二進制序列化 + http協議，至少在開源版本沒發現對文本序列化的支持）、hessian（二進制序列化 + http協議）、WebServices （文本序列化 + http協議）等等...
2.和RMI,HTTPINvoker等對比
通訊效率測試結果:
RMI > Httpinvoker >= Hessian >> Burlap >> Web service
1.RMI 是 Java 首選遠程調用協議，非常高效穩定，特別是在數據結構復雜，數據量大的情況下，與其他通訊協議的差距尤為明顯。但不能跨語言。
2.HttpInvoker 使用 java 的序列化技術傳輸對象，與 RMI 在本質上是一致的。從效率上看，兩者也相差無幾， HttpInvoker 與 RMI 的傳輸時間基本持平。
3.Hessian 在傳輸少量對象時，比 RMI 還要快速高效，但傳輸數據結構復雜的對象或大量數據對象時，較 RMI 要慢 20% 左右。但這只是在數據量特別大，
數據結構很復雜的情況下才能體現出來，中等或少量數據時， Hessian並不比RMI慢。 Hessian 的好處是精簡高效，可以跨語言使用，而且協議規范公開，
我們可以針對任意語言開發對其協議的實現。另外， Hessian與WEB服務器結合非常好，借助WEB服務器的成熟功能，在處理大量用戶並發訪問時會有很大優勢，在資源分配，
線程排隊，異常處理等方面都可以由成熟的WEB服務器保證。而 RMI 本身並不提供多線程的服務器。而且，RMI 需要開防火牆端口， Hessian 不用。
4.Burlap 采用 xml 格式傳輸。僅在傳輸 1 條數據時速度尚可，通常情況下，它的毫時是 RMI 的 3 倍。
5.Web Service 的效率低下是眾所周知的，平均來看， Web Service 的通訊毫時是 RMI 的 10 倍。
三、關於hessian的7個問題：
1、是基於什么協議實現的？
基於Binary-RPC協議實現。
2、怎么發起請求？
需通過Hessian本身提供的API來發起請求。
3、怎么 將請求轉化為符合協議的格式的？
Hessian通過其自定義的串行化機制將請求信息進行序列化，產生二進制流。
4、使用什么 傳輸協議傳輸？
Hessian基於Http協議進行傳輸。
5、響應端基於什么機制來接收請求？
響應端根據Hessian提供的API來接收請求。
6、怎么將流還原為傳輸格式的？
Hessian根據其私有的串行化機制來將請求信息進行反序列化，傳遞給使用者時已是相應的請求信息對象了。
7、處理完畢后怎么回應？
處理完畢后直接返回，hessian將結果對象進行序列化，傳輸至調用端。
springMvc集成hession的例子：http://blog.csdn.net/isea533/article/details/45038779
--------------------- 本文來自 馬萬明 的CSDN 博客 ，全文地址請點擊：https://blog.csdn.net/mawming/article/details/52151879?utm_source=copy