先說說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